Buby.kicks_ass? => true

----
This post got lost in the move back to blogger domain, its probably outdated, im sure tebo doesnt support any of the code... but i've been asked for it before and i found it on someone's evernote

-CG
----

Buby.kicks_ass? => true

Wed, 04/14/2010 - 06:25 by tebo  

Buby combines two things I use on at least every web application penetration test, if not every penetration test. Burp and Ruby.
I will assume you are familiar with both. If you aren't familiar with Burp, it's the best money you'll spend on a security tool in my opinion. So go get it, install the PortSwigger cert, tweak your config and get to work. See the end of this post for some operational Burp references.
Buby was widely introduced in the Blackhat USA 09 presentation "Ruby for Penetration Testers" by Matasano Security and is available thanks to the BurpExtender API by PortSwigger and some pretty Ruby by Eric Monti.
Depending on your platform, Buby and some of it's sample dependencies can quite literally be a pain in the ass to install, as in you could be in your seat trying to resolve dependencies for a portion of your day, so assuming you've got it running on your platform, let's talk about some of the use cases.
We could all use a little more interaction with the application under test and a scripting capability is the first thing that comes to mind. Whether it's manually scripting out a login request or application workflow to reach deeper parts of the app or surgically manipulating requests to evade filters or demonstrate a particular attack vector, every test is going to include some component that needs to be handled more interactively than you can do with just a big app scanner. Some common (trivial, fictional, broken, crude, etc.) cases...

Mining and aggregating parameter values or server responses to a certain page is a no brainer.

faces = []
$burp.with_proxy_history do |req|
        return unless $burp.in_scope?(req.url)
        parms = $burp.parameters(req.req_str)
        parms.collect.each {|x| faces << x[1] if x[0] == "javax.faces.ViewState" }
end

Harvesting embedded application paths and feeding them to the Burp spider

exp = /Js\.getView\ /
$burp.search_proxy_history(nil,exp) do |view|
        return unless $burp.in_scope?(view.url)
        view.rsp_str.each_line do |line|
                url = "#{view.protocol}://#{view.host}:#{view.port}/"
                $burp.send_to_spider(url + line.split("=")[1]) if line =~ "Js.getView"
        end
end

Sick Burp's active scanner on requests with several insertion points

# LHF - Throw the kitchen sink at anything that gives you the stink-eye
hist = $burp.get_proxy_history
hist.each do |req|
        return unless $burp.in_scope?(req.url)
        if $burp.parameters(req).length >=3 then
        $burp.active_scan(req.rhost, req.rport.to_i, false, req.req_str)
        end
end

Burp's active scanner conducts tests and reports on a limited number of issues in detail and Buby is ideal for manually reproducing issues found by other tools. Pick your poison when it comes to Ruby http client APIs (Mechanize and rbkb-httphave been convenient for me) and crank out those PoCs.
Because you're a hot shot application tester, perpetratin some perpetual POST penetration and strokejacking the sauce out of all those users (seriously?), you should have a ton of findings data in your proxy history. The pages and parameters that are affected by each issue are typically the meat of the report findings and will be details that the client will require to begin remediation. Buby (via Burp) provides a hook that is run whenever Burp's scanner reports an issue (Ref) and allows you to tap into all of the data that goes into Burp's scanner reports including the offending request/response messages and rememdiation details where provided by Burp.
Inevitably you will have issues that Burp does not report on, for example: I have ported some of the passive checks and good work done by the Watcher team, into Buby http message hooks to passively detect a couple of the same issues. I also route larger application scanners through Burp so I can send the issues that they find to Burp's Repeater tool and manually verify or debug the issues and not have to open up that tool again when I want to look at the report.
In order to collect these issues and work fluidly in Burp, I wrote a very simple Module to collect the information that Burp's scanner reports on in real-time and log it to a Sequel database and a helper method for the Buby class so that you can quickly flag your own issues during the test and log them to the database with all the detail that is in the offending request and response.
I find the issues database useful whether you don't launch Buby interactively and just want it to catch Burp's scanner issues, or you can use it offline with a state file and parse the proxy history with your passive check API or if you use it inline to route other tools through Burp and reproduce and flag their issues to the database for repeatability and verification.
I won't highlight the code inline but I have put my Buby rc file which has a bunch of dumb stuff in it (named BubyTrap ;])here and the module here. The are comments in both that demonstrate some of the usage. If you have any comments or feedback or if you can't figure it out just email me here at AR.
Bonus: Check out the presentation at Blackhat EU this week that (I think) mentions Buby
Cheers,