In Security

Einar Otto Stangvik just released an interesting study regarding the state of STARTTLS for SMTP servers in Norway. He used SSLyze to perform the scans and wrote a script to process SSLyze’s XML output to analyze the data and compute an SSL grade for each server, using SSL Labs’ SSL Server Rating Guide. He found that:

• More than 60% of the scanned mail servers do not support STARTTLS.
• 43% of the mail servers that do support STARTTLS get an F grade, meaning that they either expose an invalid SSL certificate or they support extremely weak cipher suites.

Although limited to email servers in Norway, this study illustrates the poor state of email encryption. One major issue that isn’t mentioned in the article is that because so many SMTP servers expose an invalid SSL certificate, it is impossible for SMTP clients (which can be both end-user clients and other mail servers) to implement strict validation of the server’s certificate, resulting in the SSL connection being trivial to man-in-the-middle.

To improve the situation, Einar deployed STARTLS.info, a website to easily scan SMTP servers and rate their STARTTLS configuration, similarly to what SSL Labs does for HTTPS servers. This is a very useful tool and it also nice to see a project make good use of SSLyze.

I’ve updated the iOS certificate pinning code which is part of iSEC Partners’ SSL Conservatory project on Github. This new version brings the following changes:

• The Xcode project was re-created as a static library (instead of an iOS App) to facilitate integration. Sample code demonstrating how to use the library has been moved the project’s unit tests.
• A new convenience delegate class for NSURLSession, the HTTP connection framework introduced in iOS 7, was added to the project. Similarly to the existing convenience class for NSURLConnection this class makes it easy to add certificate pinning to connections relying on NSURLSession.

Project page

Code and instructions are available on the project’s Github page.

With the availability of the evasi0n7 jailbreak and the subsequent release two days ago of Cydia Substrate with support for iOS 7 and ARM64, a full-blown iOS 7 penetration testing environment can now be setup. To this extent, I’ve updated the two following iOS pentesting tools in order to add support for iOS 7 and ARM64:

• iOS SSL Kill Switch v0.5 which disables SSL certificate verification/pinning within Apps.
• Introspy-iOS v0.4, an iOS Apps security profiler.

The pre-compiled packages for these tools now contain both an armv7 and an arm64 slice, which means that they will work on 64 bits iOS Apps for devices with an A7 chip (such as the iPhone 5s and the iPad Air).

Both tools were successfully tested on an iPhone 5s running iOS 7.0.4:

</img>

Sandbox changes in iOS 7

While testing Introspy-iOS on iOS 7, I ran into issues with the sandboxd daemon denying write access to specific files the tool was trying to create. Interestingly enough, it seems like the Seatbelt profiles deployed on iOS 7 have been updated, compared to iOS 6. Specifically:

• AppStore Apps can no longer write to the root folder of their container directory, for example /var/mobile/Applications/3152B928-D771-424C-AE39-F79EC4A79EC5/
• System Apps can no longer write to /var/mobile/

Because of these changes, I had to modify the locations where Introspy-iOS stores its files, to the following paths:

• [App Container]/Library/ for AppStore Apps.
• /var/mobile/Library/Preferences/ for System Apps.

It is unclear why the Seatbelt profiles were changed, although the ability to write to these locations was not actually needed by Apps. More information regarding the Seatbelt profiles used for various iOS Apps is available on the iphonedev wiki.

I just released a new version of SSLyze, a Python tool that can analyze the SSL configuration of a server by connecting to it.

Changelog

• Additional certificate chain validation using the Apple, Microsoft and Java trust stores in addition to Mozilla’s
• Added support for StartTLS RDP; see –starttls=rdp
• Greatly improved the reliability and accuracy of scan results by adding an exponential backoff algorithm to retry failed network connections. This will especially impact scans against servers that stop properly answering after several concurrent connections have already been opened. The number of retry attempts can be controlled using –nb_retries
• Bug fixes including:
  • Better results when the server requested a client certificate but none was supplied
  • Clarified text and XML output

Packages

SSLyze requires Python 2.7; the supported platforms are Windows 7 32/64 bits, Linux 32/64 bits and OS X 64 bits.

SSLyze is statically linked with OpenSSL 1.0.1e. For this reason, the easiest way to run SSLyze is to download one the pre-compiled packages available in the release section of the project’s page on GitHub.

