USA 2012

### Overview In this Black Hat presentation titled "Adventures in Bouncer Land," researchers Nick Percoco and Sean Schulte explore the mechanics, capabilities, and limitations of Google Bouncer—an automated scanner introduced by Google to detect and mitigate malicious applications in the Android Marketplace (now Google Play). Motivated by questions about whether automated scanning effectively neutralizes Android malware, the speakers set out to test the boundaries of Bouncer without attempting to breach Google's infrastructure or distribute malware to real users.

### Key Topics - **Bouncer Architecture and Assumptions:** Google revealed that Bouncer executes automated dynamic, behavior-based checks and static scans in an emulated cloud environment both upon app submission and post-publication. - **Research Methodology and Safety Rules:** The researchers established strict ground rules: behave like normal developers using standard SDK tools, avoid compromising Google infrastructure, and price the research app high ($49.95) to prevent any end users from installing it. - **Dynamic Code Execution via JavaScript Bridge:** Investigating how modern apps (such as Netflix and Facebook) deploy hybrid web-wrapper architectures, the speakers demonstrate that an application can use Android's WebView and `addJavascriptInterface` to dynamically load and execute unverified remote JavaScript payloads with native platform SDK permissions, bypassing code-signing assumptions. - **Detection Evasion via IP Profiling:** Bouncer's behavioral scanning environment exhibited identifiable traits, such as running in an emulator originating from a known Google IP range (`74.125.0.0/16`), allowing malware to serve benign code during analysis while serving malicious instructions to victims.

### Technical Details To evaluate Bouncer, the speakers developed a seemingly benign Android application called "SMS Blockster" that legitimately requested sensitive permissions (reading SMS, contacts, and phone state). Key technical findings include: - **Alarm Manager & Persistence:** Using `AlarmManager` with `RTC_WAKEUP` allowed background tasks to execute periodically without appearing in the user's active running apps list. - **Bouncer Execution Characteristics:** Within minutes of app submission or updates, Bouncer executed the application from Google-owned IPs (`74.125.x.x`). The emulator environment simulated a device with specific dummy attributes (including a fake phone number, SIM serial, and contact entry for the White House). - **Incremental Testing:** The researchers iteratively submitted updates pairing legitimate features with dual-use capabilities (e.g., contact selection paired with contact exfiltration, phone Recon, focus-stealing/screen hijacking to push URLs, and background HTTP denial-of-service traffic). None of these triggered rejection during regular iterative scans. - **Triggering Bouncer:** The app was only flagged and removed after researchers removed Google IP blacklisting and programmed the application to aggressively ping and exfiltrate personal data every second immediately upon launch. Following an initial burst scan and a secondary verification scan six minutes later, the developer account was terminated 24 hours later.

### Takeaways Automated entry-point application scanning alone cannot completely eliminate mobile malware. Because dynamic code loading mechanisms (like WebView JavaScript interfaces) allow an application's behavior to shift post-installation, attackers can easily evade static and initial behavioral checks. The speakers advocate for defense-in-depth on mobile platforms, including endpoint-level behavioral monitoring, restricting untrusted remote JavaScript access to native APIs, and scanning from diverse, non-static network ranges.