Fri 20 May 2022
If by any chance you are dealing with Android pentesting and you have not already met Apktool, then know it is a tool for reverse engineering 3rd party, closed, binary Android apps. It is a very useful tool, as it allows you to edit and debug an Android application, it provides access to the Smali code of the app, decodes the resources so they are readable and finally it can rebuild the app after the changes are applied. Back in 2017 Raul Siles created a feature request for adding an option to Apktool, that would allow to automatically add a more generic/permissive network security configuration file while building an app. Given that this was not implemented yet, I considered it a good idea and a nice contribution towards this great tool, so I made it.
This article goes through an example application with a network security config and shows how the new flag of Apktool can be used to bypass this. The commit with the new flag can be found here.
The network security configuration is a feature added from Android API 24(Nougat) and onward. It allows apps to customize their network security settings in a safe, declarative configuration file without modifying the app code at all, but by just add a new line in the AndroidManifest file. You can check the official page here for more information on what can be done using the network security configuration and how easy that is.
Example Case
Lets take an example application in which the developer has enabled SSL Pinning. In that application the developer has done two things, first the actual network configuration file was added as shown below:
Do note that the name of the file is not the default one "network_security_config.xml" but it is modified. This is intentional so it can be seen that the new flag of Apktool is independent of the naming of the file. The second step of the developer was to declare that in the AndroidManifest file:
Running the application in our device it should work properly, unless there is an attempt to intercept the traffic between the app the the server it contacts. Setting up the proxy looks like this:
Using now the application and checking the logcat the following line stands out:
04-02 13:56:44.864 3134 3134 I System.out: An error of type javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found. happened: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.There is an exception occurring which is the result of the SSL Pinning that the developer implemented. This is an obstacle while trying to debug/pentest the application and using the new flag of Apktool, the process of substituting this network security configuration file with one that tells the application that it can trust all the user and system certificates, becomes trivial.
Using the help command -advance the description of the new flag -n can be found saying -n,--net-sec-conf Adds a generic Network Security Configuration file in the output APK.
Using that flag during rebuilding the application takes care automatically of the network security configuration.
The following figure shows the application being decoded with Apktool and then rebuilding it using the new flag:
After signing and aligning the APK(you may use uber-signer for that for example) that was build, it can be installed in the device and this time the application will trust the user and system certificates as the configuration has changed to this:
<network-security-config>
<base-config>
<trust-anchors>
<certificates src="system" />
<certificates src="user" />
</trust-anchors>
</base-config>
</network-security-config>Given that we have added the appropriate certificate of our proxy to the device, it is possible for the application to reach the internet and it will not throw any exceptions like before. The flag has been now merged in the master branch and it is available with the latest versions. Feel free to experiment with it and as always reach out to me for anything interesting.