As previously announced during our Ruxcon presentation, Marc Blanchou just released Introspy for Android. Marc and I demonstrated the final version of both the iOS and Android tools at the iSEC Open Forum in San Francisco.

Similarly to the iOS version that was released a few months ago, Introspy for Android is a tool designed to help penetration testers understand what an Android application does at runtime, and to greatly facilitate the process of reviewing the application’s security mechanisms.

The tool can easily be installed on a rooted device running Cydia Substrate and provides a GUI interface to configure hooks, filters and options. See the project page as well the slides we presented at the Open Forum for more information about what the tool does and how it works.

Source code and pre-compiled packages are available on the project’s source repository on Github.

Last month, Marc Blanchou and myself presented Introspy at the Ruxcon conference in Melbourne, Australia. This presentation describes why we created this tool and how it works. We also did a quick demo of the iOS tool and the Android version (which hasn’t been released yet).

• Slides available here.
• We were also featured in SC Magazine, which put a video of the presentation on Youtube.

Note: this article was originally posted on iSEC Partners’ blog.

Blackbox iOS Pentesting

In 2013, assessing the security of iOS applications still involves a lot of manual, time-consuming tasks - especially when performing a black-box assessment. Without access to source code, a comprehensive review of these applications currently requires in-depth knowledge of various APIs and binary formats, as well as the ability to use relatively complex, rather generic tools such as Cycript, Mobile Substrate, or a debugger.

Introspy

To simplify this process, a coworker and I are releasing Introspy - an open-source application profiler for iOS. Introspy is designed to help penetration testers understand how an application functions at runtime by swizzling system APIs to gather detailed information on each of the calls that can then be analyzed offline.

The tool comprises two separate components: the injected dylib that performs the swizzling and traces calls to the system APIs, and an offline analysis tool for mining the traced calls. The iOS tracer can be easily installed on a jailbroken iOS device and configured via the main Settings application. The tracer hooks security-sensitive APIs called by a given application and records the calls in a database. These include function calls related to cryptography, IPC, data storage / protection, networking, and user privacy. The full list of traced calls can be found on the project wiki. The introspy analyzer can then extract the database of traced calls off of the device and generate an HTML report displaying all recorded calls, plus a list of potential vulnerabilities affecting the application. Additionally, there are a myriad of options to allow quick and dirty analysis from the command-line.

Project page

We have been using this tool internally with much success for a period of time and have decided to share it with the community with the hope that it will lead to better black-box security analysis and ultimately more secure iOS applications. For a quick overview read our GitHub page or checkout the GitHub repository for full details on how to install and configure the tool.

TL;DR: By default, MobileSubstrate tweaks do not get injected into system daemons on iOS which explains why my SSL Kill Switch tool wasn’t able to disable SSL certificate validation in the iTunes App Store.

The problem

Last year I released the iOS SSL Kill Switch, a tool designed to help penetration testers decrypt and intercept an application’s network traffic, by disabling the system’s default SSL certificate validation as well as any kind of custom certificate validation (such as certificate pinning ).

While the tool worked well on most applications including SSL-pinning apps such as Twitter or Square, users reported that it didn’t work the iTunes App Store, which would still refuse to connect to an intercepting proxy impersonating the iTunes servers. Other similar tools such as Intrepidus Group’s trustme also seemed to have the same limitation.

A quick look at the App Store on iOS

The first step was to get the right setup:

• An intercepting proxy (Burp Pro) running on my laptop.
• An iPad with the SSL Kill Switch installed, and configured to use my laptop as the device’s proxy.

After starting the App Store app, I noticed that I could already intercept and decrypt specific SSL connections initiated by the App Store: all the HTTP requests to query iTunes for available apps (as part of the App Store’s tabs such as Featured'',Top Charts’’, etc.) as well as app descriptions (Details'', Reviews’’).

However, more sensitive operations including user login or app installation and purchase would fail by rejecting my intercepting proxy’s invalid SSL certificate. From looking at logs on the device, it turns out that two distinct processes are behind the App Store’s functionality:

AppStore[339] <Warning>: JS: its.sf6.Bootstrap.init: Initialize
itunesstored[162] <Error>: Aug 22 11:29:10  SecTrustEvaluate  [root AnchorTrusted]

