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>

How I became a Mac security researcher

Over the years, I’ve been attacked and criticized many times over my views on security. At times, it’s been completely justified, while other times, it stems from not knowing the things that I know.

Thus, spurred on by events that are ultimately unimportant, for the first time publicly, I’ve decided to tell the entire story of how I got into security, how I ended up at an antivirus company, and how and why my views have changed. This is the story of someone who went from a rabid “Macs don’t get viruses” fanboy to a professional malware researcher, and why exactly such a strange turn of events occurred. With a smattering of stories about the history of Mac malware thrown in. 🙂

“Macs don’t get viruses”

In January of 2006, I joined Apple’s discussion forums, termed “Apple Support Communities,” or ASC for short. Around this same time, I was attempting a poorly-thought-out transition to teaching high school science, which I would soon learn I was not cut out for. A few years later, I failed at it and quit before I could finish paying off the debt from getting my Master’s degree. My self-esteem was at an all-time low, and I vented steam at people on the forums. It was not a time I’m particularly proud of.

At that time, I firmly believed that the Mac’s malware problems from the early days were a thing of the past. Before OS X, Apple’s “Classic” system (as we call it now) had all manner of malware. In fact, the first widespread computer virus – the Elk Cloner virus, which appeared in 1982 – actually affected the Apple II computer, a precursor of the Macintosh, and not a PC running DOS or Windows.

Disinfectant logo

The early Macintosh was no stranger to threats, and antivirus software was soon to be considered important. John Norstad’s Disinfectant, introduced in 1989, was considered by many to be the best, though other early pioneers in the antivirus industry were also offering some of the first antivirus software on the Mac, such as McAfee’s VirusScan.

Working in the campus computer lab as a college student, I encountered my first piece of malware, a virus known as WDEF, which spread from disk to disk automatically, infecting any floppies inserted and spreading to the next Mac that used it. (The virus infected the “desktop file” present on every disk on the Classic Mac system.) Despite this, my interest in malware would not truly start until nearly two decades later.

Once Apple transitioned to the Unix-based OS X, all the old malware was suddenly obsolete. OS X was a drastically different system, viruses written for Classic systems no longer worked. On ASC, I routinely told people that Macs didn’t get viruses, thanks to my preconceived notions and lack of knowledge to the contrary, and, frankly, acted like a bit of a jackass.

Information tips the balance

At some point, someone – and I couldn’t tell you for the life of me who it was, or precisely when this happened, at this point – challenged me with some concrete information. I set out on a frenzy of research to refute his (her?) arguments. But my determination to prove that I was correct took a turn that would change my life: I learned that I was actually wrong!

Needless to say, this was a humbling experience. More importantly, though, I felt like I was glimpsing the periphery of a hidden world. I decided I wanted to know more.

Over the next few years, I believe that I dug up information on every piece of OS X malware that ever became publicly known. I knew the symptoms, the dangers, and how to remove every obscure piece of malware that nobody ever saw anymore. I started monitoring for and documenting the emergence of every new piece of malware. In 2011, I created The Safe Mac to serve as a repository for this knowledge and a way of educating people about the potential dangers.

The Safe Mac logo

I was still, at that time, a bit negative on the benefits of antivirus software. I was not nearly as rabid about it as I once was, of course, as I realized that it could provide a valuable service to some people, though I felt I personally did not need it, and that others who shared a similarly technical mindset didn’t need it either.

Adware Removal Guide

I started noticing an increase in a particular kind of malware that become known as adware, because its goal was to steal from advertisers, search engines, and other affiliate programs in general. In 2013, I knew I was onto something big when an adware company I had blogged about threatened to sue me if I didn’t remove all content about them from my website.

Genieo legal threat
Threat posted publicly in the comments on The Safe Mac

This was a particularly scary event, as this legal threat could jeopardize my family’s financial future. I ended up refusing their demands. They backed down, I breathed a sigh of relief, and I continued with my (unpaid) work.

In hindsight, this outcome probably could have been predicted due to the fact that Genieo rather amateurishly posted the threat publicly, for anyone to read. Still, this was an eye-opening event that underscored to me the idea that “adware is malware with a legal team.”

Since the adware problem had been on the rise, I was answering large numbers of questions on ASC about adware removal. In late 2013, I decided to create a set of pages on The Safe Mac that I called the Adware Removal Guide. These pages provided information to help the user figure out what adware they were infected with, and how to remove those infections.

