¿Cómo explotar la vulnerabilidad "PHP_MAGIC_QUOTES ON" para causar un daño máximo?

22

He encontrado una gran cantidad de exploits de inyección SQL en algunos sistemas que mantengo. Sé cómo prevenir la inyección, pero me gustaría demostrarle a mi CEO y CTO lo peligroso que es si no nos concentramos lo suficiente en mantener nuestras aplicaciones seguras.

Muchas veces tenemos que reaccionar en lugar de proactuar cuando se trata de seguridad, principalmente porque cuando se encuentra una vulnerabilidad, no se prioriza la reparación porque es poco probable que se explote.

La siguiente consulta es uno de estos ejemplos. El servidor se está ejecutando con PHP_MAGIC_QUOTES ENCENDIDO (sí, sé que eso es realmente malo) y, por lo tanto, evita las explotaciones en varios lugares porque los programadores han agregado explícitamente "todo el valor de entrada usado en las consultas (por lo que no puede salir de él). Sin embargo, la consulta que he encontrado vulnerable ahora se trata como un número entero en lugar de una cadena, y no contiene "alrededor".

Aquí está el ejemplo:

$sql = "select * from vulnerable_table where id = " . $_GET['id'] . " limit 1"; 
$result= mysql_query($sql); 

¿Cómo harías el daño máximo al sistema considerando que controlas la variable id.

Algunos ejemplos que he encontrado por mi cuenta:

id = 1;drop table mysql.user 
Only if semi colon is accepted

id = 1;SELECT '<?php exec($_get['cmd'])?>' INTO OUT_FILE('/var/www/backdoor.php')
Only if I could bypass the magic_quotes somehow
    
pregunta Chris Dale 21.12.2010 - 14:10
fuente

7 respuestas

19

En PHP no puedes apilar consultas con un punto y coma. Sin embargo, puede anidar una consulta en otra con paréntesis (comúnmente llamadas subconsultas), por ejemplo:

SELECT * FROM vulnerable_table WHERE id = (SELECT number from other_table)

Usando esta técnica (sin importar si publicas el resultado de SQL o no) un intruso puede extraer todos los datos de tu base de datos.

Ejemplo (con salida en la página web)

SELECT * FROM vulnerable_table WHERE id = (SELECT group_concat(table_name) from information_schema.tables WHERE version = 10)

Esta consulta dará como resultado una lista (como una cadena) de todas las tablas definidas por el usuario en su base de datos. Otras consultas revelarán las columnas y le permitirán al adversario obtener un conocimiento completo de la estructura de su tabla (por ejemplo: "tbl_accounts, tbl_passwords, tbl_guestbook").

Si no da ningún resultado en su página web, un atacante podría inyectar una declaración condicional (piense: caso-cuándo) con su subconsulta de SQL, lo que resultará en un error de SQL en un caso y no en el error. otro caso Derivado de "sin salida" y de su página web normal, puede recopilar 1 bit de información y realizar una búsqueda binaria a través de su base de datos.

La generación de cadenas en una consulta SQL como la que sugirió cargar un PHP-Backdoor (dependiendo de si el usuario de MySQL actual tiene el privilegio de ARCHIVO, que no debería;)) tampoco es tan difícil de conseguir: usar el Con las funciones ascii () y ord (), puede crear sus cadenas con entradas enteras. También un valor como 0x414141 se convertirá automáticamente a 'AAA' en MySQL.

Con respecto a las técnicas muy avanzadas de ataque y evasión de filtros, también le recomiendo leer el blog de Reiners sobre seguridad SQL: enlace

En aras de la integridad: para corregir esta vulnerabilidad, solo puede realizar un encasillado y transformar $ _GET ['id'] en un entero.

    
respondido por el freddyb 22.12.2010 - 12:11
fuente
11

Si su empresa forma parte de las regulaciones que requieren seguridad (como SOX o HIPPA en los EE. UU.) o estándares comerciales (como PCI o varias normas ISO), todo lo que tiene que hacer es decirles que:

  • ha encontrado agujeros que podrían permitir que cualquiera descargue toda la base de datos y la red (extienda un poco la verdad si tiene que venderla, y recuérdeles la pérdida de ACS: Law).
  • bríndeles información acerca de cuánto tiempo y dinero le costó a otras compañías que perdieron datos o fueron pirateadas.
  • que si alguna vez se audita, la empresa puede ser multada o eliminada por no cumplir con los estándares.
  • que si alguna vez lo demandan o lo procesan, y existe alguna evidencia de que ignoró un problema potencial mayor o conocido, los daños punitivos podrían ser suficientes para llevar a la empresa a la bancarrota. (Vea la demanda de Ford Pinto).

Esto funcionará mejor si puede convencer al abogado de la compañía para que le transmita las malas noticias. Si eso no funciona, no hay nada que pueda salvar a su empresa.

Hagas lo que hagas, olvídate de explotar a ti mismo la vulnerabilidad. Usted se abre a los juicios y al tiempo en la cárcel si lo hace sin un permiso por escrito, aunque podría funcionar una pequeña evidencia que demuestre que funciona en una cuenta de prueba que configuró específicamente para el propósito.

    
respondido por el SilverbackNet 22.12.2010 - 02:55
fuente
4

Aquí es posible la extracción de información (como la lectura de archivos o la extracción de información de usuarios de la base de datos) y el consumo de recursos del servidor. Primero se puede lograr usando la instrucción UNION en la consulta. Segundo se realiza mediante el uso de la función BENCHMARK (). La extracción de datos también es posible mediante el uso de la función mencionada.

No quiero mostrar ejemplos aquí, están en Internet. Y supongo que, como mantenedor del sistema, puedes reproducir casos. Si realmente los necesitas, comenta.

Por cierto, no necesitas el punto y coma para poder escribir en archivos (aunque se necesita acceso para escribir en un archivo).

    
respondido por el anonymous 21.12.2010 - 15:02
fuente
3

Creo que esta caricatura lo dice todo. Little Bobby Tables

    
respondido por el Dave 21.12.2010 - 18:38
fuente
2

id =

0 OR id <> 0

omitiría completamente el uso de ID, y el pirata informático podría volcar toda la tabla.

    
respondido por el Matthew Read 21.12.2010 - 20:15
fuente
2

El daño máximo es relativo. Insertar discretamente datos pequeños y difíciles de detectar de forma continua puede ser mucho más devastador que destruir grandes cantidades de datos de una sola vez.

Una situación potencialmente aún peor puede ser simplemente leer los datos durante meses / años. ¿Cuántos números de tarjeta de crédito almacena en esa base de datos? ¿Contraseñas?

Nadie puede mostrarte la bala de plata de la inyección SQL. Depende de los datos que guardes, la habilidad del atacante, si tienen conocimiento interno, la arquitectura del esquema, etc.

    
respondido por el bahamat 26.12.2010 - 10:02
fuente
0

Si el sitio es Drupal, podrían alterar la contraseña para el usuario 1 en la tabla de usuarios para proporcionarles acceso administrativo, y más daño dirigido más adelante ya que ahora tienen la capacidad de explorar el sitio con privilegios de administrador.

    
respondido por el Dave Keays 21.12.2010 - 20:57
fuente

Lea otras preguntas en las etiquetas