Don't discount software distribution sites as attack vectors

Sendmail. Tcpdump. OpenSSH. In addition to being highly useful software products, the Internet sites used to distribute each of these tools were compromised by attackers over the last few years.

With control of the sites, the bad guys replaced the downloadable installation package for each tool with a "Trojanized" version that included a backdoor bundled in the package. By placing their evil versions on the normal, trusted sites enterprises relied on to download their tools, the bad guys had hit upon the ideal mechanism to propagate their malicious code -- duping systems administrators to take the bait and install their wares for them.

While certainly damaging, the compromise of those sites represents just the tip of the iceberg. With all due respect to Sendmail, Tcpdump and OpenSSH, what's the big kahuna of software distribution Web sites? Why, it's Microsoft's own windowsupdate.com and the newly formed update.microsoft.com, of course. Millions of users around the globe rely on these sites to update their Windows boxes, and a compromise of these sites could cause damage on an unprecedented scale. What's more, users of Microsoft's automatic update get patches pushed to them automatically, without having to bother hitting any Microsoft site at all.

But, surely Microsoft maintains careful and diligent watch over these ultra-important software distribution channels, you must be thinking. But, stuff happens. I build a lot of Windows servers and update them regularly, as much as two or three times a week. About a year ago, I noticed a glitch in this particular matrix. As usual, I went to windowsupdate.com to grab the latest and greatest set of critical security patches for a newly built box. But, windowsupdate.com wasn't really windowsupdate.com. Instead of the familiar "Checking to see if your computer has the latest version of Windows…" message, I was presented with some bizarre text telling me that, to update my system, I had to go to the Start button and invoke a program that just didn't exist on my box. But, most important, there were no updates at all present on the site for me to download.

Something about this update doesn't look right
My first reaction: Microsoft's been hacked, or there's some DNS cache poisoning going on. While a distinct possibility, this alternate windowsupdate.com wasn't trying to push any evil software to my box. What's more, I used nslookup, dig and a whois search to check out the DNS entry. It looked OK, resolving me to a legitimate Microsoft address. The glitch lasted for an hour, after which, the "normal" site reappeared, letting me download my desired patches. I informed my fellow handlers at the Internet Storm Center about my observations. We postede a short note in the Handler's diary for the day. The very next day, about a dozen other people reported seeing this strange site as well.

So, what happened? It was most likely a Microsoft employee who mistakenly pushed a bad update to the site or its DNS record with a fat-fingered typing error. But the main point of the story is this -- for a whole whopping hour, windowsupdate.com was something else. Microsoft fixed the glitch fairly quickly and always seemed to maintain control of the site, but one wonders how long it would take them if they had totally lost control of the site to a bad guy looking to cause mass disruption.

Now, you're probably thinking that Microsoft signs that code; therefore, the bad guy couldn't sign the code as Microsoft, eliminating this issue. However, if the attackers could compromise this channel, they could load self-signed malicious code, with a forged signature appearing to be Microsoft itself. Users' browsers would present them with a warning message, exclaiming that someone named "Microsoft Corporation" is trying to push code to their systems. Untold millions would take the bait and click "OK." What's more, when you build a virgin Windows box and surf to update.microsoft.com for the very first time, you are presented with a certificate warning message automatically, just so you can run the Microsoft update packages for the first time. Users have been trained to accept such updates from Microsoft itself.

Thus, there's a significant risk here. And, not to pick solely on Microsoft, other sites could come under fire as well. Sourceforge.net, rpmfind.net, and even your antivirus vendor's update site -- all are juicy targets.

Be careful with your software downloads and updates
In enterprise environments, you've got to be careful. A bad patch [whether something created by attackers or a buggy patch from a vendor] could cause mayhem in your network. Deploy patch management systems, such as Microsoft's own Windows Server Update Services [SUS] or other commercial tools. Don't configure your Windows workstation and server machines to pull patches directly from your vendors, though. Instead, set them up to grab updates from your own infrastructure update servers automatically.

Then, don't blindly push patches to this environment. Be very careful in downloading new software and updates in the first place. Get them from reliable sources, and check their digital signatures and/or hashes if they are present. For those vendors like Microsoft who use Authenticode [Microsoft's technology for checking code signatures, built into Internet Explorer], make sure the signature checks out in your browser. Other software developers include an MD5 hash or PGP signature of their code on their site. Check these by recalculating them against the software you download from multiple mirrors of the site. Whenever I upgrade my stuff, I download a package from at least three different mirrors and verify that all of the mirrors have the same software, by comparing the MD5 and SHA-1 hashes using the md5sum and sha1sum commands built in to most Linux distributions. Of course, an attacker could compromise all of the mirrors, but at least I've raised the bar and given myself some extra assurance that my downloaded software isn't evil.

Carefully but quickly test each patch or new software package in a quality assurance environment before pushing it to your update infrastructure. In advance, define a test regimen that will let you verify your system and application functionality and performance, as well as look for telltale signs of malicious code infection [including antivirus and antispyware scans, checks for new listening network ports and evidence of sniffers]. Run through your test regimen for all updates you'll push, including software patches, configuration tweaks, and even signature updates for your desktop antivirus and antispyware tools.

Of course, these actions aren't easy. Safely applying patches can be a time-consuming task, but it is absolutely vital. By applying these multiple layers of checks of new software and then carefully rolling patches into production, you can help mitigate the risk posed by compromised software distribution sites.

Ed Skoudis is a technical editor for Information Security magazine and the author of Malware: Fighting Malicious Code (Pearson Education, 2004).