A fundamental problem with distributing software is distributing trust as well. When we download an app to our mobile devices or computers, we want to know that we’re not accidentally installing malware, adware, or the like. Apple has mostly taken care of this problem in iOS by restricting downloads to the App Store.
Developers have managed to bypass Apple’s protections in some limited cases, as with the “ZergHelper” approach. And researchers have found some obscure pathways—now patched—that could be used by malicious apps that appeared innocuous to get approved and then grab data from other apps.
Late last week, we saw what seemed to be a peril of a more widely open frontier—on reflection, it’s a different horse altogether. Transmission, a BitTorrent client that hadn’t been updated for two years until February 28, had its 2.9.0 client compromised on March 4. If you downloaded or used the in-app updater to install 2.9.0, delete it immediately. Version 2.9.2 is ostensibly safe and also removes the malicious files. Also, read this blog post by the research firm that discovered the infection if you launched version 2.9.0 and follow its instructions immediately. Apple has also updated its virus database.
Typical ways of knowing that an app had been suborned didn’t work. It was on the developer’s official website. It had been distributed for days before the compromise became known. There’s still no information about how the download was swapped out or the site taken over, and thus we don’t have a lot of assurance that future releases will remain safe. And the modified app was signed by an Apple-issued developer’s certificate for a firm in Turkey. Apple revoked that certificate, but we don’t know anything yet about how it was used maliciously.
Checksum but verify
On other platforms, past and present, you can verify that a software download wasn’t tampered with in transit by using what’s known as a checksum. Such a value is a short output from a cryptographic algorithm that takes the contents of an original document and runs through a large series of mathematical operations. If the original file is changed by even a single bit, running that same “hashing” operation produces a dramatically different result. The developer posts checksums in one or more popular formats on the download page, allowing a closed loop.
The trouble is that most software compromises occur as they did with Transmission: A website or other distribution method is hacked and has a file replaced. Even if the developer’s posted checksum matches the downloaded package, that could be because a site was hacked and the checksum updated on that webpage. And changes can sometimes be slipped in during development of open-source or proprietary projects that lack close oversight, allowing a seemingly legitimate version of a product to get into the release cycle.
Apple uses a digitally signed form of cryptographic verification for downloads via the App Store in OS X. It even offers instructions on verifying downloads you make manually from its site. It also allows developers to use an Apple-issued certificate to sign downloads that developers host and distribute themselves, providing a similar benefit. But this doesn’t help when a developer’s certificate is hijacked, as with Transmission. (Last May, my colleague Jeffery Battersby wrote an excellent rundown on Apple’s techniques.)
Apple’s approach does prevent most lines of attack. Coupled with that are its abilities to update XProtect (as noted above, its silent virus-signature database) and to revoke developer certificates.
What can the average user do to prevent something like the Transmission situation? My frank answer is: precious little. However, the flip side is that this kind of exploit occurs remarkably rarely, and the circumstances known so far about this one don’t indicate that there’s a newly discovered pathway to carrying out similar swaps.
And it’s a bit perverse that this malware wasn’t embedded in unsigned Mac software, but in a package that wouldn’t set off any alarms. This is almost a Trojan horse nested inside another Trojan horse.
The broadest lesson you can draw is that developers generally need to make sure they are monitoring and closing loops internally. In this case, automated software that would check that a file remained unchanged and with a known checksum would have alerted the folks who run Transmission.
Without tarring all open-source and other noncommercial or free software projects with the same brush, the best advice I can offer is to hold off a week or a few weeks when less-active projects post updates, just to be sure that enough time has passed for proper scrutiny. This injection of ransomware into Transmission will also spark more scrutiny by developers, security researchers, and even casual users.
Author: Glenn Fleishman, Senior Contributor
Glenn Fleishman’s most recent books include Take Control of iOS and iPadOS Privacy and Security, Take Control of Calendar and Reminders, and Take Control of Securing Your Mac. In his spare time, he writes about printing and type history. He’s a senior contributor to Macworld, where he writes Mac 911.