Monday, 16 July 2012

No source? No problem...

When performing any kind of product assessment, it is always preferable to have the source code. However, in the real world we all know that this isn't always possible and as a security consultant we have to be prepared to use both static and dynamic analysis to reverse engineer what a product is doing. While these approaches are fairly well documented for run-of-the-mill binary applications, there is far less published research available for mobile apps.

Over the last few years, MDSec have been regularly performing a mixture of both whitebox and blackbox mobile app reviews. During the course of these assessments we have developed a comprehensive toolset to help automate some of the tasks that need to be performed. One such weapon from our arsenal is "iAuditor", a tool to provide semi-automation of blackbox mobile app tests.

What is iAuditor?
iAuditor is a command line tool that can be used on a jailbroken iOS device to "peak" inside other apps. It uses MobileSubstrate to hook Objective-C APIs and evaluate if they are being used in a secure manner. iAuditor is "semi-automatic" because it requires the user to go and navigate the app while iAuditor is injected in to the runtime. This user-driven approach allows wide coverage of the application features.

What does it check for?
Currently, we've implemented checks for the following common issues:
  • Accepting self-signed certificates
  • Use of protocol handlers
  • Connecting to clear-text URLs
  • Writing to the file-system
  • Permitting external XML entities
  • Address book access
  • Logging with NSLog
  • Use of GeoLocation
The hooks are implemented within the LibiAuditor dynamic library that should be placed in the MobileSubstrate directory under "/Library/MobileSubstrate/DynamicLibraries". When a method is hooked, the hook will evaluate the issue and write an entry in to the iAuditor database which is stored in the relevant apps "Documents" directory.

Let's look at an example:
CHOptimizedMethod(1, self, BOOL, NSURLConnection, continueWithoutCredentialForAuthenticationChallenge, NSURLAuthenticationChallenge *, challenge)
    NSString *issueTitle = @"Self Signed Certificates Permitted";
    NSString *issueDesc = [NSString stringWithFormat:@"The application permitted a self-signed certificate when attempting to connect the host %@.", [challenge.protectionSpace host]];
    Database *iadb = [[Database alloc] init];
    [iadb setName:issueTitle];
    [iadb setDescription:issueDesc];
    [iadb addIssue];
    [iadb release];
    return CHSuper(1, NSURLConnection, continueWithoutCredentialForAuthenticationChallenge, challenge);
The above example shows how to hook the "continueWithoutCredentialForAuthenticationChallenge" delegate method of NSURLConnection. This method may be called when an application is configured to accept a self-signed certificate. The issue is then added to the iAuditor database using the "addIssue" method. Finally, the return value calls the original function, allowing the application to continue as normal.

Finally, let's take a look at iAuditor in action:

As this is the first release, there will probably be some bugs to iron out; bug reports, feature requests and/or general flames are welcome!

Download it
The iAuditor binary release can be downloaded from the the research section of MDSec's website, here.

Alternatively, the source is available on our GitHub repository.

Sunday, 8 July 2012

BlackHat USA 2012 - MDSec's WAHH Live Training

MDSec will be delivering the WAHH live training course at BlackHat USA again this year. The course syllabus follows the chapters of the Second Edition of The Web Application Hacker's Handbook, with strong focus on practical attacks and methods.

So if you're a fan of the original book want to try your hand exploiting everything in the new Second Edition, you're in luck.

Did we mention Burp Suite? If you want to learn from the author of Burp, you're in luck again.

We have run courses for over 5 years at BlackHat, and we know what you want. This structured course is balanced at 120 slides with numerous opportunities to watch instructor-led demos, whilst hacking our library of over 150 lab exercises, spanning .Net, J2EE, PHP and finishing with a "Capture the Flag" contest.

Register online now, while there are still places available!

Thursday, 10 May 2012

Introduction to iOS Platform Security

This if the first in a series of blog posts about iOS and iOS platform security, encompassing and expanding on the MDSec iOS Application (In)Security whitepaper.
In this post, MDSec provides some background information on the iOS platform and a brief introduction to the core security features of iDevices.

The core security features of the iOS platform can be summarised as:
  • Code Signing
  • Generic native language exploit mitigations
    • Address Space Layout Randomisation
    • Non executable memory
    • Stack Smashing Protection
  • Process level sandboxing
    • Also known as Seat Belt
  • Data at rest encryption
A comprehensive review of these features can be found within the whitepaper “Apple iOS 4 Security Evaluation” by Dino Dai Zovi [1] which provided much of the foundation for the details discussed.

Code Signing
Code signing is a runtime security feature of the platform that attempts to prevent unauthorised applications running on the device by validating the application signature each time it is executed. Additionally, applications may also only execute code signed by a valid, trusted signature.
For an application to be run on the device, it must first be signed by a trusted certificate. Developers can install trusted certificates on a device through a provisioning profile signed by Apple. The provisioning profile contains the embedded developer certificate and set of entitlements that the developer may grant to applications. In production applications, all code must be signed by Apple, this is performed during the AppStore submission process. This process allows Apple some degree of control over apps and to govern the APIs and functionality used by developers. For example, Apple looks to prevent apps using private APIs or downloading to installing executable code [2].

