Auditting iPhone and iPad applications

Auditting iPhone and iPad applications

Ilja van Sprundel <ivansprundel@ioactive.com>

Who am I

Ilja van Sprundel IOActive netric blogs.23.nu/ilja

What this talk is[n’t] about

is: common security issues seen in 3rd party iOS applications possible fix or mitigation of them document how to exploit them in some cases isn’t: bugs in iOS itself to some extend it does cover some api shortcomings

Introduction

Mobile app market exploded over the last 2 years lots of demand for security reviews of iPhone and iPad apps over the last year or so Very little has been published I’ve done a number of them in the last 10 months notes of what I’ve learned so far

Application environment

native applications iOS, port of MacOSX to arm cpu obj-c (strict c superset) obj-c classes take care of most low level handling (memory allocations, ....)

Transport security

fair amount of iOS apps need to do secure transactions online banking, online trading, ... They will use SSL use of https:// urls passed to NSURLRequest / NSURLConnection api uses a set of default ciphers:

Transport security

Transport security

TLS_RSA_WITH_DES_CBC_SHA TLS_RSA_EXPORT_WITH_RC40_MD5 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA

Transport security

on by default no (documented) way to turn it off this is (kinda) documented:

from apple’s Secure Coding Guide (2010-02-12), page 29

Transport security

SSL api’s on iOS aren’t granular enough developer should be able to set ciphersuites can’t fix it, but you can mitigate it include an ssl library and use that one (e.g. CyaSSL and MatrixSSL are build for embedded use)

Transport security

documentation said secure trasport programming not available, use CFNetwork CFNetwork doesn’t allow setting ciphersuites (AFAIK) it does have api’s for some other things: allow expired certs allow expired roots allow any root don’t validate certificate chain

Transport security

NSMutableDictionary *settings = [[NSMutableDictionary alloc] init];[settings setObject:[NSNumber numberWithBool:YES] forKey:(NSString *)kCFStreamSSLAllowsExpiredCertificates];[settings setObject:[NSNumber numberWithBool:YES] forKey:(NSString *)kCFStreamSSLAllowsExpiredRoots];[settings setObject:[NSNumber numberWithBool:YES] forKey:(NSString *)kCFStreamSSLAllowsAnyRoot];[settings setObject:[NSNumber numberWithBool:NO] forKey:(NSString *)kCFStreamSSLValidatesCertificateChain];CFReadStreamSetProperty((CFReadStreamRef)inputStream, kCFStreamPropertySSLSettings, (CFDictionaryRef)settings);CFWriteStreamSetProperty((CFWriteStreamRef)outputStream, kCFStreamPropertySSLSettings, (CFDictionaryRef)settings);

Transport security

Luckily none of that is on by default! takes quite some work to screw this up for a developer however it’s not unthinkable: “wait, we shipped that debug code ???”

url handler’s / IPC

By design iPhone does not allow sharing between applications application developers sometimes need to share anyway developers (initially)found a way around this This now appears to be supported by apple (according to developer.apple.com)

url handler’s / IPC

Application can register a url handler other application would call url, with data rather simple IPC mechanism http://mobileorchard.com/apple-approved-iphone-inter-process-communication/

url handler’s / IPC

info.plist file: code looks like:

- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url { [viewController handleURL:url]; return YES; }

url handler’s / IPC

any webpage can call that link too any webpage can now also do IPC with the application this IPC mechanism clearly had unintended consequences

url handler’s / IPC

so the browser can call the url handlers too wouldn’t it be neat if we could get it done without tricking a user into visiting a webpage from their mobile safari ?

url handler’s / IPC

iOS 3 (and beyond) has this neat wifi hotspot feature if it connects to a wifi network, and detects redirection, it assumes it’s a wifi hotspot pops up mobile safari, and goes to the redirected page see http://support.apple.com/kb/HT3867

url handler’s / IPC

looks like this:

url handler’s / IPC

Attack is quite simple you must be on the same lan knock iOS device off the network when it rejoins, forge the redirect to your webpage

url handler’s / IPC

on by default you can turn it off (on iOS 4)

url handler’s / IPC

Starting from iOS 4.2 there is newer api that should be used application:openURL:sourceApplication:annotation from the documentation:

url handler’s / IPC

OpenURL is a much more elegant api for IPC shows you who’s calling (so you can reject the browser for example) allows passing of object instead of serializing over url arguments

UIWebView

can be used to build gui (mostly in web-like environments) basically renders html (can do javascript!) a browser window more or less

UIWebView

Vulnerable to attack (if used as a gui) if attacker can inject unescaped data will lead to Cross site scripting

UIWebView

by default there is no bridge from UIWebView’s javascript to actual obj-c most iOS apps developers that use UIWebView (for gui’s) would like there to be one url handler, only valid for that specific UIWebView shouldStartLoadingWithRequest: method

UIWebView

that url handler can do anything you want it to do most UIWebView’s url handler are used to handle some internals, arguments are considered trusted! even worse, a lot of them serialize/unserialize a methodname and parameters !

UIWebView

UIWebView

if used simply as a browser can do a lot more than render html and interact with a webapplications can parse and render a large number of file formats (and will not prompt user first!)

UIWebView

Excel (xls) keynote (.key.zip) (and also zip files) numbers (.numbers.zip) Pages (.pages.zip) pdf (.pdf) powerpoint (.ppt) word (.doc) rtf (.rtf) / rtf dictionary (.rtfd.zip) keynote ’09 (.key) numbers ’09 (.numbers) pages ’09 (.pages)

UIWebView

Very long list enormously difficult file formats to parse once parsed it gets rendered as html in the current DOM apple api’s, but they are in proc ! on by default no way to turn this off

UIWebView

