LWN: Comments on "Exploit that gives remote access affects ~200 million cable modems (ars technica)"

Exploit that gives remote access affects ~200 million cable modems (ars technica)

dcoles — Mon, 20 Jan 2020 01:53:18 +0000

If you're wondering how this can be exploited, here's a webpage that can reliably crash my ARRIS SB6183 cable modem with one click: http://kria.dcoles.net/cablehaunt/

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)

dcoles — Mon, 20 Jan 2020 01:17:43 +0000

> Probably why security-conscious users change the 3rd octet to something random if they can.

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.

IP aliasing

marcH — Thu, 16 Jan 2020 22:14:15 +0000

> This is often the only way you can connect to the cable modem to configure it.

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).

IP aliasing

klossner — Thu, 16 Jan 2020 20:09:06 +0000

This mechanism swings into action when the cable modem and the router are separate machines. The router probably NATs on 192.168.1.*, so 192.168.100.1 is a remote address. The router forwards the IP packet upstream, just as it would for e.g. 64.233.185.138 (google.com). The cable modem notices that the destination IP address is 192.168.100.1 and captures the packet for itself.

This is often the only way you can connect to the cable modem to configure it.

Exploit that gives remote access affects ~200 million cable modems (ars technica)

excors — Thu, 16 Jan 2020 18:10:55 +0000

6000 was blocked 19 years ago. I believe the thinking is that anyone implementing a network service today really ought to be aware of the existence of web browsers, and aware that an attacker can trivially cause a user's browser to send a partly-attacker-controlled HTTP GET/POST to any address (<img src="http://192.168.0.1:1234/router_admin/disable_firewall.cgi"> etc), even an address that's using a non-HTTP protocol, and therefore an HTTP message received from a trusted user's IP is not inherently trustworthy. There must be some extra authentication, or a protocol header that's intentionally incompatible with HTTP so the browser's request will be rejected. (Old protocols were designed without that awareness, but that's a constant set and can be explicitly blacklisted.)

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.

Exploit that gives remote access affects ~200 million cable modems (ars technica)

flussence — Thu, 16 Jan 2020 17:12:03 +0000

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.

Broadcom33xx SoC

johnjones — Thu, 16 Jan 2020 15:42:04 +0000

this is a Broadcom Firmware vulnerability and the closed source nature of their Firmware means all those gateways are targets

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...

Exploit that gives remote access affects ~200 million cable modems (ars technica)

smurf — Thu, 16 Jan 2020 10:02:48 +0000

> I thought browsers had a network connection blacklist built in for precisely this reason?

Why should it? No browser blacklists RFC1918 addresses.

IP aliasing

marcH — Wed, 15 Jan 2020 20:37:07 +0000

> Perfect configuration for testing, thanks for sharing.
> ...
> PS: I need to perform some testing on my side too...

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.
- I could add the missing firewall rule from OpenWRT's web interface in no time:

/etc/config/firewall diff, tested
+
+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'
+

I performed a before/after iptables -L sanitycheck and it looked as expected.

IP aliasing

rahvin — Wed, 15 Jan 2020 16:00:31 +0000

His case isn't unique. My configuration uses a business grade docsis cable modem with all routing features disabled. It hands a /29 and IIRC a /60 to my firewall. The modem uses 10.0.10.0 for configuration that none of my internal networks use this subnet. The cable modem will respond to requests from off subnet, including on a 192.168 address. I haven't tested this but I think they'll respond to any request on their default IP as long as it originates from the client side. It totally ignores any subnetting issues or configurations. The only way I can prevent this is to drop all packets to from that particular IP on the firewall. I was boggled the first time I typed in the address on the local lan before I'd creating a routing rule and not only did the modem respond the firewall routed it. I've never understood why it was doing that.

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.

Exploit that gives remote access affects ~200 million cable modems (ars technica)

nim-nim — Wed, 15 Jan 2020 11:53:05 +0000

Websocket and WebAssembly are red flags security-wise.

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.

Exploit that gives remote access affects ~200 million cable modems (ars technica)

Kamilion — Tue, 14 Jan 2020 23:05:04 +0000

