Sitecom firmware encryption and wireless keys

Authors: Roberto Paleari (@rpaleari) and Alessandro Di Pinto (@adipinto)

Last year we blogged about multiple security issues affecting Sitecom device models WLM-3500 and WLM-5500. One of these issues allowed attackers to obtain the default wireless passphrase of a vulnerable device in a "single shot", as the wireless key was derived from the device MAC address using an algorithm included inside the device firmware. This is a very serious issue, as many users never change the default Wi-Fi passphrase and keep using the one set by the device manufacturer.

We recently had the opportunity to analyze some other Sitecom routers, more precisely models WLR-4000 and WLR-4004. We were first attracted by this models due to the introduction of some mechanism to encrypt the firmware image distributed through Sitecom web site. To make a long story short, we soon realized the encryption layer could be easily circumvented; in addition, these routers were affected by the very same issue concerning the wireless passphrase: also for these models the key is derived from the MAC address, thus attackers can easily generate the default wireless key and access the LAN of a victim user.

Analysis of the firmware layout

In the following we briefly describe the analysis of the WLR-4004 firmware image (v1.23), but WLR-4000 differs only in minor details.

As a first step, to analyze an embedded device we typically try to download the firmware (when available) and inspect its contents. With WLR-4000/WLR-4004 devices we were lucky enough to find the firmware image on Sitecom web site. However, a preliminary analysis of the firmware  using binwalk provided no information about its internal structure:

$ binwalk 4004-FW-V1-23.bin
DECIMAL       HEX           DESCRIPTION
---------------------------------------------
$

This can be a symptom of a weird image format or, more often, an encrypted/obfuscated firmware. After we gave a quick look at the file entropy, we started to opt for the latter hypothesis. As an example, consider the low-entropy areas around 1.4MB and at the very end of the file:

File entropy for the WLR-4004 firmware image

A closer look to these regions provided some clues about the actual structure of the firmware image. As can be seen from the hex dump below, the final low-entropy area is due to the very same 8-byte sequence (88 44 a2 d1 68 b4 5a 2d, highlighted in red) that repeats until the end of the file.

$ dd if=4004-FW-V1-23.bin bs=$((0x0339720)) skip=1 | xxd | head
0000000: 00c6 ece0 c8f2 402e bdaa db83 d91d d987  ......@.........
0000010: b47d 4da1 987d 0f0d d64f 901a a6ae 056a  .}M..}...O.....j
0000020: 6d68 0219 3648 7980 4073 c849 ee04 5a2d  [email protected]
0000030: ef9c ae4f 68b5 f52f 104c a2d1 1d08 620a  ...Oh../.L....b.
0000040: b674 af5a 6ab4 5a2d 8845 fb8b fe71 472d  .t.Zj.Z-.E...qG-
0000050: 8844 a2d1 6c34 5a2d 8844 5617 75b4 5a2d  .D..l4Z-.DV.u.Z-
0000060: 8844 a2d1 68b4 5a2d 8844 a2d1 68b4 5a2d  .D..h.Z-.D..h.Z-
0000070: 8844 a2d1 68b4 5a2d 8844 a2d1 68b4 5a2d  .D..h.Z-.D..h.Z-
0000080: 8844 a2d1 68b4 5a2d 8844 a2d1 68b4 5a2d  .D..h.Z-.D..h.Z-
0000090: 8844 a2d1 68b4 5a2d 8844 a2d1 68b4 5a2d  .D..h.Z-.D..h.Z-
...

In an unencrypted firmware, the final bytes of the image are often used for padding and are thus initialized to zero (or to 0xff). But assuming our Sitecom firmware has been encrypted using some standard scheme, which algorithm would produce such a recurring pattern?

Our first attempt was to try with a basic XOR encryption, assuming a 8-byte key equal to byte sequence we observed before. The following Python snippet reads the encrypted image from standard input, performs the XOR and writes the result to standard output.

Firmware decryption routine for WLM-4004 images

After decrypting the firmware image we tried again to use binwalk to analyze the firmware. The results confirmed our hypothesis about a XOR algorithm being used to cipher the image: this time binwalk identified all the main components of a standard firmware image, including the kernel image (at offset 0xc0) and the root file system (offset 0x15d080).

