Hacker News Reader

Comment by arciini | Hacker News Reader

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?

View on HN

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.

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...

Good to know!

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?

Android controls the App Store better than email controls side loading. I wouldnt recommend people side load unless they’re capable of auditing packages they’re loading, the equivalent recommendation in the desktop world is application allowlisting.

The general public has proven that they’re not capable of any type of sanity check to the point where I would call sideloading dangerous.

It is a matter of practical fact that only a small proportion of the Andriod-using public chooses to use the software of their choice by sideloading. Mentioning sideloading in this context shouldn't be interpreted as an attack upon or a dispargement of the practice of sideloading. I, as an Android user, am happy to learn that the (main?) vector of attack happens to be sideloading. (if true) This informs the broader conversation and helps individual Android users gague the likelihood of whether they have may have been directly affected.

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.

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.

Makes sense -- but how was it discovered?

Pretty straightforward, honestly: if the signature on a piece of malware can be verified by a corporation's private key, unless that corporation is a remarkably inept bad actor, that corporation and its signing key have been compromised.

Not saying it's how these were picked up, but that's the most obvious way.

I think you’d be surprised how many large companies have such poor control of their signing servers that anyone in the company with a valid login and engineering group membership can generate signatures for arbitrary artifacts.

What would an actual secure workflow for signing artifacts look like?

I'm thinking: Final round of "code review" by security engineer on high-security single-purpose device, build artifact on that device, sign using hardware security module.

I put "code review" in scare quotes because code changes are potentially expensive at this point. For minor issues, turn to your standard workstation and file an issue for next release. For a major security problem, call off the release.

One guy named Jeff and his boss Clem have access to an offline PC with some signing software in a closet behind a badged door. Not TEMPEST secure unless they have govt contracts. For hardware stuff it might be at the factory.

Thanks, interesting.

I don't see how TEMPEST is relevant?

I mean, if you don't want state actors to steal your super secret keys, maybe secure the power lines and RFI

I searched on Google for RFI, not sure what it stands for?

I believe that RFI here is "RF interference." Here's links to learn more about the references above [1] [2].

[1] https://en.wikipedia.org/wiki/Tempest_(codename)

[2] https://en.wikipedia.org/wiki/Van_Eck_phreaking

Yep. It is pretty trivial to extract encryption keys via either control of voltage or detection of electromagnetic radiation emanating from a server

> anyone in the company with a valid login and engineering group membership can generate signatures for arbitrary artifacts.

Trust me, I'm not at all surprised, but my point stands: it's either a compromise of the company or the key.

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?

Why would Google have these keys?

(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.

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.

Platform keys are only required to be v2, as far as my understanding goes.

Yeah that's the minimum since Android 11 for system apps targeting API level 30+.

This is about non-Google OEM OS signing keys.

v1/v2/v3 APK signing has nothing to do with the Play Store requiring Play Signing for newly published apps. App bundles / split APKs also don't inherently have to be used the way they're using them. Entirely possible to use them outside the Play Store with your own signing keys. v3 signing is just v2 with key rotation support. v2 is proper whole file signing instead of v1 which was just the flawed JAR signing system.

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

The bug doesn't mention any vendor, rather the bug specifies "Partner-Multiple", seen reports elsewhere that points to a particular vendor?

Search google for the certificate SHAs. Most don't result in anything but this report, but one is for Samsung and another for LG.

It's not hard to figure out which vendors are affected. Just search for the SHA256 hash of each malware sample on VirusTotal.

eg. https://www.virustotal.com/gui/file/b1f191b1ee463679c7c2fa7d...

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

Reply on news.ycombinator.com