Apple Core Rot: Apple Notarizes Adware (Malware), Compromises User Systems

2020-09-01 • SEND FEEDBACK |
Related: Apple, Apple Core Rot, security

Sloppy engineering, irresponsible and negligent quality control practices, and disdain for the needs of working pros are now the hallmark of Apple software

Centralized trust is an inherently bad security design*, but that is how Apple now operates. A single mistake has worldwide implications for hundreds of millions of users. And the notarization process is guaranteed to be fallible.

"The vast majority of threats for macOS in 2019 were in the AdWare category." -Kaspersky

You cannot trust Apple to get system software right, but what can you do when Apple notarizes malware?

* Security that relies on one central authority is kaput should that central authority make a mistake or be compromised. In this case, that authority is Apple. The PGP model of distributed and graduated trust never caught on, but it is far superior and also allows users to build networks of trust—far more resilient.

Apple Approved Malware malicious code ...now notarized!?

We can confirm the payloads are indeed notarized via the spctl command (note the “source=Notarized Developer ID”):

As far as I know, this is a first: malicious code gaining Apple’s notarization “stamp of approval”.

What does this mean?

- These malicious payloads were submitted to Apple, prior to distribution.
- Apple scanned and apparently detecting no malice, (inadvertently) notarized them.
- Now notarized, these malicious payloads are allowed to run—even on macOS Big Sur.
- Again, due to their notarization status, users will (quite likely), fully trust these malicious samples.

To Apple’s credit, once I reported the notarized payloads, they were quick to revoked their certificates (and thus rescind their notarization status): Thus, these malicious payloads will now, no longer run on macOS. Hooray!

...This occurred on Friday, Aug. 28th.

Interestingly, as of Sunday (Aug 30th) the adware campaign was still live and serving up new payloads. Unfortunately these new payloads are (still) notarized:

$ spctl -a -vvv -t install /Volumes/Installer/Installer.app
/Volumes/Installer/Installer.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: Aimee Shorter (73KF97486K)

Which means even on Big Sur, they will (still) be allowed to run: Big Sur, prompts, but allows.

If we extract the code-signing time stamp, we can see this (new) payload was signed on Friday PM (Aug 28, 2020 at 1:04:04 PM HST) ...likely after Apple’s initial “response”?

Both the old and “new” payload(s) appears to be nearly identical, containing “OSX.Shlayer” packaged with the “Bundlore” adware.

However the attackers’ ability to agilely continue their attack (with other notarized payloads) is noteworthy. Clearly in the never ending cat & mouse game between the attackers and Apple, the attackers are currently (still) winning.

...