At our presentation at Black Hat and Defcon this year, Shawn Moyer and I gave a talk called Weaponizing the Web: More Attacks on User Generated Content. During the talk we discussed something we are calling Dynamic Cross-Site Request Forgery (CSRF). Dynamic CSRF methods can be used to create new attack vectors and compromise CSRF protection mechanisms. CSRF is often difficult to explain in the first place, so I just wanted to do a post about it and link our Dynamic CSRF White Paper.

Static CSRF Attacks

The current way people are exploiting CSRF issues is pretty static. A link may be crafted and people are tricked in to clicking on it or viewing a page with this link embedded. They may even do something such as create an auto-submitting POST that the user executes when visiting certain content. The moral is that someone crafts this attack for a specific location and chooses a vector for delivering it to users. On it’s own, this static CSRF attack method can be pretty devastating or perhaps totally innocuous. That’s just the nature of CSRF. There aren’t too many vulnerabilities that fall in to this category, which may be why it can sometimes be hard to understand.

Let’s just think about some things that would make CSRF even more dangerous. What if we had visibility in to CSRF tokens or even session identifiers? What if we knew for sure a user was on the site that we wanted to attack? What if we could use a central point to dynamically attack multiple sites? What if we could create a custom payload on the fly to include tokens and session data? What if we could request data in another process and fixate it on to a request that the user executes? CSRF would become much more dangerous. Well, it just did….

Dynamic CSRF Attacks

With Dynamic CSRF attacks the game changes a bit. Attacks can be adapted based on where requests are originating from. Sensitive information sent in a cross-domain fashion can be packaged in to a customized payload and sent to a location. Disjoined or bolted on components can be queried and fixated on to a user’s request. This opens up new opportunities for attacks. Dynamic CSRF allows you to run one central system and run attacks for multiple sites and applications with the ability to remove and repackage any leaked session information.

Using dynamic methods may allow for the bypass of CSRF protections. Whether these protections are leaked in the referer or if they can be requested by other means and fixated on to the request, bypassing may be possible. This makes requests that were previously not vulnerable to CSRF vulnerable again.

When not limited by static requests a few new attack vectors open up. I just wanted to highlight a couple here.

Getting Dynamic

In the next couple of sections I am going to point out some dynamic methods for bypassing CSRF protection mechanisms.

HTTP Redirect

A simple redirect attack can be made more devastating with the addition of session related data added to the request. So a user hits a piece of HTML on a web page that sends a GET request containing session data (Session IDs, CSRF Tokens, etc) in the referer. This session data can be taken from the referer and repackaged in to a payload that is sent to the users browser as a location for a 302 redirect.

A scenario for this type of attack might be embedding a hidden image tag that links to a location offsite. This image tag may leak session data through referer allowing a tool to repackage that session data and get the user’s browser to execute it as a payload. This could be used to bypass CSRF protections by using the CSRF tokens from the referer.

HTML-based Redirect

For this scenario a hyperlink could point to a page that is created dynamically per-each request. This page contains a hidden GET or POST that could contain session data taken from referer as mentioned previously in the HTTP Redirect. The page would then refresh to a legitimate destination. To a user there would only appear to be a short pause prior to their landing on the legitimate destination, but in the background an attack has happened.

This attack could be made more interesting with URL shortening services. People have become accustomed to URL shorteners due to their use of Twitter and other social networks. Using a URL shortener would mask the location of the dynamic page and may not raise further suspicion.

A scenario for this would be posting a link that is shortened with a URL shortener on a web site that supposedly links to a video on YouTube. When the user clicks the link a hidden action (GET or POST) is executed. After the hidden action takes place, the browser does a refresh to the expected destination (the YouTube video). The victim may get little or no indication that the hidden attack has happened.

Fixation Based Attacks

Here is where things get a bit interesting. This attack hinges on the ability to have a valid CSRF token and a valid session identifier, but those two values aren’t associated together from a session perspective. Say you are posting on a message board. This message board issues you a Session ID in a cookie and also issues you a token for use when posting. If these two values aren’t linked from a session perspective, it would allow for any valid token to be added to the request. Since the Session ID is in the cookie value, if a forged request had a valid token appended this would bypass CSRF protections.

What makes this fixation attack an interesting scenario is it requires no leaking of any session data in a cross domain fashion. As long as you have some visibility to the token, it can be requested and fixated to the request.

Other Scenarios

There are other scenarios as well. It really depends on how much session data gets leaked in a cross-domain fashion. For example, if the full session ID is leaked, there could be some real problems. It could allow for a tool to construct any GET or any POST to the target application.

MonkeyFist

MonkeyFist is a tool I wrote to PoC Dynamic CSRF attacks. The tool runs as a small service on a system listening for all incoming input. When it receives a request it looks in the referer to determine where the request is coming from. It then uses this information to parse a payloads file and look for the specific attack to construct for that domain. You can have multiple entries in the payloads file performing multiple types of attacks. Redirect, POST, Page (GET and POST) and an Experimental Fixation handler are all included in the application. You can learn more about MonkeyFist on the the Hexsec Labs page. It is not exactly where I would like it to be, but it works. More streamlining and modifications will come soon. I am still recovering from Black Hat and Defcon

I have some posts on MonkeyFist that are coming soon as well.

More Info

That’s it for a quick intro to Dynamic CSRF. If you would like more information you can read our white paper which is available here.

