Friday, April 11, 2008

More Aggressive Network Self-Defense

Some of you might remember this book from my 2005 review. I thought of it after reading Security Guru Gives Hackers a Taste of Their Own Medicine. From the article:

Malicious hackers beware: Computer security expert Joel Eriksson might already own your box.

Eriksson, a researcher at the Swedish security firm Bitsec, uses reverse-engineering tools to find remotely exploitable security holes in hacking software. In particular, he targets the client-side applications intruders use to control Trojan horses from afar, finding vulnerabilities that would let him upload his own rogue software to intruders' machines.

He demoed the technique publicly for the first time at the RSA conference Friday.


You might remember a similar story from Def Con 2005:

New research released at the DefCon conference suggests that not only is it important to apply patches to fix security flaws in commonly used computer software, but that patch installation is important for the very tools hackers and security professionals frequently use to break into (or test the security of) computer networks.

According to new findings by the venerable hacker ninjas known as the Shmoo Group, some of the most popular tools used by hackers and security professionals to infiltrate and test the security of targeted networks contain serious flaws that defenders could use to turn the tables on hackers.


Three years ago in my post about ANSD I wrote:

I disagree with the strike-back idea, as I believe it steps over the line into vigilante justices.

I'm less sure about that now. In the three years that have passed, security has gotten worse, government ability to deter and/or defeat intruders has not improved, and intruders have become more sophisticated. If we continue to sit on our hands waiting for the cavalry to arrive, it will be too late. (It already is too late for most companies anyway; they're owned.)

Disruption of the command-and-control mechanisms used to control compromised hosts is not something I recommend for everyone, but it would certainly push some attackers off-balance. They would suddenly start to incur some of the same costs that defenders spend on trying to develop more secure software. I think it's time for some of us to consider these offensive techniques.

Incidentally, the ActiveResponse.org site I mentioned in 2005 appears to be collecting links to papers and studies on active response.

5 comments:

Michael Janke said...

Disrupting command and control has a long term down side. The bad guys will figure out they've got weaknesses and will close the holes and improve their own security. The result will be that command-and-control infiltration and disruption will, over time, become more difficult and less successful.

When Allied cryptographers in WWII 'infiltrated' enigma, their top priority was to make sure that they didn't take any action that would indicate that they were intercepting German communications. Their success was first in breaking the various ciphers, and second in keeping secret the fact that the codes were broken. The second success was what made a difference in the outcome of the conflict. They successfully disrupted the war, not the communications network.

I believe that infiltration of command-and-control has great value. But the infiltration must be conducted such that the target has no knowledge of the act. The infiltration should be used to mitigate the effect of the botnet on the botnets targets, but not necessarily to disrupt the botnet itself.

Anonymous said...

Richard,

I too am torn on this issue. Sitting back and watching targeted attacks at my company and not being able to do anything proactive to counter them is extremely frustrating.

AT one time I thought that I was helping by providing the malware captured and dropped at the gateway to my anti-virus vendor and receiving custom patches was effective. When I thought about it, I realized while this helped, it was reactive. A simple change in the size of the file or the location within the file where the malware code executed would render the signatures worthless.

So - I continue to search for what I can do legally to protect the company and what proactive measures there may be for me to use against the systems and hopefully the people attacking my networks.

Alex Muentz said...

A major concern about aggressive/retaliatory approaches is the potential legal liability.

Here's a little hypo.

Attacker Alan uses Bob's compromised PC to attack Charlie's network.

Charlie sees the attack coming from Bob's PC, compromises it and either cripples it or accesses user data to determine who owns it.

Charlie has now committed prosecutable acts, and since he's both visible and with deep pockets (his organization), he's more likely to be sued/prosecuted than Alan.

There isn't much precedent on this (in the US) yet, so I can't reliably estimate the risk.

Right now, the safest approach is to defend one's own network and alert the responsible ISP, which may be able to throttle/disconnect the offending hosts.

Anonymous said...

From what I've seen: Governmental organizations (both in the U.S. and in Europe) are doing a lot of work figuring out how to deal with this. But there are a lot of troublesome areas, like borders. How would for example Turkey consider an attack by the U.S. military on a command and control center hosted hosted in Turkey? Is there any legal difference in an attack done through cyberspace than an physical attack?

Personally I think the situation is going to be even worse before we see any improvement. And when we see the improvements, they comes as a result of us (as in the good guys) changing the rules. All I hope for is that the pendulum don't swing too far the other way when that happens...

LonerVamp said...

The line of vigilantism is one reason I still think there is a strong perimeter in our networks. If someone is physically inside my nework, he'll show up as a rogue system, and I have no problem doing anything in my power to identify that system or disrupt anything bad it might be doing.

Sure, we have more endpoints floating away from the nest and more holes for remote trusted partners and more emphasis on the data, but I don't think any of that predicates the disappearance of the perimeters.