2009/10/21 Andres Riancho <andres.rian...@gmail.com>: > Sébastien, > > 2009/10/21 Sébastien Duquette <ekse...@gmail.com>: >> 2009/10/21 Andres Riancho <andres.rian...@gmail.com>: >>> Sébastien, >>> >>> You're on fire man, thanks for the new contribution =) >>> Please read inline, >>> >>> 2009/10/19 Sébastien Duquette <ekse...@gmail.com>: >>>> Hi, >>>> >>>> I started playing a bit with w3af and I wanted to implement a plugin. >>>> I chose the ReDoS (Regular Expression Denial of Service) attack that >>>> was presented recently at OWASP (details can be found here >>>> http://www.checkmarx.com/NewsDetails.aspx?id=23). Basically, ReDoS can >>>> be found when some regular expressions take an exponential time to >>>> check some patterns. It will thus take twice the time to check a >>>> pattern each time you add a character to a specific part of the >>>> pattern. >>>> >>>> For example : >>>> >>>> If aaaaaaaa! takes 2 second to check, then aaaaaaaaA! (one more >>>> character) will take 2 seconds and so on. >>> >>> First time I head about this, I can't believe I missed it. I just >>> performed some tests in python by following the slides, and this is >>> what I found: >>> >>> - re.match('^[a-zA-Z]+(([\'\,\.\- ][a-zA-Z >>> ])?[a-zA-Z]*)*$','aaaaaaa!')>>> re.match('^[a-zA-Z]+(([\'\,\.\- >>> ][a-zA-Z ])?[a-zA-Z]*)*$','aaaaaaaaaaaaaaa!') >>> >>> Runs "instantly" >>> >>> - re.match('^[a-zA-Z]+(([\'\,\.\- ][a-zA-Z >>> ])?[a-zA-Z]*)*$','aaaaaaaaaaaaaaaaaaaaaaa!') >>> >>> Runs in ~4 seconds. >>> >>> - re.match('^[a-zA-Z]+(([\'\,\.\- ][a-zA-Z >>> ])?[a-zA-Z]*)*$','aaaaaaaaaaaaaaaaaaaaaaaaa!') >>> >>> Runs in ~12 seconds. >>> >>> I suffered from this in the past. w3af had some regular expressions >>> that took A LOT OF TIME to run when specially crafted HTML was being >>> parsed. At this moment, I think that I've filtered most of this >>> regular expressions. >>> >>>> I tried to find an elegant way to implement this. I looked at the >>>> osCommanding plugin because it has a test on time delay. In this >>>> plugin, the time delay is changed between the runs with a simple >>>> regular expression. I did something somewhat similar, I double some >>>> characters from the original pattern in the next request (X and 9). >>>> >>>> So, a...@a.aaaaaaaaaaaaaaaaaaaaaax! will be changed to >>>> a...@a.aaaaaaaaaaaaaaaaaaaaaaxx!. >>>> >>>> I then check if the response time of the second request is longer than >>>> 1.5 time the original one. >>> >>> Nice, I like the plugin and the implementation method. Here are some >>> minor comments on the plugin source: >>> >>> - Since there is only one way of auditing this using black-box: time >>> delays, I simply removed the "_with_time_delay" method and put >>> everything inside "audit". >>> >>> - Removed some debug "print"s >>> >>> - Added a reference to the redos slides in the plugin long description >>> >>> Could you please send me a vulnerable PHP script, so I can add it to >>> my test scripts? >> >> Glad you liked the plugin. I did some testing and it seems that the >> PHP regex engine is not vulnerable (on Linux at least). I included a >> basic PHP script. > > Oh, this sucks. Most of my test scripts are in PHP, and I wanted to > maintain that. > >> For my testing of the plugin, I used a ruby CGI script. The fact that >> the ruby regex is engine is vulnerable is interesting because >> RubyOnRails is a very popular framework. The script is also in >> attachment. > > Ok, great. > >>>> The plugin works in it's current form on a test installation. I know >>>> there is a lot of room for improvement. I want to add more patterns >>>> and also adjust the length of the patterns. I would greatly appreciate >>>> feedback. >>> >>> I think that the length of the strings are ok (at least they add some >>> delay on my laptop + python regex). The plugin was perfect, I changed >>> only minor things, and now I just commited it to the trunk: >>> >>> http://w3af.svn.sourceforge.net/w3af/?rev=3098&view=rev >>> >>> If you have enhancements for the plugin, please let me know =) >> >> I have some improvement ideas that I want to implement. In summary, I >> want to add more test patterns, > > This could be an issue, because you would be sending lots of requests > to each parameter.
Right, like everything it's always a tradeoff. I kept the number of patterns small for the moment for this reason. The best thing would be to run tests with more tests patterns and gather statistics as to what patterns yield the most results. > >> make some more iterations (2 or 3) >> when a possible regex is found to reduce false positives. > > This would be perfect, everything we can do to reduce false positives, > should be done. In this case, the 2 or 3 iterations would be performed > only after the parameter seems to be vulnerable, so no extra overhead > is added to each parameter test. > >> One more >> ambitious improvement would be to extend strings when the response >> time is still small. Since the response time to a string is directly >> linked to the computational power of the server, a server with a lot >> of CPU power might answer to the test strings faster than the 1 second >> threshold while still being vulnerable. Still, this change would make >> the redos testing longer so I want to test it to make sure it's not >> just adding unneeded overhead. > > I think that you should find a string length that will in most (~80%) > cases perform more than 1 second of delay, but at the same time not be > overly long to cause a real DoS. yeah I would really like to find that kind of compromise. I'll do further testing to see if it's possible to have strings that cover a reasonable range in performance. The 10 seconds default timeout on HTTP requests should allow to cover a difference of around 9 times more CPU power, which is a lot. If someone finds redos "in the wild" with the plugin, I would really appreciate to ear about it, that would help me adjust the plugin. Cheers ;-) Sébastien > > Cheers, > >>> Cheers, >>> >>>> Thanks, >>>> >>>> Sébastien Duquette >>>> >>>> ------------------------------------------------------------------------------ >>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>>> is the only developer event you need to attend this year. Jumpstart your >>>> developing skills, take BlackBerry mobile applications to market and stay >>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>>> http://p.sf.net/sfu/devconference >>>> _______________________________________________ >>>> W3af-develop mailing list >>>> W3af-develop@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/w3af-develop >>>> >>>> >>> >>> >>> >>> -- >>> Andrés Riancho >>> Founder, Bonsai - Information Security >>> http://www.bonsai-sec.com/ >>> http://w3af.sf.net/ >>> >> > > > > -- > Andrés Riancho > Founder, Bonsai - Information Security > http://www.bonsai-sec.com/ > http://w3af.sf.net/ > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ W3af-develop mailing list W3af-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/w3af-develop
