Analysis of multiple vulnerabilities in AirDroid
Edit: 11:02AM PDT: added exploit POC code below the disclosure timeline.
Edit2: 06:01PM PDT: edited timeline to reflect 4.0.0 and 4.0.1 release dates and confirming that both versions are still vulnerable.
Edit3: Dec 12th, 2016, 10:41AM PDT: edited timeline to reflect security testing on 4.0.2 and 4.0.3. version 4.0.3 is safer to use and we recommend to update your AirDroid application.
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.
- AirDroid <= 4.0 (latest version)
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
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
User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)
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.
- 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 28 2016: AirDroid 4.0.0 released, still vulnerable.
- Nov 30: AirDroid 4.0.1 released, still vulnerable.
- Dec 1 2016: Full disclosure
- Dec 6 2016: AirDroid 4.0.2 tested, uses SSL but does not enforce certificate pinning.
- Dec 12 2016: AirDroid 4.0.3 tested – uses SSL but does not enforce certificate pinning. main update RCE issue described above is now fixed!
Download the latest Bettercap modules from github (https://github.com/evilsocket/bettercap-proxy-modules).
AirDroid Information leak POC:
sudo bettercap -T TARGET_IP –proxy-module airdroid_info.rb –no-sslstrip
AirDroid RCE POC:
sudo bettercap -T TARGET_IP –proxy-module airdroid_rce.rb –no-sslstrip –httpd
For the RCE module to function properly, place an “update.apk” and “changelog.html” files in the current working directory.