Hacker News Reader

Comment by mannyv | Hacker News Reader

An open question is still: how were the attackers able to grab his HTTP traffic?

Some CPEs have a cloud Wireshark-like capability for debugging. I'm not sure if those are even on the Cox production firmware images. Usually there's a set of firmware for production and a set for test (which obviously makes it hard to test for problems in production).

I suppose Cox could do a check to see what firmware versions are out there. ISPs can auto-upgrade firmware that doesn't match a specific firmware revision, and this was a Cox modem so they probably have firmware for it. So if it was a debug firmware how did it get there and survive?

View on HN

If you create a socket with PF_PACKET you can intercept all the traffic on a Linux system on all interfaces. Think of a low-tech version of tcpdump.

Intercept all data on port 80, parse the http headers, do whatever you need with them, easy.

Not sure why anybody would replay the requests though.

Its HTTP not HTTPS, anyone or anything on the wire could see the request

That's the part I didn't get. The author said there was no other possibility except the modem, but why? It seems like quite a leap. I would have first suspected a compromised router on the internet. Is it possible that changing the modem caused new routes to be used which appeared to fix the problem?

Of all the routers along the route, the one most likely to be compromised is obviously the piece of plastic guano your ISP forces you to use

also, yet another reason I don't trust (and don't use) any ISP provided equipment. Remote administration from my ISP? No thank you.

Even if you buy your own modem they can push firmware to it (and do). The config file your modem downloads includes a cert that allows the isp to do this. You can flash special firmware (used to be called force ware) to prohibit this.

Is it safe enough to buy a separate router and put the ISP modem on the "internet" side of it?

I think the attack described in the article is still possible in this setting, where the modem is in the middle of your unencrypted http traffic. This is true of any equipment belonging to the isp

However, I would assume no unencrypted traffic is safe anyway, and the modem would indeed not have access to your internal network.

It depends. The tr069 managed devices are typically router wifi combo type devices. If you can get a dumb modem that would would likely remove any tr069 vulnerabilities.

The firmware on whatever is doing docsis is going to be updatable by the ISP generally.

Two different mechanisms. The tr069 management and snmp triggered firmware upgrade

You're assuming DOCSIS. I'm on FTTP, where the demarcation point is a cat5 cable to my equipment. Granted, there could be chicanery on the optical terminal, but that still doesn't provide my ISP visibility into my internal network.

How about putting the ISP supplied modem in a DMZ? Then the ISP could admin it all they want but still never touch the LAN.

So open it up to anyone? DMZ is an open target, not what you want to be doing.

It’s more about protecting your network against a potentially malicious device rather than protecting the device from attackers on the Internet. From that position, placing the isp device on a “DMZ” aka outside your own router/firewall, makes perfect sense.

That's pretty much the way to go. Keep the ISP modem, but connect it to your own router/firewall and connect your devices to your hardware and not the ISP modem.

I get the perspective, but I also like the fact that ISPs do take over some of the admin burden associated with running a piece of equipment like a router.

You, I and most of the HN crowd may be well capable of maintaining a reasonably secure state of our own hardware and troubleshoot our way through common errors. However, the average internet user isn’t that experienced nor are most people interested in learning those skills.

I have a feeling the OP ... has the skills to manage his router :)

but point well taken in general.

Reply on news.ycombinator.com