As we’ve all read, Google recently experienced a massive attack on its network, probably from China, and has threatened to leave the Chinese market as a result. I’ve written about that aspect before (Google taking its ball and going home) but this column is about the attack itself and Google’s internal plans for how to deal with future such problems, because of course this will happen again. I’m frankly trying to understand what Google is up to in its response to the Chinese threat — a response that doesn’t make much sense to me given the details of the attack as published.
First reports of the attack blamed a security flaw in an attached PDF file. Later reports blamed a vulnerability in Microsoft’s Internet Explorer browser. Adobe denies the PDF vulnerability, though the company not long ago issued a security patch for that product. Microsoft confirmed the IE vulnerability. But what’s interesting to me is that I understand from inside Google that the company plans to respond to this Chinese threat by changing its log-in process for web apps to one using a secure secondary server. That’s great, but it wouldn’t have stopped the most recent attack.
Is there something here we aren’t being told?
The most popular secure secondary server access system is called SiteKey and is used by Bank of America and many other financial institutions. The way SiteKey works is you log on to your bank’s computer, for example, by first typing an account identifier which causes one server to generate a picture and another server to generate a pass phrase which together don’t identify you to the bank but rather identifies the bank to you. Trapped as it is in a hash table, nobody at the bank can even tell you what picture you chose but you know it (the pass phrase too) so you can be pretty sure the server you are logging into is the one you want and not some phishing site. If the picture and phrase are satisfactory you can then type in your real password and you are there.
I’m told that Google will soon roll-out a similar system for Google Apps.
But I can’t see how using secure secondary authentication would have had any impact at all on the recent Chinese malware incident.
So I went to a friend who manages data security for a huge defense contractor and he agreed. “Authentication helps, ” he said, “but that was the second part of the attack, the original piece was a carefully crafted PDF file that was executed by the user. No amount of authentication helps against an authorized user. Don’t get me wrong, I am a believer in strong X. 509 based authentication, just it would not have helped against a malicious attachment.”
Adobe says it wasn’t a PDF problem at all. Yet my friend, who is privy to a flow of information the rest of us are not, says Adobe may be technically incorrect in this assertion. I don’t know for sure, nor do I think it really matters in this case.
“The IE use was a secondary effect (to download the malware using an allowed program), ” he explained. “I’m not sure what they are calling a vulnerability (it might be a feature). The initial vector was the PDF. Typically such an attack is limited in just how large a program can be in the initial attack (hidden inside the attachment). It has to be just enough to pull the real root kit. Early ones used their own network app but most systems are now protected by personal firewalls that would disallow or alarm. Use of IE would probably avoid this (and explains why large corporations are going to gateway white lists). Bottom line: the attack requires an executable program to be running on the workstation. Once that is in place, anything can be done. ”
The best defense against this sort of attack would have been two-fold. First, strip all e-mail attachments from messages and replace them with a URL. Send one copy of the attachment to a dedicated server that can be set to paranoid. Take as much time as needed to vet the attachment including emulation to see if it is malware or not. Once complete, the URL embedded with the forwarded e-mail becomes active and the attachment can be downloaded.
Google owns Postini, which could implement just such a technique, so we should probably expect that they will do so, making Google apps more secure and therefore more attractive in the process. In Google’s move to make itself ever more essential to the net they may well offer such a quarantine service as a standalone product, too.
The second part of this solution unfortunately died with Windows Vista — the hated User Access Control (UAC). Temporary privilege escalation with logging, which is what Vista’s UAC provided along with some user grief, is the way to go.
Remember that all the authentication in the world will not protect against a privileged user doing the wrong thing. It’s just that logging may help to determine what happened after the fact.
We have known for years how to fix this, but nobody cared.