In the readme for https://github.com/Lyrebirds/cable-haunt-vulnerability-test

"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.

IP aliasing

marcH — Tue, 14 Jan 2020 18:56:37 +0000

> What I mean is: I have the cable modem in bridge mode. The ISP DHCP server gives me a publicly routable IPv4+IPv6 address and gateway with publicly routable address. Yet, I can still connect to 192.168.100.1 and get to the web UI.

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...

Exploit that gives remote access affects ~200 million cable modems (ars technica)

flussence — Tue, 14 Jan 2020 18:35:59 +0000

I thought browsers had a network connection blacklist built in for precisely this reason?

In other news, allowing arbitrary remote code execution by default has been linked to bad things happening.

IP aliasing

dezgeg — Tue, 14 Jan 2020 18:00:15 +0000

What I mean is: I have the cable modem in bridge mode. The ISP DHCP server gives me a publicly routable IPv4+IPv6 address and gateway with publicly routable address. Yet, I can still connect to 192.168.100.1 and get to the web UI.

I don't know what happens if you enable NAT on the modem and connect a machine with that 192.168.100.1 address.

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.

Exploit that gives remote access affects ~200 million cable modems (ars technica)

Lennie — Tue, 14 Jan 2020 17:37:25 +0000

Did I read the article correctly ? The devices have an open websocket port so browser can connect to it. Well, isn't that 'smart'.

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
start up or something like that.

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.

Exploit that gives remote access affects ~200 million cable modems (ars technica)

hmh — Tue, 14 Jan 2020 17:36:23 +0000

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.

Setting the CPE to bridge mode, adding an openwrt-based router to the front of that CPE, and firewalling off the CPE's administrative IP addresses (which will be still active and answering to traffic even in bridge mode) is a very good idea. Just do it. And don't you dare forget that the CPE might answer on several IPv6 addresses too, those also need to be blocked somehow.

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.

Not to mention some of the LuCI extensions to OpenWRT do not require the user to be logged in to provide service, and that can also be a concern.

Exploit that gives remote access affects ~200 million cable modems (ars technica)

farnz — Tue, 14 Jan 2020 17:21:49 +0000

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.

Exploit that gives remote access affects ~200 million cable modems (ars technica)

Lennie — Tue, 14 Jan 2020 17:08:22 +0000

From what I heard, some Windows malware actually install a patch so other malware can't take over the machine. ;-)

IP aliasing

marcH — Tue, 14 Jan 2020 16:29:09 +0000

> Most cable modems have a feature where any outgoing traffic to 192.168.100.1 is always intercepted and replaced by the web UI

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 :-/

Exploit that gives remote access affects ~200 million cable modems (ars technica)

dezgeg — Tue, 14 Jan 2020 15:50:08 +0000

Most cable modems have a feature where any outgoing traffic to 192.168.100.1 is always intercepted and replaced by the web UI

Exploit that gives remote access affects ~200 million cable modems (ars technica)

Cyberax — Tue, 14 Jan 2020 15:45:18 +0000

There are no cable modems with OpenWRT, but you can buy a CableCard which is basically a cable modem on a PCI card and use it with your hardware.

I would recommend putting the cable modem into bridge mode and setting your router in front of it.

Exploit that gives remote access affects ~200 million cable modems (ars technica)

leromarinvit — Tue, 14 Jan 2020 15:43:21 +0000

Maybe this exploit can help you install OpenWRT on your cable modem! :-)

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.

Exploit that gives remote access affects ~200 million cable modems (ars technica)

Wol — Tue, 14 Jan 2020 15:40:26 +0000

> Another, unrelated question: does the vulnerability require the home subnet to include the cable's modem IP address? (192.168.100.1 apparently?)

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,
Wol

Exploit that gives remote access affects ~200 million cable modems (ars technica)

marcH — Tue, 14 Jan 2020 15:15:15 +0000

Does OpenWRT support any cable modem? Does any alternative firmware (officially) support any cable modem? I thought cable modems were all locked down.

Another, unrelated question: does the vulnerability require the home subnet to include the cable's modem IP address? (192.168.100.1 apparently?)