Testing for Mobile Vulnerabilities: Logging Sensitive Data – Part 2

One major flaw in mobile testing is the use of insecure logging. Often developers will use log methods to trace code for debugging purposes. Sometimes this can include sensitive data like usernames and passwords, and as applications go from the development phase into production the code can make its way into production mobile applications. 

In this example we can see that Insecure Shop makes use of the log.d method or the Log Debug Android API. Do take some time to overview the common use of the logging methods. It can help with understanding each of their intended uses.

In the last part of the blog series we took some time to examine the LoginActivity class. We observed that the class took in the username and password of the application user. This specific class also has a log method flaw built into the code. As we can see in the example code below. The highlight red text identifies the user of log.d or the debugging log Android API call. 

We can see that the username and password are logged into the application logs and can be retrieved in real time. This can be a major risk for any user who may be using an application and if their phone is stolen. Sensitive data can be pulled from the log files on the phone and used to further an attack against the user’s device. 

Logcat is a useful tool built into adb. It allows for monitoring and even storing logs of an application on an Android device. Often used in mobile penetration tests as part of the dynamic analysis part of the application test. The tester can observe all the actions happening on the device that may be logged. 

Using the command below let’s start adb and log into the Insecure Shop application the device:

adb logcat > log.txt

I like to make use of the standard redirect command to create a log.txt file. This helps me parse the logs to locate any sensitive user data. 

Below we can see the sensitive data stored in the logs of the android application that we submitted in the prior blog post. This includes the fake credentials used in the boolean bypass and the default username and password. 

Remediation

It is advised to remove code that could log sensitive information in a mobile application. Especially if that application is in production. As we saw in this post, user credentials are stored directly into the log file.

Leave a Reply

Your email address will not be published. Required fields are marked *