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 non-commercial 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.
Source: Macworld AU
Sign up for MIS Asia eNewsletters.