does a number of other things: e.g. try to detect phone numbers and turns them into tell:// url’s you can turn this off set detectPhoneNumbers property to NO

UIWebView

mitigation: render out of proc give url to safari instead of rendering in UIWebView attack surface reduction if a bug gets exploited now, your application is no longer affected.

UIImage

Wide attack surface very similar to UIWebView’s UIImage is a general image class can handle a _LOT_ of image file formats

UIImage

tiff jpeg png bmp ico cur xbm gif

UIImage

not to mention some extensions that work with various image file formats: exif ICC profiles

UIImage

Huge attack surface there is no property to specify which one you want and which you don’t want

UIImage

2 possible workaround UIImage allows using CGImageRef use more low-level Core Graphics library to specifically load jpg or png then feed the CGImageRef to UIImage

UIImage

or you could just look at the first couple of bytes of the image file each graphics format is trivial to detect based on some magic bytes in the begining for example: png signature: 137 80 78 71 13 10 26 10 (decimal) jpg signature: 4A 46 49 46 GIF signature: 47 49 46 38 39 61 or 47 49 46 38 37 61 BMP: first 2 bytes: “BM”

header / xml injection

not iOS specific, however rampant in mobile apps mostly with regards to interacting with webservices dev’s implement their own http handing stuff forget things like escaping \r, \n, “, ...

header / xml injection

Consider the following example:

- (NSData *)HTTPHdrData { NSMutableString *metadataString = [NSMutableString string]; [metadataString appendString:@"Content-Disposition: form-data"]; if (self.name) [metadataString appendFormat:@"; name=\"%@\"", self.name]; if (self.fileName) [metadataString appendFormat:@"; filename=\"%@\"", self.fileName]; [metadataString appendString:@"\r\n"]; if (self.contentType) [metadataString appendFormat:@"Content-Type: %@\r\n", self.contentType]; … return result; }

header / xml injection

iOS has some decent api’s for this NSMutableURLRequest addValue:forHTTPHeaderField setValue:forHTTPHeaderField not vulnerable to injection although they do fail silently if injection is detected

Format string bugs

iPhone apps use obj-c which is native code however, if you stick to the obj-c syntax and the classes provided, chances of overflows and the like are small (the provided classes can do almost anything you want) provided classes also have format based functions

Format string bugs

these formatstring functions can also lead to formatstring bugs seems most iOS apps are riddled with it most iOS apps developers don’t seem to know this is a problem

Format string bugs

vulnerable obj-c methods NSLog() [NSString stringWithFormat:] [NSString initWithFormat:] [NSMutableString appendFormat:] [NSAlert informativeTextWithFormat:] [NSPredicate predicateWithFormat:] [NSException format:] NSRunAlertPanel

Format string bugs

obj-c is a superset of c so all c fmt functions could also be abused in iOS apps: printf snprintf fprintf ...

exploiting NS* format string bugs

These aren’t the format string bugs you’re looking for NS* object format functions are slightly different from the printf* style ones They don’t support %n can’t write to arbitrary addresses ?

Exploiting bugs

binary protocol handling

said before obj-c superset of c stick to NS* objects, mostly safe binary protocol handling is sort of the exception no good obj-c classes for that developers have to fall back to old c-style binary protocol parsing.

Directory traversal

iOS has similar file api’s as MacOSX same types of desktop/server os file issues NSFileManager

Directory traversal

classic dir traversal: ../../../../ will work.

NSString *file = [[NSString alloc] initWithFormat: @"%@/%@", NSTemporaryDirectory(), attackerControlledString]; NSFileManager *m = [NSFileManager defaultManager]; [m createFileAtPath:text contents:nsd attributes:nil];

Directory traversal

Poison NULL byte ../../../../blahblah\0 This works, because NSStrings don’t use 0-bytes to terminate a string, but the iOS kernel does.

NSString *file = [[NSString alloc] initWithFormat: @"%@/%@.ext", NSTemporaryDirectory(), attackerControlledString]; NSFileManager *m = [NSFileManager defaultManager]; [m createFileAtPath:text contents:nsd attributes:nil];

NSXMLParser

NSXMLParser is the class used to parse xml files it handles DTD’s by default billion laughs no way to turn it off doesn’t resolve external entities by default can be turned on

NSXMLParser

There’s kindof a hairy workaround. 6 callbacks can be defined, that will be called if a DTD is encountered. foundElementDeclarationWithName foundAttributeDeclarationWithName foundInternalEntityDeclarationWithName foundExternalEntityDeclarationWithName foundNotationDeclarationWithName foundUnparsedEntityDeclarationWithName

NSXMLParser

- (void) parser:(NSXMLParser*)parser foundExternalEntityDeclarationWithName:(NSString*)entityName { [self abort:@"DTD"]; } - (void) parser:(NSXMLParser*)parser foundAttributeDeclarationWithName:(NSString*)attributeName ... { [self abort:@"DTD"]; } - (void) parser:(NSXMLParser*)parser foundElementDeclarationWithName:(NSString*)elementName model:(NSString*)model { [self abort:@"DTD"]; } - (void) parser:(NSXMLParser*)parser foundInternalEntityDeclarationWithName:(NSString*)name value:(NSString*)value { [self abort:@"DTD"]; } - (void) parser:(NSXMLParser*)parser foundUnparsedEntityDeclarationWithName:(NSString*)name ... { [self abort:@"DTD"]; } - (void) parser:(NSXMLParser*)parser foundNotationDeclarationWithName:(NSString*)name publicID:(NSString*)publicID ... { [self abort:@"DTD"]; }

NSXMLParser

This works, but it’s hairy and error prone it would be nice if NSXMLParser had a parseDTD attribute

Questions