As you probably know, Cross-Site Request Forgery (CSRF) can be a devastating vulnerability. Much of the focus has been on how this can affect your online accounts. CSRF can be used to exploit the trust of an authenticated connection you have to a web application. As an example, Shawn Moyer and I demonstrated several of these on Social Networks for our Black Hat 2008 / Defcon 16 talk. Slides from our talk can be downloaded here. I mean, the vulnerability itself was originally reported in 1988 so it is an old issue. Many people don’t realize that you can use CSRF to attack local network devices even services on the Localhost. For more information on localhost web services and CSRF check out an Rob Carter’s example for uTorrent here. Any network device on your local network that runs a web server can be vulnerable to the same attack as the Motorola / Netopia device I am about to discuss.

Recently, while getting ready for a web cast I am doing called: Cross-Site Request Forgery and Beyond, I was messing around with a Motorola / Netopia 2210 DSL modem. AT&T started issuing these modems in 2007. While looking at this device I noticed it was particularly vulnerable to a devastating attack. This demonstrates a perfect example of attacking local network devices though CSRF. This vulnerability isn’t just isolated to the Motorola / Netopia DSL modems, but most of them out there. By default most DSL modems, don’t require authentication to access the configuration menu. This is because of a mistaken assumption that only trusted devices would be on the local network. This is a mistake, because the user and their browser are on the local network, and they can’t always be trusted. People access so much content on the web, they never seem to know where their browser is sending requests.

Motorola / Netopia 2210 DSL modem Vulnerability

The reason this makes a perfect example is because it exploits an assumed trust relationship, allows request transformations, and complete ownage. When a user on the local network browses to the following URL they are greeted with the DSL configuration homepage. This is with no authentication by default. http://192.168.1.254

If you notice on the right hand side there is a menu option that says Remote Access. When you click on this option it takes you to the following screen.

As you can see remote admin is disabled by default. There is, however, a default username, empty password, and a couple of other options including Enable Permanent Remote Management. When you click the enable button a POST is sent to the device. This POST looks like this:

POST /Forms/remoteRES_1 HTTP/1.0
Host: 192.168.1.254
 
NSS_RemotePassword=blehblah&NSS_EnableWANAdminAccessRES=on&timeoutDisable=0&Enable=Enable

This POST will enable remote admin on the DSL modem, set the password to blehblah, and enable permanent remote access. Now, this is bad because this is done with no authentication. So if someone were to stage an auto-submitting JavaScript form, they would be able to submit values for this and enable their own password. So, let’s make matters a little worse. It appears that the DSL modem allows you to transform requests and still accept values. So, you can transform the previous POST request to a GET and get the same results. This means just getting the user to send a request to the following URL causes a compromise:

http://192.168.1.254/Forms/remoteRES_1?NSS_RemotePassword=blehblah&NSS_EnableWANAdminAccessRES=on&timeoutDisable=0&Enable=Enable

As you can see this is bad. Just getting a user to forge a request to that URL gets them to enable remote admin and set a password of an attacker’s choice. Ouch! This can be done a few different ways, but the most simple is an HTML img tag that is 1 x 1 px. So, the little red X doesn’t show when no image is retrieved.

<img src="http://192.168.1.254/Forms/remoteRES_1?NSS_RemotePassword=blehblah&NSS_EnableWANAdminAccessRES=on&timeoutDisable=0&Enable=Enable" alt="" width="1" height="1" />

If anyone with this DSL modem visits a page with this image tag on it, they will have remote admin set and a password of an attacker’s choice set. An attacker doesn’t have to just do this. They can pretty much control other options from the DSL modem as well through other submissions to the DSL modem. I mean, this stuff is incredibly simple and nothing complicated is required to exploit these types of issues.

Vulnerability Impacts

Remember that attacker has remote admin on your routing device. So, even if you have a network inside with private IP addresses, the attacker has access to your logs. It is trivial at that point to identify internal IP addresses and configure pass-through to these machines so they can attack them directly. Basically the machines on your local network can be compromised.

The attacker already has pieces of static information, that is the username: admin and the port number: 2420. A simple sweep for that port number could reveal results from compromise. Also, the attacker can have two img tags on a page, one that sets the remote admin and the other that just allows them to log the IP address of people visiting the content. This would help narrow down potential victims.

People have the ability to place their own content in many different popular locations. One of the biggest is of course Social Networks. For example, this vulnerability means that your DSL modem could be compromised just by visiting MySpace. That’s pretty scary. Just one more instance of how a social network can be turned in to an attack platform. I think I heard some people were talking about that not to long ago

This attack only took one request, just one HTTP GET. This attack could have been made a bit more difficult by not allowing requests to be sent in the form of an HTTP GET request. Not quite sure why this is, but it is a good bet that Motorola is not aware their little web server allows this. That is just a guess of course.

Mitigation

Um, just like you learned (or didn’t learn) with your Linksys wireless devices, change your defaults. CSRF vulnerabilities are exploited based off static, known data. Setting a password on your DSL modem and changing the default IP address of the device is a good start. While your at it why don’t you choose a strong password. I wouldn’t set remote admin in your DSL modem ever. Did you see what happened when you enabled remote admin? No cryptographic protections for your credentials, over the web, to your routing device. If you want to get fancy, configure yourself a Linux firewall and just let your DSL do IP passthrough to that device and do your configurations on that.

Don’t keep learning these lessons. Anything on your local network or localhost that has default settings, passwords, predictable locations, etc change them. This way, when future vulnerabilities arise, you will be better protected.