MDJ 2020.02.20: The Weekly Attitudinal, Part 2

Why developers pay for malicious adware

While the Attitudinal was considering how to draw the distinctions between Apple’s different developer programs, it came across this pagecirculating Wednesday on Mac Twitter. The table on that page, reproduced below, makes the hierarchy of programmers rather evident.

A three-tiered system

It’s not particularly apparent in the chart, but the “Apple Developer Program (ADP)” capability is for apps distributed in the Mac App Store. The “Developer ID” capability is for other applications that are signed with a valid Apple-generated Developer ID certificate (well, the private key in the certificate, but let’s not get bogged down there again).

The “Apple Developer” capability, although it sounds like both of the previous ones, is neither: you can get this capability by merely accepting the Apple Development Agreement to download Xcode and other development resources on Apple’s developer web site. It is free, full of limitations, and Apple flatly says that programmers using this capability “cannot distribute apps.”  Of course they can, but double-clicking will not launch those apps the first time. Users will need to Control-Click on the program icon in Finder and pick “Open,” or go to the Security & Privacy preferences pane after double-clicking fails.

Even then, parts of macOS are closed to those programs. No Game Center, no iCloud access (except perhaps with the long-delayed iCloud folder sharing, if it works as a Dropbox-style folder), no in-app purchase APIS, and while they can display maps, they cannot provide routing directions.  Programs using the “Apple Developer” signing certificate cannot associate themselves with a web site to share credentials with Safari. They can’t build their own network protocols based on IP, and they cannot include VPN configurations, kernel extensions, network extensions, or use Apple’s low-latency HLS streaming protocol.

And in a glorious fit of pique, they can’t use the new “Sign in with Apple” capability either. This seems like the kind of thing that would draw antitrust scrutiny. Apple has also declared that if your app lets users authenticate with most third-party account sharing (Facebook Login, Google Sign-in, Sign in with Twitter, Sign in with LinkedIn, Login with Amazon, and WeChat login are Apple’s named examples), you must also offer “Sign in with Apple.” But as the table shows, it’s not a catch-22, because the guideline applies only to Mac App Store submissions, and those apps are the only ones allowed to use “Sign in with Apple!”

Yes, dear reader, while apps signed with a Developer ID certificate for security and verification can use most of macOS to make your life easier, they are precluded from “Sign in with Apple.” They’re also excluded from Game Center, in-app purchasing, and low-level HLS—unless they are sold through the Mac App Store, where Apple gets 30% of the purchase price for the app and all in-app purchases. They can, however, now use all iCloud services when avoiding Apple’s online marketplace. At least it no longer costs developers an arm and a leg to let you make use of a service you purchase from Apple.

Membership has its privileges

The other hidden aspect of this capabilities chart is that while the “Apple Developer” signing capability is free (and limited), the other two require the developer to pay Apple $99 (plus applicable local tax) per year. This change, implemented in the last decade, draws a psychological distinction between the haves and the have-nots in a way Apple had never done before. Even in the 1990s, when access to the top-tier developer program cost $3000 per year, programmers who were not members could write applications and distribute them without restriction. Download (or install, or copy from floppy!) a new program, double-click it, and away you went. Now that same action is pushed into a dark corner where Apple discourages exploration.

There are lots of good, valid, thoughtful ways to defend this system. $99 per year isn’t much when Xcode itself is free, given that Microsoft only allows its Visual Studio to be used for free if you’re teaching, making open-source software, or have fewer than five employees. Otherwise, everyone needs a professional license starting at $45 per month. For Apple’s $99 fee, you can make and distribute as many Developer ID-signed macOS apps as you like, charge whatever you want, and receive 100% of your selling price. If you want to put them in the Mac App Store, you’ll have to meet the store’s guidelines and give Apple their exorbitant cut.

For that price, Apple handles all payments, installations, refunds, currency conversions, updates, and provides more to boot. The company also enforces its guidelines inconsistently, makes arbitrary decisions that it refuses to discuss, and can pull the plug on your app at any time. Apple could do that outside the Mac App Store by revoking a Developer ID certificate, but the Attitudinal has not seen evidence that’s happened over an actual business dispute.

