Android has become the most popular mobile operating system with consumers, which means it has become the rage for malware writers also. To combat that, earlier this year Google introduced Bouncer, a system that looks for malicious apps in the Google Play market.
Bouncer, which checks for malicious apps and known malware, is a good first step, but an attacker can bypass it quite easily and in ways that will be difficult for Google to address in the long term, said researchers.
As a part of their research, mobile security experts Oberheide and Miller went into their experiment without much detailed knowledge of how Bouncer works. Google has said little publicly about its capabilities, preferring not to give attackers any insights into the system’s inner workings. So Oberheide and Miller looked at it as a challenge to see how much they could find out about Bouncer from the outside, and the inside.
“The problem that Bouncer faces is very similar to the problems that normal antivirus analysts face. Malware will fingerprint the system it’s on to see whether it’s running in a virtualized environment or in an emulator,” Oberheide said. “Bouncer was designed by people I know really well, and I wanted to see how they’d design a system. It was a total black-box approach for us, to see how much we could learn by submitting apps and poking around.”
The researchers set up fake Google accounts and began submitting apps to Google Play, the new name for the Android Market. They wanted to get a sense of the kind of environment Google uses to analyze apps, see what weak spots the system may have and then look for methods to use them to bypass Bouncer entirely. One of the apps that they submitted contained some functionality that called out to a server the researchers controlled once it was in the Bouncer environment. The app gave them a remote shell on the system and the ability to issue commands and see what was happening as Bouncer was analyzing the app.
The researchers noticed their app was running inside an emulator. That gave them data they could use in future submissions to hide malicious functionality if an app discovers it’s running in such an environment.
“It’s pretty trivial for us to bypass now, but I’m sure Google will make changes,” said Oberheide.
By looking at the traffic coming to the command-and-control server they set up, the researchers were able to see that all of the requests were coming from one Google IP block, something an attacker could easily identify. Google could change that IP block, Oberheide said, but then the company would need to get IP space from a variety of providers and send traffic through those IP blocks.
Oberheide also said Google’s security caught them a few times during their research.
“We were a little overzealous and didn’t take many precautions at the beginning,” Oberheide said. “We wanted to see what it took to get caught. Some of them were blatant, like capturing a lot of data and sending it back out. We saw some follow-up from them that looked to be manual. It came from a Google IP address, but not in the Bouncer block. We got caught when our app was calling back to a server I run, but we got stealthier after that.”
Another interesting thing the two noticed is it is possible to upload apps to the system and have them analyzed by Bouncer without a valid credit card or account. So malware authors could try various tactics in their apps and see whether they’re successful without needing to burn a stolen card.
The researchers have talked with Google about the general outline of their findings and Oberheide said he expects the company to respond, but that the larger problem with Bouncer will be difficult to solve.
“These issues are non-trivial to fix. They can knock off a few of the easier ones, but it’s a long-term problem,” he said.