The antivirus scanner that polices Google’s Android Market is named Miles Karlson. It has one friend, Michelle K. Levin, and a cat. And it seems to be a fan of Lady Gaga.
Those are a few of the many personal characteristics that security researchers Charlie Miller and Jon Oberheide have spent the last several months learning about Google’s newest safeguard for Android users, the scanning program it launched with the codename “Bouncer” in February. And knowing just one of those seemingly random details, they say, would be enough for a malicious app to hide itself from Google’s protective scans and find its way onto a user’s device.
At the Summercon conference in New York this week, Miller and Oberheide plan to present a new method for bypassing Google’s mobile app store’s protections against programs that steal data, send spam or siphon a victim’s money by making calls to premium numbers. Their method takes advantage of the fact that Google’s ‘Bouncer’ tool tests apps by running them in a virtualized environment–a simulated phone created in software–to see how they’ll perform on real users’ devices. And if malware can be designed to detect that it’s running on that simulated gadget rather than the real thing, it can temporarily suppress its evil urges, pass Google’s test and make its way onto a real phone before wreaking havoc.
“The question for Google is, how do you make it so the malware doesn’t know it’s running in a simulated environment?” says Oberheide. “You want to pretend you’re running a real system. But a lot of tricks can be played by malware to learn that it’s being monitored.”
Oberheide and Miller say they submitted a testing application to the Android Market that gives them remote access to a target device to analyze Bouncer’s scans and catalogue the “fingerprints” that malware can use to determine whether it’s in the test environment: And Google’s simulated test phone leaves behind all the identifying characteristics of any bot pretending to be a flesh-and-blood user. Every instance of Google’s simulated Android phone, they discovered, is registered to the same account, Miles.Karlson@gmail.com. To bait malware into trying to steal photos or contacts, Bouncer’s test phone lists exactly one contact (Michelle.email@example.com) and stores two photos: Cat.jpg and Ladygaga.jpg. (Pictured above)
Some other giveaways are more subtle: Miller and Oberheide say that they can find evidence in a file subdirectory that the phone is running on QEMU, a type of virtualization software. (Oberheide demonstrates this in the video below.) The virtual phone’s performance is slower than a real phone. And if the program sets the phone to access an outside server, that server can identify its IP address as one that belongs to Google.
“There are a thousand different ways to very accurately and sustainably fingerprint Bouncer,” says Oberheide. “Some are really hard to fix. Some can be fixed pretty easily. But in the long term game, the attackers have a major advantage.”
To prove his point, Oberheide uploaded an application called HelloNeon to the Android Market Sunday night that’s capable of pulling down new malicious code once it’s installed on a user’s phone. It passed Bouncer’s scan and was available for download Monday morning.
Oberheide says he and Miller have spoken to Google’s security staff about their work, and Google may have already changed some of the characteristics of Bouncer to make its simulations harder to differentiate from a real user’s phone. I reached out to Google to confirm Oberheide’s and Miller’s findings and hear the company’s comments, but I haven’t yet heard back.
Both Miller and Oberheide have a long history of poking holes in the security measures for mobile devices. In 2010, Oberheide showed that programs posing as innocuous apps like an Angry Birds upgrade or Twilight photos could pull down new malicious code after making their way onto a user’s device. Miller, one of the world’s top Apple hackers, exploited a bug last year in the iOS app store that allowed an app he created to similarly download and execute new code despite Apple’s code-signing restriction, a measure designed to prevent unauthorized commands from running on iPhones and iPads.