Network security configuration android

Bypassing Android’s Network Security Configuration

Written by: Adrian Villa

With the release of Android Nougat (Android 7) came a new security feature called Network Security Configuration [1].

This new feature arrived with the intention of allowing developers to customise their network security settings without modifying app code. Additional modification was also included in the default configuration for connections to SSL/TLS services; if the application targets an SDK higher or equal to 24, only the system certificates are trusted.

All of the above has an impact in the way an Android mobile application assessment is performed. If the HTTPS traffic needs to be intercepted, then a proxy certificate must be installed, but it is going to be installed in the ‘user certificates’ container, which is not trusted by default.

Here, we’ll aim to explain how the new mechanism works and how the default behaviour could be modified by either re-compiling the application or hooking the mechanism on runtime. During a mobile application assessment on Android 7 or higher, these procedures are essential in order to intercept HTTPS traffic between the application and the server.

How to use it as a developer

To modify the default configuration, an XML file that specifies the custom configuration has to be created on the resources directory. The piece of code below shows an example of a configuration file that uses the user certificates container for all HTTPS connections made by the application.

Additionally, the file has to be referenced from the Android Manifest file, which introduces the key android:networkSecurityConfig on the application tag, as shown here:

How to bypass it as a pentester

Re-compiling

If the assessed application is executed on Android 7 or higher — and the targetSdkVersion key is configured to version 24 (Android 7) or higher — the application probably uses the default configuration. Hence, the user certificates (i.e. proxy CA certificate) will not be trusted by the application.

The usual approach to modifying the default configuration would be to re-compile the application after inserting an XML, which activates the use of the certificate container. Once we have the APK, this process can be achieved using apktool [2], which allows the application to be manipulated.

The first task is to de-compile the application with the de-compile flag of apktool. After this process completes, an XML file has to be created on the resources directory and the AndroidManifest.xml file has to be modified to point to the Network Security Configuration file. At this point we can compile the application again with apktool and sign the generated APK file with the jarsigner tool, provided by the Java JDK.

When the APK is re-signed using an arbitrary certificate, it can be installed in the mobile phone using adb (Android Device Bridge). If the mobile is configured to send the traffic via an intermediate proxy, like Burp Suite, the HTTPS traffic could be intercepted as long as the CA certificate is installed on the system.

Hooking on runtime

However, in some situations the process described above is not possible. For example, if the application uses sharedId to share the same ID of another application, and hence access its data directly, then Android restricts our scenario to only applications signed by the same certificate. If an application is therefore re-compiled and re-signed, this feature is made redundant as it would not be possible to sign the modified APK with the original certificate used by the developers of the application.

For this kind of scenario dynamic instrumentation is useful because it allows the application’s behaviour at runtime to be modified without modifying the application itself. To perform this process, a Frida script will be created which adjusts the Network Security Configuration default behaviour on applications that target SDK version 24 or higher.

The android.security.net.config package [3] implements the Network Security Configuration module, while the main class, ManifestConfigSource , loads either the custom configuration specified in the XML file or the default configuration (if the resources file does not exist). You can see this below:

The DefaultConfigSource class, which is defined as a private class within the ManifestConfigSource class, is the one used if the configuration is not modified using an XML file.

As can be seen in the constructor, it receives three parameters, one of them being the SDK version which targets the application. This value is used to build the NetworkSecurityConfig class, using the getDefaultBuilder() method, which is shown on the next piece of code. As it can be seen, the last block of code loads the user certificates if the targetSdkVersion is less than or equal to Android Marshmallow (Android 6.0), which is the SDK version 23.

With this in mind, a Frida script which hooks the constructor of the DefaultConfigSource class and changes the value of the targetSdkVersion variable could be created. In addition, the script will also hook to the getDefaultBuilder() method to ensure that the value is modified, even if the Android code changes this constructor in the future.

At this point, the Android application which targets SDK 24 or higher can be spawned by loading the above script with Frida, and the traffic can then be intercepted using an HTTP proxy such as Burp Suite.

