Inyección SQL a sitio web de institución educativa en Veracruz.

Hace un par de días jugando con unos Dorks de Google encontré un sitio web de Veracruz perteneciente al sector industrial, luego de haber hecho algunas pruebas a mano con diferentes parámetros  en distintos enlaces dentro de este sitio preferí mejor pasar a revisar todo el sitio con un escáner para hallar vulnerabilidades, este fue Acunetix. De las 2 que hallé  y corroboré con el resultado del escaneo, la de inyección SQL fue la que más perjudicial resultó, ya que la info obtenida, fue bastante.

Parte de este sitio es una supuesta institución educativa, la que resulta tener afiliaciones con otros negocios mediante este sector educativo, lo que la inyección realizada permitió conseguir fue:
Iformación acerca de alumnos (calificaciones, asistencias, cursos, asignaturas), curriculums del personal, teléfonos, matrículas, etc.

Antes de seguir: ¿Qué es una inyección SQL, como se lleva a cabo y que tan perjudiciales pueden resultar? 

Este es un ataque que está dirigido a las bases de datos, en donde se lleva a cabo la inyección de vectores de ataque en un input especificado (parámetro vulnerable), este fallo de seguridad (security flaw) se debe a que la o las entradas de datos (inputs) no autentican de forma correcta el ingreso de datos, aquí es en donde un atacante puede aprovecharse para realizar acciones perjudiciales, como se demostrará a continuación; los parámetros vulnerables y la info obtenida estarán censurados, ya que este artículo está escrito con una finalidad informativa y educativa .

sitio

Cuando terminé de haber hecho la búsqueda con el Dork SQLi de Google, me topé con el sitio anterior, por lo que quise usar un “WAS” (Web Application Scanner) para ver con que me topaba dentro de él, así que recurrí a mi segundo preferido de estos, Acunetix.

A lo largo del proceso en Acunetix me encontré con la vulnerabilidad “SQL Injection”, por lo que revisé los “ítems” u objetos afectados por esta, por lo que me aparecieron los siguientes resultados. En donde aparecen 3 vulnerabilidades críticas, de las cuales trabajé sobre la última, en donde existen 20 ítems afectados por ella:

acuurl

De los ítems perjudicados seleccioné el número 4 perteneciente al parámetro vulnerable para realizarle unas pruebas lo envié al “HTTP editor” en donde se lleva a cabo un simple ataque en el parámetro seleccionado para poder así definir detalles acerca del mismo, como lo es el URIPATH donde se ubica el vector de ataque o input vulnerable, y las peticiones de cabecera (Request Headers). Consulta la imagen:

acuhttpeditor

Algo que no está de más mencionar, es que no porque aquí aparezca esta “vulnerabilidad” o fallo y lo hallamos testeado de esta manera significa que es susceptible a una inyección, ya que puede ser un falso positivo, por lo que esto puede resultar un poco confuso por los resultados obtenidos en un principio, así que lo que hice fue averiguar si esto era posible  si yo mismo hacia pruebas en el parámetro vulnerable mediante el testeo manual de este, y posteriormente hacer el intento de inyección con SQLMAP.

¿Qué es SQLMAP y como intervino aquí?

Estando incluida en diferentes distros para pentesting y siendo una open-source, SQLMAP tiene un uso bastante eficaz para pentesters que automatiza el proceso de búsqueda y explotación de vulnerabilidades tipo SQL Injection con la finalidad de robar datos o capturar un host remoto, y si, también está incluida en Parrot Sec OS. A decir verdad, probé este vector de ataque con una herramienta llamada “Havij” y no me funcionaba como debía (esto no quiere decir que sea mala o no sirva), sin embargo, tuve que recurrir a mi preferida… SQLMAP.

*El uso de ambas herramientas se muestra en el curso de hacking ofensivo COISP Nivel 1.

Como ya es de costumbre, usé mi distro para pentesting preferida: Parrot, con versión 3.3

Sabiendo esto, se hizo una primer prueba:
Dentro de una terminal en Parrot, se ejecutó el siguiente comando:
sqlmap –u “(Aquí va el URL donde se especifica el variante del ataque)” –p “(Aquí va el parámetro vulerable)” –current-user –current-db

