Insecure iPhone in free fall

Last week, Alaska Airlines flight 1282 was forced to land after a “door plug” popped out of the plane. Fortunately, no one was injured, and the lack of tragedy has led to countless jokes about things like extreme exit row seating and the like.

One of the stories that has captured people’s attention is the finding of an iPhone that was sucked out of the plane and fell 16,000 feet to the ground. Twitter user SeanSafyre reported finding the phone. (If you, like me, prefer not to visit that hellsite, the post is also visible on Mastodon – an open-source alternative to Twitter – via a mirror of the SeanSafyre Twitter account.)

Finding the phone

According to Sean, he found the phone on the side of the road, under a bush. It was apparently in extremely good condition despite its lengthy fall. Although folks in the area had been alerted by the NTSB to be on the lookout for debris, he thought it was more likely this was just one that was thrown from a car or something similar.

So how did Sean learn that this was from flight 1282? Because, as he reported, it didn’t have a lock screen. He “opened it up” and found the screen showing an e-mail showing a checked baggage receipt from Alaska Airlines.

How was the phone unlocked?

The photo and Sean’s description don’t shed much light on the question of how the phone was unlocked, but there are two possibilities.

The most likely one, based on the description, is that the phone was simply not secured with a PIN or passcode. It’s not to hard to decline setting a PIN during setup of a new phone. This would mean that anyone finding it would be able to unlock the phone (if indeed you could even refer to it as “unlocking” when there’s no lock in the first place).

The other is that the phone had been set to not lock automatically, which would mean it had been sitting there with the screen on since it landed. This seems less probable, as this setting is hard to find and the battery would likely have run out by the time Sean found it.

Thus, I’m going with the assumption that there was simply no passcode.

Why should I have a passcode?

The iOS setup process encourages you to set a PIN or passcode for a very good reason: to protect your data. Lots of folks assume it’s to protect your phone, by making it unusable to a thief. However, a thief can still sell a locked iPhone for parts, and the phone itself is easily replaced. (Even if the expense means “easily” is a stretch, you’re going to be replacing the phone either way, and the phone is still more replaceable than your data.)

The passcode is actually there to keep a thief from accessing your data. The data stored on your phone is very difficult to get off of a locked phone, because it’s encrypted. A thief would have to crack the passcode in order to access any of your data, and that’s not easy. It’s even harder if you choose a 6-digit rather than a 4-digit PIN, and quite a bit harder if you use a passphrase.

Why should I care about my data?

I can quite literally hear you saying things like, “Nobody’s interested in my data.” (“Quite literally” because I’m hearing that currently from a conversation on Mastodon.) However, you couldn’t be more wrong.

Okay, so maybe you don’t do banking on your phone, and you don’t use Apple Pay, and you don’t buy apps or anything else on the phone, and you don’t have any naughty pix in your photo library. Great! A data thief doesn’t care. I mean, sure, they’d take advantage of any of that in a heartbeat, but even the most boring person in the world still has data on their phone that a thief could use.

First of all, if you use multi-factor authentication (MFA) on any of your online accounts, most likely at least some of them involve either sending you a text or sending some other kind of notification to your phone. With your phone, a thief can gain access to many of your online accounts, and use that access to take over others… including, potentially, accounts connected to you bank, your credit cards, etc.

Okay, you say, but I don’t use MFA at all. To which I’d say, that’s not the flex you think it is, but it also doesn’t mean your phone is uninteresting. What about your e-mail? Mail on your iPhone is likely full of all kinds of data that might be worth something. Further, access to your e-mail would give a thief the ability to gain access to all kinds of other accounts. And this would be a heck of a lot easier since you don’t use MFA!

Messages is also a concern, and not just because of MFA. Apple talks a lot about how secure Messages is, and it’s true… but not if the phone is unlocked in someone else’s hands! How often have you sent sensitive information, such as a credit card or a social security number, to a friend or relative via Messages? Has anyone else sent you that kind of information? Do you even remember? A thief could, for example, simply search your Messages for common credit card prefixes. (For example, Discover card numbers usually start with 6011.)

I hear you… you don’t use Mail on your phone and you’re 100% certain you’ve never sent or received sensitive info through Messages. You’re still not boring enough. Consider just your contacts, for example. Imagine a scammer just cold-calling numbers at random. They’re not likely to have a very high success rate. Such calls can be successful with certain folks – unfortunately, the elderly are one of the most common victims – but many folks these days are highly skeptical of these kinds of calls.

However, imagine what a scammer could do if they knew the names of your parents, your children, your cousin in Maine, etc. If you use the calendar, that adds more information. They know you were in Florida for spring break and that your brother visited in August. And so on. That’s a lot of information that a scammer could use to make their story believable.

If, at this point, you say you don’t use Contacts or the Calendar, along with everything else mentioned above, and that you only use it for phone calls by keying in the numbers manually… well, I’m going to give you quite a flummoxed look and ask you why the hell you have a $1,000 iPhone instead of a cheap flip phone!

