Wednesday, March 28, 2012 At 9:21AM
It is a fairly common occurrence to encounter iOS applications that are logging sensitive data during mobile application security assessments. Some examples of sensitive data we have seen logged include authentication tokens, session cookies, passwords, etc. We have also noticed that developers sometimes do not fully understand the implications of logging this data using the NSLog function. Lets walk through some of these misconceptions.
1. NSLog data is only displayed in the device console and not stored on the device.
When writing an iOS application, developers commonly use NSLog for debugging purposes and the data is displayed within the device console provided by XCode. Behind the scenes, the data passed to the NSLog function is logged using the Apple System Log (ASL), which is Apple’s alternative for syslogd. On iOS devices, the data logged using ASL appears to be cached until the device is rebooted.
2. NSLog data cannot be read by other applications.
The Apple System Log C library (asl.h), which is available for Mac OS X, is also available on iOS. This library can be used to print out the contents of the ASL and even perform queries to retrieve specific log data. An example of a query would be querying for data logged by specific applications. One might ask, what about the iOS sandbox? Shouldn’t the sandbox prevent applications from accessing data logged by another application? Unfortunately, the iOS sandbox does not protect the ASL and therefore any application is able to view the data logged by another application. The following documentation details the ASL API for writing, reading and querying data from the ASL:
3. iOS prevents applications from utilizing these low level C APIs during their submission review process.
Unfortunately, it does not look like Apple has a strict restriction on iOS applications utilizing the ASL C library in order to retrieve data from the ASL. There are applications currently in the App Store that are able to read and perform queries on ASL data. One example of such an application is the “AppSwitch” application.
So let us recap,
iOS application data logged using NSLog utilizes the Apple System Log (ASL) which caches the data logged until the device is rebooted
The ASL data can be read and queried through a C API available for iOS applications. This API is not restricted by Apple’s application review process.
The ASL data is not sandboxed and therefore any iOS application can read data logged by arbitrary applications
Due to all these conditions, logging sensitive data using NSLog should be considered a fairly high-risk issue. If applications are logging sensitive authentication data, a malicious application would be able to actively query for this data and send it off to a remote server.
Developers should get in the habit of using a preprocessor macro for performing any logging used during the development process. The following blog post provides a nice walkthrough on how to utilize NSLog when building in DEBUG mode and how to remove all NSLog statements within production builds.
Author: Ron Gutierrez
©Aon plc 2023