1. SecuBat: An Automated Web Vulnerability Detection Framework
Stefan Kals, Engin Kirda
Christopher Kruegel and Nenad Jovanovic
Secure Systems Lab
Vienna University of Technology
Austria
Thank you, xxx.
Good morning and welcome to my presentation on SecuBat, an automated web vulnerability scanner. We carried out this project the last 12 months at the Secure Systems Lab of the Vienna University of Technology in Austria.

2. Outline Motivation Problem Definition Typical Vulnerabilities
Automated Attack & Analysis Concepts
SecuBat Implementation
Related Tools
Prototype Results
Findings & Case Study
Let me start by listing each presentation part i have prepared for you today.
First of all, i will briefly discuss some of the common problems in the area of web security which motivated us to initiate the SecuBat project in the first place.
After analyzing the problems out in real life, we defined for ourselves, which parts we will consider and which we‘ll ignore.
In the third part of this speak, i am going to introduce you into the common vulnerability types on the web which we selected as targets.
After describing these typical security issues, i will mention already existing projects and products out on the market addressing similar areas as we do but providing you with distinguishing criterias.
This will be the moment, when we dive into the details of our way of finding vulnerabilities describing the automated detection approach.
After explaining the generic detection approach, i am going to speak about the concretely implemented attack and analysis modules and of the SecuBat architecture in whole.
In the end, i will show you the interesting detection results and one exemplary case study of a found vulnerability to demonstrate the effectiveness of SecuBat.
2006/05/25
SecuBat: An Automated Web Vulnerability Detection Framework, © 2006 Stefan Kals

3. Motivation Highly increasing number of web applications
Developers lack awareness of typical vulnerabilities
The „Why me?“ belief
Manual vulnerability checking causes much work
Automated tool would solve the problems and raise the security level
Well, where did the motivation came from driving us into performing this project?
First of all, as you all know, the commercial use of the web is increasing every day. At whatever business area you look, web applications spring up like mushrooms. Obviously, with every new business-critical application out in the web, the role of security and privacy is rising.
Apart from the big advantages this service oriented infrastructure brings to every one of us, vulnerabilities in such applications offer much more damage potential than former approaches. Unfortunately, especially web developers even nowadays often lack the awareness of typical web application vulnerabilities and the knowledge of how to avoid them.
Additionally, they don‘t even think of being an interesting target for attackers: Developing just one new web application under millions, one could easily believe that it just will not be attacked.
Why is it difficult for developers to secure their web applications? Because of the big effort needed to manually check the application for a big number of common vulnerability types. So the way out of this dilemma would be an automated tool which relieves this work from the developer.
2006/05/25
SecuBat: An Automated Web Vulnerability Detection Framework, © 2006 Stefan Kals

4. Problem Definition
Demonstrate how easy an attacker can find soft targets on the web if web vulnerabilities are not fixed
Implement a crawling engine for collecting potential targets
Find generic and automatically executable attack techniques for the chosen approaches (SQL Injection, Cross-Site Scripting)
Find suitable analysis techniques
Assemble these parts together into a pluggable vulnerability analysis and detection framework
So our self-defined way started with doing research on the field of typical web attacks and their approaches. Concentrating on the development of the prototype implementation we decided to analyze and develop attack modules for two main attempts: SQL injection and Cross-Site Scripting. I am going into detail on these two approaches later.
Beside from letting users self-define target web addresses, the second goal of the SecuBat framework was to implement a crawling engine which allows for automatic target accumulation.
More difficult but necessary was a detailed analysis of the selected attack approaches and the translation into a formal and automatically executable algorithm.
But the most sophisticated part of this project was probably implementing a functional and determinable algorithm analysing the results of the attacked web server.
For making sense, all of the mentioned sub-parts of this project had to be assembled together to create a usable tool. Designing this tool as generic as possible and implementing a plugin-interface for new modules, the SecuBat framework was outlined.
2006/05/25
SecuBat: An Automated Web Vulnerability Detection Framework, © 2006 Stefan Kals

5. Typical Vulnerabilities 1/2 – SQL Injection
Problem: No input validation before using values to query database
Dynamically built SQL query: q = “select * from user where mail=‘“ + mail + “‘ and pw=‘“ + pw + “‘“
Enter values using SQL syntax: mail: ‘ or 1=1-- password: ‘ or 1=1--
Query has changed its semantics: q = “select * from user where mail=‘‘ or 1=1--‘ and pw=‘‘ or 1=1--‘“
Resulting query: q = “select * from user“
The next two slides address the security issues covered by SecuBat in its current prototype status. They both have in common that the malfunction of the web application is triggered by malicious user input using forms in web pages.
The first vulnerability I will discuss, is the SQL injection. A SQL injection vulnerability is caused by the absence of sufficient input validation combined the technique to dynamically build SQL queries with the user input. Let me clarify the concept of a SQL injection with the following example.
Here you can see a typical line cut out of a login script of a secured web application. In this line, a SQL query is concatenated using static parts like the “SELECT * FROM” and so on and user input like the mail address and the password. Notice the quotes used for the string comparison. Let’s assume that the web application queries all users matching the given mail address and password and gives access to the secured area if at least one was found.
An attacker could now try to execute a SQL injection by just not entering valid data but providing the form with the following values. As you can see, using SQL syntax is the key to success.
When the web application now concatenates the strings, the following SQL query results. With the help of a quote at the beginning of each field, the comparison value quotation gets closed. The following “OR one equals one” condition clears out all other conditions by equating to true every time. Using the comment SQL syntax characters, the rest of the query gets ignored by the SQL server.
Summarizing the injection, this is semantically the resulting query which grants the attacker access to the secured system by always returning at least one matching user from the database.
2006/05/25
SecuBat: An Automated Web Vulnerability Detection Framework, © 2006 Stefan Kals

