Risk
6/7/2012
01:57 PM
Connect Directly
RSS
E-Mail
50%
50%

Google Play Exploits Bypass Malware Checks

Security researchers find multiple ways to bypass Bouncer, Google's automated service for spotting malicious Android apps.

Two well-known smartphone security researchers said they've found multiple techniques for bypassing Bouncer, the automated system Google uses to keep malicious applications out of Google Play, its official Android application store (formerly dubbed Android Market).

The researchers--Jon Oberheide, CTO of DUO Security, and Charlie Miller, principal research consultant at Accuvant Labs--plan to present their research at Summercon this Friday. The pair said they've shared full details in advance with Google.

Android is now the most-used smartphone operating system, on track to command 61% of the global smartphone market this year, according to IDC.

After a flurry of news reports highlighted a marked increase in Android malware volumes, Google earlier this year responded by disclosing the existence of Bouncer. According to Google, between the first and second half of 2011 Bouncer reduced by 40% the number of malicious applications downloaded by users of the Android application marketplace.

[ Read about how hackers used Gmail's password recovery to breach security site. See Google Apps Security Beat By CloudFare Hackers. ]

How many different techniques did the two researchers discover for bypassing Bouncer? "Hard to count, but I'd say at least 20 is a safe bet," said Oberheide, an independent security researcher with extensive mobile security experience, via email. "At that point, finding new minor ones is not very interesting, but finding ones that are difficult to fix or generally asymmetric--in the attackers' favor--in the long-term are."

The researchers were able to submit an app for Google Play-vetting that established a connect-back shell in the Bouncer infrastructure, thus allowing them to probe how it works.

"To Google's credit, we did get caught a couple times during our probes, although we were being pretty blatant at the time. I remember receiving a connect-back from an entirely different IP address from the normal Bouncer range--but still owned by Google--and interacting with it briefly before realizing it wasn't operating as expected and was most likely a manual reviewer checking out our app after it was flagged," said Oberheide. "I tried to send some friendly messages to that person."

The researchers also discovered that Bouncer is based on QEMU, a popular emulator that has had its share of vulnerabilities in the past, according to Oberheide. Accordingly, he explained, "It may be possible to exploit the Bouncer infrastructure itself by exploiting a bug in QEMU. Obviously, this is something that crosses the ethical lines of research,"--meaning he didn't test any such attacks--"and I'm sure [it] has been considered appropriately by Google."

Oberheide said that he and Miller weren't surprised that they could find Bouncer-bypassing techniques, given the "complex black box" approach that Google is undertaking. "Google's trying to solve a pretty difficult problem here: make a fake emulated device that looks and operates indistinguishably from a real user's device," Oberheide explained. "Not a simple thing."

After Google highlighted the existence of Bouncer, security experts pointed out that while such services are helpful, they're not foolproof. Security researcher Dmitry Bestuzhev at Kaspersky Lab, for example, has suggested that attackers might find ways of defeating the emulation environment used by Bouncer, or disguising any malicious behavior until after the application had cleared the malicious-intent review.

Oberheide seconded the feasibility of such an attack scenario. He explained that it could be accomplished by fingerprinting the emulation environment--as he and Miller have done--and then instructing an app to "look normal" as long as it's in that environment. "The easiest way to 'bypass' Bouncer is to not do anything malicious/suspicious when your app is running within it," he said. "Therefore, your app passes its test and can be distributed to your real target: users."

Apple last year banned Miller from its iOS developer program for one year for testing a proof-of-concept attack of that very nature. Notably, Miller was able to sneak proof-of-concept malware past Apple's iOS review teams, resulting in his application becoming available via the official Apple App Store.

In response to his temporary iOS developer program excommunication, Miller asked why Apple had bothered to give free accounts to security researchers such as himself. "If I'm the only bad guy in the world right now, you guys are perfectly safe," Miller quipped earlier this year at the RSA conference in San Francisco.

In the case of the Bouncer-bypassing techniques Miller and Oberheide identified, Google didn't immediately respond to an emailed request for comment about whether the flaws might be used in real-world scenarios by malware creators to place malicious apps on Google Play. But Oberheide suggested that if he and Miller can find vulnerabilities, so can people with malicious intentions.

"Based on what we've seen in the traditional malware world, malware authors are great at sharing code and techniques," he said. "I wouldn't be at all surprised if sophisticated malware is already bypassing Bouncer and unsophisticated malware will definitely catch up as techniques become more widely known. That being said, Bouncer itself will continue to improve and evolve to increase its efficacy."

Google also hasn't commented about whether it might have the exploits patched before the researchers' Friday conference presentation. "I know some of the folks working on Bouncer at Google, and they're top-notch, so they're definitely aware of its weaknesses and I'm sure are working to address them," said Oberheide. "These types of weaknesses aren't simple things to patch, though, so I don't think they'll be in place in the short term."

Black Hat USA Las Vegas, the premiere conference on information security, features four days of deep technical training followed by two days of presentations from speakers discussing their latest research around a broad range of security topics. At Caesars Palace in Las Vegas, July 21-26. Register today.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2009-5142
Published: 2014-08-21
Cross-site scripting (XSS) vulnerability in timthumb.php in TimThumb 1.09 and earlier, as used in Mimbo Pro 2.3.1 and other products, allows remote attackers to inject arbitrary web script or HTML via the src parameter.

CVE-2010-5302
Published: 2014-08-21
Cross-site scripting (XSS) vulnerability in timthumb.php in TimThumb before 1.15 as of 20100908 (r88), as used in multiple products, allows remote attackers to inject arbitrary web script or HTML via the QUERY_STRING.

CVE-2010-5303
Published: 2014-08-21
Cross-site scripting (XSS) vulnerability in the displayError function in timthumb.php in TimThumb before 1.15 (r85), as used in multiple products, allows remote attackers to inject arbitrary web script or HTML via unspecified vectors related to $errorString.

CVE-2014-3562
Published: 2014-08-21
Red Hat Directory Server 8 and 389 Directory Server, when debugging is enabled, allows remote attackers to obtain sensitive replicated metadata by searching the directory.

CVE-2014-3577
Published: 2014-08-21
org.apache.http.conn.ssl.AbstractVerifier in Apache HttpComponents HttpClient before 4.3.5 and HttpAsyncClient before 4.0.2 does not properly verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Three interviews on critical embedded systems and security, recorded at Black Hat 2014 in Las Vegas.