There seems to be some confusion about this, so I'll just copy/paste what I wrote on Twitter:
>Folks, this is bad. Very, very bad. Hackers and/or malicious insiders have leaked the platform certificates of several vendors. These are used to sign system apps on Android builds, including the "android" app itself. These certs are being used to sign malicious Android apps!
>Why is that a problem? Well, it lets malicious apps opt into Android's shared user ID mechanism and run with the same highly privileged user ID as "android" - android.uid.system. Basically, they have the same authority/level of access as the Android OS process!
>The post on the Android Partner Vulnerability Initiative issue tracker shared SHA256 hashes of the platform signing certificates and correctly signed malware using those certificates. Thanks to sites like VirusTotal and APKMirror, it's trivial to see who is affected...
>In any case, Google recommends that affected parties should rotate the platform certificate, conduct an investigation into how this leak happened, and minimize the number of apps signed with the platform certificate, so that future leaks won't be as devastating.
>Okay, so what are the immediate implications/takeaways for users?
>- You can't trust that an app has been signed by the legitimate vendor/OEM if their platform certificate was leaked. Do not sideload those apps from third-party sites/outside of Google Play or trusted OEM store.
>- This may affect updates to apps that are delivered through app stores if the OEM rotates the signing key, depending on whether or not that app has a V3 signature or not. V3 signature scheme supports key rotation, older schemes do not.
>OEMs are not required to sign system apps with V3 signatures. The minimum signature scheme version for apps targeting API level 30+ on the system partition is V2. You can check the signature scheme using the apksigner tool: https://developer.android.com/studio/command-line/apksigner
>Affected OEMs can still rotate the cert used to sign their system apps that have V2 signatures and then push an OTA update to deliver the updated apps. Then they can push app updates with that new cert, but devices that haven't received OTAs won't receive those app updates.
Any idea if signing up for Google's Advanced Protection program would mitigate/prevent potential attacks from this security issue?
My understanding is that signing up for this program blocks the usual methods of installing sideloaded apps (you can't install an app's apk file from your phone's local storage), and instead requires you to physically connect your Android phone to an external computer and use the adb CLI tool to sideload apps that are not on the Google Play store.
If you're speaking from the perspective of an enterprise making recommendations, yes that'd be an option. As a user, though, you could just avoid sideloading.
Just trying to think if there are any other potential immediate recommendations for non-technical friends and family with Android phones from these vendors other than "don't sideload any apps" and "make sure to install any security updates as soon as they're available".
A possible way this occurred was through a hacker compromising a bunch of OEMs like Samsung and LG.
If that's your threat model, "don't sideload" seems insufficient as a response. A hacker who's able to steal the private keys of Samsung and LG (the "crown jewels") may also be able to replace the official apps they upload to the Play store with apps that contain malware.
Plus if I understand other comments correctly, a stolen key allows the thief to privilege escalate from "ability to issue an update for a fart app on your phone" to "ability to root your device".
So if you're serious about security, I would uninstall apps very aggressively, especially apps from the affected OEMs. You can fool around with fart apps on a separate device if you want.
>Folks, this is bad. Very, very bad. Hackers and/or malicious insiders have leaked the platform certificates of several vendors. These are used to sign system apps on Android builds, including the "android" app itself. These certs are being used to sign malicious Android apps!
>Why is that a problem? Well, it lets malicious apps opt into Android's shared user ID mechanism and run with the same highly privileged user ID as "android" - android.uid.system. Basically, they have the same authority/level of access as the Android OS process!
>Here's a short summary of [shared UID](https://blog.esper.io/android-13-deep-dive/#shared_uid_migra...), from my Android 13 deep dive.
>The post on the Android Partner Vulnerability Initiative issue tracker shared SHA256 hashes of the platform signing certificates and correctly signed malware using those certificates. Thanks to sites like VirusTotal and APKMirror, it's trivial to see who is affected...
>So, for example, this malware sample: https://virustotal.com/gui/file/b1f191b1ee463679c7c2fa7db5a2...
>scroll down to the certificate subject/issuer, and whose name do you see? The biggest Android OEM on the planet? Yeah, yikes.
>Go to APKMirror and just search for the SHA256 hash of the corresponding platform signing certificate... https://apkmirror.com/?post_type=app_release&searchtype=apk&...
>Yeah, this certificate is still being used to sign apps.
>That's just one example. [There are others at risk, too.](https://twitter.com/mszustak/status/1598406354464829440)
>In any case, Google recommends that affected parties should rotate the platform certificate, conduct an investigation into how this leak happened, and minimize the number of apps signed with the platform certificate, so that future leaks won't be as devastating.
>Okay, so what are the immediate implications/takeaways for users?
>- You can't trust that an app has been signed by the legitimate vendor/OEM if their platform certificate was leaked. Do not sideload those apps from third-party sites/outside of Google Play or trusted OEM store.
>- This may affect updates to apps that are delivered through app stores if the OEM rotates the signing key, depending on whether or not that app has a V3 signature or not. V3 signature scheme supports key rotation, older schemes do not.
>OEMs are not required to sign system apps with V3 signatures. The minimum signature scheme version for apps targeting API level 30+ on the system partition is V2. You can check the signature scheme using the apksigner tool: https://developer.android.com/studio/command-line/apksigner
>Affected OEMs can still rotate the cert used to sign their system apps that have V2 signatures and then push an OTA update to deliver the updated apps. Then they can push app updates with that new cert, but devices that haven't received OTAs won't receive those app updates.