Total Recall – Persistence of Passwords in Android

1. Total Recall – Persistence of Passwords in Android Zain Azimullah [Lee-NDSS19] Lee, Jaeho, Ang Chen, and Dan S. Wallach, "Total Recall: Persistence of Passwords in Android", In Proceedings of Network and Distributed Systems Security Symposium, San Diego, CA, USA, 2019.

2. Introduction - Problem • Memory disclosure attacks • E.g. HeartBleed, Meltdown, Spectre Bad because: • Simple scripts can extract passwords from memory dumps • Passwords/keys can be reused • Users use similar passwords • Developers tend to keep passwords alive in memory • Therefore try to avoid password retention

3. Introduction - Motivation • Password in memory  found in memory dump • Therefore, avoid password retention!

4. Preliminary Study • 11 apps selected (6 popular apps, 4 password managers) and lock screen processes • Performed full memory dump and per-process memory dump • After authentication • After backgrounding • After playing videos on YouTube • After locking

5. [Lee-NDSS19] Lee, Jaeho, Ang Chen, and Dan S. Wallach, "Total Recall: Persistence of Passwords in Android", In Proceedings of Network and Distributed Systems Security Symposium, San Diego, CA, USA, 2019.

6. Problems with the Android Framework that Cause Password Retention • Lack of zeroization • Insecure SpannableStringBuilder • Lack of secure getPassword() API • Use and propagation of String passwords • Lack of manual TextViewcleanup • Lack of app-level zeroization

7. Lack of Zeroization • When an app is backgrounded, TextView does not automatically zeroize its text • Left up to the developer to clear TextView buffer on pausing/stopping app

8. Insecure SpannableStringBuilder • SpannableStringBuilder is used as a buffer for TextView • Allocates and copies new array with each typing of a character • Previous array discarded without zeroizing

9. Lack of Secure getPassword() API • TextView has a getText() method which returns a CharSequence • String is an implementation of CharSequence • Developers tend to invoke toString() to convert it to String • Strings are immutable • Android API lacks getPassword() support

10. Lack of Manual TextViewCleanup • TextView buffer can be cleared using clear() • Even if developer remembers to do this, clear() just sets to null • Password still exists somewhere in memory until garbage collection • Password managers tend to be good at invoking the garbage collector

11. Use and Propagation of String Passwords • Strings are immutable, cannot derive stronger keys from them • In the apps used in the study, some tend to send String passwords to a server • More places where retention can happen

12. Lack of App-Level Zeroization • Using char array better than String because can overwrite memory • Can derive keys from char arrays • But developer still needs to remember to zero them • Not all developers are responsible

13. Solution • Four objectives: • Using char arrays instead of Strings (use charAt() instead of toString()) • Clear TextView’s buffer using clear() • Derive a key • Zeroing memory

14. Solutions • Proposed solutions: • SecureTextView • KeyExporter

15. Solution - SecureTextView • Zeros sensitive memory after use • Uses SecureBuffer instead of SpannableStringBuilder • SecureBuffer prevents password fragments from being left in memory • close() method that cleans up passwords • Automatically zeroizes data buffer if app becomes paused/stopped

16. Solutions - KeyExporter • Gets array instead of String • Derives a key from the array • Sets the array to zeros • Clears the TextViews buffer • Encapsulates this, developer just has to call getKey()

17. [Lee-NDSS19] Lee, Jaeho, Ang Chen, and Dan S. Wallach, "Total Recall: Persistence of Passwords in Android", In Proceedings of Network and Distributed Systems Security Symposium, San Diego, CA, USA, 2019.

18. Results [Lee-NDSS19] Lee, Jaeho, Ang Chen, and Dan S. Wallach, "Total Recall: Persistence of Passwords in Android", In Proceedings of Network and Distributed Systems Security Symposium, San Diego, CA, USA, 2019.

19. Limitations • If someone gains root privileges to the phone, they can monitor touchscreen activities to get the password. • Credentials, keys, must be deleted fast as possible • Impossible to install on mobile phones because • SecureTextView modifies the Android framework. • Make standalone library with duplicate code or wait for Google? • The fix modifies apps – to avoid this, would have to fix at OS-level • Performance overhead • Intrusive