Programatically scanning using Arachni (Part 5)

As promised, part 5.
Not that anyone’s reading this crap, once I’m done with the series though I’ll be able to gather them into a nice developer’s guide so I might as well keep going.

As always, keep your installation to up date with the experimental branch before continuing.
These articles have forced me to see Arachni from a completely different perspective and so I keep improving the API to make it more developer friendly.

This time we’ll focus on auditing individual elements and also work on a per page scope.

Let me paint you a picture:

You have a Rails (or some other such framework) web application.
You need to audit it in a consistent manner.
You wish you could simply add security tests to your existing test suite next to your units/functional/integration/etc. tests.
Your webapp framework already keeps track of pretty much all inputs (and if not you can override helper methods like link_to and form_for to keep track of them).
The only thing missing is a system to which you can feed that data and audit those inputs.

You see where I’m going with this, right?

The Arachni framework can easily handle this in a number of ways, some of which I’ll demonstrate here.

Scripted element audits

Let’s start from the outside and move inwards.
The framework feeds pages to modules –> modules audit pages –> pages include elements –> modules inherit from Arachni::Module::Base –> Arachni::Module::Base includes Arachni::Module::Auditor and Arachni::Module::Output.

And everything’s at its place, modules live under “/modules” and everyone’s happy.

I’ve already showed how to script an audit but what if you want a narrower scope?
What if you have a list of elements you want to audit?
What if you want to pass a custom page to be audited?
And more importantly, how can you do that without needing to work with the framework, the module manager and without needing to write a full blown module?
What if you just want the functionality without the hassle?

Obviously that’s possible, otherwise I wouldn’t have gone through that sales pitch.
What we need to do is create our own Auditor at runtime… better yet, let’s create our own Module so that way we’ll have access to some utilities and other toys as well.
Through that Auditor we’ll be able to submit, fuzz, audit, analyze elements and server responses.

Time to go through the 2 cleanest ways to do that.

First of all, this will be our Auditor, it’ll serve as a proxy to the functionality enjoyed by regular framework modules.

Each Auditor must have a page as a reference if only to know the current URL, so a page with at least a URL assigned must be available at all times.

Per element

This approach deals with auditing individual, user created, elements, which is the finest grained of controls possible.
Talk is cheap though, let’s test a few examples.

Pattern matching

Simple enough, inject a string and see if it appears in the response:

This time we don’t mute the output, and why should we? Let’s admire our handy work. 🙂

But what if you don’t want the auditor to log the the issue automatically based on an expression or substring?

Differential analysis

The Auditor module contains helpers that perform differential analysis for you using Arachni’s own rDiff algorithm.

See this SQL injection example for instance:

Again, if you want to perform your own analysis and logging:

Time-out/delay attacks

Yes, timing attacks are of course part of the repertoire but are not available on a per-element basis.
Don’t worry though, there’s an alternative way to perform them as we’ll see shortly.

Per page

The per-page approach is slightly different and requires some commitment as you have to you properly configure a page object with elements and feed that page object to the module.
The module then audits those elements in batch.

Pattern matching

Let’s see what the pattern matching example looks like when adjusted for this approach:

I’ve removed most of the comments this time since they were identical to the first example.

I just had an idea, let’s add an audit method to the page object itself and see if it’s any easier to work with.

Huh, seems kinda nice… 🙂

Differential analysis

Should be a familiar sight:

’ ],
:bools => [ ‘ and 1+1 = 2’ ],

auditor.audit_rdiff( rdiff_opts )

results = Arachni::Module::Manager.results
auditor.print_info “Found ” + results.count.to_s + ” matches.”

Time-out/delay attacks

And now it’s time to check out some timing attacks.
Actually, since timing attacks are wildly unreliable Arachni doesn’t simply perform a time-out check.
It performs a few time-out checks with different delay tolerances and waits for the server to normalize in between and it also does some other weird stuff to make sure that false positives are a rare occasion.

Simple as pie.

Page delegation

Let’s investigate this idea a bit further, shall we?
Having audit functionality built-into the page objects would surely be helpful!

Time to monkey-patch the Page class I reckon so update your auditor.rb file to this:

And from that point on you can simply audit pages like so:

Audit combo

Running all modules

We may have gone a little bit too deep it seems…
You may not want to perform the audit yourself…
You may want to specify a narrow scope, on a per-element basis, but use the existing modules to audit them.
How do you do that?

First of all, you can’t give Arachni’s modules individual elements…you have to give them pages.
That’s alright though since as we’ve seen today creating pages containing elements of our choosing is no big deal.

That’s all for now, I hope you that found this post interesting — I certainly did.


Posted in: Arachni, Open Source, Programming, Projects, Ruby, Security, Web Application

Tags: , , , , , , , , , , , , , , , , , , , , , , , ,


rssComments RSS transmitTrackBack Identifier URI

FWIW I’m reading this, not had the time to work through all of it yet, but v. interesting stuff.

Comment by Rory McCune on 04/12/2011 9:34 pm

Definitely interesting stuff. Arachni has quickly become my go to tool for web security.

Comment by Chris Clements on 06/12/2011 7:31 pm

Cheers guys

Comment by Zapotek on 06/12/2011 7:39 pm

You can use these 2 callbacks in order to see all responses as they appear.

This will call the block for all responses in the running batch of requests and get emptied out once the current run finishes:
Arachni::HTTP.instance.after_run( &block )

This will always call the block for each response as it arrives:
Arachni::HTTP.instance.after_run_persistent( &block )

You can call both multiple times if you’ve got many blocks.

Comment by Zapotek on 12/02/2012 3:05 am

Great Stuff!

But I have another use case. I am still passing in a generated page to Arachni, so this tutorial is great, but I would also like to see the full responses associated to requests, so that, for example, if Arachni ends up killing the server and/or logging out of the webapp in request #7, it does not end up shooting blanks for the rest of the test. More importantly, I would like to see this in (approximately) real time, so I don’t need to wait for an hour for the tests to complete. That way I can stop the scan, log back into the site, and continue with request #8 and more restrictive options. Any ideas?

Comment by Robert on 12/02/2012 2:51 am

Sorry my bad, the persistent one is:
Arachni::HTTP.instance.on_after_run_persistent( &block )

Comment by Zapotek on 12/02/2012 2:38 pm

Just came to me, try:
Arachni::HTTP.instance.add_on_complete( &block )

This will pass responses to the block as they arrive.

Comment by Zapotek on 24/02/2012 9:11 am

addLeave a comment