Stealing the entire filesystem from an iOS device can give you a sobering look into the sheer quantity of data cached by these devices. Many reasonably secure applications in the App Store don’t leak data on their own, but still suffer from data leaks because they are subject to Apple’s caching, including the keyboard cache (which caches every secure email or other message typed in), the WebKit cache (which caches many web data views displayed in the application), and other facilities working against the security of the application. This isn’t done intentionally, of course, but rather is the side effect of innocently creating a seamless integrated experience. Depending on what other components of iOS your application uses, your application may also be subject to data leakage in many forms, which could result in theft of data from an otherwise secure app.
This chapter contains excerpts from a private law enforcement training manual I use to train federal agents and local police worldwide. Portions have been rewritten and geared toward developers to understand how an attacker might steal otherwise secure data from a device. It’s necessary to have a full understanding of the extent of data that can be stolen by an attacker, and give you (the developer) a list of nooks and crannies to look in to help ensure your application isn’t being compromised by any of iOS’ integration features. In reviewing your own company’s applications, it is strongly recommended that you analyze a full disk image from a device that has been running your apps to scan for forensic trace. You might be surprised to find corporate data you thought was once secure is now bleeding into other areas of the operating system.
Your own application and its data are stored in the Applications folder inside the mobile user’s directory. There, you’ll find all of the information pertaining specifically to your application. This chapter chronicles all of the information you’ll find throughout the rest of the user data disk, which may contain clear text copies of some of your own application’s data. We saw in Chapter 3 how to extract the data described in this chapter.
Some data cannot be helped but written to the caches, and so the only way to ensure that it doesn’t wind up in a clear text copy outside of your application is to know what data gets written, and avoid writing it all together. This chapter identifies many such types of data, so that you can determine the best way to integrate your application into the operating system.
Other forms of data leakage can also affect the security of an application—many of which are within the developer’s control. These range from the handling of geotagged data to failing to properly wipe deleted records from a SQLite database. All of these data leaking scenarios will be covered in this chapter.
You’re probably familiar with the capability of iPhone and iPad devices to not only take photos, but tag them with the user’s current location. Geotagging is the process of embedding geographical metadata to a piece of media, and iOS devices do this with photos and movies. Devices with onboard cameras can embed exact longitude and latitude coordinates inside images taken. Geotagging can be disabled when photos are taken, but in many cases, the user may either forget to disable it or fail to realize its consequences. Photos taken through a third-party application don’t, by default, cause geotags to be written to pictures, but an application could use the GPS to obtain the user’s location and add the tags itself. Sending photos from a user’s library to an insecure network destination will result in these tags being sent as well.
If your application saves geotags when using the camera, this data may be leaked into the photo reel. This could prove problematic for applications running in secure facilities, such as government agencies and secure research facilities with SCIFs.
Exifprobe is a camera image file utility developed by Duane Hesser. Among its features is the ability to extract an image’s exif tags. Download Exifprobe from http://www.virtual-cafe.com/~dhh/tools.d/exifprobe.d/exifprobe.html.
To check an image for geotags, call exifprobe on the command line:
If the image was tagged, you’ll see a GPS latitude and longitude reported, as shown here:
JPEG.APP1.Ifd0.Gps.LatitudeRef = 'N' JPEG.APP1.Ifd0.Gps.Latitude = 42,57.45,0 JPEG.APP1.Ifd0.Gps.LongitudeRef = 'W\000' JPEG.APP1.Ifd0.Gps.Longitude = 71,32.9,0
The longitude and latitude coordinates are displayed here as degrees, minutes, and seconds. To convert this to an exact location, add the degree value to the minute value divided by 60. For example:
57.45 / 60 = 0.9575 + 42 = 42.9575 32.9 / 60 = 0.54833 + 71 = 71.54833
In this example, the photo was taken at 42.9575,-71.54833.
On a Mac, the Preview application includes an inspector that can be used to graphically pinpoint the location without calculating the tag’s GPS value. To do this, open the image and select Inspector from the Tools menu. Click the information pane, and the GPS tag, if present, will appear, as shown in Figure 4-1. Clicking on the locate button at the bottom of the inspector window will display the coordinates using the Google Maps website.
You’ll also find tags showing that the image was definitively taken by the device’s built-in camera. If the image was synced from a desktop (or other source), the tag may describe a different model camera, which may also be useful:
JPEG.APP1.Ifd0.Make = 'Apple' JPEG.APP1.Ifd0.Model = 'iPhone'
The timestamp that the actual photo was taken can also be recovered in the image tags, as shown below:
JPEG.APP1.Ifd0.Exif.DateTimeOriginal = '2008:07:26 22:07:35' JPEG.APP1.Ifd0.Exif.DateTimeDigitized = '2008:07:26 22:07:35'
The consolidated GPS cache can be found as early as iOS 4 and is
located in /private/var/root/Caches/locationd/consolidated.db.
This cache contains two sets of tables: one set of harvest tables, fed
into the device from Apple, and one set of location tables, sent to
Apple (Figure 4-2). The
harvest tables assist with positioning of the device. The
CellLocation tables contain information cached
locally by the device and include WiFi access points and cellular towers
that have come within range of the device at a given time, and include a
horizontal accuracy (in meters), believed to be a guesstimate at the
distance from the device. A timestamp is provided with each
provides a number of MAC addresses corresponding to access points seen
at the given coordinates. This too can be useful in pinpointing the
location of a device at a given time, and also help to determine which
access points were within range. Regardless of whether the user
connected to any given wireless network, the MAC address and location
could still be harvested when the GPS is active. This should be of
particular concern when activating the GPS within wireless range of a
The data in these tables do not suggest that the device’s owner connected to, or was even aware of the towers or access points within range. The device itself, rather, builds its own internal cache, which it later sends to Apple to assist with positioning. Think of this cache as a war-driving cache, and each GPS-enabled iOS device as Apple’s personal war driver.