Having almost shot myself in the face by doing this wrong, I thought I’d make sure that this little piece of information was documented somewhere.
Fuzzing is a lazy man’s game. We’re like toothless hill people, sitting on the porch of our minds in a rocking chair, a shotgun loaded with crackable data resting soundly on our filthy little laps. Waiting. Sippin’ our shine. The unfortunate thing is that we have to be conscious so much of the time. You know, to fetch more shine and what not. What if we could just rot out by the still, relieving ourselves where we fancy?
I’m talking about generating data models without all the fuss of actually investing time and reading the specs.
So, the first thing to do is target an application that will consume an xml file format.
Modeling this normally would involve looking at the spec, writing out each string, maybe as was my case a ridiculous amount of XML encoding to get a good crack. Getting into this I thought, there has to be a better way. Just then Saint Eddington smiled down upon me and said “xml.XmlAnalyzer”.
Basically, Peach will take an xml file of our choosing and spit out a reasonable pit file. Seriously.
You might think you can throw all your boilerplate StateModel, Monitor, Publisher stuff on as usual. You can, the only caveat being that you cannot crack data into pits with XmlElement nodes. Though, this doesn’t matter too much as you’re newly minted pit will contain all the seed data from your sample.
That’s all there is to it. Now go take the banjo down to the still and Rip Van Winkle yourself.
This post is in no way meant to discourage the motivated from modeling out non-xml formats, but more to encourage the most of awful of you to fire up a fuzzer more often.
Once again, l1pht is turning out beer. It’s getting cooler out, and nothing warms my bones like a killer stout. I found a great base recipe for a clone of North Coast’s Old Rasputin. I thought of attempting the clone straight away, but then thought, why not tweak it a bit. After attempting to get the grain bill filled in one place, I had to make a few more changes. Here’s what I ended up with.
Recipe:
9lbs – Northern Brewer’s Organic Light Malt Syrup
1lb – Briess Caramel 20L
1lb – Briess Organic Crysal 120L
.75lb – Simpsons Chocolate
.25lb – Simpsons Roasted Barley
.5lb – Crisp Brown Malt
1oz – Centennial pellets
1oz – Northern Brewer pellets
3oz – Cluster pellets
White Labs WLP001 California Ale
We steep the malts at 150*F for 30 minutes. Add extract and bring to boil. Add the cluster hops and a bit of Irish moss for 60 minutes. Add the Nothern Brewer and centennial hops just before the end of the boil (last 2 minutes). After this, it’s back to business as usual.
This was the first beer that I got to use a yeast starter and my immersion chiller. It turned out well and has some of the Old Rasputin roasty notes with a big upfront sweetness. Find me at a meeting for a sample. Slainte!
I thought I’d contribute this Peach Pit. It’s lightly modeled (ssnd and comm chunks) so there are definitely areas to be improved if the mood hits you.
I wanted to put something together, largely to start posting again (not that I ever have on any regular basis), that might be helpful to someone getting started in light web app testing. I was trying to think of something worth a quick mention. I started tossing the idea of discovering remote file inclusion bugs and generating a list (read, scripting op) of decent fuzz values for playing with.
It was easy enough to do and rather than take a bunch of screen-shots I decided to roll a screencast and walk through the steps in stunning LODEF. The tutorial may be better muted, but here it is:
Here’s the fuzz value list I used in the video: rfitargets.txt. It’s worth considering, if the application being fuzzed makes use of an app specific scheme (i.e wp-<valuehere>) it’s easy enough to adapt by adding the necessary pattern on to the front of the injection point.
Maybe next time we’ll roll the same sort of scenario using Selenium. See you then.