6. Typical Vulnerabilities 2/2 - Cross-Site Scripting
Injecting HTML/Javascript by attacker – displayed & executed in victim’s browser
Reflected vs. Stored XSS
Stealing of user data (Cookies, Credentials…)
Example: Redirecting login form to hacker’s web server
Create exploit URLs & use for authentic Phishing s
The second and even more interesting vulnerability we decided to address is the so-called Cross-Site Scripting attack. The main goal of an attacker trying to use this technique is to inject malicious code into web pages which then gets executed in the victims browser.
This can be achieved by tricking the victim into clicking a link or posting a web form causing the malicious code getting executed within the result web page. Because of the reflection of the script by the web server, this variant is called a “Reflected XSS attack”.
Apart from this variant, an attacker can store the malicious code in a suitable web application like a bulletin board or a blog. Every user viewing the attacker’s message in the web application will then have the script executed by the browser. This variant is called a “Stored XSS attack”.
Exploiting an existing XSS vulnerability, many possibilities arise to the attacker. The malicious code is executed in the clients browser and so has access to private data like cookies and user credentials. One interesting example for such an exploit might be the redirection of an existing login form to the attacker’s server. Creating such an exploit URL for a major e-commerce site and using it in a Phishing mail would enable the attacker to collect a bunch of valuable login credentials.
2006/05/25
SecuBat: An Automated Web Vulnerability Detection Framework, © 2006 Stefan Kals

7. Attack & Analysis Concepts 1/4 - General
Open framework for easily implementing & adding new attacks
Attack & Analysis modules (Black Box)
Runtime configurable Plugins
Use common Crawling and Attacking APIs
Store analysis results into database
After presenting you with the general workflow concept, let me introduce you into our concrete attack and analysis concepts.
?? Folie weglassen ??
2006/05/25
SecuBat: An Automated Web Vulnerability Detection Framework, © 2006 Stefan Kals

8. Attack & Analysis Concepts 2/4 - SQL Injection
Attack module prepares new attack & sends it to server (e.g. single quote)
Server sends back a response page
Analysis module parses response for keywords, builds summary confidence factor
Black box approach.
For simulating a SQL injection attack, SecuBat prepares data for posting the target web form, for example a single quote only.
After posting the web form, SecuBat waits for a response page from the target server.
When the response page is received, it gets parsed for recurrences of preconfigured keywords.
Assuming that the web application uses the posted user input for building a SQL query, the injected quote must have caused a syntax error. Using a weighted keyword search on the response page for phrases like “MySQL”, “Server Error” or “exception occurred”, we try to detect response pages containing a server error.
q = “select * from user where mail=‘ ‘ ‘ “
2006/05/25
SecuBat: An Automated Web Vulnerability Detection Framework, © 2006 Stefan Kals

9. Attack & Analysis Concepts 3/4 - XSS Attack
Attack module prepares new attack & sends it to server (e.g. Javascript to show a message box)
Server sends back a response page
Analysis module parses response checking for the occurrence of the injected string (and the executability)
Similar to the SQL injection discussed before, our XSS attack module posts user input to the target web server. Different than before, the XSS attack is done by trying to inject a javascript code snippet.
After the server sends back the response page, SecuBat analyses it and searches for complete and executable recurrences of the injected script code. If SecuBat finds the injected code snippet in an executable way, it marks this page as vulnerable.
?? Input validation vs XSS vulnerable ??
2006/05/25
SecuBat: An Automated Web Vulnerability Detection Framework, © 2006 Stefan Kals

10. Attack & Analysis Concepts 4/4 – Enhanced Attacks
Enhanced XSS attack
Uses decimal HTML encoding to bypass input filters
Replaces characters, e.g.: ‘ => '
Form-Redirecting XSS scenario
Checks for potential assets (stealable credentials)
Uses an encoded injection string redirecting the found login form to the “attacker‘s server”
Simulates a real XSS attack, does not only check input validation
2006/05/25
SecuBat: An Automated Web Vulnerability Detection Framework, © 2006 Stefan Kals

