Day 2: ITSM Vulnerability Assessment techniques
Lesson 2: We hope that you are enjoying the format of these, as well as the content. Yesterday, I talked about how rogue AP's/clients can be scanned for without adding infrastructure or spending active time walking around the office. I also introduced software assurance tools, including most of the popular and best browser-based tools. Browser-based tools can really get you started with learning how to approach testing for web application vulnerabilities -- whether or not you plan on using code inspection or a purely black-box approach.
Part 1: Information assurance vulnerability assessment — Kernel protection, network drivers
Once when I was performing a full network vulnerability assessment, the client asked me, "What is the worst that can happen from a WiFi attack?". We talked about how easy it was to break WEP and WPA, and I mentioned how this could be done using Rainbowtables, as well as using injections to speed up the traffic (or that small packet traffic such as ARP could easily be predicted) including a discussion about OpenCiphers' use of relatively cheap hardware to perform NSA-grade attacks.
However, this was not the end of the discussion. I then spoke about how some WiFi drivers have had problems, including the FreeBSD 802.11 Management Frame Integer Overflow vulnerability, discovered by Karl Janmar. I made the assumption that many WiFi drivers could be vulnerable to remote root upon boot.
One of the best initial ways to perform a vulnerability assessment on unknown code such as WiFi drivers is to utilize binary analysis. These sorts of rough tests can provide information that is not normally available. Using tools such as GDB, IDA Pro, OllyDbg, and ImmDbg isn't available for system drivers at runtime, so other tools such as KGDB, SoftIce, RR0D, and WinDbg must be used instead. Some tools such as bugreport might also be able to be used, assuming you can also have objdump produce a disassembly. Just poking around can produce a lot of useful information on where to start with other kinds of vulnerability assessments, such as using CAPEC to model attack-paths or moving to other techniques such as reverse engineering, static analysis, and dynamic analysis.
Other software such as BinDiff can be extremely useful to identify areas of code in binaries that change over time. Particular useful is to utilize BinDiff and IDA/HexRays to identify weaknesses in WiFi drivers after a patch to a vulnerability is released. Fuzzers aren't usually specific to WiFi, although there is at least one 802.11 fuzzer. The vulnerability research community has mostly adopted scapy for this purpose. I suggest also checking out file2air and UTScapy.
WiFi drivers present a unique problem for vulnerability research. Their closed-source is often a contention point, especially from the OpenBSD camp. Great projects such as WVE produce content on wireless vulnerabilities. However, because of the complexity and importance that these drivers maintain the highest assurance levels -- I firmly believe that we need more. I would like to see both a CAPEC-specific wireless attack-path classification (similar to WASC TC), as well as a WiFi driver weakness program similar to CWE or OWASP T10-2007. This should be driven by the vendor community, who should provide open standards for pen-testing AP's and drivers.
Theo de Raadt has been a proponent of both open drivers and open documentation. Clearly, both open documentation and source code would allow at least some third-party selective review. Vendors of all WiFi software/hardware should also open their documentation, hardware, and software for third-party selective review. If you are a big client to one of these vendors, please push them to these ends. In order to prove the need, consider fuzzing before purchase.
Recommendation: Use hardened WPA2 to protect your WiFi clients. WPA2-Enterprise is simply too complex for most needs -- consider using HostAP with per-MAC WPA2-Personal PSK's, or other AP that provides such support. Make sure to make the SSID and PSK for every AP/client as random and long as possible. Regularly scan Windows WiFi clients using WiFiDEnum from Aruba Networks. For further information, please check out the books, "WarDriving and Wireless Penetration Testing" (especially the last section on Device Driver Auditing), and "Hacking Exposed Wireless" (by Johnny Cache and Vinnie Liu).
Part 2: Software assurance vulnerability assessment — Crawlers and spiders
Best HTTP crawlers
Burp Spider, Paros, OWASP WebScarab, w3af, larbin / FEAR::API, Heritrix, wget, curl, Offline Explorer Pro
Best Javascript/DOM link crawlers Burp Spider, w3af, scanajax, urlgrep, sts-scanner, CSpider, Syhunt Sandcat
Best Ajax crawlers OWASP Sprajax, scanajax, w3af, Ruby mechanize, crawl-ajax (RBNarcissus), crawl-ajax (Watir), FireWatir, scRUBYt, Syhunt Sandcat
There's not much more to say about crawling, as I've already said it a million times. These should get you started. Again, the order is important. If you've never crawled an application using Burp Spider, today is your lucky day.
Some of these tools such as FEAR::API, Ruby mechanize, RBNarcissus, Watir (including offshoots like FireWatir, Watij, and Watin), and scRUBYt may require some knowledge of programming, although if you read my past posts -- there are many links to get you started. Other tools such as curl provide libraries in several languages (libcurl for C, PHP-CURL, et al) that are also usually worth checking out.
Even if you're only interested in static analysis (which we'll get to next week), application understanding that comes from how a crawler works on a website is important knowledge.
blog comments powered by Disqus