Developers commonly need log statements in their apps to track down problems by printing out information about the current program state. However, this can also lead to serious information disclosure to third parties, as many developers still use the old NSLog statement in about 40% of the Top 2000 German iOS apps. Many developer sites state, that information logged with NSLog will not be persisted on the device and therefore the usage is not critical. However, that’s not correct as we will demonstrate in the following for current iOS devices.
Over the years, Apple has changed a lot under the hood of iOS. Likewise the logging mechanism has changed in multiple aspects. One major change was the introduction of unified logging with iOS 10, which provides log levels, information hiding for sensitive entries and many other configuration capabilities. However, these new feature are only usable if the new os_log macro is used.
When using NSLog, the log messages are stored with default log level persistently for a certain time, which was tested with iOS 12.4, iOS 13.3 and 13.4 on non-jailbroken devices. Depending on the usage intensity of the iOS device, the stored log messages can go back days or months.
Log entries on these iOS devices are stored system-wide in the directory /var/db/diagnostics/Persist in files of the tracev3 binary format, which can be made readable again e.g. with the OSX log tool or platform independent wth UnifiedLogReader. The stored database files are protected by iOS DataProtection class NSFileProtectionCompleteUntilFirstUserAuthentication with the device passcode until the first user’s logon and can only be read by the administrative user root.
This means, in a lost-device scenario for an iOS device without passcode, these logging outputs can be read directly via USB using the iOS sysdiagnose function. If a passcode is set, the passcode is required to read the logging outputs.
However, since users are often asked to send the sysdiagnose data to Apple or App developers (see instructions e.g: https://faq.pdfviewer.io/en/articles/1458505-ios-how-to-send-a-sysdiagnose), in this case third parties will get access to log messages of all utilized apps (within the persisted time frame).
Among many other debug information, the transmitted file sysdiagnose_[date]_iPhone_OS_[device].tar.gz contains the file system_logs.logarchive. It is compressed and needs to be converted first to make use of it. This can be done quite easy on OSX.
The file system_logs.logarchive can be viewed on OSX with the log command:
log show system_logs.logarchive --info --debug > logs.txt
To use the UnifiedLogReader instead, one first has to extract the files from the system_logs.logarchive to a folder and start the python script inside this folder like this, e.g. on Windows systems:
python [path_to]\UnifiedLogReader.py .\ .\timesync\ .\Persist [output_folder]
In the output file logs.txt, one can search for the app binary name to find the related log messages. In the following example the binary is called TestApp:
2020-03-25 15:18:19.707346+0100 0x517db Default 0x0 737 0 TestApp: My NSLog example GPS: {"geoData": {"latitude": 49.xxx, "longitude": 8.xxx, "radius": 2.818104}, "filters": {}, "exclude": []} 2020-03-25 15:18:25.635420+0100 0x517db Default 0x0 737 0 TestApp: My NSLog example GPS: {"geoData": {"latitude": 49.xxx, "longitude": 8.xxx,"radius": 5.515101}, "filters": {}, "exclude": []} 2020-03-25 15:18:28.657474+0100 0x517db Default 0x0 737 0 TestApp: My NSLog example GPS: {"geoData": {"latitude": 49.xxx, "longitude": 8.xxx,"radius": 10.625031}, "filters": {}, "exclude": []}
In these log messages, we often find GPS-positions along with email addresses, generated encryption keys, full credit card information and much more entered user content. Even for apps that primarily do not store sensitive data, the log can also reveal sensitive information such as sensitive app names, their installation dates and how and what was used inside the apps.
From a user’s perspective, it should now be clear:
- Do not send sysdiagnose data to anyone!
- Deny access for Apple (see https://support.apple.com/en-us/HT202100), however, this does not disable the logging nor does this disable the possibility to create sysdiagose files.
- Use a good passcode to make it harder to access these files unauthorized.
But the best protection is to use apps, that don’t store sensitive data to logfiles!
So, make a test for yourself and inspect your sysdiagonse file to learn more about your apps and the things they store.
Developers should take a look at iOS Unified Logging with the os_log macro. It can be used to programmatically enable a persistent storage only for cases when needed for remote debugging (if that’s necessary at all). For all other cases it can be configured to use only console output, preventing a data leakage via persitent log files.