So apparently this went around the internet last month, which I totally missed, so I am posting it here for a few reasons:
1) I thought this “vulnerability” was widely known already, but apparently not. The iOS web browser I make has had functionality to block exactly this exploit since at least January of 2015, and it was inspired by a Chromium issue to do the same which was opened in 2014 (but is apparently still not merged and/or off by default).
2) Despite the fact that I purchased my Motorola SB6141 cable modem myself from Amazon years ago, because it’s attached to Comcast’s network, Comcast takes the liberty of remotely upgrading the firmware on my device whenever they want, yet I as the actual owner am not able to upgrade or downgrade the firmware at all through any interface the modem exposes to end users. To side-step this recent security scare, Comcast updated the firmware on every vulnerable SurfBoard cable modem on its network, except their method of fixing this security problem was to just completely disable the remote reboot functionality. Not put the reboot page behind a password or some other mechanism to prevent automated fetching of it, but completely disable/remove the functionality from every user’s modem. Now I can no longer remotely reboot my own cable modem through its web interface, a function it’s had for years since I initially purchased it.
I only found out about this because my OpenBSD router has a weekly cron job to force the retrieval of a new dynamic IP from Comcast, which requires fetching the reboot page on the router, waiting a few seconds, ifconfig re0 lladdr random, and then waiting for the cable modem to come back up to then run dhclient again. (This is required because Comcast will only issue a new dynamic IP if it sees a new MAC address from the CPE, and the cable modem will only talk to the first device it sees, so if you change the MAC address of your router, the cable modem will refuse to talk to it until it’s rebooted.) Since my script kept running each week, it would instead just knock my network offline because the cable modem would never actually reboot despite the fetching of the reset.htm succeeding (since they didn’t actually remove the page from the modem’s web server, it just doesn’t actually trigger an internal reboot), but the router would continue changing its MAC address to something random, and then cease to be able to talk to the modem. So each time this would happen, I’d have to physically unplug the modem to reboot it to get my network back online. It wasn’t until I actually researched the problem today that I learned Comcast changed the firmware on my (and everyone else’s) modem.
In the spirit of “fuck you it’s in my house I can do what I want with it”, I can’t imagine it would be terribly difficult to find or build a networked disconnect to go between the modem and wall outlet. No amount of firmware will keep it running when the power cuts.
It is incredibly disappointing how little of the management functionality of cable modems is exposed to the actual users, though.
So apparently this went around the internet last month, which I totally missed, so I am posting it here for a few reasons:
1) I thought this “vulnerability” was widely known already, but apparently not. The iOS web browser I make has had functionality to block exactly this exploit since at least January of 2015, and it was inspired by a Chromium issue to do the same which was opened in 2014 (but is apparently still not merged and/or off by default).
2) Despite the fact that I purchased my Motorola SB6141 cable modem myself from Amazon years ago, because it’s attached to Comcast’s network, Comcast takes the liberty of remotely upgrading the firmware on my device whenever they want, yet I as the actual owner am not able to upgrade or downgrade the firmware at all through any interface the modem exposes to end users. To side-step this recent security scare, Comcast updated the firmware on every vulnerable SurfBoard cable modem on its network, except their method of fixing this security problem was to just completely disable the remote reboot functionality. Not put the reboot page behind a password or some other mechanism to prevent automated fetching of it, but completely disable/remove the functionality from every user’s modem. Now I can no longer remotely reboot my own cable modem through its web interface, a function it’s had for years since I initially purchased it.
I only found out about this because my OpenBSD router has a weekly cron job to force the retrieval of a new dynamic IP from Comcast, which requires fetching the reboot page on the router, waiting a few seconds,
ifconfig re0 lladdr random, and then waiting for the cable modem to come back up to then rundhclientagain. (This is required because Comcast will only issue a new dynamic IP if it sees a new MAC address from the CPE, and the cable modem will only talk to the first device it sees, so if you change the MAC address of your router, the cable modem will refuse to talk to it until it’s rebooted.) Since my script kept running each week, it would instead just knock my network offline because the cable modem would never actually reboot despite the fetching of thereset.htmsucceeding (since they didn’t actually remove the page from the modem’s web server, it just doesn’t actually trigger an internal reboot), but the router would continue changing its MAC address to something random, and then cease to be able to talk to the modem. So each time this would happen, I’d have to physically unplug the modem to reboot it to get my network back online. It wasn’t until I actually researched the problem today that I learned Comcast changed the firmware on my (and everyone else’s) modem.In the spirit of “fuck you it’s in my house I can do what I want with it”, I can’t imagine it would be terribly difficult to find or build a networked disconnect to go between the modem and wall outlet. No amount of firmware will keep it running when the power cuts.
It is incredibly disappointing how little of the management functionality of cable modems is exposed to the actual users, though.
Why do you do this?
The same reason my browser deletes all of the cookies from websites once I navigate away from them.