Donde:

  • sqlmap –u: Hace uso de la herramienta mediante la opción de URL
  • -p: Aquí es  en donde se indica el parámetro vulnerable
  • –current-user: Si se realiza la inyección exitosamente conseguirá el usuario actual que existe en la DB existente.
  • –current-db: Obtendrá el nombre de la base de datos existente (En donde se realiza la inyección).

Al hacer esto, sqlmap iniciará los “Testing Protocols” antes de intentar/realizar una inyección, como lo es el checking de la existencia de algún WAF, IPS, IDS y comprobar si el enlace es estable. En la imagen podemos notar que en el Log de SQLMAP indica que el parámetro vulnerable de tipo GET puede ser inyectable y su posible SGBD puede ser MySQL, seguido de la misma indicación acerca de un posible XSS e indicando la prueba de inyección el parámetro vulnerable.

También nos indica si para las pruebas o test restantes incluir todos los parámetros de testing para el SGBD de MySQL, le dijimos que sí.

Y, por último, nos da 2 indicaciones, la primera es sobre que el parámetro vulnerable de tipo GET parece ser un booleano de inyección tipo Blind, y la última nos afirma que el parámetro anterior es vulnerable a inyección SQL a base de errores:

map1

Durante el proceso de Testing al SGBD encontrado (MySQL), nos encontraremos con la indicación de que no se puede llevar a cabo la inyección con valores tipo NULL, por lo que tendremos que intentar el testing de forma aleatoria con valores tipo “int”, indicáremos que si con Y. Seguido notaremos que el parámetro vulnerable de tipo GET, puede tener de una a 20 columnas inyectables mediante consulta (Query) tipo UNION:

map2

Terminada esta fase de Testing, (donde se lleva a cabo la inyección), SQLMAP nos indicará que ha identificado los siguientes puntos de inyección gracias al parámetro proporcionado para las pruebas, dando un total de 77 peticiones HTTP. En la siguiente imagen veremos detalles del parámetro vulnerable tipo GET, que fue en donde se inyectaron todos los vectores de Ataque, seguido de la afirmación total del tipo de SGBD hallado, así como detalles de este, como lo son, el tipo de uso, el servidor y versión del gestor.

Al final vemos el usuario actual de esa DB, que es “cmic_cmicvera@localhost”, este se obtuvo gracias al comando especificado “–current-user”, y por último el nombre de la DB que es “cmicvera_cmic”, esta se obtuvo gracias al parámetro de configuración con el comando “–current-db”:

map3

Hasta este punto hemos conseguido la inyección que estábamos buscando, entonces es momento de pasar a trabajar con la información a la que hemos tenido acceso. Para poder visualizar este contenido, en SQLMAP haremos uso de los parámetros de config. “-D” y “–tables”, el primero es para especificar la base de datos objetivo o a usar, y el otro para demostrar las tablas existentes en ella, ya que de eso están conformadas (además de columnas). Por lo que al primer comando ejecutado le haremos unos cambios, quedando de la siguiente forma:

sqlmap –u “(URL con variante del ataque)” –p “(Parámetro vulnerable)” –D cmicvera_cmic  –tables :

map4

Lo que haremos con este comando será hacer un “Fetching” de las Tablas que constituyen a esta base de datos, SQLMAP las enumerará en la terminal de comandos en donde se está ejecutando, como se indicó en el comando anterior, se hará el listado de las tablas con las que cuenta la DB actual, en este caso son 20, indicando su obtención y enumerándolas:

map4.1

Así como también vemos que SQLMAP nos indica que en el directorio colocó un .txt con el contenido mostrado en la terminal, lejos de solo verlo en la terminal, también conservarlo en el equipo virtual, esto es con la finalidad para hacer una revisión posterior de esta información:

map4.2

Ahora que ya tenemos las tablas, y sabemos cuáles son las que constituyen a la base de datos a la que se realizó la inyección, es momento de hacer el “dumping” o “dumpeo” de estas. Un “dump” es hacer un volcado de la información, siendo este una descarga de las tablas o toda la DB completa si así lo queremos, solo basta con especificar a qué le haremos dumping, en SQLMAP este se consigue con el comando “- -dump”. Los siguientes parámetros de configuración fueron colocados en el anterior comando de SQLMAP:

–D cmicvera_cmic  –tables

Donde:

  • -D cmicvera_cmic: Se indica la DB sobre la que se va trabajar.
  • -T cmic_alumnos: Es la tabla que se va a usar.
  • –dump: Indica la acción de descarga.

