[attachment=14321]
Auditting iPhone and iPad applications
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:
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
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://mobileorchardapple-approved-iphone-inter-process-communication/
url handler’s / IPC
info.plist file:


code looks like:


url handler’s / IPC
any webpage can call that page 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.applekb/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:openURLourceApplication: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:
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 ?