#.appbox cache apk
#.appbox cache archive
#.appbox cache android
#.appbox cache code

The attacker can then overwrite downloaded files and crash libgoogle_speech_jni.so app’s native lib.

#.appbox cache archive

The app downloads offline speech recognition languages to External Storage ( /storage/emulated/0/Android/data//files/download_cache/) as an archive and then decompresses machine learning related binaries in the app’s Internal Storage directory ( app_g3_modes).

Video: A demonstration of a Man-in-the-Disk attack against Google Translate. This scenario does not require any file observation from the attacker side. The attacker can then generate a rogue binary, overwrite original files located in the external storage and crash the lib. These data files are processed by libtranslate.so app’s native lib upon entering the first letter for translation. Google Translate app downloads and holds off-line mode translation packages on external storage – /storage/emulated/0/Android/data/.translate/files/olpv3/v5/25/r11/.

#.appbox cache android

These vulnerabilities show that even the biggest Android vendors and developers make dangerous mistakes when working with the External Storage. Let’s take several examples of how a Man-in-the-Disk attack can be used. In one case it took just 15 minutes to reach the crash, with the other it took half a day. In the case of some of the apps below, for example Yandex or Google Translate, the ‘Grey Box’ fuzzing allowed us to mutate the translation package files in an efficient way until a lib crash was reached. The execution flow is as follows: AFL Fuzz Engine → QEMU ARM CPU emulator → dalvikvm tool → Android Runtime + adapter DEX. The assembly of these tools eventually allows to fuzz a user custom lib wrapped in a DEX file on an actual Android device or an ARM device emulator. This tool consists of several parts including patched version of Android Runtime (libart.so), dalvikvm tool, GLib, QEMU and AFL. This allowed us to run ‘Grey Box Fuzzing’. So in order to successfully test for vulnerabilities in the target apps our research team adapted an existing fuzzing tool (AFL) to run native Android libraries over the QEMU Emulator. However, there are only Black Box Fuzzing available for Android, which would not be an efficient or sufficient, and therefore not really applicable, for our purposes. Once we encountered an app that saves either data or configuration using the External Storage, we decided to use fuzzing techniques to try and search for vulnerabilities within the app. DoS and EoP vulnerabilities are also possible.

#.appbox cache apk

Another attack is to hijack an app update flow, overwrite APK files and silently install a rogue app instead of a legitimate one.

#.appbox cache code

This crash can lead to a code execution in the context of a privileged or popular app. What’s more, many apps hold working data permanently in the External Storage since the device can often be limited by using the Internal space only.Īs all third-party apps installed on the device can observe data transferred by other apps via the External Storage, as well as overwrite a target file, various possibilities are available for a Man-in-the-Disk attack.įirstly, a malicious app can crash a target app’s native library which parses a storage located data file. Many high privileged systems and popular apps use Android’s External Storage as a temporary buffer when downloading data from the Internet. External Storage: This is a partition in the Internal Storage or SD-card which is shared by all applications.īefore going any further, though, let’s take a deeper look at Android’s External Storage.Internal Storage: This is an app’s built-in memory which each application uses separately and is segregated by the Android Sandbox.

There are two types of Android device storage: In this post we will show how one WRITE_EXTERNAL_STORAGE permission can make it possible for an Android app to silently execute privileged code and install other apps. Failing to employ security precautions on their own leaves applications vulnerable to the risks of malicious data manipulation. These Man-in-the-Disk attacks are made possible when applications are careless about their use of External Storage, a resource that is shared across all applications and does not enjoy Android’s built-in Sandbox protection. Careless use of External Storage by applications may open the door to an attack resulting in any number of undesired outcomes, such as silent installation of unrequested, potentially malicious, apps to the user’s phone, denial of service for legitimate apps, and even cause applications to crash, opening the door to possible code injection that would then run in the privileged context of the attacked application. Recently, our researchers came across a shortcoming in the design of Android’s use of storage resources. Man-in-the-Disk: Android Apps Exposed via External Storage