16 ms·

Platform certificates used to sign malware

684 points by arkadiyt 4y ago

skp1119 4y ago
In my opinion, mobile Authentication should be perform along with registered mobile’s IMEI number + sim unique number or telecom providers unique token number. This can be easily done by Microsoft , intuine . This will be one additional layer of protection to your mobile auth
solarkraft 4y ago
This is confidence-inspiring considering that Google now requires letting them sign your apps for some features now. > OEMs have mitigated the issues above in previous updates. Yeah, sure they have. Because OEMs are so good at updates. Would be interesting to see how many users such updates are available to. My guess is between 20 to 40%.
deleted 4y ago
[deleted]
remram 4y ago
So this was disclosed November 11 (edit: or maybe May 13 as per green text?) and became public yesterday November 30. Leaves little time for Android devices to get the new key no?
- themoonisachees 4y ago
  If may 13 which would make more sense then there have been several android security patches since. Devices no longer supported are toast though
  - remram 4y ago
    I think for the industry as a whole there should be some penalty or disincentive for going "we're no longer providing updates" and then "we lost the key that gives full access to the system".
- MishaalRahman 4y ago
  >Leaves little time for Android devices to get the new key no? It's not so simple, also rotating the keys could affect how devices get app updates, depending on whether or not an 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. 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.
- michaelt 4y ago
  This isn't the kind of security issue where disclosing it allows new attackers to start exploiting it - because new attackers haven't compromised the keys. So there's little reason to keep the compromise secret, except to let your partners save face.
Denvercoder9 4y ago
What's the blast radius of this? Are only specific models of phones affected (if so, which?), or does this impact entire brands or the whole ecosystem?
- MishaalRahman 4y ago
  It's isolated to devices from the specific brands whose platform certs were leaked and are still being used to sign apps.
- ezekiel68 4y ago
  I'm no expert but judging from what seem to be informed comments in this topic, the main attack vector might be restricted to the side-loading not of regular apps, but of system-level components. If that's true, the blast radius would be fairly small indeed (though still not good in those cases).
arciini 4y ago
This thread leaves a lot of unanswered questions: 1. This was likely mitigated through a device update. What version did it roll out with? Which devices are still unpatched? 2. How was it compromised? Was it an OEM? An internal leak at Google? 3. What is the attack vector? It sounds like it was likely side-loading apps used by some attacker, but did any of these make it onto the Play Store?
- whizzter 4y ago
  1: Hopefully the delay was so the device updates with time-based activation triggers would shut out the bad actor in as many places as possible at once. 2: I don't see any reason to share the master key with an OEM, the master key could be used to sign certificates down-chain but they should never share it. This leaves 2 options: - Google had waaay too sloppy key management (sitting on servers or even possibly developer laptops) - Google had proper management by putting the keys on HSMs or some virtual HSM with multi-party activation, unless there was weaknesses in the HSMs(or the virtual HSM OS) then yes, some person(s) would've gained physical access to extract it. 3: Universal 2nd stage rootkit?
  - mjg59 4y ago
    Why would Google have these keys?
    - whizzter 4y ago
      (posterity) Sure the primary OS/Bootloader key probably falls under vendors, but wasn't much of the core systems (phone, play, browser,etc) moved to be under Googles control due to the vendors being sloppy with providing updates for devices in the olden days? (And as such this key would be the thing that the os/loader grants privilegies to). Edit: Noticed the comment about them being lowend(mediatek?) certificates.
    - nullc 4y ago
      My understanding is that with v3 google started requiring that app developers send their private keys to google, as a requirement for inclusion in the play store (using the 'Play Encrypt Private Key (PEPK) tool'). In light of that I guess it wouldn't be shocking if there were similar requirements for vendor's platform keys.
gjsman-1000 4y ago
I had speculated for a while that Secure Boot, Widevine, Trusted Computing, all of it seems like they have some pretty serious central points of failure. So much so, that it would be a modern heist of the century if they were stolen. If someone (for example) got Apple's iOS signing key and Apple's HTTPS certificate, Apple could suffer catastrophic damage. If someone got the PlayStation 5 signing key or the Xbox One signing key, catastrophic damage there. In a way, it's a beautiful, super-secure house... built on a single ludicrously powerful point of failure. Good thing we don't have any corrupt government agencies who might want to bribe someone for keys... yet... hopefully... This is actually something I would fear for the future. There have been countless physical heists - most recently in Antwerp, Belgium, where over $100 million in diamonds were stolen in 2003. We haven't had a major signing key stolen yet, but there's always that first day... if you can't keep $100M in diamonds safe, can you really be sure that you can keep a hardware signing key safe forever? Heck, the logistics of stealing the diamonds is insane - but stealing a key only takes a pencil and a piece of paper.
- bombcar 4y ago
  And you know nobody actually has their high-value signing key protected by a series of complex offline vaults and checks and balances like you'd see in Ocean's 11 - at best it's on the other side of a room on an air gapped computer.
  - gjsman-1000 4y ago
    Right... because the more you lock the key down and try to secure it, the greater the risk something in your security will go wrong, and then you will lose it yourself. Losing the key is not as bad, though still catastrophic, from a corporate perspective. Imagine if Apple couldn't distribute a software update ever again. Much better to not invest in super-strong security that has that risk... but then you have an increased risk of theft... It's almost like cryptographic signing keys are the modern day Ring of Power...
    - whizzter 4y ago
      https://www.iana.org/dnssec/ceremonies https://www.iana.org/dnssec/ceremonies
