Thursday, December 22, 2016

ANDROID PT / Client Side Injection


- Layout for this exercise:

- Connecting Santoku to Nexus 5:

- The goal of this exercise is to inject a crafted SQL query to a database, so that the application yields the contents of the database due to the lack of proper input sanitization.

- Android mobile devices use SQLite as framework for local database storage, so let's install the application sqliteapp.apk into the mobile device:

- Clicking the icon of the application:

- The user is prompted to register:


- Registering a user:

- The valid user logins and his private details are displayed:

- With the purpose of bypassing the authentication proceses, let's disassemble the application with jadx and see how is written the source code:

- Running jadx over the application:

- A new directory is created:

- Going to the manifest to see what is the associated package:

- Moving trough the directory to reach the innermost folder of the package, the Java source code is found:

- Opening the connector to the database, there is a SQL instruction that takes credentials (username and password) from the user_records database:

- Now, taking advantage of the lack of input validation sanitization, let's try an "always true" SQL query.

- This SQL injection is based on the well-known fact that OR function yields TRUE whenever one the operands is 1:

0 OR 0 = 0
0 OR 1 = 1
1 OR 0 = 1
1 OR 1 = 1

- For instance: Joey1'or'1'='1'--

- The command injection is successful, because all the details about the user are displayed:

Wednesday, December 21, 2016

ANDROID PT / Bypassing SSL Pinning


- Layout for this exercise:

- Connecting Santoku to Nexux 5:


- 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.


- 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, 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:


- Burp proxy is enabled on the Android device:

- The proxy hostname corresponds to Santoku's IP (, 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. 


- For the purpose of bypassing the SSL pinning, let's download to Santoku the application AndroidSSLTrustKiller, by ISECPartners:

- Installing AndroidSSLTrustKiller on Nexus 5:


- Testing again the application SSLPinningExample.apk:

- Now, the HTTPS request connection to 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.

Monday, December 19, 2016

ANDROID PT / 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.