ARRIS Cable Modem has a Backdoor in the Backdoor

A couple of months ago, some friends invited me to give a talk at NullByte Security Conference. I started to study about some embedded device junk hacking hot topics and decided to talk about cable modem security. Braden Thomas keynoted at Infiltrate 2015 discussing about Practical Attacks on DOCSIS so, yeah, cable modem hacking is still mainstream.

On November 21st I'll be at Salvador speaking on "Hacking cable modems: The Later Years". It's not a talk about theft of service and getting free Internet access. I'll focus on the security of the cable modems, the technology used to manage them, how the data is protected and how the ISPs upgrade the firmwares. Spoiler Alert: everything's really really bad.

Securing cable modems is more difficult than other embedded devices because, on most cases, you can’t choose your own device/firmware and software updates are almost entirely controlled by your ISP.

While researching on the subject, I found a previously undisclosed backdoor on ARRIS cable modems, affecting many of their devices including TG862A, TG862G, DG860A. As of this writing, Shodan searches indicate that the backdoor affects over 600.000 externally accessible hosts and the vendor did not state whether it's going to fix it yet.


ARRIS Backdoors

ARRIS SOHO-grade cable modems contain an undocumented library (libarris_password.so) that acts as a backdoor, allowing privileged logins using a custom password.

The following files load the backdoor library on ARRIS TG862A Firmware TS0705125D_031115_MODEL_862_GW (released on 2015):

/usr/sbin/arris_init
/usr/sbin/dimclient
/usr/sbin/docsis_mac_manager
/usr/sbin/ggncs
/usr/sbin/gw_api
/usr/sbin/mini_cli
/usr/sbin/pacm_snmp_agent
/usr/sbin/snmp_agent_cm
/usr/www/cgi-bin/adv_pwd_cgi
/usr/www/cgi-bin/tech_support_cgi

ARRIS password of the day is a remote backdoor known since 2009. It uses a DES encoded seed (set by the ISP using the arrisCmDoc30AccessClientSeed MIB) to generate a daily backdoor password. The default seed is MPSJKMDHAI and guess what - many ISPs won't bother changing it at all.

The backdoor account can be used to enable Telnet and SSH remotely via the hidden HTTP Administrative interface "http://192.168.100.1/cgi-bin/tech_support_cgi" or via custom SNMP MIBs.

The default password for the SSH user 'root' is 'arris'. When you access the telnet session or authenticate over SSH, the system spawns the 'mini_cli' shell asking for the backdoor password.

When you log using the password of the day, you are redirected to a restricted technician shell ('/usr/sbin/cli')

Restricted shells are ;restricted

In order to understand how the backdoor works, I built an Puma5 toolchain (ARMEB) and cross compiled some useful tools like strace, tcpdump and gdbserver. I hosted them on my Github, get them here:

- https://github.com/bmaia/cross-utils/tree/master/armeb

While analyzing the backdoor library and the restricted shells, I found an interesting code on the authentication check:

Yes, they put a backdoor in the backdoor (Joel from Dlink is sure to be envy). The undocumented backdoor password is based on the last five digits from the modem's serial number. You get a full busybox shell when you log on the Telnet/SSH session using these passwords.

The vendor asked not to disclose details about the password generation algorithm. I'm really relieved knowing that those awful guys from Metasploit won't be able to reverse this in a timely manner.

Vulnerability, Disclosure and Marketing

Of course, we need a logo so the media can report about this with fancy graphs as well as vendors could distribute customized t-shits at Blackhat.

What I like most about lcamtuf is how visionary he is. While people were still writing dumb fuzzers, he wrote AFL performed a detailed Technical analysis of Qualys' GHOST. Based on his analysis, I hired a couple of marketing specialists to find out the best way to disclose the ARRIS backdoor.

What do we have here?

- Multiple backdoors allowing full remote access to ARRIS Cable modems
- An access key that is generated based on the Cable modem's serial number

