Man-In-The-Disk
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Makkaveev, Slava
Most of modern OS are using sandboxing in order to prevent malicious apps from affecting other apps or even harming the OS itself. Google is constantly reinforcing Android’s sandbox protection, introducing new features to prevent any kind of sandbox bypass. In this talk we want to shed new light on a less known attack surface which affects all Android devices and allows an attacker to hijack the communication between privileged apps and the disk, bypassing Android’s latest sandbox protection. The problem begins when privileged apps interact with files stored in exposed areas, and even worse, some of them will unintentionally break the sandbox by insecurely appending such data to its confinements. Can you imagine if someone could execute code in the context of your keyboard, or install an unwanted app without your consent? Well… It’s hardly within the realm of imagination. The external storage and network based vulnerabilities we discovered, can be leveraged by the attacker to corrupt data, steal sensitive information or even take control of your device.
 And without further ado, here's Slava. Hello everyone. Thank you for attending this talk. Today I'm going to compromise Android sandbox through a new main-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 principled 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 Revence 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 privileged 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 to permit access to his SMS contacts and storage. Print-stalled apps, which are shipped with the device, have more extended permissions such as change from settings or silent app installation. And the most privileged applications are signed with ROM signature or associated with some Android components 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 to third category and try to gain some privileges. So 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, there are three types of Android app storage. So internal storage is built in memory. All is 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 shared between all apps. Removal storage is actually SD card, which can be extracted from a device and world accessible as well. From the app perspective, external and removable storage 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 search-pity 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 allocate in the external storage slightly more protected directory for preventing of internal file observing. But if a search-pity app has global storage access, it can read and write any files inside of this directory as well. Let's look at possible 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 and extract the compressed to internal storage. And the second scenario is application holds, maintain it, work in data on external storage without any transferring at all. Both these communication scenarios can be hijacked. So any third-party app can overwrite any file located in external storage, providing an easy 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 partially 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 C-scores. And in case of private app directory in external storage when I-notify based methods would not work, but folding methods based on timers will get the job done always. Let's get several examples of Manus 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. OK, validation is quite simple. Google Translate holds its offline translation packages on external storage. So any third party app can generate a raw file and override the original file in the external storage associated with Google Translate. And to crash, native library of this app will translate as a native library. Because this library handles parses files located in external storage and associated with 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 the external storage and the world readable. I started my Hello World application and just I will write 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. Thank you. The same story with Yandex translator, most popular Russian translator, but another library, Libmobile Android is compromised. I think that everybody knows OK Google application. OK Google. So it's actually Google Voice Assistant. And Google Voice Assistant is the app that downloads offline speech recognition files through external storage without any verification. So when this attacker app can override such files and to crash, Libgoogle's PG9SO, 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 from external storage. Really? LG has its own app stores for application associated with LG devices. And LG application manager is actually LG Abox client system app. It's hyper-illeged. Responsible updating, downloading, installing, or 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 men disk attacker can override such updates and install any app in any moment that 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 OK, Lex Huck, app 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. OK, I want to install my FM radio. But instead of FM radio, right now, I have installed some other application. Quite simple. Thank you. The same story with another LG related system app which is responsible for displaying themes and false on all LG phones. Downloads self-update through external storage. And again, same story. I can override this file and install another app without any problem. Quite simply. And another excerpts. OK, you should sign and verify signature of all files located in external storage. OK, understood. Google text to speech. Again, all phones in the world. And download voice packet in archive to external storage, verify signature. 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 override file after verification. What is the problem with this? OK, and again, internal application, internal native library, and then tech. And as an example, Xiaomi browser download self-update to external storage, verify SHA-1 hash, and installs update. Again, we can override 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 installation has not yet begun. So I'll 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. I'm OK. Hello, world application. Let's hack it. And I'm going to update Xiaomi browser. And an update button. In moment when user press update button, download and verifications will be done. And after that, we have another button, install. OK, so I'm attacker. I have a lot of time between verification and installation. I quite simple to override this file and then again, install my model. No problem. Thank you. To summarize, ANI security app can override any file located in external storage. And Android has no relevant protection to offer. And many high-previvalent and popular apps transfer and hold their data through external storage. It allows a lot to manage the disk 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 manage 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 further automation tool to help me with my investigation. And 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 storage-based file found, I'm going to implement my simple Java program to reproduce the attack for law. The text law, this means that loading, parsing of the storage file. 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 used to find vulnerability in Google handwriting or Yandex search. And you are welcome to try them. And so in this point, I just want to stress that adapter is very simple. It's a 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 poses several challenges and I recovered many patches throughout all the listed here stack. Unfortunately, my time is up, but I will help you to supply any additional information about these tools stacked to everybody who is interested. And of course, you can download this as an open source tool. And I will open this link and try to find your own another disk vulnerability. Thank you. Thank you.
 And without further ado, here's Slava.  Hello everyone.  Thank you for attending this talk.  Today I'm going to compromise Android sandbox  through a new main-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 principled 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 Revence 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 privileged 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 to permit access to his SMS  contacts and storage.  Print-stalled apps, which are shipped with the device,  have more extended permissions such as change  from settings or silent app installation.  And the most privileged applications  are signed with ROM signature or associated with some Android  components 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  to third category and try to gain some privileges.  So 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, there are three types of Android app storage.  So internal storage is built in memory.  All is 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 shared between all apps.  Removal storage is actually SD card,  which can be extracted from a device and world accessible  as well.  From the app perspective, external and removable storage  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 search-pity 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  allocate in the external storage slightly more protected  directory for preventing of internal file observing.  But if a search-pity app has global storage access,  it can read and write any files inside of this directory  as well.  Let's look at possible 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  and extract the compressed to internal storage.  And the second scenario is application holds,  maintain it, work in data on external storage  without any transferring at all.  Both these communication scenarios can be hijacked.  So any third-party app can overwrite any file  located in external storage, providing an easy 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 partially 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 C-scores.  And in case of private app directory in external storage  when I-notify based methods would not work,  but folding methods based on timers  will get the job done always.  Let's get several examples of Manus 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.  OK, validation is quite simple.  Google Translate holds its offline translation packages  on external storage.  So any third party app can generate a raw file  and override the original file in the external storage  associated with Google Translate.  And to crash, native library of this app  will translate as a native library.  Because this library handles parses files  located in external storage and associated  with 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 the external storage and the world readable.  I started my Hello World application  and just I will write 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.  Thank you.  The same story with Yandex translator,  most popular Russian translator, but another library,  Libmobile Android is compromised.  I think that everybody knows OK Google application.  OK Google.  So it's actually Google Voice Assistant.  And Google Voice Assistant is the app  that downloads offline speech recognition files  through external storage without any verification.  So when this attacker app can override such files  and to crash, Libgoogle's PG9SO, 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 from external storage.  Really?  LG has its own app stores for application  associated with LG devices.  And LG application manager is actually  LG Abox client system app.  It's hyper-illeged.  Responsible updating, downloading, installing,  or 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 men disk attacker can override such updates  and install any app in any moment  that 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 OK, Lex Huck, app 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.  OK, I want to install my FM radio.  But instead of FM radio, right now,  I have installed some other application.  Quite simple.  Thank you.  The same story with another LG related system  app which is responsible for displaying themes and false  on all LG phones.  Downloads self-update through external storage.  And again, same story.  I can override this file and install another app  without any problem.  Quite simply.  And another excerpts.  OK, you should sign and verify signature of all files  located in external storage.  OK, understood.  Google text to speech.  Again, all phones in the world.  And download voice packet in archive to external storage,  verify signature.  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 override file  after verification.  What is the problem with this?  OK, and again, internal application,  internal native library, and then tech.  And as an example, Xiaomi browser  download self-update to external storage, verify  SHA-1 hash, and installs update.  Again, we can override 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 installation has not yet begun.  So I'll 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.  I'm OK.  Hello, world application.  Let's hack it.  And I'm going to update Xiaomi browser.  And an update button.  In moment when user press update button,  download and verifications will be done.  And after that, we have another button, install.  OK, so I'm attacker.  I have a lot of time between verification and installation.  I quite simple to override this file and then again, install  my model.  No problem.  Thank you.  To summarize, ANI security app can override any file  located in external storage.  And Android has no relevant protection to offer.  And many high-previvalent and popular apps transfer and hold  their data through external storage.  It allows a lot to manage the disk 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 manage 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 further automation tool  to help me with my investigation.  And 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 storage-based  file found, I'm going to implement my simple Java  program to reproduce the attack for law.  The text law, this means that loading, parsing  of the storage file.  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 used to find vulnerability in Google  handwriting or Yandex search.  And you are welcome to try them.  And so in this point, I just want  to stress that adapter is very simple.  It's a 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 poses several challenges  and I recovered many patches throughout all the listed  here stack.  Unfortunately, my time is up, but I  will help you to supply any additional information  about these tools stacked to everybody who is interested.  And of course, you can download this as an open source tool.  And I will open this link and try to find your own  another disk vulnerability.  Thank you.  Thank you.
DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_0_71.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_72_323.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_324_1727.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_1728_2735.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_2736_3263.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_3264_6323.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_6324_14291.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_14292_15395.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_15396_15539.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_15540_16859.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_16860_16931.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_16932_17003.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_17004_17051.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_17052_17327.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_17328_17639.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_17640_17771.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_17772_17843.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_17844_17975.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_17976_18551.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_18552_20867.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_20868_21023.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_21024_21119.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_21120_21779.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_21780_21863.png DEF_CON_26_-_Slava_Makkaveev_-_Man_In_The_Disk_vvfs0u1or3M_21864_27079.png