map5

Al momento de la ejecución de este comando, vemos que SQLMAP retomará el último punto de inyección que se llevó a cabo, así no tendremos que esperar a que todo el proceso anterior se complete de nuevo. Una vez ejecutado comenzará el proceso de “Retriving info” donde se mostrará lo que se está obteniendo por parte deldump”, al finalizar se mostrará la tabla en la terminal actual y se guardará en un directorio para su posterior revisión.

Algo podemos notar en el proceso del “retriving” que se hizo un Query que arrojó 7 entradas, siendo estas las columnas que constituyen a la tabla (alumnos), las cuales son: “id”, “matrícula”, “pass”, “nombre”, “curp”, “status”, y “correo”. Y durante el proceso se enlista la info obtenida de estas columnas, así como también se muestra el directorio en donde reside la info descargada en un file tipo CSV:

NOTA: TODA LA INFORMACIÓN OBTENIDA NO SE MOSTRARÁ A DETALLE Y ESTARÁ CENSURADA.

map6map7

Hemos terminado, con esta primera tabla, ahora haremos lo mismo para poder resguardar la info en nuestro equipo, ejecutando el comando anterior con los mismos parámetros de configuración, con la diferencia de que ahora seleccionaremos la tabla “cmic_alumnos_calificaciones”, en donde se retomará el punto de inyección y se harán los procesos de “retriving y dumping”, en donde se muestra que se obtuvieron 602 entradas en esta tabla y 8 columnas, siendo estas “id”, “alumno”, “carrera”, “grupo”, “periodo”, “materia”, “calificación” y “faltas”:

map8

Ya mostrándose en la terminal la tabla “dumpeada”, podemos ver el contenido de esta misma por columnas, también podemos ver un aviso de que, debido al largo tamaño de esta tabla, solo se están mostrando los últimos 256 renglones que la constituyen:

map9

Repetiremos los mismos pasos ahora con la tabla “cmic_curriculums” y esperaremos a que termine el “fetching, retriving y dumping” de la información que contiene esta tabla, está constituyéndose por las columnas “id”, “nombre”, “área”, “apellidos”, “fecha_nac”, “correo”, “teléfono”, “país”, “estado”, “sexo”, “curriculum”:

map10

Debido a que esta tabla es bastante extensa se mostrarán únicamente los últimos 256 renglones, además tuve que usar un tamaño de fuente muy pequeño para las columnas y renglones se pudiesen acoplar y leerse mejor, por ello aquí les dejo una imagen de resolución mayor, obviamente me vi obligado censurar la información sensible de la gente que se halló en esta tabla:

cambio1

Lo mismo sucedió con la tabla “cmic_socios”, por lo que tuve que usar una fuente del mismo tamaño para que se acoplará mejor. En esta tabla me topé con 5 columnas: “id”, “nip” “socio” “correo(s)” y “nombre”, este último es el nombre de la empresa que tuvo o con la tiene una asociación alguna en este sector:

map12

Los pasos anteriores se repitieron para una tabla que contenía información acerca de un comité, por lo que se también hice que se pudiese visualizar esa info en la terminal de comandos, mostrando las columnas “id”, “nombre” y “teléfono”:

cambio2

Hasta ahora hemos visto cómo conseguir visualizar la información almacenada en las tablas que constituyen a la base de datos comprometida. Si simplemente no se busca entrar en detalles solo basta con hacer el “dump” de la base seleccionada y listo:

map14

A lo largo de este artículo se demostró el potencial que tienen las herramientas que permitan llevar a cabo la explotación de una vulnerabilidad de inyección por SQL (SQLMAP) en este caso, mostrando, así como un error de este tipo en donde un input o entrada de datos no está verificando el ingreso de información o caracteres de forma adecuada, llevando eso a un resultado como este.

Con esto se ejemplificaron los claros resultados y consecuencias de la no corrección de estos fallos de seguridad que son comunes en mundo de las aplicaciones web, este post fue hecho con fines informativos y preventivos.

Toda la información sensible fue censurada a lo largo de esta demostración, y por otro lado también me he deshecho de ella, ya que este artículo fue escrito con las intenciones antes mencionadas

Todo el contenido de este escrito fue hecho con fines informativos y educativos.

-Mike Nav.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *