Exploit that gives remote access affects ~200 million cable modems (ars technica) [LWN.net]

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

Posted Jan 14, 2020 15:40 UTC (Tue) by Wol (subscriber, #4433) [Link] (2 responses)

> 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

Broadcom33xx SoC

Posted Jan 16, 2020 15:42 UTC (Thu) by johnjones (guest, #5462) [Link]

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)

Posted Jan 20, 2020 1:17 UTC (Mon) by dcoles (subscriber, #80488) [Link]

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

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

Posted Jan 14, 2020 15:43 UTC (Tue) by leromarinvit (subscriber, #56850) [Link] (1 responses)

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)

Posted Jan 14, 2020 17:08 UTC (Tue) by Lennie (subscriber, #49641) [Link]

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

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

Posted Jan 14, 2020 15:45 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

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)

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.

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

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.

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)

Posted Jan 14, 2020 15:50 UTC (Tue) by dezgeg (subscriber, #92243) [Link] (7 responses)

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

IP aliasing

Posted Jan 14, 2020 16:29 UTC (Tue) by marcH (subscriber, #57642) [Link] (6 responses)

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

IP aliasing

Posted Jan 14, 2020 18:00 UTC (Tue) by dezgeg (subscriber, #92243) [Link] (5 responses)

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.

IP aliasing

Posted Jan 14, 2020 18:56 UTC (Tue) by marcH (subscriber, #57642) [Link] (4 responses)

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

IP aliasing

Posted Jan 15, 2020 16:00 UTC (Wed) by rahvin (guest, #16953) [Link]

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.

IP aliasing

Posted Jan 15, 2020 20:37 UTC (Wed) by marcH (subscriber, #57642) [Link]

> 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

Posted Jan 16, 2020 20:09 UTC (Thu) by klossner (subscriber, #30046) [Link] (1 responses)

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.

IP aliasing

Posted Jan 16, 2020 22:14 UTC (Thu) by marcH (subscriber, #57642) [Link]

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