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:

• http://www.l1pht.com/rsx1.js
• http://www.l1pht.com/rsx2.js
• …
• http://www.l1pht.com/rsx11.html
• http://www.l1pht.com/rsx12.css
• http://www.l1pht.com/rsx16.xml
• http://www.l1pht.com/rsx17.jpg

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

Code fuzzdb, web appsec, xss

A while ago I put out a tweet inquiring as to how people where going about the task of downloading examples (lots) of a specific filetype from teh internetz.  I got a couple replies, which I certainly appreciated.  The most interesting of which came from @shawnmoyer related to @rwnin‘s tool ‘datapyning‘.  rwnin’s script definitely has some strengths, particularly regarding surgical searches related to specific domains.  I wanted a troubled little script that didn’t require much care and had a little more “dice roll” type attitude.  If the utility I describe below doesn’t fit the bill, you might check out datapyning.

My criteria looked more like this:

• Must be able to pull a large (until disk reaches capacity) number of files
• Must run unattended for long periods of time
• Must be able to pull files based on regex for URL
• Must allow me to determine all known URLs where a particular file was found Read more…

Code Code

I recently came into possession of a certain software suite that got me revisiting some thoughts on reverse engineering, binary diffing and the like. So, after a fresh install of XP SP3 and before loading up my new friend, I thought “Wouldn’t it be great to archive the system file changes as I apply patches?  That would be excellent for binary diffing security updates.”.

Then I remembered that Jeongwook Oh had presented just such a tool (SortExecutables.exe) during a talk at Blackhat ’09.  I looked around for SortExecutables.exe, but didn’t find it (*See update @ bottom).  The idea was simple enough and looking for an opportunity to write some code I decided to write my own version.  I present for your viewing pleasure…binaryeti.

Parameters are simple:

Finishing an initial run takes a few minutes, runs after initial usually complete in seconds.

This is a run after updating KB976662, an update for IE8 JSON:

Another run, after updating KB954155 regarding a Media Format Runtime bug:

Finally, after archiving several rounds we end up with a folder structure like this, containing each version of the .dlls we might want to diff:

With the help of a lightweight utility like this, it’s easy enough to archive changes so that we have them handy for later.  This is something so simple and useful, I’m sure there are more than a few researchers with their own versions.  I would be interested to hear about different features and what led to them.

Grab the Source [6kb] or Installer [337kb]

If you decide to go the source route, take note of the NDesk.Options dependency, go get that library and add a reference before compilation.

*UPDATE: So, I’m just about dense.  SortExecutables.exe is distributed with DarunGrim and can be found in the DarunGrim install folder.

Code .Net, binary, Code, reverse engineering, reversing

So, a couple of months ago at the DC405 we were lucky enough to have Tim Skorick come and speak with the group about the dangers of browser extensions.  His talk sparked several ideas for things that a malicious individual might do to gain control of the browser and what she might do once she’s there.

Since Tim didn’t drop any sample code off (after working through this I can see why), I wondered just how difficult it might be to get from zero knowledge to a working malicious plugin.  As it turns out, it’s not difficult at all.

I sat out to make an extension that had some semi-interesting/real functionality (something that would get people to install it, maybe even on multiple machines) and then have some triggerd malicious action performed, like storing their passwords from various websites for a while and then one day tweeting them all out using captured twitter credentials.

The first order of business was to get a plugin up and running.  Following the documentation at https://developer.mozilla.org/en/Extensions gets you most of that.  It’s probably not a bad idea to install all of the “helper” extensions they list, but I was able to get by with only “Chrome List“, “Console2″ and “Extension Developer”. Read more…

Anti-malware, Code browser, Extensions, Firefox, malware

Recently I decided to take a look at a vulnerability in ProShow Gold reported by BKIS and detailed in OSVDB 57226.  Much of the hard work was done, as BKIS had released a PoC pointing out the trigger location.  I quickly found that the way to make this bug work easily was to exploit it using the SEH technique.

I used Metasploit’s ./pattern_create.rb to get the offset to the first handler in the chain.  Typing ./pattern_create.rb 6500, felt a little weird, but sometimes you just have to overwrite a lot of stuff.  I then used ./pattern_create.rb again to get the max payload size, past the handler.  In the module this is listed as 1000 bytes, but you could actually squeeze a few more (if you’re into writing exceptionally large custom shellcode). Read more…

Code, Exploitation 0day, exploit, metasploit