Notarized Mac Malware
Interestingly, Peter noticed the campaign originating from
homebrew.sh, leveraged adware payloads were actually fully notarized! 😱We can confirm the payloads are indeed notarized via the
spctlcommand (note the"source=Notarized Developer ID")[…]As far as I know, this is a first: malicious code gaining Apple’s notarization “stamp of approval”.
[…]
As noted, Apple (quickly-ish) revoked the Developer code-signing certificate(s) that were used to sign the malicious payloads. 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[…]
This is discouraging, as OSX.Shlayer is said to be the “most prevalent” Mac malware, yet notarization didn’t catch it. It’s not clear whether Apple was eventually able to adapt or whether new binaries are still being notarized at will. Perhaps the real benefit of notarization is not prevention but rather that it allows related binaries to be found (because Apple can search the previous submissions) and disabled sooner, before they have widely spread.
See also: Zack Whittaker, Thomas Reed, MacRumors, Lily Hay Newman, Nick Heer.
Previously:
- Potential
- XCSSET Mac Malware
- 2020 State of Mac Malware
- The True and False Security Benefits of Mac App Notarization
Update (2020-09-07): Cedric Owens:
I had similar observations last year when I found that I was able to get my red team apps notarized. I wrote about my steps here. I reported to Apple but not sure if any changes have been made.
Over the last couple of years, a succession of security experts have deemed Shlayer unsuitable for conventional signature-based detection methods, because of its design and frequent evolution. Rapid checks, such as those most probably performed as part of Apple’s initial notarization process, are therefore unlikely to be able to detect it. Most of us had assumed that those brief checks would be followed by slower and more thorough analysis, with triage determining which apps needed to go on for expert human dissection.
Update (2020-09-11): Phil Stokes:
But Shlayer has been up to other tricks since June of 2020 that have been helping it avoid the static signatures employed by most vendors. Although bypassing Apple’s Notarization checks is obviously a headline grabber, this new variant of Shlayer utilizes heavily obfuscated Zsh scripts and is in fact far more prolific in the wild. Let’s take a look at how this new variant works.
4 Comments RSS · Twitter
What really distresses me about all of these "new Apple security technologies":
- All of them are very new and at this time aren't worth beans. Maybe in 5 years when they have been "battle tested" and matured... maybe. At this point it's like "Windows Defender, early days. The bad guys are going to go after "new to Apple" features and they're going to win. Just tonight? Read on Twitter that OSX.Shlayer bad guys are using zsh scripts. zsh is not new, but it's "new to Apple."
- Howard brings up the "layered defense" and "swiss cheese".. layered defense ONLY works when fleets of computers have truly different layers from different vendors. If Apple is as slow as MSFT has been with their malware lists then you have thousands of computers with all of the same vulnerabilities. Malware authors are known to read release notes and then go after platforms that are slow to patch either affected lists or shared libs. Oldest trick in the book.
Our older Macs and even these new Macs (up to Catalina) can and should be additionally protected: Strong /etc/host files, AdGuard (reactive blocklists that load when new XSS threats are flagged), Little Snitch, BlockBlock, Oversight, SAP Privileges, use any you can up to when there's a performance hit.
Apple "Sherlocking" any of these tools and making them "mandatory" is a mistake and is not really layered defense at all. It just sets the parameters of the box for the bad guys.
- Apple already has security bulletins when they fix bugs. This is the most useful thing Apple Security has done. Might be better if they publish something more like a CERT bulletin to warn power users and enterprise of observed/noticed threats.
- Finally, I really do not like outsourcing "all security" to Apple, and I really don't like Apple being the "central authority" over our machines, having the power to revoke certs "by mistake". The only "security incident" I've had in the past 10 years on a Mac, that's wiped out a day of work originated from Apple itself when they "automatically cancelled" Charlie Monroe. That's too much power, that is open to "mistakes" "negligence" or even an insider threat from within Apple itself.
Apple was doing better when they left macOS alone and let vendors who know better do better. I've had more grief from Apple in the last 2-3 years than in the entire time I've owned Macs going back to pre-OSX days, and I went thru the 68K to PPC era and the PPC to Intel era. I call this era "Windows, but with more grief."
All of them are very new and at this time aren’t worth beans. Maybe in 5 years when they have been “battle tested” and matured… maybe.
The underlying tech isn’t very new. Code signing, performing static analysis, etc.
What’s relatively unusual is enforcing it through policy.
At this point it’s like “Windows Defender, early days.
IME, Windows Defender was quite an improvement over the competition (perhaps in large part because Microsoft’s business model didn’t hinge on trying to upsell you on snake oil).
The bad guys are going to go after “new to Apple” features and they’re going to win. Just tonight? Read on Twitter that OSX.Shlayer bad guys are using zsh scripts. zsh is not new, but it’s “new to Apple.”
OK, maybe? But that’s not a net loss. A security policy isn’t bad just because it’s imperfect. We don’t throw the towel when there’s a root exploit and make everyone root; we fix the exploit and look for more of them.
(There are certainly concerns to be had with notarization, but I don’t think “there was one (1) false positive after a year and a half” is one.)
Howard brings up the “layered defense” and “swiss cheese”.. layered defense ONLY works when fleets of computers have truly different layers from different vendors. If Apple is as slow as MSFT has been with their malware lists then you have thousands of computers with all of the same vulnerabilities.
Where do you get the impression that MSFT is slow with malware?
Our older Macs and even these new Macs (up to Catalina) can and should be additionally protected: Strong /etc/host files, AdGuard (reactive blocklists that load when new XSS threats are flagged), Little Snitch, BlockBlock, Oversight, SAP Privileges, use any you can up to when there’s a performance hit.
Yeah, that sounds really practical for the mass market.
(I also have bad news for you regarding hosts files, such as if you’re using Chrome.)
Apple “Sherlocking” any of these tools and making them “mandatory” is a mistake and is not really layered defense at all.
Apple has been about delivering a one-size-fits-all package for a long time now, reinforced in the Jobs 2.0 era. It should come as no surprise that there isn’t some kind of API to hook into various security layers.
Microsoft did do such an API, for various places, such as IOfficeAntiVirus and IAttachmentExecute, and various NDA’d lower-level ones. Unfortunately, it’s also biting them in the behind a little — these kinds of hooks are part of the reason file system access is so much slower in Windows (see this infamous comment). Threading the needle of security and performance is hard enough when you’re the first party; it becomes much harder when you need to wait for third-party code to execute (and suppose Apple did provide such a hook: they’d be criticized that their code is unfairly faster).
Apple already has security bulletins when they fix bugs. This is the most useful thing Apple Security has done. Might be better if they publish something more like a CERT bulletin to warn power users and enterprise of observed/noticed threats.
I have no idea what your point is here.
Does a user read security bulletins? If so, what actionable information is in it?
Finally, I really do not like outsourcing “all security” to Apple, and I really don’t like Apple being the “central authority” over our machines, having the power to revoke certs “by mistake”.
I mean, sure, but that’s really the logical continuation of something Steve started long ago. Had he remained in charge of the Mac in the late 1980s, we’d probably be further along, even.
The only “security incident” I’ve had in the past 10 years on a Mac, that’s wiped out a day of work originated from Apple itself when they “automatically cancelled” Charlie Monroe.
So you’re criticizing both that notarization isn’t effective enough, and also that there aren’t actual problems?
Apple was doing better when they left macOS alone
I would argue they haven’t done enough with macOS lately.
