Today web applications become more and more popular and process a huge amount of critical information: financial, private and sometimes even military kinds. To mitigate risks in it we can implement secure software development circle and security testing as part of it. There are 4 basic techniques for analyzing the security of a web application:
- Automated scanning
- Manual penetration testing
- Static analysis
- Manual code review
w3af is an Web Application Attack and Audit Framework and it can be used in the first two activities. It is an open source project (GPLv2) created by Andres Riancho and developed by him and a group of contributors from around the world. w3af is written in Python which as you know very powerful language "with batteries". Batteries of w3af are plugins - it has at least 143 ones!
w3af is divided in two main parts: the core and the plugins. The core coordinates the process and provides features that plugins consume. Plugins find the vulnerabilities and in some cases are able to exploit them! Plugins share information with each other using a knowledge base.
In w3af we have 8 different types of plugins each for various purpose. Discovery plugins finds new URLs, forms, etc. and creates a complete sitemap. webSpider is one of them and is classic example of web spider engine which parses HTTP response and extract links, forms, image sources and so on. Discovery plugins runs in loop - the output of one discovery plugin is sent as input to the next plugin. This process continues until all plugins fail to find a new resource.
Audit plugins takes the output of discovery plugins and find all kinds of vulnerabilities like SQL injection, XSS and others. As I think audit plugins are main in w3af plugins hierarchy.
Bruteforce plugins bruteforces the HTTP Basic and Form Login authentications that are found during the discovery phase. For example, formLogin plugin automatically detects login forms by finding forms with two parameters, one of them of type text and the other one of type password. Once the username and password fields are identified, the bruteforce starts automatically.
Attack plugins reads the vulnerability objects from the KB and try to exploit them. Yes, these ones can give you the shell ;)
Mangle plugins allows modification of requests and responses based on regular expressions like sed stream editor. Evasion plugins tries to evade simple intrusion detection rules.
Output plugins writes framework messages to different locations (different format files) and usually are used for generating of reports.
Scanning a web application
Well, we have reviewed the architecture of w3af. Now it is time to see w3af in action. Let's scan some web applications! For demonstration purposes I have made a simple but very sociable web application called Itter. Yes, it is micro-blogging service and hope that it will become as popular as twi..OK, it is joke :) This testing web application has following characteristics:
- LAMP (Linux-Apache-MySQL-PHP) stack
- search, private messages
- authentication protected user area
- usage of AJAX capabilities
- has vulnerabilities!
For the first we will test our web application without logging-in like "cold start".
w3af has 2 user interfaces: one based on GTK toolkit and console UI with auto-complete feature for console hackers.
For GUI version simply type in the console
./w3af_gui and you will see something like on the picture:
There are Profile, Plugins, Target sections and Toolbox. Profile is a file where the scan configuration
(including target, misc and HTTP settings, enabled plugins) is saved. For testing Itter I have made "My Profile"
configuration with webSpider and pykto (python port of famous Nikto tool) to find target URLs,
some grep plugins to find anything strange and interesting in HTTP transactions like DOM-based XSS
and some audit plugins like XSS and SQLi to find appropriate security holes. Pressing Start button and waiting for
the first results. We can monitor scan progress on Log tab - console with application messages, progress bar and time
diagram will help us. Scan finished in about 20 minutes and we have the results. Oh, besides server configuration
flaws like Apache web server status page and suspicion on DOM-based XSS w3af has found XSS vulnerabilities!
Let's discover it. For the first of course XSS flaw - w3af has found it in
/index.php and some other scripts.
Pykto plugin has found Apache web server status page and phpinfo()
From other plugins we has determined web server name, version and web platform - in our case it
are Apache/2.2.16 on Debian GNU/Linux system and PHP as programming language with enabled
Another cool feature which helps us to better understand web application structure is URLs tab with graphical representation of testing web application map and traditional tree-list. By clicking on target point on the map you can zoom it in/out.
Testing web 2.0 applications
[Mon 30 May 2011 12:08:22 AM MST] spiderMan proxy is running on 127.0.0.1:44444. Please configure your browser to use these proxy settings and navigate the target site. To exit spiderMan plugin please navigate to http://127.7.7.7/spiderMan?terminate . [Mon 30 May 2011 12:15:29 AM MST] The user is navigating through the spiderMan proxy. [Mon 30 May 2011 12:15:29 AM MST] Trapped fuzzable requests: [Mon 30 May 2011 12:15:29 AM MST] http://localhost/index.php | Method: GET [Mon 30 May 2011 12:15:32 AM MST] http://localhost/user-info.php | Method: GET [Mon 30 May 2011 12:22:36 AM MST] SQL injection in a MySQL database was found at: "http://localhost/user-info.php", using HTTP method GET. The sent data was: "id=d'z"0". This vulnerability was found in the request with id 3911. [Mon 30 May 2011 12:27:10 AM MST] Cross Site Scripting was found at: "http://localhost/index.php", using HTTP method GET. The sent data was: "limit=15&u=<ScRIPT>a=/UzmE/%0Aalert(a.source)</SCRiPT>". The modified parameter was "u". This vulnerability affects ALL browsers. This vulnerability was found in the request with id 4042.
As you can see after stopping usage of spiderMan by navigating to special URL webSpider have found some new targets and audit plugins have found SQL injection and XSS vulnerabilities. The first one in AJAX request.
w3af also has capabilities to exploit some types of vulnerabilities, e.g. even can give you the desired shell on the target system! To exploit the vulnerability, you need to drag the exploit and drop it on the vulnerability you want to exploit. For our example with SQL injection it can be built-in version of famous sqlmap.
w3af has a number of GUI tools for manual work with HTTP transactions. Among them:
- Sending automated HTTP requests e.g. for explore SQL injection point
- Manual request editor can be used to send HTTP requests to the remote web server
- Encode and decode strings: URL encoding, base64, MD5 hash and so on
- Compare HTTP responses may be useful when you finds blind SQL injection and need to know differences between HTTP responses
- Intercepting Proxy
- Export requests
Launching proxy tool starts local proxy server (don't forget, you need to tune you web browser to use it).
Navigating through our testing social service. History tab shows us all HTTP transactions between web browser and
server. In case of really big applications there will be a lot of items but we can filter it in various ways.
For example show only transactions with parametrized request and 2xx response.
When mouse pointer hovers over user avatar we see that in background web application sends AJAX request
/user-info.php?id=1 to the web server to get user information for pop-up area. It is very interesting!
Lets test this page against some vulnerabilities by pressing "Audit request with..." button and selecting sqli.
Bingo! We have found a SQL injection! It is classic error based SQL injection. In case of blind SQL injections
we can use special blindSQli plugin but lets assume switched off error displaying and try to find it manually.
Using Manual request editor sending 2 requests with different ID values:
/user-info.php?id=1%2b1, then sending it to Compare tool.
As you can see our algebraic expression works correctly inside SQL interpreter and we get user information for user with ID 2. Further steps can be of course exploitation with w3af's attack plugins or manually.
Now we have seen w3af in action and it is really powerful tool for security testing of web applications. But framework is not buzzword in the definition of w3af - number of plugins is striking demonstration for it. It is really easy to extend its functionality, you can write your own plugin for various purposes. But it is a good reason for writing the next article.