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

Today, I will talk to you about what are the four ways to bypass Android SSL certification certificates, which may not be well understood by many people. In order to make you understand better, the editor summed up the following content for you. I hope you can get something from this article.

Previously, mobile applications directly ignored all SSL errors and allowed attackers to intercept and modify their own traffic. But now, many popular applications at least check to see if the certificate chain is issued by a valid and trusted certificate authority (CA).

As penetration testers, we often need to convince the target application that our certificate is valid so that we can conduct a man-in-the-middle attack (MITM) and modify its traffic. We will show you four ways to bypass Android SSL validation.

SSL MitM

Why should we pay special attention to the SSL MitM security of mobile applications? In order to observe or invoke Web services on the mobile application, we need to use an intercepting agent such as BurpSuite or ZAP. When we use the agent to intercept SSL traffic, the client's SSL link will be interrupted. By default, self-signed certificates generated by tools like Burp will become invalid, and if the certificate is not trusted, the mobile App will break the connection. Next, the technology we are going to introduce will enable mobile applications to trust the certificates provided by our interceptor agents.

Technology # 1-add a custom CA to the user certificate

The best way to avoid SSL errors is to set a valid and trusted certificate. This method is relatively simple. If you can install a new trusted CA certificate to the device and the operating system trusts your CA, it will trust the certificate signed by your CA.

Android has two built-in certificate stores (System Store and User Store) that track CA trusted by the operating system. The System Store is used to store the pre-installed CA,User Store to store the CA installed by the user. By default, a secure connection like TLS or HTTPS will trust the pre-installed system CA, while Android 6.0 (API Level23) and below will default to the CA added by new users.

What does that mean? If we add our own CA to User Store, we can try a man-in-the-middle attack on devices with Android version 6. 0 and below. If you are targeting a device that is older than Android 6.0, the certificate we added will not be trusted. To solve this problem, we can edit the application's Manifest file and force it to adapt to Android 6.0. The target API Level defines the 'platformBuildVersionCode' attribute (' manifest' element) in the AndroidManifest.xml file:

We're going to change 'platformBuildVersionCode=25'' to 23:

After repackaging, the application will trust the CA certificate added by the user.

Of course, if you want to run in a specific platform version, you can also define one in the'/ res/xml/network_security_config.xml' file of APK. For example, the following code defines a new trusted CA, which is stored in / res/raw/my_ca:

In this way, we can successfully complete the MitM.

Technology # 2-rewrite packaged CA certificates with custom CA certificates

If the first approach doesn't work, it may be because the developer limits the CA certificates that the application can trust. Remember when we used a custom one to provide the CA certificate path? Developers can also use this method to protect their applications from SSL interception attacks.

In this scenario, in order for our intercept certificate to be trusted, we need to extract the APK and rewrite the CA certificate provided by the application with our custom CA certificate. It is important to note that this approach may require a series of validation.

Open the APK file using a tool such as APK Studio, and then find the certificate bundled with the application in the window. In the figure above, the certificate is located in the assets directory of the application. Next, overwrite the application's original CA ('UniversalRootCA' certificate) with our custom CA, so that the application can directly trust our certificate and intercept traffic.

Technology # 3-Frida Hook

If the installation of a custom CA is not successful, the application may be using some kind of SSL binding technology or additional SSL authentication. In general, in order to bypass this validation method, we need to set hooks on the application's code and the validation interface. This interface is generally used to limit root or jailbreak of mobile phones, but with the help of the Frida framework [tool download], we can dynamically analyze applications without root devices.

Frida can be run as a stand-alone application in the operating system, but this requires root of the device. To avoid root operations, we can inject Frida directly into the target APK. The Frida tool contains a dynamic library that allows the application to load Frida at run time and allows us to dynamically modify the code and instructions of the target application.

Next, we need to extract the APK file, inject the dynamic library, and then edit some smali code so that our code base is called first when the application starts. When you are done, repackage APK and install it. For the complete operation of the whole process, please refer to [this article].

In addition, we can also use the Objection tool [project address] to achieve our goals. Objection can automate the whole process. We only need to provide the path to the target APK on the command line, and Objection can help us complete all the code injection and modification operations.

