Exploit that gives remote access affects ~200 million cable modems

Cable Haunt lets attackers take complete control when targets visit booby-trapped sites.

Read the whole story

 

[lewax00]

So if my modem is configured in bridge mode and doesn't HAVE an IP address, then I'm not vulnerable tot his attack?

From https://cablehaunt.com/

"What About Modems in Bridge Mode, or Behind a Firewall?

It is hard to say across all models, if the vulnerable endpoint is available when operating in bridge mode. We have however received several reports from individual users across the world, where the modem was still vulnerable even in bridge mode, so this is definitely not a security guarantee. If your modem is running behind a separate router/gateway, you might be safe by configuring a firewall restriction on the spectrum analyzer. In any case, it is a decent mitigation strategy, while waiting for your ISP to roll out deployments."

Seems a bit like non-answer, they really don't want to say that bridge mode is not vulnerable, although logically it shouldn't be.

I'm wondering if there are cable modems which have a local management interface that is separate from the main WAN ethernet interface. If so, then those might have a local IP and still be vulnerable. I'm not familiar with any cable modems that operate that way but many other types of devices have separate management interfaces, so I think it would be possible.

If I understand what you're saying correctly...yes, they do exist, mine is like that. It has it's own IP address (well, it should anyways...the router doesn't always play nice with the IP it assigned itself, so it only works sometimes), and that IP address gives you access to a webpage with some config and stats for the modem.

 

[j17robotdancer]

All I can say is (comcast,verizon,spectrum, frontier, att, etc) don't give even give a fuck because they know the consumer is too damn stupid to realize what this major fuck this is.

 

[TwoChances]

My Comcast provided modem is in bridge mode but still has an IP address. The article doesn’t provide mitigation steps but wouldn’t it be possible to block egress to the modem IP address at the router? That would prevent machines on the LAN from being able to successfully execute the attack, no?

What am I missing Ars?

 

[milski]

My Comcast provided modem is in bridge mode but still has an IP address. The article doesn’t provide mitigation steps but wouldn’t it be possible to block egress to the modem IP address at the router? That would prevent machines on the LAN from being able to successfully execute the attack, no?

What am I missing Ars?

Yes, that's possible. Your router should not be routing packets sent to a private network to it but you can explicitly block them anyway.

 

[NetMage]

It would be useful to know the port / IP address the exploit attacks for potential mitigation, without blocking useful access to the cable modem.

OTOH, is it possible to re-IP these cable modems as a work around?

 

[cosmotic]

I'm not affected but this is a good reminder I need to check my networking hardware for firmware updates.

While never a bad idea, do keep in mind that cable modem firmware updates only happen through your ISP as far as I know.

It creates a bit of a hairy situation where if you bring your own hardware (vs paying a monthly equipment rental fee) and your ISP doesn't support it, it'll never see a firmware update.

The ISP holds all the keys to the firmware update process so I think it's fair to say it's still the ISP's problem.

 

[cpplindev]

I just created rule that blocks access from LAN to 192.168.100.1 for any protocol and verified that I can no longer get to modem web page from LAN.
If exploit requires request from LAN to ws://192.168.100.1 that should stop it from sending request to cable modem with crafted buffer overflow?

Am I missing something here?

 

[Azethoth666]

Would not having Java installed (or enabled) protect you from this vulnerability?

Java != JavaScript.

I know we're decades into the mess, but it was dumb to make the names of such radically different programming languages so similar. Doubly so since I'm pretty sure it was on purpose.

blame Netscape The browser itself is basically dead, but its legacy lives on in the form of Javascript. (FYI as far as I know, JS was never designed to be secure, but rather the security (such as it is) comes from running in a theoretically secure sandbox). Then again, IS there any mainstream programming language that WAS designed for security?

(edit : corrected incorrect contraction)

So like the RUST language?

 

[orangpelupa]

How about modem/routers from ISP that have un-changeable default password and always-on access from WAN?

In Indonesia, 3 major ISP (1 government-owned) uses modem/router that have un-changeable default password and always-on access from WAN.

the only "workaround" that i found works = buy your own router, then login as ISP (login as root or admin didnt give enough access) into the modem/router, then change the modem/router into "bridge mode" and copy the MAC Address to your own router.

 

[Azethoth666]

So if my modem is configured in bridge mode and doesn't HAVE an IP address, then I'm not vulnerable tot his attack?

Would be good to have some article clarification if possible, but it does sound like the attack depends on a client LAN device being able to directly connect in some way the modem. If so anything that interferes with that would prevent it. Note though that even in bridge mode some modems do still have an IP address (albeit potentially on a different subnet), depending on the model and firmware. If you know yours doesn't then that should be that, but don't assume either.

If the modem suddenly has no ip address in bridge mode, how would you access it to drop it out of bridge mode?

Bridge mode means it extends the dhcp addressing scheme it finds itself in. Not this magical security stuff you suspect it of. If you are looking for the thing without an IP address then that is your Ethernet cable and maybe a PoE injector.

 

[norton_I]

My Comcast provided modem is in bridge mode but still has an IP address. The article doesn’t provide mitigation steps but wouldn’t it be possible to block egress to the modem IP address at the router? That would prevent machines on the LAN from being able to successfully execute the attack, no?

What am I missing Ars?

Yes, that's possible. Your router should not be routing packets sent to a private network to it but you can explicitly block them anyway.

Most if not all edge routers will route "private" addresses just fine. That is exactly what you want as many edge routers use multiple subnets of private address space. Only ISP and backbone routers should be dropping private addresses by default.

My arris surfboard cable modem is in bridge mode and will still respond on the 192.180.100.1 management interface. There is no username or password at all as it doesn't have any writeable configuration accessible -- that is all managed by the ISP per DOCSIS. It sounds like the modems in question work similarly, but have a buffer overflow in the supposedly "read-only" interface.

 

[lohphat]

I thought that cablemodem firmware was under the sole control of the ISP as they push the image and DOCSIS certificate as there's no UI to do so on the user-side UI.

 

[veldrin]

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. While Cabe Haunt accesses modems through a browser, the attack can come from any place where running code can reach an IP on the local network.

Rebinding attacks, ROP, and more

The attack doesn't work when vulnerable targets use Firefox, because the websocket used by that browser isn't compatible with the websocket used by the spectrum analyzer. Attackers can still carry out their remote attack by using JavaScript that carries out what's known as a DNS rebinding attack. To bypass the same origin policy—a restriction that prevents code served from one domain from executing on a different domain—the rebinding attack manipulates DNS tables inside the local network. Because the attack site's domain address is mapped to the IP of the vulnerable modem, the JavaScript will execute the attack code successfully.

Hrm. From the sound of it, the attack won't work if the cable modem is simply not addressable at all from the LAN? I manage the internet for an elderly relative, and they do have cable internet since that's the only thing available there. However, when I set them up I used what at the time was my standard setup: basic cable modem in pure modem mode <> Unifi Security Gateway <> Switch <> WAPs. The USG is the effective edge of the LAN, being a NAT and handling DNS/VLAN L3 routing and all that, and in fact one frustrating long standing irritation (that Ubiquiti at one point said they'd fixed, before the company went to shit) is that there is no standard way to access a modem config page or anything else through the USG without a bunch of manual work, which I never bothered with. Seems like that might be a bullet dodged here though, if the attack requires essentially bouncing off a LAN device to the cable modem than anything that interfered with that would stop it right? Seems like if devices were isolated on VLANs as well. It's too bad consumer networking has never put a better GUI on VLAN usage, isolating different classes of devices on networks is super useful anyway (not even just for security, VoIP and the like tends to be a lot happier without anything else buzzing around its subnet).

Maybe. If packets out from the LAN to 192.168.100.1 are dropped and never reach the modem, the usual attack vectors will be rendered impotent. If the problem is instead that replies are being dropped, the sample code will fail, but it would be relatively straightforward to adapt the payload to work despite the lack of feedback, at the cost of greater complexity in the delivery mechanism, which could make it more easily detectable by the browser.

 

[milski]

So if my modem is configured in bridge mode and doesn't HAVE an IP address, then I'm not vulnerable tot his attack?

Would be good to have some article clarification if possible, but it does sound like the attack depends on a client LAN device being able to directly connect in some way the modem. If so anything that interferes with that would prevent it. Note though that even in bridge mode some modems do still have an IP address (albeit potentially on a different subnet), depending on the model and firmware. If you know yours doesn't then that should be that, but don't assume either.

If the modem suddenly has no ip address in bridge mode, how would you access it to drop it out of bridge mode?

Bridge mode means it extends the dhcp addressing scheme it finds itself in. Not this magical security stuff you suspect it of. If you are looking for the thing without an IP address then that is your Ethernet cable and maybe a PoE injector.

Reset to factory settings. At least that's how the last DSL modem I had use to work in that case.

 

[milski]

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. While Cabe Haunt accesses modems through a browser, the attack can come from any place where running code can reach an IP on the local network.

Rebinding attacks, ROP, and more

The attack doesn't work when vulnerable targets use Firefox, because the websocket used by that browser isn't compatible with the websocket used by the spectrum analyzer. Attackers can still carry out their remote attack by using JavaScript that carries out what's known as a DNS rebinding attack. To bypass the same origin policy—a restriction that prevents code served from one domain from executing on a different domain—the rebinding attack manipulates DNS tables inside the local network. Because the attack site's domain address is mapped to the IP of the vulnerable modem, the JavaScript will execute the attack code successfully.

Hrm. From the sound of it, the attack won't work if the cable modem is simply not addressable at all from the LAN? I manage the internet for an elderly relative, and they do have cable internet since that's the only thing available there. However, when I set them up I used what at the time was my standard setup: basic cable modem in pure modem mode <> Unifi Security Gateway <> Switch <> WAPs. The USG is the effective edge of the LAN, being a NAT and handling DNS/VLAN L3 routing and all that, and in fact one frustrating long standing irritation (that Ubiquiti at one point said they'd fixed, before the company went to shit) is that there is no standard way to access a modem config page or anything else through the USG without a bunch of manual work, which I never bothered with. Seems like that might be a bullet dodged here though, if the attack requires essentially bouncing off a LAN device to the cable modem than anything that interfered with that would stop it right? Seems like if devices were isolated on VLANs as well. It's too bad consumer networking has never put a better GUI on VLAN usage, isolating different classes of devices on networks is super useful anyway (not even just for security, VoIP and the like tends to be a lot happier without anything else buzzing around its subnet).

Maybe. If packets out from the LAN to 192.168.100.1 are dropped and never reach the modem, the usual attack vectors will be rendered impotent. If the problem is instead that replies are being dropped, the sample code will fail, but it would be relatively straightforward to adapt the payload to work despite the lack of feedback, at the cost of greater complexity in the delivery mechanism, which could make it more easily detectable by the browser.

The script is using WebSockets to connect to the modem, so it needs a TCP connection, which in turn needs packets to move both ways to get established. So dropping in either direction should work.

 

[Green RT]

While Cabe Haunt accesses modems through a browser, the attack can come from any place where running code can reach an IP on the local network.

There is an 'l' missing from 'Cabe' in the last sentence before the 'Rebinding attacks, ROP, and more' heading.

 

[veldrin]

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. While Cabe Haunt accesses modems through a browser, the attack can come from any place where running code can reach an IP on the local network.

Rebinding attacks, ROP, and more

The attack doesn't work when vulnerable targets use Firefox, because the websocket used by that browser isn't compatible with the websocket used by the spectrum analyzer. Attackers can still carry out their remote attack by using JavaScript that carries out what's known as a DNS rebinding attack. To bypass the same origin policy—a restriction that prevents code served from one domain from executing on a different domain—the rebinding attack manipulates DNS tables inside the local network. Because the attack site's domain address is mapped to the IP of the vulnerable modem, the JavaScript will execute the attack code successfully.

Hrm. From the sound of it, the attack won't work if the cable modem is simply not addressable at all from the LAN? I manage the internet for an elderly relative, and they do have cable internet since that's the only thing available there. However, when I set them up I used what at the time was my standard setup: basic cable modem in pure modem mode <> Unifi Security Gateway <> Switch <> WAPs. The USG is the effective edge of the LAN, being a NAT and handling DNS/VLAN L3 routing and all that, and in fact one frustrating long standing irritation (that Ubiquiti at one point said they'd fixed, before the company went to shit) is that there is no standard way to access a modem config page or anything else through the USG without a bunch of manual work, which I never bothered with. Seems like that might be a bullet dodged here though, if the attack requires essentially bouncing off a LAN device to the cable modem than anything that interfered with that would stop it right? Seems like if devices were isolated on VLANs as well. It's too bad consumer networking has never put a better GUI on VLAN usage, isolating different classes of devices on networks is super useful anyway (not even just for security, VoIP and the like tends to be a lot happier without anything else buzzing around its subnet).

Maybe. If packets out from the LAN to 192.168.100.1 are dropped and never reach the modem, the usual attack vectors will be rendered impotent. If the problem is instead that replies are being dropped, the sample code will fail, but it would be relatively straightforward to adapt the payload to work despite the lack of feedback, at the cost of greater complexity in the delivery mechanism, which could make it more easily detectable by the browser.

The script is using WebSockets to connect to the modem, so it needs a TCP connection, which in turn needs packets to move both ways to get established. So dropping in either direction should work.

Yes, the sample code is relatively limited. What I'm saying is that it wouldn't be hard for someone with more than beginner level network programming experience to craft a slightly more sophisticated exploit that would work even if replies are filtered. Only by filtering the outbound requests from the LAN can you be sure that exploitation from the LAN is impossible.

These are embedded devices we're talking about here, so the bar for blindly spoofing a TCP handshake is pretty low.

 

[sep332]

Well, shit. I forewent the ISP modem.

If you're using a modem supported by the ISP, they'll generally push firmware updates to it. I know from experience (when they push an update at 2 AM while I'm binge watching some show on Netflix...lol.)

I don't know. It was the Wirecutter's pick at the time, an Arris something-or-other but I doubt I could expect a straight answer from Spectrum about whether my modem is supported.

https://www.spectrum.net/support/intern ... r-network/

Xfinity used to have a searchable list but it's now hidden behind a login page. https://www.xfinity.com/support/devices/#unauth

https://www.cox.com/residential/support ... odems.html

Looks like Optimum used to have a list but they deleted it? This might be out of date. https://web.archive.org/web/20170712034 ... ided-modem

Ditto Suddenlink https://web.archive.org/web/20171023174 ... yList.aspx

https://mediacomcable.com/assets/pdf/le ... 0_2019.pdf

https://www.wowway.com/docs/wow/documen ... y-list.pdf

https://www.rcn.com/hub/help/bring-your-own-modem

https://support.sparklight.com/hc/en-us ... ntial-Only

https://atlanticbb.com/sites/default/fi ... h_2019.pdf

 

[not12listen]

Everything in this article states that 'modems' are impacted. Reading into the detail - the devices that are impacted are either ISP supplied or personally purchased modem/router combo units - not stand alone modems (Motorola MB7220 as example of a stand alone modem).

Most people likely do have modem/router combo units, but this technical detail is important - whether or not stand alone modems VS combo units are impacted.

 

[Maltz]

I have a Netgear which will respond to packets sent to 192.168.100.1 on its LAN interface even when it is in bridge mode. So just bridge mode is not enough, you may need to block traffic to 192.168.100.1 on your router (although it should not be routing 192.168.0.0/16 to it WAN interface anyway).

But every router I've ever seen does. Otherwise, the modem wouldn't be able to intercept the traffic to that address, which I would assume it does even in bridge mode. Otherwise, how could you interact with the modem directly? I've never seen one with a console port.

But yeah, the obvious, trivial workaround to this is to block 192.168.100.1 port 8080, or whatever IP/port your modem uses for that interface. Even if you just block the whole IP, you couldn't see your signal levels either, but you'd be safe.

 

[TwoChances]

For mitigation, blocking via firewall rules didn't appear to work on my ASUS router. It still happily routed to my modem in bridge mode.

The only thing I could get to work was enable and define a static route. That prevents any internal client from being able to access the modem's config page and all pings to the modem return destination unreachable. Switching the static route toggle allows access to the modem config page if needed.

On ASUS routers, it's LAN page, route tab

Network: Modem IP (ex. 192.168.0.1, 10.0.0.1, etc)
Netmask: 255.255.255.255
Gateway: Router LAN IP

 

[kenada]

For mitigation, blocking via firewall rules didn't appear to work on my ASUS router. It still happily routed to my modem in bridge mode.

The only thing I could get to work was enable and define a static route. That prevents any internal client from being able to access the modem's config page and all pings to the modem return destination unreachable. Switching the static route toggle allows access to the modem config page if needed.

On ASUS routers, it's LAN page, route tab

Network: Modem IP (ex. 192.168.0.1, 10.0.0.1, etc)
Netmask: 255.255.255.255
Gateway: Router LAN IP

That’s what I ended up doing on my Orbi, though I routed it to a non-existent IP on my LAN instead (since it wouldn’t let me configure a null route). I also took steps to mitigate DNS rebinding attacks by updating my internal DNS server (Unbound in a container running on a Raspberry Pi) to filter out responses with private and reserved IP addresses.

 

[The Cappy]

I'm not affected but this is a good reminder I need to check my networking hardware for firmware updates.

I have no idea how to update the firmware on my cable modem, which was supplied and configured by my cable provider :-\

 

[VaughnP]

I'm not affected but this is a good reminder I need to check my networking hardware for firmware updates.

I have no idea how to update the firmware on my cable modem, which was supplied and configured by my cable provider :-\

You can't!

Only the ISP can update the firmware.

 

[ferdnyc]

Greaaaat. And since I decided to cheap out and buy my own modem ($40 once vs. $10/month to CableVision), **I'm** the person I have to contact to find out if my modem's vulnerable, and/or if there's a firmware patch.

Hopefully TP-LINK's after-sales support is better than their pricing would seem to imply.

 

[kenada]

Greaaaat. And since I decided to cheap out and buy my own modem ($40 once vs. $10/month to CableVision), **I'm** the person I have to contact to find out if my modem's vulnerable, and/or if there's a firmware patch.

Hopefully TP-LINK's after-sales support is better than their pricing would seem to imply.

You can’t update your modem’s firmware. Only the ISP can do it. If it’s an officially supported modem, they should update it eventually.

 

[cfbcfbcdb]

Well, shit. I forewent the ISP modem.

If you're using a modem supported by the ISP, they'll generally push firmware updates to it. I know from experience (when they push an update at 2 AM while I'm binge watching some show on Netflix...lol.)

I don't know. It was the Wirecutter's pick at the time, an Arris something-or-other but I doubt I could expect a straight answer from Spectrum about whether my modem is supported.

The wirecutter recommendations for cable modems suck, in my opinion. More focused on cost and simplistic methodology for forming their recommendation. Last I checked slightly over a year ago, they were recommending an Arris modem that comcast spent a lot of good money to replace as their ISP rental modem. Comcast isn't going to spend millions replacing a serviceable modem.

Here's where they messed up, but its a common mistake. They made their recommendation by multiplying modem supported up/download channels and saying a lower channel product was fine "because it supports the speed tiers". Nice, but more channels = lower chance of getting congestion induced reduced quality of service. I actually owned their recommended modem...eight years ago. I had variable pings and downloads, depending on the time of day. When busy times (7-8am, when school lets out and netflix time) came around, I was stuck with fewer channels for my modem to receive data on. Moving to a modem that cost a couple of bucks more and more channels solved it.

I often describe it as buying a nice car (what you pay a month for internet) and pushing it to save on gas (saving $20 on a cable modem).

I used to like wirecutter recommendations before they started doing it for money and they "diversified" into areas where they aren't really experts.

Further, I've never seen ANY of these modems mentioned in the article here in the US. Has anyone else?

 

[ferdnyc]

Everything in this article states that 'modems' are impacted. Reading into the detail - the devices that are impacted are either ISP supplied or personally purchased modem/router combo units - not stand alone modems (Motorola MB7220 as example of a stand alone modem).

Is that based on anything concrete, or is it just that the only devices _reported_ vulnerable by the researchers all happen to be combo units? Because, any modem will have a spectrum analyzer, and most modems also listen on 192.168.100.1. I know mine does.

Sure, EXPLOITING a dumb modem may not be as profitable, since I doubt you could bring one into a botnet's fold in any meaningful way. But if the exploit is feasible then I'd still like to button mine up, because somebody will hack them anyway.

 

[LimeFluff]

There's more models listed on cablehaunt.com. Look under "Am I affected" then "Modems confirmed by the community". My own Arris SB8200 is on that list, as are other popular models like the SB6183.

 

[ferdnyc]

Further, I've never seen ANY of these modems mentioned in the article here in the US. Has anyone else?

Other than Netgear, I've never even heard of the MANUFACTURERS / Brands.

 

[phansen]

Further, I've never seen ANY of these modems mentioned in the article here in the US. Has anyone else?

The bug was discovered by Danish researchers. The modems are used by the Danish operator TDC.

 

[not12listen]

Everything in this article states that 'modems' are impacted. Reading into the detail - the devices that are impacted are either ISP supplied or personally purchased modem/router combo units - not stand alone modems (Motorola MB7220 as example of a stand alone modem).

Is that based on anything concrete, or is it just that the only devices _reported_ vulnerable by the researchers all happen to be combo units? Because, any modem will have a spectrum analyzer, and most modems also listen on 192.168.100.1. I know mine does.

Sure, EXPLOITING a dumb modem may not be as profitable, since I doubt you could bring one into a botnet's fold in any meaningful way. But if the exploit is feasible then I'd still like to button mine up, because somebody will hack them anyway.

Spectrum Analyzers are used specifically in wireless communications (I am not saying they are NOT used in other technologies). Each device listed had wireless capabilities (ie. was a combo unit).

Per the article, good thing I only use Firefox.

Agreed that updating the firmware/patching is a good practice - I am absolutely a proponent of that practice!

 

[phansen]

Spectrum Analyzers are used specifically in wireless communications (I am not saying they are NOT used in other technologies). Each device listed had wireless capabilities (ie. was a combo unit).

They are also a part of all modern cable modems. The operator can use it as a tool to track down problems.

 

[alxx]

So basically all the cg3xxx series have been pawned by one exploit or another?

 

[Wolvenmoon]

I'm not affected but this is a good reminder I need to check my networking hardware for firmware updates.

Hey! Guess what I learned yesterday while fighting my ISP tooth and nail for cable modem shenanigans?

Particularly in the U.S., you can't update your cable modem's firmware! Only your ISP can push those updates, and some of them like to avoid updating store-bought modems to try to push customers into rentals.

 

[phansen]

So basically all the cg3xxx series have been pawned by one exploit or another?

Well, not CG3000. That one is too old. No analyzer in that one.

 

[momurda]

Well, shit. I forewent the ISP modem.

If you're using a modem supported by the ISP, they'll generally push firmware updates to it. I know from experience (when they push an update at 2 AM while I'm binge watching some show on Netflix...lol.)

I don't know. It was the Wirecutter's pick at the time, an Arris something-or-other but I doubt I could expect a straight answer from Spectrum about whether my modem is supported.

The wirecutter recommendations for cable modems suck, in my opinion. More focused on cost and simplistic methodology for forming their recommendation. Last I checked slightly over a year ago, they were recommending an Arris modem that comcast spent a lot of good money to replace as their ISP rental modem. Comcast isn't going to spend millions replacing a serviceable modem.

Here's where they messed up, but its a common mistake. They made their recommendation by multiplying modem supported up/download channels and saying a lower channel product was fine "because it supports the speed tiers". Nice, but more channels = lower chance of getting congestion induced reduced quality of service. I actually owned their recommended modem...eight years ago. I had variable pings and downloads, depending on the time of day. When busy times (7-8am, when school lets out and netflix time) came around, I was stuck with fewer channels for my modem to receive data on. Moving to a modem that cost a couple of bucks more and more channels solved it.

I often describe it as buying a nice car (what you pay a month for internet) and pushing it to save on gas (saving $20 on a cable modem).

I used to like wirecutter recommendations before they started doing it for money and they "diversified" into areas where they aren't really experts.

Further, I've never seen ANY of these modems mentioned in the article here in the US. Has anyone else?

Yes, i have the Netgear C3700EMR, i bought it to work with Comcast a few years ago. Its the one in the picture for the article on main page. Hope it is patched soon.

EDIT: Interesting and terrifying, the article mentions these devices use 192.168.100.0/24 for default access. In my case, when i bought this, I changed the internal network to use 192.168.0.0/24, this was years ago. Disalbed everything possible there as long as internet kept working. After reading this i logged in at 192.168.0.1 as expected. I then opened another tab and went to 192.168.100.1 and was presented with the same login page i just logged into on 192.168.0.1. I had no idea this network still existed until now. It is unlisted anywhere in the UI that i have access to. Is it some sort of hidden admin interface that cant be disabled?

edit 2: Angry IP Scan says the only device using .100 is 192.168.100.1, so I think it may be an interface that cant be turned off.

 

[Legatum_of_Kain]

Oh, this is cool. *checks modem notes* Ah, Comcast limits the firmware updates due to network compatibility. Cool, cool, cool, cool.

 

[Ken the Bin]

For mitigation, blocking via firewall rules didn't appear to work on my ASUS router. It still happily routed to my modem in bridge mode.

The only thing I could get to work was enable and define a static route. That prevents any internal client from being able to access the modem's config page and all pings to the modem return destination unreachable. Switching the static route toggle allows access to the modem config page if needed.

On ASUS routers, it's LAN page, route tab

Network: Modem IP (ex. 192.168.0.1, 10.0.0.1, etc)
Netmask: 255.255.255.255
Gateway: Router LAN IP

Thanks for that information.

I had protected this one system by creating a local IP address of 192.168.100.2, ensuring that requests to 192.168.100.1 would not go to my router, but that doesn't cover the other devices on my network.

I have an ASUS router, so I removed the 192.168.100.2 local IP address from this system, verified that access to 192.168.100.1 was restored, then logged into the router, turned on static routes, and created the route as you described (except I created it for the entire 192.168.0.0/255.255.0.0 subnet). It works great.

pings don't work. tracert stops at the router. Attempting to access the modem's web interface from my browser times out.

 

[mikeh3]

Most ISPs in the US are monopolies and thus have no motivation to push a fix for this. IF you have a router that supports outgoing firewall rules, use it to block access to the modem at 192.168.100.1. This protects you from both the modem and your ISP.

http://www.computerworld.com/article/28 ... modem.html