Security-Protocols

Michal Zalewski and his colleague Filipe Almeida have released DOM Checker which is an automated tool for validating browser security policy enforcement. Below is a description of DOM Checker from the page:

The tool features several fairly neat features, including exhaustive hierarchy crawling and side-channel blind write validation to reduce the number of false positives.

DOM Checker had been used to find a number of major security bypass and information disclosure problems in several popular browsers, and we had worked closely with vendors to resolve them (although it’s worth noting that the tool still reports anywhere from 10 to 30 low-risk, design-related information disclosure issues in these programs).

Our hope is that this tool may serve as a framework for ongoing browser security research, and would be integrated by browser vendors with their regression testing and general release QA processes.

Project Page:
http://code.google.com/p/dom-checker/

Access live instance for testing
http://lcamtuf.coredump.cx/dom_checker/

QueFuzz is a small fuzzer that uses libnetfilter_queue to take in packets from iptables. It’s fuzzing engine either randomly fuzzes binary or ASCII protocols or uses a basic fuzzing template to search and replace packet data. QueFuzz has a very short learning curve, unlike many other fuzzing frameworks. It may not be as powerful but you can have it up and running in under a minute.

Unlike other fuzzers QueFuzz is not focused on data generation. It relies on a valid application to generate the data and instead just mutates the network traffic inline and passes it on.

Below is an example:

1. Setup an iptables rule that queues all outgoing packets with a TCP dst port of 21.

iptables -A OUTPUT -p tcp –dport 21 -j QUEUE

2. Start QueFuzz with an FTP template that looks like this

replace USER USERRRRRRRRRRRRRRRRRRRRRRR
replace PASS PAS%nSSSSS%nSSSSS
$./quefuzz -t ftp.fuz

3. Open your FTP client, and connect to your server as normal. QueFuzz takes care of the packet mutation inline, all you have to do is monitor your server with a debugger for any potential crashes.

QueFuzz was created by Chris Rohlf.

QueFuzz Project page:
http://code.google.com/p/quefuzz/

Varun Uppal and Andy Davis have released PGMfuzz which is for identifying vulnerabilities within PGM option parsing implementations. PGM is a reliable multicast transport protocol developed by a group of vendors including Cisco and TIBCO and described in RFC3208. The protocol is used in various messaging and middleware products, including TIBCO’s Rendezvous and SmartPGM FX. The IRM research team has found numerous PGM related flaws within TIBCO products.

You can download PGMfuzz here:

http://www.irmplc.com/Tools/pgmfuzz.c

Fusil project is a fuzzing program. Today, it’s specific to Linux command line program, but the code is designed to be used with any project type (remote process, fake HTTP server, fuzz network socket, etc.). New Fusil implementation is now based on multi-agent system instead monolithic architecture. See Fusil architecture for the details. Read also documentation. Fusil allows to easily write so-called “Fuzzing projects” from a set of functions and the power of Python: create a process, compile C program, watch a process, watch syslog, etc.


fusil --project project/xterm.py

$ cd fusil
$ fusil -p project/xterm.py
[session #1] Start session
[process xterm] Timeout! (1.0 second)
(...)
[session #8] Start session
*** glibc detected *** /usr/bin/xterm: double free or corruption (!prev): 0x080ad2b8 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7b957cd]
(...)
[watch process] Process killed by signal SIGIOT
[session #8] Session score: 100.0%
[application] Success with session #8!


Fusil Project Page
http://fusil.hachoir.org/trac

Michal Zalewski has released Bunny the Fuzzer which is an open source general purpose closed loop protocol blind fuzzer. Bunny uses automatically generated C-level instrumentation to focus on runtime inputs observed to trigger new control flow paths or interesting parameter variations - and to bail out early on dead-end fuzzing routes.

This notably improves flow path coverage and overall quality of the fuzzing process. The tool is designed to maintain a near-native execution speed, and requires virtually no setup, even when dealing with complex and large code bases. This is probably a major improvement over previous closed loop solutions. This architecture makes it possible to significantly improve the coverage of the testing process without a noticeable performance impact usually associated with other attempts to peek into run-time internals.

Bunny is currently known to support Linux, FreeBSD, and Cygwin on IA32 systems.

If you found any flaws using bunny, post a comment here. Also, the name of this fuzzer kind of reminds me of Fluffy Bunny. The guy who was hacking all kinds of crazy sites and leaving that funny pink bunny on the sites he owned. Good times…

You can find the documentation here:
http://code.google.com/p/bunny-the-fuzzer/wiki/BunnyDoc

Download the current version here:
http://code.google.com/p/bunny-the-fuzzer/