Security testing with Google's ratproxy

Ratproxy is a passive web application security assessment tool released by Google. Basically you set it up as a proxy server between yourself and the target site, and then click around in the target site doing whatever it is you normally do, while ratproxy analyzes your activity in the background and looks for security holes.

Installing ratproxy.

I couldn’t figure out how to compile it on OS X - I kept getting a warning aobut the flare binary (love the bianry mis-spelling):

*** WARNING: flare-dist/flare bianry is not operational.
*** Please see flare-dist/README and update it for your OS.

I read the flare-dist/README and downloaded the mac-specific binary, but i still kept getting the same error. After about an hour of trying various hacks I just gave up and decided to run it on a virtual Ubuntu install in Parallels. This was straight-forward with aptitude :

> sudo aptitude install ratproxy

Running ratproxy.

Once it was installed on Ubuntu, it was dead simple to get running (obviously replacing my-site.com with the site you want to test) :

> ratproxy -v ratproxy -w report.log -d my-site.com -leXtifscgr
ratproxy version 1.58-beta by <lcamtuf@google.com>
[*] Proxy configured successfully. Have fun, and please do not be evil.
    WARNING: Disruptive tests enabled. use with care.
[+] Accepting connections on port 8080/tcp (any source)...

The various options are explained in depth on the ratproxy wiki, so I won’t go into them here. Reading documentation is not my strongest point, so I sat around for a few minutes watching ratproxy do nothing before I started wondering if there was something else I was supposed to do. A quick trip back to the wiki was enlightening :

Once the proxy is running, you need to configure your web browser to point to the appropriate machine and port (a simple Firefox extension such as QuickProxy may come handy in the long run);

Aha! We need to set up firefox to connect via ratproxy. Open up Advanced -> Network -> Settings and add the proxy information as follows. The HTTP Proxy set here (beta) is the name I have set up in my /etc/hosts file as a shortcut to my virtual Ubuntu box - substitute the domain or IP address of the machine you’re running ratproxy on here. 8080 is the default port ratproxy runs on - you can change this if you want using the -p argument when you start it up.

It’s quite handy to add the FireFox QuickProxy plugin too - it adds a toggle button in the bottom right of your browser window so you can easily enable/disable the proxy :

When I first did this, I couldn’t connect via firefox, and noticed the ratproxy log said :

[+] Accepting connections on port 8080/tcp (local only)

The fix for this was to add the -r option (included above), which allows connections from remote machines. Since I was running ratproxy on a virtual box, I couldn’t connect without this option. After adding -r we have more luck :

[+] Accepting connections on port 8080/tcp (any source)

Once I had FireFox set up with the proxy, testing was a simple matter of clicking around the site watching the report.log file grow as ratproxy collected information. Once you’re satisfied that you’ve tested the major parts of your site, you can stop the proxy and move onto reading the report.

Reading the report.

This report.log file produced by ratproxy isn’t really human-readable, but luckily google has provided a script to convert it to HTML. {{ “ratproxy.googlecode.com/svn/trunk/ratproxy-report.sh” | ext_link: “Download it from here”}}, save it somewhere and make it executable :

> wget http://ratproxy.googlecode.com/svn/trunk/ratproxy-report.sh
> chmod a+x ratproxy-report.sh

Now that you have the converter script, you can generate the HTML report by running it on the report.log file we’ve produced :

> ./ratproxy_report report.log > report.html

Open the resulting report.html file and you can see the results of your test :

If you get a basically blank report with no errors, chances are the data wasn’t collected properly - if your report.log file is zero bytes then this is the case. If this happens, try removing the -d my-site.com parameter and run your test again and you may have more luck (although using the -d option is recommended).

Fixing some of the problems.

I had a couple of hundred ‘vulnerabilities’ of varying severity. Luckily most of them could be grouped into a couple of categories, and fixed en masse.

“MIME type mismatch on renderable file”

These errors were caused by Apache reporting a different mime-type than the one ratproxy was expecting. It turned out that this javascript file is actually dynamically generated by the application, so fixing it was a simple matter of setting the Content-type header in code :

/**
 * Outputs some jscript variables for the uploader.
 *
 * @return void
 */
public function jscriptAction()
{
    // Set the correct mime type.
    $this->getResponse()->setHeader('Content-type', 'application/x-javascript; charset=utf-8');
}

There were various other low-severity _MIME type mismatch_es for static .js files such as this :

…and getting to the heart of the problem :

MIME type: application/x-javascript, detected: text/plain, charset: -

These were easily fixed by forcing the mime-type and encoding for files with a .js extension in Apache :

<VirtualHost *:80>

    ...

    # Set encodings.
    AddDefaultCharset UTF-8
    <FilesMatch "\.js$">
        ForceType 'application/x-javascript; charset=UTF-8'
    </FilesMatch>

    ...

</VirtualHost>

I had a similar problem with .css files :

… notably :

MIME type: text/css, detected: text/plain, charset: -

The solution to these was similar to the .js fix, but for the .css extension :

<VirtualHost *:80>

    ...

    <FilesMatch "\.css$">
        ForceType 'text/css; charset=UTF-8'
    </FilesMatch>

    ...

</VirtualHost>

“Inline PNG image”

I had about 50 warnings about inline PNG images :

After a bit of googling I found out that ratproxy wanted .png files to have a Content-Disposition attachment header, to fix a vulnerability in IE6. Once again this was easily fixed in the Apache config :

<VirtualHost *:80>

    ...

  # Fix ratproxy .png warnings
  <Files *.png>
    ForceType image/png
    Header set Content-Disposition attachment
  </Files>

  ...

</VirtualHost>

Since you’re almost certain to get a different set of problems to me, there’s a good explanation of the various error codes that is pretty much vital in getting to the bottom of some of this stuff.

Conclusion

I’m not sure how serious any of these vulnerabilities would be out in the wild, but it’s great to have a (free!) tool that goes into this much depth.

Ratproxy rocks!