Application Security Testing Tools

I have been asked a few times recently to tell people what tools I use when I'm testing web applications for security issues.

I always find that a mixture of tools can be used to find potential security issues in applications but to exploit these issues it always seems to be a manual effort. I don't mind that, I get a good feeling when I hack things!

I will list the tools I use along with a short description, I'm not writing this post as a tutorial - if anyone wants tutorials then let me know and I will see what I can do.

My favourite tool would be the Burp Suite from Portswigger. We have recently purchased a site license at work - I think that says a lot for this tool. Burp Suite offers many different modules that can help you test application security. I like the intruder module the most, this allows me to input the strings I would use in manual tests very quickly and in a few different ways. My test inputs file is nearly 400 different inputs so the intruder module is a lifesaver. The Burp Suite is available as a free or commercial tool, I recommend that anyone interested in web application security testing grabs a copy and has a play with it.

The Burp Suite can also be extended using the IBurpExtender, if any developers reading this want to collaborate on a project then drop me a line. I have a few ideas that I would love to implement using the Burp Extender.

I have recently started playing with the Exploit Me Firefox plugins and I have been impressed by them. I have put SQL Inject me and XSS me into my testing tool box. The plugins allow you to "point and click" test web applications for XSS and SQL Injection issues. They are quick and efficient and I would recommend them to anyone wanting to test for these issues.

I have recently started to try some fuzz testing tools when I have been testing web applications. This approach has found a lot of bugs in high profile software in the past so I felt it was worth a try.

I had started using Spike Proxy for fuzzing but if I'm honest I'm not that impressed with the tool. I felt the initial character set that is hardcoded into the tool wasn't as big as I would like. I extended this significantly but I'm still not likely to stick with this tool. I wanted the fuzzer to put random data into fields with random lengths and this tool didn't deliver that for me. Perhaps I'm using it incorrectly, if so drop me a line and enlighten me :-)

So to fulfill my desire for a fuzzing tool I have begun playing with Jmeter for this purpose. I think if I write some Java which has a predefined character set (could even pull from a "random" source - /dev/random?) and an upper and lower length for the input I can use BeanShell with Jmeter and input this fuzz type data into fields which I submit to the web application. I can't take all of the credit for that idea, if the person who helped with this idea is reading this now then thank you very much! That idea is still very much in the "does it actually work?" stage so I will let you all know how it goes.

Thats my main set of testing tools at the moment but I'm always playing with new things. I have a few tools listed below that I think are going to be squeezing into my testing tool box soon (not all of these are new tools):

Grendel-Scan

Nikto

Wikto

Try them and find out what works for you.

Dave

Up in the clouds......

With all the discussion of cloud computing recently I have decided to give it a go. I'm going to sign up with the Amazon cloud service.

Since I created this blog I'm finding I need bigger and better labs to test out things like the Dan Kaminsky DNS flaw, Evilgrade and a multitude of reverse engineering tasks. I have decided that doing all of this up in the Amazon cloud gives me a huge amount of computing power for a very small price.

I'm going to get myself set up in the next few days - expect some good lab work to appear on the blog in the coming months!

Dave

Security/Hacking conferences

With all the talk of Blackhat USA and Defcon at the moment it makes me wish I would have gone along! I have a lot of friends over in Las Vegas at the moment telling me about the fun they are having. I look forward to reading the presentations from the conferences.

Next year I will be going! I will also being making my usual journey to Blackhat Europe in 2009. It seems like a long way off but Blackhat Europe will be hosted in Amsterdam as usual. It will run from April 14th through to the 17th next year. Details will be posted on this page.

I also plan on visiting the Chaos Communication Congress in December this year, the Chaos Congress will be held on the traditional days of 27th - 30th December. I think I really need to pick my time carefully when I tell my girlfriend I plan on going! More details can be found here.

I will post more about Blackhat nearer the time but if anyone else is planning on going to CCC give me a shout.

Dave

An apple a day.......

Should keep the doctor away. Useless its an OS X install acting as a DNS server, in which case this apple a day will get you owned.

Incase you have been living on the moon and have missed the huge amounts of news stories about the serious issue discovered in every DNS implementation please read this.

It appears that Apple are one of the few major vendors who have not released a patch and according to Heise Security they haven't even issued any security alerts. I'm not an anti Apple person, I own a Macbook and an Ipod Touch but over the years they haven't been great at security and patching. Steve Jobs might be right about Microsoft lacking taste and design ideas but they sure do kick Apple's ass when it comes to patching and patch scheduling.

This DNS issue has been bubbling for a couple of weeks now until Halvar Flake figured out the problem. DYOR (Do Your Own Research) on the whole story but the issue has got much worse with the release of a metasploit module and Evilgrade which exploits this issue.

As soon as I get the chance I will give a demo of either the metasploit modules or Evilgrade, probably Evilgrade as I like the look of that!

Dave

76% of US Banking websites insecure

I came across a study today written by Laura Falk, Atul Prakash and Kevin Borders from the University of Michigan which explains that of the 214 US banking sites reviewed 76% have security holes.

The report focuses on security issues that have occurred because of poor design decisions in the development of the banking sites. I like this approach because it demonstrates that security compromises don't just occur through obscure or fancy attacks.

Some of the issues highlighted are things that I would suggest are obvious design flaws such as beginning a logon session from an HTTP page.

I would suggest that anyone with an interest in secure web application development should have a read of this report. My article in the next edition of Insecure Magazine will give you tips on how to avoid these types of design issues.

Dave

Views on the news

I have come across a few news stories I wanted to share with you all today, so instead of having multiple posts I thought I would address them all here.

The first news story I nearly didn't read but I'm glad I did. Moodle is a course management portal used by universities and the like across the world. The story explained how the portal has two vulnerabilities, XSS (Cross Site Scripting,not really a "wow") but also a CSRF (Cross Site Request Forgery). The CSRF really interested me and I now have something to point my colleagues to who have listened to me talking about this issue for a while now.

I won't explain CSRF here (details can be found here) but the attack itself tricked users into clicking on a link which sent an edit profile request on their behalf. This leads to a compromise of the users account.

The second story explains how 3/4 UK companies have banned IM within their infrastructure. In the story it states that only 88% of the IT directors surveyed felt IM posed a security risk, oh dear. Personally I would ban public IM (MSN, Yahoo etc) for all users, in fact I would go one step further and remove web access completely for certain business units. If a business unit has access to sensitive data then, in my opinion, the systems in that business unit should not have web access. The sensitive data could be credit card data, Intellectual Property such as source code - anything sensitive and of high value to the business really.

I'd like to hear the opinions of other people on this.

Just one more to go, a more technical story.

The last one is from Sans ISC, have a read and let me know what you think.

Dave

The dataloss database

I often struggled to find the statistics I required for presentations on data breaches until I found attrition.org

I liked attrition, but I love what it has evolved into! I got an email on full disclosure mailing list today announcing its change to the dataloss database. The Open Security Foundation will be running the datalossDB and I for one look forward to using it going forward!

Basically it is a central DB for all public data breaches for the past 8 years there are many ways to search the data and monthly and annual reports can can be viewed by any one.

I have to say the guys at OSF have done a great job with this!

Dave