PANGOLIN: Automatización de inyección SQL
Pangolin es una herramienta gráfica para plataformas win32 programada en C++ destinada a explotar vulnerabilidades del tipo inyección SQL e inyección SQL ciega (Blind SQL) muy fácil de usar y muy rápida.
La herramienta ha sido desarrollada por zwell del grupo nosec, cuyos proyectos pueden encontrarse en http://www.nosec.org/web/index.php?q=pangolin suponiendo que se domine el idioma chino aunque siempre se puede tirar de un buen traductor o del mismo google translator.
Entre las características de la última versión (1.3.650) destaca el soporte para distintos motores de bases de datos: MSSQL, MYSQL, ORACLE, PGSQL, DB2, INFORMIX, SQLITE, ACCESS.
En aquellos motores donde la vulnerabilidad lo permita, la herramienta implementa explotación para conseguir información y datos del servidor, ejecución de shell, acceso al registro, escritura o descarga de ficheros del servidor, navegador de archivos, etc. Las consultas y peticiones a la base de datos pueden efectuarse via Proxy y utilizar métodos de evasión contra firewalls e IDSs explicados más adelante.
A continuación se exponen todas las funcionalidades del programa, analizando un ejemplo práctico (habilitado a tal efecto) de explotación de una aplicación vulnerable cuyo motor de bases de datos en este caso es MySQL. En artículos futuros se mostrarán ejemplos con el resto de motores de base de datos que soporta Pangolin, Oracle, MSSQL, etc.
0x02 UTILIZACIÓN
En la primera ejecución del programa se muestra la pantalla principal desde donde se llevará a cabo el análisis de la aplicación vulnerable. En el recuadro inferior aparecerán los registros de las operaciones que se van llevando a cabo:
Fig 1 – Pantalla principal del programa
Los diferentes campos a rellenar para revisar la aplicación y que se completan en la pantalla inicial del programa son:
Campo URL
Es donde se indica la dirección o URL objeto del análisis (http://www.ejemplo.com/vulnerable.php?user=1). Cabe destacar que Pangolin no actúa como un scanner de vulnerabilidades, es decir, no servirá de nada poner como URL destino la raíz del servidor web (http://www.ejemplo.com) y esperar que el programa encuentre aquellas variables que sean vulnerables a inyección SQL ya que no hace funciones de crawler ni de spyder, ni intentará buscar todos los objetos accesibles.
Se debe introducir la URL completa, incluyendo el fichero en el que se desea realizar la inyección y los parámetros asociados a la petición. En este caso, la dirección será:
http://www.vulnerable.com/vulnerable.php?user=1
En el caso que la dirección indicada no satisfaga los requisitos y que la aplicación no detecte ningún parámetro donde intentar la inyección de código SQL, se mostrará el siguiente mensaje:
Fig 2 – Mensaje de error generado cuando la URL no es válida
También es posible insertar una dirección con el parámetro a inyectar vacío y entonces no se generará ningún mensaje de error. De todas formas, esto no es recomendable, ya que Pangolin realiza en primera instancia distintos intentos de inyección para determinar qué resultados son ciertos y cuáles falsos (peticiones similares a ...vulnerable.php?user=%20and%201=1), mostrando cada vez el mismo resultado sea TRUE o FALSE la petición que se realice y el programa no será capaz de distinguir si realmente la aplicación es vulnerable o no.
Campos GET/POST
En el desplegable se selecciona el método para realizar las peticiones, ya sea mediante el uso de GETs o POSTs. Normalmente, se utilizará el método GET, aunque en el escenario donde existe un formulario en el que insertar datos, se deberá indicar el uso del método POST y concatenar los parámetros y valores que pasa el formulario en el campo URL comentado anteriormente. Un ejemplo práctico de este caso sería un formulario donde se pasan los parámetros id y pass mediante el fichero form.php, en este caso se utilizaría el método POST y se agregaría la URL de la forma siguiente:
http://www.vulnerable.com/form.php?id=XXpass=sss
Campos Check/Pause/Stop
Se trata de los botones de control para iniciar y/o pausar una determinada tarea y retormarla posteriormente. Pangolin mantiene un listado con las URLs escaneadas en un fichero en formato sqlite (archivo data.s3db) que es accesible desde cualquier gestor de sqlite:
Fig3 – SQLite Manager
Campos Type y DB
Si no se dispone de ninguna información acerca de la explotación que se va a intentar, tales como el tipo de datos de la variable vulnerable o el motor de la base de datos (MSSQL, MySQL, Oracle, etc.), Pangolin realizará una exploración de la dirección proporcionada para determinar el motor de base de datos y el tipo de datos a inyectar (integer, string, etc.). Si se conocen dichos datos se puede prescindir de esta fase de exploración seleccionando el tipo de datos y de base de datos de forma directa mediante los menús desplegables de la pantalla inicial (Type / DB). Alguna de las queries o peticiones efectuadas para determinar el tipo de base de datos utilizado son:
...
http://www.vulnerable.com/vulnerable...E0%20and%201=1
http://www.vulnerable.com/vulnerable.php?user=1%20and%201=1/*%20and%201=1 HTTP/1.1
http://www.vulnerable.com/vulnerable.php?user=1%20/*!39999%20and%201=2*/--%20and%201=1
http://www.vulnerable.com/vulnerable.php?user=1%20union%20select%200/*%20and%201=1
http://www.vulnerable.com/vulnerable.php?user=1%20union%20select%200,0/*%20and%201=1
http://www.vulnerable.com/vulnerable.php?user=1%20union%20select%200,0,0/*%20and%201=1
http://www.vulnerable.com/vulnerable...97,97,97,97,97,
...
Peticiones para comprobar el tipo de datos inyectado:
http://www.vulnerable.com/vulnerable.php?user=1%20and%20user=0--
http://www.vulnerable.com/vulnerable.php?user=1%20and%20user=0--
http://www.vulnerable.com/vulnerable.php?user=1'%20and%20user=0--
http://www.vulnerable.com/vulnerable.php?user=1'%20and%20user=0--
Campo Keyword
En el caso de que, tras la exploración inicial, Pangolin no encuentre la manera de gestionar el error devuelto por la aplicación web, se puede explorar manualmente dicha página Web y encontrar algún string con el que identificar la página de error.
En cambio, al añadir una URL completa, incluyendo el valor del parámetro cuya consulta devuelva TRUE, Pangolin ya es capaz de distinguir entre los resultados.
También es importante a la hora de preparar el análisis de una aplicación utilizar la característica de Pangolin que permite hacer una serie de consultas para determinar qué tipo de motor de bases de datos usa la aplicación que se está revisando.
Options
En el botón Options se encuentran las diferentes opciones de configuración de Pangolin.
Options: Pestaña HTTP
En esta sección se permite escoger el User Agent deseado entre los predefinidos pudiendo incluso crear alguno nuevo. También se puede utilizar la característica Read Cookie que inicia un navegador Web:
Fig4 – Opciones de configuración de la pestaña HTTP
Options: Pestaña Proxy
Con esta opción se permite configurar un Proxy (tipo HTTP o socks v4 o v5):
Fig5 – Opciones de configuración para conectar a través de un proxy
Options: Pestaña Scan
En esta sección se pueden configurar distintas opciones de Pangolin para explorar la aplicación vulnerable según la URL que se le ha indicado anteriormente:
Fig6 – Opciones de configuración de la pestaña SCAN
• SCAN WITH SEARCH-TYPE Al seleccionar está opción inicialmente se ejecutan una serie de peticiones automáticas para determinar qué tipo de base de datos se va a analizar.
• SCAN SQLSERVER FIRST Esta opción comprobará MS SQL antes que el resto de motores que soporta la aplicación. En la práctica se marquen o no las opciones comentadas, el comportamiento es el mismo y lanza las mismas requests para determinar siempre cuál es el motor de bases de datos utilizado por la aplicación web que se está revisando
En las opciones restantes, se ofrece la posibilidad de cambiar el método de recuento de comprobación de la vulnerabilidad usando clausulas ORDER BY o UNION SELECT, cabe destacar que el hecho de utilizar ORDER BY para extraer los datos funciona más rápidamente.
En el campo CHECK VALID PAGE METHOD se puede determinar cuándo una respuesta del servidor analizado se considerará válida como, por ejemplo, mediante el uso del código estándar HTTP 200.
Primera Request :
http://www.vulnerable.com/vulnerable.php?user=1
Request para determinar si hay vulnerabilidad :
http://www.vulnerable.com/vulnerable.php?user=1%20and%201=1
http://www.vulnerable.com/vulnerable.php?user=1%20and%201=2
Request para determinar distintos tios de motor de Base de datos:
http://www.vulnerable.com/vulnerable...E0%20and%201=1
http://www.vulnerable.com/vulnerable...E0%20and%201=1
http://www.vulnerable.com/vulnerable.php?user=1%20and%201=1/*%20and%201=1 HTTP/1.1
http://www.vulnerable.com/vulnerable.php?user=1%20/*!39999%20and%201=2*/--%20and%201=1
http://www.vulnerable.com/vulnerable.php?user=1%20union%20select%200/*%20and%201=1
http://www.vulnerable.com/vulnerable.php?user=1%20union%20select%200,0/*%20and%201=1
http://www.vulnerable.com/vulnerable.php?user=1%20union%20select%200,0,0/*%20and%201=1
http://www.vulnerable.com/vulnerable...97,97,97,97,97,...
Detección de Mysql :
http://www.vulnerable.com/vulnerable.php?user=1%20/*!49999%20and%201=2*/--%20and%201=1
Extracción del nombre de la base de datos del motor Mysql :
http://www.vulnerable.com/vulnerable.../*%20and%201=1
Options: Pestaña Advantage
En esta sección se pueden utilizar diversas técnicas de evasión:
Fig7 – Opciones de configuración de la pestaña ADVANTAGE
• REPLACE SPACE AS: Uso de técnicas de evasión reemplazando los espacios en blanco por otros equivalentes (por defecto se incluyen: /**/ + %09 [TAB]) con el fin de saltarse posibles filtros. También se pueden insertar nuevos patrones de reemplazo.
Petición sin reemplazo de espacios en blanco:
http://www.vulnerable.com/vulnerable.php?user=1%20/*!39999%20and%201=2*/--%20and%201=1
Petición con reemplazo de espacios en blanco por /**/:
http://www.vulnerable.com/vulnerable.php?user=1/**//*!39999%20and%201=2*/--/**/and/**/1=1
• BYPASS FIREWALL FILTER WHEN SELECT IS NOT ALLOW: En el caso que las sentencias SELECT estén filtradas por algún tipo de firewall de aplicación o similar, se intentará utilizar esta técnica que codifica la sentencia SELECT de manera que no pueda ser reconocida por los dispositivos de filtrado.
Petición sin opción seleccionada:
http://www.vulnerable.com/vulnerable.php?user=1%20union%20select%200/*%20and%201=1
Petición con opción seleccionada:
http://www.vulnerable.com/vulnerable.php?user=1%20union%20se%25l%25e%25c%25t%200/*%...
• URI ENCODE MODE: Codifica las peticiones que se realizan al servidor, concretamente el parámetro a utilizar ya que, igualmente, por defecto sin utilizar esta opción los espacios en blanco ya se codifican con %20. Utilizando la codificación URL en el siguiente ejemplo, se muestra que la petición sustituye 1 por %31, a parte de los espacios en blanco por %20.
Petición sin url encode activado:
http://www.vulnerable.com/vulnerable.php?user=1%20union%20select%200/*%20and%201=1
Petición con url encode activado:
http://www.vulnerable.com/vulnerable.php?user=1%20union%20select%200/*%20and%201=%31
El resto de opciones presentes en esta pestaña son Language que sirve para cambiar el idioma de la interfaz. Actualmente, sólo está disponible en inglés y chino pero hacktimes.com está colaborando para traducir la herramienta al idioma español. Otra opción es Charset que se refiere el juego de caracteres a utilizar (Unicode, utf, etc.).
Options: Data Manual
Por último, el botón Data Manual permite acceder al historial de direcciones analizadas:
Fig8 – Listado de las URLs analizadas por Pangolin
0x03 CASO PRÁCTICO DE UTILIZACIÓN
Para facilitar el análisis, es recomendable que, previamente, se intente descubrir el motor de base de datos utilizado por la aplicación y distinguir el tipo de datos, de esta manera, aunque Pangolin pueda intentar descubrirlo y dispone como hemos visto de opciones para ello, se ahorran algunas peticiones extra y se va de forma más directa a revisar la aplicación.
Para comprobar qué tipo de datos se va a inyectar se pueden hacer varias comprobaciones manuales. Para saber si es del tipo integer se realiza la siguiente comprobación:
http://www.vulnerable.com/index.asp?id=12 AND 1=1
lo que devuelve una página sin errores que significa que se trata de un entero.
Para saber si es del tipo string se realiza la siguiente comprobación:
http://www.vulnerable.com/index.asp?id=12' AND 'a'='a
si devuelve una página sin errores significa que se trata de un parámetro tipo cadena o string, en este ejemplo, se trata de tipo integer porque con esta petición se obtienen varios errores.
En el caso de este ejemplo práctico, se puede intuir que si el lenguaje de la aplicación es PHP, es probable que el motor de base de datos sea MySQL. Con esta información se rellenan los datos referidos a Integer en la opción Type y Mysql en la opción DB:
Fig9 – Introducción de la dirección vulnerable y los datos del motor de base de datos (MySQL)
Al definir ya las 2 opciones para detectar el motor de la base de datos (Options ? Scan) simplemente se realizaran pruebas que puedan afectar al motor MySQL.
Una vez comprobada la posibilidad de explotación de la vulnerabilidad de inyección SQL en la variable y en la URL proporcionadas, automáticamente se muestra el nombre de la base de datos. Al mismo tiempo, aparecen nuevas opciones (marcadas en rojo en la figura 11): Informations, Datas, FileReader y MysqlFileWritter que permiten profundizar más en la exploración:
Fig10 – Nuevas opciones disponibles para una dirección vulnerable
Informations
Una vez conseguido el nombre de la base de datos, la aplicación irá directamente a esta pestaña que es donde se gestiona toda aquella información que puede extraerse a partir de la inyección. Se han de seleccionar los campos que se desean obtener (usuarios, version, etc.) y pulsando Go, la aplicación empezará a extraer la información solicitada. En este ejemplo, se han marcado todos los campos disponibles:
Fig11 – Campos a extraer de la aplicación vulnerable analizada
Como puede observarse en la anterior captura, se ha obtenido diversa información sobre la aplicación que aloja la base de datos, incluyendo tipo de sistema operativo, rutas de acceso y de instalación, versión del MySQL utilizada, cuentas de usuarios y otras bases de datos existentes en el sistema.
Datas
Con toda la información anterior aunque no es indispensable, se puede pasar a la opción Datas para realizar un volcado de la base de datos en uso, en este caso, vuln-db.
Fig12 – Campos a extraer de la aplicación vulnerable analizada
Si se deseara volcar otra base de datos existente en el servidor analizado se indicaría su nombre con la opción “Use this database”.
Siguiendo con el ejemplo, con el botón Tables se obtienen las tablas de la base de datos. A partir de este punto, se pueden seleccionar los campos a volcar ejecutando como se ha visto anteriormente, el botón Datas del recuadro derecho para volcar la información de las diferentes tablas.
Una vez conseguida toda la información de la base de datos, Pangolin permite realizar un report en formato HTML apretando el botón Save del recuadro derecho:
Fig13 – Ejemplo de informe de la aplicación vulnerable analizada
FileReader
Llevando un poco más allá la exploración del sistema, se accede a la siguiente pestaña que permite leer archivos del sistema donde se aloja la base de datos, en el caso de este ejemplo, se realiza la lectura y volcado del fichero /etc/passwd con los usuarios y las contraseñas en modo hash del servidor donde se aloja la base de datos analizada.
Fig14 – Volcado del fichero de contraseñas del servidor
La petición que se efectúa al servidor para volcar ficheros es mediante la sentencia load_file:
http://www.vulnerable.com/vulnerable.../*%20and%201=1
MysqlFileWritter
En este apartado la herramienta permite subir archivos al servidor siempre y cuando el motor de PHP del sitio vulnerable tenga la directiva magic_quotes_gpc deshabilitada (color off). A pesar de que en la pestaña principal (Informations) se indica si esta directiva está o no habilitada, la información NO es demasiado fiable:
Fig15 – Opción de subir ficheros al servidor vulnerable
La mejor forma de comprobar realmente si el servidor tiene deshabilitada dicha directiva, es porque al intentar subir algún archivo se obtiene el siguiente mensaje de error si no está deshabilitada:
0x04 COMENTARIOS
La herramienta en sí es muy potente como se ha podido comprobar y permite un montón de posibilidades para poder analizar sites vulnerables a inyección SQL así que desde Hacktimes.com nos hemos propuesto ir publicando de forma periódica un caso práctico sobre el uso de Pangolin con los diferentes motores de bases de datos que soporta, de momento ya tenemos aqui el de MySQL.
Autor: Daniel
Co Autores: Fco. Javier Puerta Rubio y VaxMAN
Fuente:
http://www.hacktimes.com/?q=node/57