It is difficult for the Attitudinal to express how much it hates this system. Barriers to programming are bad. Locking away push notifications to those who have achieved the lofty status of “paid the fee” might keep some pranksters from flooding your sidebar, but you already have control over your notifications and can disable them if they’re obtrusive. Game Center should be more open and robust than it is, even if no one liked the iOS standalone Game Center app.

And “Sign in with Apple?” Come on, that should be available to everyone. The Attitudinal understands there are costs for these services, but shouldn’t those fees be part of the cost of providing the OS—that is, coming out of hardware sales instead of out of developers’ pockets? “Why should all users subsidize a few programs that use these features?” a corporate bookkeeper might ask. The Attitudinal might reply, “Not every app in the Mac App Store uses these capabilities. Why should developers who don’t use them subsidize developers that do?”

Anyone who can write code should be free to use all the capabilities of macOS, be able to get revocable signing credentials at no cost, and be allowed to distribute those programs to anyone who wants them. This is a fundamental tenet of a computer that wants to be for everyone.

And it will not happen. Not under any imaginable circumstances, now or in the future. And the Attitudinal can explain why in the next four words.

Adware is insanely profitable.

Let’s step back for a moment. Last week, Malwarebytes released its 2020 State of Malware Report, and gathered headlines for this item in the “Key takeaways” section:

We saw a significant rise in the overall prevalence of Mac threats in 2019, with an increase of over 400 percent from 2018. However, part of that increase can be attributed to an increase in our Malwarebytes for Mac userbase. To see if that increase reflects the reality of the Mac threat landscape, we examined threats per endpoint on both Macs and Windows PCs. In 2019, we detected an average of 11 threats per Mac endpoint—nearly double the average of 5.8 threats per endpoint on Windows.

Later, in the Mac-specific section, the report says of that 400 percent increase:

However, since you could argue—validly—that part of this was due to a corresponding increase in the total number of Mac endpoints running Malwarebytes software, it’s more interesting to look at the change in the number of detections per endpoint. Mac detections per endpoint increased from 4.8 in 2018 to a whopping 11.0 in 2019, a figure that is nearly double the same statistic for Windows. [emphasis added]

“Corresponding” in this context means “we saw five times as many things we considered threats in 2019, but we also had five times as many copies of our software running.” Similarly, there is no real way for readers to know if detecting more malware per “endpoint” (a single computer running Malwarebytes for Mac) means that there was more malware out there, or if Malwarebytes just got better at detecting it.

Or maybe it just aggressively blocked more programs. Installing antivirus software means substituting the vendor’s judgment for your own. For example, Malwarebytes says the fourth-most detected item on Macs was the “potentially unwanted program,” or PUP, called “JDI.” That’s the name the company gives to a few launch daemons belonging to TotalAV—an antivirus vendor and competitor to Malwarebytes.

There’s a lot in the report that doesn’t quite add up when examined. In the “Methodology” section, the report says: 

In addition, we focus on named threats rather than generic detections gathered by heuristics (i.e. anomalous behavior detections), as they provide little-to-no intelligence value.

But in the “Top Mac Threats” section, the company writes:

The most common Mac malware family, OSX.Generic.Suspicious, fell well down the list at 30th place in Mac-specific detections, and hundreds of spots down on a cross-platform threat list.

It goes on. The “Key Takeaways” section says the company detected 30 million Mac adware infections, adding, “The number one Mac detection, an adware family called NewTab, brought in 28 million detections itself.” But a bar chart in the Mac section (page 25) shows NewTab coming in at just under 30 million detections, but has “PUP.PCVARK” coming in at nearly 25 million detections.  If that’s the top two, then they detected a lot more than 30 million Mac adware infections. Also note that #3 is MacKeeper.

