Security Samizdat

There is an interesting article by Scott Berinato at CSOonline about the widespread use of “antiforensics” tools, and how they are changing the information security landscape in general, and the forensics practice in particular.

This is antiforensics. It is more than technology. It is an approach to criminal hacking that can be summed up like this: Make it hard for them to find you and impossible for them to prove they found you.

The concept is neither new nor foolproof, but in the past 12 months, forensic investigators have noticed a significant uptick in the use of antiforensics. This is not because hackers are making more sophisticated antiforensic tools, though some are. Rather, it’s because antiforensic tools have slid down the technical food chain, from Unix to Windows, from something only elite users could master to something nontechnical users can operate. What’s more, this transition is taking place right when (or perhaps because of) a growing number of criminals, technically unsophisticated, want in on all the cash moving around online and they need antiforensics to protect their illicit enterprises. “Five years ago, you could count on one hand the number of people who could do a lot of these things,” says the investigator. “Now it’s hobby level.”

The article describes some tools currently used, such as Timestomp, Slacker, Sam Juicer, etc. and how the “arms race” has moved from the disk to memory.

It would seem that the forensics practice is currently sitting at the bottom of a “trough of disillusionment“.

Some months ago I prepared a presentation about “Forensics in the Corporation” (sorry, only in Spanish!) which should have been really called “Why everything you learned at forensics training won’t be really useful in the real world”. And I didn’t include anything about antiforensics, just focusing on the technical, political and organizational challenges that big corporations pose to the forensics investigator.

The forensics practice is much too focused around the PC world. That is, you normally have physical access to the “suspect” machine, you can power it off or unplug it from the network, hard drive sizes are reasonable, and some expectations are always met. That is fine. This kind of forensics work… works! But mostly in the workstation/laptop world.

What about servers? Virtualization, huge storage capacities (SAN, NAS, RAID arrays, etc.), distributed systems (as in “distributed all over the world”), business critical systems that cannot be unplugged or turned off (come on, in how many LOB servers could you do such things?)

I’m sure the forensics practice will evolve in the following years. I’m sure it’ll be damn interesting to see.

Let’s assume you have the usual “defense-in-depth” security architecture in place. Anti-virus software, perimeter firewalls, machines properly hardened, non-admin users, etc.

Let’s also say you have a serious malware outbreak today. Wait, make that tonight. Your sysadmins call you at night and tell you several thousand clients and servers are infected with something that sneaked past the AV software. What do you do? Do you have a procedure?

These things happen. You might have the best security architecture, follow best practices, have top consultants evaluate your risk periodically, the whole thing. But when push comes to shove, does everyone know what to do? Do they have the tools to do it?

This is a simple checklist. It probably isn’t very complete. But it’s wise to at least think about these questions before lightning strikes. In no particular order:

- Do you have alternative malware cleaning tools?
- Do you have malware-cleaning tools that can run from a bootable CD?
- Do you have admin-level access to all involved machines?
- Can you reach machines in remote locations?
- Do you know the current admin passwords?
- Are there people available with physical access to the machines in remote locations?
- If you have to re-install / re-image some boxes, do you have the relevant installation media?
- Do you have the phone numbers of the important vendor’s support service? Is it 24×7x365?
- Do your operators know how to react? (yes, I know you have a Incident Response document somewhere, but have people actually read it?)
- Do you have access to someone that can take drastic decisions if needed?

Or would all this make life too easy for us? ;)

The ATLAS Dashboard has become my first-pageload-of-the-day of lately. Together with ISC from SANS, of course. It is interesting, not only for the information about the attacks going on, but also because it puts in perspective the relative rates of occurrence of different threats.

You see, of the top 5 attacks in the Internet right now, 4 of them are related to Windows. Nothing new here. However we find that they are expliting vulnerabilities which are between 3 and 6 years old!

Come on, the top attack is related to a SQL Server Buffer Overflow from 2002!! and the fourth attack is related to a IIS vulnerability from 2000!!

The Security community is well aware of the need to:

• Patch!
• Block unwanted traffic from the Internet (that includes SQL, NetBIOS, SMB, etc)
• Patch again!

Just by following these simple rules (which even a trained chimpanzee would be able to), nearly 100% of the attacks would be prevented, and the security guys would be able to focus on the really tough ones.

It’s not superhackers we are up against 99% of the time. As they say, there is no patch for human stupidity.