$ cat 4004-FW-V1-23.bin | python decrypt.py > decrypted.bin
$ binwalk decrypted.bin

DECIMAL       HEX           DESCRIPTION
----------------------------------------------------------------------------------------
128           0x80          uImage header, header size: 64 bytes, header CRC: 0xAAB37DFB, created: Wed Jan 15 06:15:01 2014, ...
192           0xC0          LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 4240232 bytes
1429632       0x15D080      Squashfs filesystem, little endian, version 4.0, compression:  size: 1951490 bytes,  131 inodes, blocksize: 131072 bytes, created: Wed Jan 15 06:14:03 2014

 

Generation of the wireless key

We were finally able to analyze the contents of the firmware image (and, in particular, of the root file system) to search for any evidence of the wireless key generation algorithm. We were soon attracted by a rather "suspect" function exported by a shared library named libdbox.so; the function itself was named generate_wpa2_key_based_on_mac(). And yes, as you can probably imagine this is exactly the function we were looking for :-)

Function generate_wpa2_key_based_on_mac(), exported by libdbox.so

Similarly to the algorithm we found in WLM devices last year, the scheme used in WLR routers is also based on "scrambling" the MAC address and apply some character substitutions leveraging a hard-coded charset. The WLR-4000 and WLR-4004 only differ in the actual charset being used. More in detail, the algorithm is sketched out in the next figure.

A fragment of the key generation algorithm

As usual, we wrote a Python script that implements the attack (available here). The script receives in input the MAC address of the vulnerable Wi-Fi network and the router model name ("4000" for WLR-4000 and "4004" for WLR-4004) and generates the corresponding Wi-Fi key. A usage example is shown below.

$ python wlr-genpsk.py -m 4000 aa:bb:cc:dd:ee:ff
MAC:  aa:bb:cc:dd:ee:ff
SSID: SitecomDDEEFF
WPA:  ND68V8QLC6VS

$ python wlr-genpsk.py -m 4004 aa:bb:cc:dd:ee:ff
MAC:  aa:bb:cc:dd:ee:ff
SSID: SitecomDDEEFF
WPA:  C3N8VQEA2NVG 

Conclusions

Is not so uncommon for embedded device makers to rely on some obscure, and often custom-made, algorithms in order to generate secrets (e.g., Wi-Fi keys, admin passwords) starting from public details (e.g., MAC addresses, wireless SSID). Such approaches are quite handy for testing, debugging and manufacturing purposes. Even if it could be a very bad security practice, as long as the algorithm is sufficiently robust and is not leaked, no big issues arise.

However, in this blog post we shown how things can change when developers "forget" to remove an implementation of the algorithm from the final version of the device firmware: in these cases, it is just a matter of time until the code is found, analyzed and a key generator is developed, even when the device firmware image is "protected" by some obfuscation or encryption scheme.

Multiple vulnerabilities on Sitecom devices

Authors: Roberto Paleari (@rpaleari) and Alessandro Di Pinto (@adipinto)

One of our main activities at Emaze consists in analyzing embedded devices to identify security vulnerabilities that could be exploited by attacker to threaten end-users. In this blog post we focus on some issues that affect Sitecom N300/N600 devices, more precisely models WLM-3500 and WLM-5500 (...and possibly others).

The first vulnerability concerns the Wi-Fi network. Modern routers typically allow users to access the Internet also through a wireless connection. Obviously, Wi-Fi is crucial from a security perspective, as could allow nearby attackers (i.e., attackers located within the Wi-Fi network range) to access the user's local network. Unfortunately, in the past embedded devices have often been found to be affected by security vulnerabilities that allow attackers to access the Wi-Fi network, as we also demonstrated in previous blog posts. In the specific case of Sitecom devices, one of the issue we identified permits attackers to obtain the default wireless passphrase configured on the device. As many users don't change the predefined wireless key and keep using the default one, attackers can exploit this vulnerability to connect to the Wi-Fi network and access the victim's LAN.

In addition, we describe two vulnerabilities that permit remote attackers (i.e., attackers located anywhere on the Internet) to activate and access the Telnet service on the device, thus gaining full control over any aspect of the router.

Wireless key generation

