Shulou(Shulou.com)05/31 Report--

How to use Frida to bypass Android network security configuration, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

Words written in the front

We will demonstrate how to use Frida scripts to bypass Android's network security configuration, which is a new technology that bypasses network security configuration. In addition, we will demonstrate how to test the script in other scenarios and analyze how the script works.

In a previous Android application security audit, the first thing we had to do was prepare the penetration test environment and configure the application to bypass the network security configuration. Because I personally prefer Frida, it has become my preferred tool.

I downloaded two or three scripts at the time, but when I ran the scripts in Android 7.1.0, none of them succeeded. That's why I want to study how network security configurations work and how to bypass them with Frida.

The first thing I did was generate different test cases, and I tried to choose several of the more common ones:

1 、 OKHttp

2 、 HttpsURLConnection

3 、 WebView

Next, I generated three applications with different network security configurations:

1. An application that uses the default NSC configuration-BypassNSC

2. An application with a NSC file (using only the system certificate)-BypassNSC2

3. An application with NSC file (force certificate binding)-BypassNSC3

The code parses and verifies the network security configuration in Android SDK, and my test versions are 24, 25, and 26. The majority of users can click [here] to get the application I generated and the script I used.

The script name is as follows:

Network-security-config-bypass-1.js

Network-security-config-bypass-2.js

Network-security-config-bypass-3.js

Network-security-config-bypass-cr.js

The following figure shows the analysis and test results of each script:

Network-security-config-bypass-1.js

Original reference: [link]

The script modifies the getEffectiveCertificatesEntryRefs method in the NetworkSecurityConfig.Builder class, which returns a list of valid certificates. In a standard Android configuration, the list of valid certificates it returns is the valid certificate installed on the target system. I had no idea that this script would directly return the certificate installed by the user, so in theory, it could bypass the network security configuration of the first two applications, but to my surprise, it also applies to the third case, that is, certificate binding configuration. We can use the following methods to verify the bound certificate:

Android.security.net.config.NetworkSecurityTrustManager.checkPins

The following stack trace record shows the execution path of the code to the checkPins function:

At android.security.net.config.NetworkSecurityTrustManager.checkPins (Native Method) at android.security.net.config.NetworkSecurityTrustManager.checkServerTrusted (NetworkSecurityTrustManager.java:95) at android.security.net.config.RootTrustManager.checkServerTrusted (RootTrustManager.java:88) at com.android.org.conscrypt.Platform.checkServerTrusted (Platform.java:178) at com.android.org.conscrypt.OpenSSLSocketImpl.verifyCertificateChain (OpenSSLSocketImpl.java:596) at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake (Native Method) at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake (OpenSSLSocketImpl.java:357)...

If the patch is not executed, an exception is thrown when the execution path reaches the function:

Caused by: java.security.cert.CertificateException: Pin verification failed at android.security.net.config.NetworkSecurityTrustManager.checkPins (NetworkSecurityTrustManager.java:148) at android.security.net.config.NetworkSecurityTrustManager.checkServerTrusted (NetworkSecurityTrustManager.java:95) at android.security.net.config.RootTrustManager.checkServerTrusted (RootTrustManager.java:88) at com.android.org.conscrypt.Platform.checkServerTrusted (Platform.java:178) at com.android.org.conscrypt.OpenSSLSocketImpl. VerifyCertificateChain (OpenSSLSocketImpl.java:596) at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake (Native Method) at com.android.org.

Let's take a look at the implementation code for this method (API 25):

Private void checkPins (List chain) throws CertificateException {PinSet pinSet = mNetworkSecurityConfig.getPins (); if (pinSet.pins.isEmpty () | | System.currentTimeMillis () > pinSet.expirationTime | |! isPinningEnforced (chain)) {return;} Set pinAlgorithms = pinSet.getPinAlgorithms (); Map digestMap = new ArrayMap (pinAlgorithms.size ()) For (int I = chain.size ()-1; I > = 0; iMurray -) {X509Certificate cert = chain.get (I); byte [] encodedSPKI = cert.getPublicKey () .getEncoded (); for (String algorithm: pinAlgorithms) {MessageDigest md = digestMap.get (algorithm) If (md = = null) {try {md = MessageDigest.getInstance (algorithm);} catch (GeneralSecurityException e) {throw new RuntimeException (e);} digestMap.put (algorithm, md) } if (pinSet.pins.contains (new Pin (algorithm, md.digest (encodedSPKI) {return;} / / TODO: Throw a subclass of CertificateException which indicates a pinning failure. Throw new CertificateException ("Pin verification failed");}

This method can receive a list of certificates returned by website communications, and the first thing it does is conditional checking:

1. Pinset is empty

2. Pinset expired at the time of verification

3. Certificate binding is not a mandatory requirement for configuration

If none of the above conditions is true, binding validation will be ignored. If authentication is necessary, the application checks to see if any certificate provided by the site matches one of the certificates defined in the network security profile, and the authentication is successful. If this does not happen, the method throws the exception shown in the previous stacktrace.

At first, I thought the problem existed in the for loop used to analyze each certificate, so I added the following log to the Frida script:

Var Pin = Java.use ("android.security.net.config.Pin"); Pin.$init.implementation = function (digestAlg,digest) {var bt = Java.use ("android.util.Log") .getStackTraceString (Java.use ("java.lang.Exception"). $new (); console.log ("\ nBacktrace:\ n" + bt); console.log (digestAlg); return this.$init (digestAlg,digest);}

It can output every pin during the validation process, and when I run the changed application, I find it doesn't work. So I added a call to pinSet.getPinAlgorithms () to log and executed it before the for loop:

Var PinSet = Java.use ("android.security.net.config.PinSet"); PinSet.getPinAlgorithms.implementation = function () {var bt = Java.use ("android.util.Log") .getStackTraceString (Java.use ("java.lang.Exception"). $new (); console.log ("\ nBacktrace:\ n" + bt); return this.getPinAlgorithms ();}

Nothing was printed this time, so next I had to see if the condition of the function was true, so I added the following code to the script:

NetworkSecurityTrustManager.checkPins.implementation = function (pins) {var bt = Java.use ("android.util.Log") .getStackTraceString (Java.use ("java.lang.Exception"). $new (); console.log ("\ nBacktrace:\ n" + bt); pinSet = this.mNetworkSecurityConfig.value.getPins (); console.log ("pinSet.pins.value.isEmpty:" + pinSet.pins.value.isEmpty ()); console.log ("isPinningEnforced:" + this.isPinningEnforced (pins)) Console.log ("pins.isEmpty:" + pins.isEmpty ()); console.log (System.currentTimeMillis ()) console.log (pinSet.expirationTime.value); console.log (System.currentTimeMillis () > pinSet.expirationTime.value); this.checkPins (pins);}

After running the application, I get the following output:

PinSet.pins.value.isEmpty: falseisPinningEnforced: false

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.