Android Phone Vulnerabilities

[Nikky Schreier]

My Android phone is rather old. It's running stock Android 4.1.2, which includes known security vulnerabilities. Unfortunately, this is the latest firmware which T-Mobile offers for this phone. Still, I'm fairly happy with Android 4.1.2.

I generally only install apps from the Google Play store or from F-Droid; normally not from other sources. I surf the Internet a fair bit, normally using either Google Chrome or Firefox. I'm not picky about making sure that I watch videos hosted only on trusted websites such as YouTube; I'm willing to watch online videos hosted anywhere. I install app updates from the Google Play store perhaps once a month or so.

I see at xda-developers.com that there are various third-party "ROMs" (unofficial firmware images) available for my device, including CyanogenMod and others. If I install one of these ROMs, I can end up with a newer Android version, including all of its security fixes.

That depends how important is anything you do on the phone. If it is prepaid plan and you only anonymously watch youtube clips and surf the web, the worst that could happen is your phone becoming just another of zombies in some botnet and use up your credits and spy on you.

If it is postpaid, it could build up your phone bill with extra data usage, calls and sms/mms to who-knows-where. If you use it to access email, it could destroy or takeover your email account. If you use it to enter credit card details for online shopping, your credit card could get maxed out. If you are famous person, your pictures and homemade videos could make some paparazzi very happy. And so on. So it really depends.

Another question is how likely you are to be exploited. That is also pretty hard to say. If you drive Audi A7 while under influence of alcohol, how likely is it you'll have an car accident? There is just no way to tell (even if you provide much more detail), and even if we had accurate statistics, they still won't tell what happens to individual.

So, you should assess what is the worst risk that can happen if your phone is taken over, how likely you think that may be, and how much effort are you willing to put in to avoid it. Nobody else can do it for you but you...

Also...consider buying something that comes with OEM unlock out of the box(Nexus, Dev devices, etc) if you want to stay updated in the future and not worry about as many vulnerabilities or third-party firmware compatibility issues.

Consider choosing a device for which you can continue to get security updates for the maximum number of years possible. Third-party ROMs can be a good way to get long-term security support, but once third-party ROM development ceases for your device, you may be out of luck. Consider choosing a device which third-party ROM developers are likely to support for many years.

One of the scary aspects of this is that if a remote attacker managed to use the exploit to steal photos from your Android phone they could then examine the EXIF metadata embedded within the photos to locate your physical location.

As a proof of concept demonstration, the researchers created a malicious weather app which did not request any special permissions beyond the basic storage access, and thus would be unlikely to appear suspicious or threatening to even the most cautious users.

When the app is run it creates a persistent connection back to a remote command-and-control (C&C) server, from where an attacker can send it instructions. According to the researchers, even closing the app does not terminate the connection.

The researchers responsibly disclosed details of the vulnerabilities to Google, and details of the high severity flaw were not made public until both Google and Samsung had released fixes earlier this year.

After discovering this issue, we identified several vulnerable applications. As part of our responsible disclosure policy, we notified application developers through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR) and worked with them to address the issue. We would like to thank the Xiaomi, Inc. and WPS Office security teams for investigating and fixing the issue. As of February 2024, fixes have been deployed for the aforementioned apps, and users are advised to keep their device and installed applications up to date.

The Android software development kit (SDK) includes the FileProvider class, a subclass of ContentProvider that enables file sharing between installed applications. An application that needs to share its files with other applications can declare a FileProvider in its app manifest and declare the specific paths to share.

Every file provider has a property called authority, which identifies it system-wide, and can be used by the consumer (the app that wants to access the shared files) as a form of address. This content-based model bears a strong resemblance to the web model, but instead of the http scheme, consumers utilize the content scheme along with the authority, followed by a pseudo-path to the file that they want to access.

For example, assuming that the application com.example.server shares some files under the file:///data/data/com.example.server/files/images directory that it has previously declared as shared using the name shared_images, a consumer can use the content://[authority]/shared_images/[sub-path]/[filename] URI to index these files.

Access is given by the data sharing application most commonly using the grantUriPermissions attribute of the Android manifest, in combination with special flags that are used to define a read or write mode of operation. The data sharing application creates and sends an intent to the consumer that provides temporary fine-grained access to a file. Finally, when a provider receives a file access request, it resolves the actual file path that corresponds to the incoming URI and returns a file descriptor to it.

In simple terms, a share target is an Android app that declares itself to handle data and files sent by other apps. Common application categories that can be share targets include mail clients, social networking apps, messaging apps, file editors, browsers, and so on. In a common scenario, when a user clicks on a file, the Android operating system triggers the share-sheet dialog asking the user to select the component that the file should be sent to:

Since the rogue app controls the name as well as the content of the file, by blindly trusting this input, a share target may overwrite critical files in its private data space, which may lead to serious consequences.

During our investigation, we identified that the application exports the CopyFileActivity, an activity alias of the com.android.fileexplorer.activity.FileActivity, which is used to handle copy-from-to file operations:

Since this activity is exported, it can be triggered by any application installed on the same device by using an explicit intent of action SEND or SEND_MULTIPLE and attaching a content URI corresponding to a file stream.

Given the case that the _display_name and _data values, returned from the external file provider, are relative paths to the destination directory, after exiting from the method above, these class fields will contain values like the ones depicted below:

As shown above, the paths (variables d and e) of this file-model point to files within the home directory of the application, thus the file streams attached to the incoming intent are going to be written under the specific locations.

An acute reader might have noticed that the second step requires the attacker to force the browser to overwrite the com.mi.android.globalFileexprorer_preferences.xml, which, as we already mentioned, was not possible.

To overcome this restriction, we referred to the actual implementation of the SharedPreferences class, where we found that when an Android application uses the getSharedPreferences API method to retrieve an instance of the SharedPreferences class, giving the name of the shared preferences file as an argument, then the constructor of the SharedPreferencesImpl class performs the following steps:

If a third party app was able to exploit this vulnerability and obtain code execution, an attacker could retrieve these credentials. The impact would then extend even further, since by the time that a user requests to open a remote share, the browser creates the directory /sdcard/Android/data/com.mi.android.globalFileexplorer/files/usbTemp/ where it saves the files that the user retrieves:

This means that a remote attacker would be able to read or write files to SMB shares of a local network, assuming that the device was connected to it. The same stands for FTP shares as they are handled exactly in the same way:

In step 3, the attacker uses the arbitrary code execution capability to retrieve the SMB and FTP credentials from the rmt_i.properties file. Subsequently, the attacker can now jump to step 5 and access the shares directly using the stolen credentials. Alternatively, after retrieving the share credentials, the mobile device can connect to a local network (step 4) and access an SMB or FTP share, allowing the attacker to access the shared files through the /sdcard/Android/data/com.mi.android.globalFileexplorer/files/usbTemp/ folder (step 5).

In cases where such an approach is not feasible, developers need to take extra steps to ascertain that the cached file is written to a dedicated directory. As an incoming file stream is usually identified by a content URI, the first step is to reliably identify and sanitize the corresponding filename. Besides filtering characters that may lead to a path traversal and before performing any write operation, developers must verify that the cached file is within the dedicated directory by performing a call to the File.getCanonicalPath and validating the prefix of the returned value.

Another area to safeguard is in the way developers try to extract a filename from a content URI. Developers often use Uri.getLastPathSegment(), which returns the (URL) decoded value of the last path URI segment. An attacker can craft a URI with URL encoded characters within this segment, including characters used for path traversal. Using the returned value to cache a file can again render the application vulnerable to this type of attack.

c80f0f1006