After a thoughtful analysis, the marketing committee advised w00tsec members to write a Keygen. In order to write a Keygen, we need a leet ascii art and a cool chiptune. The chosen font was ROYAFNT1.TDF, from the legendary artist Roy/SAC and the chiptune is Toilet Story 5, by Ghidorah.

Here's the POC (make sure you turn the sound on):

Conclusion

I reported these flaws to CERT/CC on 2015-09-13 but we didn't receive much feedback from the vendor. CERT/CC was very helpful and responsive (10/10 would disclose again!). I was asked not to release the POCs immediately so I'm going to wait for the vendor to "fix" the issue.

CERT/CC set a disclosure policy of 45 days long ago. They waited for more than 65 days for them to "fix" it but ARRIS didn't remove the backdoors in a timely manner. Someone needs to update the Responsible Disclosure RFC and include a note describing that vendors shall lose disclosure points whenever they plant a backdoor on the device (ARRIS modems have a third backdoor too, check the ConsoleCowboys Blog).

I'm pretty sure bad guys had been exploiting flaws on these devices for some time (just search for ARRIS DNS on Twitter, for example). We need more people bypassing EULAs and reversing end-user software and firmware. If you haven't heard about the Firmware.RE, check them right now. A broader view on firmwares is not only beneficial, but necessary to discover new vulnerabilities and backdoors, correlating different device families and showing how vulnerabilities reappear across different products.

To all the vendors out there, I would like to finish this post by quoting @daveitel:

Binwally: Directory tree diff tool using Fuzzy Hashing

For this post, I'll discuss about the concept of directory tree and binary diffing and how it could be used to find potential vulnerabilities and security issues that were (silently) patched on firmware images.

Silent patching is a big deal as we don't have many security researchers like Spender around. This is a common practice among companies that create software and firmwares for embedded devices. Changelogs from new firmwares often contains few information about security issues, outlining the changes as "bugfixes" or "enhancements": we get no CVE's and we don't know how critical the flaws are.

In addition to that, you may occasionally find some reference for the string 'Ac1db1tch3z' on your code (which means that you got a free vulnerability assessment) or your employee Joel might forget to remove a backdoor from the firmware. Diffing the content from previous firmwares may be useful to find out when these backdoors were first installed, modified and/or removed.

I introduce you to Binwally: a simple script to perform directory tree diffing using the concept of Fuzzy Hashing (ssdeep) to define a matching score between binaries.

Binwally says "no" to Silent Patching

Fuzzy Hashing

Fuzzy Hashing, also know as context triggered piecewise hashes (CTPH), can match inputs that have homologies. Such inputs have sequences of identical bytes in the same order, although bytes in between these sequences may be different in both content and length. The concept was introduced by Andrew Tridgell and the most well-known tool is ssdeep, created by Jesse Kornblum.

The usage example outlined on ssdeep's homepage summarizes it well:

$ ls -l foo.txt
-rw-r--r--   1 jessekor  jessekor  240 Oct 25 08:01 foo.txt

$ cp foo.txt bar.txt
$ echo 1 >> bar.txt

A cryptographic hashing algorithm like MD5 can't be used to match these files; they have wildly different hashes.

$ md5deep foo.txt bar.txt
7b3e9e08ecc391f2da684dd784c5af7c  /Users/jessekornblum/foo.txt
32436c952f0f4c53bea1dc955a081de4  /Users/jessekornblum/bar.txt

But fuzzy hashing can! We compute the fuzzy hash of one file and use the matching mode to match the other one.

$ ssdeep -b foo.txt > hashes.txt
$ ssdeep -bm hashes.txt bar.txt
bar.txt matches foo.txt (64)

The number at the end of the line is a match score, or a weighted measure of how similar these files are. The higher the number, the more similar the files.

Binwally

Binwally is a simple Python script that uses this concept to diff directory trees in order to find different, unique and matching files, displaying an overall score of the results. It was based on diffall.py from the book Programming Python (4th Edition) and it requires python-ssdeep, a wrapper for ssdeep (which is coded in C). You can download the script from my Github, following the link below:

• Download Binwally