Affected Sitecom devices are shipped with a 8-letter WPA/WPA2 passphase, printed on a stick attached under the device. The very same passphrase can  be also used to authenticate to the router web interface, with administrative privileges. At a first glance, this key seems just like a random sequence of eight lowercase and uppercase letters. However, our analysis revealed that this 8-letter key is not random at all, as it can be generated from publicly-accessible information, namely the MAC address of the wireless interface card.

Generating the WPA/admin passphrase from publicly-accessible information

This kind of issue is not new: in the past several other device models were shown to derive the wireless passphrase from the MAC address and/or the Wi-Fi SSID (e.g., Thomson, Huawei and many others). To the best of our knowledge, this is the first time Sitecom devices are also proved to be vulnerable.

More in detail, attackers can connect to a vulnerable Sitecom Wi-Fi network through a simple 3-step procedure:

1. Move inside the wireless network range and intercept the router Wi-Fi MAC address.
2. Apply the Sitecom key generation algorithm. This algorithm, starting from the Wi-Fi MAC address, generates the default WPA passphrase.
3. The generated WPA key can be used to access the victim's wireless network, unless the user has changed it configuring a different Wi-Fi passphrase.

Of course, the challenge for the attacker is to determine which algorithm was used to generate the WPA key starting from the Wi-Fi MAC address. In the case of the affected Sitecom routers, the key generation algorithm was included right inside the device firmware, and was used during a "factory reset" procedure to re-generate the default WPA passphrase.

To demonstrate this attack, we reconstructed the WPA key generation algorithm and implemented it in a Python script, available here. Usage is very simple: just invoke the script passing the MAC address of the target Wi-Fi network, as shown in the example below. The script outputs both the key for the WLM-3500 and the two passphrases for the dual-band WLM-5500.

$ python sitecomkeygen.py aa:bb:cc:dd:ee:ff
==== Single-band (N300/WLM-3500) ====
KEY 2.4GHz: DqzskECV

==== Dual-band (N600/WLM-5500) ====
KEY 5GHz:   1ju5YcPQ
KEY 2.4GHz: 1jgFz11Q

Unauthorized Telnet access

We also realized that unauthenticated remote users can enable the Telnet server by accessing the following (undocumented) URL:

http://<target-ip>/cgi-bin/telnetControl.cgi

This URL is accessible on the WAN side, i.e., it can be invoked by Internet-facing attackers. As soon as the URL is accessed, the Telnet server is enabled also on the WAN interface. In addition, attackers don't have to guess a valid username/password combination to login: Sitecom devices embed a hard-coded credential, "admin:1234", that can be used to authenticate to the Telnet service, with administrative (i.e., root) privileges. As this administrative account is hard-coded, it cannot be disabled nor changed by a normal user.

Remediation

All the security issues discussed in this blog post have already been notified to Sitecom. Sitecom has now released updated firmware versions to address the Telnet issues (firmware versions WLM-3500v2001 v1.08 and WLM-5501v1001 v2.01). Besides manual upgrade, patched software images are also distributed to end-users through the automatic firmware upgrade feature. 

Regarding the wireless passphrase issue, obviously Sitecom cannot distribute a modified firmware that changes the Wi-Fi key with a true random one, as this approach would make several users unable to access their Wi-Fi network. For this reason, we strongly recommend Sitecom users to immediately change their Wi-Fi passphrase, avoiding to use the default one.

In addition, Sitecom confirmed that the algorithm for the generation of WPA/admin passphrase discussed above is valid only for WLM-3500 and WLM-5501 devices. New device models should not be affected by the same issue.

Huawei B153 3G/UMTS router WPS weakness

Authors: Roberto Paleari (@rpaleari) and Alessandro Di Pinto (@adipinto)

Introduction

Last May we performed a security assessment involving a B153 device, a 3G/UMTS wireless router manufactured by Huawei.

During these tests, we identified a new, previously unknown, security issue that allows to instantaneously crack the WPA/WPA2 passphrase of any of these devices. In other words, by exploiting this vulnerability attackers can gain access to the victim's wireless network in a "single shot", without the need of any brute forcing.
All the tests were performed using a Huawei B153 device; other device models from the same family are probably also affected, but they were not tested.

As required by the ISP that distributes this device to end-users, we do not disclose the full commercial name of the product, but only the manufacturer device model (i.e., Huawei B153).

Vulnerability overview

