It was recently shown by the Mirai botnet or Linux/Moose worm that more and more connected devices can run a large scale DDoS. As an example, I’ll provide here a small analysis showing that the problem is even more complicated since we sometimes have to live with old devices which have not been updated by Internet providers.
A few months ago I was connected to the Internet by a cable connection provided. I was interested in studying the security of the box after I saw a very good talk by Alexander Graf regarding cable modem security. My modem box was a Thomson (now Technicolor) TWG870.
This box provides Internet access through DOCSIS and offers all the usual features found in this kind of modem. A web interface is accessible on http://192.168.0.1 to configure it.
The good thing about this is that the internet provider delivers the box with the customer number as the login and a randomly chosen password.
The standard web vulnerabilities were tested on the web interface but nothing like for previous boxes was found. After scanning the box address no other open port was found. Therefore the box was opened to hunt for a serial/jtag port. The serial port was quickly found:
After hooking up the serial port, the bootloader displayed interesting information:
The operating system is RTOS eCos and runs on a MIPS BCM3380. However no interactive shell was available after the start-up which can happen sometimes. Then another IP address, 192.168.100.1, was noticed on the local network. In addition, a telnet server was running at this address:
It was another access to the box. However, the access is protected by a password and in this case, the credentials of the web interface were not accepted. The flash chip was a Macronix MX25L6405D and with the help of @dummys we were able to extract the firmware.
The firmware strings were then displayed:
Customer account and password were in clear in the firmware. In addition, the WPA-PSK was also in clear text. But there is more, just after the account credentials, another account seems to be hard coded (value changed in the image) and this account is allowed to connect to the web interface. This is a hidden account which allows you to change the settings of the box but you can neither disable it nor change the password. It seems to be added by the cable company and not Thomson since the memory space seemed to be customized by the cable company. Nevertheless, these credentials also worked at a friend’s place who has the same operator and same box to access the web interface. This is where the first security problem arose. In the web interface there is a “Remote Config Management” option.
It is off by default for this provider, however, by activating it, it allows you to connect to the web interface from outside of the LAN with the URL http://my.ip.address:8080. The hidden account also works remotely meaning that if you grant a visitor access to your LAN, then he can connect to the web interface and activate the previous option as a backdoor connection to the box. The cable company was informed about the issue but as far as we know they have not corrected it yet.
More interestingly, the “admin” credentials also work on the telnet access and allow access to the console.
Among a few commands, the call command allows one to execute any function with any parameter. This means that the box was completely owned. With such interesting findings, the firmware code was analyzed. Using the binwalk tool on the firmware highlighted two LZMA archives of almost the same size was highlighted. Each one starts with a file name and one of them ” TWG870-B3.01.74-150616-F-1C1.bin” matches the firmware version running on the modem. Even if the archives start with 5D 00 00 00 01 indicating a LZMA compression the next 64 bits should be the data’s uncompressed size but it wasn’t. An article from w00tsec gave the solution. By adding an uncompressed length after the header, the firmware images extracted successfully. As expected it was an eCos firmware for MIPS. The RAM offset where the firmware was loaded is located just before the file name.
With all the information in hand, the firmware was loaded in radare2 to analyse it further. A first analysis showed that after a valid authentication, the length of the URL is not checked if it ends by “.asp” and if you enter more than 40 characters you start to have an overflow. After the URL was sent, the box rebooted:
More interestingly, we can debug our exploit by using the previous telnet access which gave us a full crash dump:
You may have spotted that the return address changed to 0x00617370: “.asp”. It means that we fully overwrote the return address, therefore we can control the execution of the box. Combining this vulnerability with the backdoor account you have a complete remote access to the modem.
I quickly contacted Technicolor to inform them about the problem. They answered two days later informing me that the problem has already been corrected a while ago and my provider did not update the firmware. The cable Internet provider was contacted in May 2016, after a few exchanges, they answered just before the blog post publication that a new firmware and configuration will be pushed to the devices. Even if it does not concern a huge number of subscribers and even if it is not directly remotely exploitable it demonstrates that the central point of a personal network may not be secure even if you have a serious device manufacturer securing the device.
Yes, it’s a security flaw, but gaining access to their modem still puts you on the WAN side of their router (assuming they have a router).
Yes but exploiting on of the vulnerabilities of the router leave you the opportunity to access the LAN side.
I found this vuln about three years ago, my post (in polish): https://frankowicz.me/blad-w-popularnych-routerach-od-upc-technicolor-tc7200-i-thomson-twg870-umozliwiajacy-zdalny-restart-urzadzenia/
Could you please explain how did you extract the firmware of the Macronix MX25L6405D?
Thanks in advance!
We unsoldered the memory, connected to a bus pirate and dumped it with flashrom.
where do you find that this model is based on BCM3380 SoC? From info you provided it only follows that the device is using BCM33XX (Broadcom generic denotation). Can you specify full flash memory map addresses: Bootloader, Perm NonVol, Image1, Image2, Dynamic NonVol? (address, offset) Thanks.
It is written on the SoC package on the picture.