You may have heard people like me talk about watering-hole attacks. It’s an indirect attack on someone by compromising a third party and using that to get in. Here’s a watering hole attack example from the real world.
In this case, back in November, attackers got a Forbes ad server, and from there, attacked visitors from government and bank networks.
Here’s the logic: Since ad servers tend to be much less secure than your target company, you compromise an ad server from a site someone on the target network is likely to visit, then infect them from there. The attackers jumped to the ad network first. That put them into position to jump onto government and bank networks.
“Sophisticated” is a loaded word, but this attack showed careful planning. They got the Forbes ad server, then added malware that exploited previously undiscovered vulnerabilities in Flash and Internet Explorer. Then, when computers belonging to certain networks connected, it infected them–but ignored others, to limit the malware’s exposure in order to make it last longer.
Since Forbes is a popular site, you can count on someone from just about everywhere to connect to it. At that point it’s just a matter of waiting for the victim.
That’s why I don’t want to hear about the firewall and why I spend so much time hounding people to patch Flash and the common web browsers. Being up to date wasn’t enough in this case, but it prevents some attacks. It’s also why I pay attention to minor vulnerabilities–chaining together two minor vulnerabilities can be more effective than using one major vulnerability, because many organizations don’t bother applying patches that fall below a certain threshold.
If it applies, I want it patched, unless it breaks something in a demonstrable and repeatable way. Then we get on the phone with the vendor to find the problem–I don’t want to cause outages, but I also don’t want gaping holes in the network.
Patching helps when a patch exists. Of course, in this case the hack happened before the patches came out. But believe it or not, there are things that can help in that case too.
A browser virtualization tool like Bromium would have likely contained the attack. Bromium loads your browser tabs into separate virtual machines that are isolated from your host OS. Someone can compromise that VM all they want, but to get anywhere, they’ll have to get through the hypervisor first. I love the idea of Bromium, but Bromium is expensive and so are the PCs that are capable of running it. One cheaper option is using EMET, which is a cheap way to block some, but not all, undiscovered exploits. If the exploit uses memory corruption, EMET will help. If it’s a logic flaw, EMET probably can’t help.
Another theoretical option would be a web proxy that blocks Flash from anything other than trusted external sites. Just allow business partner sites that need it, for whatever reason. That’s not easy to implement, but the payoff is considerable.
Attackers are clever. Security has to be too.