(I’m beginning to think someone out there doesn’t want me to finish posting entries for the conference sessions — this time SBC lost DSL routing for half the San Francisco Bay area for nearly 20 hours. Sheesh.)
This talk was packed to the gills, and really should have been in a larger room. I wonder if this was true for the rest of the security track, which seemed to be consigned to the smaller E meeting rooms. (Hello, O’Reilly? The SANS schedule alone ought to convince you that it’s probably a topic of interest to more people than can fit in E144!)
Nitesh is a security audit manager at E&Y, and made the decision to prohibit his team from using any closed source attack and penetration tools. [EDIT: Originally listed some more detail here, but that information actually was a from a different talk that I had accidently merged in my notes.]
He started by listing the standard attack and penetration phases: Discovery, Scanning, Enumeration, Vulnerability Exploit, and Rootkit/Log Cleaner Install.
For the Discovery and Scanning phases, he described several ways to use Google to find enormous amounts of information. Using Google for this has several advantages: searches are much faster than direct scanning attacks, searches don’t tip off the target by making a connection to them, and Google’s cache can provide detailed information about the target that would not be available from stealth scanning.
As sample Google searches, he suggested intitle:”Index of” admin and “VNC Desktop” inurl:5800. Webcam index pages and error messages also have distinctive, easy to search for signatures; one of his oreillynet.com articles has more detail on this technique.
For direct scanning of the target, Nitesh suggests Nessus, which he points out is far more than just a standard vulnerability scanning tool, but rather a framework for writing scans, with a scripting language of its own (NASL).
Nitesh recommended not using off-the-shelf exploit scripts, as often as not they are really just disguised malware that attacks the script user, installing a back door for the “exploit” writer’s enjoyment. (I’ve never downloaded an exploit myself, for precisely that reason. Mmmm, paranoia . . . .)
He took some time to impress on everyone the seriousness of cross-site scripting attacks (which prey on failure to encode HTML sent to the browser properly), by exploiting a badly-written shopping-cart app to give himself any price he wanted for any item. As he pointed out, the cart app in question has been known vulnerable for years; it’s just criminal that the responsible company hasn’t done anything about it. To give an idea of how often these types of bugs are exploited in the real world (usually for phishing attacks), he pointed out that at least one large bank sees 10-15 distinct new phishing attacks targeted at their customers every day.
He then went through a number of other useful tools to keep in your toolkit:
- Blind SQL injection
- BURP Proxy
- Acts as a special proxy that allows you to manually edit HTTP requests and responses on the fly
- Point, click, root
- Network Man-In-The-Middle attacks
- Web server testing, including automated Google scans
- Live Linux distro with all the A&P tools you want
He also made a pitch for his O’Reilly book, Network Security Tools. [EDIT: There was originally a block in here about reporting UIs, but this was actually part of a later talk that I had accidently merged in my notes.]
All of that was good information, but I expected the session to be details on how the sneakiest new attacks actually worked, rather than basic info about current toolkits for vulnerability assessment, peppered with occasional bits of wisdom won on the battlefield. Perhaps next year.
What’s your favorite network security tool or toolkit?