A Look at WeChat security

Original address: http://blog.emaze.net/2013/09/a-look-at-wechat-security.html

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

Introduction

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

As conversations be rapidly converging to IM applications, it's natural to start asking howSecureThis 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-start with WeChat, a popular mobile IM platform developed By the china-based Tencent Company. The choice of this specific application were quite arbitrary and mainly based on the fact, in this period, WeChat is P Ublicized 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 and we focused on the Android version only:according to Google Play, W Echat for Android alone have more than million downloads. Most of the issues discussed in this post should affect Android versions for WeChat up to 4.5.1. On August 5th, Tencent released version 5.0, which introduced some major changes; We still has to analyze this version in detail.

A Glimpse at the network traffic

The most obvious and easy thing-to-start with is an analysis of the network traffic generated by the application during n Ormal usage. At the This is 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 is seen from the figure, most of the traffic travels on TCP port 8080, typically reserved for HTTP connections (pre vious 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 is 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 was followed by a opcode-dependent message body, usually in encrypted form. Briefly, the first message is a encrypted by the application using RSA, with a hard-coded public key; Next messages is encrypted in AES. In WeChat versions up to 4.3.5 we identified several vulnerabilities which allow a 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 is immune to these attacks, but we still has to perform a more in-depth analysis of the ENC Ryption 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 is abused by attackers to steal sensitive information concerning a WeChat user Accou Nt.

In detail, WeChat reads debug settings from a Android contentprovider, identified by URI "Com.tencent.mm.coolassist.debug Provider/config ". This contentprovider was used by the application as a centralized source of debug configuration parameters, and can be Empl oyed to specify which debug messages should being logged to the Android console (adb logcat), to save log messages to the SDC ARD, and even configure aRemoteLogger.

From a security perspective, the remote logging feature are surely the most interesting one. By exploiting this functionality, an attacker can develop a malicious application which exposes the AFOREMENTIONEDCONTENTP Rovider and, through specially-crafted debug settings, makes WeChat to send logs to an external, attacker-controlled, serv Er. 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, Passwo RD hash and other details. As an example, this is an excerpt from a remote log session:

 the- the  -: +:Wuyi 594V/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 the- the  -: +:Wuyi 635I/micromsg.autoauth sending remote request, network.active=false the- the  -: +:Wuyi 666I/micromsg.autoauth.sceneinfoqueue inqueue:netid=0 the- the  -: +:Wuyi 691V/micromsg.sdk.synctask Sync Task Done,return=0, cost= About(wait=0, run= About) the- the  -: +:Wuyi 783V/micromsg.netstatwatchdog dkreport Status:9999002Nowcount:1Ret:1 the- the  -: +:Wuyi 810d/Micromsg.autoauth Account Info updated:accinfo:|-uin =-1893467821|-user =ukcd_ao03gex3y2731v|-session =|-pass =5f4dcc3b5aa765d61d8327deb882cf99|-pass2 =5f4dcc3b5aa765d61d8327deb882cf99 '-cookie =(NULL) the- the  -: +:Wuyi 885D/micromsg.netstatwatchdog Item.tobytearray ():433 the- the  -: +: the 101D/micromsg.gynet encoding,type=380, key=, Time=284 the- the  -: +: the 108I/micromsg.gynet sendimp Reqdata.len:866 the- the  -: +: the  theD/micromsg.netstatusutil Activenetinfo Extra=internet,type=0

As can is 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 (5F4DCC3B5AA765D61D8327DEB882CF 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 has been edited to prevent readers from hacking we account but, yes,5f4dcc3b 5aa765d61d8327deb882cf99 is the MD5 for string "password" and this was really we 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) and while others is used to set the log server addr ESS for the both 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 a 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. Functiongeneratekey () receives in input the three lines sent by the server and returns the corresponding DES key.

Import Hashlib def mangle (data): CharSet="0123456789abcdef"R=""     forCinchhashlib.md5 (data). Digest (): R+ = charset[(ord (c) >>4) & 0xf] R+=Charset[ord (c) & 0xf]returnrdef GenerateKey (line0, Line1, line2): Seed= line1[2:] Seed+ = str (int (line2[2:])) Seed+="DFDHGC"Key= Mangle (Seed) [7: +]    returnKey

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

As a final note, we would the ". com.tencent.mm.debug.log.mmlog.url.*" configuration keys is not s Upported by the latest version of WeChat (5.0). However, this version still queries the ContentProvider for debug settings and part of the logging functionalities has be En 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 Mechan ISM has simply been moved elsewhere.

Local Database Encryption

WeChat locally stores application data in an encrypted SQLite database named "Enmicromsg.db". This database was located in the "micromsg" subfolder inside the application's data directory (typically something like "/d ATA/DATA/COM.TENCENT.MM ").

The database is a 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 th Rough 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 are the value returned by the Android API Functiontelephonymanager.getdeviceid (). Follows a sample SQLCipher console session that demonstrate how the ENMICROMSG.DB database can be decrypted.

$ sqlcipher Enmicromsg.dbsqlite ' b60c8e4 ' ; SQLite> PRAGMA cipher_use_hmac = off;sqlite> . Schemacreate TABLE Conversation ( Unreadcount INTEGER, status INT, ... CREATE TABLE bottleconversation (unreadcount INTEGER, status INT, ... CREATE TABLE tcontact (username text PRIMARY KEY, Extupdateseq long, ...

It's also worth pointing out, as the key generation algorithm truncates the password to 7 hex characters, it would b E difficult for motivated attackers who is 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 it 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 B OTH 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 CO Nsiderations, as their application would probably rapidly become an attractive target for attackers.

A Look at WeChat security