Contribución de Julio Gómez: Continuamos el post de antes de ayer sobre como se puede crackear un hash cracker:
Después de haber utilizado la aplicación varias veces, vemos que los mensajes que devuelve en la salida son exactamente iguales a los de la herramienta que os comentaba al comienzo de la entrada. Además de que si consultamos la sección "What's this site?" dice específicamente que el sitio está basado en findmyhash.
Sabiendo que findmyhash es un script en Python que se llama desde la línea de comandos y que la aplicación web está implementada en PHP, podría ser que el sitio estuviera realizando alguna llamada al sistema de la forma:
exec ("python findmyhash.py " . $_POST['encrypt-method'] . " -h " . $_POST['hash']);
Sabiendo que el servidor que utiliza es un Apache sobre Debian (se puede ver en la cabecera Server de la respuesta HTTP), se me ocurre probar una inyección de comandos en Linux. Algo parecido a "; ls":
La salida aparece estar acotada a un espacio demasiado limitado para poder hacer un 'cat' de algún fichero o utilizar cualquier otro comando cuya salida sea de más de unas pocas líneas. Sería genial si tuvieran instalado el netcat para ponerlo a escuchar en algún puerto y tener una shell...
; nc -v -l -p 22022 -e /bin/sh
Si no lo hubiera tenido hubiéramos podido hacer otras cosas, pero en este caso ha sido mucho más fácil de lo que esperábamos, con el netcat instalado, todos los puertos abiertos, etc.
Una vez dentro, le podemos pegar un vistazo al código de la aplicación y confirmar que codifican los parámetros de entrada con la función de PHP 'htmlentities' para tratar de prevenir los Cross Site Scripting, pero por desgracia para el desarrollador, no solo existen los XSS.
Nota Jose Selvi: Como nota curiosa, cuando estuvimos pegándole un vistazo a la aplicación a ver lo que hacía, vimos que guardaba en una base de datos local cada hash que se le introducía y contraseña exitosa calculada. En este caso no guardaba ninguna información más, pero podría estar guardando la IP de origen, con lo cual estaríamos proporcionando a un desconocido las llaves de nuestra casa, y además le habríamos puesto la etiqueta con la dirección. Es necesario tener mucho cuidado cuando se usan servicios públicos de crackeo de contraseñas, ya que si se crackea con éxito, no sabemos que va a pasar con esa contraseña.
¿Hemos dicho que la aplicación almacena en base de datos? Quizá podríamos explotar una Inyección SQL... En el próximo post.
.png "English"){kind=small}
Entradas
3 comentarios :
¿Una instalación Debian en producción tiene el netcat instalado por defecto? ¬¬
Si no es así, el administrador de la máquina es un crack
@Felipe: Yo he visto de todo, NetCat, NMap, GCC, e incluso recuerdo alguna vez que un administrador había hecho una prueba de crackeo de contraseñas y se había dejado en /tmp/ el fichero resultante del unshadow del john the ripper, y supongo que por no lanzarlo como root, le había cambiado los permisos y lo podía leer cualquiera.
A veces suponer que el administrador ha seguido todas las recomendaciones de seguridad... es mucho suponer.
Muy bueno el post, demuestra que no hay complicarse la vida, los admin muchas veces dejan las puertas abiertas sin darse cuenta.
Y muy buena lo de olvidarse el fichero de john de ripper jejeje
Publicar un comentario