So what do I do?

The answer is easy. Use a 4-digit PIN at the very least. Better would be a 6-digit PIN. Even better would be a password or passphrase of some kind. Be sure to choose something that you can remember, but that a thief would never be able to guess, even if they also stole your wallet or other personal documents. (In other words, no birthdays, no names, etc.)

Next, turn on Touch ID or Face ID, whichever your phone has. This makes it much simpler to use your phone with a longer passcode, because you don’t have to enter it as often. Some people are nervous about these technologies, but your biometric data is stored extremely securely, and is never transmitted off the device. It’s definitely not going to wind up in a database somewhere.

Also, if you’re one of the people who said you don’t use MFA… please start using MFA! Even the worst forms of MFA are better than no MFA at all.

It’s not a virus

(If you don’t read that title in your head the same way Arnold Schwarzenegger said “it’s not a tumor” in Kindergarten Cop, I’d argue you need to rethink your life choices. 😉)

I have a non-functional hot tub that needs repair, which is a problem as my wife and I are preparing to sell our house. (Bear with me for a minute, I’m going somewhere with this.)

When is a hot tub not a hot tub?

On Monday, I called a place that services and repairs hot tubs. I started to explain the issue and what we needed, but as soon as I said the words “hot tub,” the guy I was talking to interrupted. “You don’t have a hot tub,” he told me, “there’s no such thing. You have a spa.” I kid you not.

I’m sure you can imagine my reaction. I paused, trying to process what had just happened, and uttered a short “what the hell is going on here” laugh. In all honesty, there was a part of my brain that wanted to just hang up the phone right then and there.

Unfortunately, we really need the darn thing repaired, and I’d promised my wife I’d get it done, so I soldiered on, calling it a “spa.” Yet that word felt alien in my mouth, like I was talking about a place where someone might put hot rocks on me or dunk me into a tub full of mud – both exactly as appealing to me as I make them sound. Everyone I’ve ever encountered calls this thing a “hot tub.” Books, TV shows, movies, etc. It’s “Hot Tub Time Machine,” not “Spa Time Machine.”

The “hot tub” of the security world

After this encounter, it got me thinking. There’s a huge parallel between this conversation and conversations I’ve seen on security topics. I’ve seen – and, I imagine, have probably said – nearly the same pedantic phrase in another form. “You don’t have a virus, those are rare today. You have malware.”

In the security community, education of the user is of great importance. Thus, we often think that we need to correct terminology like this, to ensure the user understands. Malware is the more “correct” term these days, as the term “virus,” from a technical perspective, implies particular behaviors that most malware no longer exhibits.

However, think about my reaction when someone interrupted me to tell me I don’t have a hot tub. I felt disrespected, talked down to. If I’d been female, I’d have been justified in accusing him of mansplaining hot tubs – sorry, “spas!” – to me. (If a man mansplains to another man, is it still mansplaining?)

Now think about the results. I stuck with the conversation, but I really didn’t want to. That single comment very nearly caused that company to lose my business. The negative feelings could still affect the business relationship, if future interactions are even slightly off. I’m primed to dislike this guy, and the company he represents, if anything doesn’t go exactly right.

The same is likely to be true if you correct someone who tells you they have a “virus.” It may not be entirely logical, but human interactions seldom are.

Don’t be pedantic

The vocabulary used by security or IT professionals is very different from the vocabulary of non-technical people. To the layperson, “virus” is the term used by books, TV shows, and movies to refer to malware. This is the lens through which they see the concept.

No matter what role you have in security, it’s critical that you understand and accept this perspective. Sure, you may not like it, but that’s the way it is. If you are having a discussion with someone who thinks they’re infected with “a virus,” you’ve lost them immediately if you argue about their chosen terminology. You’ve suddenly become an adversary, rather than an ally. You may be able to come back from it, but it’ll take a lot more work.

Instead, focus on the user’s problem. Non-technical people these days are primed to call anything and everything that happens to their computer a “virus.” Help them discover the cause and fix it, regardless of what it is. Chances are, it’s not even malware at all.

Once you’ve fixed the problem, that’s your opportunity to explain the nuances to the user. At that point, they’ll be far more likely to be interested in hearing that the “virus” was actually an adware trojan, how it infected them in the first place, what threat it posed, and how to prevent it in the future.


Long story short, when you – as a technical person – have the task of assisting a non-technical person with a technical issue, it’s your job to adapt to the language that person understands, not vice versa. Failure to do that will lead to… well, failure.

macOS bugs are causing kext failures

Back in summer of 2018, customer support at Malwarebytes started seeing people with problems activating the kernel extension (kext) in Malwarebytes for Mac. This opened a can of worms that we’re still struggling with today… as soon as we think the worms are back in the can, we start finding new ones. Unfortunately, these worms all belong to macOS, and are affecting other kexts as well.

A history of previous issues

