¿La Inyección SQL actúa sólo a nivel de la base de datos o el riesgo es aún mayor?

Pregunta:


Existe una pregunta relacionada:
¿Qué es la inyección SQL y cómo puedo evitarla? la cual cuenta con
excelentes respuestas sobre el tema de la Inyección SQL.

Creo que muchos de nosotros, cuando vemos consultas de este tipo:

"SELECT * FROM tabla WHERE id=$valor";

O bien:

"INSERT INTO tabla (columna) VALUES ($valor)";

O bien:

"UPDATE tabla SET columna=$valor";

u otra parecida, pegamos el grito al cielo (y con toda razón), advirtiendo al OP de que su código es vulnerable.

En efecto, comprendemos que la variable $valor es suministrada por el usuario, a través de un formulario, de una URL o de cualquier otra fuente externa.

Si dicha variable depende del usuario y el programador crea código para que la consulta se ejecute sin ningún tipo de prevención, cualquier usuario mal intencionado puede escribir código dañino donde se recogen los datos externos y dicho código se ejecutará.


La pregunta

En muchos casos, cuando se advierte del código vulnerable algunos argumentan que son datos de prueba y que es una base de datos de prueba. O sea, poco importa que se borren tablas o que se tome el control de la base de datos, después de todo son datos de prueba.

Pero… ¿y si nuestro sistema propiamente está en riesgo?

Mi pregunta es si la Inyección SQL tiene impacto sólo a nivel de la base de datos o si cualquier usuario mal intencionado puede acceder también a nuestro sistema (no solamente a la base de datos) y ejecutar comandos dentro de él.

O planteado de otro modo: ¿la Inyección SQL podría ir más lejos de SQL?.

PREGUNTA DEL AUTOR: A. Cedano

La respuesta Muriano:

La respuesta corta es sí.

¿Hasta dónde? Dependiendo del tipo de ataque, podría ir desde “tumbar” el servidor hasta hacerse con el control de un usuario de sistema. Entre otros efectos:

  • File system read access Acceso de lectura a ficheros de sistema. En el caso de MySQL, haciendo uso por ejemplo de funciones como LOAD_FILE()
  • File system write access Acceso de escritura a ficheros de sistema. En el caso de MySQL, haciendo uso por ejemplo de sentencias como SELECT … INTO DUMPFILE
  • Operating system access Acceso al sistema operativo. Es un tema más complejo, para que busques información al respecto, podría mencionarte la Inyección UDF
  • Out-of-band connection Conexiones fuera de banda. Al contrario que las conexiones en banda (http) usan otros canales para enviar la información. Decir que, en este punto, el atacante podría obtener acceso directo a nuestros servidores vía consola de comandos o interfaz gráfica vnc.
  • Privilege escalation Escalado de privilegios. Suelen darse cuando la aplicación utiliza tokens para identificar a los usuarios. El atacante podría hacerse con el listado de estos y usar uno para suplantar una identidad con privilegios mayores.

¿Cómo? Existen varias prácticas, en las que no voy a profundizar para no dar idea a gente que lo pueda usar para hacer daño. Resumiendo:

Las técnicas pueden ser consideradas en 3 grandes categorías:

  • Boolean based blind
  • UNION query
  • Batched queries Que son a las que tú haces referencia en tu pregunta 1; DELETE FROM tabla; DELETE FROM otra-tabla; DELETE FROM todas-las-que-quiera;

Todo depende de lo que te permita hacer la base de datos en sí, pero se me ocurre el siguiente escenario:

  • La base de datos está en un sistema windows, donde los archivos son ejecutables sólo dependiendo de su extensión.
  • La base de datos tiene comandos que permiten hacer una query y guardar los resultados en un fichero.

Esto permitiría hacer algo como (en pseudo-código):

1; COPY (select 'del c:\Users /R' from DUMMY) to "c:Users<nombreUsuario>Startejecutar.bat"

He puesto el comando del, pero podría ser cualquier otra cosa, como hacer un Invoke-WebRequest, que es el equivalente al comando Linux “wget”, y descargarse y ejecutar un troyano.

Add a Comment

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