Multiple vulnerabilities on Sitecom devices

0 comments
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

1 comments
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 <cheffner@tacnetsol.com>

  ----------------------------------------------------------------
-=[ 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.