The Android Logging Service – A Dangerous Feature for User Privacy?

Posted on by

The Android logging mechanism is used by many Android applications. Even the Android framework uses this mechanism for outputting debug information. But does this logging mechanism also include private information? This article gives a short overview of the privacy-sensitive information that could be gathered from the Android logging mechanism. It also describes Google’s countermeasure of accessing the “log file” since Android 4.1 and what kind of possibilities an attacker still has.

Android provides a mechanism for reading and writing log entries, which is especially of interest for debugging purposes. A developer can use the command-line tool LogCat for viewing the internal logs. It includes things such as stack traces when the device/emulator throws an error and messages that the developer has written from her application by using the Log class. This class contains different kinds of methods for the different logging level – verbose, debug, error, info and warning. For instance, if a developer wants to create an error log entry, she can use the method e in the Log class:

Log.e("ERROR", "This line should have never been called");

To view the log entries, she can use the LogCat command-line tool provided by the Android Tools (SDK). When the mobile device is connected to the PC, the LogCat tool can be started by the PC via adb logcat (note there are also other possibilities) and the error log entry above would look like:

E/ERROR   (19077): This line should have never been called

But why is logging a privacy concern?

The log entries can include messages with harmless information such as the one above, but we found that in practice many messages include privacy-related information such as e-mail addresses, passwords, contact information, SMS/MMS, etc. This information can be written into the log by Android applications, but also by the Android framework or pre-installed apps. We tested the logging behavior with a vanilla Nexus 4 (version 4.2) and made some interesting findings. Exemplarily, we show a few of them:

Navigation Information

If the mobile-device user uses the Google Maps App for navigation purpose, Google internally calls a URL which includes the source and destination address of the user’s input. These URL can be read in the “log file”:

I/ActivityManager(526): START u0 {act=android.intent.action.VIEW dat=google.navigation:///?ll=49.872600,8.636720&q=Alexanderplatz, Berlin&token=Fdj–AIdMMmDACmJjSWej3C9RzGzM32OzZezHw&entry=w&opt= cmp=com.google.android.apps.maps/com.google.android.maps.driveabout.app.NavigationActivity} from pid 22056

The two double numbers after the “ll=” are the longitude and latitude of the source and the information after “q=” is the destination address.

Bluetooth Information

After the enabling of bluetooth the following information is stored into the “log file”:

05-17 13:41:36.346: I/hci_qcomm_init(25522): BTS_DEVICE=/dev/ttyHS0;
05-17 13:41:36.346: I/hci_qcomm_init(25522): BTS_BAUD=3000000;
05-17 13:41:36.346: I/hci_qcomm_init(25522): BTS_TYPE=qualcomm;
05-17 13:41:36.346: I/hci_qcomm_init(25522): BTS_ADDRESS=98:d6:f7:af:b9:32;

The bluetooth address is written in clear text.

Wifi information

After the access into a wifi network, the following information is stored into the “log file”:

05-17 13:45:33.069: I/wpa_supplicant(25862): wlan0: Trying to associate with 00:26:99:4f:ee:40 (SSID=’eduroam’ freq=2437 MHz)
05-17 13:45:33.149: I/wpa_supplicant(25862): wlan0: Associated with 00:26:99:4f:ee:40
05-17 13:45:33.149: I/wpa_supplicant(25862): wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
05-17 13:45:33.149: D/Tethering(526): sendTetherStateChangedBroadcast 1, 0, 0
05-17 13:45:33.149: I/wpa_supplicant(25862): wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25

The SSID and the WLAN mac address is shown in clear text.

Opening of a specific app

When a user clicks on an app to open, the logfile contains the exact app that was opened:

05-17 13:55:30.586: I/ActivityManager(526): START u0 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.rovio.angrybirds/com.rovio.fusion.App} from pid 818

com.rovio.angrybirds is the unique id for the well-known Angry Birds game (https://play.google.com/store/apps/details?id=com.rovio.angrybirds)

This is just a short summary of sensitive information stored in the “log file” and shows that all information are written as cleartext without any sanitization. But there are also sanitized pieces of information in the logfile, such as phone numbers. The toSafeString() method in the android.net.Uri class gives information about the data that is sanitized before it is  written into the “log file”. Those are URIs that start with “tel:”, “sip:”, “sms:”, “smsto:” or “mailto:”. For instance if someone calls a phone number, the number is sanitized via xxxxxxxxx:

I/ActivityManager(522): START u0 {act=com.android.phone.SIP_SELECT_PHONE dat=tel:xxxxxxxxx flg=0x10000000 cmp=com.android.phone/.SipCallOptionHandler (has extras)} from pid 767

Can I create a malware that reads all this sensitive information?

Yes, it is actually quite easy to create such a malware application. An app can use the call Runtime.getRuntime().exec("logcat") to access the “log file” information. Furthermore, the READ_LOGS permission has to be set in the AndroidManifest.xml. As an improvement, one could use the logcat -v time setting for adding time information to the log entries. With this setting the malware could also gain access to timestamps which creates a real-time privacy tracking problem. An attacker could send all the events (switching on bluetooth, opening specific website, opening specific app, etc) a user creates on a phone together with a timestamp to a malicious server, resulting in real-time privacy tracking.

Is this really so dangerous?

Yes and no. Google fixed the problem of granting access to all log entries, even those of other applications, in Android version 4.1. Since 4.1 it is not possible to read log entries of other applications and also not of the internal methods (as shown above). Unfortunately, there is no official documentation in Android for this fix

“Hi, sorry this didn’t get documented.” (Dianne Hackborn Android framework engineer)

If one has a rooted devices, it is still possible to successfully execute the malware. There are two possibilities in doing so (source):

  • grant access via the shell pm command: pm grant org.jtb.alogcat.donate android.permission.READ_LOGS
  • giving every app the READ_LOGS permission by applying this ugly and insecure hack: chmod 04755 /system/bin/logcat

Even with an unrooted device, there are a lot of Android devices out there (only 26.1% have updated to 4.1.x and only 2.3% to 4.2.x – as of Mai 2013) with a version < 4.1 and all of those are vulnerable to this kind of privacy tracker. So update your Android version if you have not done yet ;-)!

There is also a third possibility of reading the log entires of another application. This can be done if the application explicitly sets the android:debuggable flag to true in the AndroidManifest.xml file. The default setting is false.