SSL Certificates

Generally, an SSL certificate is issued by a Certificate Authority or CA. A CA’s job, among issuing you a certificate, is to verify your identity. The CA is what vouches for you when other clients ask about how trustworthy you are. Once a certificate is issued by a CA, this is one mechanism in which they say “Yeah this guy’s shown us all his docs and we believe he’s legit so trust us when you see that his certificate is issued by us.” In the early days of public key infrastructure (PKI), obtaining an SSL certificate was quite a process. The process is a lot more straightforward now as you will see. But first, let’s talk about the three types of validation for HTTP certificates.

Self-Signed Certificates

Another quick way in which you can generate a server certificate is to issue one yourself. These are called self-signed certificates and can be generated by using OpenSSL. The command to do this and accompanying output are as follows:

> openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365

Generating a 4096 bit RSA private key

...............................++

...++

writing new private key to 'key.pem'

Enter PEM pass phrase:

Verifying - Enter PEM pass phrase:

-----

You are about to be asked to enter information that will be incorporated

into 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 blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) []:SG

State or Province Name (full name) []:Singapore

Locality Name (eg, city) []:Jurong

Organization Name (eg, company) []:Madison Technologies

Organizational Unit Name (eg, section) []:

Common Name (eg, fully qualified host name) []:www.redteamlife.com

Email Address []:[email protected]

> ls

cert.pem key.pem

>

The command openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 will generate a new certificate valid for 365 days. Pay close attention to the Common Name. This is the name of your domain which you want the certificate issued for. At the end of this process, you will see a certificate and private key which you can then take and use in your web servers and so on. However, note that if you try to access a web server that has a self-signed certificate, your browser will likely show you an error or warning screen such as the one in Figure 9-2. If you click the “Not Secure” portion, your browser will show you more information about why the certificate was not trusted in Figure 9-3.

Getting a DV Certificate

