Solución al Desafío ESET #21

Les presentamos la solución al desafío lanzado por ESET Latinoamérica la semana pasada. En dicho reto, había que probar la inocencia de uno de los trabajadores de una empresa de desarrolladores, verificando si por medio de la información filtrada por un malware se podría llegar a vulnerar la aplicación web.

Al analizar la captura de tráfico con Wireshark, encontramos el acceso a un servidor FTP donde se descarga un archivo de nombre data-intrusion.rar:

En la siguiente imagen tenemos los bytes en crudo al momento de transferir el archivo de una máquina a otra:

Dicho flujo puede ser reensamblado nuevamente con el botón “Save As”. Al abrir el RAR, tenemos un access.log, que no es mas que un fichero donde quedan almacenadas todas las peticiones que fueron ejecutadas en el servidor vulnerado.

Antes de seguir con el análisis, mostremos un poco el código del servidor para explicar el error:


Como pueden observar, este es el módulo principal de nuestro buscador. En la captura anterior, se puede notar como pasa directamente el parámetro “q” a la consulta SQL sin ser debidamente filtrado. Esto permitiría inyectarle porciones especificas de código SQL, beneficiando así al atacante. Miremos un claro ejemplo de inyección para ver de que estamos hablando:


En el anterior caso el parámetro “q se cargó con el valor inyectado‘ or ‘1’=’1″, y el servidor ha retornado la búsqueda correspondiente a trololo. Analicemos que paso aquí, la consulta final sobre la base de datos ha quedado como:

  • SELECT * FROM search WHERE palabraclave=’inyectado’ or ‘1’=’1′;

Esto será verdadero siempre y cuando la palabra clave sea “inyectado” o si “1 es igual a 1”. Como la segunda condición siempre será satisfactoria, se imprime el primer valor de la tabla:


Está claro que el servidor es vulnerable a una inyección SQL, pero… ¿como podemos probarlo a partir de los datos que tenemos?

Si prestan atención en la descripción del reto, se especificaba que en caso de que se realizara una búsqueda negativa se redireccionaba a otro buscador. Esto significa que en el access.log se van a ver dos tipos de códigos de respuesta ante la petición HTTP. Una sera 200, en el caso de una búsqueda positiva, y otra 302 marcando la redirección al buscador Bing. A continuación, se muestra un ejemplo:

Al tratar de buscar la palabra malware el buscador nos ha redirigido a Bing, guardando un 302 como respuesta del servidor. En cambio con la palabra Facebook, obtuvimos un código 200 ya que la misma se encuentra en la base de datos. Es decir, si en el log vemos una respuesta 200 sabremos que la base de datos procesó la petición como verdadera, y en caso contrario tendremos un 302. Este tipo de ataques se conoce como Blind Sql Injection.

Y en base a la respuesta afirmativa o negativa podríamos ir extrayendo carácter a carácter datos sensibles. Sin embargo, tengan en cuenta que la base de datos ya fue vulnerada, por lo tanto toda la información de interés está a nuestra disposición. Analicemos la bitácora del servidor para ver que encontramos:

Si procesamos los caracteres URL con cualquier software, podremos ver la petición un poco más limpia:

Posteriormente, vemos como el software sqlmap ha hecho peticiones GET con la intención de volcar la información de la base de datos. Una de las consultas anteriormente ejecutadas quedó de la siguiente forma:

  • SELECT * FROM search WHERE palabraclave=’facebook’  AND ORD(MID((SELECT IFNULL(CAST(user AS CHAR), 0x20) FROM challenge.users ORDER BY id LIMIT 1,1),5,1)) > 114

Además, sabemos que la palabra clave “Facebook” nos dará una respuesta 200, entonces analicemos la segunda parte. En este caso tenemos un AND. Por lo tanto, como obtuvimos un 200 como respuesta del servidor es claro que esta condición también se cumplió. Al final de la consulta, se valida si el código ASCII del quinto carácter del segundo usuario es mayor a 114.

Con este tipo de consultas se ha conseguido volcar la base de datos. Para demostrarlo, se ha hecho un pequeño programa en la linea de comandos de que permite obtener carácter a carácter la información filtrada:

La linea anterior parece un poco confusa, pero cumple bien con la función de buscar los datos más interesantes del access.log. Una vez que esa información es extraída completamente, se puede analizar:

  • user: root
  • contraseña: 926e27eecdbc7a18858b3798ba99bddd

Al pasar el hash md5 en cualquier bruteforcer, se obtiene la siguiente contraseña:

Ahora el autor del malware cuenta con las credenciales de root para la administración del servidor web. Esto es una gran prueba de la inocencia de Carlitos ante la justicia.

Javier Aguinaga
Malware Analyst

Autor , ESET

  • Nahuel Vara

    Despues de que descubriste que era inyectable la base de datos me perdi, supongo que me falta leer mas sobre el tema. Excelente trabajo, realmente impresionante, saludos!

    • Buenas tardes Nahuel, si te queda alguna duda, lanza tu pregunta en el comentario, y siempre que este dentro de mis posibilidades, la responderé ;)

  • Adrián Martínez

    Que tal Javier, faltó dar crédito a los que lo resolvieron… o no se resolvió?

    • Estimado Adrián, el reto fue resuelto solo por dos personas, a los cuales ya se les ha dado los créditos necesarios en los comentarios del reto en sí.

      Gracias por tu mensaje

Síguenos