Malwarebytes calls these things “potentially unwanted” for a reason. Some of these are legitimate offerings, whether you want them or not. For a long time, you had to explicitly uncheck a box to avoid having a Yahoo toolbar installed with Oracle’s Java SDK. Oracle approved of that ad placement and put it in their own signed installers but did offer a way out. According to this ComputerWorld article from 2016, brokers who sell the ads that go in adware can get paid up to $2 per installation.

It’s no wonder that some adware developers care little about how their adware gets installed, and that leads in turn to other adware developers who intentionally mislead to get that all-important installation. These are the ones that pretend to be something they’re not—porn streaming apps, movie downloaders, pirated software, and so forth. You may have seen examples where they tell users to Control-Click on the app to open it and blindly approve anything the system may ask.

 Such code may have interest only in displaying ads and preventing you from disabling them, but it’s a small step from there to actual malware. Once code is launched on your system, it has whatever control the OS has granted it. In days of yore, this is where it could upload your contacts, your browser history, and go searching for files of interest like anything with a Quicken file type or filename extension. That can’t happen so much these days, thanks to all the permissions MDJ has discussed this month.

Nonetheless, users generally catch on pretty quickly that having to open unknown code with Control-Click may not be wise (frustrating legitimate developers who abhor the PKI signing restrictions). Malware developers really, desperately want their programs to launch via double-clicking with a simple quarantine warning. Apple, in turn, does not want that to happen—and one effective way to stop a lot of it is through making developers jump through hoops.

If regular adware is worth $2 per installation, what do you imagine that real criminals, bad actors, or “interested” foreign governments would pay for a way to run arbitrary code on a machine? The Attitudinal would bet it’s significantly more than $2. To infect computers at scale, malware developers are constantly tweaking their code, making slight changes here and there that keep the functionality intact but slip past malware detectors.

The Attitudinal is further willing to bet a good chicken sandwich or two (not that there are any here, ahem) that serious malware developers would think nothing of spending $99 to get a Developer ID certificate they could use to sign a few hundred slightly-different installers released into the world.  With just a few installations they can make that money back. Then their malware is out in the wild, infecting machines and stealing resources (if not more) until it’s detected and gets back to antivirus vendors or Apple.

The antivirus vendors can try to remove the code, but Apple can—and will—revoke certificates for such malware. That means when the infected system next gets a list of revoked certificates (probably around once a day or so), it will then refuse to launch the program. Wherever the code lives, in apps or launch items or system extensions, it has to be signed to run and it won’t run when the signing certificate is revoked. Notarization lets Apple kill a bad app immediately, and then step up to revoke the Developer ID certificate if the infection was no accident.

If you’re connecting the dots, you see the inevitable next step. Apple really does want malware to be signed! Only a revoked certificate (or, these days, notarization) can effectively kill the malware on all systems at once. Apple’s notarization efforts are opaque in the hopes of foiling some of these bad actors, but the Attitudinal would not put it past the company to be saving copies of every submitted binary, so they can be searched in the future for any newly-detected malware that’s bad enough.  That would require a lot of resources, but hundreds of $99 developer fees from bad actors can offset a lot of that.

But that means the Attitudinal’s cherished principles of open development for anyone with a machine are gone and not coming back. The next logical step in this war on Mac users is to make it even harder to run unsigned or non-notarized code. Apple’s existing security design protects users from attacks like most ransomware as long as the app is sandboxed (and the Attitudinal is quite sure that malware developers are trying to get their evil into the Mac App Store daily, too) because it can’t access files outside of its container.  Right now, Developer ID programs are not so restricted, but that could change if ransomware becomes a real threat.

Then developers would complain, and rightly so, but this has always been the way of the Mac. Computers and operating systems are only getting more complicated. End users should get to avoid that complexity wherever possible, but that doesn’t eliminate it—it just moves it to the developers, and eventually upstream to Apple. It has always been hard to write good Mac software; programmers have to sweat details that users only notice when they’re not done right. Over the past three decades, that complexity has included locking down capabilities that have been abused. And, once again, to keep the users from having to worry so much about it, developers bear the costs.

To paraphrase a maxim, the only thing worse than this system is all the other ones.