To get ourselves a DV certificate, we’re going to use Let’s Encrypt [https://letsencrypt.org/]. Let’s Encrypt is a nonprofit CA that provides DV certificates for free. The service itself is provided by the Internet Security Research Group that had board members and technical advisors from many of the large companies such as Google, Facebook, and Akamai and from other groups such as the ACLU and EFF. The entire process is automated as we will see shortly. For the issuing of a DV certificate, remember that we have to prove that we own the domain name and the server it is running on? This also means that we need to have a domain name and a server to run it on that can be publicly accessible. If you want to follow along, that means you will need a public IP that is configured on a server or workstation of yours that you have access to. I used DigitalOcean [https://www.digitalocean.com/] and quickly spun up a Debian Linux virtual machine or droplet to run this test. You could also choose to use Ubuntu which is based off of Debian. For the demo, I am going to use my domain name called redteamlife.com and will apply for a subdomain name certificate: aas2.redteamlife.com. OK, let’s get started.

Answer yes to when it asks if you want to continue and wait for nginx to be installed. At this point, I am going to assume your domain name is pointing to the IP address of the server that is running the nginx server. Test your nginx server to see if it is reachable by entering your domain name in your browser. You should see something that resembles Figure 9-4.

Now we need to use the Certbot to generate our certificate.

Certbot

Certbot [https://certbot.eff.org/] is the EFF’s automated certificate generator. The best way to get a certificate quickly and painlessly, in my opinion, is to use a popular Linux distro with shell access. The reason I say use a popular distro is because the Certbot instructions are a lot easier to follow and generally more precise.

Having stated this, I am aware that getting Certbot up and running well can be a little bit tricky. Here is a list of key points that you need for getting Certbot up and running fast:

1. 1.

   A server with a public IP address

    
2. 2.

   A domain name purchased and correctly pointing to the IP address from point 1

    
3. 3.

   Ports 80 and 443 open on the server from point 1

    
4. 4.

   Ability to install and configure a web server properly (e.g., nginx) and pick a server operating system where you can install nginx smoothly

    
5. 5.

   There are specific instructions that can be found in the Certbot website that gives you a very good combination of web servers and operating systems to choose from. For further information, you can visit this URL: https://certbot.eff.org/instructions.

    

On the Certbot page, select which web server and operating system that you use. Figure 9-5 shows you what that looks like. I have selected nginx and Debian 10 to match my setup.

I’m going to save you from having to look at any more screenshots for this, but I followed the instructions as stated and ended up with my certificate and private key file like from the preceding openssl example. Let’s Encrypt will usually write your certificates to /etc/letsencrypt/live.<domain name>/.

The Back End

We could technically conduct our demo by using the nginx web server that we just installed and requested a certificate for, but I want to show you a bit more on how API communications will look on the wire, so let’s go ahead and write a back end. I will give you the basic blueprint of the back-end server so you can implement it in the language of your choice. I chose Golang (https://golang.org/) and we will look at the source code later on. You can download the source code here: https://github.com/sheran/aas2-ch09-go_backend.

Note that you will need both the certificate and private key file in the directory that you run this file from.

Android Client

Similar to how we did in Chapter 3, we’re going to build a very basic Android client that has just one purpose – to capture our input and send it to the back-end api, receive a response, and print it out on the screen. In Android Studio, start a new Android Studio Project and then pick the one with an Empty Activity. Name it accordingly as you would want to (refer to Chapter 3) and let's design a UI.

Here’s my design in Figure 9-6.

I am just going to give you my strings.xml, activity_main.xml, MainActivity.kt, and NetUtils.kt source here. These are the files necessary to build the app. You can find the full source code to this client here: https://github.com/sheran/aas2-ch09-android_client_1.

After building and running, you should be able to interact with it and see either error or success messages being displayed like in Figure 9-7.

Testing SSL Traffic Interception with Burp Suite

We are now ready to see if we can intercept traffic from between our client app and our back-end server. First let’s fire up Burp Suite and then install its certificate on our Android device. For this demo, I’m using the emulator. Go into the Proxy upper tab, then Options lower tab. Then select Import/export CA certificate, and in the resulting dialog, select Export ➤ Certificate in DER format as shown in Figure 9-8. Then select a location, name the file, and save it.

Now we have to install it on our Android device. So, on the device, go to Settings ➤ Security and Location ➤ Encryption & Credentials ➤ Install From SD Card. In the file browser that pops up, navigate to your Download folder and select the certificate as shown in Figure 9-9 and then proceed to name it and install it as shown in Figure 9-10.

Doing this will tell the device to trust any server certificates that are signed by the Burp Suite CA certificate. Now, we have to route all our traffic from the device to Burp Suite so it can relay that data to the server and effectively become our man in the middle. To do this, go to Settings ➤ Network & Internet ➤ Wifi and then select AndroidWifi (if you’re using an emulator) or the network that you are currently connected to. Make sure that both your Android device and Burp Suite are connected to the same network so that they can easily send traffic back and forth. Remove any firewalls between the two devices if any, for example, if you have any antivirus software or something like either Little Snitch for MacOS X or iptables on Linux. Modify this network as shown in Figure 9-11, and in Proxy, select Manual and then fill in the IP address and port of your Burp Proxy. In my case that is 192.168.69.42:8888.

One more thing, switch off your mobile data on your Android device. This is because Android will use this as a backup in case it detects something unusual with the Wi-Fi connection, for example, it detects a fake certificate. OK, I think we’re ready to test SSL traffic interception! Fire up the client app and enter some codes and click submit.

Two things may happen at this point. First, you will see the SSL traffic in Burp’s Proxy section. Or second, the app will crash. When I first did it, the app crashed on me. So I did a little further digging, and I found that since Android version 7 (API 24), the engineers over at Google have reconfigured how trusted Certificate Authorities handle CA certificates. There is a link to a blog post here: https://android-developers.googleblog.com/2016/07/changes-to-trusted-certificate.html. What does this mean for us? Well, it means that even if we add user CAs (like we did) to our Android device, an app has to specifically opt in to work with that user CA certificate – the premise being that if we were able to add it to the device, we should also be able to add it to the network security config. Turns out, though, that we actually can! But we need to play around with the APK first a little. Let’s do that now.

Lastly, install it on the device and test again. This time, it should work just fine, and you will be able to see SSL traffic flowing back and forth as shown in Figures 9-12 and 9-13. Now keep in mind, this is for an app that hasn’t had SSL Pinning implemented. So, let’s build in some SSL Pinning into our app.

Adding SSL Pinning

If you put that into your app and repackage it with APKTool and test it, your app should crash.

Lines 19–39 and 48 are different as you can see in the code in bold. What we’re doing here is storing the certificate from our server aas2.​redteamlife.​com in the app. Then, we read it and add it to a KeyStore and then use that KeyStore to initialize a TrustManager which we then pass on to an SSLContext. Then, the SSLContext is passed to our HttpsURLConnection. In this way, the TrustManager will ensure that it can verify all certificates against the one we included and pinned. Now when I test the new client, my app crashes right away. There are a few points here to keep in mind. First is on the pinning side. Generally, it is a better idea to pin a public key as opposed to an actual certificate like we have done. This is because when a certificate gets renewed, its public key still remains the same. Thus, each time we renew a certificate, it wouldn’t mean we have to make a code change on our client. So it’s always better to pin a public key. I will show you that later in the chapter. The next point to consider is the continuation. You have a choice with what to do when your certificate pinning validation fails. If the exception is thrown, then you know that something fishy is going on and at that point can take action. Would you continue with lesser features or would you completely stop? In my opinion, it is better to completely stop communications until the certificate issue has been resolved. In our case, we’re failing fairly inelegantly. You could choose to notify the user that there’s an issue with the server certificate or even just fail with a generic error message. With that said, let’s move on to the real reason you’re here, breaking SSL Pinning.

Breaking SSL Pinning

The TrustManager, as its name implies, plays a pivotal role in ensuring that server certificates are trusted. If you look at the TrustManager class or rather the X509TrustManager, which is the subclass most often used, you can see three public methods: checkClientTrusted(), checkServerTrusted(), and getAcceptedIssuers(). We are most interested in the checkServerTrusted() method which we want to render nonfunctional. There are possibly many ways to do this, but hooking this function and rewriting it is probably the cleanest way. We would use a tool like Frida in this case to load a script that has our own implementation of the X509TrustManager.checkServerTrusted() method. But we can take a shorter cut. Essentially, the easiest way is to create our own TrustManager which is empty and then send that into the SSLContext’s init method by hooking it. Since our TrustManager has no actual checks in place, we should be able to get past the SSL Pinning in this case. So, let’s try that out.

We get dropped into the Frida shell, but we will notice that our emulator just started up our app. So let’s go ahead and test it now. Bam! SSL Pinning is broken on my emulator. A quick peek at Burp Suite verifies this as I see the data going in between my client and server (Figure 9-14).

I would like to quickly revisit the topic of the way Android 7 and above handled Certificate Authorities. If you recall, we used Network Security Configuration to trust all our user certificates. There is another way, however – again, by using Frida. But to do that, we have to dig into the Android source a little bit. Google decided to fork OpenSSL and write their own library called BoringSSL [https://boringssl.googlesource.com/boringssl/]. They use the BoringSSL library in their own projects Google Chrome and notably Android. Android’s implementation of BoringSSL is through Conscrypt [https://source.android.com/devices/architecture/modular-system/conscrypt]. Conscrypt is a Java Security Provider used in Android together with the BoringSSL native library to provide Android’s cryptographic functionality such as ciphers, key generation, and message digests. It also provides Android’s TLS implementation. Since there are many common functions with OpenSSL, let’s take a quick look at how OpenSSL does its certificate verification.

OpenSSL allows you to set a verification callback function from the functions SSL_CTX_set_verify or SSL_set_verify. The difference being the former works for all ssl objects derived from a single context, ctx, and the latter works only on the ssl object that it is called on. What both functions do is call your user-defined verification callback function when it is time to verify a peer certificate. You can find out more about these function calls on the OpenSSL website here: www.openssl.org/docs/manmaster/man3/SSL_CTX_set_verify.html. I am bringing this up because BoringSSL and Conscrypt make use of a similar function. If you look at the embedded Android Conscrypt code, especially in the class com.android.org.conscrypt.NativeCrypto, you will see a similar SSL_set_verify method which calls the underlying native BoringSSL library. Figure 9-15 shows how Android Oreo handles its certificate verification.

then we can easily avoid the pesky issue of having to add a new network_security_config.xml file that asked Android to trust all user-added certificates.

Other Pinning Techniques

This list comes from the Frida codeshare script frida-multiple-unpinning.js found here: https://codeshare.frida.re/@akabe1/frida-multiple-unpinning/. Frida’s codeshare section is an open platform where users can submit their own scripts. Then by using Frida’s “—codeshare” switch, you can use these scripts without having to download them. If you look further on codeshare, you can see a whole slew of scripts dedicated to removing SSL Pinning. It is important to take note that these scripts usually show up when a new pinning mechanism has been found. That goes to show you that in general, reverse engineers are always going to come out on top. Tools such as obfuscation, moving code to native libraries, and such can act as a deterrent and possibly slow down a reverse engineer. But if there is determination and time, in the end, your app is bound to succumb to the attacks that are thrown at it. This isn’t meant to discourage you but serve as a warning that it is best to not expose as much code or data as possible and hope that the security tools solve the problem.

I’ve made the changes bold so you can clearly see what we are doing. We have two new functions called trustedChain and validatePinning. trustedChain will pick up all the certificates from the server and then run it through its own X509TrustManagerExtensions check. The difference between the X509TrustManagerExtensions and plain X509TrustManager is that the checkServerTrusted method will verify and also return the list of certificates to the caller. If it cannot, then the method will throw an SSLException. If it can verify, then it gets verified by the validatePinning method to see if one of the certificates has a matching public key hash that we compare with. If this also fails, then again an SSLException is thrown. If it passes, the connection proceeds as planned.

The preceding piece of code isn’t mine, but I did translate it into Kotlin from Java. The code itself was featured in a blog post by Matthew Dolan here: https://medium.com/@appmattus/android-security-ssl-pinning-1db8acb6621e. In this post, he also provides a few other mechanisms of SSL Pinning. It is highly worth a read. If you notice this code, it doesn’t actually conform to any of the present SSL pin-breaking mechanisms we have with Frida. I am not a fan of security through obscurity, but if you wanted to further hide what this class was doing, you could rename the methods and fields, but a reverser will always be able to find it through the exceptions. You could then possibly roll your own exceptions, but again, it’s a case of following the breadcrumbs. Lastly, you could obfuscate all of that, but then on a rooted phone, a reverser could trace all the native calls and work backward from there. As discouraging as this sounds, only the most determined reversers with something to gain will go after you. Usually, the current mechanisms for protecting apps in the form of obfuscation are sufficient for the drive-by hackers. You can find the TrustManager pinning client source code here: https://github.com/sheran/aas2-ch09-android_client_2.

Summary

In summary, it is important to keep in mind that your app is effectively a showcase for your code and data. It’s just a more structured way of sending out your intellectual property to the world. Your app will be installed on many mobile devices, and a percentage of those will very likely be hostile. Your goal should be to first limit the amount of exposure by reducing what you release in your app, whether it is code or data. Then, if there are parts that you must lock down with obfuscation, do so. SSL is nonnegotiable of course. Always implement SSL Pinning so that even a drive-by hacker can’t see client and server data exchange. But always be prepared that they will be able to see this data and take steps accordingly. Like I said in my first edition, a healthy dose of paranoia when developing your app will serve you well.