 And without further ado, here is Slava. Hello everyone. Thank you for attending this talk. Today I'm going to compromise Android sandbox through a new menu in the disk attack surface. I will show how the simplest Android app like Hello World can attack another app through external storage and gain possibilities for silent app installation, denial service attack of pre-installed apps, or even code execution in context of system or popular apps. I'm Slava from Checkpoint and I'm working at Checkpoint and vulnerability research and Ravens Engineering are my daily work. So let's begin with Android security basics, of course. Android application is highly fortified, I team and Android implement the concept of application sandbox to isolate execution of one app from others. And this simplified model shows following things. Android application has its own process and private storage accessible for this application only. And the second communication between apps are limited by Android framework. So each application has its individual permissions and Android application sandbox just prevents escalation of privilege attacks between them. Android frameworks provides hundreds of permissions to permit application access to user data or system features and all these permissions can be grouped to three categories. Normal and dangerous permissions can be granted by a user to an app and permit access to his SMS, contacts, and storage. Pre-installed apps which are shipped with the device have more extended permissions such as phone change phone settings or silent app installation. And the most privileged applications are signed with ROM signature or associated with some Android component like media or radio or something else. So it will be fine to find a way for a low-privileged app from the first category to attack another apps from the second or third category and try to gain some privileges. And so, and that's it. There are a lot of types of attacks of one app to others, but today I'm going to talk about storage based. So what about Android application storage, of course. Android apps has, there are three types of Android app storage. So internal storage is built-in memory, always available and accessible and private for each app. No one can get access for the app internal storage except the app itself. Another way, another side, external storage. External storage is partitional in internal storage but share it between all apps. Removal storage is actually the cart which can be extracted from a device and world accessible as well. From the app perspective, external and removable storage are the same thing and Android framework provides one API for both of them. Why Android needs an external storage at all? First of all, users want to transfer, want to share their media data like photo, video, audio data between apps and transfer this data to the PC. Plus all devices are limited in internal storage but should be supported as well. But no reason to save any sensitive internal apps information in the external storage. How it's difficult for a third-party app to get storage access is really simply an app can ask the user for storage permissions in the same way as any other permission and gain global application access, global storage access. And it should be noted that each app can locate in the external storage slightly more protected directory for preventing of internal file observing. But if a third-party app has global storage access, it can read and write any files inside of this directory as well. Let's look at possible many disk attack scenarios on application sandbox. And most popular external storage usage scenarios are downloading of some data to external storage and after that transferring this data I mean extract, decompress to internal storage. And the second scenario is application holds maintained working data on external storage without any transferring at all. Both these communication scenarios can be hijacked so any third-party app can rewrite any file located in external storage providing the disk attack. So I will show that even one data file overwritten in the external storage can lead to crash of Android application native library and as you know the crash is the first step for the code execution inside of attack apps. The most challenging part of the first scenario is detect the moment when actually downloaded file should be overwritten. It's really right after the file downloading. To resolve this problem file observing techniques can be used and Android application is mostly Java and potentially maybe it's native code so Android Java framework provides file observer component for file observation or observing in native part can be implemented using I notify these calls. And in case of private app directory in external storage when I notify based methods would not work but pulling methods based on timers will get the job done always. Let's get several examples of many of the disk attack. But I discovered much more and for this presentation I took several excerpts from Android security guides for application developers to show that it's not enough to write a guide to provide any security gaps. And even biggest Android vendors don't follow the proposed rules. The first excerpt is you should perform input validation when handling data from external storage. Okay, validation is quite simple. Google translate holds its offline translation packages on external storage. So any third party app can overwrite, can generate a raw file and overwrite the original file in the external storage associated with Google translate and to crash native library of this app, live translate is a soft native library because this library handles parses files located in external storage and associated with the Android translate in Google translate application. I will show a quick demo video. Here you can see that I will show just the files located in external storage and world readable. I started my hello world application and just overwrite it without any observer, two files to rock one and in moment when translator goes to translate first later it will be crashed. That's it. Thank you. The same story with Yandex translator, most popular Russian translator but another library, live mobile Android is compromised. I think that everybody knows okay Google application, okay Google. So it's actually Google voice assistant and Google voice assistant is the app that allows offline speech recognition files through external storage without any verification. So when the disk attacker can overwrite such files and to crash, live Google speech in ISO again at crash. I will not show all my demo videos. I prepared a lot of videos but this PDF presentation file will link to all of them. The next excerpts, you should not store executables files on external storage. Really? LG has its open app stores for application associated with LG devices and LG application manager is actually LG app box client system. It's high privileged. Responsible updating, downloading, installing all such updates on all LG phones. So it means that the app downloads updating Android package file through external storage and installs from external storage. This means that disk attacker can overwrite such updates and install any app in any moment where he wants on all LG phones. It's quite simple. So I will show another demo with LG. So I just start my hello world application and okay, let's hack up manager. And I'm sure that user for example not going to update application is going to install some LG related application. For example, FM radio. Okay, I want to install my FM radio but instead of FM radio, right now I have installed some malware application. Quite simple. The same story with another LG related system app which responsible for displaying themes and false on all LG phones downloads self-updates through external storage. And again, same story, I can overwrite this file and install another app without any problem. Quite simply. And another excerpts. Okay, you should sign and verify signature of all files located in external storage. Okay, understood. Google text to speech. Again, all phones in the world. And downloads voice packet in archive to external storage, verify signature. Okay. And decompress such files to the internal storage. It's look nice. We have signature, verification of signature. But the second and third part of the algorithm are not atomic action. This means that an attacker can overwrite file after verification. What is the problem with this? Okay. And again, internal application, internal native library and then tech. And as example, show my browser, download self-update to external storage, verify SHA-1 hash and installs update. Again, I can overwrite this file after verification. You might be wondering how is it possible to infiltrate in the exact moment when file, when update was verified but has not, but installation has not yet begun. So I will show that in this example, for example, as installation and verification are two separate and manually invoked actions. So I'm going to update browser. Okay. Hello world application. Let's hack it. And I'm going to update, show my browser. And update what? I'm going to update button. In moment when user press update button, download and verification will be done. And after that we have another button, install. Okay. So I'm an attacker. I have a lot of time between verification and installation. I quite simple to overwrite this file and again install my browser. No problem. To summarize, any security app can overwrite any file located in external storage and Android has no relevant protection to offer. And many high-privileged and popular apps transfer and hold their data through external storage. It allows a lot to manage this attacker various attack possibilities and of course compromises Android application sandbox. I have a few minutes so let's look at how to find your many disk vulnerability. When first approaching this problem, I was quite surprised that very little work in this field exists and I could not find any father of automation tool to help me with my investigation and I, my decision was to prepare my own setup. And so the research target is native library. Application native library is so file because I'm going to crash C code but not Java. And if such library, Android application library handles in any way controllable file, this application can be attacked. In our case, the controllable file is file located in the external storage. In a moment, once a suitable native library and a storage-based file found, I'm going to implement my simple Java program to reproduce the attack flow. The attack flow this means that loading, parsing of the storage file, it's all this, all this implemented code does is just loading of targeted library and calling of one, two functions from the one and that's it. And after that, fuzzing of the prepared Java program is start. This is real-time examples of adapters which I use to find vulnerability in Google handwriting or Yandex search and you're welcome to try them. And so in this point, I just want to stress that adopters is very simple, it's very simple program. So I have an adapter but how to fuzz. And I prepare it fuzzing setup based on the Linux counterparts. It's a famous American fuzzer loop and fuzzer and QMU emulator and I get the possibility to fuzz Android application native libraries. The set of preparation pauses several challenges and I recover it many patches throughout all the listed here stack. Unfortunately, my time is up but I will help you to supply any additional information about this tool stack to everybody who is interested. And of course, you can download this as open source tool and I will open this link and try to find your own man of the disk vulnerability. Thank you.