On March 4, we detected that the Transmission BitTorrent client installer for OS X was infected with ransomware, just a few hours after installers were initially posted. We have named this Ransomware “KeRanger.” The only previous ransomware for OS X we are aware of is FileCoder, discovered by Kaspersky Lab in 2014. As FileCoder was incomplete at the time of its discovery, we believe KeRanger is the first fully functional ransomware seen on the OS X platform.
Attackers infected two installers of Transmission version 2.90 with KeRanger on the morning of March 4. When we identified the issue, the infected DMG files were still available for downloading from the Transmission site Transmission is an open source project. It’s possible that Transmission’s official website was compromised and the files were replaced by re-compiled malicious versions, but we can’t confirm how this infection occurred.
Fascinating hack – they basically compromised the Transmission website to upload infected installers. And it worked, too.
Update: Apple has shut down the exploit by revoking the compromised app’s certificate.
I’d actually brew updated over the week-end, but luckily the brew cask guys still haven’t found an elegant solution to seamlessly update the GUI-based apps along with the rest of homebrew… so the 2.90 version was still waiting for me to install it, one brew cask –force install away.
This is a bit scary really, and made me realise that I implicitly trust whatever I install via homebrew like I’d trust apt-get or pacman on my linux-based machines (I’d honestly never given it much thought before).
Not that the linux package managers are completely impossible to compromise, mind you (Ars had an article on this very subject recently: http://arstechnica.com/security/2016/02/most-software-already-has-a… )…
True, but it is much more difficult to compromise a package maintained by a particular distribution in its own repositories. Most distributions maintain a strict process where new versions of software are vetted for stability and security before they are provided as an update to regular users in the primary repository. Debian for example has three levels of such repositories: Experimental, Unstable and Stable. It would be highly unlikely that an upgraded package would pass with an undetected security vulnerability into the Stable repository. Ubuntu and Linux Mint have similar hierarchies.
If it makes you feel better, once GNU/Linux becomes enough of a target you’ll have to worry about it there, too. This is a nasty shock for a lot of Mac users, who for years have counted on the “security by obscurity” guarantee of their platform, despite warnings that it wouldn’t last.
Personally I think anyone who creates ransom-ware like this ought to be taken out back and summarily shot once we catch them. But we don’t get everything in life.
In principle it looks very similar to the recent linux mint site compromise – only there the links were replaced instead of files.
It seems websites are getting to be a weak point in software distribution, to the point that, maybe, they need 24 hour/day (automated?) monitoring of download links and files.
Edited 2016-03-08 03:54 UTC
emphyrio,
Maybe they should, but automated monitoring can be fooled. Assuming an attacker knew about them, they might actually monitor the monitoring agents from the server and give them the information they want. It’s a good question whether they’d be able to detect one another.
I think the protection needs to come in at the server level. You could try to setup some tripwires and hope the hackers activate them.
For a static site, one might provision a new VM every hour that’s a clone of a clean VM. If there are any changes after that period there’s a good chance it was a hacker, and you could keep the VM as evidence.
I would mount a read only filesystem with the required files, so there’s no way to write to it, whatever the vulnerability.
Not really practical, unless you’re willing to take the web site offline for even the tiniest of changes. I might secure certain pages this way, such as the downloads and the files relating to them, but to do it for the entire site just introduces too much maintenance. And, as long as doing it for the whole thing is impractical, attackers would simply shift their attack surface to something else–loading ransomware via something such as a Flash exploit through an advertising network, for example.
You can remount an ro filesystem rw, when you update no need to take things offline
And how, then, do you remount it ro again without taking files offline, given that the files are in use? The error message, by the way, is “device or resource busy”.
Use optical media then.
Thankfully, I’m lazy and don’t like to wait for the upgrade to finish, click additional buttons, etc. So the many times it asked me to upgrade I declined.
Unfortunately, happenings like these only illustrate why sandboxing is becoming so necessary.