Before the release of the sts-scanner, I plan to add on some crawling capabilities as the strategy is to take the tool to a level where there is minimal human interaction (i.e., no manual crawling of the web application). Note: I am a big fan of the manual crawl, as it is possibly the best assurance you have that every link of a web application has been clicked and all forms have been correctly submitted. So the idea of building a crawler that can do perform like or even better than a human sounds like a nice challenge…

Firstly, some the obvious problems with basic crawlers are things like malformed html, frames, forms, javascript, ajax, web services, web 2.0, etc to name a few breaking the crawling algorithm. Some crawlers simply fall apart when faced with these challenges and as a result, you end up with a minimal or in extreme cases no attack surface area to test.

This blog is about how I plan to overcome some of these challenges and implement them within the sts-scanner. I will only focus on web 1.0 for now as I will concentrate on web services, web 2.0, ajax and javascript at a later date.

Read the rest of this entry »

The concept of writing your own tools has always appealed to me as it offers so many rewards. Apart from the obvious where automating a process provides more time to spend on other bleeding edge areas, some other benefits include:

- Putting into practice all the concepts you have learnt on the job or from whitepapers and presentations etc.

- Being able to share these ideas with a large audience via the Internet and the use of the GPL

- The journey that research and development takes you on and where you don’t really know where you may end up

I want to chat about the last point and some of the work I have been doing over the last month in the development of an application scanner. Continuing on from the educational scanners placed on our site, I have expanded on these ideas to see the difficulty in building an open source scanner that could be comparable to some of the proprietary scanners on the market. Read the rest of this entry »

Following on from the last post, extended scanner is capable of enumerating the back-end DBMS if it is MS SQL, Oracle or MySQL. If these DBMS are discovered, then the tool can enumerate the column number and data types. But what then? How do you use this information to exploit the vulnerability to extract sensitive information or takeover the server? What if the DBMS is say something other than listed above?

To solve this, there are plenty of tools out there (see below) but one pretty cool tool to brute force this information out from the vulnerable application is SQLMap. I recommend that anytime you find a blind SQL injection point, the next step should be to run this tool (or a similar tool) every time. All the information and downloads can be found here and there are plenty of examples in the README. Below is an example of how SQLMap performed on one of our vulnerable test servers.

If you are interested in checking out some other SQL injection tools then see http://www.security-hacks.com/2007/05/18/top-15-free-sql-injection-scanners

Read the rest of this entry »

As promised the extended scanner has been released with more intelligent exploitation algorithms to enumerate the SQL backend database. Of course credit should be given where credit is due and the algorthms are all from Ch 9 Network Security Tools by Justin Clarke et al. The only thing I have added is the MySQL code as my demo app has a MySQL backend. Before I chat about this, the code can now perform the following:

Of the above points, the last point is a little dubious when it comes to MySQL. You see, to enumerate the data type of a MS SQL column, you first try a string. If there is no error then it is a string. If not then try a date. If there is no error it is a date. If not then try an integer. Hopefully it is an integer, otherwise the code throws an error. MySQL behaves a little differently when employing the above algorithm. Say you have an integer and you try a string, unlike MS SQL the MySQL databse will have a warning in the backend (which is not visible via the app) but will allow the string. Hence, all columns are enumerated as strings even if the actual backend contains an integer. Nonetheless, the reason to identify the string columns is important so that you can later inject a query to retrieve sensitve information via these string columns. So if MySQL allows strings through integer columns, theoretically then it may not matter if it is a string or an integer and you can retreive the data via any column…this is yet to be tested.

Might chat with Justin to see if he can incorporate MySQL into his tool SQL Brute. For those unaware, when you find the above SQL injection, all you need to do is point his tool at the string columns and it will enumerate (via brute force) the rest of the database procedurally. That is, database names, database tables, database columns and finally database data. You can find a real nice howto here.

Note that I did not incorporate my other promises of more advanced Ruby libraries and better object oriented design schemas. I have kept the code as close to the original so that you at home can follow along with the book. Sorry for those who wanted something with a little more grunt but you are going to have to wait a little while longer…

Nearly forgot: To download click here