¿Puertas traseras después de la inyección de SQL?

6

Acabo de encontrar una vulnerabilidad de inyección en un sitio en vivo de un cliente. Se parece a esto:

$sql = "SELECT * FROM users_dl WHERE Username = '" . $Uname . "' AND Password = '" .     $Pword . "'";

Lo "piraté" con éxito usando ejemplos de wikipedia, por lo que debería ser una vulnerabilidad bastante mala.

El sitio ha sido así durante muchos años.

Sé cómo solucionarlo, pero como no sé mucho sql, estoy preocupado por las puertas traseras.

¿Todavía estaría expuesto después de arreglar esto? ¿Qué puertas traseras se podrían dejar?

Por ejemplo, ¿un atacante podría haber obtenido acceso total, como mysql user y pass, y ni siquiera necesitar inyecciones en el futuro? ¿Necesito cambiar de usuario y pasar? ¿Qué más?

La base de datos se usa en varios sitios, por lo que estoy bastante seguro de que su dominio cruzado está habilitado.

    
pregunta user1721135 17.06.2013 - 01:00
fuente

2 respuestas

3

Como dice @Adnan, lo peor es "Compromiso total y la existencia de una puerta trasera". ¿Por qué? Si bien jugar con SQL, Alon no puede llevar a ningún compromiso del sistema en sí (simplemente vuelva a cargar la base de datos desde una copia de seguridad y debería configurarlo), los programas que usan SQL e interactúan con el sistema tienen capacidades mucho mayores.

Por ejemplo, existe la posibilidad de que tenga una tabla que contenga fragmentos de plantilla de PHP. Un atacante puede editar eso y agregar código malicioso. Si se está ejecutando algo de las tablas SQL (o incluso volcado a un archivo, si el archivo se puede volcar en la carpeta web, entonces un atacante podría usarlo para inyectar y ejecutar su propio PHP), entonces es posible que tenga un problema. .

Averigüe dónde se utilizan todos los datos de las tablas. Si, en algún punto, se está guardando o ejecutando, vea si esto es explotable (en el caso del primero, depende si el atacante puede poner texto arbitrario en la carpeta web que lo usa. En el caso de este último, es casi siempre un problema). Si es así, existe la posibilidad de que el sistema se haya visto comprometido y es posible que desee realizar una instalación limpia.

Si no es así, busque los problemas en las tablas y corríjalos si están presentes. Asegúrate de cambiar tu nombre de usuario / contraseña (y buscar cuentas falsas)

Una cosa interesante a tener en cuenta es que en SQLite, el comando ATTACH DATABASE se puede usar para introducir vulnerabilidades directamente / a>.

De forma similar, el comando SPOOL en SQL * Plus puede ser Se utiliza si la inyección permite ejecutar varios comandos.

Si está usando cualquiera de los dos anteriores, una instalación limpia sería buena independientemente de cómo se usen los datos.

    
respondido por el Manishearth 17.06.2013 - 07:08
fuente
1

Una sola inyección de SQL puede llevar a un compromiso total del sistema. Hay muchas formas, desde las bases de datos, para acceder al sistema de archivos local a través de las operaciones de lectura y escritura. Consideremos que la base de datos se está ejecutando como 'raíz', entonces sería trivial leer el archivo / etc / shadow. Además, supongamos que puede leer la tabla de usuarios locales de la base de datos (seleccionar usuario, pasar de mysql.users por ejemplo) y, después de descifrar hashes triviales, puede poder SSH en el host usando el mismas credenciales (abuso de reutilización de contraseña). Además, y probablemente más comúnmente, puede ejecutar comandos del sistema operativo desde la propia base de datos. Xp_cmdshell se puede usar en SQL Server, las funciones definidas por el usuario se pueden crear en MySQL y hay muchas formas de hacerlo en Oracle. ¡Crear funciones Java es solo una!

Si su base de datos se ha visto comprometida y no ha seguido ningún paso para bloquearla o endurecerla, puede suponer que lo peor es que el atacante haya aumentado el privilegio al propio sistema operativo.

    
respondido por el fixulate 17.06.2013 - 10:55
fuente

Lea otras preguntas en las etiquetas