Es por eso que arrancamos el año a puro training! Durante el 2011 seguimos dictando trainings abiertos y sumamos a nuestros cursos tradicionales un nuevo training basado en OWASP Top 10.

Abril

15 de Abril de 2011 :: Training basado en OWASP Top 10 :: Lanzamiento!

El training basado en el OWASP Top 10 está focalizado en las vulnerabilidades Web clasificadas por OWASP como de alto riesgo. Durante este curso de un día se explicará teóricamente cada vulnerabilidad con prácticas hands-on, demostraciones y las contramedidas necesarias para mitigar dichas vulnerabilidades

Pensado especialmente para desarrolladores, programadores, QA, Analistas de Seguridad Informática, etc.

$ 1.100 ARS + IVA por persona *15% off * si te anotas antes del 21 de marzo.

Junio

:: Web Application Security Training

El training de Web Application Security de Bonsai se focaliza en el descubrimiento y explotación, manual y automático, de vulnerabilidades en aplicaciones Web. Durante este curso de dos días, se presentarán una serie de temas teóricos seguidos de prácticas hands-on realizadas por los asistentes. En cada práctica encontrarás vulnerabilidades para explotar, cada una con un nivel diferente de complejidad, las que desafiarán tu comprensión del tema.

Nuestra experiencia en capacitación nos ha ayudado a crear el mejor training de Web Application Security, el cual está orientado a la comprensión del código fuente: para cada tema se presenta un segmento de código vulnerable e independientemente del lenguaje, los asistentes aprenderán sobre vulnerabilidades en Java, PHP, ASP.NET, ASP, Ruby y Python.

Durante la primer hora, se repasarán conceptos básicos de HTTP y técnicas genéricas de descubrimiento de vulnerabilidades, para luego incrementar gradualmente el nivel de dificultad hasta llegar a comprender y ejecutar los ataques de mayor complejidad.

El training está diseñado para administradores, consultores, oficiales y responsables de Seguridad Informática; desarrolladores de aplicaciones Web, expertos en Quality Assurance, Administradores de Aplicaciones Web, etc.

Próximas Fechas

Y todavía hay más! Vamos a estar dictando cursos en los meses de Julio, Septiembre y Noviembre. En cuanto tengamos las fechas exactas de los mismos, las publicaremos en nuestro Google Calendar, y se irán actualizando por este medio también.

Consulte descuentos a grupos y cursos modalidad in-company

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 (ryan@bonsai-sec.com) 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 'root@localhost' 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 'root@localhost' 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.