I’m pleased to announce the Framework v0.4.3 and WebUI v0.4.1 release of Arachni. There’s lots of new features and optimizations so let’s go through the most important ones real quick.
YAML engine switched to Psych
The YAML engine used for communication over RPC has been changed to the now Ruby default Psych, so please update any tests you may have in place and check your infrastructure to make sure everything behaves as expected.
This change was supposed to take affect as of the previous v0.4.2 release but there was a leftover piece of code forcing the engine to Syck, this time though the change has been verified.
Multi-Instance scans have finally become stable enough for production use. This means that you can utilize multiple cores/CPUs/Grid-nodes by using multiple Arachni Instances to perform a single scan. This works due to the fact that each Instance is its own process and these processes communicate over TCP/IP (or Unix sockets if they are on the same host).
The Grid previously operated only in line-aggregation mode, that is, you could perform multi-Instance scans by retrieving Instances from Dispatchers which were configured with unique bandwidth Pipe-IDs; if you were interested in simply load-balancing (getting Instances from the least burdened Grid member) you had to take care of that on your own.
Now though, the default operation of the Grid is that of load-balancing, this means that when you make a “dispatch” call to a Dispatcher, the Dispatcher will delegate that call to the least burdened Grid member automatically — thus allowing for seamless and transparent load balancing. If you wish to scale-up, the only thing you’d have to do is add a new Dispatcher to the Grid and the load-balancing process would be transparent to the client.
Arachni got a bit more brains with this release, it now takes into account the platforms deployed by the targeted webapp and tailors the audit to match it. This means, for example, that if the webapp uses PHP, only payloads applicable to PHP will be injected, thus preserving bandwidth, lessening the remote server’s load and also resulting in shorter runtimes.
The fingerprinting feature is on by default and is completely passive, merely taking advantage of information leaks like ‘Server’ response headers or other clues like names of cookies and file extensions. You can of course disable it if you wish and/or manually specify default/extra platforms.
This, combined with multi-Instance scans, can have a dramatic effect in performance.
Not a lot has changed in the interface, mostly bugfixes and optimizations. The most important changes are support for PostgreSQL and the ability to import the data and settings from your existing 0.4.2-0.4 package.
The build-machines have been migrated to CentOS 6.4 and as a result the packages will now depend on GLIBC 2.12 which should make them more portable and less prone to GLIBC errors. Now, if you haven’t updated your system in quite a while (and as a result have GLIBC <2.12) you will still get these errors but there’s only so much I can do, sorry.
That’s all folks, I hope that you’ll enjoy this release and provide feedback.