11. SecuBat Implementation 1/2
The next two slides briefly discuss the architecture and implementation of the SecuBat framework. As you can see, SecuBat is built using a classical three-tier layer architecture with a User Interface, a Business Logic and a Data layer.
The user interface consists of the main window which informs the user about the current progress and some additional windows for configuration and reporting of historical analysis data.
The business layer consists of modules which are used for crawling, attacking, thread & workflow management, plugin handling and so on. Additionally to these built-in modules, additional attack and analysis plugins can be configured to be used by SecuBat.
At the bottom of the diagram you can see the data access module which handles all data flow from and to the database.
2006/05/25
SecuBat: An Automated Web Vulnerability Detection Framework, © 2006 Stefan Kals

12. SecuBat Implementation 2/2
Implementation Details C#
Data Store: MS SQL Database
Requirements
MS Windows 2000, XP, 2003
MS .NET Framework 2.0
MS SQL Server 2000/2005 or MSDE/SQL Express 2005
SecuBat was developed as Windows Forms application in Visual Studio using the programming lanugage C# of the .NET framework 2.0.
As data store we chose a SQL database within a Microsoft SQL server.
If you want to run SecuBat, you need an installation of a modern Windows, the new .NET framework 2.0 and any of the SQL server variants. Of course you can use one of the free versions, as there are MSDE and SQL Server 2005 Express, too.
2006/05/25
SecuBat: An Automated Web Vulnerability Detection Framework, © 2006 Stefan Kals

13. Related Tools Acunetix Web Vulnerability Scanner (commercial)
+ Web server technology detection
+ Application level attacks: Simple SQL injection, XSS
- Closed source, no papers, no details to the public
Nessus, Nikto
- Rely on repositories of known vulnerabilities
NMap, Xprobe...
- Port scanners only
- Network/OS level, no application level attacks
Check features!!!
Acunetix: No papers available (?), no details to the public
2006/05/25
SecuBat: An Automated Web Vulnerability Detection Framework, © 2006 Stefan Kals

14. Prototype Results Evaluation Run Results (Google search for „login“):
crawled pages
web forms
4 attack types
SQL Injection: 6,63%
Simple XSS: 4,30%
Enhanced XSS: 5,60%
Form-Red. XSS: 5,52%
Now we reach an interesting part of this talk, the results. Using the prototype version of SecuBat, we scheduled a complete testing run using all of our already existing attack plugins. After several hours, SecuBat had crawled about twenty-five thousand web pages including about twenty-one thousand web forms.
As you can see in the diagram, six-point-six percent of the attacked web forms were classified as vulnerable against SQL injection, four-point-three against the simple Cross-Site Scripting, five-point-six againts the encoded variant and five-point-five against the form redirecting XSS scenario.
After retrieving the list of vulnerable sites from SecuBat we verified a sample of the results by hand. While the SQL injection detection showed up to have some potential for improvement, the Cross-Site Scripting detection was very accurate.
XSS: 10% false positives
SQL: 40%
2006/05/25
SecuBat: An Automated Web Vulnerability Detection Framework, © 2006 Stefan Kals

15. Findings Critical XSS Vulnerabilities (assets) eBay (Auction access)
Austrian Finance Ministry (E-Government access)
Geizhals (Price management)
Crit.org (Security associated content)
Apple (Developer access) …
After verification, we had a long list of verified XSS vulnerabilities in web applications of well-known companies.
This list includes companies like Ebay and Apple but also governmental organisations like the Finance Ministry of Austria.
Exploiting such XSS vulnerabilities, one would be able to steal user credentials for abusing the offered services.
2006/05/25
SecuBat: An Automated Web Vulnerability Detection Framework, © 2006 Stefan Kals

16. A Case Study eBay.de Press
?? Live demo ??
As you can see, this exploit is perfect phishing because it can not be detected by standard anti-phishing products which verify the used domain name in URLs.
2006/05/25
SecuBat: An Automated Web Vulnerability Detection Framework, © 2006 Stefan Kals

17. Notifications Query recipients using WhoIs service 591 Mails sent
306 “recipient unknown”
48 detail inquiries after 1 week
?? Hide ??
2006/05/25
SecuBat: An Automated Web Vulnerability Detection Framework, © 2006 Stefan Kals

18. Conclusion
Increasing use of web technology needs increasing security effort
Rather simple attacks (SQL Injection, XSS Attack) but many vulnerable web sites
An automated detection approach can increase your site’s security
Implementation of an extensible (pluggable) analysis framework (“SecuBat”)
First results of a prototype version show proof of concept
Summarizing the SecuBat project we can state that the increasing use of web applications demands for an increasing effort in the security area, too.
While we implemented rather simple attacks into the prototype version of SecuBat, a large percentage of web applications showed up to be vulnerable.
What showed up quite clearly is that detecting application-level vulnerabilities using an automated approach could help us out of this dilemma.
So we planned and implemented SecuBat, an extensible attack and analysis framework for automatically scheduling attacks.
Already the first test run demonstrated the effectiveness of the approach and the analysis algorithms.
2006/05/25
SecuBat: An Automated Web Vulnerability Detection Framework, © 2006 Stefan Kals

19. The End http://www.secubat.org
For further information about the SecuBat project and a download link, visit
Thank you very much for your attention, if you have any questions, please feel free to ask them now.
The End
2006/05/25
SecuBat: An Automated Web Vulnerability Detection Framework, © 2006 Stefan Kals