Lessons Learned From the Aurora Attacks

It's been more than two weeks now since the cyber-end of the cyber-world caused by the cyber-attacks on the cyber-networks of Google, Adobe and several other high tech companies, and amid all of the noise and hand-wringing there has been precious little in the way of cool, logical analysis of what lessons might be drawn from the incidents.

But researcher Dino Dai Zovi, who has spent most of his career looking for and exploiting the same kind of attack vectors that were used against Google et al., has taken a good look at the attacks and found that there was little to nothing new about them. He makes the point in an essay on the Google attack, saying that one vulnerability should not be game over for a corporate network.

One exploit should never ruin your day.  Isn’t that why we build DMZ networks with firewalls in front and behind them?  The point of doing that is so that it requires more than one server-side exploit to get into your organization.  Thanks to rich Internet client applications, it now only requires one client-side exploit to get into your organization.  Ideally, it should require around three or four: a remote code execution exploit, a sandbox escape or integrity level escalation exploit, and finally a local privilege escalation exploit in order to be able to install and hide a remote access backdoor on the system.  Also, workstations that receive e-mail and instant messages from strangers, visit random web sites, and download/install whatever software from the Internet should probably not be on the same network as something like your lawful intercept system.

That last sentence is a reference to the reports that the attackers who infiltrated Google's network were able to gain access to the system that Google uses to provide data on its users to the government and law enforcement agencies. That's not something that most enterprises have to worry about (at least for now), but the point is still worth considering. Take the time to look at the separation of duties and privileges inside your network and see whether there are ways to isolate access to sensitive data. In other words, don't make life any easier for the attackers than it already is.

Commenting on this Article is closed.