I will be publishing here all the software and papers I write that are for free distribution.
I have been developing a protocol to generate packets and be able to send them through a network in order to make inter process communication easily.
At work, we are developing a distributed tool that needs to communicate over the network. In order to make a standard way of parsing the packets I developed a simple, but yet powerful protocol to build the packet and interpret it.
W3AF Plugins, Modules and Patches
W3AF is a framework to audit webpages. I work a lot with it, and because of that I realized
that there are many unsolved issues in it. And many of the plug-ins have flaws.
Here you will find the things I've patched or rewritten for a better performance in W3AF.
Blind SQL Injection plug-in
During an usual auditing in a website we found an SQL injection that W3AF wasn't detecting,
when we analyzed the source code of the plug-in we found out that there was a flaw in W3AF
blind_sqi_time_delay.py when trying to detect a blind sql injection through the benchmark
W3AF uses a pre-established number as a parameter to the benchmark function, the problem
with this is that the response time will depend a lot on the server's infrastructure. In our case
the site was being run in a virtual machine, with that parameter the benchmark function took
so long that it lead to time-out errors in the request.
To solve this issue me and a friend/colleague re-wrote the blind_sqi_time_delay.py module.
This time first we use repeated requests to get average responses time. In te case of other
DBMS that have the sleep function first we inject with 1 second, get the average response time
of that and then we inject with 6 seconds, if the difference between those response times is
between 4.5 and 5.5 then we have a valid sql injection.
In the case of MySQL, the DBMS that gave us headaches, what we did is in a first stage calculate
the average response time with 1 as parameter to benchmark, then we calculate the average
response time with 100000 as parameter. 100000 is a quite low number but it will gave us the
difference we need for the later steps.
After we have both average response times we can calculate the average response time of each
calculation in the benchmark and then calculate an estimative number that used as parameter
to the benchmark would lead us to a 6 second delay. So now we inject with that number and if
the average response time is between 5.5 and 6.5 we have a blind sql injection.
You can download the code in this link: blind_sqli_time_delay.py. To use it download it
and replace the original one in /core/controllers/sql_tools in the w3af folder.
It hasn't been deeply tested so I'm really interested in receiving feedback from all of you.
By this time I'm working in a new SQL injection detection plug-in using another techniques to
find SQL Injections.