Dissecting Android's Bouncer

Charlie Miller and I will be presenting on Android’s Bouncer this week at the SummerCon conference and demonstrating how Bouncer can be bypassed to slip malicious apps into the Android Market. This screencast shows our submitted app handing us a connect-back shell on the Bouncer infrastructure so that we can explore and fingerprint its environment.

While Bouncer may be unable to catch sophisticated malware from knowledgeable adversaries currently, we’re confident that Google will continue to improve and evolve its capabilities. We’ve been in touch with the Android security team and will be working with them to address some of the problems we’ve discovered.

We hope you’ll be able to make it out to SummerCon to see our presentation live! Feel free to comment below if you have any questions about the video or our presentation.

Transcript

Hey everyone, Jon Oberheide here, with some more mobile security fun. My esteemed colleague, Dr. Charles Miller, and I will be presenting later this week at the SummerCon conference out in New York City, so we wanted to give you guys a quick preview of what we’ll be covering in our talk. The main topic of the presentation is Android’s Bouncer. Bouncer is a system Google recently put in place to prevent malicious apps from getting into the Android Market. While it shouldn’t be a big surprise that Bouncer can be bypassed, we’ll show quite a few ways one can do so. So in this quick screencast, we wanted to demonstrate one of those ways. So in this screencast, we’re going to submit an application to the Android Market and get a connect-back shell on the Bouncer instance when it attempts its runtime dynamic analysis of our mobile application. This allows us to explore the Bouncer environment with an interactive remote shell. So first, we’re going to upload our new malicious APK to the Android Market, using one of our fake Android Market accounts. We’ll fast forward about five minutes to avoid boring you to death waiting for the connect-back. We received the callback and now have a remote interactive shell running on the emulated Android device hosted by Bouncer. We can poke around the system using our shell to look for interesting attributes of the Bouncer environment such as the version of the kernel its running, the contents of the filesystem, or information about some of the devices emulated by the Bouncer environment. If we look in the /sys directory, we immediately notice the qemu_trace directory, exposing the fact that our app is running within Bouncer’s qemu-based emulated environment. So this is just one technique to fingerprint the Bouncer environment, allowing a malicious app to appear benign when run within Bouncer, and yet still perform malicious activities when run on a real user’s device. Of course our presentation will cover this in much more detail so we hope that you’ll make it out to SummerCon this week in New York City. If you can’t make it out we’ll likely be posting the full presentation materials soon after the event. And last but not least, there will be pinatas!