Man in the Binder
Big Brother is watching. His name is Binder. Binder is the only vehicle of inter process communication in Android, making it a prime target for attackers. We'll provide a review of this sophisticated and little known mechanism, describe the multitude of dangers in its compromise and demonstrate several Binder-based data manipulation and theft attacks. In depth (presentation outline): * The Android malware world lags behind the PC in sophistication, but rapidly catching up. We believe the next generation of mobile malware is soon to come, and the Binder is a natural target. * Binder Background (what makes it special?): - The peculiarity of Android's architecture: on the idea of a userland OS built on top of the Linux kernel, and how Binder is critical to this concept. - The inevitable security trade-off in Android: Minimizing the attack surface against the kernel, at the cost of introducing Binder as a classic single-point-of-control. - How a developer sees the Binder (spoiler: he doesn't). * In depth Binder mechanics (how does it work?): - A detailed look at the data structures, classes and functions which define the behaviour of Binder, with a special focus on security-critical areas. - Hooking Binder: How and where to control Android's IPC mechanism. - Looking at the raw data travelling through Binder, and how to sift through it to find the interesting stuff (passwords, keyboard input, SMS, sound and many more). - Why modern mobile AVs are having a hard time detecting these methods of operation. * (Demonstrations) Comparing the "naive malware" approach and Man in the Binder philosophy to: -> Logging keyboard input. -> Capturing data sent between Activities. -> Modifying sensitive information at runtime (i.e. faking a financial transaction, banking-trojan style). * Mitigation: - Why code obfuscation and app wrapping won't help you. - Encrypting your data before it leaves the process (even within the same app!). - Example: using an in-app keyboard securely. We believe that this is ground-breaking work that has not been properly researched before: Binder’s central position in the Android architecture means that it is likely to become heavily attacked in the next few years. By shining a bright light on this topic, our research is a significant contribution to the security of the Android platform as a whole. An earlier version of this research was presented at Black Hat Europe 2014 and Kaspersky SAS2015. A white paper of the results up until a few months ago can be found here: https://www.blackhat.com/docs/eu-14/materials/eu-14-Artenstein-Man-In-The-Binder-He-Who-Controls-IPC-Controls-The-Droid.pdf
Recommended
Recommended
More Related Content
Similar to Man in the Binder
Similar to Man in the Binder (20)
Man in the Binder
- 1. MAN IN THE BINDER: HE WHO CONTROLS IPC, CONTROLS THE DROID
- 2. A Hack in Three Acts Act I – Know Your Droid Act II – Attack Your Droid Act III – Prepare Your Droid
- 4. Nitay Artenstein Idan Revivo Michael Shalyt
- 5. Name: Kitty Bank Occupation: Bank Application “U want KitCoins – we haz it”
- 6. Name: Kitty-ninja Occupation: Script kiddy “Mommy, can I rob this bank?”
- 7. Name: Paw of Death Occupation: Black belt ninja hacker “To rob a bank, you must first become the bank”
- 8. Name: System Service Occupation: Sitting and waiting to serve your needs These things run Android!
- 9. Name: $ echo `uname –r` Occupation: Holding the world on its shoulders since 1.1.1970 Feeling neglected now that system services get all the attention on Android
- 10. Name: The Binder Occupation: All Powerful Mystery Character ?
- 12. An Application’s Life On Windows Syscalls
- 13. An Application’s Life On Android Syscalls Syscalls Syscalls
- 14. Android – The Real Picture Syscalls Syscalls
- 15. /dev/binder /dev/tty0 libbinder.so kernel /system/libbinder.so /system/lib*.so DalvikVM DalvikVM syscallparcel parcel Bank Application Process System Service Process application System services proxy libandroid_runtime.so libandroid_runtime.so System Service • Binder has a userland component and a kernel one • The driver receives the Parcel via an ioctl syscall and sends it to the target processes
- 16. What’s a Parcel?
- 17. A Short Recap libbinder.so DalvikVM Kitty Bank Process Parcels Syscalls Parcels Audio Manager
- 21. A n00b Attacker’s View of The System
- 22. What Would The n00b Attacker Do?
- 23. What Would The n00b Attacker Do?
- 24. What Would The n00b Attacker Do?
- 25. A Ninja Attacker’s View of The System
- 26. What Would The Ninja Attacker Do?
- 27. Key Logger Demo
- 28. What Would The Ninja Attacker Do?
- 30. A n00b Attacker’s View of The System Activity Activity Activity
- 31. What Would The n00b Attacker Do? Bye Kitty Bank , Hello Shi**y Bank
- 32. What Would The n00b Attacker Do? Bye Kitty Bank , Hello Shi**y Bank
- 33. A Ninja Attacker’s View of The System Activity Manager
- 34. In-app data goes through Binder???
- 35. A Ninja Attacker’s View of The System Activity Manager
- 36. What Would The Ninja Attacker Do? Activity Manager
- 37. A trillion dollars, anyone?
- 39. What Would The Ninja Attacker Do?
- 41. A n00b Attacker’s View of The System Telephony Manager
- 42. What Would The n00b Attacker Do?
- 43. What Would The n00b Attacker Do?
- 44. A Ninja Attacker’s View of The System Telephony Manager
- 45. What Would The Ninja Attacker Do?
- 46. SMS internals • The Telephony Manager notifies the SMS app whenever an SMS is received • The app queries the TM’s database via Binder:
- 47. SMS internals • But what’s a Cursor object? • It’s a messy abstraction of a response to a query
- 48. SMS internals • Surprise: Under the hood, it’s just a Unix fd • Now we’re in business!
- 49. What Would The Ninja Attacker Do?
- 51. Attacking The Binder • Hook libbinder.so at the point where it sends an ioctl to the kernel • Stealth: dozens of places to hook • But don’t you need root?
- 52. Attacking The Binder Vulnerable to known rooting exploits
- 54. Summary Features: • Versatility: one hook – multiple functionalities. • App agnostic: no need to RE apps. • Stealth: the Android security model limits 3rd party security apps just like any other app.
- 55. Summary • This is NOT a vulnerability. It’s like man-in-the- browser, but for literally everything on Android. • Root is assumed. Rooting won’t go away any time soon.
- 56. Rumors (You didn’t hear it from me…)
- 57. What are you trying to tell me? That I can get all permissions on a device? No. I’m trying to tell you that when you’re ready, you won’t have to
- 59. Solutions – for developers • Take control of your own process memory space. • Minimize the amount of data going to IPC, and encrypt what has to go.
- 60. Solutions – for security industry • Scan files like it’s the 90’s. • Be brave – get root yourself: • Runtime process scanning and monitoring. • Software firewall (like Avast). • Binder firewall/anomaly detection. • Etc.
- 61. Further Reading [1] White paper: “Man in the Binder”, Artenstein and Revivo [2] “On the Reconstruction of Android Malware Behaviors”, Fatori, Tam et al [3] “Binderwall: Monitoring and Filtering Android Interprocess Communication”, Hausner
Editor's Notes
- Need to say something about our group what do we do and maybe a promo for ccc
- This is a serious bank application for transferring funds between accounts
- To attack a system, one must first understand the system. And to do first lets take a look at standard OS that we all know … and some of us like… I guess … windows
- Application on windows needs to know allot of information about the environment its operating in. Sound example needs to know: Kernel version Enumerate all the audio devices correct device descriptor syscall number for transmitting the data system is engineered in order to do anything specific It doesn’t mean that if you are a programmer and you open visual studio you don’t to know all that stuff but the compiler knows all that stuff for you , and he incorporate all this data into your binary file. And this makes your application really heavy. And this is exactly what the android designers wanted to avoid .
- They wanted to create an Object Oriented operating system And the way to do it is isolate the application from the kernel In android according to object oriented concept we have what's called system service . system services come prebuild inside the android operating system , Each system service had its own specific role: audio,video,etc… Basically they handle all the kernel communication for the application. So the android application can only talk to manger applications to request their services For example play sound (explain rpc) Ok so that’s a great approach ,everything is good , everyone is happy but we do have a problem here ,can anyone spot the problem ? (Windows example) application cant talk to the kernel so how exactly is send this request to manager application? And the answer is binder
- So you probably asking yourselves what is binder Binder is an inter-process commination mechanism that in charge on passing remote procedure calls from different process in the system. What this is actually means is that when our application needs to talk to a specific system service, the application will send a remote procedure call to the binder and the binder will pass it to the required system service, Basically what I’m trying to say is here is that basically “everything goes through the binder” now lets look at how android designers implemented binder
- So the binder is implemented in two parts, a userland framework which is loaded inside every application process and a kernel driver. userland framework part is responsible Taking remote procedure calls with their arguments and wrap the in special container. Sending the container to kernel via iocatl syscall. Unwrapping that data when it arrives at the target process. That's possible because the Binder framework is a core part of every process in Android, servers as well as application. So when you fork() a process to create a new one, that new process will also have a copy of the Binder framework in it's memory space. The kernel driver part responsible Passing the remote procedure calls between process it acts more like a router by receiving the container ,parses the destination address of that container, and copies the container data to the target process' address space. It then wakes up a designated thread in the target process which is supposed to listen for incoming calls from client applications. So what exactly is this container?
- The name of that container is parcel It’s a flexible and extensible data object that when send to the kernel via ioctl call it’s been marshells into a flat buffer and passed to the other process The parcel contains The name of the destination service in this case media player The function code of the procedure call it needs to invoke And the arguments for that function For example here we want to change the volume of the device So we have two arguments two floats for left and right speaker
- Ok now lets do a short recap. Just to make sure that everyone understand the concept . The wants to play sound It warps the arguments in this case an audio file descriptor in a parcel using the userland framework part then the the process sends an ioctl syscall to kernel with the parcel inside The kernel driver parses the destination address of that parcell, and ten copies the parcel data to the target process' address space then the rpc call is invoked and the audio manger trasnmits to kernel to play that audio file And the the response is sent to back the same way to the application proceess
- And now we see the real picture on Android. A group of client application, here represented as the green islands, constantly send request to system services via the Binder. On the other side, the system services receive the requests, talk to the hardware via the kernel, and return a reply to the application. This intricate web is what makes Android tick. And now you finally understand that ... “everything goes through the binder” .
- Now for the fun part of binder attacks I give you nitty
- A thread in an app sets up a listener When the user hits a key, the keyboard server sends a Parcel to an InputContext interface We sniff the Parcel as it goes through the Binder
- When the application process starts a new Activity, it calls the ActivityManager. Data that needs to be available to another Activity is sent in the parameters of StartActivity() All we need to do is sniff it in Binder