Output of sensitive information into the system log

  HIGH  
Detection method   DAST         SENSITIVE INFO  

Description

Android provides an option for the applications to output information into a system log. Applications can send information into a log file using the android.util.Log class.

Before Android 4.0 any application with the READ_LOGS permission was able to access the entire system log (including the system log and logs of other applications).  After Android 4.1 the specification of the READ_LOGS permission has been modified and an application is now able to access its own logs only. However, the system log and logs of other applications still can be reached by connecting the Android device to a PC with logcat command.

This is why it is so important to ensure that applications do not send confidential information into the system log. 

The android.util.Log class provides a number of possibilities to output information:

  • Log.d (Debug)
  • Log.e (Error)
  • Log.i (Info)
  • Log.v (Verbose)
  • Log.w (Warn)

Also, libraries with similar functionality can be used (one of them is Timber)

Example of the vunerable code

Log.d("authorize", "Login Success! access_token="
        + getAccessToken() + " expires="
        + getAccessExpires());

Recommendations

Before publishing an application you need to ensure that confidential information does not go into the system log.   Also, if an application uses third-party libraries, it is imperative to ensure that those libraries don't send the confidential information and that they are configured in a proper way (i.e.: the release version of the library is used or correct attributes are set).

One of the well-known solutions is to declare and use a user class of logging to automatically include / exclude the information into the system log in accordance with its build type (release / debug).

if (BuildConfig.DEBUG) {
        ...
        serverEditText.setText("http://test.test");
        loginEditText.setText("user_test");
        passwordEditText.setText("12345");
        ...
    }

Also, a good practice is to use ProGuard to delete the particular logging calls. And to exclude during the release build logging from Timber and android.util.Log libraries.

Example of Proguard settings

-assumenosideeffects class android.util.Log {
        public static boolean isLoggable(java.lang.String, int);
        public static int v(...);
        public static int i(...);
        public static int w(...);
        public static int d(...);
        public static int e(...);
    }
-assumenosideeffects class timber.log.Timber* {
        public static *** v(...);
        public static *** d(...);
        public static *** i(...);
        public static *** e(...);
        public static *** w(...);
    }

Inclusion of Proguard into a release build of an application

buildTypes {
        releaseSomeBuildType {
                ...
                proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'your-proguard-file.pro'
            }
    }

Links

  1. https://www.owasp.org/index.php/Poor_Logging_Practice
  2. https://cwe.mitre.org/data/definitions/778.html
  3. https://source.android.com/setup/contribute/code-style#log-sparingly