AI
Bot Fraud That Created a Zero-Day Market
The research target ran an Android app where users raced to claim offers. Bot service providers wrote Python scripts, ran them on cloud VMs, and cut out legitimate users so thoroughly that you couldn’t compete without paying for a bot. They owned the entire service.
The company’s countermove was Android key attestation: attest every client, force bot operators to hold a physical device per session, make the margin disappear. Bot numbers dropped, then recovered within weeks. The profit was still there, and operators started hunting for bypasses.
“we basically created a zero-day market for Android key attestation — bot service providers were looking for all the ways that they can basically circumvent the implementation” — Alex Gonzalez
That demand sent Gonzalez into the codebase looking for zero-days himself.
What Android Key Attestation Actually Does
Key attestation is not app attestation. App attestation (Play Integrity API) checks whether the binary on the device matches the Play Store copy. Key attestation proves a key pair lives in secure hardware. The private key never leaves the Android KeyStore. What the device produces is an X.509 chain signed up to a Google root, with a custom OID extension in the leaf that reports hardware security level, bootloader state, and patch metadata. Developers receive that chain and must validate it themselves. They verify each certificate against its predecessor, check Google’s revocation list for compromised key boxes, and parse the attestation extension in the leaf.
Three Common PKI Bypass Techniques
Three attack classes cover most implementations. The first targets chain-of-trust validation: generate an EC key pair outside the TEE, forge a leaf with a fake OID attestation extension, and append it to a legitimate chain. An off-by-one error stopped validation at the intermediate. The forged leaf returned a valid session token. Forged chain bypasses research target (chain-of-trust miss) The second uses leaked key boxes. Manufacturer EC private keys circulate in Telegram ROM channels; backends that skip CRL checks accept them. The third: the Trusty TEE key pair for pre-Android 7 is in AOSP source. Developers allow-list it for testing and ship it to prod.
“this works way too often because if you’re a developer, how do you actually like do end to-end testing uh, for your app that’s using Android Kia test station if you must use a physical attested device?” — Alex Gonzalez
Certificate Extension Attack and the Forgery Proof-of-Concept
The attack appends a forged leaf to a legitimate hardware-backed chain. X.509 basic-constraints marks a leaf’s CA field false, blocking it from signing further certificates. Validators that skip that check accept it. Gonzalez wrote an Android app that generates an attacker-controlled EC key pair in memory, signs a forged leaf using the legitimate key store key, and prints the chain to stdout. That chain goes to the backend in a POST request. Certificate extension forgery confirmed working on target: the research target returned a valid session key, giving full API access from a Python script with no physical device required.
Root Cause: Google’s Library Shipped Broken Validation for Seven Years
Google’s official key attestation library shipped in 2016 with no CVE process, no versioned releases, and no central repository. The 2023 fix never triggered a notification — it landed as a silent commit on main. The library’s “fix” didn’t check basic-constraints or key-usage extensions. It assumed developers always pass certificates leaf-first. When Gonzalez tested with root-first ordering, Root-first ordering flips the library’s leaf-selection logic — the parser treated the attacker-controlled leaf as legitimate and bypassed attestation checks entirely. Google declined to issue a CVE, citing insufficient severity. The documentation still points to the deprecated repo.
State of the Ecosystem and the KIA Tester Tool Release
Any app that implemented Android key attestation between 2016 and 2023 using Google’s official library is vulnerable to a certificate extension attack. Post-2023 implementations may be fixed, depending on how carefully developers handled certificate ordering. New implementations get a replacement library that is still under active development. Underground Telegram channels are paying researchers to suppress TEE disclosures and keep compromised key boxes off revocation lists. That market exists because the profit margin holds. Fix your own implementation: Gonzalez is releasing KIA Tester, an open-source library that builds forged X.509 chain payloads covering every bypass class from the talk. After the research target patched, bot traffic dropped from 30% to 2%.
Q&A
Did you try filing a CVE retrospectively to say this version is still a thing? They submitted three times — Google punted between Android and open-source VRP teams for months, then declined to issue a CVE, saying the bug didn’t warrant the severity. ▶ 38:38
If not that library, what should people have been using — or is this a generic cop-out of liability? Gonzalez called it a liability cop-out and recommended rolling X.509 chain validation using Java PKIX built-ins plus the webauthn4j library, which handles all attestation types and is actively maintained. ▶ 39:47
Notable Quotes
there was no information at all about actually just breaking the PKI trust model, which really is the lowhanging fruit here Alex Gonzalez · ▶ 13:18
we basically created a zero-day market for Android Kia testation bot service providers were looking for all the ways that they can basically circumvent the implementation Alex Gonzalez · ▶ 4:00
they didn’t feel that it uh warranted the severity to release a CVE Alex Gonzalez · ▶ 39:20
this works way too often because if you’re a developer, how do you actually like do end to-end testing uh, for your app that’s using Android Kia test station if you must use a physical attested device? Alex Gonzalez · ▶ 20:19
Key Takeaways
- Validate X.509 basic-constraints extensions explicitly — ordering-based hacks in Google’s own library are bypassable by flipping chain order.
- Any app using Google’s key attestation library before the 2023 silent patch is implicitly vulnerable to certificate extension attacks.
- Test every attestation implementation with forged chains before deploying; proper validation dropped bot traffic from 30% to 2%.