C: > objection patchapk-s test_app.apkNo architecture specified. Determining it using `adb`.Detected target device architecture as: armeabi-v7aGithub FridaGadget is v10.6.28, local is v10.6.13. Updating...Downloading armeabi-v7a library toC:\ .objection\ android\ armeabi-v7a\ libfrida-gadget.so.xz...Unpacking C:\ .objection\ android\ armeabi-v7a\ libfrida-gadget.so.xz...Cleaning up downloaded archives...Using Gadget version: 10.6.28Unpacking test_app.apkApp already has android.permission.INTERNETReading smali from:C:\ Temp\ tmp8dxqks1u.apktemp\ smali\ com/test/app/TestMainActivity.smaliInjecting loadLibrary call at line: 10Writing patched smali back to:C:\ Temp \ tmp8dxqks1u.apktemp\ smali\ com/test/app/TestMainActivity.smaliCreating library path: C:\ Temp\ tmp8dxqks1u.apktemp\ lib\ armeabi-v7aCopying Frida gadget to libs path...Rebuilding the APK with the frida-gadget loaded...Built new APK with injected loadLibrary and frida-gadgetSigning new APK.jar signed.Signed the new APKPerforming zipalignZipaling completedCopying final apk from C:\ Users\ cwass\ AppData\ Local\ Temp\ tmp8dxqks1u.apktemp.aligned.objection.apkto current directory...Cleaning up temp files...

Next, a file called 'test_app.objection.apk' should appear in our working directory (by default, the tool adds a .objection suffix after the original APK file name). We can install this file just as we would install a normal APK, and use the command "adb install test_app.objection.apk" to push it directly to the connected device. Run the target App after the installation is complete, and App will get stuck in the startup interface. Now we can connect to the Frida server and start listening for device traffic. The Frida command line tool is used as follows:

C:\ > frida-ps-UPID Name-----6383 Gadget C:\ > frida-U gadget____/ _ | Frida 10.3.14-A world-class dynamic instrumentation framework | (_ | | > _ | Commands:/_/ | _ | help-> Displays the help system. . .. Object?-> Display information about 'object'. . .. Exit/quit-> Exit. . .... .. More info at http://www.frida.re/docs/home/ [MotorolaMoto G (5) Plus::gadget]-> Java.availabletrue Alternatively,Objection supports interaction with the listening Frida server by using the'explore' command: C:\ > objectionexplore___ | | _ | _ | | _ |. |. |-_ | _ | | |. | _ _ | | _ _ | | _ | _ _ | | _ | | (object) inject (ion) v1.2.2 RuntimeMobile Explorationby:@leonjza from @ sensepost [tab] for command suggestionscom.test.appon (motorola: 7.0) [usb] # android hooking search classes TrustManagerandroid.security.net.config.RootTrustManagerandroid.app.trust.ITrustManager$Stub$Proxyandroid.app.trust.ITrustManagerandroid.security.net.config.NetworkSecurityTrustManagerandroid.security.net.config. RootTrustManagerFactorySpiandroid.app.trust.TrustManagerandroid.app.trust.ITrustManager$Stubcom.android.org.conscrypt.TrustManagerImplcom.android.org.conscrypt.TrustManagerImpl$ExtendedKeyUsagePKIXCertPathCheckercom.android.org.conscrypt.TrustManagerImpl$TrustAnchorComparatorcom.android.org.conscrypt.TrustManagerFactoryImpljavax.net.ssl.TrustManagerFactory$1javax.net.ssl.TrustManagerjavax.net.ssl.TrustManagerFactoryjavax.net.ssl.X509TrustManagerjavax.net.ssl.TrustManagerFactorySpijavax.net.ssl.X509ExtendedTrustManager [Ljavax.net.ssl.TrustManager

At this point, you can use the built-in SSL binding bypass function to carry out the attack:

Com.test.appon [usb] # android sslpinning disableJob:2f633f86-f252-4a57-958e-6b46ac8d69d1-Starting [6b46ac8d69d1] [android-ssl-pinning-bypass] Custom, Empty TrustManager readyJob:2f633f86-f252-4a57-958e-6b46ac8d69d1-Started

Technology # 4-reverse the verification code for custom certificates

Of course, it is also possible for developers to use their own SSL libraries instead of directly using the system libraries to handle the SSL certificate verification process. If this is the case, we need to extract the APK file and convert the smali code into Java code, so that we can analyze the code responsible for certificate verification and find a way to intercept traffic. Here we need to use the dex2jar tool.

The command statements for using the dex2jar tool are as follows:

C:\ > d2j-dex2jar.bat "C:\ test_app.apk" dex2jarC:\ test_app.apk->.\ test_app-dex2jar.jar

The output .jar file can be opened directly in most Java inverse tools, such as JD-GUI.

Once you have found the code responsible for handling certificate verification, you can choose to modify the code directly or use Frida to set hooks for specific functions. To avoid refactoring the entire application, we can directly set hooks on the certificate verification function. The specific operation method can refer to the content introduced in technology # 3 (using Frida command line tool or Objection interface).

After reading the above, do you have any further understanding of the four ways to bypass Android SSL authentication certificates? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.