Like many other Wi-Fi routers, the B153 device supports the WPS procotol, to allow wireless users to easily authenticate to the WPA/WPA2 network. In December 2011, one of the WPS methods, namely the "external registrar" PIN-based method, was demonstrated to be insecure by design, as attackers can brute force the configured PIN in just few hours. This attack is now implemented in publicly available exploitation tools, such as reaver.

We noticed that, in the default settings, B153 devices are configured to accept PIN-based WPS sessions. However, no WPS PIN is actually configured: attackers can spend hours trying all possible WPS PINs, but none of these PIN values will actually work. Nevertheless, the fact that the device actually replies to PIN-based WPS requests was quite suspicious, so we decided to investigate more deeply.

We spent some time analyzing the implementation of the WPS daemon running on the B153. We soon realized that, despite no WPS PIN is actually configured, a specially-crafted WPS session can still force the device to complete the handshake, revealing the current WPA2 passphrase. In other terms, attackers located within the wireless range of the device can instantly recover the WPA passphrase.

It should be considered that this vulnerability allows attacker to return the current WPA/WPA2 key: even if the user has modified the key, choosing a passphrase different than the default one, the attack still succeeds. Additionally, we would also like to stress out that this vulnerability is present in the default device configuration, thus no user action nor any specific customization is required.

Proof-of-concept attack

This attack cannot be performed using a "standard" WPS cracking tool, as it requires a peculiar modification to the WPS protocol implementation.

We implemented a proof-of-concept by modifying the reaver WPS cracking tool, introducing few modifications to the WPS implementation in order to exploit the vulnerability we identified on B153 devices. A sample session using our patched reaver tool is reported below, showing how WPA/WPA2 key is recovered in a "single shot", i.e., with a single WPS session.

$ sudo ./reaver -c 1 -i mon0 -b aa:bb:cc:dd:ee:ff -vv

Reaver v1.4 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner <[email protected]>

  ----------------------------------------------------------------
-=[ Patched by Emaze Networks to implement the Huawei B153 WPS attack ]=-
    ----------------------------------------------------------------

[+] Switching mon0 to channel 1
[+] Waiting for beacon from AA:BB:CC:DD:EE:FF
[+] Associated with AA:BB:CC:DD:EE:FF (ESSID: xxx79E0)
[+] Trying the "secret" pin :-)
[+] Sending EAPOL START request
[+] Received identity request
[+] Sending identity response
[+] Received M1 message
[+] Sending M2 message
[+] Received M3 message
[+] Sending M4 message
[+] Received M5 message
[+] Sending M6 message
[+] Received M7 message
[+] Sending WSC NACK
[+] Sending WSC NACK
[+] Pin cracked in 3 seconds
[+] WPA PSK: '5D3FC94E'
[+] AP SSID: 'xxx79E0'
[+] Nothing done, nothing to save.

To protect end-users, we will not disclose the details of the attack, nor the reaver patch we developed. In fact, despite the device manufacturer now provides a firmware version that should address this vulnerability, to the best of our knowledge the new software is not deployed automatically on the affected devices, and vulnerable users are required to manually update their devices. Unfortunately, according to our experience, end-users apply security patches to their embedded devices very rarely.

Conclusions

We notified this security issue to the manufacturer on May 21st, 2013, providing a technical description of the attack and our proof-of-concept implementation of the exploit. Huawei released an updated firmware version that addresses this vulnerability. Emaze has still not tested the effectiveness of the security patch introduced in this new software version.

Testing wireless access points

Nowadays, wireless devices are ubiquitous. Despite the widespread diffusion of this technology,  the security of wireless systems still needs a thorough scrutiny, in particular at the 802.11 network stack level.

Today we introduce WiFuzz, a very simple but nifty tool for testing wireless access point (AP) devices. WiFuzz generates "fuzzy" 802.11 network packets to trigger corner-case errors in the AP 802.11 stack.

How it works?

WiFuzz is written entirely in Python, and leverages the Scapy library for packet generation. To use WiFuzz, the network card driver must support traffic injection. Moreover, the wi-fi interface must be put into "monitor mode"; as an example, with my NIC these commands do the job:

$ sudo rmmod iwlagn
$ sudo modprobe iwlagn
$ sudo ifconfig wlan0 down
$ sudo iwconfig wlan0 mode monitor
$ sudo ifconfig wlan0 up

