A security flaw in the modem provisioning system of Telekomunikacja Polska
Sent confidentially to Telekomunikacja Polska in October 2004. Disclosed to the public at the CONFidence 2006 conference in slide form. Translated from Polish using AI.
Summary
TP Internet DSL, based on ADSL technology, is a service from Telekomunikacja Polska (TP) mainly targeted at businesses. The DSL modem management system contains a serious security flaw. In this post, I will explain how I discovered the flaw, what risks it involves, and propose countermeasures.
Background
It all started when my DSL modem broke. I had been using TP’s DSL Internet Access service for a while and was mostly satisfied. The connection was provided by a Siemens Speedstream 5660 ADSL modem. The modem worked well, though it occasionally suffered from stability issues1. However, one thing always annoyed me: TP didn’t allow users to configure the modem themselves—it was password-protected, and neither the customer nor even the technician knew the password.
TP claimed this restriction was for security reasons2. Ironically, it actually compromised security.
Since the modem broke on a weekend, I knew I’d be waiting a while for a replacement. A friend lent me a Planet ADSL modem, and I tried configuring it manually. The DSL link connected fine, but I couldn’t get past the PPP login—I didn’t have the username or password, and TP didn’t provide this information to customers. After some persistence, a helpful technician gave me the PPP credentials, which I greatly appreciated.
During that call, I learned something interesting: by entering a special service login and password, a script would automatically configure the modem. Unfortunately, this only worked with Speedstream modems, so I had to configure everything manually.
How it works
The service login and password are a clever trick for installers. The installer resets the modem to factory settings, connects it to the DSL line, and enters the login konfiguracja@konfiguracja with the password konfiguracja. A script then completes the configuration remotely.
This setup prevents rogue installers from keeping access to modems or sharing it with customers. TP controls a centralized database of logins and passwords, allowing them to enforce strong password policies.
But as I realized, this special pair of login and password shouldn't be public—because it can be exploited. And anyone can learn them—all it takes is carefully watching the technician’s hands during modem configuration.
The experiment begins
I began to wonder whether this automation could be used to gain access to the modem.
I downloaded the modem manual from the manufacturer’s website. After studying it, I concluded that the modem is most likely configured remotely via Telnet, since it has a built-in Telnet server. If I could intercept the Telnet session, I might be able to extract some interesting information. But how? The transmission takes place over the DSL line. A DSL sniffer? It was beyond my reach.
Eventually, I came up with an idea. An attacker equipped with two DSL modems and some additional hardware can build a network like the one shown below:
The attacker configures the Planet modem to forward (NAPT) traffic coming from the Internet on administrative ports (Telnet, WWW, SNMP, FTP) to an internal host—the Speedstream modem. The Speedstream is reset to factory settings—this enables Telnet access to its configuration. The last step is to set the default route on the Speedstream so that it goes through the Planet modem.
I entered the service login and password into the Planet modem's PPP configuration, then started a sniffer on my PC...
First success
After a moment, the Planet modem establishes a connection. It receives an address from the pool of service addresses. After a short while, the attacker notices activity on the Ethernet network. The traffic comes from a provisioning server that initiates a Telnet connection to the Planet modem, which forwards it to the Speedstream modem, allowing interception of the session. After recording and analyzing the transmission, I learned, among other things, confidential information about the modem!
Type "?" at the command prompt for a list of commands.
Type "help" at the command prompt for general help.
For detailed help on a specific command, type command name
followed by a "?", for instance, "show ?".
Command-> show
--- General Router Information
System Mode - Router
System Type - SpeedStream 5660-R:ENI
System HW Version - 0
System Up Time - 0 Days 0 Hours 22 Minutes 36 Seconds
Software Version - 2.3.0(8) Jan 13 2003 09:29:38
Factory MAC Address - 00:11:22:33:44:55
DSL Phy Description - Motorola 850 SAR Alcatel/RT Adapter
DSL Phy Version -
DSL Interface State - Down
Host Name - SpeedStream
Domain Name - domain.invalid
IP Gateway - 10.0.0.2
Ethernet Interface - 10.0.0.1/255.0.0.0
DSL Interface - /
RIP Mode - Disabled
DNS Server - Enabled
DHCP Server - Enabled
NAPT Mode - Enabled
IP Filter Mode - Disabled
Command-> set pppauth xxxxxxxx@internetdsl xxxxxxxx
Command-> set napt disable
Command-> set ethip x.x.x.x x.x.x.x
Implement IP changes now? default: n [y,n] n
Changes will not take effect until modem is rebooted!
Command-> set snmpcfg xxxxxxxx a a a 10.10.10.10 10.10.10.10
Command-> set password
Setting user password:
New password : ********
New password : ********
Password updated
Command-> reboot
Are you sure? default: n [y,n] y
System rebooting as requested!!!!The provisioning script connects, displays the modem’s data (using the show command), and sets configuration parameters, passwords, and the IP address. Finally, it reboots the modem so the new configuration can be loaded. As a side effect of the reboot, even if the attacker had initiated an administrative session (via Telnet or serial console using the factory password) before the script started configuring the modem, that session would be terminated by the reboot. If the reboot didn’t occur, the attacker would remain connected and could retrieve the newly set passwords.3
For a moment, I wondered why the script ran the show command, but the answer quickly became clear: this is how the script identifies the modem to assign it the correct configuration. The only piece of data likely to differ between modems is the MAC address…
The masquerade
I wrote and ran a simple Perl script. The script, when hooked up to inetd on port 23, emulates the behavior of the modem’s Telnet server after a factory reset. I set up a network similar to the previous one, but without the Speedstream modem, since it’s no longer needed.
To check whether it’s possible to obtain passwords for any modem, I configured the script to display the MAC address of another existing device.
Indeed, the provisioning script connected to my script and handed over the configuration data of a different modem!
I could repeat this experiment successfully using the MAC address of a modem from another city. To obtain confidential configuration data for any modem in Poland, all you need is its MAC address!
Packet filter
I gained Telnet access to modems to which I had physical access. However, an attempt to log in to a modem in another city failed. Connections to the Telnet port were hanging—there was no response from the remote modem. Meanwhile, TCP connections to other ports were actively rejected (the modem sent a TCP packet with the RST flag set). This was a clear sign of packet filtering.
Using the tcptraceroute tool, I determined where the packets were being filtered. It turned out the filtering was done by the DSLAM located just before the remote modem. A DSLAM (DSL Access Multiplexer) is a central hub to which many DSL modems are connected. It provides connectivity between the modems and the external network. In the case of TP, these are most likely Lucent’s Stinger devices.
The packet filters and “firewalls” in the operating systems of such devices usually have little in common with professional solutions (like Cisco PIX, GNU/Linux, or *BSD systems). Instead, they function more like add-ons that “sort of work.”
Based on this assumption, one can try to bypass the DSLAM’s blocking rules. Simple packet filters may, by default, allow all fragmented packets through. I needed to structure the connection attempt to the modem so that at least the initial connection packet is fragmented. For this, I used the fragroute tool. It turns out a small patch was necessary because the program doesn’t fragment packets with the SYN flag set, which are precisely the packets that need to be fragmented.
Filter bypassed!
The filter allowed the fragmented packets through, and the attacker gained remote access to the modem.
Another method of bypassing the filter is IP spoofing. For the attack to succeed, one would need to find an inactive IP address that’s on the DSLAM’s list of “trusted” addresses. These IPs should be searched for “near” the IP address of the server running the modem configuration script.
If such a trusted, inactive IP were found, the attack—despite the obvious challenge of performing it without feedback—would be relatively simple because, according to Nmap, the modem’s ISN (Initial Sequence Number) generator is predictable:
Starting nmap x ( http://www.insecure.org/nmap/ ) at xxxx-xx-xx xx:xx CEST
Host x (x.x.x.x) appears to be up ... good.
Initiating SYN Stealth Scan against x (x.x.x.x) at xx:xx
Adding open port 1723/tcp
Adding open port 21/tcp
Adding open port 80/tcp
Adding open port 23/tcp
The SYN Stealth Scan took 6 seconds to scan 1659 ports.
For OSScan assuming that port 21 is open and port 1 is closed and neither are firewalled
Interesting ports on x (x.x.x.x):
(The 1655 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
21/tcp open ftp
23/tcp open telnet
80/tcp open http
1723/tcp open pptp
Device type: firewall|switch|WAP
Running: SonicWall embedded, Enterasys embedded, Cisco embedded
OS details: SonicWall SOHO firewall, Enterasys Matrix E1, or Accelerated Networks VoDSL, or Cisco 360 Access Point
TCP Sequence Prediction: Class=64K rule
Difficulty=1 (Trivial joke)
IPID Sequence Generation: Incremental
Nmap run completed -- 1 IP address (1 host up) scanned in 12.380 secondsWhat’s next?
Full access to the modem gives a malicious actor significant capabilities.
In the simplest case, the attacker could disconnect the subscriber from the Internet by disabling the LAN interface; they could change the modem’s access password, preventing TP technicians from reaching the device; or they could attempt to break into the subscriber’s internal network, which until now was protected by the modem’s NAT.
There is an officially undocumented SET PRIV command that provides full access to the operating system (VxWorks). Full system access gives the attacker virtually unlimited possibilities—they could upload and run any program on the modem. Such a program could turn the modem into a so-called “zombie” used in DDoS attacks; it could allow the attacker to eavesdrop on traffic and perform man-in-the-middle (MitM) attacks. Finally, the program could reprogram the modem’s FLASH memory to the point that it stops functioning entirely and would require service reprogramming.
The described threats become more serious when one considers the number of modems in use in Poland.4
The problem of obtaining MAC addresses
To gain control over a modem, one must know its MAC address. It wasn’t possible to obtain this address based on the IP of the Speedstream 5660 modem.
After analyzing a transmission dump between the script and the modem using p0f, it turned out that the server running the configuration script most likely operates under Solaris 8.
p0f - passive os fingerprinting utility, version 2.0.2
(C) M. Zalewski <lcamtuf@coredump.cx>, W. Stearns <wstearns@pobox.com>
p0f: listening (SYN) on 'filtered.dump', 193 sigs (9 generic), rule: 'all'.
80.50.248.71:14396 - Solaris 8 (1) (NAT!)
-> 10.0.0.1:23 (distance 8, link: unknown-1472)
[+] End of input file.If an attacker were able to gain control of this server, they would also have access to the MAC address database (and most likely passwords and other confidential data as well).
The server is protected by a firewall that likely performs packet defragmentation, so the previous trick with packet fragmentation wouldn’t work here. I did not attempt direct intrusion, but I tested the provisioning script by feeding it incorrect input. It proved to be resistant—at least to the inputs it was tested with.
While testing the buffer capacity of the remote side, it became clear what kind of firewall was in use. When my program sent a large amount of data, the script on the other side disconnected and closed the connection. The firewall interpreted this as a terminated connection, while my program kept sending data. As a result, the packets sent by the program were reset—but in a very specific way. The RST packets weren’t empty—they contained a payload that was a copy of the packet being reset. This is a known bug in Cisco PIX.
With other methods blocked, brute-forcing MAC addresses was the remaining option. Of course, it’s not necessary to scan the entire MAC address space. While there are 2⁴⁸ possible MAC addresses, which might sound discouraging, the first three bytes are identical for all the modems. Additionally, the first half of the fourth byte is often the same. That narrows it down to 2²⁸ = 268,435,456 possibilities.
It’s reasonable to assume that TP purchased modems in batches. Devices from the same batch have almost identical MAC addresses. If the attacker “hits” one valid MAC address, finding others from the same batch becomes easy.
During testing, I observed that TP’s script has timeouts for modem configuration. If the modem doesn’t respond within a certain time, the script disconnects and reconnects—this cycle can repeat multiple times. This behavior can be exploited to speed up password collection.
With enough time, it would be possible to create a password-harvesting program that intelligently scans MAC addresses and extracts passwords from the database at a rate of one every few seconds—provided it “hits” a valid series. The wait time could be longer if the MAC address is a miss, but likely no more than 2–3 minutes.
New modems
After identifying and initially describing the vulnerability, it turned out that, in addition to the Speedstream 5660 modems, TP was also providing subscribers with newer modems—devices from the same manufacturer, but marked with the model number 5100.
Like the 5660, the Speedstream 5100 also features a web interface for managing and monitoring the modem. However, unlike the 5660, which protects the entire interface with a password, the 5100 allows users to monitor the modem's status without authentication. This allows subscribers to diagnose connection issues without needing full access.
The main page of the web interface also includes basic information about the device. From an attacker’s perspective, the key piece of information is… the MAC address.
The problem of obtaining MAC addresses—solved
This is a major convenience for an attacker. Knowing the IP address of a remote modem is enough to connect to the modem’s homepage (again using fragmented packets) and retrieve its MAC address.
An attacker, using a tool to scan all IP ranges assigned to TP and looking specifically for 5100 modems (which are easy to identify remotely), could very quickly collect the MAC addresses of all such modems in Poland. Needless to say, all of the previously described threats also apply to these devices.
Default password
An attempt to retrieve authentication data for the 5100 using the spoofing script failed. The provisioning script disconnected, just as it does when it receives an invalid response from the modem. It’s likely because the CLI interface was different.
To adapt the spoofing script to “work” with the 5100, I recreated the test setup—this time using the newer modem. Analysis of the captured transmission provided the necessary details and revealed an amusing fact: to prevent subscribers from tampering with the configuration, the factory password had been changed. This means even someone with the modem's manual—including the default password—cannot gain access to the device after a factory reset.
Unfortunately, by analyzing the transmission between the script and the modem, an attacker can easily learn this password.
Countermeasures
It's difficult for me to suggest what actions TP could take to secure the DSL system as I’m certainly unaware of all its features and the requirements it must meet. I also don't know the system's internal architecture or the capabilities of the devices that comprise it. Still, I will briefly discuss some simple remedies that wouldn't require major changes to the system design.
The most reliable solution would be to abandon automatic modem configuration entirely. However, I realize this could increase the cost of installing new modems and maintaining existing ones.
If the packet filters on DSLAMs allow it, a simple measure could be to block fragmented packets. However, this would serve only as a temporary fix, as it doesn’t prevent credential theft from the central database nor stop the use of those credentials when the attacker has physical access to the modem.
A more balanced solution might be to limit automatic modem provisioning to a few trusted locations—for example, one in each major city. In those locations, technicians would configure the modems before installing them at customer premises.
The modem requires that all IP addresses available to the client be used; otherwise, it often "freezes."
TP FAQ, question 59.
Even the Telnet password, although it isn’t displayed—it can only be changed. However, the Telnet and SNMP passwords are the same in TP’s system, so obtaining one effectively gives access to the other.
According to information dated August 29, 2004, published on the website of Telekomunikacja Polska, the DSL Internet Access service from TP is used by 35,000 subscribers.