Just when you thought things were getting boring in the security field, some twisted genius pops up with a nifty new attack perfectly capable of ruining your week. When we say "attack," we don't mean vulnerability, either -- we mean a good, old-fashioned hack.
We've seen a few of those lately, popping up out of the white-hat and black-hat communities. So here it is, folks, a run-down of three big ones that you really should be doing something about:
Problem: WPAD bug still unpatched
Ah yes, WPAD. I was fortunate enough to sit through Beau Butler's presentation on Web Proxy Auto-Discovery at the Kiwicon hacker conference back in November '07.
To say I was amazed would be one of the great understatements of this or any other century.
Butler had figured out that Internet Explorer attempts to automatically download proxy configuration files from sub-domains beginning with "wpad". So if your computer was configured as IP.yourdept.yourorg.co.nz, it'd try wpad.yourdept.yourorg.co.nz/proxy.pac. If that failed it would move up one to wpad.yourorg.co.nz. Failing that, it would try wpad.co.nz, a domain name Butler had the foresight to register.
That meant he could place a proxy file there that would configure any system connecting to wpad.co.nz to proxy through a server of his choosing. By injecting inline browser exploits (iframe etc), he'd have a very high success rate in taking control of a significant proportion (30% + at a guess) of New Zealand's workstations. That's serious pwnage.
This is a problem that affects systems attached to 2nd-level TLD's like .com.au, .org.au, .net.au, .co.in etc.
Solution: Give the monkey a banana
As Butler describes it, the WPAD functionality in Windows is like a monkey climbing a tree. It keeps climbing until it gets what it wants.
The simplest solution is to just give the monkey a banana -- configure a wpad box at wpad.yourorg.com.au and put a "return direct" proxy PAC file there. Problem solved.
Even if Microsoft fixes this issue you'd still do well to set up a wpad box -- other applications, like the iTunes competitor Winamp, various updating agents and so forth have a habit of exhibiting the same sort of behaviour.
Problem: Cached search result iframe poisoning attacks
If you're responsible for securing anything on the Web, this is a BIG one for you. Many Web-sites, in the name of search engine optimisation, tend to cache search results these days. You go to a news site and search for "oranges" and the result is cached and stored on the Web-server for indexing by Google.
It's a sensible idea, but it has an unintended side-affect: If your site isn't validating user input correctly and allows you to search for funky stuff like <iframe src="evil Russian exploit"> then you could encounter some problems.
In essence, people can use cross site scripting techniques to embed evil iframe code into your cached search results. When that search result is stored on your local Web server and cached by Google, you'd better hope no one clicks through from Google on to that entry, because it means you've just aided and abetted the bad guys in pwning an innocent endpoint. Good write up here).
The solution: Web security tactics that have been around since the Web
For God's sake, validate your user input. XSS is so very, very, very lame.
Go through your Web application code and make sure you're conducting the appropriate sanity checks on field input. You'd think the message had gotten through to Web coders. It hasn't.
If you find a problem, you'll want to consider clearing your cached searches -- your Pagerank score might take a temporary hit, but it's better than helping Hackistanis turn your customers into drooling zombies.
You might also want to consider using your border security device to sniff or block incoming packets containing strings like "iframe". You know. Just on the off chance your Web coders don't read your urgent memo.
Problem: Attacks on full disk encryption
The last couple of months have seen two extremely viable techniques pop up allowing attackers to bypass full disk encryption on running systems with mounted volumes. One technique extracts the keys from the RAM of a running machine by freezing it, the other just unlocks the screen password. Pop!
Solution: Don't be silly
A simple tweak to your security policy is all that's required here -- always use pre-boot authentication when you're rolling out full disk encryption, and make sure to instruct staff to shut down systems when they're in transit, or at the very least put them in hybernation mode -- that will unmount the disks and a user will be required to enter a password when they switch the system on again.