BYPASSING SSL PINNING
- Layout for this exercise:
- Connecting Santoku to Nexux 5:
0 - INTRODUCTION
- SSL Pinning is an extra layer of security used by applications to ensure that the certificate provided by the remote server is the expected one.
- By storing the certificate or public key within the application, it is possible a comparison with the certificate or public key provided by the remote server.
- This technique allows the developers to specify what certificates are considered valid by the applications.
- Without SSL pinning, it would be possible to add one certificate to the custom certificate chain, and later to intercept all SSL traffic.
- SSL pinning prevents this from happening, because the certificate introduced by the user doesn't match the certificate embedded or "pinned" into the application.
1 - METHODS TO BYPASS SSL PINNING
- However, this client-side security measure can be bypassed by manipulating the application.
- Applications can be disassembled by removing or manipulating the certificate pinning, also switching the certificate embedded within the application with another.
- In the same way, there are some tools that automatically disable certificate pinning, like for instance the AndroidSSLTrustKiller, by ISECPartners.
- Denis Andzakovic published a paper on 2014 about the SSL Pinning on Android devices. The document can be found here .
2 - SSLPinningExample.apk
- The previous document provides the application SSLPinningExample.apk, very useful to test the bypassing process of SSL Pinning.
- SSLPinningExample.apk just performs an HTTP request to http://github.com, displaying the result of the request.
- In general circumstances, the HTTP response would be returned from Github.
- However, because SSL Pinning is enabled, in case of presence of a proxy like Burp, it would result in an SSL error.
- Once the test application is downloaded from the previous link, it is installed on the Android device:
3 - TESTING WITH BURP
- Burp proxy is enabled on the Android device:
- The proxy hostname corresponds to Santoku's IP (192.168.1.8), where the Burp suite is installed:
- Clicking the icon of the application:
- The user is prompted to test the application:
- Launching Burp and setting to "on" the interception, however nothing happens. The reason is that the application tries to verify the certificate, but not been recognized as the trusted one, the connection is not established.
4 - ANDROID SSL TRUST KILLER
- For the purpose of bypassing the SSL pinning, let's download to Santoku the application AndroidSSLTrustKiller, by ISECPartners:
https://github.com/iSECPartners/android-ssl-TrustKiller
- Installing AndroidSSLTrustKiller on Nexus 5:
5 - FINAL TEST
- Testing again the application SSLPinningExample.apk:
- Now, the HTTPS request connection to github.com is intercepted:
- Forwarding the request:
- Eventually, the mobile device receives the answer to the HTTPS request:
- The success of this final test is due to the fact that the application Android SSL TrustKiller is disabling the SSL Pinning embedded into SSLPinningExample.apk, what didn't happen at the previous test on point 3.
PATH TRAVERSAL VULNERABILITY
- Layout for this exercise:
- Connecting from Santoku to Nexus 5:
- The goal of this exercise is to perform a Path Traversal attack, aiming to access files and directories that are stored outside the root folder.
- By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations or by using complete file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files.
- This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”.
- For instance, let's try to read the content of a file, a secret KEY, stored at the SD Card of the mobile device:
- For this exercise, a vulnerable application will be used, by exploiting one of its Content Providers. The adobe.apk is referred to a reported vulnerability about a past Acrobat Reader version, at this moment already patched.
- The attack is based int the fact that the application allows to read files from External Storage, according to the established permissions, as it will be seen later.
- Installing the application into the mobile device.
- Now, let's make sure that Drozer is running at the mobile device:
- Also, let's forward port TCP 31415 so that a connection is established with Drozer between Santoku and Nexus 5:
- Launching Drozer:
- Searching for any package related with Adobe:
- Finding the attack surface for the application, there is a vulnerable Content Provider:
- There is just one Content Provider, so for sure it is the vulnerable one:
- However, querying directly into the Content Provider, the result is unsuccessful:
- Getting some information about the package, an interesting fact is found, because there is a READ_EXTERNAL_STORAGE permission associated to the package:
- Reading the Content Provider using the direct path of the application does not yield any result. The reason is because that path is not the complete path from the root of the file system:
- However, adding some backtrack directory traversals (../../), once the root of the file system is reached, the reading process is successful and the KEY is discovered:
- Let's take into account that Drozer applications does not hold the permission READ_EXTERNAL_STORAGE:
- So, it is important to notice that the attack has been successful due to the vulnerability of the Adobe Reader application, having available the permission READ_EXTERNAL_STORAGE, as seen before. In other words, the Adobe Reader cad read files from the SD card, but Drozer cannot.
