HackDig : Dig high-quality web security articles for hacker

«No Previous
No Next

Analysis of multiple vulnerabilities in AirDroid

2016-12-01 14:35
By: Simone Margaritelli
   Zimperium zLabs

Analysis of multiple vulnerabilities in AirDroid

Reported by: Simone Margaritelli
Security Researcher at Zimperium zLabs

AirDroid is a popular remote management tool for Android. It has an estimated user base of over 50 million devices according to the Google Play Store.
Our research highlights how insecure communication channels make millions of users vulnerable to Man-in-the-Middle (MITM) attacks, information leakage and remote hijacking of update APK which leads to a remote code execution by a malicious party. The attacker exploits the app’s built-in functionalities and uses them against its users.

Affected Products

DIY Cryptography and Insecure Communication Channels

AirDroid relies on insecure communication channels in order to send the same data used to authenticate the device to their statistics server. Such requests are encrypted with DES ( ECB mode ) however the encryption key is hardcoded inside the application itself (thus known to an attacker). Any malicious party on the same network of the target device could execute a man in the middle attack in order to obtain authentication credentials and impersonate the user for further requests.

A malicious party could perform a MITM network attack and grab the device authentication information as shown in the “Details” section from the very first HTTP request the application performs.
This HTTP request can be decrypted at runtime using the 890jklms key hardcoded inside the application and the authentication fields parsed from the resulting JSON.
Having this information, the attacker can now impersonate the victim’s device and perform various HTTP or HTTPS requests on its behalf to the AirDroid API endpoints.
For instance, a payload like the following ( encrypted in DES with the same exact key ) can be sent to the https://id4.airdroid.com/p14//user/getuserinfoviadeviceid.html endpoint :


The server will reply with the user information, including his email and password hash:


This is the output log of our POC bettercap proxy module:


Moreover, an attacker performing a MITM attack and redirecting HTTP traffic to a malicious transparent proxy, could modify the response for the /phone/vncupgrade request which is normally used by the application to check for addons updates:

GET /p14/phone/vncupgrade/?q=[DES ENCRYPTED PAYLOAD]&ver=20151 HTTP/1.1
Host: srv3.airdroid.com
Connection: close
User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)

Injecting a new update, thus remotely executing custom code on the target device, is just a matter of modifying this response:


To something like the following:


AirDroid will notify the user of an available update, download the RCE.apk package and eventually prompt the user for its installation on the target device.

AirDroid relies on secure HTTPS API endpoints for most of its functionalities, but during our analysis we’ve found that other insecure channels are used for specific tasks. For instance, the app sends statistics to http://stat3.airdroid.com as we can see in the com.sand.airdroid.configs.urls.ReleaseUrls class:


When using this endpoint, the application relies on DES encrypted JSON payloads in order to add a minimal layer of security. You can see in the com.sand.common.Jsonable object  is used as a base class for every JSON payload being sent to the stats server:


Once the buildParamQ is executed on the payload, the whole HTTP request will look like:

GET /phone/open/?q=[HEX ENCODED DES ENCRYPTED PAYLOAD]&ver=20151 HTTP/1.1
Host: stat3.airdroid.com
Connection: close
User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)

Unfortunately, being the key used for DES encryption hardcoded inside the APK you can see in the com.sand.common.DesCrypto class:

Despite its name, the sandDecrypt method reverses those numbers and hex decode them, returning the final encryption key: 890jklms

Once decrypted, the payload is sent to the stats server. Such payload looks like this:


The account_id, androidid, device_id, imei, imsi, logic_key and unique_id fields are used for every other API request, on HTTP or HTTPS, in order to authenticate the device and uniquely identify it.


  • Use only secure communication channels ( HTTPS )
  • Verify the remote public key ( key pinning ) in order to avoid SSL MITM.
  • For additional encryption, use safe key exchange mechanisms such as Diffie-Hellman instead of hardcoded encryption keys inside the app.
  • Leverage and verify digital signatures for update files.


  • Use Mobile Threat Protection solution like Zimperium zIPS to proactively prevent network tampering attacks and provide forensics to understand potential impact to employee device.
  • Uninstall or disable AirDroid until a fix is available.

Disclosure Timeline

  • May 24 2016 : Initial disclosure email sent.
  • May 30 2016 : Acknowledgment from vendor.
  • Aug 10 2016 : Follow up.
  • Aug 17 2016 : Follow up.
  • Aug 22 2016 : Follow up.
  • Aug 28 2016 : Follow up.
  • Sep 06 2016 : Follow up.
  • Sep 07 2016 : Got reply about new upcoming release.
  • Nov 24 2016 : Release 4.0 published, still vulnerable.
  • Dec 1 2016: Full disclosure


By: Simone Margaritelli
   Zimperium zLabs

Analysis of multiple vulnerabilities in AirDroid

Reported by: Simone Margaritelli
Security Researcher at Zimperium zLabs

Source: /diordria-ni-seitilibarenluv-elpitlum-fo-sisylana/moc.muirepmiz.golb

Read:7235 | Comments:0 | Tags:App Security Mobile security News Research AirDroid

“Analysis of multiple vulnerabilities in AirDroid”0 Comments

Submit A Comment



Blog :

Verification Code:


Share high-quality web security related articles with you:)


Tag Cloud