RETO HACKER DE VERANO

Transcripción

1 RETO HACKER DE VERANO Blind XPath Reto Hacker de verano

2 Índice 1 Introducción Proceso de trabajo Toma de contacto (fingerprinting) Comienza el ataque Explicacion del ataque y posible mitigación Fuentes Continuara

3 1 Introducción En este caso la introducción será un poco más informal que de costumbre contando que estamos en verano, hace calor Y es que es justo en verano cuando más nos relajamos pero los malos no entienden de descanso así que llega un domingo de verano y después de una tarde de verano recibes un haciendo un llamamiento al equipo ninja. Se trata de conseguir acceso a una intranet averiguando su login y password. Parece sencillo no? Pues nos ponemos manos a la obra a ver qué es lo que conseguimos 2 Proceso de trabajo 2.1 Toma de contacto (fingerprinting) Lo primero por lo que empiezo, a pesar de que lo que se pide es un usuario y password de la web es por tratar de obtener información del entorno a auditar ya que nos puede dar pistas de hacia dónde dirigir nuestros ataques, puertos por defecto que nos indiquen un Sistema gestor de bases de datos, metadatos de ficheros, versiones de sistemas operativos, etc. Comenzamos de la manera más simple y es comprobando si hubiera un fichero robots.txt que pudiera darnos algo de información sobre la estructura de los directorios.. Imagen 1 2

4 Parece que no ha habido suerte y que el administrador del sitio web sabe por dónde se anda, así que vamos a tratar de provocar un error a ver si con eso tenemos más suerte, metemos una URL aleatoria a ver si el error nos muestra algo de información. Imagen 2 No es nuestro día hoy, así que tendremos que llamar a los refuerzos para lo cual lanzo un escaneo mediante NMAP o en este caso su versión para Windows tal y como vemos a continuación. Imagen 3 A parte de otra información sobre el servidor que no está relacionada con nuestra misión, encontramos un puerto que nos llama la atención, el 3306 que es utilizado por el sistema de bases de datos MySQL por lo que podemos tener una pista de por dónde atacar. 3

5 2.2 Comienza el ataque Bueno tenemos información sobre un sistema gestor de bases de datos, y tenemos un formulario por lo que vamos a probar con la llave maestra de las inyecciones SQL: 'or '1'='1 Imagen 4 Y ante nuestra sorpresa HA COLADO! Parece que nuestro administrador de la página web no termino el módulo de seguridad completo }:P. Bueno pues vamos a empezar verdaderamente con la misión, que es obtener un nombre de usuario y un password. Vemos que no se muestra ningún parámetro del formulario o información recogida de la base de datos cuando el login es correcto por lo que no podremos utilizar SQL Injection tal cual sino que necesitaremos hacer un Blind SQL Injection. Esta técnica nos permite saber mediante el comportamiento de la página web si la consulta ha tenido éxito o no, en nuestro caso cada vez que muestre Usuario correcto significará que la consulta es correcta. 4

6 Por lo que vamos a intentar en primer lugar conocer el esquema de la base de datos de manera que sepamos los campos a los que atacar para obtener la información. Para ello comenzamos con una consulta simple para probar que funciona ' or (substring(@@version,1,1)=5) Con esto podremos comprobar si la información de NMAP es correcta y conocemos si la versión de la base de datos es correcta. Pero algo no nos cuadra y es que en un error por mi parte no metí la versión completa de la base de datos como se ve en la consulta anterior por lo que nos debería haber devuelto Usuario incorrecto, en cambio esto es lo que vemos: Imagen 5 Todo nuestro gozo en un pozo, el administrador nos la ha jugado bien, así que comenzamos de nuevo a ver cuál puede ser el problema por el que responde a ciertas consultas y a otras no. Comenzamos multitud de pruebas alrededor del SQL Injection incluso utilizando herramientas como havij o sqlmap pero sin ningún resultado. A la desesperada comencé a eliminar datos de la consulta hasta solo quedarme con la comilla simple y sorprendentemente, accedió al sistema correctamente. En ese momento hice memoria de lo que ponía el correo que habíamos recibido sobre que los malos saben XML y sobre una parte de un manual que 5

7 había leído de OWASP sobre hacking ético en el que hablaban de XPath injection. En ese artículo se hablaba de cómo detectar y explotar esta vulnerabilidad e indicaban que si el formulario responde únicamente a una comilla simple, es probable que sea vulnerable a XPath injection. Por lo que empezamos a probar de la misma manera que antes diferentes consultas siempre de manera ciega con el comportamiento de la página. Con esta primera consulta podremos saber el número de nodos principales que tiene nuestro fichero XML de donde valida el acceso el formulario: ' or count(parent::*)='1 Vemos que al meter el valor del que dispone el documento (Un solo campo padre) el acceso es correcto y si variamos el número a otro no correcto el formulario no accede. Imagen 6 Imagen 7 6

