Day 5: ITSM Vulnerability Assessment techniques
Lesson 5:After the first week, many of these assessment techniques don't all fit together or seem congruent. Mid next-week, I think a lot of these pieces will start to come together to form a big picture. The recommendations I've given so far are not things I've seen or heard from the community of security professionals. Many people are asking for examples, but my question is -- what exactly do you want to delve into? If anything, I would rather spend my time introducing the concepts so that you can explore the details for yourself.
Part 1: Information assurance vulnerability assessment — Secure channels
There has been constant debate about how to create a secure channel over a network, especially say, the global Internet. The two leading systems are SSL and DNSSEC.
SSL has had various problems over the years, but it's the top dog. DNSSEC will likely never become popular, and the complexity behind it rivals IPSec. SSL VPN has all but replaced IPSec today as well. SSH is in use but isn't seen as a consumer-level technology, not even with SSHTerm / Ajaxterm. Other abominations such as SNMPv3, S-BGP, and Kerberos-enabled protocols, encrypted IMAP/POP3, et al -- these are bound to be around and unpopular for another ten to twenty years.
Off-topic and unrelated, yet on my mind as I write this: I can't believe that people still use TFTP for router/firewall images and configurations. I'm sorry did I say, "people still use"? I meant, "vendors left implemented for over 13-14 years because that's how long SSH and SSL have been around for".
Drive-by-pharming, which involves using CSRF (possibly aided by XSS or other attack vector) to modify Intranet/home routers and firewalls, often changes the router DNS servers. DNS hijacking in this way could create a situation where browser rootkits are always installed on Intranet users' browsers universally. RSnake's Using DNS to enable XSS and the subsequently linked LURHQ paper are must reads.
Similarly, DNS cache poisoning can cause the same effect. ARP cache poisoning, ditto. We've seen BIND 9 exploits and ARP spoofing malware throughout 2007. The only interesting defenses in the research community have also ended up in failure, as seen by the PRIV8 SCM Firefox Add-on. It appears that this research has been duplicated by OpenDNS and DNSstuff, as I recently read in this article from Dark Reading on Hacking a New DNS Attack.
Sure, there are issues with Firefox add-ons (which I knew about the first time I installed an extension). I love how every security professional thinks their research is new when they apply an old concept (e.g. arp cache poisoning) with a bleeding-edge technology (e.g. Firefox add-ons).
Recommendation: There were plenty of exploits available for both Microsoft's DNS server and ISC BIND last year. Do you want to repeat the same mistakes and headaches this year? Consider alternatives, or push vendors to provide reliable DNS server software that has high assurance properties. CoDoNS is an interesting research project that needs more attention and support.
Every book worth it's weight on network security and system administration has a section on DNS server security. Go read that section now. I also suggest reading Domain Contamination from Amit Klein.
Monitor your DNS servers. I also suggest monitoring external DNS and co-operating with other organizations to form a strong passive DNS infrastructure for replication. Recently, source code was released for dnslogger-forward in order to create sensors for this purpose.
As for SSL, I'm getting quite upset about what once was a great technology. I mean, what good is it when browsers have serious problems that remain unfixed for years? Please be sure to read heise Security's article on Bugs in Mozilla browsers facilitate man-in-the-middle attacks. Try out the test page that they link to and see the problem for yourself.
Certificates are a nuisance and all of this is being wrapped up under the umbrellas of liability and Certificate Authority god-complexes. Sure, SSL works today and DNSSEC doesn't, but I'm pretty sure both are wrong and we'll see the demise of both over time. If anyone besides myself thinks that Enigform and mod_auth_openpgp are the future of secure HTTP channels, please holler.
For more information, you would think I'd recommend DNS & BIND, but it turns out that one of the authors is a spammer (yes, Cricket Liu is an evil, bad spammer -- how's that for irony?) and BIND software just plain sucks. Instead, I suggest you read "The dotCrime Manifesto", by Phillip Hallam-Baker.
Part 2: Software assurance vulnerability assessment — Reflected XSS
Best Reflected-XSS scanning tools
XSSscan.py, XSS-Me, HttpBee, Acunetix XSS Scanner, Syhunt Sandcat, w3af, Wapiti, OWASP CAL9000, Wfuzz, Grabber, SPIKEproxy, WebFuzz, Gamja, Burp Intruder, Burp Repeater, Paros, OWASP WebScarab, screamingCSS, gunzip webfuzzer, N-Stealth Scanner Free Edition
I'll cover Stored-XSS, DOM-based XSS, and XSS attack helper tools next week! I will go into more detail about finding XSS once more techniques/tools are suggested. Here's a few suggested tools to play with over the weekend.
I don't usually repeat tools if they aren't particularly interesting for helping individual attacks. However, you'll want to go back and review how Reflected-XSS can be found using HTTP request tampering tools or browser-based tools. In the case of Reflected-XSS, these can be found in both parameters and forms, as well as in binaries (UXSS), emails, images, QuickTime/Flash and other media files, and pretty much just about everywhere.
blog comments powered by Disqus