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

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.

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

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.