Reported by: Simone Margaritelli
Security Researcher at Zimperium zLabs
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.
Background
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.
DIY Cryptography and Insecure Communication Channels
Summary
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.
Impact
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.
Details
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:
Mitigations
Recommendations
Disclosure Timeline
Exploit POC
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.
By:Simone Margaritelli
Follow Simone Margaritelli (@evilsocket) Zimperium zLabs
Follow Zimperium zLabs (@zLabsProject)
Reported by: Simone Margaritelli
Security Researcher at Zimperium zLabs