8 Siguiendo este método voy a dejar una serie de consultas realizadas sobre el sistema que pueden ser de utilidad: ' or count(parent::*)='1 Indica el número de nodos padre ' or count(child::*)='8 Indica el número de nodos hijo ' or substring(name(parent::*[position()=1]),1,1)='u Indica las letras del título del nodo padre ' or substring(name(child::*[position()=1]),1,1)='i Indica las letras del módulo hijo. Variaremos en estas el número del campo substring para ir obteniendo cada letra del título, vemos un ejemplo de la secuencia necesaria para saber el nombre del nodo padre: ' or substring(name(parent::*[position()=1]),1,1)='u ' or substring(name(parent::*[position()=1]),2,1)='s ' or substring(name(parent::*[position()=1]),3,1)='e ' or substring(name(parent::*[position()=1]),4,1)='r ' or substring(name(parent::*[position()=1]),5,1)='s Tal y como vemos nuestro primer nodo se llama USERS por lo que nos hace pensar que vamos en el buen camino. Continuamos con diferentes consultas realizadas sobre el sistema y que pueden ser de utilidad una vez obtenidos los nombres de los campos. ' or substring(//id,1,1)='1 Saca el número de campo ID ' or substring(//login,1,1)='a Saca el login ' or substring(//password,1,1)='a Saca el password ' or substring(//user[2]/id,1,1)='2 Saca el id del segundo usuario ' or substring(//user[2]/login,1,1)='s Saca el login del segundo usuario ' or count(//id)='2 --> Numero de nodos ID y con ello el número de usuarios Etc 7

9 Con estas consultas ahora solo queda ir tocando el piano hasta obtener todas las letras del acceso. En este caso he obtenido el del primer usuario cuyos datos serían: Usuario: amadapa Password: amadapa Por lo que podríamos dar por concluido el trabajo encargado, el otro usuario al conocer la mecánica no lo he sacado a mano porque mediante el uso de Curl quería tratar de automatizar el proceso para que no sea tan tedioso. En el caso del segundo usuario la contraseña comienza por Z por lo que es importante el orden con el que probemos. Al ser un sistema de ensayo error para evitar probar todas las combinaciones en el mismo orden aconsejo ir saltando de un extremo a otro de los valores posibles para como en el caso del segundo usuario no tener que probar todo el abecedario hasta llegar a este valor. Ejemplo: Orden normal: a,b,c,d,e,f,g,h. Orden que sigo: a,z,b,y,c,x De esta manera en vez de en el intento 27, la letra sale al segundo intento. 2.3 Explicación del ataque y posible mitigación Este ataque al igual que el SQL Injection están basados en un fallo de programación de manera que nos permite inyectar caracteres especiales que son tomados por una consulta como diferentes valores en una consulta pudiendo así hacer consultas dentro de la consulta programada en el sistema. Además de tener cuidado durante la programación para no dejar posibles comillas que nos jueguen una mala pasada, debemos controlar los caracteres especiales en nuestros formularios pudiendo hacer uso de funciones como htmlspecialchars que nos permiten escapar ciertos caracteres especiales que conforman etiquetas HTML o consultas SQL. 8

10 Por último si solo hacemos consultas a nuestra base de datos, debemos tener cuidado con el usuario que ejecuta las consultas y evitar siempre que sea el usuario root para evitar problemas mayores y ponérselo un poco más difícil a los malos. 3 Fuentes Manual sobre XPath Injection por OWASP 010) Artículo sobre Xpath Injection 4 Continuara. Los siguientes pasos son automatizar el proceso de manera que evitemos hacer tantas consultas de manera manual. Para este proceso estoy haciendo pruebas con CURL de manera que pueda lanzar consultas por post desde una línea de comandos con la siguiente estructura obtenida tras analizar la consulta con Wireshark : login=%27+or+substring%28%2f%2flogin%2c1%2c1%29%3d%27a+&passw ord=%27+or+substring%28%2f%2flogin%2c1%2c1%29%3d%27a+ 9

11 Imagen 8 Una vez conseguido el lanzar la consulta correctamente desde línea de comandos se podrá realizar un script que automatice el proceso. Con esto vemos otra razón más para usar https y evitar en la medida de lo posible estas cosas así como otros muchos problemas como robos de sesión, robo de credenciales 10