RjQoLCOSwiIKfpm 4y ago
Is this like Google's central "root key"? Or does each Android OS distributor, e.g. Samsung, LineageOS, etc., have their own certificate?
- themoonisachees 4y ago
  I expect keys to be per software vendor, because otherwise lineageOS, and pretty much all small device manufacturers would not be able to sign their android kernel (required for pretty much anything secure, like google pay or safetynet), and giving them a central key would be a significant security risk compared to say Samsung. That said the private key for the CA could be compromised and in that case everything not up to date is toast
  - ShredKazoo 4y ago
    >That said the private key for the CA could be compromised and in that case everything not up to date is toast I don't follow. Do different Android distributors make use of the same CA? If so why? I don't even see why they would need to make use of a CA if their public key is shipped with the device.
- Zeik0s 4y ago
  There are different certificates for each vendor, therefore there are multiple hashes listed in the Bugtracker: https://bugs.chromium.org/p/apvi/issues/detail?id=100 https://bugs.chromium.org/p/apvi/issues/detail?id=100
- mjg59 4y ago
  The public evidence doesn't seem to suggest that any Google-owned keys are affected. Platform certificates are owned by the vendor.
- MishaalRahman 4y ago
  These platform certificates are all from different vendors, but the problem is that one of the leaked certs appears to be from the biggest Android vendor...Samsung. And that cert is seemingly still being used by them to sign apps.
dtx1 4y ago
If I understand this correctly this is an orbital nuke on android security.
- gryf 4y ago
  I think it’s more an orbital dung beetle.
- MishaalRahman 4y ago
  The existence of leaked platform signing certificates breaks a core Android security feature: the application sandbox. Theoretically, a malicious actor with the leaked cert can sign an app and declare the shared user ID Manifest element to run in the same process as 'android', ie. the operating system process.
miohtama 4y ago
Why this is Chromium issue tracker? Or is the same tracker used across all Google projects?
- MishaalRahman 4y ago
  It just happens to be where vulnerabilities are disclosed under the Android Partner Vulnerability Initiative: https://security.googleblog.com/2020/10/announcing-launch-of-android-partner.html https://security.googleblog.com/2020/10/announcing-launch-of...
- saagarjha 4y ago
  For various historical reasons a lot of the device-related security work is housed on Chrome infrastructure.
- bsimpson 4y ago
  Monorail is a fork of Google Code, which was Google's public source control offering for a while. Repos from Google Code were mostly transitioned onto more popular platforms (like GitHub). Chromium wanted to keep using the issue tracker, so they took it over to create Monorail: https://chromium.googlesource.com/infra/infra/+/refs/heads/main/appengine/monorail/doc/README.md https://chromium.googlesource.com/infra/infra/+/refs/heads/m... Chrome is the biggest one, but many of Google's public-facing issue trackers are on Monorail (which is hosted at bugs.chromium.org).
- jeffbee 4y ago
  Here's the real reason: nobody in a position to make it more consistent ever notices the inconsistency, because internally the use of short URL redirectors is ubiquitous. I can't be sure because I don't work there any more but I would be surprised if the canonical location of this issue for Googlers is something other than go/avpibug/100 or something similar to that.
- thrdbndndn 4y ago
  >Why this is Chromium issue tracker? Others have already answered the historical reason, but a more direct and technical answer: this is not, since that would be: https://bugs.chromium.org/p/chromium/issues/list https://bugs.chromium.org/p/chromium/issues/list This is issue tracker for "apvi" (whatever it means), just happened to be hosted on "bugs.chromium.org" domain like batch of others.
david_allison 4y ago
Is the "First Time Seen in the Wild" accurate? (2016-02-13 11:50:54 UTC) https://www.virustotal.com/gui/file/b1f191b1ee463679c7c2fa7db5a224b6759c5474b73a59be3e133a6825b2a284/details https://www.virustotal.com/gui/file/b1f191b1ee463679c7c2fa7d... If so, this has been around for 6 years. EDIT: A number of listed APKs target API 22 (Android 5.1). This isn't definite, (and apps can be run on later phones), but this also implies some compromises occurred in ~2015.
- deleted 4y ago
  [deleted]
- jeroenhd 4y ago
  Targeting an old API can be used to trick the compatibility system to kick in and expose APIs and behaviour that's restricted on newer platforms. This is how Termux is able to execute executables in ways that shouldn't normally be permitted by the OS, for example. The Play Store doesn't allow apps targeting old APIs but the system itself will try not to break the old apps you've installed before installing your OS updates.
pyinstallwoes 4y ago
Interesting for whoever is curious: > Fri, Nov 11, 2022 at 8:01 AM PST (20 days ago) So it took 20 days to disclose.
- deleted 4y ago
  [deleted]
- fotta 4y ago
  The tags in the left sidebar have "Reported-2022-May-13"
  - pyinstallwoes 4y ago
    Dang
