Over the past few weeks, I've been putting together test hacking scenarios for a customer. They wanted to see copies of the RSA attack, the Google attack, advanced persistent threat (APT) simulations, social engineered Trojans, worms, remote buffer overflows, and more. The objective: to test what they could do to prevent all of those assaults on their predominately Microsoft Windows environment.
I put the customer's environment through its paces, and as expected, it was great fun. It certainly beats filling out paperwork and reading security policies. But something unexpected happened along the way, although I shouldn't have been surprised as I am a full-time principal security architect at Microsoft: I found that Windows 7 and other Microsoft programs were significantly harder to hack than most anyone would believe. It was difficult to perform almost any hack without disabling multiple default defenses and ignoring one or more additional warnings.
[ Master your security with InfoWorld's interactive Security iGuide. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. | Get a dose of daily computer security news by following Roger Grimes on Twitter. ]
Now, many readers will paint me as a shill for Microsoft, but if you don't believe me, try it yourself. Until then, please don't waste my time and yours reading me the Riot Act diatribe. I've walked the walk, and the results were surprising.
For example, simulating the RSA and Google attacks only worked if I was using software many years old; neither of them worked if I was using Microsoft software built in the past three to four years. In the RSA attack, employees were sent a spam email claiming to be a recruitment list. It contained an Excel spreadsheet with a link that opened a malicious zero-day Flash file (containing vulnerability CVE 20110609). The zero-day vulnerability could grant a hacker remote access, and the rest would be history.
First, as with the real attack on RSA, all spam emails were caught and placed in spam folders. Thus, employees had to first leap that small hurdle, which they willingly did. When the Excel file was opened in almost any version of Microsoft Office made in the past 10 years, the user was given a warning that the file contains a macro or script and, depending on the version, a link to an external file. The user was warned that the file may contain a malicious item. A user would have to ignore all of that to even give the malware a chance to launch. Microsoft Office 2010 opened the file in its new Protection Mode, which automatically disables the malicious code, by default.
In order to get the exploit to work, I had to disable most of the protections that Office gives, or I had to act -- as is very reasonable -- like an employee who ignores multiple warnings on purpose. In nearly every exploit, I had to disable User Account Control (UAC) and Data Execution Prevention (DEP) in Windows, Office, and Internet Explorer. Most of the exploits did not work with Internet Explorer 7 or 8.
Even when I disabled all the memory protections, application protections, and so on, warnings continued to pop up. I've always known that a fully patched Windows system was a tough opponent, but I'm here to tell you it's much more resilient than it used to be.