PDF de programación - El regreso de los Boinas Negras Solución al II Reto de Hacking Web

Publicado en la revista @rroba, nº 74, pp. 22-26. Noviembre, 2003. © Román Medina-Heigl Hernández.


El regreso de los Boinas Negras
Solución al II Reto de Hacking Web – “Boinas Negras II”

Ya se empieza a convertir en una tradición. La primera edición de “Boinas
Negras”-hace casi año y medio- causó furor por aquel entonces por ser quizás el
primer reto de autenticación web celebrado en España, además de ser
particularmente divertido. Este año se ha celebrado una nueva edición y, como ya
ocurriera en su primera entrega, también hemos participado y logrado pasar con
éxito todas y cada una de las pruebas. Este artículo narrará detalladamente los
pasos seguidos para alcanzar nuestro propósito, esto es, finalizar con éxito el reto.





Recordando los orígenes




Se está convirtiendo es una práctica cada vez más frecuente: una empresa de
seguridad lanza un reto o “wargame” al público, con el fin de auto-publicitarse y de
paso divertir a la gente. Si encima ofrece premios a los primeros que consigan pasar
todas las pruebas se incrementará aún más el grado de interés y competitividad
despertado entre las masas. Este último detalle resulta diferenciador si lo comparamos
con los muchos wargames existentes en la Red donde no hay ni premios ni prisas.


Una segunda característica diferenciadora es el grado de realismo del reto:
“Boinas Negras” siempre ha sido bien considerado en este sentido, por constar de
pruebas basadas en fallos típicos y reales que nos podemos encontrar hoy en día en



1

cualquier página web de Internet. Dicho de otra forma: para resolver el reto habremos
de valernos de técnicas reales y actuales de hacking ético. Resulta atractivo, ¿verdad?







¿Por qué “Boinas Negras”?


Peculiar nombre, sí señor. En este juego de palabras se mezclan varios
ingredientes. Por un lado, los conocidos “black hats” (que podríamos definir como una
especie de hackers maliciosos y no muy bien vistos por la Comunidad o gente inmersa
en el mundo de la seguridad) y algo tan peculiar y simpático como nos puede resultar
una boina. Si a esto añadimos premios un tanto simbólicos como una tabla de quesos,
un jamón o una boina enseguida nos daremos cuenta del particular tono burlesco con el
que los organizadores del concurso han querido dotar al mismo. Este hecho es cuanto
menos curioso y en algunos casos puede resultar hasta atractivo.






2

El concurso


