lcimeni / disney

0 stars 0 forks source link

NowSecure dynamic analysis: Unique Device Identifier (Build Fingerprint) Leaked to Device Logs #96

Open lcimeni opened 1 year ago

lcimeni commented 1 year ago

Finding Description

A build fingerprint is a unique identifier for an Android device (not app specific), and as a result can be used in connection with user data to track individuals by their device. The build fingerprint has been found within device logs. Data written to device system logs can be accessed through several attack vectors. An attacker who is able to access the charging port may be able to access this data if the user acknowledges the trust relationship. Attackers can also access this data via another app if that app is able to view the device system logs. This vulnerability is common on various OEM devices.

Steps to Reproduce

Launch Android studio to view the syslog entries the app makes and search for sensitive data. Evaluate the app's logging capabilities to remove the possibility of sensitive or extraneous data being written to logs. To view the logs using Android Studio and logcat, follow these directions: https://developer.android.com/studio/debug/am-logcat#running

In NowSecure's automated and manual testing, a copy of syslog is pulled and searched for sensitive values. This testing is able to differentiate between log entries created by the app being tested and entries written by any other app or the system.

Business Impact

The app is insecurely storing sensitive data on the device which can lead to unauthorized access to the user's account and data by anyone with access to the device. Reuse of passwords can lead to further compromise of a user's accounts and additional exposure to risk for the organization.

Remediation Resources

Recommended Fix

To prevent this sensitive information from being compromised (such as by another application or process running on the same device), it is recommended that debug logs be disabled in a production environment. One method involves leveraging ProGuard or DexGuard (or an alternative) to completely remove the method calls to the Log class, thus stripping all calls to Log.d, Log.i, Log.v, Log.e methods. One example is use add the following snippet to proguard.cfg:

-assumenosideeffects class android.util.Log {
public static *** d(...);
public static *** v(...);
public static *** i(...);
public static *** e(...);
}

Please note that certain hybrid frameworks may have custom log functionality that also need to be disabled before app compilation.

Code Samples

Bad Android Manifest (.xml)

<manifest ...>
...
<application
android:debuggable = "true" ...>
...
</application>
</manifest>

Bad Code Sample (.java)

Log.v(), Log.d(), Log.i(), Log.w(), Log.e()

Good Android Manifest (.xml)

<manifest ...>
...
<application
android:debuggable = "false" ...>
...
</application>
</manifest>

If you're using proguard, you can add this to your proguard config file to remove all log calls (.java)

assumenosideeffects class android.util.Log {
public static *** v(...);
public static *** d(...);
public static *** i(...);
public static *** w(...);
public static *** e(...);
}

Additional Guidance

Risk and Regulatory Information

Severity: low CVSS: 2.1

Application

See more detail in the NowSecure Report