Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 8 Apr 2024 21:10:58 +0200
From: Fay Stegerman <>
Subject: PoC for fdroidserver AllowedAPKSigningKeys certificate pinning bypass


This is published here:

I've attached the PoC and patch and included the text from the README below.

- Fay


# F-Droid Fake Signer PoC

PoC for fdroidserver AllowedAPKSigningKeys certificate pinning bypass.

## Background

We started looking into Android APK Signing Block oddities at the request of
F-Droid [1] on 2021-08-25; we opened F-Droid issue "APK Signing Block
considerations" [2] on 2022-10-19.  No action was taken as a result.

We published the "Android APK Signing Block Payload PoC" [3] to the
Reproducible Builds mailing list [4] on 2023-01-31.

> But the Android APK Signature Scheme v2/v3 actually allows embedding
> arbitrary data (or code) in the signing block, meaning that two APKs with
> the exact same valid signature -- though not a bit-by-bit identical
> signing block -- can behave differently.

Jason Donenfeld reported "Potential security hazard:
apk_signer_fingerprint() looks at certs in reverse order that Android checks
them" [5] on 2023-05-05; no action was taken to fix this bug.

> However, there's a discrepancy between how these certificates are
> extracted and how Android actually implements signature checks. [...]
> Notice how [the google flowchart [6]] checks v3, then v2, and then v1.
> Yet the [F-Droid] code above looks at v1, then v2, and then v3, in reverse
> order. So v1 could have a bogus signer that some versions of Android never
> even look at, yet fdroid makes a security decision based on it. Yikes!
> Also, it's worth noting that apk_signer_fingerprint() also does not bother
> validating that the signatures are correct.

Andreas Itzchak Rehberg (IzzyOnDroid) reported about "BLOBs in APK signing
blocks" in "Ramping up security: additional APK checks are in place with the
IzzyOnDroid repo" [7] on 2024-03-25.  The accompanying German article
"Android-Apps auf dem Seziertisch: Eine vertiefte Betrachtung" [8] points
out that we noticed that that apksigner and androguard handle duplicate
signing blocks rather differently: the former only sees the first, the
latter only the last, which allows all kinds of shenanigans.

## Observations

We observed that embedding a v1 (JAR) signature file in an APK with minSdk
>= 24 will be ignored by Android/apksigner, which only checks v2/v3 in that
case.  However, since fdroidserver checks v1 first, regardless of minSdk,
and does not verify the signature, it will accept a "fake" certificate and
see an incorrect certificate fingerprint.

We also realised that the above mentioned discrepancy between apksigner and
androguard (which fdroidserver uses to extract the v2/v3 certificates) can
be abused here as well.  Simply copying the v2/v3 signature from a different
APK and appending it to the APK Signing Block will not affect apksigner's
verification, but androguard, and thus also fdroidserver, will see only the
second block.  Again, the signature is not verified, a "fake" certificate
accepted, and an incorrect fingerprint seen.

As a result, it is trivial to bypass the AllowedAPKSigningKeys certificate
pinning, as we can make fdroidserver see whatever certificate we want
instead of the one Android/apksigner does.  Note that we don't need a valid
signature for the APK (we really only need a copy of the DER certificate,
though having another APK signed with the certificate we want to use makes
things easy).

## PoC

NB: you currently need the signing branch of apksigtool [9].

NB: the "fake" signer shown here is from the official F-Droid client (its
APK has a v1+v2+v3 signature), the one apksigner sees is randomly generated
by; the app.apk used for testing had minSdk 26 and a v2
signature only.  Using APKs with other signature scheme combinations is
certainly possible, but might require adjusting the PoC code accordingly.

$ ./             # generates a dummy key
$ python3    # uses app.apk (needs minSdk >= 24) as base, adds fake.apk .RSA
$ python3         # verifies and has fake.apk as signer according to F-Droid
$ python3    # uses app.apk as base, adds signing block from fake.apk
$ python3         # verifies and has fake.apk as signer according to F-Droid
$ apksigner verify -v --print-certs poc.apk | grep -E '^Verified using|Signer #1 certificate (DN|SHA-256)'
Verified using v1 scheme (JAR signing): false
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): true
Verified using v4 scheme (APK Signature Scheme v4): false
Signer #1 certificate DN: CN=oops
Signer #1 certificate SHA-256 digest: 029df1354735e81eb97c9bbef2185c8ead3bc78ae874c03a6e96e1e1435ac519

$ mkdir fakesigner
$ cd fakesigner
$ fdroid init -d oops --repo-keyalias fakesigner
$ mkdir metadata
$ printf 'Name: MyApp\nAllowedAPKSigningKeys: 43238d512c1e5eb2d6569f4a3afbf5523418b82e0a3ed1552770abb9a9c9ccab\n' > metadata/
$ cp /path/to/poc.apk repo/
$ fdroid update
$ jq '.packages[].versions[].manifest.signer.sha256' < repo/index-v2.json

## Patch

The fdroidserver.patch changes the order so it matches Android's v3 before
v2 before v1, and monkey-patches androguard to see the first block instead
of the last one if there are duplicates.  This is still likely to be
incomplete, but prevents the known bypasses described here.

## References

* [1]
* [2]
* [3]
* [4]
* [5]
* [6]
* [7]
* [8]
* [9]

## Links


Download attachment "" of type "application/x-sh" (198 bytes)

View attachment "" of type "text/x-python" (698 bytes)

View attachment "" of type "text/x-python" (852 bytes)

View attachment "" of type "text/x-python" (416 bytes)

View attachment "fdroidserver.patch" of type "text/x-diff" (2301 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.