Platform certificates used to sign malware

https://bugs.chromium.org/p/apvi/issues/detail?id=100

by arkadiyt • 4 years ago

684 234 4 years ago

bugs.chromium.org

remram2• 4 years 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?

themoonisachees2• 4 years 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

remram2• 4 years 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".

MishaalRahman19• 4 years 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• 4 years 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• 4 years 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?

MishaalRahman19• 4 years ago

It's isolated to devices from the specific brands whose platform certs were leaked and are still being used to sign apps.

ezekiel684• 4 years 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• 4 years 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?

whizzter4• 4 years 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?

mjg597• 4 years ago

Why would Google have these keys?

hn_throwaway_99• 4 years ago

These aren't Google's keys. They are vendor-specific keys (e.g. Samsung's) used to sign their releases.

MishaalRahman19• 4 years ago

Google isn't at fault, their certs weren't leaked (as far as we know).

MishaalRahman19• 4 years ago

1. We don't know what mitigation steps have been applied. However, it seems that at least some affected vendors are still signing their apps with compromised platform certs: https://www.apkmirror.com/?post_type=app_release&searchtype=...

2. Unknown. Could be multiple independent hacks of the OEM or an ODM, could be an insider, etc.

3. The attack vector is usually sideloading.

dhx2• 4 years ago

The latest November Samsung firmware for a phone in front of me has android.uid.system signed by the compromised certificate with SHA256 fingerprint 34df0e7a9f1cf1892e45c056b4973cd81ccf148a4050d11aea4ac5a65f900a42. This certificate is provided by com.samsung.android.svcagent version 6.0.01.6 which is also signed with the same compromised 34df0e7a9f1cf1892e45c056b4973cd81ccf148a4050d11aea4ac5a65f900a42 certificate. The latest version of com.samsung.android.svcagent I could find is 7.0.00.1[1] which has a creation date of 2 September 2022 and also provides the compromised 34df0e7a9f1cf1892e45c056b4973cd81ccf148a4050d11aea4ac5a65f900a42 certificate.

On top of that, at least for the S21 series Samsung phones in their Common Criteria evaluated mode seemingly use the compromised 34df0e7a9f1cf1892e45c056b4973cd81ccf148a4050d11aea4ac5a65f900a42 certificate provided by earlier version 5.0.00.11 of com.samsung.android.svcagent[2]. I couldn't find a published applications list for S22 series phones in Common Criteria mode but suspect com.samsung.android.svcagent 7.0.00.1 from 2 September 2022 would be more recent anyway.

[1] https://apkcombo.com/svc-agent/com.samsung.android.svcagent/...

[2] https://www.google.com/search?q=inurl%3Adocs.samsungknox.com...

Aachen2• 4 years ago

I think the attack vector cannot be simply said to be "being able to run software of your choice on your device". We don't describe victims of emails with malicious attachments as having been compromised via the attack vector "sideloading" (or whatever the non-mobile equivalent of the word is). With this framing, it gets really easy to see sideloading as an evil that must be disallowed for our own good and we end up with devices that can do nothing that is not, with every update of every app again and again, judged to be allowable by an overseas vendor from another culture. What would be a better description though, something like installing software from a malicious source?

arsome6• 4 years ago

It seems some of the malicious applications were pre-installed system update tools on cheap MediaTek devices, so no sideloading needed if that's the case.

throwawaaarrgh4• 4 years ago

2. State actor. Otherwise you'd have to either a) hack every vendor independently for its most cherished keys, or b) find some intermediary that keeps every vendor's most cherished keys. The latter is feasible for a private actor but unlikely, the former is feasible for a state actor and we already know they do this kind of thing.

wyldfire2• 4 years ago

Makes sense -- but how was it discovered?

gjsman-100011• 4 years 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.

bombcar2• 4 years 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-100011• 4 years 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...

secabeen• 4 years ago

The IANA key ceremony is pretty close to best practice: https://kimdavies.com/key-ceremony-primer

walrus01• 4 years ago

“But the plans were on display…”

“On display? I eventually had to go down to the cellar to find them.”

“That’s the display department.”

“With a flashlight.”

“Ah, well, the lights had probably gone.”

“So had the stairs.”

“But look, you found the notice, didn’t you?”

“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”

gryf2• 4 years ago

The Simpsons got it right: https://youtu.be/eU2Or5rCN_Y

saagarjha10• 4 years ago

The places that care store them in HSMs which few people have physical access to.

dgacmu2• 4 years ago

That's not strictly true. At one point, my desk was next to the room that held the vault for one particular signing key. You'd have to get through the building security, through a room guarded by one access control mechanism, and then into a vault secured by a second mechanism. It wasn't guards and guns but it also seemd sufficient for the task at hand.

dmix• 4 years ago

recently in Antwerp, Belgium, where over $100 million in diamonds were stolen in 2003

One of my favourite books I’ve read was about this heist

https://www.goodreads.com/en/book/show/7071759-flawless

EMIRELADERO• 4 years ago

This summarizes a thought I had for a while.

Muggings and robberies happen every single day, probably by the millions.

Hacks also happen, although not that frequently.

Now, what would happen if you combined both? Say a rogue criminal group threatens/kidnaps/holds a sysadmin at gunpoint and forces them to export all the private keys, the keys to the kingdom.

It would be like the explosive mints in Mission Impossible, where if you make the two ends touch, BOOM!

Make the hacking world and the physical mugging/robbing worlds intersect and you probably got an extremely dangerous combination, a nuclear bomb waiting to explode.

User23• 4 years ago

Make the hacking world and the physical mugging/robbing worlds intersect and you probably got an extremely dangerous combination, a nuclear bomb waiting to explode.

This is easily within the capabilities of any state level actor. And unlike a nuclear bomb, it can be kept out of the news. I’d wager it’s already been done.

DrPhish• 4 years ago

This is a well know, and I'd imagine well used technique

see https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis

c22• 4 years ago

I think you're describing the plot of Firewall with Harrison Ford.

shadowgovt3• 4 years ago

Given how much modern hardware is on check-for-updates-online mode by default, how long would a stolen signing key be valuable? I'd imagine the OEM would respond to the theft by cutting new keys and pushing an update to supplant the old key. There'd be some details to hammer out (retroactively declaring the old key untrustworthy past date of theft, allow-listing a bunch of software and peripherals that couldn't be updated to accept if they matched key + checksum), but it feels like stealing such keys would have a very short window of utility.

To be clear, this is not to imply resolving the theft is trivial... Some engineers will have a bad week. It's more that it's solvable from the aggrieved party's side in a way that a diamond theft isn't.

NegativeLatency• 4 years ago

The beauty of stealing a signing key is you don't necessarily tip off the company by getting yourself a copy of it. (The diamonds were removed, but the key stays where it is)

If you were clever enough to get the key you might hold it until it was truly valuable for your exploit.

gjsman-100011• 4 years ago

If you stole a hardware key (which I am speaking of), you've just smashed Secure Boot on all the devices that use it, forever. You can boot whatever software you want on your PlayStation, or Xbox, or Windows Secure-Boot-Enabled PC, or iPad, or similar. Every device with that key has had their locks smashed and there's no going back. Once you've done that, downgrading firmware, modifying firmware, undoing software updates, it all becomes a lot easier.

Bonus points if you stole a Windows signing key and a Windows Update CDN Certificate. Send out fake Windows updates, approved by Microsoft, to do whatever you want. Maybe even force them to use your own middleman update server and only recognize your own keys. Fun stuff.

Got the Apple signing key? Revoke any app you like and have it instantly lock out from millions of iPhones. Break every app for everybody on iPhone and give Apple employees and users a miserable week and cause a political panic. Sky's the limit.

keskival• 4 years ago

Depends on which key is stolen. You can't update the certs on distributed users without some root certificate key. If that key is compromised, there is no trust root which the clients can trust anymore. The thief can revoke all the keys the original institution holds, so they have no path for changing keys.

AnimalMuppet• 4 years ago

If someone copies the key with pencil and paper, the original remains in place. There will be nothing to show that anything happened... until signed malware is detected in the field. (Which is exactly where we are now - with signed malware from a bunch of different keys.) The amount of damage depends on how long the signed malware was out there, and what its uptake rate is.

Sure, it won't destroy or infect the entire world. It's still pretty bad, though. And so far I haven't seen anything saying how long it was out there.

Also: How did so many keys get compromised? There may be a bigger (or more systemic) problem.

V__2• 4 years ago

Having stolen the key, the thieves themselves could push such an update and lock the OEM out. Imagine millions of Apple devices getting an update, locking Apple out while simultaneously installing some nefarious code which uploads all saved credentials to the thieves' server. Sure, the time window is short (if the breakin was detected), but having full-access to millions of people personal data could be a long term money-trove while simultaneously bankrupting Apple through damages. One could short-sell companies by leaking sensitive data, impersonate people and send messages, blackmail people, even simple ransomware would be devastatingly profitable.

gerdesj• 4 years ago

" ... cutting new keys and pushing an update to supplant the old key ..."

What about the keys to say Windows updates?

If someone manages to nick the key you can be sure that they would push a new one and revoke the "old" one whilst simultaneously deploying nasties.

100M (whatevs) is chicken feed compared to the rewards from compromising something like Windows updates. Bear in mind that a simple pecuniary minded criminal gang might leverage a lot of coin mining or whatever for a while and generate an awful lot of electricity usage but a state level actor gets the real crown jewels: information.

Anyway, that's far too complicated when there are far easier ways to crack rather a lot of the world. Look at the Solarwinds compromise. That sort of thing won't (and wasn't) be the last.

Supply chain attacks in the IT world are probably the worst in terms of fall out and the potential losses are vast in comparison to a bit of shiny carbon falling down the back of a sofa. However, for some reason, in this most bizarre modern world we find ourselves in, we still fixate on a bloody diamond!

killjoywashere• 4 years ago

We haven't had a major signing key stolen yet

The DigiNotar case seems fairly close ...

https://en.wikipedia.org/wiki/DigiNotar

https://darknetdiaries.com/transcript/3/

sgjohnson2• 4 years ago

There’s also the HDCP key getting leaked.

https://www.themarysue.com/hdcp-master-key-confirmed-blu-ray...

NovemberWhiskey6• 4 years ago

but stealing a key only takes a pencil and a piece of paper.

You need to have a serious discussion with your HSM vendor if that is the case.

brezelgoring• 4 years ago

A theoretical piece of paper and pen

patmcc2• 4 years ago

Getting to it might be very, very hard. But once it's in your hand you've got it. Diamonds can found as you're leaving the building, or you can be stopped at the airport, or the big pile in your house can be found, etc.

A signing key is like, 4096 bits at most? 4 sms messages will do it.

gjsman-100011• 4 years ago

Are they though? I doubt that Apple, or Xbox, or PlayStation, use HSMs for storing their most sensitive keys. If something goes wrong with the HSM, can you recover the keys, or did you just bork your update system forever? In which case, does the key exist outside the HSM? If it only exists on multiple HSMs, how is it protected in transit between them, and is that vulnerable?

gjsman-100011• 4 years ago

In 2019, Ledger investigated their HSMs, and got it to the point where they achieved a persistent backdoor. On the HSM. Because the HSM they targeted didn’t actually have working Secure Boot(!). It was also FIPS-certified if that comforts you.

https://i.blackhat.com/USA-19/Thursday/us-19-Campana-Everybo...

Better hope Apple didn’t use that one - and that they regularly apply updates… odds of Apple trucking along with a several-year-old HSM don’t seem that low…

gjsman-100011• 4 years ago

I would also like to add to this the recent paper documenting the attacks on the 4K Blu-ray ecosystem for another reason this could happen.

It was actually really secure, until... PowerDVD. It included the AACS 2.0 Copy-Protection Scheme as an encrypted, obfuscated DLL. Which would've been fine - except they accidentally were shipping an unencrypted, unobfuscated DLL containing all the algorithms alongside it. Big oops there. As for the key material itself - it used SGX [a Secure Enclave for Intel CPUs], but it turns out it didn't check for known old insecure hacked SGX firmware, any SGX firmware would do despite Intel strongly warning that isn't safe. So for pirates, Inadvertently unencrypted DLL + bad SGX provisioning = Ripping movies ~1 year after release despite completely new DRM.

There's always the possibility for stupidity to leak a key.

AdmiralAsshat• 4 years ago

One engineer's "stupidity" is another engineer's "plausible deniability". ;)

banana_giraffe2• 4 years ago

Similar to how Bethesda shipped the DRM-free version of Doom Eternal alongside the download for the DRM version.

fomine32• 4 years ago

AACS is designed to expect some keys will leak, so they have revocation mechanism for new titles.

bokohut• 4 years ago

A passing thank you to gjsman-1000 as his words resurfaced some history. As one with many years behind the curtain I recall an old trick that many glanced over since only 'advanced developers' long ago understood the impact: Compiling public releases as debug. Many a software would fail to strip the debug symbols from their code and so the games began. Using Softice and ollydbg along with ones favorite hex editor capable of sprinkling a few nop nops where needed and boom. The really bad ones were the companies that failed to comprehend what the pdb file was and shipped that with releases in debug mode - OOPS, there goes the i.p.

m463• 4 years ago

If someone (for example) got Apple's iOS signing key and Apple's HTTPS certificate, Apple could suffer catastrophic damage.

...people could see what's going on on their phone. I think this could be a good thing.

fizx• 4 years ago

Can we call this Death Star security? Invincible quintillion-dollar project, unless you hit the tiny trash vent at the back of canyon 35.

Lammy• 4 years ago

government agencies who might want to bribe someone for keys

Why would they need a bribe? They have a whole mechanism for "do what we want, and you're not allowed to tell anyone about it". I would be shocked if NSA/FVEY didn't already have every signing key they could get their hands on, especially from companies that are friendly to them like Microsoft https://en.wikipedia.org/wiki/National_security_letter

fomine32• 4 years ago

As you may know, PS3 was the example of failure.

RjQoLCOSwiIKfpm• 4 years ago

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

themoonisachees2• 4 years 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

ShredKazoo14• 4 years 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• 4 years 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

mjg597• 4 years ago

The public evidence doesn't seem to suggest that any Google-owned keys are affected. Platform certificates are owned by the vendor.

MishaalRahman19• 4 years 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• 4 years ago

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

gryf2• 4 years ago

I think it’s more an orbital dung beetle.

MishaalRahman19• 4 years 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• 4 years ago

Why this is Chromium issue tracker?

Or is the same tracker used across all Google projects?

saagarjha10• 4 years ago

For various historical reasons a lot of the device-related security work is housed on Chrome infrastructure.

MishaalRahman19• 4 years 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...

bsimpson• 4 years 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/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• 4 years 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• 4 years 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

This is issue tracker for "apvi" (whatever it means), just happened to be hosted on "bugs.chromium.org" domain like batch of others.

Sirened2• 4 years ago

APVI is Android Partner Vulnerabilities Initiative. It's a working group (?) that deals with security issues of third party vendors

david_allison• 4 years ago

Is the "First Time Seen in the Wild" accurate? (2016-02-13 11:50:54 UTC)

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.

jeroenhd4• 4 years 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.

pyinstallwoes2• 4 years 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.

fotta• 4 years ago

The tags in the left sidebar have "Reported-2022-May-13"

pyinstallwoes2• 4 years ago

Dang

ro_bit• 4 years 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?

MishaalRahman19• 4 years 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• 4 years 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.

anshumankmr• 4 years ago

I have YouTube vanced. Should I remove it?

ShredKazoo14• 4 years ago

Malware on the Google Play store seems fairly common.

This article from Malwarebytes reported on a family of malicious apps with over 1M downloads: https://www.malwarebytes.com/blog/news/2022/11/malware-on-th...

This paper analyzed 1238 malicious apps grouped into 134 families: https://people.ece.ubc.ca/mjulia/publications/GooglePlayMalw...

An attacker who can steal these private keys can get malware uploaded to the Google Play store. Getting malware uploaded to Google Play is way easier.

And if Samsung's private key is stolen, I would certainly not be inclined to trust their Galaxy Store.

Now is a great time to go through your phone & uninstall apps you don't use or don't trust -- especially bloatware from the compromised OEMs. If I understand other comments in this thread correctly, the stolen keys allow the thief to escalate privileges from "ability to issue an update for a random app you have installed" to "ability to root your device".

Aachen2• 4 years ago

Or F-Droid, or other stores you trust. It's about trusted sources, not it originating from Google specifically, right? Theoretically that includes third-party websites, if you can be sure that the download wasn't compromised in transit, that the server isn't compromised, that the uploader is benign...

jeroenhd4• 4 years ago

Any new app can get system privileges if it's signed by a platform key. This doesn't just apply to updates of existing apps.

I'd go one step further, don't install any apps from third party websites. Also think very critically about trusted app stores, make sure you know their signature policy.

lzooz• 4 years ago

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

manchmalscott• 4 years ago

All the comments seem to be deleted. Do you remember what was unsettling about them?

2OEH8eoCRo0• 4 years ago

One was a video of a dancing child with a cellphone.

MishaalRahman19• 4 years 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_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.

musicale• 4 years ago

Do not sideload those apps from third-party sites/outside of Google Play or trusted OEM store.

Is that you Messrs. Pichai and Cook?

So you're saying this "security" isn't just a smokescreen to lock us into Google and Apple App Stores?

alexw912• 4 years ago

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.

https://landing.google.com/advancedprotection/

MishaalRahman19• 4 years ago

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.

danielscrubs• 4 years ago

Google “recommends”, gives out strong IBM vibes. No longer very end user centric but business customer centric if that makes sense.

saagarjha10• 4 years ago

What should they do?

mjg597• 4 years 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.

MishaalRahman19• 4 years 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• 4 years ago

I assume that the level that the malware is running at couldn’t simply modify the OTA file and inject itself back in?

strcat4• 4 years ago

You can freely update from a v2 signature to a v3 signature.

If the minimum SDK version is below when v2 was introduced, Android will include both a v1 and v2 signature by default.

If the minimum SDK version is above when v2 was introduced but below when v3 was introduced, Android will only include a v2 signature by default.

It will only include a v3 signature by default if the minimum SDK version is above when v3 was introduced, which is rare.

The reason it works this way is because v2 was a significant security upgrade over v1 but v3 is just v2 with rotation support. If you do a key rotation, you get a v3 signature included to handle it for versions with key rotation support. If you support older versions, the users on those versions are still relying on the original keys. This is transparently supported in a way that it's backwards compatible.

It would simply waste space to include v2 + v3 when no rotation has happened yet. I don't know why they bothered to micro-optimize to this extent but they did.

For some reason the Play Store doesn't make use of Android's support for key rotations yet. They only support key rotations with Play Signing since they're phasing out non-Play-signed apps. If you switch from non-Play-signed to Play Signing, they keep signing the app for existing installs with the old key but switch to a new key for fresh installs. They do the same thing if you trigger a key rotation with the UI. They could rotate the key for existing users on Android versions with v3 support. They might as well rotate it even for users on versions predating it, since if they did get an OS upgrade it will start working right away.

netheril96• 4 years ago

My entirely unsupported guess is that they may all share manufacturing for some models, and certificates may have been on site there?

I think manufacturing only needs the public key, so the compromise can’t really happen there.

mjg597• 4 years ago

Firmware builds may be outsourced to the ODM in some scenarios.

userbinator2• 4 years ago

Not surprising either, given that you can far more easily find MTK's leaked datasheets and other useful design documents than any of the other major Android SoC vendors. I could own the detailed documentation for my phone (which is of course rooted) thanks to that insecurity, so you can't say it's entirely a bad thing.

blihp• 4 years ago

Depending on the age of the devices in question, 'simply' may not accurately reflect the solution as Android vendors generally stop updating devices as soon as they can get away with it, security issue or otherwise. Unless these are newer devices, I'd expect that a fair number of them will never get an update.

bee_rider• 4 years ago

All the more reason to highlight the simplicity. Any vendor who decides not to do something simple to protect their customers should be relegated to the “never buy” heap.

ShredKazoo14• 4 years ago

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.

This implies that all the affected vendors shared their private keys with Mediatek. Why would they need to do this? (Genuine question, I don't know much about firmware. But it doesn't seem like it should be necessary at first glance.)

arsome6• 4 years ago

It's possible Mediatek (or an unrelated contractor) did the firmware work for them all so they're the ones holding the keys in the end.

arsome6• 4 years ago

Take a look here, I found some strings mentioned on VirusTotal for the malware in question (drv.androidsecurityteam.club) here in the slideshow. Sounds like malicious updaters are being signed by some vendors perhaps?

https://maldroid.github.io/docs/vb_2022.pdf

I'll be curious when more details come out, but there's not much to go off yet.

EDIT: Sounds like this may all tie back to a contractor providing OTA update applications, either being compromised or directly malicious themselves: https://wuffs.org/blog/digitime-tech-fota-backdoors

"They provide Android ODMs/OEMs with the SystemFota updater APK, instructions on how to build OTA packages and a web portal where they can upload them and view statistics."

strcat4• 4 years ago

The post title here should really be corrected. It's editorialized and is completely wrong.

There is no 'Android platform signing key'. Android is not a single OS provided by Google. It's an OS family. Each OEM has their own OS and keys, often per device or device family. Several non-Google OEMs either got tricked into signing malware or had at least one of these keys (platform key) compromised. The issue is clearly marked as a partner issue discovered by their program for reporting issues to partners (non-Google Android OEMs). Google detected it and that's why it's on a Google issue tracker. Platform signing key is used to sign app-based components in the OS which are able to receive platform signature permissions, including some quite privileged access. Any app can define signature permissions. Platform signing key is the one used by the highly privileged app-based components of the platform itself, such as the Settings app.

Platform key is only really meant to be used for first party code, normally all built with the OS but potentially updated outside it. It's not the verified boot key (avb key) or the key for signing over-the-air updates (releasekey by default but can be a dedicated key). There are also similar keys for several other groups of OS components with internal signature permissions (media, shared, etc.). All of these keys can be rotated, but aren't rotated in practice as part of the normal process of maintaining devices, partly because supporting phones for 5+ years is a recent development. The rotation that's done in practice is using a separate set of keys for each device / device family. For example, Google used new keys for each generation of Pixel phones and they currently use separate keys for separate device models although they've sometimes used the same keys for XL and non-XL variants in the same generation.

Even the verified boot key for the stock OS could be rotated by firmware updates since they're all shipped with OS updates and it's completely normal to do breaking changes requiring both new firmware and new OS. It'd require adding code to handle the rotation in several places (TEE and secure element pin it and use it as a bonus input for key derivation, which would need to continue using the old value) along with breaking anything pinning the hash for attestation. Only the SoC firmware signing key and firmware for other secondary components with the key burned into the hardware can't be rotated.

dang• 4 years ago

Ok, we've changed the title to be that of the article.

(Submitted title was "Android platform signing key compromised".)

strcat4• 4 years ago

Only the SoC firmware signing key and firmware for other secondary components with the key burned into the hardware can't be rotated.

Side note: those components do have fuses burned via updates that are used to implement downgrade protection dynamically. In theory, they could provide key rotation support. That may make sense as device support gets longer than 5 years. They should also really support more downgrade protection counter increments than they currently do. Snapdragon used to support 16 increments (16 fuses) but I'm not sure what they support in current generation devices. They called it a '16 bit version number' but you can't unset a bit.

OS downgrade protection is generally being done with special replay protected storage from the TEE (Pixel 2), the secure element (Pixel 3 and later) or simply by hard-wiring the version in firmware (very common approach before Android Verified Boot 2.0). It's a lot more flexible both in terms of being able to do key rotation in theory and not having any limit on # of updates. Pixels simply convert the Android / Pixel patch level such as 2022-11-05 into a Unix timestamp and that's the OS rollback counter stored in the secure element after successful boot. Happens alongside updating the firmware rollback counter, which rarely increases. Pixel 6 only bothered shipping the code to increment the firmware counter with Android 13 when they increased it. It's so uncommon that the external development community largely wasn't prepared to cope with it even though it should be done much more regularly.

guelo3• 4 years ago

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

mjg597• 4 years 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.

guelo3• 4 years ago

I would be able to use this key to sign terminal or file manager apps and get full access to my file system.

LooseMarmoset2• 4 years 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• 4 years ago

That was my first thought after "oh fuck". Does this mean any current Samsung phone can now be rooted by the user?

LooseMarmoset2• 4 years 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• 4 years 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.

MishaalRahman19• 4 years ago

Yeah that's my understanding as well

ok_dad• 4 years 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.

userbinator2• 4 years ago

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

teaearlgraycold• 4 years ago

Do you realized that it's mandated by Google that a phone sold under the name "Android" has to be rootable?

kaladin-jasnah• 4 years ago

Why can't I root a Qualcomm Samsung phone for the US market? What about carrier locked phones? Et cetera.

ShredKazoo14• 4 years 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• 4 years 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.

saagarjha10• 4 years 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• 4 years 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.

hsuduebc2• 4 years ago

Well that's a bummer

arsome6• 4 years 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/2abeb8565c30a3d2af0fc8ea...

ShredKazoo14• 4 years ago

So Google's private key was stolen?

arsome6• 4 years 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.

dhx2• 4 years 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• 4 years 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.

javajosh• 4 years 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.)

archon8104• 4 years 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).

jeroenhd4• 4 years 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-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• 4 years 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.

archon8104• 4 years 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

skp1119• 4 years 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• 4 years 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%.

Platform certificates used to sign malware

Related Stories