The code is pretty straightforward, it takes two dirs/files as arguments and displays which files are unique, the ones that matches and the ones that differs and their match score. It still needs some improvement (the matching score is based on the number of files and don't consider the filesizes for example) but it works fine for what it purposes to accomplish.

Comparing two directory trees from a firmware unsquased using Binwalk and firmware-mod-kit:

You can already achieve this using Winmerge, but the tool does not display a matching score, it's not command line based and not scriptable. You can check my previous post describing how to use it to differ firmware images.

Binwally is best used with Binwalk, that's why I'll talk to devttys0 to merge it with his tool (maybe a new command line switch under the Binary Diffing options). Binwalk already supports binary diffing (-H switch), but it will just compare files and firmware images. The problem is that firmware images are usually packed, encrypted and/or compressed. When you unpack and compare the extracted files and their directory tree, you have much more valuable information. If you disassemble the code and compare the results again, you get even better data - this is what bindiff from Zynamics/Google does pretty well. The Insinuator blog has a nice example on how to use bindiff for RE.

Binwally Usage: Dissecting DLink Backdoor Patch

So you may have heard recently that some DLink routers had a backdoor and that a security update was issued to address the vulnerability.

According to Bruce Schneier, we should "Trust but verify": that's what we are going to do here. First let's download the backdoored version (v1.13) and the patched version (1.14) from DLink's FTP. Next step is to extract the firmware images (binwalk -e DIR100A1_FW114WWB02.bix DIR100_v5.0.0EUb3_patch02.bix) and compare the directory trees using Binwally:

$ python binwally.py _DIR100_v5.0.0EUb3_patch02.bix.extracted/ _DIR100A1_FW114WWB02.bix.extracted/

I removed the matching files and symlinks for better reading, but the analysis is now narrowed to a small set of files. According to the release notes, a minor PPoE dial up issue was also fixed, that may be the reason why "/bin/pppd" had differences.

Some files like the "/www/Home/bsc_lan.htm" have a matching score of 100 even though they have different content and MD5, for example. This is due to the nature of Fuzzy Hashing, as the small modification was not enough to change the fuzzy hash value. It's important to note that files with a "match" result do actually have the same content and also have a matching score of 100.

There's a new Shell script on the patched 1.14 firmware, located at "/etc/wdhttp.sh". It seems that Joel "do not know how to write sash loop command ugly code":

Busybox was another binary that had a different pattern. Running them using QEMU shows that they still have the same version (v1.0.0-pre2) and different compile dates (2011.09.15 and 2013.10.31).

According to the analysis from devttys0, the binary "/bin/webs" had the backdoor function (if you did not read his analysis yet, read it here). Binwally returned a match score of 0 because it was unable to find similar patterns. The binaries have different sizes and were probably compiled using different toolchains, containing different offsets, as displayed on the diff from Winmerge:

Binwalk from v1.3.0 beta on now displays 3D binary data visualization, so let's have a look on how they differ in a 3D plane:

This is time to use an approach other than byte comparison and fuzzy hashing. Bindiff uses graph-theoretical approach to compare executables by identifying identical and similar functions. We first need to analyze both files using IDA to create the needed IDB files. After inputting both files on bindiff, we notice a high level of similarity on the Call Graphs:

Let's focus on the previously backdoored function "alpha_auth_check":

We can easily spot the difference displaying the flow graph:

Zooming in (courtesy of NSA):

It seems that Joel's "xmlset_roodkcableoj28840ybtide" is gone, say hello to "iNteLalsEtvaLuewitHoutnAme". And yes, it seems that Joel (and the binaries that can re-configure the device's settings) can only access the device from 127.0.0.1 now  =)

Conclusion

Binary and directory tree diffing is a powerful tool for reverse engineering and to find potential compromise of a system as long as you have a "known template". In the context of Embedded Systems, it reveals modified files, settings and directories, narrowing the analysis to a small set of data when analyzing different firmware images.

To all the vendors out there it's important to be transparent on what's being fixed, alerting the end-users about how critical the issues are. And please, leave the backdooring job to the guys who "read the constitution" and are paid for that, OK?