TLS Client Authentication While Testing Applications

So what is TLS Client Authentication?

TLS client authentication is not a new concept by any means, it is simply rarely used in most web servers and web services that most applications utilize. Because of this most people won't be familiar with it when penetration testing applications. Put simply TLS client authentication is when the web server requires the user to present a trusted certificate to allow the connection to be established before any data is transmit. In essence this is just like when you setup key based authentication for your SSH connections.

If you would like to dive deeper there is a great overview at ABOUTSSL.

What challenges does TLS Client Authentication present a tester?

The obvious problem with testing an application that relies on TLS client authentication is that you cannot make requests to the web server/web services at all. This is a problem when intercepting traffic with a proxy such as the commonly used Burp proxy. For example, we recently tested a windows thick client application which had an embedded certificate that was used to authenticate to the web services. When capturing these requests in Burp, we didn't have that certificate to forward to the server and thus our requests were all rejected.

Fortunately, Burp has the ability to use a certificate bundle to present the client certificate to the web service and allow you to intercept traffic and proceed as normal. This can be found under the User or Project Options => TLS => Client TLS Certificates as shown below.

You will need to define what hosts the certificate is sent when attempting to connect and provide a full PKCS#12 bundle, or hardware token/smartcard (PKCS#11).

Okay but what if we aren't provided the client cert?

Naturally the easiest way to get these certificates would be to simply ask our client for a copy. However, this is not always possible especially if a client wants a more black box approach to their testing. Let's take our example application we tested recently it utilized client authentication, and we were not provided the certificate for this. This was a Windows thick client application so where might we start to try and obtain this certificate?

The answer is simple, we should check the processes memory to see if the certificate is retained and we are able to access it unencrypted. There are multiple ways to do this, but my favorite is to use a tool called Process Hacker 2. It provides a simple GUI for reviewing loads of information about the process you want to observe. Once you have loaded Process Hacker and found the process you need to inspect simply double click the process and navigate to the memory tab. There is a string search feature here which is super helpful in finding various things such as hardcoded passwords in memory, but in our case we want to find a TLS certificate.

Now we know how RSA keys are started with a line such as -----BEGIN RSA PRIVATE KEY----- or -----BEGIN PRIVATE KEY----- so this gives us a good starting point. We can just search on strings of a longer length to provide less results, since we know a key will be longer than at least say 20 or 30 characters. Then we can search within those results for "begin" to try and locate the certificate within memory. In our example application this worked and we discovered a private key! We also found the corresponding public key in memory, as well as other signing keys for encrypted information stored in a local database. Be aware that you may have to perform some trial and error to get the right combination of keys on an application you are testing if multiple are presented.

Now how do we use this private key?

We have our keys! As you will recall Burp only allows us to use a certificate in a PKCS#12 or PKCS#11 bundle. So how do we convert this private/public key pair into a proper PKCS#12 bundle for use in Burp?

Store both keys in a text file, I gave mine the .cer extension to easily keep track of which file is which, and then use a simple OPENSSL command to convert the two keys into a properly formatted bundle.

openssl pkcs12 -export -in {filename}.cer -out {outputname}.p12

Burp will require a password with your bundle so do not leave this empty.

In the below screenshot I first validate that I have entered my certificate correctly and OPENSSL can read it, then I execute the command to bundle them.

Now just add the exported bundle into Burp as shown earlier here.

Conclusion

So in summary while you may not see client authentication often, it is good to know how to handle it when it does come up. I strongly recommend saving yourself the headache and just asking your client for a certificate when you can, but in the event they can not/will not provide one, or maybe you are bounty hunting, there are options to retrieve this certificate.

If you found this tip helpful drop a comment below! We will release more pentesting tips in the future.

Are you looking for a security assessment for your network or applications? Send us an email at info@mccormackcyber.com