Cable Modem Security
by Fencer (fencer@nudist.org)
Cable modems are becoming increasingly popular among the Internet Connected for a variety of reasons, not the least of which is the availability of a cheap, high-speed, high-bandwidth connection on request. I have observed a resonant social reaction within the computer enthusiast community here in the Boston area with regard to cable modems. It's a tired cliche - but we now have the economic reality of the "haves" and the "have not's" respective of cable modem access.
Some areas of Boston have it, some do not. The concept of luck really doesn't play into it so much as misfortune, an admittedly pessimistic view of the situation. You either live in an area that has it or you don't.
Along with the surge in popularity cable modems bring, a growing "urban myth" is forming as well. It is widely believed that no cable company installer will install the cable modem if they discover you are running Linux (or some other form of UNIX). This is, in part, true insofar as I have been able to determine through reviewing the advertising material available on the websites of the various cable companies. Some of them don't allow UNIX. Some don't really say one way or the other, they simply and arbitrarily list Windows and/or MacOS as a requirement. There are a handful, like Adelphia Cable, which list Linux as an acceptable OS, although it may not in fact be. The reason I say this is that when I had the cable modem installed at my office in Plymouth, the installer reacted very oddly to his discovery of a large Linux partition on the computer he was installing the modem on.
The majority of cable TV companies who offer cable modem Internet access use the MAC verification option as their security and identification model. This is a simple process. It is also one of the oldest, and found its origins in Token Ring networking, though the cable modem networks are not Token Ring.
Basically the cable modem serves as a bridge respective of the MAC address for the Ethernet card in the computer and communication to the node routers. The MAC address is recorded by the central office and is used to identify your system. This is used in place of a login/password process. It saves the cable company time and the hassles of having to help people who forget their password.
Essentially, all Ethernet interfaces are hand entered into a database based upon their MAC address as the controlling feature. This is done in the activation phase of the installation - the installer records the MAC address of your NIC and calls it in to the cable company CO. Part and parcel, this database contains the MAC address along with the account and user information identifying that NIC as belonging to you. Amazingly enough, the MAC address is not paired to the cable modem, introducing some interesting possibilities for abuse - which I will briefly explore later.
The actual login process works along these lines. The cable modem is switched on first. This needs to happen because the modem itself needs to establish its communications with the domain server in order to be able to sync and forward MAC identification and receive DHCP offers. Once the cable modem itself shows a sync light, you can turn on the PC. Under normal circumstances, the cable modem is supposed to be left plugged in and turned on 24/7 so the order in which the connections are made should never be an issue. When the PC is turned on, it makes its UDP announcement to the network which triggers the DHCP process request. The request, under normal circumstances, is answered by the domain server with a DHCP offer. The PC will then record the IP number, config up with it and the appropriate subnet mask, etc., and acknowledge the domain server indicating that it is there.
Periodically the domain server may or may not send out a change of IP in the form of a DHCP offer. This depends on whether a Time To Live (TTL) has been set on the original offering. It has been my experience that the majority of cable companies do use TTLs as a method of discouraging the customer from running HTTP or FTP servers.
This is essentially the cable modem login procedure. Once the IP has been assigned, you are ready to use the Internet through the cable modem. When the IP changes, you will not be informed of it. That is to say, unless you are using an IP watcher (a plethora of these are available from winfiles.com), you will not know that your IP has changed.
It is possible to use dynamic domain names with cable modems (see www.ml.org/ml/dyndns for more information) although this is frowned upon by the provider. All that is left for us is to examine why the cable companies use the MAC address as the security and login control.
Up until recently, the majority of Ethernet cards were non-addressable respective of the MAC address. The NIC essentially performs the functions of the first layer of the OSI model - the physical layer. It performs TR and TX, CRC checks, and monitors collisions in order to request resend. That's pretty much it in a nutshell. The more complex job of filtering, reception via destination address, and packet distribution is handled by the OS.
Since the modern cable modem Internet system used by most cable companies is built around head-end systems, the data is moving in restricted spectrums over the same wire as the rest of the cable content. A modern cable modem takes two "TV channels" and converts them into a 10 Mbps network. One channel is used to send packets from the head-end to subscribers. The other is used to send packets from the subscriber to the head-end. A standard router is used at the head-end, acting as a bridge between the nodes, and a smart router is used to combine all of the individual nodes into the Internet exchange. Thus you have essentially a physically connected Wide Area Network (WAN) operating under the principles of Local Area Networks (LAN) but possibly spanning several hundred miles of cable.
When you factor in the ability of the cable company to limit your use of bandwidth by remote SNMP management of your cable modem, you have a system that is hard to continually abuse. Which means you have to be careful how you behave. Setting up an MP3 site and sucking up a major amount of bandwidth may not cost you your connection, but the cable company might crank down the Quality of Service (QoS) levels on your modem to prevent you from hogging the bandwidth. The answer to this is simple - don't set up the MP3 site using your MAC address.
The MAC address on older NIC's is a hard-coded address in the PROM. On newer cards and most 10bT/100bT selectable cards, the MAC address can be set using the NIC's configuration software. Upon powering up, the MAC address is recording by the domain controller at the CO, and compared to the database table. If it is found in the table, it is then sent a DHCP offer (an IP address), which is also stored in the database with a TTL entry. In addition to providing basic security that does not require a login server, this process also records hosts that are not in the MAC database. This is useful for flagging accounts that are violating the terms of service. The important thing to remember is that the process does not record which cable modem the request passed through at the present time.
Think in terms of misconfiguration. To use more than one computer on the cable modem, you have to either run a Windows 95/NT app like WinGates, or you have to configure your Linux/UNIX box as a firewall/router. If you misconfigured it - an example would be using IP forwarding without quenching at the interface - the MAC addresses of the other NIC's on your network might leak to the CO domain server. It would record this event and the path to the unregistered NIC's and you would discover you no longer had service. The cable companies are serious about this. They view any abuse of their ToS as lost profits.
On the other hand, if you intentionally misconfigured it with someone else's MAC, you are them for all intent and purposes. At least as far as the cable company is concerned. Obtaining the MAC addresses of the other subscribers on your node is not all that hard, but serious care must be taken while doing this. It has long been thought that a network administrator cannot tell when a NIC has been throw into promiscuous mode, in order to sniff traffic. This is simply not true. There are a variety of ways in which to detect that a NIC has been brought up in promiscuous mode. As a matter of fact, this area is so complex that it really deserves its own article, so I am only going to briefly touch upon this now.
You will want to use a commercial sniffer to obtain MAC addresses. There are a variety of them out there. The one common denominator among them all, whether they are Windows 95/NT-based or UNIX-based, is that they throw the NIC into promiscuous mode. Depending upon how much snap your cable company has, this might be what gets you into trouble. A large number of cards based upon the DEC (LANCE) Ethernet model make a UDP announcement when they are brought up in promiscuous mode that is different than the normal one. Some in fact do not broadcast their MAC address when in promiscuous mode. Others send a specific ARP - which certain switches and routers are able to detect. The Cisco 2501 and 4000 series are two that are known to be able to detect this. Subsequently you would need to approach this with discretion.
The easiest way would be to use a dial-up connection to the Internet to sweep (scan) the Class C(s) assigned to your node, and than query these using Netwatcher or an NTScope with ARP/RARP ability. Under UNIX you can interrogate the IP address using a variety of free utilities designed for this purpose, and available from SunSITE. Build your list of MAC addresses from outside their network so that there is no trail leading back to you inside their network. Once you have your list, it's a simple matter of reconfiguring your Ethernet card with the MAC address of a legit user who is not currently logged onto the network.
If you pick a MAC address that is currently in use, or the person logs onto the network while you are configured as them, that could create a problem. At the very least, it will knock you both off the network, and you will have to fight for the IP address assigned by the domain server. At the worst, the domain server recorded this impossible event, and you can count upon their admin wondering how that happened and perhaps investigating it.
There are limitless possibilities for exploration here. It is possible to have both your own and the real system up using the same MAC/IP providing you don't originate any traffic on the same ports as the other guy. That would of course mean that anything he does will be visible to you and vice versa. That in and of itself is an interesting idea for further study. If I were interested in knowing what you were doing, I might want to develop software to facilitate that type of monitoring. And if I were Big Brother, well... you might start thinking that using encrypted clients is a good idea from now on.