So, to start things off: Yes, I do know that #1 Android exists and #2 I can do a little bit of Android when the starts align.

This week in a fit of craziness, I engaged in an opium-hazed adventure through Android OS and trying to figure out exactly WHY you can’t use endpoints with enterprise-issued certificates on Android OS. We ALL know that for the most part you can’t do it on Android based on their progressive security changes over the last few years. I’m going to cover how I evaluated things end-to-end.

How Android Certificate Trust Works Today

It took a bit of confusion to work through, but basically this is how it works today.I’

We have a file at the root called the AndroidManifest.xml that imparts essential information about the application. I’m not going to go too deep into what the AndroidManifest.xml does, but I want to call out a key declaration:

android:networkSecurityConfig="@xml/network_security_config"

The network security configuration is how the Android application defines custom network security settings in its own configuration file. You might ask why do I care? The reason why it matters is because of some changes over the years in Android OS, you need to declare what stores it will trust on Android to validate certificate chains. An example of one of these files can be seen below:

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <debug-overrides>
        <trust-anchors>
            <certificates src="user" />
        </trust-anchors>
    </debug-overrides>
    <base-config cleartextTrafficPermitted="false" />
</network-security-config>

Basically, this configuration file says “we can use the user certificate store as an extension of our trust” and “we do not allow HTTP.” So this helps us understand exactly how certificate validation works on Android.

What you also need to be fully-aware of is the heavy reliance on a complete certificate chain on Android. That means your certificates need to look like this:

-----BEGIN CERTIFICATE-----
Server Certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Intermediate Certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Root Certificate
-----END CERTIFICATE-----

I tend to rebuild my certificates from the ground up to ensure that happens. First, we rip apart the PFX and get the vital pieces like I talked about in an old article:

openssl pkcs12 -in uag.pfx -nocerts -out uagkey.pem -nodes
openssl pkcs12 -in uag.pfx -nokeys -out uag.pem
openssl rsa -in uagkey.pem -out uagkey.key

Next, we edit the pem file and add in root certs into it like we mentioned above. Once that is done, we re-package the PFX:

openssl pkcs -export -out uag.pfx -in uag.pem -inkey uagkey.key -certfile uagroot.cer

Now that we covered all of that, let’s move onto how we can pull the APK off my Android device.

Using Android Studio and the SDK to Pull APKs

We start our fun little analysis process by using Android Studio, which is an Android development application, which is also used for log capture and many other interesting capabilities. We will start by using ADB, which is a very cool command-line tool to help you pull a live APK off your device. This is especially important because people love “blaming AirWatch” for EVERYTHING that goes wrong. It’s much harder to blame AirWatch aka Workspace ONE when you have the ACTUAL APK. Let’s check the video out for more:

So that was pretty easy! If you’re interested in ADB, I like this article on ADB to detail the other ways you can use it. Now, we have a pretty little APK, and we can continue on by decoding that APK so its usable.

Decoding APKs Via the APK Tool

Once you have your mystical APK, you should go grab the APK Tool. As I mention in the video, you can easily follow the steps to install it:

1. Download the APK Tool here.
2. Rename the JAR file to apktool.jar
3. Download the APK batch file here
4. Drop both files into C:\Windows

Once that is done, you can watch the video and follow the steps to decode your APK so you can easily work with it. It’s impressive how simple it is.

Now, you have a decoded folder with all of the binaries/config files/etc. of your APK and you can start the exploratory process. You will notice with every step that it is much easier than you would think.

Reviewing the APK Code to Learn Something Valuable

Now, you have a collection of workable items. You can see the folder structure below:

You will learn as you see in the video that many of the files that matter in the res/xml folder, which can teach you quite a bit about how the application itself is constructed. The brilliance is you don’t need to be a developer. You just need to be a detective!

Now, you have a better understanding on my journey this week and trying to understand how the app actually works. All UEM/Modern Workplace foundationally is about an understanding into data flow.

Final Thoughts

A large part of being in the mobility/UEM/MDM/abcdefghijklmnopqrstuvwxyz field is being an investigator. We try to understand how A+B=C. To be truly great in IT, you need to get more comfortable with reading developer documentation and APIs.

People are not going to do your job for you. When stuff doesn’t work, we need to look at what is known in the equation and solve for the missing variables. So like we learned today: Android + Internal CA = Epic Fail. We don’t know why it fails, so we try to figure out how an Android application validates a certificate chain. We know we see a basic error like this:

2021-08-19 13:03:55.589 27083-3978/? I/X509Util: Failed to validate the certificate chain, error: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.

Now, we figure out why the trust anchor is missing. Today, we validated how the application checks its trust chain and what stores it checks them against. We are always solving for the missing variables. This is who we are at our core. So, get investigating Sherlock!