Android and SSL
For several months, we have been looking at the risks and precautions to take regarding the use of mobile devices (smartphones and tablets running iOS, Android, Windows Mobile, BlackBerry OS, etc.), as well as the security of applications on these environments.
This work involves, in particular, adapting our approaches and developing suitable tools to evaluate a mobile application – including in black box or via reverse engineering (whether the purpose is penetration testing, application auditing, code review or analysis of a suspicious application).
In the specific case of dynamically analyzing an Android application, our initial approach was to use an emulator that passes through a local proxy (ZAP, Burp, WebScarab or other), in the same way that we might do for a classic web penetration test.
We quickly encountered an SSL outage problem, as Android did not recognize the proxy certificate.
Android applications encountering exceptions of this type generally consider that internet access is unavailable or simply quit.
Google's operating system, however, has an internal certificate store that allows it to accept SSL connections from trusted sources (/system/etc/security/cacerts.bks).
We therefore attempted to extract it and insert our proxy's root certificate, which, in theory, should have allowed us to observe HTTPS traffic. However, the system needs to reboot to recognize the new certificate, but Android has a mechanism for managing the integrity of its certificate store and removes manually added certificates at each startup, thus rendering the maneuver ineffective.
During our research, McAfee then published a white paper describing how to bypass certificate verification during SSL communications on Android![1]
HTTPS connections in the Android API are usually made by instantiating one of the following objects:
- org.apache.http.impl.client.DefaultHttpClient ;
- javax.net.ssl.HttpsUrlConnection ;
- android.webkit.Webview.
Two methods are then proposed to bypass the certificate validation step:
- We have the source code: we manually insert Java code allowing us to bypass the certificate validity check;
- The source code is not available, in which case the application must be disassembled and the same code inserted before recompiling the application.
Regardless of the method used, we obtain a "patched" version of the application that no longer checks the validity of SSL certificates.
The major disadvantage lies in having to perform these manipulations manually, potentially for each application tested.
Since we were not certain of having the source code of the applications to be analyzed, we therefore opted to modify the code after decompilation.
Apktool[2] is used for decompiling and recompiling the application, and the code proposed by McAfee is inserted into the application code.
We therefore wrote a Python script "intrinsec-android-ssl-patch" (intrinsec-android-ssl-patch @googlecode), which automates the following actions:
- Decompiling the application;
- Insertion of decompiled files allowing bypassing of the verification within the application;
- Searching for calls initiating HTTPS connections and inserting the bypass code;
- Recompiling the application;
- Reinsertion of the original application's resources (images, layouts, etc.), which may be affected by decompilation operations.
This tool automates the bypassing of SSL certificate verification during HTTPS exchanges in Android applications.
Since observation, interception and replay of issued requests are the major actions of application analysis, the use of this tool on the applications to be tested should allow for the performance of complete tests.
Feel free to contact us if you have any comments or would like to discuss this topic!
Thanks to Marc Lebrun for his research and script development!
