Slashdot Mirror
Adelphia's Cable Modems Compromised
texus writes "The Adelphia PowerLink Cable Modem Internet Service Provider, that serves 5.5 million customers nation wide, was found to be vulnerable of a major security flaw that allows cable modem subscribers to spy on each others traffic, as well as the ability to modify other users internet packets in realtime. The severity of a potential attack could allow a malicious subscriber to gain access to the customers private activity on the net, as well as the capabilities to hijack connections, intercept SSL/SSH/VPN encrypted sessions, hijack and poison dns servers, and perform a Denial of Service on the entire subnet. The advisory on BugTraq officially states that it didn't seem like Unix machines that logged onto the network were affected, but reports from other Adelphia subscribers indicate that this was inaccurate and Unix users are vulnerable as well."
took a couple times to load, so just in case the server is flaking out and about to ban /. reffers...
Problem Description:
A certain set of subnets on Adelphia's Powerlink network are treated as a HUB/SWITCH and therefore allow cable modem subscribers promiscuous monitoring of the subnet, and arp poisoning (man in the middle) attacks. Upon finding this flaw, it seems to only affect windows users dhcp requests, as for *nix it hands off an entirely different subnet ip address that is not vulnerable. This doesn't stop one from booting into *nix and manually configuring their ip to be on the vulnerable subnet. To review, with arp poisoning, one can do a tremendous amount of malicious activity on a subnet, from DoS'ing the network, to hijacking DNS servers, and even attacking/cracking SSL/SSH/VPN negotiations. Promiscuous mode, one can passively monitor all traffic on the subnet, obtaining private information, including logins/passwords, and private email.
Vulnerable Subnets:
please contact security@invisiblenet.com for info regarding specific subnets.
Solution:
The solution is varying on how the cable networks topology is handled, and arp poisoning, as we know is not a completely solvable issue without a physical/virtual separation of Layer 3 from Layer 2 in the OSI Model. For promiscuous mode, don't have the network in HUB mode.
ARP poisoning has been around since...well...ARP! Its really easy to do and I'm surprized that it hasnt made more of a storm than it really deserves. Hopefully this story will bring to light the problem a bit more.
There are patches out there for linux that will secure the ARP table, I wrote one but there are better and I dont remember what they are called but search...you will find.
They can sniff the session, but all they will get is meaningless rubbish unless they can decrypt it. This is nearly impossible to do when using 128 bit SSL encryption.
ARP poisoning can allow you to re-route someones traffic. Lets say I re-route your traffic through my machine upon detection of SSH/SSL host key request and give you a host key that I crafted, when you initiate an SSH/SSL connection you are now using a bad host key from my machine and not the real host. I could have the ability to decode that traffic now.
You're assuming that your browser is immune to man in the middle attacks. It may not be.
On any cable network, ARP spoofing is available, not just in this example. It is quite easy for someone to do this.
Depends on the equipment. Some cable routers allow only a limited number of IP address to MAC address mappings per modem and refuse to override an ARP table entry in the cable router with a different IP address once it has been created. Packets that do not have MAC and IP addresses matching the entries for the modem session get dropped.
"I have opinions of my own, strong opinions, but I don't always agree with them." -- George H. W. Bush
Your SSL connections should be safe from MiM attacks, unless your browser is unpatched.
Now, this does not rule out ARP spoofing, but the only really interesting ARP to spoof would be the one for the default gateway on the network. Since the gateway for the network is living on the CMTS and since any ARP request must pass through the CMTS before getting to our spoofer, I would expect the spoofed replies to arrive after the legitimate ones from the CMTS. Additionally, I would not be surprised to find out that the CMTS suppresses attempts to ARP spoof it's addresses ( and if it doesn't now, it will in the near future ).
Now, with 100% less rudeness than smoothwall!
IPCop
Adelphia sucks. I guess in more ways than one now.
;)
Please, don't mod this down as a troll, it isn't, it may be blatant advertisement for a sucks.com web site, but it's not a troll
j
-- There is no sig line, only Zuul.
When I run tcpdump on my household server (acts as the gateway for our LAN), I can see traffic destined for us, and ARP who-has messages from the CMTS. The ARP messages are Ethernet broadcasts that have to be bridged. If users at Adelphia can see all the traffic, and it's a DOCSIS system, something (probably the cable modem configuration file) is really screwed up.
More info as I get it...
SIG: HUP
Well, I can tell you that, before Adelphia bought out my local cable company, Prestige, I NEVER had so much as a single BOOTP packet outside of my own. Now, about 10% of the traffic I see is CONSTANT BOOTP requests from other customers all over the country. It is painfully obvious that Adelphia operates their network in HUB mode, when Prestige operated theirs in SWITCHED mode. You DO know what that means, right?
BOOTP traffic should never leave the private UVR segment; period. In fact NO broadcast traffic of ANY sort should be allowed to leave the private network segment at all.
So, don't give me that "it's an non-issue because it is TCP/IP" crap. It is an architectural issue that YOU guys need to clean up on your own network, otherwise, someone needs to do some network technician house-cleaning (all the way up to the CIO, if necessary) and send some people back to flipping burgers at McDonald's.
While we are on the subject of security, why aren't you guys doing something about all the sequential IP scans that are going on in your network right now? Why isn't someone cleaning up THAT mess. Let's see, according to the firewall, I have 4 different scans going on right now; it has been as high as 12.
That, and I have been having fits with your mail server (and, no, this isn't the first time, either; it happens so often, I just switch over to my own until you guys eventually finish reading your sendmail HOWTO and get it fixed).
I realize that with Adelphia being more or less in bankruptcy right now, customer support is not very high on your list of things to take care of (just like network engineering), but don't come in here and tell us that it is a fundamental problem outside of your control when it is NOT. Get control of your network and stop making excuses.
-SS "Teach the ignorant, care for the dumb, and punish the stupid."
Any decently configured VPN won't just warn the user if the key changes -- it'll out and out refuse to work. Likewise, the server will also be verifying the client's key -- any change and thanks-for-playing but yer out.
For SSH, where folks really *do* ignore the issue, yes, this is a problem. A good VPN? No, absolutely not.
The problem with ettercap is that it allows for a man-in-the middle attack against ssh 1 implemenations. That includes seeing the cleartext data passing through....
Also... many routers/firewalls and access devices that have ssh only have ssh 1 capability.... so there goes that protection.... since ettercap can intercept those... (Yes... the fingerprint presented would not match.... but then how many would know to check the fingerprint?)
--
Time is on my side