We hope you liked the article and it helps you to overcome different barriers that could face during a research or an assessment.

If you have any question or feedback, you can contact me via Twitter @AdriVillaB.

Источник

A Security Analyst’s Guide to Network Security Configuration in Android P

As data privacy becomes increasingly important, Google has been introducing mobile OS enhancements to safeguard all data that traverses Android mobile devices and endpoints. Set for release in August, network communications in Android 9.0 P (Pie) will default to TLS. Android mobile app developers will either need to update their back-end services to support HTTPS or implement the Android Network Security Configuration feature to prevent app connections from failing.

Discover more about the security features in Android Pie in our upcoming webinar.
>>> View the recording here

When Android 6.0 Marshmallow was released, Google introduced the manifest attribute android:usesCleartextTraffic as a means to protect against accidental use of cleartext traffic. Android 7.0 Nougat extended this attribute by introducing the Android Network Security Configuration feature, which allows developers to be more prescriptive about secure communications. Network Security Configuration is an XML file in which developers customize network security settings for an Android app.

Some of you may think this sounds familiar. iOS uses a similar client side check known as App Transport Security. While there are quite a few similarities in what protections Network Security Configuration offers when compared to NSAppTranportSecurity, the two take very different approaches to network security on their individual platforms. To learn more about ATS, check out my previous blog.

Let’s examine several benefits of using Network Security Configuration in Android mobile apps and dive into best practices for implementing this feature.

1. Protect against regressions to cleartext traffic

Security is more about layers of protection than a single iron wall. The Android Network Security Configuration feature provides a simple layer to protect apps from unintentionally transmitting sensitive data in unencrypted cleartext.

If you don’t know what “unencrypted communications” means, think of it this way — let’s say your office has a policy to send all shipments via UPS. A new intern joins the office and is tasked with shipping equipment to an office across the country. Oblivious to the policy and with all the best intentions, the intern sets up all shipments to be sent through an unknown, less expensive service. The Android Network Security Configuration feature is like the shipping/receiving manager who examines all inbound and outbound shipments and stops the shipment before the equipment gets into the hands of an unvetted delivery system. It can be used to prevent the accidental use of untrusted, unencrypted connections.

One of the biggest changes in Android 9 is that cleartextTrafficPermitted is set to false by default. This means that if you don’t see this flag explicitly set to false, and the app is targeting API levels lower than 28, the flag will be honored as true.

Another capability of the cleartextTrafficPermitted flag being used in the Network Security Config is the ability to enforce the true setting on specific domains and subdomains:

2. Set up trusted Certificate Authorities for secure connections

Trusted Certificate Authorities (CA) act as the circle of trust. In the previous example, the office policy was to ship with UPS, but that policy could be expanded to FedEx, DHL, and so forth. Essentially, who do you trust to securely send app data and prevent man-in-the-middle attacks? Developers can use the Android Network Security Configuration feature to designate which CAs they trust to issue certificates and ensure secure communications.

To start, Android Network Security Configuration gives developers a few options in terms of what CAs they should be trusting. By default, the trust anchor used by Android 7+ (Nougat, Oreo and Pie) will be the pre-installed system CA certificates, noted as system :

In Android 6 (Marshmallow) and below, your default trust-anchor will also include user installed certificate, noted as user :

Finally, you can set a custom trust anchor:

3. Implement certificate pinning

Implementing certificate pinning offers yet another layer of security. Let’s revisit the running example of shipping equipment. If trusted CAs are like UPS, FedEx, etc., then certificate pinning is akin to specifying which of those companies’ drivers you trust to send your shipment. The Android Network Security Configuration feature can be used to restrict communications with only specific certificates issued by a trusted CA.

We discussed different implementations of certificate pinning in a previous blog post. In the example below, we see we can pin to a specific domain and subdomains, set pins along with backups, and set an expiration date.

4. Debug app network connections

Another option offered in Android Network Security Configuration is debug-overrides . This feature allows you to have settings in the Network Security Config that will only be usable when android:debuggable is set to true . For example, you can configure a custom trust-anchor for a quality assurance/pre-production environment using a custom CA. This eases testing in a closed environment because the app store does not accept apps marked debuggable.