• AppStore is the actual App Store iOS application that you can launch from the Springboard. It is responsible for displaying the App Store UI to the user.
• itunesstored is a daemon launched at boot time by launchd, the process responsible for booting the system and managing services/daemons. tunesstored seems to be responsible for the more sensitive operations within the App Store (login, app purchase, etc.) and possibly some of the DRM/Fairplay functionality.

Why SSL Kill Switch didn’t work

I initially thought the issue to be that the strategy used by the SSL Kill Switch to disable certificate validation somehow wasn’t enough to bypass itunesstored’s certificate pinning. However, it turns out that the SSL Kill Switch was just not being injected into the itunesstored process at all, for a couple reasons:

• The itunesstored process is started as a daemon by launchd early during the device’s boot sequence, before MobileSubstrate and MobileLoader get started. Therefore, none of the MobileSubstrate tweaks installed on the device, including the SSL Kill Switch, get injected into this process.
• The SSL Kill Switch had a MobileLoader filter so that the code disabling certificate validation would only be loaded into apps linking the UIKit bundle (ie. applications with a user interface). This was initially done to restrict the effect of the SSL Kill Switch to App Store apps only. However, itunesstored is a daemon that doesn’t have a user interface, hence the filter prevented MobileLoader from injecting the SSL Kill Switch into the process.

Man-in-the-Middle on itunesstored

After figuring this out, getting itunesstored to stop validating SSL certificates was very straightforward. First of all, make sure you’re using the latest version of the SSL Kill Switch (at least v0.5). Then, all you need to do is kill the itunesstored process:

iPad-Mini:~ root# ps -ef | grep itunesstored
501   170     1   0   0:00.00 ??         0:01.95 /System/Library/PrivateFrameworks/iTunesStore.framework/Support/itunesstored
  0   432   404   0   0:00.00 ttys000    0:00.01 grep itunesstored

iPad-Mini:~ root# kill -s KILL 170

When doing so, launchd will automatically restart itunesstored. This time however, MobileLoader will inject the SSL Kill Switch’s code into the process. You can validate this by looking at the device’s logs, for example using the xCode console. You should see something like this:

itunesstored[1045] <Notice>: MS:Notice: Loading: /Library/MobileSubstrate/DynamicLibraries/SSLKillSwitch.dylib
itunesstored[1045] <Warning>: SSL Kill Switch - Hook Enabled.

If you restart the App Store app, you should then be able to proxy all the traffic and see app store transactions such as logins or app downloads.

If you try to install an app while proxying, your proxy might crash or freeze when the App Store tries to download the app because IPA files can be fairly large (200+ MB).

Takeaway

A similar methodology could be used to proxy other system daemons including for example accountsd, which is responsible for the Twitter and Facebook integration that was added to iOS 5 and iOS 6.

While working on this, I also discovered a better way to disable SSL certificate validation and certificate pinning in iOS apps. Hence, SSL Kill Switch v0.5 is actually a complete rewrite. If you’re interested in knowing how it works, I wrote a blog post explaining what the tool does.

Version 0.5 of the iOS SSL Kill Switch is now available. iOS SSL Kill Switch is a tool to disable SSL certificate validation - including certificate pinning - within iOS Apps in order to facilitate blackbox testing.

The main goal for this version was to add the ability to disable certification within the iTunes App Store app. While working on this feature, I discovered a new way to disable certificate validation that worked on many more applications than previous versions of the tweak. As a consequence, version 0.5 of the SSL Kill Switch is a complete rewrite.

The debian package is available here and was tested on iOS 6.1. Instructions on how to install it are available on the project page.

How it works

Just like the previous versions of the tool, the SSL Kill Switch uses MobileSubstrate to patch system functions. However, this new version of the tweak hooks functions within the Secure Transport API instead of hooking NSURLConnection methods and SecTrustEvaluate().

The Secure Transport API is ``the lowest-level TLS implementation on iOS’’ which makes it an interesting target because other higher level APIs such as NSURLConnection internally rely on the Secure Transport API for their certificate validation routines. This means that disabling SSL certificate validation in the Secure Transport API should affect most (if not all) of the network APIs available within the iOS framework.

According to the documentation, disabling or performing custom certificate validation is implemented the following way when using the Secure Transport API:

