[<prev] [next>] [day] [month] [year] [list]
Date: Sun, 21 Apr 2024 00:02:06 +0200
From: Fay Stegerman <flx@...usk.net>
To: oss-security@...ts.openwall.com
Subject: [Update] PoC for fdroidserver AllowedAPKSigningKeys certificate
pinning bypass
Hi!
An update for [1], still published at [2]: a third PoC, a second patch, and
a script to scan for potentially affected APKs. I've attached the new files
and included the new sections from the README with the updates below.
Meanwhile, upstream has performed their own analysis and confirmed being
affected by the previously reported vulnerabilities [3]. At present they have
not yet applied any of the suggested patches. A "fix is in the works" [4] but
repeated warnings that their deviation from the provided second patch would
leave the vulnerability unfixed have been ignored.
- Fay
[1] https://www.openwall.com/lists/oss-security/2024/04/08/8
[2] https://github.com/obfusk/fdroid-fakesigner-poc
[3] https://gitlab.com/fdroid/fdroidserver/-/issues/1128
[4] https://gitlab.com/fdroid/fdroidserver/-/merge_requests/1466
============================================================================
# F-Droid Fake Signer PoC
PoC for fdroidserver AllowedAPKSigningKeys certificate pinning bypass.
Published: 2024-04-08; updated: 2024-04-14, 2024-04-20.
[...]
### [Observations] Update (2024-04-14)
Having been asked about multiple certificates in APK signatures [5], we
realised that, like v2/v3 signatures, v1 signatures can indeed also contain
multiple certificates (e.g. a certificate chain, though neither jarsigner
nor apksigner seem to enforce any relationships between certificates).
However, unlike v2/v3 -- which guarantee that the certificate used for the
signature is always the first in the sequence -- v1 does not define an
ordering: the signature block file is a PKCS#7 DER-encoded ASN.1 data
structure (per RFC 2315) and uses a SET for the list of certificates.
Android/apksigner will find and use the first certificate that matches the
relevant SignerInfo, ignoring any other certificates, but fdroidserver
always returns the first certificate it finds in the signature block file.
Thus we can once again trick it into seeing any certificate we want -- as
long as it only checks the v1 certificate (e.g. when the fdroidserver.patch
has not been applied or the APK only has a v1 signature).
NB: apps with targetSdk >= 30 are required to have a v2/v3 signature.
NB: Android < N will only check the first SignerInfo, later versions pick
the first one that verifies if there are multiple.
### [Observations] Update (2024-04-20)
Despite repeated warnings [5] that using the last certificate instead of the
first one does not in any way fix the vulnerability described in the
2024-04-14 update (PoC #3), the proposed patches for fdroidserver [10] and
androguard [11] do exactly this. With that patch, version A (which inserts
the fake certificate first) of the PoC now fails, but version B (which
inserts it last) now works.
[...]
### [PoC] Update (2024-04-14)
NB: version A, for fdroidserver using the first v1 certificate.
```bash
$ python3 make-poc-v3a.py # uses app2.apk (needs targetSdk < 30) as base, adds fake.apk .RSA cert
$ python3 fdroid.py # verifies and has fake.apk as signer according to F-Droid
True
43238d512c1e5eb2d6569f4a3afbf5523418b82e0a3ed1552770abb9a9c9ccab
```
### [PoC] Update (2024-04-20)
NB: version B, for fdroidserver using the last v1 certificate.
```bash
$ python3 make-poc-v3b.py # uses app2.apk (needs targetSdk < 30) as base, adds fake.apk .RSA cert
$ python3 fdroid.py # verifies and has fake.apk as signer according to F-Droid
True
43238d512c1e5eb2d6569f4a3afbf5523418b82e0a3ed1552770abb9a9c9ccab
```
[...]
### [Patch] Update (2024-04-14)
The fdroidserver-multicert.patch simply rejects any v1 signatures with
multiple certificates. This may reject some valid APKs, but handling those
properly is nontrivial and there should be few APKs with multiple
certificates and no v2/v3 signatures in the wild (e.g. the IzzyOnDroid
repository found none in its catalog). We recommend using the official
apksig library (used by apksigner) to both verify APK signatures and return
the first signer's certificate to avoid these kind of implementation
inconsistencies and thus further vulnerabilities like this one.
## Scanner (2024-04-15, 2024-04-20)
The scan.py script can check APKs for *possible* signature issues: it will
flag APKs that are not clearly signed with a single unambiguous certificate,
which *could* result in the kind of accidental misidentification of the
signer -- despite successful verification by apksigner -- that we've
demonstrated here. Unfortunately, such misidentification can easily happen
as even the official documentation of the various signature schemes does not
completely cover how Android/apksigner handles such cases.
NB: this will flag some valid APKs too, e.g. those with certificate chains,
those having used key rotation, or those with multiple signers; as the
IzzyOnDroid repository found none in its catalog, these cases luckily seem
to be relatively rare.
```bash
$ python3 scan.py poc*.apk
'poc1.apk': Mismatch between v1 and v2/v3 certificates
'poc2.apk': Duplicate block IDs
'poc3a.apk': Multiple certificates in signature block file
'poc3b.apk': Multiple certificates in signature block file
```
## References
[...]
* [5] https://gitlab.com/fdroid/fdroidserver/-/issues/1128
[...]
* [10] https://gitlab.com/fdroid/fdroidserver/-/merge_requests/1466
* [11] https://github.com/androguard/androguard/pull/1038
[...]
View attachment "fdroidserver-multicert.patch" of type "text/x-diff" (618 bytes)
View attachment "make-poc-v3a.py" of type "text/x-python" (3582 bytes)
View attachment "make-poc-v3b.py" of type "text/x-python" (3581 bytes)
View attachment "scan.py" of type "text/x-python" (4847 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.