“Boinas Negras I” (http://www.boinasnegras.com/autenticacion/) consistió en
diez niveles en la mayoría de los cuales la idea era conseguir vencer un formulario de
autenticación web. Es decir, se partía de una ventana donde se nos pedía usuario y
contraseña, y debíamos conseguir saltárnosla, sin conocer de antemano el usuario y
contraseña correctos. Para ello había que jugar con las cookies, el código HTML y
JavaScript (y hasta ASP) de la página e incluso aplicar técnicas un poco más elaboradas
como la inyección SQL o la explotación de errores de tipo XSS (“Cross Site
Scripting”).


El concurso de este año –“Boinas Negras II” (http://www.boinasnegras.com/
tienda/)- ha resultado algo diferente. En esta ocasión, tan sólo disponíamos de cinco
niveles a superar y el protagonista ha sido sin lugar a dudas la inyección SQL (por otro
lado quizás la técnica actual más usada en el hacking de aplicaciones web junto con los
bugs XSS). El escenario escogido para todo el desarrollo del juego ha sido una tienda
virtual especialmente desarrollada para el evento y ubicada en:
http://www.tiendabn.com/






Como la mayoría de vosotros sabréis es fácil implementar una tienda de estas
características. Lo normal es utilizar un motor de bases de datos (como MySQL en
Unix, o SQL Server si se ha optado por Windows), donde guardaremos todos los datos
(listado de productos y precios que vendemos, clientes, etc.), y al cual lanzaremos
consultas SQL para acceder rápidamente a la información que necesitemos. La
aplicación web propiamente dicha se suele realizar en un lenguaje como PHP o ASP
(por citar algunos). En el caso que nos ocupa, todo está implementado bajo Windows:
concretamente sobre IIS, SQL Server y ASP.net.




3

Basado en el escenario anterior nuestra meta es lograr alcanzar cinco objetivos

diferentes dando lugar por tanto a los cinco niveles del juego:


(cid:131) NTC: Obtener el número de tarjeta de crédito del cliente con login "gonzalo"
(cid:131) J1: Comprar un jamón, valorado en 350,00 euros, por 1,00 euro
(cid:131) XSS: Encontrar un agujero de cross-site scripting
(cid:131) BD: Obtener el nombre de usuario bajo el que se ejecuta la base de datos del

(cid:131) CC: Obtener los contenidos del carrito de la compra del cliente con login

backend

"capitan_hispania”






A continuación veremos cómo resolver cada una de las pruebas. El orden de
resolución de las mismas en principio es indiferente ya que los niveles no están
numerados. Sin embargo y por claridad vamos a abordar los distintos niveles siguiendo
el mismo orden que yo seguí para solucionar el reto. Como es normal las pruebas más
difíciles preferí dejarlas para el final.


Nivel J1


El objetivo es comprar un producto a un precio diferente del marcado en la
tienda. En concreto, debemos comprar el jamón que podemos encontrar a un precio de
350 euros pero invirtiendo sólo la módica cantidad de 1 euro (sustancial rebaja). Para
ello, nos dirigimos a la sección de “productos” de la tienda, entramos en “alimentación”
y seleccionamos “Jamón ibérico”. Estaremos viendo la descripción del producto
seleccionado, su precio y se nos ofrecerá la posibilidad de añadirlo a nuestro carrito de
la compra. La URL correspondiente es:
http://www.tiendabn.com/publico/caracteristicas.aspx?id=1



4







Si miramos con atención el código HTML de la página veremos que hay un
formulario. Lo primero que llama la atención son unas variables extrañas con
extravagantes valores. Por ejemplo:

<input type="hidden" name="__VIEWSTATE" value="dDwx [...] YHJ9nDsCGrvgIWgvj" />

ASP.net utiliza este tipo de variables para mantener cierta información de estado. Lo
primero que se me ocurrió fue buscar información sobre su posible explotación. Aunque
encontré la forma de decodificar la variable (http://www.wilsondotnet.com/Demos/
ViewState.aspx) no me resultó útil.


Seguimos pues observando nuevas variables. En particular:

<input name="PrecioProducto" id="PrecioProducto" type="hidden" value="350" />

Bingo: el precio se pasa como un parámetro escondido. ¿Qué ocurre si lo alteramos?
Probamos a cambiar el valor “350” por “1” (para ello basta con copiar la página a un
fichero HTML local y editar éste, sin olvidar añadir la URL completa en el campo
“action” de la etiqueta <form>, para posteriormente “abrirla” con nuestro navegador
favorito; o bien, usar alguna aplicación como “Proxomitron” para alterar las peticiones
HTTP en tiempo real) y pinchamos en “añadir al carrito”. Pero no iba a ser tan fácil: no
conseguimos consumar la compra (la aplicación de la tienda detecta que hemos alterado
el precio). ¿Cómo funciona este chequeo?


Fijémonos en otro parámetro:

<input name="Firma" id="Firma" type="hidden" value="E+42yAfxBZ2T92KJ0T0Y0yJYvdo=" />

Se trata de otro campo escondido que contiene un “hash” o firma digital. No sabemos a
priori el método empleado para la generación de dicha firma ni exactamente a partir de
qué variables o campos se ha creado, aunque resulta evidente que al menos una de esas



5

variables es el precio del producto (ya que al variar el precio la comprobación de firma
falla). Otra prueba que podemos hacer es dejar el precio intacto y modificar la firma: la
comprobación falla. Nuestra forma de actuación será entonces
la siguiente:
modificaremos tanto el campo de precio como la firma. El problema es el siguiente:
¿cómo recalcular la firma sin ni siquiera conocer el algoritmo de hashing empleado?


Hemos llegado a un aparente callejón sin salida pero… ¡todavía nos quedan
variables por mirar! En particular, podemos ver una variable “Debug” que está a “Off”.
Lo que hacemos es convertirla en un “On” y falsear de nuevo el precio del formulario.
Una vez más la comprobación de firma resulta errónea pero esta vez obtenemos en
pantalla información de depuración donde se nos indica el valor de la firma empleada
en el chequeo y la que la aplicación esperaba:

"Los datos han sido manipulados.
Valor recibido: E+42yAfxBZ2T92KJ0T0Y0yJYvdo=.
Valor recalculado: Kdmf9QIHGvpMzEjqVx0YZIPgXNQ=."






Dicho de otra forma, la aplicación de la tienda ha calculado el hash
correspondiente al nuevo precio y nos la muestra en pantalla. Ya sólo resta falsear el
campo de firma e introducir el nuevo valor junto con el precio de “1”. El producto ha
sido añadido a nuestro carrito, con un valor de 1 euro. Ahora sólo resta hacer clic en
“pasar por caja”, para efectuar la compra.


Nivel CC


Existe un cliente ya registrado en la tienda cuyo nombre de usuario es
"capitan_hispania". La prueba consiste en obtener el contenido exacto de su carrito de la
compra. Nuestro primer paso será investigar cómo identifica la aplicación a diferentes
usuarios de la tienda para lo cual iremos a la sección de “Miembros”. No disponemos de
login y contraseña así que optaremos por crear un nuevo usuario. A continuación
examinamos la cookie y la comparamos con la de otros usuarios que también nos
habremos creado para hacer pruebas. Observando las diferenci