Only two mandatory parameters are required before starting to fuzz: the fuzzer type, and the SSID of the target AP.

WiFuzz is somehow a "stateful" fuzzer: depending on the chosen fuzzer type, it first moves to a suitable 802.11 state before starting to fuzz the AP. As an example, 802.11 Association requests are fuzzed with the "assoc" fuzzer, that first moves to the "probed" state, then authenticates with the AP ("authenticated" state), and finally starts to fuzz Association packets. Available fuzzers are visible in the following screenshot.

WiFuzz help screen

Fortunately, state transitions are handled transparently by the tool, so you can just forget them ;-) For example, to fuzz the AP identified by the "TestMe" SSID the following syntax can be used:

$ sudo python wifuzz.py -s TestMe assoc

To detect AP crashes, WiFuzz periodically listens for Beacon frames from the target access point: if no Beacon is received, WiFuzz assumes the target has crashed, and a PCAP test case is generated to reproduce the crash. Test cases can be replayed using the wireply.py utility.

Use case
Here is a brief example of WiFuzz in action. In this scenario, we used WiFuzz to test the access point with SSID "TestMe".

$ sudo python wifuzz.py -s TestMe auth
Wed Sep 28 10:38:36 2011 {MAIN} Target SSID: TestMe; Interface: wlan0; Ping timeout: 60; PCAP directory: /dev/shm; Test mode? False; Fuzzer(s): auth;
Wed Sep 28 10:38:36 2011 {WIFI} Waiting for a beacon from SSID=[TestMe]
Wed Sep 28 10:38:36 2011 {WIFI} Beacon from SSID=[TestMe] found (MAC=[00:aa:bb:cc:dd:ee])
Wed Sep 28 10:38:36 2011 {WIFI} Starting fuzz 'auth'
Wed Sep 28 10:38:36 2011 {WIFI} [R00001] Sending packets 1-100
Wed Sep 28 10:38:50 2011 {WIFI} [R00001] Checking if the AP is still up...
Wed Sep 28 10:38:50 2011 {WIFI} Waiting for a beacon from SSID=[TestMe]
Wed Sep 28 10:38:50 2011 {WIFI} Beacon from SSID=[TestMe] found (MAC=[00:aa:bb:cc:dd:ee])
Wed Sep 28 10:38:50 2011 {WIFI} [R00002] Sending packets 101-200
Wed Sep 28 10:39:04 2011 {WIFI} [R00002] Checking if the AP is still up...
Wed Sep 28 10:39:04 2011 {WIFI} Waiting for a beacon from SSID=[TestMe]
Wed Sep 28 10:39:04 2011 {WIFI} Beacon from SSID=[TestMe] found (MAC=[00:aa:bb:cc:dd:ee])
Wed Sep 28 10:39:04 2011 {WIFI} [R00003] Sending packets 201-300
Wed Sep 28 10:39:18 2011 {WIFI} [R00003] Checking if the AP is still up...
Wed Sep 28 10:39:18 2011 {WIFI} Waiting for a beacon from SSID=[TestMe]
Wed Sep 28 10:39:19 2011 {WIFI} Beacon from SSID=[TestMe] found (MAC=[00:aa:bb:cc:dd:ee])
Wed Sep 28 10:39:19 2011 {WIFI} [R00004] Sending packets 301-400
Wed Sep 28 10:39:42 2011 {WIFI} [R00004] recv() timeout exceeded! (packet #325)
Wed Sep 28 10:39:42 2011 {WIFI} [R00004] Checking if the AP is still up...
Wed Sep 28 10:39:42 2011 {WIFI} Waiting for a beacon from SSID=[TestMe]
Wed Sep 28 10:40:42 2011 {WIFI} [!] The AP does not respond anymore. Latest test-case has been written to '/dev/shm/wifuzz-eK97nb.pcap'

The AP has been tested using the "auth" module (802.11 Authentication Request fuzzer). In this case, the AP has crashed after roughly 325 packets, and a PCAP file with all the generated packets since the beginning of the last fuzz round has been written to "/dev/shm/wifuzz-eK97nb.pcap".

Conclusions

We use WiFuzz in our daily activities, and it lead to the identification of some interesting wireless bugs. The tool is available here, and it is released under the GPL license. so feel free to contribute!