Free Mobile App Security Assessment

Implementation Advice

Now that you understand a few of the benefits of deploying Network Security Configuration, let’s cover some best practices for implementing this file.

First, check the app manifest to see if it uses this feature. Look for the attribute android:networkSecurityConfig , which would appear similar to this:

Once you’ve located the Network Security Configuration file, it’s time to check how to permit cleartext traffic.

The example code snippet below shows a bad example of how someone might use Network Security Configuration.

While this ensures all traffic to example.com and cdn.example2.com is sent over HTTPS, the default configuration for all traffic sent to other domains can be cleartext. This completely defeats the intended purpose of the Network Security Configuration feature — to improve the privacy of all data transmitted through Android devices.

If your mobile app must send data in cleartext, then do this to only allow encrypted communications to certain domains. In addition, carefully scrutinize endpoints that HTTP is explicitly allowed to check for sensitive data and other API-related issues:

Another thing to consider regarding the cleartextTrafficPermitted flag is it defaults to true on Android 8 and lower. Because of this, explicitly set the flag to false in all apps’ Network Security Configuration.

Let’s look at another example below:

In this example, we see the app is accepting user certs within the app’s trust anchor. This means that user-installed certs will be trusted by the app the same way system pre-installed certs are. When configuring the trust-anchors used by the app, it’s best to limit trust only to the system certs and, when necessary, to a custom CA built within the app. This can help prevent MITM attacks where an attacker is able to install a cert on the device. As part of the the protections introduced as part of Android 7, by default a user-installed certificate isn’t trusted like pre-installed certificates. As stated earlier, Android 6 and below accept user certs by default, so it’s important to explicitly select system and/or a custom CA when necessary and exclude user in all apps.

Let’s look at an example implementation of pinning:

The example above reveals two potential issues within the app. First, there is no expiration set for the pin-set . Second, there is no backup pin. A smart strategy is to set an expiration for certificates and have multiple backup pins. It is not unheard of to have four pins in rotation. If you do not explicitly set an expiration date for the pin, your app will fail to connect after expiration occurs. But if you set an expiration and the pin expires, the app will fail over to the system CA on the device instead of failing to connect.

Finally, let’s talk about the Network Security Config debug-overrides .

While the debug feature can help eliminate debug network code in an app, make sure to remove any debug CAs from the app. As a best practice, avoid leaving unnecessary information in your app that could present a security risk, especially if the internal CA certificates are included with final production build of the app.

From the perspective of a security analyst, knowing how to read and spot issues in the Network Security Configuration is important. As we can see, we are able to find some potential issues in the app before install. But keep in mind that these findings alone aren’t proof that your app’s network connections are secure.

You’ll still need to determine if your app is performing hostname verification, because Network Security Configuration will not protect against those types of issues. Make sure your third-party libraries honor Network Security Configuration. If they don’t, these protections may cause issues in your app. In addition, Network Security Configuration is not honored by lower-level network connections such as websockets. Finally, keep in mind that network-related issues in mobile are only a small part of the overall scope in mobile testing.

Overall, Android Network Security Configuration offers a lot of simple network security features for Android. If your app does not currently take advantage of Network Security Configuration, you will need to use it in the coming year.

Coinciding with the release of Android P, Google has begun enforcing target API levels in the app stores to reduce mobile OS fragmentation and push users to current releases. The current requirement is 26, although Google plans to incrementally increase that number with each new release. By this time next year, API Level 30 (Android Q) will probably be out. That means if your app uses HTTP, it must be declared in the Network Security Configuration file because the mandatory target API level will be 28 by then.

You can learn all about other security enhancements in the Android P release during NowSecure’s webinar — watch here.

What to read next:

A 3-Part Mobile App Security Testing Checklist to Build Your Program

To help security analysts and developers craft a more effective list of mobile testing requirements, we’ve assembled a Mobile App Security Testing Checklist of three key questions to address

Источник