ro_bit 4y ago
What risks does this cause me as an android user? Does this mean my phone might accept auto updates that install malware onto my device? What can I do to mitigate those risks?
- MishaalRahman 4y ago
  No, you should be safe so long as you only accept updates to system apps through official app stores, like Google Play or the Galaxy Store. Do not sideload updates to system apps through third-party websites.
  - tgsovlerkhgsel 4y ago
    From the description in the bug "Any other application signed with the same certificate can declare that it wants to run with the same user id, giving it the same level of access to the Android operating system.", so this applies to all app installations and updates.
    - deleted 4y ago
      [deleted]
    - fowl2 4y ago
      Presumably the Play Store will reject any app signed with these keys. I'd appreciate them making a statement to this affect. And someone double checking.
      - MishaalRahman 4y ago
        Yeah, I'd be surprised if Google Play wasn't already on the lookout to flag newly uploaded apps signed with these keys.
        ShredKazoo 4y ago
        Honestly, if it's true that the Android security model allows an OEM-signed app to escalate privileges, Google should always be monitoring OEM-signed apps on the Play store very carefully. There shouldn't be more than a few hundred of them. Can't be that hard. And when installing a OEM-signed app, instead of the normal permissions dialogue, there should be a giant red warning that says the app can basically root your device. If the OEMs don't like it, they can set up a second key pair with no privilege escalation capability to sign updates for most of their apps (the ones that don't need elevated privileges).
lzooz 4y ago
The comments on some issues are downright unsettling. https://bugs.chromium.org/p/apvi/issues/detail?id=34#c9 https://bugs.chromium.org/p/apvi/issues/detail?id=34#c9
- manchmalscott 4y ago
  All the comments seem to be deleted. Do you remember what was unsettling about them?
  - 2OEH8eoCRo0 4y ago
    One was a video of a dancing child with a cellphone.
MishaalRahman 4y ago
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! >Here's a short summary of [shared UID](https://blog.esper.io/android-13-deep-dive/#shared_uid_migration 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/b1f191b1ee463679c7c2fa7db5a224b6759c5474b73a59be3e133a6825b2a284/details 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&s=34df0e7a9f1cf1892e45c056b4973cd81ccf148a4050d11aea4ac5a65f900a42 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 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 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.
mjg59 4y ago
My understanding is that these certs are vendor-specific (and potentially more finely grained than that - I think it'd be fine to have a separate cert per model, for instance) and are rooted in the firmware, not the hardware - that is, it's not the secure boot signing key, and a new firmware update can simply use a different platform certificate. Having said that, the fact that there appear to be multiple vendors affected by this (looking at those hashes in Virustotal, there are signatures that claim to be owned by Samsung, LG, and Mediatek, at least), and that's certainly concerning. My entirely unsupported guess is that they may all share manufacturing for some models, and certificates may have been on site there? But the more significant question is how many phones trust these certificates. As I mentioned before, these could be model specific, and any leaked certificates could be tied to a very small number of phones. Or maybe Samsung used the same platform cert for all phones manufactured in the past decade, and that would be a much larger problem. With the information presently available we simply don't know how big a deal this is. Edit to add: given Mediatek certs appear here, and given all the vendors linked to this have shipped low-end phones based on Mediatek SoCs, it wouldn't surprise me if it turns out Mediatek were the source.
- MishaalRahman 4y ago
  >My understanding is that these certs are vendor-specific (and potentially more finely grained than that - I think it'd be fine to have a separate cert per model, for instance) and are rooted in the firmware, not the hardware - that is, it's not the secure boot signing key, and a new firmware update can simply use a different platform certificate. Correct, affected OEMs can still rotate the cert used to sign their system apps and then push an OTA update to deliver the updated apps. Then they can push app updates with that new cert. However, V2 versus V3 signatures complicate things a bit, I think.
  - flatiron 4y ago
    I assume that the level that the malware is running at couldn’t simply modify the OTA file and inject itself back in?
    - 4y ago
guelo 4y ago
I'd love to have this key for my device so I can actually have full ownership of it.
- mjg59 4y ago
  These aren't the secure boot signing certificates. If your bootloader is locked this isn't going to let you replace the vendor firmware.
  - guelo 4y ago
    I would be able to use this key to sign terminal or file manager apps and get full access to my file system.
    - 95014_refugee 4y ago
      So would anyone else. Your filesystem, that is.
      - guelo 4y ago
        Only if I sideload their apps.
      - lostmsu 4y ago
        Only if he installs the "anyone else"'s app explicitly though, no?
- deleted 4y ago
  [deleted]
LooseMarmoset 4y ago
I wonder if any of these leaked keys were used to sign the base android installers for the phones themselves? If so, this might be a way to get new versions of AOSP onto Samsung phones that are bootloader-locked and have no current support by Samsung. Can anyone anyone experienced with Android+Samsung comment here?
- gary_0 4y ago
  That was my first thought after "oh fuck". Does this mean any current Samsung phone can now be rooted by the user?
  - LooseMarmoset 4y ago
    Well, I think you could potentially sign any rooting app at least. I'd like to see os-level signing so we can take older devices like Samsung tablets and put Samsung-less Android on it.
- chenxiaolong 4y ago
  I'm guessing it's different depending on model, but on my SM-X900 (US model Tab S8 Ultra), the key used to sign the vbmeta image (Android verified boot's root of trust) is different from every key used to sign the system apps.
  - MishaalRahman 4y ago
    Yeah that's my understanding as well
ok_dad 4y ago
Based on what I’ve read over the past year about security issues, it’s coming into focus how some personal data of mine may have gotten leaked: it was never safe to begin with.
userbinator 4y ago
Root for everyone? Maybe that's a good thing, finally restoring the balance of power from the megacorps to the actual owners.
- teaearlgraycold 4y ago
  Do you realized that it's mandated by Google that a phone sold under the name "Android" has to be rootable?
  - kaladin-jasnah 4y ago
    Why can't I root a Qualcomm Samsung phone for the US market? What about carrier locked phones? Et cetera.
- ShredKazoo 4y ago
  Have any private keys actually been made public? I don't see any evidence of that. The only claim I see here is that they're being used to sign malware.
yalogin 4y ago
The title of the post is super scary but I have no idea what it means. There is no description about it in the linked page. Reading through the comments doesn’t help either. I would just wait for a proper write up.
- saagarjha 4y ago
  OEMs have a key they can use to sign apps. Some of those keys leaked. This was discover when malware signed with those keys showed up in the wild. This is bad because apps signed with those keys have the "system" authority, which means they bypass many permissions checks.
heavyset_go 4y ago
Here's a great example of the pitfalls of forgoing real security in favor of centralized "security" that exists to secure platform owners' bottom lines and to allow them to decide what can and can't run on devices.
- 95014_refugee 4y ago
hsuduebc2 4y ago
Well that's a bummer
arsome 4y ago
One interesting thing is 2abeb8565c30a3d2af0fc8ea48af78a702a1c3b432845e3f04873610fac09e1b was mentioned in the original description 1 but removed in 2/3. That package is signed with an Android key instead of a vendor one... https://www.virustotal.com/gui/file/2abeb8565c30a3d2af0fc8ea48af78a702a1c3b432845e3f04873610fac09e1b/detection https://www.virustotal.com/gui/file/2abeb8565c30a3d2af0fc8ea...
- ShredKazoo 4y ago
  So Google's private key was stolen?
  - arsome 4y ago
    I'm not sure of the validity of the key, it's possible it was simply an untrusted key that had "Android" in the common name and got removed from the post as it was unrelated, but I'm curious if any more details surface on that one.
- dhx 4y ago
  I doubt that is a real Google-issued certificate authority based on the issuing CA certificate having an e-mail address identified as "nbbsw@nbbsw.com". It's likely the reason this sample was removed from the post?
  - axsharma 4y ago
    Same thought here. The domain appears to be associated with Ningbo Sunning Software, a Chinese vendor and likely a Mediatek partner than anything Android.
    - arsome 4y ago
      Good catch after looking into it more this may be related to subcontractors providing vendors with malicious update tools that they then sign. https://maldroid.github.io/docs/vb_2022.pdf https://maldroid.github.io/docs/vb_2022.pdf
deleted 4y ago
[deleted]
javajosh 4y ago
What is the risk here? Presumably Google Play would not accept an apk that was signed by "android", right? Assuming that is not the case, the only risk would be installing apks from alternative sources, like F-Droid, who should probably check for strange signings, too, IMHO. Or there is "something else", some sort of bullshit that goes over the baseband, where updates cannot be refused (other than to put your device in airplane mode, or off) and now because the "platforms" couldn't protect their private keys from malefactors, kids with SDRs are going to effortlessly pown people's phones by pushing their own software over a possible, nay probable, proprietary baseband channel. (Tangential scifi rant: And then you add the risk of manufacturer shenanigans at the PCB or chip-image level, and you can't really do due diligence on chips without your own electron microscope (and possibly not even then). I've had this worried thought with software, too, that there is too much complexity to really understand it. In the same way our computer hardware is actually too hard for any one person to understand "completely" - that is, possess the skill-set of every individual contributor on the engineering team of a company that makes smartphones.)
- archon810 4y ago
  What is "signed by Android"? The leaked Samsung and LG keys are used in dozens of apps. Someone could in theory upload apps but claimed by Samsung on the Play Store, sign them with those keys, and compromise millions of users whose Play Store would suddenly update to the unofficial APKs (assuming that they get around Google's own Play Protect).
  - jeroenhd 4y ago
    I assume (hope) that Google is smart enough to check for these vendor signatures, and possibly tie them to a specific vendor account. With the switch to aab app bundles (https://android-developers.googleblog.com/2020/11/new-android-app-bundle-and-target-api.html?m=1 https://android-developers.googleblog.com/2020/11/new-androi...), it's effectively impossible for most people to upload custom APKs to the Play Store anyway. I'm sure there are backdoor and special treatment for vendor applications to keep their signatures. In fact, with the exception of private applications, Google requires you to hand over your signing keys when you upload to the play store. I doubt you'd get away with just uploading vendor keys to the Play Store console.
zaptheimpaler 4y ago
So phones are heavily locked down by manufacturers for our own security, but apparently they cannot secure their own keys. If anyone outside a few million nerds really understood this and saw all the vulnerabilities we have seen over the past few years, locking users out of their devices would be completely indefensible.
archon810 4y ago
Are there any VirusTotal employees here who can help figure out the answer to this so that we can find all the affected APKs? https://twitter.com/ArtemR/status/1598444589269909504 https://twitter.com/ArtemR/status/1598444589269909504

684 points by arkadiyt 4y ago

In my opinion, mobile Authentication should be perform along with registered mobile’s IMEI number + sim unique number or telecom providers unique token number. This can be easily done by Microsoft , intuine . This will be one additional layer of protection to your mobile auth

solarkraft 4y ago

This is confidence-inspiring considering that Google now requires letting them sign your apps for some features now. > OEMs have mitigated the issues above in previous updates. Yeah, sure they have. Because OEMs are so good at updates. Would be interesting to see how many users such updates are available to. My guess is between 20 to 40%.

deleted 4y ago

[deleted]

remram 4y ago

So this was disclosed November 11 (edit: or maybe May 13 as per green text?) and became public yesterday November 30. Leaves little time for Android devices to get the new key no?

themoonisachees 4y ago
If may 13 which would make more sense then there have been several android security patches since. Devices no longer supported are toast though
- remram 4y ago
  I think for the industry as a whole there should be some penalty or disincentive for going "we're no longer providing updates" and then "we lost the key that gives full access to the system".
MishaalRahman 4y ago
>Leaves little time for Android devices to get the new key no? It's not so simple, also rotating the keys could affect how devices get app updates, depending on whether or not an 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. 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.
michaelt 4y ago
This isn't the kind of security issue where disclosing it allows new attackers to start exploiting it - because new attackers haven't compromised the keys. So there's little reason to keep the compromise secret, except to let your partners save face.

Denvercoder9 4y ago

What's the blast radius of this? Are only specific models of phones affected (if so, which?), or does this impact entire brands or the whole ecosystem?

MishaalRahman 4y ago
It's isolated to devices from the specific brands whose platform certs were leaked and are still being used to sign apps.
ezekiel68 4y ago
I'm no expert but judging from what seem to be informed comments in this topic, the main attack vector might be restricted to the side-loading not of regular apps, but of system-level components. If that's true, the blast radius would be fairly small indeed (though still not good in those cases).

arciini 4y ago

This thread leaves a lot of unanswered questions: 1. This was likely mitigated through a device update. What version did it roll out with? Which devices are still unpatched? 2. How was it compromised? Was it an OEM? An internal leak at Google? 3. What is the attack vector? It sounds like it was likely side-loading apps used by some attacker, but did any of these make it onto the Play Store?

whizzter 4y ago
1: Hopefully the delay was so the device updates with time-based activation triggers would shut out the bad actor in as many places as possible at once. 2: I don't see any reason to share the master key with an OEM, the master key could be used to sign certificates down-chain but they should never share it. This leaves 2 options: - Google had waaay too sloppy key management (sitting on servers or even possibly developer laptops) - Google had proper management by putting the keys on HSMs or some virtual HSM with multi-party activation, unless there was weaknesses in the HSMs(or the virtual HSM OS) then yes, some person(s) would've gained physical access to extract it. 3: Universal 2nd stage rootkit?
- mjg59 4y ago
  Why would Google have these keys?
  - whizzter 4y ago
    (posterity) Sure the primary OS/Bootloader key probably falls under vendors, but wasn't much of the core systems (phone, play, browser,etc) moved to be under Googles control due to the vendors being sloppy with providing updates for devices in the olden days? (And as such this key would be the thing that the os/loader grants privilegies to). Edit: Noticed the comment about them being lowend(mediatek?) certificates.
  - nullc 4y ago
    My understanding is that with v3 google started requiring that app developers send their private keys to google, as a requirement for inclusion in the play store (using the 'Play Encrypt Private Key (PEPK) tool'). In light of that I guess it wouldn't be shocking if there were similar requirements for vendor's platform keys.

gjsman-1000 4y ago

I had speculated for a while that Secure Boot, Widevine, Trusted Computing, all of it seems like they have some pretty serious central points of failure. So much so, that it would be a modern heist of the century if they were stolen. If someone (for example) got Apple's iOS signing key and Apple's HTTPS certificate, Apple could suffer catastrophic damage. If someone got the PlayStation 5 signing key or the Xbox One signing key, catastrophic damage there. In a way, it's a beautiful, super-secure house... built on a single ludicrously powerful point of failure. Good thing we don't have any corrupt government agencies who might want to bribe someone for keys... yet... hopefully... This is actually something I would fear for the future. There have been countless physical heists - most recently in Antwerp, Belgium, where over $100 million in diamonds were stolen in 2003. We haven't had a major signing key stolen yet, but there's always that first day... if you can't keep $100M in diamonds safe, can you really be sure that you can keep a hardware signing key safe forever? Heck, the logistics of stealing the diamonds is insane - but stealing a key only takes a pencil and a piece of paper.

bombcar 4y ago
And you know nobody actually has their high-value signing key protected by a series of complex offline vaults and checks and balances like you'd see in Ocean's 11 - at best it's on the other side of a room on an air gapped computer.
- gjsman-1000 4y ago
  Right... because the more you lock the key down and try to secure it, the greater the risk something in your security will go wrong, and then you will lose it yourself. Losing the key is not as bad, though still catastrophic, from a corporate perspective. Imagine if Apple couldn't distribute a software update ever again. Much better to not invest in super-strong security that has that risk... but then you have an increased risk of theft... It's almost like cryptographic signing keys are the modern day Ring of Power...
  - whizzter 4y ago
    https://www.iana.org/dnssec/ceremonies https://www.iana.org/dnssec/ceremonies

RjQoLCOSwiIKfpm 4y ago

Is this like Google's central "root key"? Or does each Android OS distributor, e.g. Samsung, LineageOS, etc., have their own certificate?

themoonisachees 4y ago
I expect keys to be per software vendor, because otherwise lineageOS, and pretty much all small device manufacturers would not be able to sign their android kernel (required for pretty much anything secure, like google pay or safetynet), and giving them a central key would be a significant security risk compared to say Samsung. That said the private key for the CA could be compromised and in that case everything not up to date is toast
- ShredKazoo 4y ago
  >That said the private key for the CA could be compromised and in that case everything not up to date is toast I don't follow. Do different Android distributors make use of the same CA? If so why? I don't even see why they would need to make use of a CA if their public key is shipped with the device.
Zeik0s 4y ago
There are different certificates for each vendor, therefore there are multiple hashes listed in the Bugtracker: https://bugs.chromium.org/p/apvi/issues/detail?id=100 https://bugs.chromium.org/p/apvi/issues/detail?id=100
mjg59 4y ago
The public evidence doesn't seem to suggest that any Google-owned keys are affected. Platform certificates are owned by the vendor.
MishaalRahman 4y ago
These platform certificates are all from different vendors, but the problem is that one of the leaked certs appears to be from the biggest Android vendor...Samsung. And that cert is seemingly still being used by them to sign apps.

dtx1 4y ago

If I understand this correctly this is an orbital nuke on android security.

gryf 4y ago
I think it’s more an orbital dung beetle.
MishaalRahman 4y ago
The existence of leaked platform signing certificates breaks a core Android security feature: the application sandbox. Theoretically, a malicious actor with the leaked cert can sign an app and declare the shared user ID Manifest element to run in the same process as 'android', ie. the operating system process.

miohtama 4y ago

Why this is Chromium issue tracker? Or is the same tracker used across all Google projects?

MishaalRahman 4y ago
It just happens to be where vulnerabilities are disclosed under the Android Partner Vulnerability Initiative: https://security.googleblog.com/2020/10/announcing-launch-of-android-partner.html https://security.googleblog.com/2020/10/announcing-launch-of...
saagarjha 4y ago
For various historical reasons a lot of the device-related security work is housed on Chrome infrastructure.
bsimpson 4y ago
Monorail is a fork of Google Code, which was Google's public source control offering for a while. Repos from Google Code were mostly transitioned onto more popular platforms (like GitHub). Chromium wanted to keep using the issue tracker, so they took it over to create Monorail: https://chromium.googlesource.com/infra/infra/+/refs/heads/main/appengine/monorail/doc/README.md https://chromium.googlesource.com/infra/infra/+/refs/heads/m... Chrome is the biggest one, but many of Google's public-facing issue trackers are on Monorail (which is hosted at bugs.chromium.org).
jeffbee 4y ago
Here's the real reason: nobody in a position to make it more consistent ever notices the inconsistency, because internally the use of short URL redirectors is ubiquitous. I can't be sure because I don't work there any more but I would be surprised if the canonical location of this issue for Googlers is something other than go/avpibug/100 or something similar to that.
thrdbndndn 4y ago
>Why this is Chromium issue tracker? Others have already answered the historical reason, but a more direct and technical answer: this is not, since that would be: https://bugs.chromium.org/p/chromium/issues/list https://bugs.chromium.org/p/chromium/issues/list This is issue tracker for "apvi" (whatever it means), just happened to be hosted on "bugs.chromium.org" domain like batch of others.

david_allison 4y ago

Is the "First Time Seen in the Wild" accurate? (2016-02-13 11:50:54 UTC) https://www.virustotal.com/gui/file/b1f191b1ee463679c7c2fa7db5a224b6759c5474b73a59be3e133a6825b2a284/details https://www.virustotal.com/gui/file/b1f191b1ee463679c7c2fa7d... If so, this has been around for 6 years. EDIT: A number of listed APKs target API 22 (Android 5.1). This isn't definite, (and apps can be run on later phones), but this also implies some compromises occurred in ~2015.

deleted 4y ago
[deleted]
jeroenhd 4y ago
Targeting an old API can be used to trick the compatibility system to kick in and expose APIs and behaviour that's restricted on newer platforms. This is how Termux is able to execute executables in ways that shouldn't normally be permitted by the OS, for example. The Play Store doesn't allow apps targeting old APIs but the system itself will try not to break the old apps you've installed before installing your OS updates.

pyinstallwoes 4y ago

Interesting for whoever is curious: > Fri, Nov 11, 2022 at 8:01 AM PST (20 days ago) So it took 20 days to disclose.

deleted 4y ago
[deleted]
fotta 4y ago
The tags in the left sidebar have "Reported-2022-May-13"
- pyinstallwoes 4y ago
  Dang

ro_bit 4y ago

What risks does this cause me as an android user? Does this mean my phone might accept auto updates that install malware onto my device? What can I do to mitigate those risks?

MishaalRahman 4y ago
No, you should be safe so long as you only accept updates to system apps through official app stores, like Google Play or the Galaxy Store. Do not sideload updates to system apps through third-party websites.
- tgsovlerkhgsel 4y ago
  From the description in the bug "Any other application signed with the same certificate can declare that it wants to run with the same user id, giving it the same level of access to the Android operating system.", so this applies to all app installations and updates.
  - deleted 4y ago
    [deleted]
  - fowl2 4y ago
    Presumably the Play Store will reject any app signed with these keys. I'd appreciate them making a statement to this affect. And someone double checking.
    - MishaalRahman 4y ago
      Yeah, I'd be surprised if Google Play wasn't already on the lookout to flag newly uploaded apps signed with these keys.
      - ShredKazoo 4y ago
        Honestly, if it's true that the Android security model allows an OEM-signed app to escalate privileges, Google should always be monitoring OEM-signed apps on the Play store very carefully. There shouldn't be more than a few hundred of them. Can't be that hard. And when installing a OEM-signed app, instead of the normal permissions dialogue, there should be a giant red warning that says the app can basically root your device. If the OEMs don't like it, they can set up a second key pair with no privilege escalation capability to sign updates for most of their apps (the ones that don't need elevated privileges).

lzooz 4y ago

The comments on some issues are downright unsettling. https://bugs.chromium.org/p/apvi/issues/detail?id=34#c9 https://bugs.chromium.org/p/apvi/issues/detail?id=34#c9

manchmalscott 4y ago
All the comments seem to be deleted. Do you remember what was unsettling about them?
- 2OEH8eoCRo0 4y ago
  One was a video of a dancing child with a cellphone.

MishaalRahman 4y ago

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! >Here's a short summary of [shared UID](https://blog.esper.io/android-13-deep-dive/#shared_uid_migration 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/b1f191b1ee463679c7c2fa7db5a224b6759c5474b73a59be3e133a6825b2a284/details 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&s=34df0e7a9f1cf1892e45c056b4973cd81ccf148a4050d11aea4ac5a65f900a42 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 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 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.

mjg59 4y ago

My understanding is that these certs are vendor-specific (and potentially more finely grained than that - I think it'd be fine to have a separate cert per model, for instance) and are rooted in the firmware, not the hardware - that is, it's not the secure boot signing key, and a new firmware update can simply use a different platform certificate. Having said that, the fact that there appear to be multiple vendors affected by this (looking at those hashes in Virustotal, there are signatures that claim to be owned by Samsung, LG, and Mediatek, at least), and that's certainly concerning. My entirely unsupported guess is that they may all share manufacturing for some models, and certificates may have been on site there? But the more significant question is how many phones trust these certificates. As I mentioned before, these could be model specific, and any leaked certificates could be tied to a very small number of phones. Or maybe Samsung used the same platform cert for all phones manufactured in the past decade, and that would be a much larger problem. With the information presently available we simply don't know how big a deal this is. Edit to add: given Mediatek certs appear here, and given all the vendors linked to this have shipped low-end phones based on Mediatek SoCs, it wouldn't surprise me if it turns out Mediatek were the source.

MishaalRahman 4y ago
>My understanding is that these certs are vendor-specific (and potentially more finely grained than that - I think it'd be fine to have a separate cert per model, for instance) and are rooted in the firmware, not the hardware - that is, it's not the secure boot signing key, and a new firmware update can simply use a different platform certificate. Correct, affected OEMs can still rotate the cert used to sign their system apps and then push an OTA update to deliver the updated apps. Then they can push app updates with that new cert. However, V2 versus V3 signatures complicate things a bit, I think.
- flatiron 4y ago
  I assume that the level that the malware is running at couldn’t simply modify the OTA file and inject itself back in?
  - 4y ago

guelo 4y ago

I'd love to have this key for my device so I can actually have full ownership of it.

mjg59 4y ago
These aren't the secure boot signing certificates. If your bootloader is locked this isn't going to let you replace the vendor firmware.
- guelo 4y ago
  I would be able to use this key to sign terminal or file manager apps and get full access to my file system.
  - 95014_refugee 4y ago
    So would anyone else. Your filesystem, that is.
    - guelo 4y ago
      Only if I sideload their apps.
    - lostmsu 4y ago
      Only if he installs the "anyone else"'s app explicitly though, no?
deleted 4y ago
[deleted]

LooseMarmoset 4y ago

I wonder if any of these leaked keys were used to sign the base android installers for the phones themselves? If so, this might be a way to get new versions of AOSP onto Samsung phones that are bootloader-locked and have no current support by Samsung. Can anyone anyone experienced with Android+Samsung comment here?

gary_0 4y ago
That was my first thought after "oh fuck". Does this mean any current Samsung phone can now be rooted by the user?
- LooseMarmoset 4y ago
  Well, I think you could potentially sign any rooting app at least. I'd like to see os-level signing so we can take older devices like Samsung tablets and put Samsung-less Android on it.
chenxiaolong 4y ago
I'm guessing it's different depending on model, but on my SM-X900 (US model Tab S8 Ultra), the key used to sign the vbmeta image (Android verified boot's root of trust) is different from every key used to sign the system apps.
- MishaalRahman 4y ago
  Yeah that's my understanding as well

ok_dad 4y ago

Based on what I’ve read over the past year about security issues, it’s coming into focus how some personal data of mine may have gotten leaked: it was never safe to begin with.

userbinator 4y ago

Root for everyone? Maybe that's a good thing, finally restoring the balance of power from the megacorps to the actual owners.

teaearlgraycold 4y ago
Do you realized that it's mandated by Google that a phone sold under the name "Android" has to be rootable?
- kaladin-jasnah 4y ago
  Why can't I root a Qualcomm Samsung phone for the US market? What about carrier locked phones? Et cetera.
ShredKazoo 4y ago
Have any private keys actually been made public? I don't see any evidence of that. The only claim I see here is that they're being used to sign malware.

yalogin 4y ago

The title of the post is super scary but I have no idea what it means. There is no description about it in the linked page. Reading through the comments doesn’t help either. I would just wait for a proper write up.

saagarjha 4y ago
OEMs have a key they can use to sign apps. Some of those keys leaked. This was discover when malware signed with those keys showed up in the wild. This is bad because apps signed with those keys have the "system" authority, which means they bypass many permissions checks.

heavyset_go 4y ago

Here's a great example of the pitfalls of forgoing real security in favor of centralized "security" that exists to secure platform owners' bottom lines and to allow them to decide what can and can't run on devices.

95014_refugee 4y ago

hsuduebc2 4y ago

Well that's a bummer

arsome 4y ago

One interesting thing is 2abeb8565c30a3d2af0fc8ea48af78a702a1c3b432845e3f04873610fac09e1b was mentioned in the original description 1 but removed in 2/3. That package is signed with an Android key instead of a vendor one... https://www.virustotal.com/gui/file/2abeb8565c30a3d2af0fc8ea48af78a702a1c3b432845e3f04873610fac09e1b/detection https://www.virustotal.com/gui/file/2abeb8565c30a3d2af0fc8ea...

ShredKazoo 4y ago
So Google's private key was stolen?
- arsome 4y ago
  I'm not sure of the validity of the key, it's possible it was simply an untrusted key that had "Android" in the common name and got removed from the post as it was unrelated, but I'm curious if any more details surface on that one.
dhx 4y ago
I doubt that is a real Google-issued certificate authority based on the issuing CA certificate having an e-mail address identified as "nbbsw@nbbsw.com". It's likely the reason this sample was removed from the post?
- axsharma 4y ago
  Same thought here. The domain appears to be associated with Ningbo Sunning Software, a Chinese vendor and likely a Mediatek partner than anything Android.
  - arsome 4y ago
    Good catch after looking into it more this may be related to subcontractors providing vendors with malicious update tools that they then sign. https://maldroid.github.io/docs/vb_2022.pdf https://maldroid.github.io/docs/vb_2022.pdf

deleted 4y ago

[deleted]

javajosh 4y ago

What is the risk here? Presumably Google Play would not accept an apk that was signed by "android", right? Assuming that is not the case, the only risk would be installing apks from alternative sources, like F-Droid, who should probably check for strange signings, too, IMHO. Or there is "something else", some sort of bullshit that goes over the baseband, where updates cannot be refused (other than to put your device in airplane mode, or off) and now because the "platforms" couldn't protect their private keys from malefactors, kids with SDRs are going to effortlessly pown people's phones by pushing their own software over a possible, nay probable, proprietary baseband channel. (Tangential scifi rant: And then you add the risk of manufacturer shenanigans at the PCB or chip-image level, and you can't really do due diligence on chips without your own electron microscope (and possibly not even then). I've had this worried thought with software, too, that there is too much complexity to really understand it. In the same way our computer hardware is actually too hard for any one person to understand "completely" - that is, possess the skill-set of every individual contributor on the engineering team of a company that makes smartphones.)

archon810 4y ago
What is "signed by Android"? The leaked Samsung and LG keys are used in dozens of apps. Someone could in theory upload apps but claimed by Samsung on the Play Store, sign them with those keys, and compromise millions of users whose Play Store would suddenly update to the unofficial APKs (assuming that they get around Google's own Play Protect).
- jeroenhd 4y ago
  I assume (hope) that Google is smart enough to check for these vendor signatures, and possibly tie them to a specific vendor account. With the switch to aab app bundles (https://android-developers.googleblog.com/2020/11/new-android-app-bundle-and-target-api.html?m=1 https://android-developers.googleblog.com/2020/11/new-androi...), it's effectively impossible for most people to upload custom APKs to the Play Store anyway. I'm sure there are backdoor and special treatment for vendor applications to keep their signatures. In fact, with the exception of private applications, Google requires you to hand over your signing keys when you upload to the play store. I doubt you'd get away with just uploading vendor keys to the Play Store console.

zaptheimpaler 4y ago

So phones are heavily locked down by manufacturers for our own security, but apparently they cannot secure their own keys. If anyone outside a few million nerds really understood this and saw all the vulnerabilities we have seen over the past few years, locking users out of their devices would be completely indefensible.

archon810 4y ago

Are there any VirusTotal employees here who can help figure out the answer to this so that we can find all the affected APKs? https://twitter.com/ArtemR/status/1598444589269909504 https://twitter.com/ArtemR/status/1598444589269909504