Friday, April 1, 2016

ARRIS (Motorola) SURFboard modem unauthenticated reboot flaw

The world's most popular cable modem can be rebooted with no authentication required.
"Wipeout" by Dan Davison, used under license CC BY 2.0

Update April 8: Tom's Guide and The Wire Cutter both report having received a statement from ARRIS that they have updated the SB6141 firmware and are in the process of making it available to service providers. As cable modems are not consumer-updateable, it is up to Internet Service Providers to deliver the update to modems. 

Update April 10: The original post was based on first-hand testing with the SURFboard 6141 modem. It turns out the same flaw existed in the older SURFboard 5100 model at least as early as 2008. Multiple individuals have also contacted me both publicly and privately to confirm the same flaw exists in the popular but dated 6121 model. In addition, Michael Horowitz wrote for Computerworld about this very issue in February 2015, and described blocking LAN access to the cable modem using router settings. If you do not use a router model that Michael demonstrates, the iptables rules at the end of the original post below will work on any Linux-based router that allows command line access.

Update April 11: ARRIS published a note stating that contrary to their box markings and SURFboard 6141 product page claims, 135 million referred to the total number of all SURFboard modems in production, not the number of SB6141 units. A subset of this number are affected by this flaw.

Update March 30, 2017: Most ISPs have now pushed an updated firmware that eliminates the reboot and reset features (but doesn't actually secure the UI). I left the proof of concept online for a year but have now taken it down.

Original post:

Want to annoy some friends? Ask them to visit this website:
Actually, don't ask them to do that until explaining that it is a proof of concept example that may in fact interrupt their Internet connection.

ARRIS (formerly Motorola) SURFboard modems are highly popular broadband cable modems with a reputation for reliability. The SB6141 model in particular can be found for around $70 US, is capable of supporting well over 150 megabit speeds, and works with all the major US Internet providers. According to ARRIS' documentation, the SB6141 is the world's most popular cable modem with over 135 million in production. [See April 11 update above for a disclaimer about the number of units affected.]

Rebooting one remotely is so easy, it doesn't even require a password.

Certain SURFboard modems have an unauthenticated cross site request forgery flaw. The modems have a static IP address that is not consumer-changeable, and the web UI does not require authentication - no username or password is required to access the administration web interface.

Problem 1: no authentication

From the local network, simply browse to and one can access diagnostic data, no login required.

The Motorola/ARRIS SURFboard 6141 cable modem administration interface

Note that the screen shots here are from a SURFboard 6141 model running firmware version SB_KOMODO-, the current firmware deployed to all such modems connected to Time Warner Cable's network. The same may or may not be true of other models; some newer models that combine a wireless router and cable modem do in fact have a password-protected administration UI.

Diagnostic data is one thing ... but the web UI also includes a function to reboot the modem.

With access to a local network, it is a trivial matter to reboot the modem serving that network, causing a denial of service while the modem reboots. Granted the modem only takes about 3 minutes to reboot, but for those three minutes, Internet access is offline. Additionally, activity sensitive to network outages (long downloads or remote desktop sessions, for example) may abort.
This might be annoying, but if someone has access to the local network, there is a good chance they have physical access to just unplug the router, so this in itself is good for little more than an April Fool's Day prank. Ah, but there's more.

The same web UI provides a method to factory reset the modem, after which it will renegotiate with the ISP. This can take as long as a half hour - and in certain cases may even require calling the ISP to initiate reactivation.
Social engineering someone into clicking a link is one thing, but there is a second flaw that makes things a bit more interesting.

Problem 2: Cross Site Request Forgery

OWASP defines cross site request forgery, or CSRF, as "an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated." It involves finding a user that is already authenticated to an application (a moot point in this case, since there is no authentication), and causing them to execute an action they did not intend to execute. 

In this case, the intended design is for a user to access the SURFboard administration interface, and then click a link to execute a reboot. The application though does not verify that the command was issued from the administration UI. When an application does not verify that a command was issued from within the application, the possibility of CSRF exists.

Did you know that a web browser doesn't really care whether an "image" file is really an image? Causing a modem to reboot is as simple as including an "image" in any other webpage you might happen to open - which is exactly the approach taken on the proof of concept:

<img src="">

Of course it's not a real image, but the web browser doesn't know that until it requests the file from the modem IP address - which of course causes the modem to reboot. Imagine creating an advertisement with that line of code, and submitting it to a widely-used ad network...

In both cases, the simplest solution would be a firmware update such that the web UI requires a username and password before allowing disruptive actions such as rebooting or resetting the modem, and that validates that a request originated from the application and not from an external source.

Alas, it is not that simple. Even if ARRIS (which purchased Motorola's broadband modem business in 2014) releases a fix, cable modems are not consumer-upgradable. Even for consumer-owned devices, firmware and configuration for these modems is applied by the ISP.

What do you need to do?

For starters, don't click on unexpected or untrusted links.

The ideal solution is for the manufacturer to issue a firmware opdate that fixes these issues, and then for each Cable Broadband provider to in turn push the update to their respective customers. Until then, those familiar with iptables could add a rule to their wireless router that limits access to the cable modem's LAN interface to a single local IP address - and not browse the web from that address:

iptables -I FORWARD -d -j DROP
iptables -I FORWARD -s x.x.x.x -d -j ACCEPT

Timeline and Caveats

This has been demonstrated on a SURFboard 6141 modem on Time Warner Cable's network. Other models and other ISPs may or may not have the same design. 

The specific issues described here apply to the LAN (internal) interface, not the WAN (external or service-provider) interface.

> January 14, 2016: I sent a report to ARRIS ([email protected]).

January 14: reported flaw to ARRIS

> January 15, 2016: The company's Director of Information Security was quick to reply with a note that my report had been forwarded to the SURFboard Security team.

January 15: ARRIS acknowledged receipt of the vulnerability report.

> January 17, 2016: I contacted MITRE to request a CVE ID

January 17: Request to MITRE for a CVE assignment

> January 25: I emailed my contact at ARRIS again asking if this was something they had already addressed (in which case it was the ISP's problem to solve) or if it was still the case as of the latest firmware. This time, I did not receive a reply.

January 25: Follow-up to ARRIS asking for an update.

> March 17: I contacted MITRE again to request a CVE ID. This time, I got a reply stating that this product is not in scope for CVE. For reference, MITRE documents products currently in-scope for CVE assignment at

March 17: Follow-up request to MITRE for a CVE assignment

> March 18, 2016: I replied to MITRE to explain the breadth of this vulnerability.

March 18: Follow-up to MITRE explaining that this product has 135 million units in production.

>March 21: MITRE replied that this product is being added to the list of potential products for future inclusion, and will be reviewed by the CVE Editorial Board at a future date.

March 21: Reply from MITRE indicating that this product will be considered for future inclusion in CVE scope.

> April 1, 2016: Public disclosure

Do you have something to add? A question you'd like answered? Think I'm out of my mind? Join the conversation below, reach out by email at david (at), or hit me up on Twitter at @dnlongen