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.