ratproxy 1.51 tutorial

Ratproxy is a [mostly] passive web vulnerability scanner that Michal Zalewski released a few days ago. Set ratproxy to proxy your web browser and go surf! When you’re done, run a shell script and out pops a clear report of all the vulnerabilities ratproxy thinks it saw.

I’ve played around with ratproxy the past few days and used it to find vulnerabilities in some major websites. Here is a short cheatsheet I wrote up, an example report file and what it means, and a quick look into the source code of ratproxy.

Cheatsheet:

./ratproxy -v dumpdir -w audit1.log -d host.domain -lextifscgjm

Small set: -lfscm
Big set: -lextifscgjm
Active: -XClfscm
Everything: -XClextifscgjm

When done, run ./ratproxy-report.sh audit1.log > audit1.html

-v folder to save http traces
-w the log file
-d the domain to analyze (multiple -d’s are allowed)

-l relaxed page checksumming
-e check caching
-x XSS candidates (-X disruptive XSS checking)
-t directory traversal candidates
-i log PNG images (possible XSS in IE)
-f log all flash and pass to the decompiler
-s log all POST requests
-c log all URLs that set cookies
-g extend XSRF checks to GET (POST and COOKIE are done by default)
-j detect evil JS functions (eval, innerHTML, etc)
-m remote images/remote linking (breaks when -d is unset)

-X active testing, validate potential XSS, XSRF
-C replay requests with modified params
-k assume HTTPS must always be on, report downgrades to HTTP
-a log all visited URLs (track code coverage)

Ratproxy breaks a trend in the security community in that it isn’t written in Ruby or Python! It’s all written in C and bash. I had no problems getting it to compile on Linux, Mac, and Windows (Cygwin). Ratproxy uses an external library to decompile flash files that you have to replace with the proper one for your platform.  Note: as much as you are tempted, don’t turn on ratproxy and pump wget through it. As a friend described it, wget will only download the “scrapeface” of the website and will behave in a substantially different manner than a human would, which ratproxy depends on for a few of its checks. Also note: turning on the “-XC” options will let ratproxy make potentially harmful requests on its own. If you’re going for stealth, leave those off and stick with “-lextifscgjm” for the largest set of possible vulnerabilities.

To demonstrate some of ratproxy’s capabilities, I set it up to actively analyze the poly.edu domain:

./ratproxy -v dumps -w poly.log -d poly.edu -XClfscm

Then I set my proxy in Firefox to be localhost:8080 and went to work surfing the web (heh ratproxy will usher in a new age of legitimate excuses for security pros to slack off!). I read some news about the NYU merger, looked up athletics info, found some IT policies, and read about the BEST center. To quit, you just CTRL+C the ratproxy process and set Firefox to connect directly to the web again. The poly.log file should be filled up by now. This log file is a pipe-separated, one-issue-per-line, easy-to-grep report, but right now I just want something easy to read so lets process it into a nice html report:

./ratproxy-report.sh poly.log > poly.html

Nice! There are a whole bunch of confirmed XSS vectors right at the top! There doesn’t appear to be anything else too serious, but those are good results considering I did basically nothing for them. It looks like there are two separate pages I went to with XSS, let’s try and verify both. The first is at http://insight.poly.edu/phonebook. Let’s go grab one of RSnake’s XSS locators, put it in a field and see what happens:

Sweet! Ratproxy knows what it’s talking about. Now let’s try the calendar at http://www.poly.edu/calendar/. According to the report, it looks like the ‘view’ parameter is vulnerable. Let’s just re-use the same XSS locator since it worked so well last time.

Ratproxy is good at this. Let’s take a look at the code they’re using to “disruptively” check for XSS.

(fyi, http_request.p is a list of decoded parameters) Sticking with their “don’t be evil” mantra, no actual javascript is injected into the web application. Instead, they’re taking all the parameters they’ve already determined are echo’d back and putting in the dummy string qg:qg qg=–>qg\”qg>qg’qg>qg+qg<qg> to check for input validation/output encoding. Later down, starting at about line 440, they have what is basically a huge switch looking for how that string was returned.

My overall assessment of ratproxy is that it’s a good first-pass tool when you’ve got a nice big web app and don’t know where to start. Ratproxy will help you pick out interesting bits to focus on and identify weakly coded chunks of applications within larger websites (notice that ratproxy picked out the phonebook and calendar above, but nothing important was returned on the main Poly website). One thing in particular that I like about ratproxy are its clean and useful reports. Each report starts with a concise description of the issue, whether you can access it pre-auth, an excerpt of the http trace demonstrating the issue, and a link to the full trace. Other web application vulnerabilities scanners need to learn from this!

Keep up the good work Michal!