Is detecting mobile compromise a losing game?
Detecting mobile compromise is not easy. Mobile OSs put heavy restrictions on what can be done by an app or analysis tool. Even though the intention is good, it limits the available options for blue team engineers to evaluate and protect the device. Over the years sophisticated tools like MagikHide, LibertyOS, HideJB, etc have found ways of masking root & jailbreak making detection even harder.
The old way
This is where it starts. A compromise leaves traces of evidence. This includes the presence of su/busybox/privileged apps, etc. Even though the mere presence of these tools doesn’t necessarily mean a device is compromised, it’s a good place to start an investigation. Similar checks look for installed apps, system configs, boot loader lock states that indicate a device might be compromised. Then came tools like Magisk, LibertyOS, Zygisk and made detecting the above traces very difficult if not impossible.
The new way
The next iteration of detection methods try to detect these new tools. This made the detection logic tool specific but important nonetheless. These hiders are easy to install and use. Ordinary folks with limited technical knowledge are capable of using them to bypass root detecting apps. There are numerous forums on XDA discussing the various ways to bypass restrictions levied by banking apps, games & other licensed apps.
The future
With the advent of a hardware-backed trusted execution environment, the tide is turning in favor of blue team engineers. TEE is a special environment that’s separate from the operating system both physically and logically. There is a dedicated hardware chip tasked with storing key material securely. Compromising this environment is very hard! Google’s Pixel phones come with Titan M. Code executed inside this chip is considered safe. An attacker needs to compromise both the OS and this chip to be able to bypass the root. To this day there are only two vulnerabilities found (CVE-2021-0449 & CVE-2021-0453). iOS has something equivalent called Secure Enclave.
From the application side, we will need to generate a keypair and store it on the dedicated chip. The generated key material contains metadata about the operating system state. This piece of information reveals whether a device is rooted or not. Let’s see this in action.
- Obtain randomly generated nonce from the server
- Use a KeyStore object’s getCertificateChain() method to get a reference to the chain of X.509 certificates associated with the hardware-backed keystore.
- Check each certificate’s validity using a X509Certificate object’s checkValidity() method. Also verify that the root certificate is trustworthy.
- On a separate server that you trust, obtain a reference to the ASN.1 parser library that is most appropriate for your toolset. Use this parser to extract the attestation certificate extension data, which appears within the first element of the certificate chain.
- Compare the extension data that you’ve retrieved from your ASN.1 parser with the set of values that you expect the hardware-backed key to contain.
The above steps are adapted from the official doc from here
Below is the output from the server side. It’s from a rooted Android 12 Pixel 3a device
As you can see, there is a “Root of Trust” block that has four properties under it. The most important line is device locked & boot state. These values should be true & VERIFIED for non-compromised devices. There are many more checks that the server needs to complete before fully trusting the device. These include checking for certificate validity (including revocation status), attestation security level (indicates whether the keypair is generated on hardware-backed TEE). Software backed keypairs are not as secure as hardware-based ones. This doesn’t mean the device is compromised. We can only be neutral or possibly categorize it under “not trusted” if we are operating under stricter requirements.
For comparison, here is the extension data for non-rooted Android 10 device.
Conclusion
The discussed methods are implemented in Pwned Report. Be sure to give it a try!