We ultimately traced the initial problem to an issue with the /Library/StagedExtensions/ folder. This folder is used by macOS in the process of activating a kext. By default, this folder is protected by SIP, so it can only be modified by the system.

Unfortunately, we were seeing that a number of users had a StagedExtensions folder that was lacking the restricted flag. (This flag is an indication that an item is protected by SIP, and can be set via the chflags command, although only from recovery mode.) This interfered with activation of the kext, since macOS no longer considered StagedExtensions to be a secure location at which to stage the kext.

The symptom of the problem was pretty easy to spot, if you knew where to look. If you run the following command (where the -O switch shows the file flags):

ls -alO /Library/StagedExtensions

The output should show this for the StagedExtensions folder itself:

drwxr-xr-x@  4 root  wheel  restricted  128 Nov  6 13:37 .

However, on affected systems, it showed:

drwxr-xr-x@  4 root  wheel  -  128 Nov  6 13:37 .

Notice the lack of a restricted flag on the folder, indicating that it is no longer protected by SIP. Of course, this flag should only be able to be cleared by the OS itself, or by a user in recovery mode. There was no reason for users to be clearing that flag themselves, and many of the users struggled with the process of setting it again, so every indication pointed to a system bug.

This was reported to Apple on August 3, 2018 (radar FB5361175), and was fixed in macOS 10.14.1, which I confirmed, and thus closed the bug report on January 28, 2019.

Later, we started seeing the issue again in macOS 10.15 and 10.15.1, and opened a new bug report on November 6, 2019 (radar FB7430509). This bug ended up being closed by Apple for the reason “Unable to diagnose with current information,” which might have irritated me, but the problems stopped again. It must have been fixed independently of our bug report, I guess…?

The current state of kext issues

Unfortunately, the problem is back yet again. This time, however, the problem does not involve the StagedExtensions folder. This time, the issue involves the folder /private/var/db/KernelExtensionManagement/, which is a newer folder that is used in the process of activating kexts on more recent versions of macOS. I’m unsure when this folder first appeared, or exactly how it is used for kext activation compared to StagedExtensions.

Affected Malwarebytes users see an error message in the app and are unable to turn on the real-time protection (RTP) features. In many cases, these users had RTP turned on previously, but suddenly found that it was off. In other cases, these are new installs where users are unable from the start to enable RTP.

Observations of affected users showed exactly the same problem as with StagedExtensions: the KernelExtensionManagement folder had somehow had the restricted flag cleared, meaning it was no longer protected by SIP. Further investigation, via the kextutil command, revealed more information:

$ kextutil -tn /Library/StagedExtensions/Library/Application\ Support/Malwarebytes/MBAM/Kext/MB_MBAM_Protection.kext 2>&1
Error making temporary directory: 1
Memory allocation failure.
Unable to stage kext (/Library/Application Support/Malwarebytes/MBAM/Kext/MB_MBAM_Protection.kext) to secure location.

On affected systems, we’ll often see this same output for a number of other kexts as well.

We’re only seeing this on 10.14.6 and, to a lesser extent, 10.13.6. We don’t really know if the issue affects Catalina as well, as Malwarebytes no longer uses a kext on Catalina, so we don’t have any data from user reports to go on there.

According to the data we’ve seen so far, all but three cases all involve macOS 10.14.6 (18G6032), which was released on September 24. The other three cases (so far) involved older systems, released this past spring or summer: macOS 10.13.6 (17G13035), macOS 10.13.6 (17G14033), macOS 10.14.6 (18G6020).

We saw a few isolated cases months ago, but have been seeing a more significant increase in incidents, starting very roughly sometime in September. So far, there aren’t enough incidents to really make any strong conclusions, other than that it looks like another macOS bug.

This was reported to Apple on October 19, 2020 (radar FB8812838), but there has not been a response yet.

A solution to the problem

The best solution would be for Apple to solve this issue. I do believe that will happen, as we’re not the only ones seeing (and, hopefully, reporting) this issue. There’s a thread on Apple’s developer forums from other people seeing the same problem.

If you are seeing this issue, or are managing machines with this issue, there is a somewhat easy fix, though it will be quite cumbersome for IT admins trying to fix problems remotely during COVID.

1 – Reboot the affected machine in recovery mode (hold command-R at startup)

2 – Enter the Terminal (from the Utilities menu)

3 – In the Terminal, enter the following command:

chflags restricted /V*/*/private/var/db/KernelExtensionManagement

4 – Reboot the machine normally

Once you have done these steps, you should be back in business.

If you’re a developer of a kext and have customers affected by this issue, please report it to Apple in as much detail as possible. The more details they have, the faster they’ll be able to find the bug and fix it.

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.


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


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


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 
         description = "OSX.VSearch.A" 
         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/\ -m provider -u -p app-password-here

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

xcrun iTMSTransporter -m provider -u -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 "" --username "" --password "app-password-here" -itc_provider "ProviderShortName" --file

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


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… 😄)