As long as there are services, there will be service thieves
As long as there are services, there will be service thieves. Preventing this theft may take some configuration changes in software, firmware upgrades and the removal of problematic cable modems, as well as adjustments to CMTS settings.
Combating service theft has been a series of moves and countermoves, not unlike a game of chess. The disadvantage being not all people on the “good” side were interested in playing, or that the game even existed. The advantage being the “good” side can see the entire board if they choose to and control when the pieces are moved.
A review of the background of theft and cloning starts with config theft, which can be done with or without cloning. Config theft involves the direct stealing of service or artificially upgrading your service to a faster tier. Cloning can involve both impersonating/cloning and stealing another higher tier of service. The distinctions can be confusing, so let’s take a closer look.
What is a clone?
Starting with the basics, DOCSIS at its most fundamental level revolves around the cable modem’s MAC address. These are the magic 48-bit hexadecimal addresses that are supposed to be unique to every device ever made. With 48-bit addressing, there are 281 quadrillion unique addresses, so duplicates shouldn’t really happen.
Cloning, as you might expect, starts by having two devices violate that rule by having the same MAC address. When two devices have the same MAC address, they ultimately look like the same device.
A similar problem exists in Ethernet networking with ARP (address resolution protocol). The headaches that result from two devices sharing the same ARP remain the stuff of legend in networking circles.
For that same ARP war reason, DOCSIS clones can’t exist on the same CMTS. They can, however, exist on different CMTSs, and thus appear to the provisioning software as if the modem moved. These instances have to be handled with care, because legitimate moving happens from time to time as nodes are split and customers are recombined/shifted to new CMTSs.
Clones also vary in their depth, tactics and evil genius complexity. Some are only the same on the surface, and the façade is barely skin deep. Others are even more similar than maternal twins and can appear exactly the same down to the most minute detail.
Figure 1: This demonstration is using cable dynamic-secret reject nocrypt and ip tftp source-interface Loopback0 commands. The modem does its normal DHCP Discover, and the server sends a DHCP offer. This DHCP offer comes down, and is intercepted at the CMTS. The CMTS checks the static MIC if configured and then strips it off. It then edits the TFTP IP address, and potentially the config file name. The nocrypt option in this case leaves the filename unaltered. It then places a single use MD5 MIC secret, used for only this modem, and only during this registration. The modem then boots up and needs to use that specific MIC to decrypt and process the config file.
Config theft
As you may be aware, DOCSIS service hinges on a very small config file. Though it occupies only a few kilobytes, the file controls almost all aspects of service for a modem. This file sets the speed or SCN (service class name) and how many CPEs, filters, etc. In a perfect DOCSIS world, each modem gets exactly the config file it’s supposed to get. Unfortunately, oversights in specifications happen, and creative hackers have found ways around that perfect world.
TFTP spoofing
This brings us to the first type of DOCSIS theft, the aptly called “spoofing” method. This tactic is fairly passé in current hacking circles but helps show the time-line of how these hacks evolved. The hack was quite simple in that it only required a computer to edit cable modem config files and a freeware TFTP server. The modem is told the “siaddr” (TFTP server)/config file name inside the DHCPOFFER. The hack involves setting the computer behind the modem to that server IP address and creating an altered copy of that file stored on the local TFTP server.
This hack works by tricking the modem into thinking the computer behind the modem is actually the real TFTP server. The modem boots up and does the normal DHCP process, but rather than downloading the file from the real server over the HFC (hybrid fiber/ coax) network, it downloads it over the Ethernet interface from the fake server. This hack was initially broken by the implementation of cable shared-secret; it was also originally done on “unhacked” modems. After understanding the spoof, the vendors caught on and countermeasures were incorporated into modem firmware.
Nostalgia warning! This was my first cable modem hack and was done on a SB3100 running firmware 3.2.12 back around 2002.
TFTP playback
Playback works on an idea similar to spoofing but requires the modem be running hacked firmware. During the age this hack began, Sigma on the SB4200/SB5100 was the de facto standard for hacked firmware. Created by TCNISO/Der Engel, Sigma was light years ahead of DOCSIS security at the time and started what some would call a revolution in CM hacking. Playback builds on the spoof method, but rather than storing the altered/different file on the subscriber’s computer, it stored this file inside the modem’s flash memory.
Here’s how it works: The normal modem boot up process would commence, but rather than downloading the appropriate config file, the modem would simply load a config file from flash memory. Luckily, cable shared-secret still prevented the use of hacked and/or altered config files. TFTP-enforce also caught this trick until the hackers figured out you didn’t have to use the file you downloaded. The TFTP-enforce process doesn’t check which config you use, nor does cable shared-secret.
This allowed the so-called “TFTP bypass” trick to gain the limelight. The “TFTP bypass” trick fools the cable shared-secret and TFTP-enforce commands by going through all of the normal processes it should. It boots up, it does DHCP, and it even downloads the config file it’s supposed to download.
That sounds normal, so what’s wrong here? Well, after downloading the legitimate file, it throws it away and uses a locally stored config, usually with a faster tier of service.
TFTP-enforce misses this hack since a file is downloaded, and shared-secret misses it since the static MIC matches. This would mean you could sign up for the cheapest tier of service and steal the most expensive tier. Depending on the system design, it might mean the self-subscription file could be turned into the fastest tier.
This hack might also require some static IP squatting, depending on whether publicly routable IPs are used in self-subscription mode. If you use cable privacy dynamic-secret reject, this hack is quickly detected and defeated. Since every config is signed with a custom single-use MIC, they can only use the specific config they are assigned.
All clones are not the same
Take all the things listed in playback and add cloning. Now you have anonymity and a potential scapegoat. Here’s where things started to get very, very interesting. Clones have been getting gradually “smarter.”
Figure 2: This demonstration is using cable dynamic-secret reject nocrypt and IP TFTP source-interface Loopback0 commands. The modem boots up and does a DHCP discover, and the server sends a DHCP offer. This DHCP offer comes down and is intercepted at the CMTS. The CMTS then edits the TFTP IP address. The CMTS then does a TFTP to get to the config file using the information in the original DHCP offer, pulls the config down, checks the static MIC if configured, and strips the original MIC off. The nocrypt option in this case leaves the filename unaltered. The CMTS then places a single use DMIC secret, used for only this modem, and only during this registration. Since the modem got an “edited” DHCP offer with the CMTS IP as the TFTP server, it pulls the config file from there. The modem then boots up and needs to use that specific MIC to decrypt and process the config file.
Weakest clones (D1.0 with BPI, D1.x with no BPI)
Simple DOCSIS 1.0 clones are the most basic version of a clone. Think of this as an underage kid with a simple fake ID. Since D1.0 BPI does not tie specific modem MACs to the modem certs, clones can get on quite easily. Also in this category are any D1.x modem that completely disables BPI/BPI+ altogether.
This brings up a point: Any provider not running BPI/BPI+ is at a severe disadvantage when it comes to combating theft. Completely denying all D1.0 modems is the best option where you only allow BPI+. You can do this with the cable privacy bpi-plus¬ policy total-enforcement command. If you still have D1.0 modems, you can also force the D1.1 modems to use BPI+ with cable privacy bpi-plus-policy D1.1-enforcement.
Weak clones (D1.1 with BPI)
I classify weak clones as D1.1 modems that take advantage of spec by running D1.1 configs but use D1.0 BPI. So the modem is using a D1.1 config file with all of its benefits, but it’s not running BPI+. This allows them to “hide” in the network as the modem is “online(pt)” but still doesn’t have to pass the cert chaining/BPI+ checks normally required of D1.1. The information above using the cable privacy bpi-plus¬ policy command also applies here.
Strong clones (D1.1 clones with self- signed BPI+)
This type of clone opened the fight to a brand new weapon. With the advent of a new hacked cable modem firmware called Haxorware, the modem was able to create and use completely fictitious self- signed certificates. Haxorware picked up where Sigma left off and could be considered the second revolution in cable modem hacking. These self-signed certificates took advantage of a work- around most providers had been using for a long time.
What was this feature? Before the full D1.1 spec had been finalized, some D1.1 modems were sold. These modems shipped as D1.0 modems with D1.0 firmware, but the vendors were not allowed to include BPI+-enabled D1.1 certificates in the modems.
This meant the modems either had to be upgraded afterward by a rather complicated certificate import process or left in D1.0. The other option was to use the self-signed cert workaround. The workaround used the command cable privacy accept-self-signed-certificate to allow modems without chained certs to work. (NO’ing negates and hides the command in config.) This command was also the same command that allowed many of the old Acterna and JDSU modem/meters to work. More importantly, it allowed the meters to change MAC addresses and “spoof” customer modems for trouble- shooting purposes. This type of modem uses a “trusted” certificate, unlikely the Cablelabs-verified and cryptographically valid “chained” certificate.
Newer versions of Cisco IOS will mark modems using self-signed certs with the &online(pt); you can find them easily with the command “sh cable modem | i &.”
The perfect clones Smart clones (D1.1 with fully chained certificates using BPI+)
A smart clone has an imported cert and a cloned MAC to match the cert.
This is done either by exploiting a flaw in the modem to get the cert/MAC or by installing hacked firmware and im¬ porting/exporting the cert/MAC. Once the cert is exported, it can be used with the matching MAC to make a perfect clone. This type of clone uses an im¬ ported MAC/cert and not its own native burned-in “factory” address. This is the most common form of perfect clone, as hacked firmware makes cert importing certificates painfully easy to do.
Identical clones (D1.1 with fully chained certificates using BPI+)
Identical clones are built using a memory dump from the native modem’s flash chip. This raw modem image is then subsequently flashed into another modem’s flash chip. The flash chip is divided into sections, so you don’t necessarily need to copy the “whole” thing, just the important information stored at a specific memory address.
This type of cloning effectively makes two exact duplicates of a modem. This can also be done with a hacked modem, creating two identical copies of the same hacked modem. This method requires full physical access to the modem and generally relies on the factory method used to program the device’s flash.
A full modem copy can be done via serial/JTAG programming or direct reading/ writing the flash chip. This generally de- pends on the specific modem in question and the underlying security in place. Some modems are easier than others to hack due to the open JTAG/serial connectors, enabled consoles, fully shelled firmwares and/or easily accessed flash chips.
What does this mean to me?
The simple answer is preventing theft, enabling BPI and limiting clones. This is not remarkably hard. Sure, it will take some work, and you may have to upgrade your cable meters, modem firmware and IOS. It may also limit your ability to troubleshoot by preventing those meters from legitimately cloning. Remember that you may also need to swap out some D1.0 modems to get the CMTS side security to the highest level.
The benefits of doing this work will far outweigh the caveats, and I’ll list a few to wet your appetite:
- Some of these people you “knock off,” who actually like the service, will start paying for it. You’ll recover some rev- enue from transitioned subscribers and stop hemorrhaging it to the ones that abandon cable.
- Think of all the bandwidth you’ll save! The people cloning are probably a little higher on the curve of bandwidth usage, so kicking them off allows the paying subs to get better service.
- If this prevents a few nodes splits, trans- mitters, receivers, QAM spigots or a US CMTS port, that’s money you save.
It won’t prevent the money being spent at some point, but it might prevent you from wasting money to feed a customer stealing your service.
Legal authorities, armed with the Digital Millennium Copyright Act (DMCA), will go after thieves. Cloning makes it confusing to figure out who is doing what, and two of the more scary things that could happen include legal finger-pointing and potentially the wrong doors being kicked down. Someone get- ting sued for a DMCA violation because someone cloned them is not cool. Less cool than that is having the police/FBI/ DHS kick down the wrong door after the person’s modem was cloned. Worse, the person actually doing the crime could very well get away with it, in addition to the wrong person being blamed.
Special thanks to: • Charles Allred • Dave Watson • Bill Bryson • Dan Hegglin
Email: owen.parsons@cox.com
