Fear-mongering about Mac ransomware

I recently discovered an absolutely atrocious article on Mac ransomware, thanks to a friend who forwarded the link to me. The article, found on the MacUpdate blog, is a minefield of glorious wrongness and fear-mongering.

https://www.macupdate[.]com/best-picks/mac-ransomware

(URL modified to avoid increasing the ranking of the article on search engines.)

Mac ransomware reality

Before we get into a tribute to the numerous ways this article is misleading and wrong, let’s set the stage by looking at the reality of the Mac ransomware landscape.

The first real Mac ransomware – KeRanger – was spotted in March of 2016. The malware infected systems through a supply chain attack, in which a malicious copy of the Transmission app was distributed via the official Transmission website, following a hack of the site. This was, ultimately, the most successful piece of Mac ransomware, but was cut short by a 3-day delay between infection and encryption of files, during which time most people who were infected would have already been disinfected by macOS, antivirus software, or a Transmission update designed to remove the malware. Few actual cases were seen.

The next two – Findzip (aka FileCoder, aka Patcher) and MacRansom – appeared in the first half of 2017, and were flops from the start. None were ever seen in the wild in any significant numbers.

There have been some proof of concept ransomware programs that have never been weaponized for malicious purposes, and even interest in creating proof of concepts has dwindled.

To put it bluntly, all Mac ransomware – so far – has been a flop, nothing more than a minor blip in Mac malware history. There is currently no known Mac ransomware in the wild.

This is not to say it’s impossible, or that we can assume it will stay this way. However, it’s certainly not a looming threat that we need to be overly concerned about right now, especially if you take the simple precaution of implementing a good data backup strategy.

So, now that we’ve got the reality covered, let’s take a look at this laughable article from MacUpdate.

“You Can’t Ignore Mac Ransomware!”

I suppose that headlines that were more clickbait-y have been written, but it seems to me that this is pretty far up there on the clickbait rating scale.

Why can’t we ignore it? Let’s read on. Hmm, those are some scary-sounding stats.

Windows ransomware stats from MacUpdate

There’s just this one little problem: those are Windows stats. They have absolutely no bearing on the state of ransomware for macOS. The article doesn’t mention that, though, leaving the reader to infer that this information applies to the Mac.

In fact, the article actually specifically calls out that “Mac ransomware is also on the increase.” Which is hard to justify, since it went from 3 to zero and has stayed there.

Most common ransomware

The article lists a number of different pieces of Mac ransomware. But there are some problems with that list. Let’s look at each one.

FBI/MoneyPak scam (2013): This is a real thing, but was not actually ransomware. It was a scam website that tried to keep you from closing the tab/window and trick you into paying the scammers.

FileCoder (June 2014): FileCoder is also a real thing, also known as FindZip and Patcher. However, it appeared in early 2017, not 2014. There was a Windows ransomware named FileCoder that was discovered in 2014, but that’s not relevant to macOS. I’m nit-picking with the date a bit, but it’s important, as it’s a strong indicator for how much this article conflates Windows threats and Mac threats.

KeRanger (March 2016): This is also a real thing, and is for the most part described accurately. There is one vital exception, though: citing MacWorld, the article says that “KeRanger appears to be still under active development.” This is portrayed as the current state. However, that quote from the MacWorld article is in turn quoted from Palo Alto Networks’ 2016 article on KeRanger, and is not actually representative of the current state of KeRanger. There is no indication that any development has continued in the nearly 4 years since it was released.

Filezip, aka Patcher (February 2017): There are two errors here. First, this is a duplicate, as this is just another name for FileCoder. Second, the name is FindZip, not Filezip.

Ransomware-as-a-Service (RaaS): I can only assume this is a reference to MacRansom, which was RaaS ransomware. This was a real thing, available for sale online, but there’s no sign that any actual infections ever happened.

What’s the takeaway?

I could get really nit-picky about some other little, unimportant things, but that would be silly, and a little to unnecessarily picky. However, I definitely don’t like the combination of the clickbait-y way this information was presented and the inaccuracies.

Bottom line, as long as you’re backing up data to drives that are not constantly connected to your Mac, you’re always safe from ransomware. (Note the plural “drives”… you should have multiple backups, and preferably at least one should be somewhere off-site, where a disaster like fire or robbery can’t get it.) Worst case scenario, if you get infected with some future ransomware and all your data is encrypted, you just restore from the backup.

Mac malware certainly does exist. Precautions are needed for dealing with malware that doesn’t announce itself by encrypting all your files.

However, screaming about the dangers of Mac ransomware, and using inaccurate and irrelevant information to do so, is precisely the behavior that leads people to accuse security people of using scare tactics.

</rant>

Notarization of AppleScript applets

As Catalina’s release date approaches, I find myself faced with a dilemma that many others are facing. At Malwarebytes, we have a number of AppleScript applets that we can provide to customers, for troubleshooting, gathering logs, incident response, etc. Come Catalina, those customers will be unable to run these scripts without special instructions… unless we notarize them.

So, they must be notarized. The next question is, “How?” Fortunately, Rich Trouton has published an excellent document on notarizing Automator applications, which is just as applicable to AppleScript applets.

I have little to add to Rich’s instructions, but did stumble across one special case. It’s sometehing that most people probably won’t see… but if you do, it’ll bring your notarization attempt to a screeching halt.

The problem

For most independent developers, their Apple developer account will stand alone, while companies will probably have multiple developer accounts all associated with a single master account. In such cases, there’s no problem… it’s unambiguous what account is going to be used for notarization.

However, if you’re reading this, you’re probably like me, and your account is associated with more than one master account (or “provider”) that can do signing and notarization. You may not even know about that, if it was set up for you or happened so long ago that you forgot.

In such a case, on attempting to submit your app for notarization using xcrun, you will will see an error message containing the following text:

Your Apple ID account is attached to other iTunes providers. You will need to specify which provider you intend to submit content to by using the -itc_provider command.

The solution

Most likely, even if you knew your account was associated with multiple “providers,” you probably don’t know the correct short name for the desired provider to use with the -itc_provider command. Fortunately, there’s a simple way to find out. If you’re using Xcode 10 or earlier, run the following, using your developer account e-mail address and the app-specific password you have created for notarization (see Rich’s instructions):

/Applications/Xcode.app/Contents/Applications/Application\ Loader.app/Contents/itms/bin/iTMSTransporter -m provider -u you@company.com -p app-password-here

This will not work on Xcode 11, where you’ll need to do this instead:

xcrun iTMSTransporter -m provider -u you@company.com -p app-password-here

The output will be very long, and will end with a provider listing looking like this:

   - Long Name -                          - Short Name -
 1  Your Corporation                      YourCorporation
 2  Another Group                         AnotherGroup

There may be more than two, and they may be different groups at your current company, different companies, etc, and may even include some stuff you are not supposed to still have access to from a previous job (oops!).

Note the short name of the one you want to use, then run xcrun again, but add the -itc_provider like so:

xcrun altool --notarize-app --primary-bundle-id "com.apple.ScriptEditor.id.MyScript" --username "you@company.com" --password "app-password-here" -itc_provider "ProviderShortName" --file MyScript.zip

Of course, if your applet isn’t called “MyScript”, you’ll want to make some changes there, but you get the idea. 🙂