Exploit that gives remote access affects ~200 million cable modems (ars technica)
The first and most straightforward way is to serve malicious JavaScript that causes the browser to connect to the modem. Normally, a mechanism called cross-origin resource sharing prevents a Web application from one origin (such as malicious.example.com) from working on a different origin (such as 192.168.100.1, the address used by most or all of the vulnerable modems). Websockets, however, aren't protected by CORS, as the mechanism is usually called. As a result, the modems will accept the remote JavaScript, thereby allowing attackers to reach the endpoint and serve it code." Thus far, there doesn't seem to be any information out there on whether routers running OpenWrt are vulnerable.
Posted Jan 14, 2020 15:15 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (16 responses)
Another, unrelated question: does the vulnerability require the home subnet to include the cable's modem IP address? (192.168.100.1 apparently?)
Posted Jan 14, 2020 15:40 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (2 responses)
That's an RFC1918 address, used all the time for NAT'ing, so yes that appears to be the address the modem uses to talk to the home subnet!
Different modems/routers may play with the 3rd octet - it's often 0 or 1, and play with the 4th octet - it's usually 1 or 254, but you can pretty much guarantee on finding your modem or router at that address from your local device. Probably why security-conscious users change the 3rd octet to something random if they can.
Cheers,
Posted Jan 16, 2020 15:42 UTC (Thu)
by johnjones (guest, #5462)
[Link]
the ISP normally will be responsible for supplying the Modem and if you are unable to patch it under EU law they might well be liable for damages...
Posted Jan 20, 2020 1:17 UTC (Mon)
by dcoles (subscriber, #80488)
[Link]
Somewhat surprisingly, it's actually the people who use the *same* prefix (i.e. 192.168.100.x) that are "safe" with this particular exploit.
To understand why, look at how a typical NAT router + cable modem are set up:
[Computer] -- [NAT Router] -- [Cable Modem] -- [Internet]
Your Cable Modem bridges traffic between your ISP ("The Internet") and your NAT Router, so typically is completely transparent at the IP layer. However it still controls all traffic in/out of your network.
When you try and connect to 192.168.100.1 (and not using 192.168.100.x for your LAN), your computer sends traffic to the default route (the NAT Router, e.g. 192.168.1.1) because it knows this address isn't reachable on the local subnet. Your NAT router will dutifully forward this packet towards it's default route (your ISP) where it is intercepted and handled by the Cable Modem.
Your NAT router rewrites the source address of the packet (e.g. 192.168.1.10), but leaves destination addresses untouched (even if they're RFC 1918 "private" addresses). This is totally legal to do (and many ISPs that use "carrier grade NAT" rely on this), so long as these addresses don't leak out onto the wider "public Internet".
So what happens if your LAN *does* use the same prefix as 192.168.100.1?
Well, in this case your computer thinks that the address should be reachable on the local subnet, thus will never send these packets to the NAT router, thus making the Cable Modem's address unreachable and preventing you from being vulnerable to this exploit.
Posted Jan 14, 2020 15:43 UTC (Tue)
by leromarinvit (subscriber, #56850)
[Link] (1 responses)
I don't know any specifics, so I guess if 192.168.100.1 is the default internal address, the attacker would need to know yours if you changed it. But if that's an external interface's address, e.g. something used by the ISP, then I suppose it depends on the modem's host model if it accepts packets to that address from an internal interface.
In the latter case, I guess you could protect yourself by either using the 192.168.100.0/24 range for your LAN or just setting a dummy route for it, as the packet shouldn't go to the default gateway in that case.
Posted Jan 14, 2020 17:08 UTC (Tue)
by Lennie (subscriber, #49641)
[Link]
Posted Jan 14, 2020 15:45 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
I would recommend putting the cable modem into bridge mode and setting your router in front of it.
Posted Jan 14, 2020 17:21 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
AFAICT, a CableCard is a way to access scrambled TV programming on a cable network, assuming you have a cable receiver already. I can't find any PCI or PCIe cards that support DOCSIS 3.0 or 3.1, implying that there's no card that lets you directly receive cable Internet service.
Posted Jan 14, 2020 17:36 UTC (Tue)
by hmh (subscriber, #3838)
[Link]
It is your bog standard "man-in-the-browser attack vector to the subnet gateway", being used to deliver an attack (specific to the firmware on those cable modems, likely something from a chipset vendor SDK) to escalate privileges using an vulnerable service in those cable modems that is left wide-open to the LAN. Man-in-the-browser as an attack vector is so common, it is not funny: it is an expected misuse case. That setup will protect the cable modem from man-in-the-browser attacks from the LAN side. Hopefully, the CPE does not have a shadow partition to allow the ISP to deploy "City-wide WiFi hotspot coverage", or the CPE vendor DID actually partition it so well it doesn't expose anything. Note that OpenWRT is not safe out-of-the-box to man-in-the-browser either. It comes without a password with full access from the LAN wired ports. You must set a strong administration password if you don't want to get p0wn3d through a man-in-the-browser trivial no-password-or-common-password attack.
Posted Jan 14, 2020 15:50 UTC (Tue)
by dezgeg (subscriber, #92243)
[Link] (7 responses)
Posted Jan 14, 2020 16:29 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (6 responses)
Even if the destination MAC address doesn't match?
Like a number of other LWN readers I guess, I have bought, installed and configured my own router. Like everyone else, only my operator can upgrade the firmware on my (dumb) cable modem. I never tried to connect to my modem and the chances its IP internal address matches my subnet are very low.
So I suspect exploiting this vulnerability in this case would require _another_ vulnerability to somehow configure IP aliasing from the web browser under attack...?
The vulnerability FAQ mentions something about routers and firewalls but it's surprisingly vague. Right, I should read the detailed vulnerability description :-/
Posted Jan 14, 2020 18:00 UTC (Tue)
by dezgeg (subscriber, #92243)
[Link] (5 responses)
I don't know what happens if you enable NAT on the modem and connect a machine with that 192.168.100.1 address.
Posted Jan 14, 2020 18:56 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (4 responses)
Perfect configuration for testing, thanks for sharing.
In this case packets to 192.168.100.1 should be targeted at the MAC of your "far" ISP router (default route), not to the MAC of the modem itself [*]. Can you run "arp -a" or wireshark on the system with the web browser to confirm? 192.168.100.1 should be missing from arp -a even after you just connected to it.
If confirmed missing then: yes, this modem catches packets to its IP address even when they don't have its MAC. As often, convenience decreases security.
[*] ISP router which should immediately discard them cause private subnet.
PS: I need to perform some testing on my side too...
Posted Jan 15, 2020 16:00 UTC (Wed)
by rahvin (guest, #16953)
[Link]
However they are doing it, I suspect it's done like this so they field less calls about why someone's cable modem won't respond when they type in the default address even if their network config is completely different.
Posted Jan 15, 2020 20:37 UTC (Wed)
by marcH (subscriber, #57642)
[Link]
How naive I was to think the default OpenWRT firewall rules would not forward private addresses to the WAN interface...
http://192.168.100.1 and ta-da: the most dumb-looking modem I bought isn't that dumb after all! Of course it has a web interface without any password. Of course it doesn't care what the destination MAC address is. Of course Linux doesn't care about the unexpected MAC address in the reply.
Firewall configuration: never before has so much work and complexity produced so much false sense of security[*]. Instead of simply locking the (network) doors and get some "defense in depth", leave them all open. Instead, sign a very complicated contract with an external, unreliable and SPOF security company.
To be fair that modem's interface seems read-only. Except when it's vulnerable and not.
[*] Wait, I forgot SELinux...
> I suspect it's done like this so they field less calls about why someone's cable modem won't respond when they type in the default address even if their network config is completely different.
Yes of course! Fewer field calls: more profit. Less security: who cares?
Now two somewhat better news:
- While this modem (SB6121) is at least 8 years old, the Firmware Build Time is much more recent: Apr 22 2019 (SB_KOMODO-1.0.7.3-SCM02-NOSH / 1.0.12.18m3). There is some hope.
/etc/config/firewall diff, tested
I performed a before/after iptables -L sanitycheck and it looked as expected.
Posted Jan 16, 2020 20:09 UTC (Thu)
by klossner (subscriber, #30046)
[Link] (1 responses)
This is often the only way you can connect to the cable modem to configure it.
Posted Jan 16, 2020 22:14 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
According to its web interface, this SB6121 has a built in DHCP server that interestingly runs only when cable link is down (then the ISP takes over).
Posted Jan 14, 2020 17:37 UTC (Tue)
by Lennie (subscriber, #49641)
[Link] (1 responses)
The idea of the websocket protocol being allowed outside of the normal cross-origin policy is because it's designed to not be compatible with normal text-based protocols, etc. (it has extra padding) so even if you could connect to something in the LAN it can't talk the protocols needed to get a proper client/server conversation going.
But in this case the device has a websocket protocol without the proper checking and has a buffer overflow.
My guess is OpenWRT has nothing running with a websocket port.
Not sure why, but the article says an other attack(s) is possible, but the exploit website talks just about the websocket one.
If it's the case it would mean the vendor really didn't do their job properly.
Because DNS rebind-attacks have been known for probably more than a decade now* and the industry knows what to do to prevent them from working (at the DNS level, which it can easily do if this device also handles DNS requests and the device level).
* it has existed for decades longer but it was so long people had forgotten it exists and thus wasn't as widely know
Default passwords ? Really is that still a thing ? I thought devices these days had a password on a sticker or demand a new password at
Username and password style HTTP-authentication has been known to be an issue for at least a decade. This is why you create a form on the page and demand at the very least a POST request, preferably one with CSRF token.
So if this is really the case I count at least 4 big mistakes not directly related to the websocket buffer overflow.
Posted Jan 15, 2020 11:53 UTC (Wed)
by nim-nim (subscriber, #34454)
[Link]
What made the Web safe (sort of) is very constrained introspectable norms and protocols.
Those two things are anything except that. They just relay blindly all the one-of-a-kind dangerous unconstrained things Web tech replaced for security reasons. They were invented by people who didn’t want to make their stuff safe by adhering to constraining rules.
Posted Jan 14, 2020 18:35 UTC (Tue)
by flussence (guest, #85566)
[Link] (3 responses)
In other news, allowing arbitrary remote code execution by default has been linked to bad things happening.
Posted Jan 16, 2020 10:02 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (2 responses)
Why should it? No browser blacklists RFC1918 addresses.
Posted Jan 16, 2020 17:12 UTC (Thu)
by flussence (guest, #85566)
[Link] (1 responses)
Browsers have no qualms about blocking TCP ports perpetually (try http://localhost:6000/ for an instant error message), something as sketchy as cross-site connections that jump address scope boundaries should be subject to at least that level of scrutiny. Or, we can just do nothing and have this kind of thing repeat every six months forever.
Posted Jan 16, 2020 18:10 UTC (Thu)
by excors (subscriber, #95769)
[Link]
That's why CORS has the weird shape that it does: certain cross-origin requests are permitted in browsers, because they've been possible for decades and everyone implementing an HTTP service or designing a non-HTTP protocol should have been aware of that (and, largely, have been). Also, blocking those requests now would cause compatibility problems in legitimate use cases. But CORS tries to lock down everything that wasn't previously possible, e.g. you can send a GET/POST and display the response as an image or an iframe, but you can't read the response into JavaScript (unless the response includes CORS headers to explicitly say it's okay to read), because reading the response is a newer capability (with cross-origin XMLHttpRequest) that services might reasonably have not anticipated. If a previously-secure service becomes vulnerable because of new features in a web browser, that would be the web browser's fault, so the browsers try hard to avoid that.
WebSockets aren't protected by CORS, because to any non-WebSockets protocol it looks just like an HTTP GET request (which is already permitted with no CORS restrictions), so there are no legacy services that need protecting from unanticipated messages. Any WebSockets service is responsible for its own security against unauthorised WebSockets connections, and the security rules have been obvious and constant since WebSockets was introduced, so it's not the browser's fault if the service has vulnerabilities.
Posted Jan 14, 2020 23:05 UTC (Tue)
by Kamilion (subscriber, #42576)
[Link]
"The script automatically scans your network to find the spectrum analyzer and tries to establish a connection to the WebSocket."
"jsonrpc":"2.0","method":"Frontend::GetFrontendSpectrumData","params": [..snip]
Seriously doubt OpenWRT has anything to do with this -- appears to be a stupidity in the actual "Modem" section's spectrum analyser, not anything in the Routing section.
Posted Jan 20, 2020 1:53 UTC (Mon)
by dcoles (subscriber, #80488)
[Link]
I have the attack behind a push-button, but absolutely nothing stops the same attack being launched as soon as a malicious page is opened.
Exploit that gives remote access affects ~200 million cable modems (ars technica)
Exploit that gives remote access affects ~200 million cable modems (ars technica)
Wol
Broadcom33xx SoC
Exploit that gives remote access affects ~200 million cable modems (ars technica)
Exploit that gives remote access affects ~200 million cable modems (ars technica)
Exploit that gives remote access affects ~200 million cable modems (ars technica)
Exploit that gives remote access affects ~200 million cable modems (ars technica)
Exploit that gives remote access affects ~200 million cable modems (ars technica)
Exploit that gives remote access affects ~200 million cable modems (ars technica)
Exploit that gives remote access affects ~200 million cable modems (ars technica)
IP aliasing
IP aliasing
Of course if you have your own router in-between that uses 192.168.x.y space as LAN and doesn't pass those packets to the modem you should be safe.
IP aliasing
IP aliasing
IP aliasing
> ...
> PS: I need to perform some testing on my side too...
- I could add the missing firewall rule from OpenWRT's web interface in no time:
+
+config rule
+ option enabled '1'
+ option src 'lan'
+ option name 'reject private'
+ option proto 'all'
+ option target 'REJECT'
+ option dest 'wan'
+ option dest_ip '192.168.0.0/16'
+
IP aliasing
IP aliasing
Exploit that gives remote access affects ~200 million cable modems (ars technica)
start up or something like that.
Exploit that gives remote access affects ~200 million cable modems (ars technica)
Exploit that gives remote access affects ~200 million cable modems (ars technica)
Exploit that gives remote access affects ~200 million cable modems (ars technica)
Exploit that gives remote access affects ~200 million cable modems (ars technica)
Exploit that gives remote access affects ~200 million cable modems (ars technica)
Exploit that gives remote access affects ~200 million cable modems (ars technica)
Exploit that gives remote access affects ~200 million cable modems (ars technica)