7 ms·

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 st

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.
    - marumari 4y ago
      Platform keys are only required to be v2, as far as my understanding goes.
      - MishaalRahman 4y ago
        Yeah that's the minimum since Android 11 for system apps targeting API level 30+.
    - strcat 4y ago
      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.
- hn_throwaway_99 4y ago
  These aren't Google's keys. They are vendor-specific keys (e.g. Samsung's) used to sign their releases.
  - whizzter 4y ago
    The bug doesn't mention any vendor, rather the bug specifies "Partner-Multiple", seen reports elsewhere that points to a particular vendor?
    - jvolkman 4y ago
      Search google for the certificate SHAs. Most don't result in anything but this report, but one is for Samsung and another for LG.
    - MishaalRahman 4y ago
      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/b1f191b1ee463679c7c2fa7db5a224b6759c5474b73a59be3e133a6825b2a284/details https://www.virustotal.com/gui/file/b1f191b1ee463679c7c2fa7d...
- MishaalRahman 4y ago
  Google isn't at fault, their certs weren't leaked (as far as we know).
MishaalRahman 4y 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=apk&page=4&s=34df0e7a9f1cf1892e45c056b4973cd81ccf148a4050d11aea4ac5a65f900a42 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.
- dhx 4y 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/download/apk https://apkcombo.com/svc-agent/com.samsung.android.svcagent/... [2] https://www.google.com/search?q=inurl%3Adocs.samsungknox.com%2FCCMode https://www.google.com/search?q=inurl%3Adocs.samsungknox.com...
  - MishaalRahman 4y ago
    Good to know!
- arsome 4y 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.
throwawaaarrgh 4y 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.
- wyldfire 4y ago
  Makes sense -- but how was it discovered?
  - eganist 4y ago
    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.
    - foobiekr 4y ago
      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.
      - ShredKazoo 4y ago
        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.
        4y ago

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.
  - marumari 4y ago
    Platform keys are only required to be v2, as far as my understanding goes.
    - MishaalRahman 4y ago
      Yeah that's the minimum since Android 11 for system apps targeting API level 30+.
  - strcat 4y ago
    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.
hn_throwaway_99 4y ago
These aren't Google's keys. They are vendor-specific keys (e.g. Samsung's) used to sign their releases.
- whizzter 4y ago
  The bug doesn't mention any vendor, rather the bug specifies "Partner-Multiple", seen reports elsewhere that points to a particular vendor?
  - jvolkman 4y ago
    Search google for the certificate SHAs. Most don't result in anything but this report, but one is for Samsung and another for LG.
  - MishaalRahman 4y ago
    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/b1f191b1ee463679c7c2fa7db5a224b6759c5474b73a59be3e133a6825b2a284/details https://www.virustotal.com/gui/file/b1f191b1ee463679c7c2fa7d...
MishaalRahman 4y ago
Google isn't at fault, their certs weren't leaked (as far as we know).

MishaalRahman 4y 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=apk&page=4&s=34df0e7a9f1cf1892e45c056b4973cd81ccf148a4050d11aea4ac5a65f900a42 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.

dhx 4y 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/download/apk https://apkcombo.com/svc-agent/com.samsung.android.svcagent/... [2] https://www.google.com/search?q=inurl%3Adocs.samsungknox.com%2FCCMode https://www.google.com/search?q=inurl%3Adocs.samsungknox.com...
- MishaalRahman 4y ago
  Good to know!
arsome 4y 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.

throwawaaarrgh 4y 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.

wyldfire 4y ago
Makes sense -- but how was it discovered?
- eganist 4y ago
  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.
  - foobiekr 4y ago
    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.
    - ShredKazoo 4y ago
      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.
      - 4y ago