Hot Topics
Security Bloggers Network 
SBN

Intercepting Android

by Jonathan Armas on October 22, 2019

Android is an operating system based on the Linux kernel and used by
mobile devices such as smartphones and tablets. Due to its popularity,
it is the major target for hackers. One of their common techniques is to
intercept and try to break an app’s web traffic using attack methods
like fuzzing and brute force.

Mobile applications usually share the same communication structure as
web applications, meaning that we can intercept requests by using a
proxy. If an application is using a secure channel like HTTPS, we are
going to have to install a digital certificate into the phone in order
to make it accept our proxied requests.

Since Android 7 Nougat (API
>= 24)
we can no longer use the simple method of setting our proxy and the
certificate to capture HTTPS traffic as the Burpsuite page explains
here.
If we try this method, we will receive thousands of certificate failures
from our proxy. This is because the Android operating system no longer
trusts certificates installed by the user.

To solve this we need to have a rooted Android smartphone, then create
and sign a digital certificate, and finally put it in the system’s
certificate folder in our phone.

In order to intercept the application’s traffic we are going to need
some tools. The tools that we are going to use are:

Creating the certificate

So what is a TLS CA certificate? When you communicate with a third
party using a secure channel like HTTPS, the SSL (Secure Socket
Layer) protocol and the TLS (Transport Layer Security) protocol
include a security measure called digital certificates that implements
asymmetric encryption by using a private and public key.

In this protocol, a public key is signed by the CA (Certificate
Authority) using their private key. This way a certificate provides a
link between the public key and the CA that signed that key. The
following process is how a connection works:

  1. The browser connects to the server using a secure protocol.

  2. The server responds with the digital certificate containing the
    server’s public key.

  3. The browser looks to see if the CA from the certificate is
    included on its trusted list of CA’s. This is where we will work.

  4. Once the browser verifies that the CA from the certificate is in
    its trusted list of CA’s, it uses the public key provided in (2)
    to create a session key.

  5. Finally, the browser and the server encrypt data over the connection
    using the session key.

Having a CA-issued digital certificate with its public keys stored on
the trusted list indicates to a cellphone that it can “trust” the
proxy HTTPS responses. Without this, we cannot intercept secure
channel traffic. As we don’t have a CA we are going to create a
self-signed one.

First, we generate the certificate with 3650 days of validity and using
a SHA256 hash. It will also request some information. We can put our
personal/company information here or leave it blank:

Generating the certificate.

OpenSSL req -x509 -days 3650 -nodes -newkey rsa:2048 -outform der -keyout fluidattacks.key -out fluidattacks.der -extensions v3_caGenerating a RSA private keywriting new private key to 'fluidattacks.key'You are about to be asked to enter information that will be incorporatedinto your certificate request.What you are about to enter is what is called a Distinguished Name or a DN.There are quite a few fields but you can leave some blankFor some fields there will be a default value,If you enter '.', the field will be left blank.Country Name (2 letter code) [AU]:COState or Province Name (full name) [Some-State]:AntioquiaLocality Name (e.g., city) []:MedellinOrganization Name (e.g., company) [Internet Widgits Pty Ltd]:Fluid AttacksOrganizational Unit Name (eg, section) []:Fluid AttacksCommon Name (e.g., server FQDN or YOUR name) []:Fluid AttacksEmail Address []:[email protected]

After generating the certificate, we have to convert it to PEM in
order to import it into the phone, and DER to import it into burp:

Converting the cert.

OpenSSL x509 -inform DER -outform PEM -text -in fluidattacks.der -out fluidattacks.pemOpenSSL rsa -in fluidattacks.key -inform pem -out fluidattacks.key.der -outform der

Finally, we export our key into a PKCS8 file in order to import it to
burp:

Modifying for burp.

OpenSSL pkcs8 -topk8 -in fluidattacks.key.der -inform der -out fluidattacks.key.pkcs8.der -outform der -nocrypt

Once we have all the files, we need to start configuring our phones.

Configuring Android

The certificates installed on the phone follow the name HASH.0; so we
need the hash of the certificate:

Getting the hash.

OpenSSL x509 -inform PEM -subject_hash -in fluidattacks.pem | head -1

After getting the hash, we create a copy of the certificate with that
hash in the name. For example, something like 49ef1764.0:

Renaming for Android.

cp fluidattacks.pem <HASH>.0

Then, we need to upload our certificate to the phone. We can do it
manually by connecting the phone and moving the file into a folder or
with the following command using adb:

Uploading the cert.

adb push <HASH>.0 /data/local/tmp

Once the file is in the phone, log in as root, remount the folder
/system with read and write permissions (it is not mounted with those
permissions by default), copy our certificate to the
/system/etc/security/cacerts/ folder and change its permissions and
ownership to 644 and root:root:

Setting the cert.

adb shellphone$ suphone# mount -o rw,remount /systemphone# mv /data/local/tmp/<HASH>.0 /system/etc/security/cacerts/phone# chmod 644 /system/etc/security/cacerts/<HASH>.0phone# chown root:root /system/etc/security/cacerts/<HASH>.0

The last thing left to do is to restart our phone to load our changes:

Restarting.

phone# reboot

Once we turn the phone back on, our certificate will be installed on the
system’s trusted credentials tab and the phone will accept the responses
of our proxy.

Android certificate

Figure 1. Android certificate

Configuring the Proxy

Now we need to set our proxy in order to use our certificate. Open
Burpsuite and create a new project. Then move to the Proxy tab and
open the Options tab.

Burp options

Figure 2. Burp options

The next step is to import our certificate by clicking on Import / export CA certificate, then selecting Certificate and private key in
DER format, and choosing our fluidattacks.der and
fluidattacks.key.pkcs8.der files that we previously created.

Import DER

Figure 3. Import DER

Choose file

Figure 4. Choose file

Now, we need to set our proxy in our phones. Go to WiFi settings,
select a shared connection between the phone and the computer; we can
use the same network that our computer is connected to or use our
computer as a mobile hotspot to share it with our phone. Then, expand
the Advanced options, set the Proxy to Manual and input the IP
address and proxy’s port.

Android Proxy

Figure 5. Android Proxy

We are now capturing secure channel requests made from our phone
applications and browsers without having problems with certificate
failures.

Capture

Figure 6. Capture

If we want to have less default traffic on our proxy, we can again
modify the WiFi settings of our phones and fill-in the Bypass proxy
input with the following domains:

Default traffic sites.

*.google.com*.googleapis.com*.gstatic.com

Recent Articles By Author
More from Jonathan Armas

*** This is a Security Bloggers Network syndicated blog from Fluid Attacks RSS Feed authored by Jonathan Armas. Read the original post at: https://fluidattacks.com/blog/intercepting-android/

Jonathan Armas