Heading into 2014, I had learned that people had great difficulty following manual removal instructions. I do not mean to imply that they were stupid, as some would uncharitably say; they were simply unsure of themselves, or over-sure of themselves, or perhaps just not particularly careful readers. Whatever the case, I went through many iterations of my instructions, and through trial-and-error learned a lot about how to write those instructions clearly.

Creation of TSMART

TSMART code

In an ironic twist, it was the actions of that same adware company I had butted heads with that spurred me to try something different. Genieo’s adware was installing files in such a way as to render the system incapable of starting up if one file were removed without removing another. Countless people ran afoul of this issue after failing to follow my removal instructions to the letter, and some of them became very irate with me over the issue, as if it were my fault.

This, coupled with a timely suggestion from someone (who, I can no longer recall) that a shell script might be handy to automate removal, sparked an idea. Soon, the abysmally named TSM Adware Removal Tool (abbreviated TSMART) was born. This tool was written in AppleScript, compiled into an application to make it easy to run, and it automated removal of everything described in my removal instructions.

It wasn’t long before the adware makers escalated with techniques like randomizing file names, making my script more difficult to maintain. Every change required a complete update of the script, and although I built functionality to alert the user when an update was available, it just became too cumbersome.

I did a thing…

AdwareMedic logo

Thus was born the idea for AdwareMedic: an application that supported flexible identification logic coded into rules, which could be updated independently of the application itself. It certainly wasn’t my intention to build an antivirus program – indeed, AdwareMedic was specifically meant to target adware, not malware – but evolution sometimes results in two different paths to the same end.

The first version of AdwareMedic was written in a very short time – a weekend for the first prototype, and about a month for something that could be released, if memory serves. It was done as a fun project that could help some people. Next thing I knew, it had become a huge success. I didn’t have a formal way to track its usage, but I firmly believe that by early 2015 there were hundreds of thousands, maybe even millions, of Macs running AdwareMedic. I began to hear that Apple Geniuses were recommending it to people!

AdwareMedic became, I believe, the first real challenge to adware companies on the Mac platform. So much so that I saw adware responding and changing behaviors based on AdwareMedic detections. At one point, one piece of adware, called VSearch (also known as Pirrit), began fighting back by modifying the content of the AdwareMedic website when viewed from an infected machine… in the initial stages, by redirecting the Download button to the MacKeeper website.

I fought back, of course, with scripts designed to detect those modifications and show the user information about how to combat the issue. The VSearch folks escalated each time, eventually going so far as to block access to the AdwareMedic site by replacing the site’s content in the infected browser with a fake “server not found” page.

This behavior directly resulted in Apple adding rules for VSearch to the XProtect antimalware feature in macOS.

rule VSearchA 
 {
     meta:
         description = "OSX.VSearch.A" 
     condition:
         Macho and
         filesize <= 2000000 and
         ( hash.sha1 ( 0 , filesize ) =="6c6acb179b232c0f1a6bb27699809320cc2c1529" or
         hash.sha1 ( 0 , filesize ) =="cebb19fee8fd72c0975ea9a19feea3b5ce555f94" or
         hash.sha1 ( 0 , filesize ) =="1503f1d7d275e976cd94cfd72929e0409e0cf76a" or
         hash.sha1 ( 0 , filesize ) =="c50adfa949a70b33d77050d7f0e2f86bccbc25cf" or
         hash.sha1 ( 0 , filesize ) =="40346b3946d7824d38f5ba71181f5c06805200af" ) 
 }

Do you have time for a quick chat?

Next thing I knew, I got an e-mail from Malwarebytes CEO Marcin Kleczynski. I didn’t know much about them, but what I read was intriguing, and Marcin was very straightforward.

When I flew out to California for a meeting, I learned that Malwarebytes started out in an almost identical fashion. Marcin started out on forums, after having infected the family computer. He built up a foundation of knowledge, with the help of some friends made on forums, and built a product. In a million years, I couldn’t have imagined a better fit.

Once I was on board at Malwarebytes, a whole world of possibilities opened up. With AdwareMedic, I had never dared to remove certain things. My experience with Genieo made me gunshy. I simply couldn’t afford to risk a lawsuit, and yet adding and later walking back a detection would be nearly as bad, as it would show that I could be bullied into submission.

Malwarebytes does not tolerate PUPs (potentially unwanted programs), and isn’t afraid to go to court when threatened by PUP vendors. With Malwarebytes at my back, I was finally able to start doing things that AdwareMedic users had been requesting for a long time – like removal of MacKeeper!

The end…?

