Archive

Archive for July, 2009

Web Application Security training @ FRHACK

July 29th, 2009

I’m going to be delivering a Web Application Security training at FRHACK next September 2009! FRHACK is a highly technical, non-business conference that is going to be held at Besançon, France. The training is a two day, hands-on class where the w3af project leader will train you in the techniques and methodologies needed to discover and exploit web application vulnerabilities.

Here is some extra information regarding the training,

Training name: Discovery and exploitation of web application vulnerabilities

Overview

This training course focus is on manual and automated, discovery and exploitation of web application vulnerabilities. During this course you are going to go through a series of lectures followed by hands on practice. In each practice you will find vulnerabilities to exploit, each with a different level of complexity, which will defy your understanding of the subject. After the hands on practice, a small lecture on how the vulnerability is fixed is presented, together with common errors introduced by developers in that process.

The training will also teach you how to use the most advanced tools used by professionals in the field, like w3af (developed by the trainer), the burp suite, sqlmap and many others.

Course Structure

This is a two-day course that combines lectures with increasingly difficult hands-on exercises designed to teach the attendee different ways to discover and exploit web application vulnerabilities. All course materials, and a certificate of completion will be offered. You must provide your own laptop.

Deliverables

- Training booklet with printed slides and trainer comments
- Live CD with Web Application Security Tools
- VMware image with the training environment
- w3af T-Shirt ;)

Audience

Security consultants, system and network administrators, experienced web application developers, information security officers, government agencies.

Topics Covered

  • Day One
    1. HTTP protocol review
      • Web architecture
      • HTTP headers and methods
      • HTTP authentication
      • HTTPS
      • Session management: cookies
    2. Common web server misconfigurations
      • Banners
      • Directory Indexing
      • HTTP authentication
      • HTTP method restrictions
    3. Common development and configuration errors
      • HTML comments and versioning
      • File inclusions
      • Backup and local database files
      • Hidden HTML Fields
      • Path Disclosure and directory enumeration
      • Exceptions and error messages
    4. Types of analysis
      • Static code analysis, black box testing and gray box testing:
      • Definitions
      • Vulnerabilities that can be detected
      • Vulnerabilities that CAN’T be detected
    5. Web Application Vulnerabilities
      • Reverse engineering of Java applets y Flash movies
      • Local file read
      • Local file inclusions
      • Path Traversal and Null Bytes
      • Remote file inclusions
      • Cross Site Scripting (XSS)
      • Cross Site Tracing
      • Cross Site Request Forgeries / Session Riding
      • HTTP Response Splitting
  • Day Two
    1. Web Application Vulnerabilities
      • Uncommon attack vectors
      • LDAP Injection
      • OS Commanding
      • SQL Injection:
        • Enumeration of tables and columns
        • Execution of queries and stored procedures
        • Creation of files
        • Execution of OS commands
      • Blind SQL Injection
    2. Web application privilege escalation
      • Session handling
      • Logical vulnerabilities
    3. Countermeasures
      • mod_security
      • Hardening for Java
        • HDIV
        • Spring Security
      • PHP hardening:
        • Secure configuration parameters
        • GRASP
        • PHP-IDS

andres.riancho bonsai, conferences , , , ,

Not the average SQL Injection

July 19th, 2009

SQL Injections are one of the most common and most critical Web application vulnerabilities that can be identified during a Web Application Penetration Test. SQL injections can occur in any part of a SQL query, but they usually occur in the “where_definition” section, to clarify what I’m talking about, here’s the syntax definition for the SELECT statement for MySQL:

SELECT
[ALL | DISTINCT | DISTINCTROW ]
[HIGH_PRIORITY]
[STRAIGHT_JOIN]
[SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT]
[SQL_CACHE | SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS]
select_expr, ...
[INTO OUTFILE 'file_name' export_options
| INTO DUMPFILE 'file_name']
[FROM table_references
[WHERE where_definition]
[GROUP BY {col_name | expr | position}
[ASC | DESC], ... [WITH ROLLUP]]
[HAVING where_definition]
[ORDER BY {col_name | expr | position}
[ASC | DESC] , ...]
[LIMIT {[offset,] row_count | row_count OFFSET offset}]
[PROCEDURE procedure_name(argument_list)]
[FOR UPDATE | LOCK IN SHARE MODE]]

While performing some vulnerability research in e-commerce Web applications, Ryan Dewhurst ([email protected]) found a rather uncommon SQL Injection vector in the “col_name” section of the SELECT query, which at first looks like the average SQL Injection, but when actually trying to exploit it we discovered that it was more difficult than expected. This is the code snippet for the vulnerability, were we only control the $sort_order value:

$userlog = db_get_array("SELECT change_id, action, timestamp,
                         amount, reason FROM points_table
                         WHERE user_id = ?i ORDER BY $sort_by
                         $sort_order $limit", $user_id);

First of all, no SQL Injection tool works with this type of SQL injection. The reason is that they all assume that they are going to be injecting in the where_definition part of the query, and in this case that assumption is false. So we went back to the SELECT syntax, and we found that we had not much space to play:

[ORDER BY {col_name | expr | position}
[ASC | DESC] , ...]
[LIMIT {[offset,] row_count | row_count OFFSET offset}]
[PROCEDURE procedure_name(argument_list)]
[FOR UPDATE | LOCK IN SHARE MODE]]

The first idea was to use a UNION clause in order to join two different queries, the one controlled by the web application, and the other controlled by us; which seemed to be a good idea, but a flawed one also:

  • select 1,2,3 union select 4,5,6 Works perfectly.
  • select 1,2,3 order by 1 ASC union select 4,5,6 Throws an "Incorrect usage of UNION and ORDER BY error."
  • (select 1,2,3 order by 1 ASC) union (select 4,5,6) Works perfectly, but we can't add the "(" at the beginning of the query.

UNION was out of the picture.

Without even noticing that I was testing something syntactically incorrect, I tried to write a file to disk using “INTO OUTFILE”, and surprisingly enough, it worked. But the problem is that we can’t control the contents of the file, because in this particular Web application we had no control of the contents of the points_table, so once again we’re were we started because we can’t write a PHP shell to disk.

So the next step was to find a way to execute a SELECT statement after an ORDER BY, the best thing that we could find was to inject a sub-SELECT statement in the col_name section of the order by. Finally the SQL injection ended up like this:

,(SELECT BENCHMARK(1000000,MD5(1)) FROM points_table where
CURRENT_USER() like '[email protected]' limit 1)

Which makes,

SELECT change_id, action, timestamp, amount, reason FROM
       points_table WHERE user_id = i ORDER BY timestamp,
       (SELECT BENCHMARK(1000000,MD5(1)) FROM points_table
        where CURRENT_USER() like '[email protected]' limit 1)

The only problem is that this injection only works if the first SELECT statement actually has more than one row to order (this is because of MySQL performance enhancements). So to be able to exploit this particular SQL injection, we had to buy two items from the e-commerce store in order to add a couple of rows to the points_table, which would then trigger the sub-select in the order by section of the query.

The above injection can be modified to perform almost any query to the database, which leads to total e-commerce web application compromise.

The conclusion is simple: while automated tools can help is in many cases, an experienced security professional can never be replaced.

andres.riancho security ,