Crackeando un Hash Cracker (III): SQLi con MD5

Contribución de Julio Gómez: Continuamos el post de ayer y acabamos la serie sobre como se puede crackear un hash cracker:

También veo que almacenan todas las contraseñas que la aplicación rompe en una base de datos... ¿Inyección de SQL? La sentencia que utilizan es similar a la siguiente:

mysql_query ("INSERT INTO table (timestamp, hash, algorithm, pass) VALUES ('".time()."', '".$hash."', '".$algorithm."', '".$pass."')");

Como la inserción sólo se ejecuta si se recupera la contraseña, el hash y el algoritmo de cifrado tienen que haber sido correctos para poder ejecutar findmyhash por debajo. Así que sólo podemos probar a inyectar en el campo 'password'.

Utilizando el mismo método que con el Cross Site Scripting, pruebo primero con una inyección sencilla:

1. calculo el hash de la cadena a inyectar. En este caso utilizo "password')#a" (sin las comillas): 380af891ac68ababff4d96cb2d242c06
2. pruebo a introducir el hash para ver si lo rompe la aplicación (que lo hace, ya que lo he calculado en uno de los servicios que utiliza).

3. accedo a la base de datos para que ver si ha añadido la cadena completa ("password')#a") o tan sólo la palabra "password", que era el objetivo. Y compruebo que la inyección ha funcionado, almacenando una password errónea:

Lo siguiente que se me ocurre es probar a insertar varios registros de una sola vez con una inyección como la siguiente:

fake1'),('1325005093','380af891ac68ababff4d96cb2d242c06','md5','fake2'),('1325005093','380af891ac68ababff4d96cb2d242c06','md5','fake3'),('1325005093','380af891ac68ababff4d96cb2d242c06','md5','fake4

cuyo hash es:

2751527becb471df139eb066442bef74

Si vuelvo a acceder a la base de datos puedo comprobar que se han añadido cuatro filas nuevas con tan sólo una consulta:

Nota Jose Selvi: Ciertamente, teniendo un acceso shell, quizá explotar una SQLi carezca de sentido, puesto que podríamos subir una webshell que accediera a la base de datos y la modificara de la forma que queramos, pero aún así Julio lo ha hecho para demostrar la existencia de la vulnerabilidad.

Como hemos visto, aunque la aplicación valida las entradas del usuario para tratar de evitar los Cross Site Scripting, hay otros vectores de inyección que no se han tenido en cuenta a la hora de implementarla.

En general, todos los datos de entrada de una aplicación, provengan de donde provengan (entradas de usuario, bases de datos, ficheros de configuración, salida de otras aplicaciones...), deben validarse de la manera más restrictiva posible y no hay que confiar en que el origen de los datos sea "confiable", porque como acabamos de ver, no siempre es realmente confiable todo lo que lo parece.

Espero que esta entrada haya servido para echarle un poco de imaginación a la hora de descubrir posibles vectores de inyección y para comprobar que todas las aplicaciones son susceptibles de tener alguna vulnerabilidad (hemos explotado tres vulnerabilidades diferentes a través del mismo parámetro).