Careless engineering, irresponsible and negligent practice of quality control, and contempt for work processes are now characterized by Apple software
Centralized trust is an inherently poor security design *, but that’s how Apple works now. A single error 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 can not trust Apple to get the system software properly, but what can you do when Apple notices malicious software?
* Security that depends on a central authority is compromised if the central authority makes a mistake or is compromised. In this case, this authority is Apple. The PGP model for distributed and graded trust never caught on, but it is far superior and also allows users to build networks of trust ̵
Apple approved malware for malware … now approved !?
We can confirm that the payloads are actually notarized via the spctl command (note “source = Notarized Developer ID”):
As far as I know this is a first: malicious code that gets Apple’s “approval stamp” notarization.
What does this mean?
– These malicious payloads were sent to Apple before distribution.
– Apple apparently scanned and discovered no evil, (accidentally) authorized them.
– Now approved, these malicious payloads can run – even on macOS Big Sur.
Again, due to its notarization status, users will (quite likely) fully trust these malicious samples.
When I reported the notarized payloads, they were quick to revoke the certificates (thus revoking the notarization status): Thus, these malicious payloads will no longer run on macOS. Hurray!
… This happened on Friday 28. August.
Interesting, from Sunday (August 30) The adware campaign was still alive and served 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)
Meaning even at Big Sur, they will (still) be allowed to run: Big Sur, pray, but allow it.
If we extract the timestamp for code signing, we can see that this (new) payload was signed on Friday PM (28 August 2020 at 13:04:04 HST) … probably after Apple’s first “answer”?
Both the old and the “new” payload (s) appear to be almost identical and contain OSX.Shlayer packed with Bundlore adware.
However, the attackers’ ability to agile to continue the attack (with other notarized payloads) is remarkable. Clearly in the endless cat & mouse game between the attackers and Apple, the attackers are currently (still) winning. 😢