iOS Application Security Part Five – App Transport Security (ATS)

In this article, I like to go over App Transport Security (ATS) from pen tester’s perspective. What does that mean exactly? First, I like to walk you through basic testing-related archaeology and help you set up the environment, I'll demo what could go wrong and why strong TLS is not enough.Welcome to part five of “iOS Application Security Testing Series” You can find the Part 4 here.

In this article, I like to go over App Transport Security (ATS) from pen tester’s perspective. What does that mean exactly? First, I like to walk you through basic testing-related archaeology and help you set up the environment, I’ll demo what could go wrong and why strong TLS is not enough.

The biggest issues I find with App Transport Security (ATS)  when conducting penetration testing is Lack of Certificate Inspection, second is Weak Handshake Negotiation and Privacy Information Leakage.

Double Proxy Network, Web, and API Monitoring

Burp Suite Pro and OWASP ZAP Proxy are the tools I always run in the background to intercept SSL/TLS connections seamlessly.

Setting up Burp to proxy your traffic through is pretty straightforward. It is assumed that you have both: iOS device and workstation connected to the same WiFi network where client to client traffic is permitted. If client-to-client traffic is not permitted, it is possible to use usbmuxd in order to connect to Burp through USB.

Portswigger also provides a good tutorial on setting up an iOS Device to work with Burp and a tutorial on how to install Burps CA certificate on an iOS device .

App Transport Security (ATS) overview

In iOS 9, Apple introduced App Transport Security (ATS). This defaults apps to requiring an HTTPS connection, and returning an error for non-HTTPS connections. In addition, HTTPS connections must also be using the latest protocol, Transport Layer Security (TLS) v1.2 and will fail to establish a connection if an older version is being used by the web server. Here are summarized App Transport Security Requirements.

ATS Exceptions

ATS restrictions can be disabled by configuring exceptions in the fileInfo.plist under the keyNSAppTransportSecurity. These exceptions can be applied to:

  • Allow insecure connections (HTTP),
  • Lower the minimum TLS version,
  • Disable PFS
  • Allow connections to local domains.

In addition, a number of the ATS keys I describe below will set off additional App Store review of the app in question, and their use will need to be justified to Apple as part of submitting an app to the store.Those keys include:

Key Description
NSAllowsArbitraryLoads Disable ATS restrictions globally except for individual domains specified under NSExceptionDomains
NSAllowsArbitraryLoadsInWebContent Disable ATS restrictions for all the connections made from web views
NSAllowsLocalNetworking Allow connection to unqualified domain names and .local domains
NSAllowsArbitraryLoadsForMedia Disable all ATS restrictions for media loaded through the AV Foundations framework

The following table summarizes the per-domain ATS exceptions. For more information about these exceptions, please refer to table 2 in the official Apple developer documentation and table 3 in the official Apple developer documentation.

Static Analysis

If the source code is available, open the fileInfo.plist in the application bundle directory and look for any exceptions that the application developer has configured. This file should be examined taking the application’s context into consideration.

The following listing is an example of an exception configured to disable ATS restrictions globally.

<key>NSAppTransportSecurity</key>
	<dict>
		<key>NSAllowsArbitraryLoads</key>
		<true/>
	</dict>

If the source code is not available, then the fileInfo.plist should be either obtained from a jailbroken device or by extracting the application IPA file.

Since IPA files are ZIP archives, they can be extracted using any zip utility.

$ unzip app-name.ipa

Info.plist file can be found in the Payload/BundleName.app/ directory of the extract. It’s a binary encoded file and has to be converted to a human-readable format for the analysis.

plutil is a tool that’s designed for this purpose. It comes natively with Mac OS 10.2 and above versions.

The following command shows how to convert the fileInfo.plist into XML format.

$ plutil -convert xml1 Info.plist

Once the file is converted to a human-readable format, the exceptions can be analyzed. Unfortunately, the application may have ATS exceptions defined to allow it’s normal functionality.

For an example, the Firefox iOS application has ATS disabled globally. This exception is acceptable because otherwise, the application would not be able to connect to any HTTP website that does not have all the ATS requirements.

Dynamic Analysis

What is wrong with below picture (i will give you a hint “NSRequiresCertificateTransparency”

ATS settings should be verified via static analysis in the iOS source code.

ATS should always be activated and only be deactivated under certain circumstances.

If the application connects to a defined number of domains that the application owner controls, then configure the servers to support the ATS requirements and opt-in for the ATS requirements within the app. In the following example, example.com is owned by the application owner and ATS is enabled for that domain.

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
    <key>NSExceptionDomains</key>
    <dict>
        <key>example.com</key>
        <dict>
            <key>NSIncludesSubdomains</key>
            <true/>
            <key>NSExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <false/>
            <key>NSExceptionRequiresForwardSecrecy</key>
            <true/>
        </dict>
    </dict>
</dict>

If connections to 3rd party domains are made (that are not under control of the app owner) it should be evaluated what ATS settings are not supported by the 3rd party domain and deactivated.

If the application opens third party websites in web views, then from iOS 10 onwards NSAllowsArbitraryLoadsInWebContent can be used to disable ATS restrictions for the content loaded in web views.

Testing Custom Certificate Stores and Certificate Pinning

 Part Three – Bypassing (Jailbreak Detection and Certificate Pinning ) We looked at applications that use Jailbreak Detection and Certificate Pinning as defenses – and how they can be bypassed.

By removing trust in external certificate authorities, the attack surface is reduced (after all, there are many known cases where certificate authorities have been compromised or tricked into issuing certificates to impostors).

Verify that the server certificate is pinned. Pinning can be implemented in multiple ways: but the best way is NSRequiresCertificateTransparency Certificate Transparency is a Google project aimed at making the SSL certificate system more secure.

Client certificate validation

Some applications use two-way SSL handshake, meaning that application verifies server’s certificate and the server verifies client’s certificate. You can notice this if there is an error in Burp ‘Alerts’ tab indicating that client failed to negotiate the connection.

There is a couple of things worth noting:

  1. The client certificate contains a private key that will be used for the key exchange.
  2. Usually, the certificate would also need a password to use (decrypt) it.
  3. The certificate can be stored in the binary itself, data directory or in the keychain.

Most common and improper way of doing two-way handshake is to store the client certificate within the application bundle and hardcoded the password. This obviously does not bring much security, because all clients will share the same certificate.

The second way of storing the certificate (and possibly password) is to use the keychain. Upon the first login, the application should download the personal certificate and store it securely in the keychain.

Sometimes applications have one certificate that is hardcoded and use it for the first login and then the personal certificate is downloaded. In this case, check if it’s possible to still use the ‘generic’ certificate to connect to the server.

Once you have extracted the certificate from the application (e.g. using Cycript or Frida), add it as client certificate in Burp, and you will be able to intercept the traffic.

About Liban Mohamud

My name is Liban Mohamud, I hold M S.c in Digital Investigations, Forensics and Computer Security from University College Dublin (UCD). I’m an Information Security Specialist and researcher with a passion for Mobile Security and Mobile Forensics and I have over 15 years experience in the industry. @coolx28

One thought on “iOS Application Security Part Five – App Transport Security (ATS)

  1. Pingback: iOS Application Security Part 6–Reverse Engineering and Tampering Re-sign + Patching. | agostini.tech

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.