1. Before starting the connection, call SSLSetSessionOption() to set the kSSLSessionOptionBreakOnServerAuth option to true'' on the SSL context. Setting this option totrue’’ disables the framework’s built-in certificate validation to let the application perform its own certificate verification.
2. Run the Secure Transport handshake as per usual using the SSLHandshake() function.
3. When SSLHandshake() returns errSSLServerAuthCompleted, call SSLCopyPeerTrust() to get a trust object for the connection and use that trust object to implement whatever custom server trust evaluation you desire.
4. Either continue the Secure Transport handshake by calling SSLHandshake() again, or shut down the connection.

The SSL Kill Switch removes the ability to do any kind of certificate validation by hooking and modifying three functions within the Secure Transport API.

Patch SSLCreateContext(): Disable the built-in certificate validation in all SSL contexts

SSLCreateContext() is used to create a new SSL context. SSL Kill Switch modifies this function so that all new SSL contexts have the kSSLSessionOptionBreakOnServerAuth set to true by default:

static SSLContextRef replaced_SSLCreateContext (
   CFAllocatorRef alloc,
   SSLProtocolSide protocolSide,
   SSLConnectionType connectionType
) {
    SSLContextRef sslContext = original_SSLCreateContext(alloc, protocolSide, connectionType);

    // Immediately set the kSSLSessionOptionBreakOnServerAuth option in order to disable cert validation
    original_SSLSetSessionOption(sslContext, kSSLSessionOptionBreakOnServerAuth, true);
    return sslContext;
}

Patch SSLSetSessionOption(): Remove the ability to re-enable the built-in certificate validation

SSLSetSessionOption() can be called to set the value of specific options on a given SSL context. The tweak patches this function in order to prevent the kSSLSessionOptionBreakOnServerAuth from being set to any value. The goal here is to ensure that all SSL contexts keep the default value of ``true’’ for the kSSLSessionOptionBreakOnServerAuth option (as set in the previous section):

static OSStatus replaced_SSLSetSessionOption(
    SSLContextRef context,
    SSLSessionOption option,
    Boolean value
 ) {
    // Remove the ability to modify the value of the kSSLSessionOptionBreakOnServerAuth option
    if (option == kSSLSessionOptionBreakOnServerAuth)
        return noErr;
    else
        return original_SSLSetSessionOption(context, option, value);
}

Patch SSLHandshake(): Force a trust-all custom certificate validation

Lastly, SSLHandshake() is modified in order to prevent this function from ever returning errSSLServerAuthCompleted, which is the return value that will trigger the caller’s certificate checking/pinning code:

static OSStatus replaced_SSLHandshake(
    SSLContextRef context
) {
    OSStatus result = original_SSLHandshake(context);

    // Hijack the flow when breaking on server authentication
    if (result == errSSLServerAuthCompleted) {
        // Do not check the cert and call SSLHandshake() again
        return original_SSLHandshake(context);
    }
    else
        return result;
}

That’s it ! After patching those three functions, certificate validation was disabled in all the applications that I tried including Safari, Twitter, Square as well as the iTune App Store (with a few additional steps).

Project page

Have a look at the full code by browsing to the project page on GitHub.

A new version of SSLyze is now available. SSLyze is a Python tool that can analyze the SSL configuration of a server by connecting to it.

Changelog

• Complete rewrite of the OpenSSL wrapper as a C extension
  • SSLyze is now statically linked with the latest version of OpenSSL instead of using the system’s (potentially outdated/broken) OpenSSL library
  • All of SSLyze’s features are now available on all supported platforms (including SSL 2.0, TLS 1.1 and TLS 1.2)
  • Scans are slightly faster
  • Python 2.6 is no longer supported
• Support for StartTLS FTP, POP, IMAP, LDAP and “auto”. See –starttls
• Support for OCSP Stapling. See –certinfo
• Other various improvements that results in SSLyze being more stable/robust

Packages

SSLyze requires Python 2.7; the supported platforms are Windows 7 32/64 bits, Linux 32/64 bits and OS X 64 bits. SSLyze is statically linked with OpenSSL 1.0.1e. For this reason, the easiest way to run SSLyze is to download one the following pre-compiled packages:

Linux

The following packages were tested on Debian 7 and Ubuntu 13.04.

• Package for Python 32 bits
• Package for Python 64 bits

OS X Mountain Lion

• Package for Python 64 bits

Windows 7

• Package for Python 32 bits
• Package for Python 64 bits