Exploit Mitigation Features
Address Space Layout Randomisation (ASLR) [3] is a security feature that attempts to increase the complexity of vulnerability exploitation by randomising where data and code is mapped in a processes address space. ASLR was first introduced to iOS in version beta 4.3 and since inception has gradually improved with each release. The primary weakness in the ASLR implementation was the lack of relocation of the dyld, this was addressed with the release of iOS 5.0. Applications can have ASLR applied in two different flavours, either partial ASLR or full ASLR depending on whether they have been compiled with support for Position Independent Execution (PIE). In a full ASLR scenario, all the application memory regions are randomised and iOS will load a PIE enabled binary at a random address each time it is executed. An application with partial ASLR will load the base binary at a fixed address and use a static location for the dynamic linker (dyld). An in-depth assessment of ASLR in iOS has been conducted by Stefan Esser and is recommended reading for those looking to gain a greater understanding [4].

ASLR is designed to frustrate exploitation due to the lack of knowledge an attacker will have of the process layout in memory and thus the addresses they need to target. However, there are a number of techniques that can weaken its effectiveness. The most common of these techniques is memory revelation. This is where a separate vulnerability is used to leak or confirm memory layout to an attacker prior exploitation of a vulnerability that will yield arbitrary code execution.

In an attempt to further mitigate exploitation of native language vulnerabilities, iOS combines ASLR with the implementation of a “W^X” non-executable memory policy, meaning that memory pages cannot be marked as writeable and executable at the same time. As part of this policy, executable memory pages that are marked as writeable cannot also be later marked back to executable. In many ways this is similar to the Data Execution Protection (DEP) features implemented by Microsoft Windows, Linux and Mac OS X desktop OS’. While non-executable memory alone can be trivially bypassed using Return Orientated Programming (ROP) based payloads, the complexity of exploitation is significantly increased when compounded with ASLR and Mandatory Code Signing.

iOS applications can look to add additional exploit mitigation at compile time through stack smashing protection. Stack canaries in particular introduce some protection against buffer overflows by placing a random, known value before the local variables. The stack canary is checked upon return of the function. If an overflow occurs and the canary is corrupted, the application is able to detect and protect against the overflow.

All third party applications on iOS run within a sandbox; this is a self-contained environment that isolates applications not only from other applications but also the operating system. While applications all run as the “mobile” operating system user, they are contained within a unique directory on the filesystem and separation is maintained by the XNU Sandbox kernel extension.  The operations that can be performed in the sandbox are governed by the seatbelt profile. Third party applications are assigned the “container” profile which will generally limit file access to the application home directory, allow read access to media, read and write to the address book as well as unrestricted access to outbound network connections, with the exception of launchd’s network sockets. See “The Apple Sandbox” [5] for recommended further reading.

By default, all data on the iOS filesystem is encrypted using block-based encryption (AES) with the File System Key, which is stored on the flash. The filesystem is encrypted only at rest; when the device is turned on the hardware based crypto accelerator unlocks the filesystem.
In addition to the hardware encryption, individual files and keychain items can be encrypted using the Data Protection (DP) API that uses a key derived from the device passcode. Consequently, when the device is locked, content encrypted using the DP API will be inaccessible unless cached in memory. Third party applications wishing to encrypt sensitive data should employ the Data Protection API to do so. However consideration should be given for background processes how they will behave if the at-rest becomes unavailable due to the device becoming locked.

[1] Apple iOS 4 Security Evaluation – Dino Dai Zovi
[2] iOS Standard Agreement
[3] Address Space Layout Randomization
[4] Steffan Esser’s ASLR Research
[5] Apple Sandbox - Dionysus Blazakis

Wednesday, 2 May 2012

iOS Application (In)Security Whitepaper

Today MDSec released a whitepaper detailing some of the vulnerabilities we've observed over the past year while performing regular security assessments of iPhone and iPad applications.

This whitepaper details some of the vulnerabilities identified as well as the methods to exploit them, and recommendations that developers can adopt to protect their iOS applications. It covers not only the security features of the platform, but provides in depth information on how to perform both black box and white box iOS penetration tests, along with suggested methodologies and compliance.

The whitepaper is available free of charge, as a download from the MDSec website:
Download it now

Monday, 2 April 2012

Beyond the OWASP Top 10

We recently had the pleasure of presenting at OWASP Ireland. The following talk discusses some of the issues we've identified during pentests that don't easily slot in to the categories provided by the OWASP top 10.

iOS Application (in)Security

We recently had the pleasure of talking about iOS application security at OWASP Ireland, the slides for our presentation are below:

Friday, 24 February 2012

MDSec @ Countermeasure 2012

MDSec are proud to announce the Web Application Hacker's Handbook training course will be running at Countermeasure 2012!

The course syllabus follows the chapters of the Second Edition of The Web Application Hacker's Handbook, with a strong focus on practical attacks and methods.

The course will be running October 22-24 2012 and places can be booked online via the Countermeasure website.

Thursday, 2 February 2012

Evaluating iOS Applications

We recently presented at the Manchester OWASP chapter on Evaluating iOS Applications. Thanks to everyone involved, it was a great evening. Our slides can be found below:Evaluating iOS Applications