Monday, August 1, 2016

Interesting Vulnerability in Some Cable Modems

Hey everyone - This is from a while back, but there was an article about a vulnerability in certain ARRIS (formerly Motorola) Surfboard cable modems.  The vulnerability here is multi-faceted, so we will break it down.  Meet me after the jump...

Surfboard modems are quite popular cable modems in the United States and elsewhere.  Like many devices, they have web interfaces that allow you to monitor the device and make configuration changes.  These web interfaces are hosted on a private IP:  Since is not routable on the Internet since it is defined in RFC1918, you might think that security for these pages does not really matter.  ARRIS does not seem to think so either.  The web configuration for these modems do not use any sort of authentication.  After all, if the interface for the cable modem is not routable from the Internet, that means that the attacker has to have access to your private network right?  This is true, but only to an extent.

Here is the original article.  It brings up some interesting points, but does not really offer any solutions.  We will see if we can mitigate this vulnerability at all.

Let's take a moment to talk about CSRF.  Cross Site Request Forgery (CSRF) is the act of using the trust that exists between a user and a remote server to access the remote server unbeknownst to the user.  Let's say you are logged into website A.  Website A is a social media site known as MyFace.  MyFace has put a cookie on your box to remember you later (and not to annoy you with those pesky password prompts).  MyFace trusts that the person on your computer is you because you logged in (as evidenced by the cookie MyFace left).  Let's say you then surf to website B.  Website B has been compromised and contains the following bit of HTML:
<img src="http://MyFace/?post-status-message=EvilGuy88%20is%20awesome!">

The %20 strings are translated into spaces (20 is the ASCII value for a space).  When you check your MyFace page later on, you see the message "EvilGuy88 is awesome!" on your message board.  You do not remember writing that, so what happened?

MyFace is configured to accept new status messages through HTTP GET requests (i.e. through the URL).  When your browser was working on rendering the img tag, it sent a request to MyFace with the arguments post-status-message and the message.  The browser presented the cookie that MyFace put on your machine previously and MyFace used that to know it was you and went through with the request.  There are two things to note.  First, as the original article pointed out, you do not have to put links to images in image tags (img).  Browsers will happily attempt to access whatever you put in an image tag and render it because some images are rendered dynamically.  By dynamically, I mean that a web application might render an image based on a number of factors, so when you send your request to a page, it will respond with an image based on those parameters.  Second, HTTP GET requests are not the only type of request that can be used in CSRF.  We will not talk about CSRF and POST in detail, but CSRF can also happen through malicious form submissions.

What we have talked about with CSRF thusfar is enough to understand the issue here.  So let's talk about the actual issue.  The web interface for the modem allows the user to reset the cable modem.  This operation takes a few minutes to complete, and during that time, the modem is not interfacing with the WAN, so the connection to the Internet is cut.  To reset the cable modem, you only have to visit

This could be used to cause a denial of service attack for anyone that owns this kind of modem.  Since the address is the same for every modem, this could affect a lot of people.   This may not be the most serious vulnerability ever, but it is a good example to learn about CSRF and how devices on your local network are indirectly accessible outside of your local network given the right circumstances.

You might visit a compromised web page that contains an image tag with the URL of the modem reset page, and when you visit it, it resets your modem.  Because there is no authentication, the modem will happily let you reset it because it trusts everyone implicitly.

In theory, this could be fixed with a firmware patch.  However, that means that your ISP has to push the patch out.  Some ISPs might do that, some might not.  So can you do anything?

There are a few things you can do:
  1. Most people connect their modem to a router then connect to their router.  If your router supports it, you could add a firewall rule that blocks access to  This is a bit extreme, but if you do not need to access the modem's web interface regularly, this will be fine.  If you do need to access the page for some reason, you can disable the firewall rule temporarily.
  2. If you use Firefox, you can use NoScript to block access to  NoScript's Application Boundaries Enforcer (ABE) can detect if a website is trying to send you to your modem's reset page (because you set up a rule to block and will block the request.
  3. If your router has an option to block RFC1918 addresses on the WAN interface, turn that option on.  Not all routers have this.  I have not seen a consumer router that has this option.
  4. If your router lets you create custom routes, you could create a custom route to route all packets destined for to null (or localhost /  This is not likely to be something a consumer router will allow either.

Conclusions and Final Thoughts

As I mentioned earlier, this is not a vulnerability where you should disconnect your Surfboard modem and throw it out the window.  I wanted to use it as opportunity to talk a bit about CSRF and to maybe spur some discussion.  Thanks for reading!

No comments:

Post a Comment