Base de datos comprometida (inyección de SQL): ¿cómo manejar la situación, después del hecho?

Question

Base de datos comprometida (inyección de SQL): ¿cómo manejar la situación, después del hecho?

#1 de Snappie (1 votos)
#2 de m1screant (-2 votos)

2

Situación

Descubrimos que una de nuestras bases de datos (MySQL) se ha comprometido a través de la inyección de SQL. El vector de inyección fue una consulta que era vulnerable a la inyección de SQL debido a la concatenación de cadenas en su cláusula WHERE .

El usuario MySQL para la aplicación web en cuestión se ejecutó con privilegios bastante limitados ( SELECT , DELETE , UPDATE , INSERT ) en una sola base de datos junto con la base de datos information_schema . Solo se puede acceder al servidor de la base de datos desde las máquinas incluidas en la lista blanca (sin acceso a internet sin restricciones).

Por lo que podemos ver, el atacante realizó todas las interacciones con nuestra base de datos a través de las solicitudes HTTP GET a la aplicación web vulnerable. Hemos asegurado el acceso al servidor web y los registros de errores que muestran claramente todos los intentos de consulta. Lo lamentable es que el atacante tuvo acceso a nuestra base de datos durante aproximadamente 3 días. Como tal, creo que debemos asumir que toda nuestra base de datos se ha mapeado y la mayoría de los datos de interés han sido descargados por el atacante.

En el momento del descubrimiento, el ataque aún estaba en curso; se ha detenido y la vulnerable cláusula WHERE ha sido reemplazada por un marcador de posición de declaración preparado (como debería haber sido todo el tiempo). Dado que el ataque todavía estaba en curso, creo que puedo asumir que aún no lograron obtener todos datos. Una vez que la vulnerabilidad se solucionó, rotamos las "contraseñas" ¹ para todos los usuarios que tuvieron acceso a este servidor de base de datos.

Los datos

La base de datos en cuestión es el almacén de datos para una tienda web. No hay información de pago en la base de datos (todas las transacciones de pago son manejadas por un proveedor de pago (ThirdPary)) y las contraseñas de los usuarios se han bloqueado con BCrypt con un factor de trabajo bastante decente.
La base de datos contiene pedidos de clientes (junto con información de dirección), productos, stock, etc.

Preguntas

El orificio se ha tapado, ¿qué pasos técnicos ² se deben tomar ahora (aparte de rotar las credenciales de usuario de MySQL, lo que ya hemos hecho)?
Como tenemos los archivos de registro con todos los intentos de consulta, debería ser posible averiguar exactamente qué tablas se han volcado.
¿Qué es una herramienta viable para extraer esta información de 1 GB de acceso a servidores web y archivos de registro de errores?
¿Cuáles son los usos maliciosos comunes de los datos robados como este? ¿Ataques de phishing dirigidos a los clientes de la tienda online?

_{¹: ASCII imprimible de 32 caracteres, cadenas aleatorias.
²: Definitivamente hay una parte judicial, de comunicaciones y relaciones públicas para este problema , pero esta pregunta se centra únicamente en la parte técnica del incidente.}

sql-injection forensics

pregunta Monika 12.09.2017 - 22:08

fuente

2 respuestas

Lea otras preguntas en las etiquetas sql-injection forensics

¿Por qué Spotify está usando mi cámara web (AppleCamera) ¿Por qué usar .ENV? ¿Qué hay de malo en almacenar secretos en un archivo config.php fuera del directorio raíz?

score 1 · Answer 1

1. El agujero se ha tapado, ¿qué pasos técnicos se deben tomar ahora (aparte de rotar las credenciales de usuario de MySQL, que ya hemos hecho)?

Auditar el sitio web. Preferiblemente por alguien fuera de la empresa si tiene el presupuesto. El término de búsqueda que está buscando es "pentest". Además, si su aplicación muestra cualquier dato almacenado en la base de datos directamente en el sitio web, verifique si el atacante colocó oportunamente algunos XSS almacenados allí. (Javascript para robar credenciales de texto claro, por ejemplo)

2. Como tenemos los archivos de registro con todos los intentos de consulta, debería ser posible averiguar exactamente qué tablas se han volcado. ¿Qué es una herramienta viable para extraer esta información de 1 GB de acceso de servidor web y archivos de registro de errores?

No tengo conocimiento de tal herramienta, lo siento. Siempre puedes intentarlo y hacerlo manualmente. Pruebe y use cualquier tipo de lenguaje de scripting (bash y el símbolo del sistema lo harán) para recrear las consultas ejecutadas de los archivos de registro. Desde allí, puede averiguar fácilmente a qué tablas se accedió, aunque sería mucho trabajo obtener más detalles en este asunto.

Si haces esto, busca las declaraciones de inserción y actualización, para ver si él también modificó o agregó datos.

3. ¿Cuáles son los usos maliciosos comunes de los datos robados como este? ¿Ataques de phishing dirigidos a los clientes de la tienda web?

Se puede utilizar para algunas cosas. ¿Supongo que la lista también contiene direcciones de correo electrónico? (las tiendas virtuales a menudo lo hacen)

El atacante podría probar y usar sus datos para comprometer otras cuentas en otros servicios. él podría:

intente descifrar las contraseñas y utilícelas en otros sitios web. ¿Las contraseñas fueron saladas? Si no, puede intentar usar tablas de arco iris.
Use la información de su sitio web para intentar recuperar cuentas en otros sitios web sin descifrar la contraseña. Mediante el uso de preguntas de recuperación.
Use las direcciones de correo electrónico (si las almacenó) para propósitos de spam. También puede vender la lista de correo electrónico.
phishing como usted mismo mencionó

score -2 · Answer 2

Lo único que puedo decir sobre el tema es cómo evitar esto de nuevo. Cambiar la información de usuario de la base de datos SQL sería un pequeño paso, pero solo es esencial escapar de los datos antes de ingresarlos en la base de datos o incluso solo de la consulta. Esto se puede hacer en aproximadamente 5 líneas a través de una función que podría reutilizar para cada entrada.

Por ejemplo, en PHP, se vería así:

$con = In this example, I'm saying this is the connection.

function escape($string) {
  global $con;
  return mysqli_real_escape_string($con, $string);
}

Luego, incluso antes de ingresarlo en la base de datos, por ejemplo, al tomar una variable de una URL a través de un método de obtención, harías algo como esto:

$data = escape($_GET['data']);

Luego, si insertara "$ data" en la base de datos, estaría seguro de que está a salvo de la inyección de SQL con el método de escape.

Entiendo que es posible que no esté utilizando PHP, pero solo quería aclarar lo fácil que es protegerse de las inyecciones en unas pocas líneas.

Es realmente tan simple mantenerse a salvo de las inyecciones de SQL.

Saludos.