parse APKv1 signatures with a cert chain like apksigner

[eighthave]

Microsoft signs their APKs with a X.509 certificate chain of trust, so there are actually three certificates included. apksigner only cares about the certificate that actually signs the manifest and ignores the certificates that just sign other certificates.

• https://apkpure.com/microsoft-edge-preview/com.microsoft.emmx/download
• https://gitlab.com/fdroid/fdroidserver/-/issues/1128
• https://gitlab.com/fdroid/fdroidserver/-/merge_requests/1466

The correct values for the test case come from:

$ apksigner verify --print-certs Microsoft\ Edge\ Web\ Browser_123.0.2420.102_Apkpure.apk 
Signer #1 certificate DN: CN=Microsoft Corporation Third Party Marketplace (Do Not Trust), OU=Microsoft Edge for Android, O=Microsoft Corporation, L=Redmond, ST=Washington, C=US
Signer #1 certificate SHA-256 digest: 01e1999710a82c2749b4d50c445dc85d670b6136089d0a766a73827c82a1eac9
Signer #1 certificate SHA-1 digest: 3f640e279f63bcea71082ae7e8c7efa2da014cad
Signer #1 certificate MD5 digest: 6b49faa1405d6a04ff7a0343cf943a7d

[eighthave]

The logs are so verbose, I can't see what the failure is. Any way to change that?

[eighthave]

I forgot to add the new test APK!

[eighthave]

Looks like the official algorithm is to loop through the certificates, and verify which one works with the .SF manifest. That would be great to have. This change makes things work for all the APKs I could find. But in theory, there could be cases were it is wrong, but wrong in the same way as before this change: choosing a certificate purely based on the order it is included.

[IzzySoft]

As we told you before: checking just either the first or either the last would not be right. A patch was provided. Meanwhile, for more details summed up and a POC included, please refer to https://www.openwall.com/lists/oss-security/2024/04/20/3 – and follow up to https://github.com/obfusk/fdroid-fakesigner-poc

That would be great to have.

You could have asked @obfusk for it, she'd have provided that.

[eighthave]

What would be great to have is a Python implementation of the algorithm in apksigner. #313 Unfortunately, neither that oss-security post nor that fdroid-fakesigner-poc contain that. I would welcome a full implementation as a replacement for this pull request

[IzzySoft]

Sorry Hans: I'm neither profound enough in Python, nor educated enough in the topic at hand to provide such an implementation. I can read the code, yes. And after being explained, I was able to understand enough to evaluate the patch and apply it with confidence. I'm aware that the patch is not complete, and more or less simply blocks APKs potentially targeting the vulnerability – and that it would have no unwanted side-effects (to my repo, or to F-Droid's at that). But that's all.

So all I can say here is you don't need the first cert, or the last cert, but the matching cert. This patch simply uses the last cert instead of the first, it doesn't check if it's really the corresponding cert. So it does not really fix a thing. Certs are not ordered in v1, they are just an unordered set.

[eighthave]

That's all true. This pull request does fix the one case I could find of APKs signed by a certificate chain: Microsoft. An APK could still exploit this algorithm in the same way as before this pull request.

[IzzySoft]

But it breaks things for other cases, if I understood Fay correctly. I don't know if it's a good idea to base this on a single example APK only. A second one might have the order inverted, a third one having the needed cert in the middle. The next release of the same app might do one of the two even.

So I don't think this change is expedient, and would rather discourage merging it. Better have androguard spit out a warning if it encounters such a case where it cannot tell for sure which cert is the right one, maybe.

But as I wrote on the related issue at fdroidserver, I'm only the messenger here – the one with some basic understanding acquired in the process (as the issue with fdroidserver was reported to me as well, and I had to see to safeguarding my repo), not the expert with long-time experience in the field who could give profound advice. So while I felt obliged to put in the little I know about it to make sure it's not missed but considered (to prevent harm if there is such involved), I cannot provide a solution unfortunately.

[erev0s]

Hi @eighthave , appreciate the effort put into the pull request. It does not seem wise to move forward with replacing one problematic section with another that also has issues.
Once a suitable fix is submitted, I will be more than happy to accept it.
In the meantime your idea @IzzySoft about androguard warning the user when such scenario is met, seems the best course of action.

[eighthave]

To actually do it fully correctly, there basically has to be a full JAR signature verification. That's not something I'm going to implement. @obfusk has already done a lot of work there with https://github.com/obfusk/apksigtool, so I'll defer to her.