Transmission hijacked again to spread malware

In March, the website of the Transmission torrent client was hacked, and a maliciously-altered copy of Transmission was uploaded in place of the real one. That incident was very well-publicized, as the malware being distributed this way was the KeRanger ransomware, which is currently the only real ransomware ever to affect the Mac platform.

Almost exactly six months later, the story has repeated. Transmission has once again become a vector for the transmission of malware – in this case, a new variant of the Keydnap backdoor.

The recent incident was discovered by ESET, the original discoverer of Keydnap. According to ESET, the malware appears to have been distributed only since around August 28th or 29th, and was quickly taken down by the Transmission team after being notified of the issue. Thus, as with KeRanger, which was also quickly detected and taken down, the total number of people infected is likely to be small, though that’s no consolation to those few.

The malicious copy of Transmission was signed using an Apple developer certificate that appears to be owned by Igor Shaderkin, and someone by the same name has several medical apps in the iOS App Store. Assuming that this is the same Igor, it seems likely that this could be a case of a stolen certificate being used to sign malware.

All in all, this is not greatly different from the previous Keydnap variant. There are a few differences, but none are particularly interesting, other than its method of distribution.

More interesting is the fact that this incident seems to indicate that KeRanger and Keydnap may be related. Not only have they both been distributed through a Transmission hack, but there are some similarities in the code added to Transmission in both cases. It seems likely that both pieces of malware may have been made by the same individual(s), and may be reasonable to speculate that the perpetrator could have some inside knowledge that has aided in gaining access to the Transmission website.

However, there are a couple important takeaways from these incidents.

Torrent apps can be dangerous

There’s good reason to be questioning the safety of Transmission right now. One would have expected the Transmission team to have learned from the first incident and taken steps to prevent it from happening again. Although security can never be 100% perfect, it is concerning that they’ve been hacked twice in such a short period, in such a similar manner.

More generally, any time you are running something like a torrent client, you are giving a lot of trust to that program. After all, a torrent client is not only a downloader, it is also a server, designed to allow strangers to download from your computer. (Torrents are designed to facilitate peer-to-peer downloads, meaning that you download from other people rather than from a central server that may get bogged down.)

Thus, torrent apps can be a huge hole in your Mac’s security if they aren’t properly configured or have vulnerabilities that can be attacked remotely. Any app that opens up your computer to remote connections by strangers is a potentially highly dangerous app.

As you would expect, although there are ways to do this kind of thing fairly safely, a lot of that safety depends on the quality and security of the app’s code. Although I have no knowledge of Transmission’s code, the fact that the developer’s site has been hacked to distribute malware twice in a relatively short period of time does cause me a great deal of concern. This does not seem to me to be something that should easily happen to a company that is serious about security.

If you’re using a different torrent app, be very cautious about which one and how you use it. With other Mac torrent apps (such as uTorrent) guilty of installing adware on the user’s Mac, it’s may be difficult to find one worthy of trust.

Who signed that app?

To be fair, such a hack could easily be repeated with many other small Mac developers who don’t have adequate security practices. The core of the issue, above and beyond the issue of hacking a website, is that it is trivial to hack an app without most users noticing.

Mac apps are typically codesigned, meaning that the app’s code has been cryptographically signed using a certificate provided to the developer by Apple. Recent versions of Mac OS X will not, by default, open an app that isn’t codesigned. However, without third-party tools or technical knowledge, the user has no way of knowing who actually signed the app… only that Mac OS X isn’t preventing them from opening it.

Both times the Transmission app has been replaced with a maliciously-altered copy, those copies were actually codesigned. As far as Mac OS X was concerned, it was a legitimate app with a proper code signature, and the user would never know it was signed with a certificate owned by someone other than the developer.

What can the average user do about this? Although it will seem to be inconvenient, it’s important to check the certificate used to sign an app before opening it. For example, if you are downloading an app made by Adobe, it would be a good idea to verify that the certificate is actually issued to Adobe.

Another option would be to use Apple’s codesign tool in the Terminal. Simply open the Terminal app (found in the Utilities folder in the Applications folder) and type the following:

codesign -dvv

Be sure to leave a single space after the “-dvv”. Next, drag the app you want to check and drop it onto the Terminal window. This will insert the path to the app into the command. Then, simply press return in the Terminal to run the command.

The information provided by any of these methods should have information about the developer ID used to sign the app. Of particular interest is the “Developer ID Application” information. For example, in the case of a Microsoft app, it will say “Developer ID Application: Microsoft Corporation.” If the company listed doesn’t match your expectation, the app may have been tampered with. (Note that apps from the App Store will not follow this pattern, but should also be much more difficult for a third-party to tamper with.)

Signature for the malicious copy of Transmission

Of course, there are a couple potential problems with checking the signature. First, it’s entirely possible that a hacker could register a certificate with Apple in the name of a fake company, sounding suspiciously like the real company; for example, “Microsotf Corporation.” Apple might not allow such an obvious fake, but it might be more difficult to tell that it’s a fake for a lesser-known company.

The other issue is that it may not always be obvious that the signature is right. For example, the legit Transmission app is signed by “Digital Ignition LLC,” which is not mentioned anywhere on the official Transmission site.

If you cannot determine if the certificate is actually associated with the software in question, it would be a good idea to hold off on opening it and contact the company for verification.

April 3, 2013 - As researchers find more security flaws in Oracle Java, the software continues to be used for exploitation and malware delivery. This year has been a shaky start for the cross-platform web technology, where it seems the number of documented vulnerabilities is hard to number. If you recall in January, we saw a zero-day later found...

April 23, 2013 - URGENT: Despite a recent critical patch to Java SE, Polish security firm Security Explorations released details of yet another Java vulnerability. Adam Gowdiak, a researcher from the firm provides a full disclosure of the exploit here.

May 27, 2016 - Graham Cluley drew my attention the other day to an issue that has apparently been known to some for years, but was new to me: clipboard poisoning, an issue where a website can replace what you think is on your clipboard with something else. Although this seems like an insignificant issue on first glance, it turns out that there are some very serious implications.