Thus ends the story of how I went from rabid Mac malware denier to a creator and proponent of security software. If you were to ask me to sum up with one single thing that pulled me in this direction, that thing would be knowledge. It’s easy to have strong opinions in a position of ignorance. It’s also easy to keep those opinions if you never challenge your own preconceptions. But it’s very hard to maintain an opinion in the face of contrary information, and you’ll never discover that information if you don’t seek it out.

Of course, this is only the end of the story of how I got here. I’ll have more stories to tell from the trenches in the future, as I fully intend to keep fighting the scumbags that are intent on turning my favorite platform into a cesspool of malware and crapware.

My years of research and experience in the trenches taught me an important lesson: people need help. It’s not their fault that they’re getting infected. The creators of malware, adware, and other unwanted programs are extremely good at tricking people, and they’re not going to stop. We’re slowly heading towards a world where Mac malware becomes as sophisticated as what’s seen on Windows.

Even now, not all threats involve tricking the user… sometimes, malware spreads through stealthy techniques that infect even the most savvy among the tech community. As an example, read the story of how Panic, Inc got hacked.

My request to you, dear reader, is this: spread the word. Mac malware does exist. Mac adware is just a millimeter shy of malware, and you don’t want that infection any more than you want malware. In fact, I’d willingly infect myself with certain pieces of malware before I would do the same with most of the adware out there!

Am I saying you have to force your friends and family install antivirus software? No. I believe it is a useful tool for many people, but I also admit it’s not a silver bullet. I make antivirus software, and I’m telling you my software is not, and never will be, perfect! Anyone telling you differently about their own software is lying to you.

Whatever you do, if you are able, help those you know to stay safe online, in whatever way suits them best. Just keep in mind that what suits someone best is not always what suits you best… that’s a lesson I’ve learned the hard way, repeatedly.

Odd recursive symlink bug in Catalina

I’ve been tracking a strange issue on macOS 10.15.1 since yesterday. Two people were having a problem installing Malwarebytes, and an error like the following was found in the install.log on both systems:

2019-11-01 13:14:19-06 some-imac Installer[606]: install:didFailWithError:Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory" UserInfo={NSFilePath=/private/tmp/PKInstallSandbox.XXXXXX}

While investigating, both I and a Malwarebytes support engineer both independently found the same thing on these two systems: the /private/tmp folder had been replaced with a recursive symlink, pointing back to itself. And, worse, that symlink was marked with a restricted flag, meaning that it was protected against being modified by System Integrity Protection. 😱

% ls -alO /private/tmp
lrwxr-xr-x@   1 root  wheel  restricted,hidden   11 Sep 29  2018 tmp -> private/tmp

This apparently prevents the Malwarebytes installer from working, and I’d guess (although I haven’t been able to test) that this means any installer .pkg will fail.

How to fix the problem

Testing has been difficult, as it appears to be impossible to add a restricted flag to the symlink in recovery mode. Which means I’ve been unable to duplicate the exact conditions, and so I cannot be 100% sure of the ideal fix.

In theory, one should be able to fix this by rebooting in recovery mode, opening the Terminal, and executing the following commands:

cd /Volumes/"Macintosh HD - Data"/private
rm -rf tmp
mkdir -m 777 tmp

(Note that you will need to replace “Macintosh HD” with the name of your hard drive.)

While in recovery mode, you should be able to freely delete items with a restricted flag, and you will have root permissions by default. You do have to be careful to identify the correct /private/tmp, however, as there are two. If you specify /private/tmp, that refers to a folder on the read-only system volume, which is (of course) read-only. You must make the necessary changes to the one on the Data volume.

In the two cases we observed, the fix was more extreme. In one case, the system was wiped and restored from Time Machine. In the other, SIP was disabled, the tmp folder was fixed while booted normally, and then SIP was re-enabled. So, if the above instructions don’t work, these are two verified methods that should work.

How did this happen?

That’s an excellent question! I’m still not sure. I’m guessing this is an obscure Catalina bug, but that’s still speculation.

There’s one thing the two affected systems had in common: both had installed 10.15.1 via recovery mode, and both had done a restore from Time Machine.

In one case, the user had installed 10.15.1 first, then restored data onto it from Time Machine. In the other, the user had restored the system from Time Machine, and then, due to problems and with the help of Apple support, installed 10.15.1 over that system via recovery mode.

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. 🙂

Welcome!

Welcome to the White Hat Mac website! My name is Thomas Reed, and this is my personal security-related website. There’s not a lot here yet, but it will eventually be a repository of open code and knowledge, meant to be shared freely.

Enjoy! (Once there’s more content, anyway… 😄)