Gh0stbo · 2016/01/29 comeliness
0 x00 profile
Number 4 on OWASP’s Top 10 mobile security Vulnerabilities list is inadvertent data leakage. When the location where the application stores data is itself vulnerable, it can cause unintended data leakage. These locations might include clipboards, URL caches, browser Cookies, HTML5 data storage, analytics data, and more. For example, when a user logs in to a banking application, the password has been copied to the clipboard, and a malicious application can obtain the password by accessing the user’s clipboard data.
0x01 Avoid caching network data
Data can be captured by various tools without the user’s awareness. Developers often overlook the security implications of data storage methods, including log/debug output, Cookies, Web history, Web caching, and more. For example, when a browser visits a page, it usually saves the HTML, JS, images, and so on in a temporary folder. When a page contains sensitive information, that information is also stored in temporary files. This creates a safety hazard. Store/cache sensitive data as little as possible on mobile devices. This is the best way to avoid leaking cached data on the device.
Development Suggestions
To prevent HTTP caching, especially of HTTPS transmitted data, developers should configure Android not to cache network data.
To avoid caching URL history and page data for any Web process, such as registration, we should configure HTTP cache headers on the Web server. Version 1.1 of the HTTP protocol specifies the use of caching. Cache-control: no-store is the answer header. Cache-control :no-store specifies that the browser must not store any content of the response or the request that caused it. For Web applications, HTML form input can be set to autocomplete=off so that the browser does not cache the value. Avoiding caches should be verified by forensics of device data after application use.
If your application accesses sensitive data through WebView, you can use the clearCache() method to delete any files stored locally.
0x02 Android: Avoid GUI object caching
Because of multitasking, the entire application can reside in memory, so does the Android application interface. An attacker who discovers or steals a device can look directly into the user’s previously viewed interface while still residing in memory and see all the data still displayed on the GUI. An example is a banking application where a user views the transaction history and then “logs out” of the application. An attacker can see previous transactions displayed by directly starting the Transaction View activity.
Development Suggestions
- Exit the entire app when the user logs out. This is against android’s design principles, but it is more secure because the GUI interface is destroyed and recycled.
- Check whether the user is logged in when each activity (interface) starts. If not, jump to the login interface.
- The GUI data is cleared when the user exits (switches) the application interface or logs out
0x03 Limit user name cache
If the user name is cached, it will be loaded into memory at run time before any type of authentication, allowing potentially malicious processes to intercept the user name.
Development Suggestions
It is difficult to easily store usernames for users while avoiding information leakage due to insecure storage or potential runtime interception. Although usernames are not as sensitive as passwords, they are private data that should be protected. A more secure way to cache usernames is to store masked usernames instead of real ones, such as using hash values instead of usernames for authentication. The hash value can contain a unique device token that is acquired at user registration. The advantage of using hash and device token is that the real user name is not stored locally and will not be protected after being loaded into memory. Copying the value to other devices or using it on the Web will not work because of the obtained device token value. An attacker must mine more information (plaintext accounts, device signature codes, and passwords) to successfully steal user credentials.
0x04 Watch the keyboard cache
Keyboard caching is one of the unexpected data leakage problems. The Android keyboard contains a user dictionary. If a user enters some text in a text field, the input method may cache some data entered by the user through the dictionary, which can be used to automatically correct the user’s input later. This user dictionary does not require any special permissions to be used in any application. Malware can extract this data by accessing the keyboard cache. The contents of the cache are beyond the application’s administrative authority, so the application cannot remove data from the cache.
Attack example: www.youtube.com/watch?v=o6S…
Development Suggestions
Disable autocorrect for any sensitive information (not just password fields). Because sensitive information in the keyboard cache can be recoverable.
To improve security, consider implementing a self-painted keyboard that disables caching and provides other protection features, such as keyboard listening protection.
0x05 Copy and Paste
Sensitive data in the clipboard can be modified arbitrarily, regardless of whether the data source is encrypted or not. If the user is copying plaintext sensitive data, other applications can access the plaintext sensitive data by accessing the clipboard.
Fixed:
Where appropriate, disable copy/paste processing of sensitive data. Eliminating replication options reduces the risk of data exposure. On Android, you can access the clipboard from any application, so if you need to share sensitive data, you are advised to use a Content Provider.
0x06 Sensitive Files Are Deleted
Android cannot safely erase files by calling file.delete(). Files can be recovered as long as they are not overwritten. Android Data Recovery does this.
Development Suggestions
Developers should assume that any data written to the device can be recovered. So in some cases, encryption can provide an extra layer of protection.
Another possibility is to delete a file and then create a large file to cover all available space, forcing the NAND flash to erase all unallocated space is also possible. The downside of this technique is the loss of NAND flash memory, resulting in slower response times for applications and the entire device, significantly increasing power consumption. This approach is not recommended for most applications. The ideal solution would be to store as little sensitive information on the device as possible.
0x07 Screen capture and recording Defense
Android 5.0 added screen recording interface, no special permissions, use the following system API to achieve the screen recording function:
After a recording request is initiated, the following dialog box is displayed asking the user to confirm:
In the figure above, “AZ Screen Recorder” is the name of the software that needs to record the Screen. “Will start to capture all the content displayed on your Screen” is the system’s own prompt message, which cannot be changed or deleted. Users click “Start now” to start recording on the screen. After recording, an MP4 file is generated in the designated directory.
But there is a loophole, specific reference: www.freebuf.com/vuls/81905…. . All an attacker has to do is give the malware a special, “reasonable-sounding” application name to turn the prompt into a UI trap, depriving it of its original “recording authorization” prompt and allowing the malware to record the user’s phone screen without the user’s knowledge.
Development Suggestions
In the Acitivity of involved user privacy sensitive information (such as a login, payment and other input interface) increased WindowManager LayoutParams. FLAG_SECURE attribute, this property can be screenshots and prevent the screen recording.
0x08 Resources
- www.w3.org/Protocols/r…
- Resources.infosecinstitute.com/ios-applica…
- www.nowsecure.com/resources/s…
- www.nowsecure.com/resources/s…
- www.nowsecure.com/resources/s…
- www.freebuf.com/vuls/81905….