The automatic update features in many software applications are proving to be vulnerable to attack. Hackers are taking notice. You should, too.
There’s been considerable discussion recently about how automatic software updates, such as those to download security patches, can be used as potential vectors of attack. This is unfortunate, as one of the primary tenets of keeping systems relatively secure is to maintain current patch levels. And when most users, including probably most businesses, need to update their systems, they tend to trust and download the updates presented to them without confirming their authenticity.
Consider what happened earlier this year with the servers Red Hat uses to publish software packages to its users. At the end of August, Red Hat confirmed that hackers had compromised infrastructure servers used by the company and the Fedora Project. These were the servers used to actually sign Fedora software packages. And while Red Hat expressed confidence that the passphrase used to secure its software packages wasn’t stolen, it did update their signing keys.
Recently security researcher Francisco Amato of Infobyte Security Research released ISR-evilgrade — a tool used to demonstrate the vulnerabilities associated with automatic updates. Affected applications included Sun’s Java, Winzip, Winamp, Mac OS X, OpenOffice, iTunes, Linkedin toolbar, and others. But to achieve widespread success, an attacker would need to pull off a successful man-in-the middle attack. It’s possible to do that by using something like DNS spoofing, among other hijacking and poisoning attacks, or any way the attacker could get between the end user and the update server.
Dan Kaminsky’s DNS poisoning vulnerability revealed just how easy such an attack could be, by simply fooling systems and people into thinking they’re reached their intended destination when they actually reached a maliciously crafted server. Once connected to the bogus server, the user then would unknowingly download whatever type of malware the attacker wished: trojans, other forms of spyware, keystroke loggers, and bots.
Some, but not many, software vendors have taken steps to shore up the security of their auto-update mechanisms. For instance, Microsoft’s Windows Update and Microsoft Update look much more secure than many update mechanisms because Microsoft mitigates risk by signing its software updates and making certain that only Microsoft Update installs binaries from Microsoft.
Unfortunately, for most software auto updaters, there is no easy way to tell if the patch is legitimate, so users are forced to check the MD5 checksums manually after downloading the update. In addition, most software vendors use proxy servers to simplify and speed up software delivery. Though this is convenient, it also means that all an attacker has to do is compromise one of the proxy servers and place its own attack code on the proxy. In addition, there are no standard update mechanisms used across vendors, which means users can fall victim to these types of attacks, especially if the software vendor is using a non-secure protocol.
What can end users and organizations do? In the long term, it’s probably a good idea to pressure software makers to secure the delivery of their updates, and to consider signing their updates digitally. In the meantime, you should consider downloading updates manually and verifying that the checksums on the packages downloaded actually match the checksums published on the vendor’s website. Most vendors make it possible to conduct manual patch updates, though some don’t make it easy.
Next, you might want to keep an eye on what software applications running in your organization are vulnerable to ISR-evilgrade. It’s probably a good idea to turn off the auto-update features of those applications, and manually install them to your staging servers for deployment. Though there’s no easy fix, these precautions may be worthwhile, especially considering all the attention given to attacking software auto-update features.