Carpeta sessions y los hashes md5 recuperados de las tablas.

Carpeta sessions y los hashes md5 recuperados de las tablas.

de German Sanchez Garces -
Número de respuestas: 3

Les dejo de nuevo otro documento que preparé, hablando sobre algo que posiblemente ya sepan que no se debe de hacer, como es publicar la carpeta Moodledata... el tema es que sin ser esta carpeta pública, una inyección SQL con un load_file o simplemente leyendo las columnas de mdl.users, se pueden comprometer las contraseñas con facilidad pues el cifrado es MD5.

http://www.enelpc.com/2011/10/admin-generosos-sessions-hash-cracking.html

Un Saludo!

Promedio de valoraciones: -
En respuesta a German Sanchez Garces

Re: Carpeta sessions y los hashes md5 recuperados de las tablas.

de Wenceslao Fernández -

Hola sonrisa

Muy cierto, la carpeta moodledata DEBE estar fuera del área pública (obligatorio en Moodle 2). El resto de problemas afectan a las versiones antiguas.

Si has podido hacer lo que dices en un servidor que tú administras, es que no estaba bien asegurado o actualizado (como sucede con muchos sitios)... es un problema de (mala) administración.

Un saludo

Promedio de valoraciones: -
En respuesta a Wenceslao Fernández

Re: Carpeta sessions y los hashes md5 recuperados de las tablas.

de German Sanchez Garces -

Buenas noches Wenceslao!

Gracias por la respuesta! Sabes si en Moodle 2.0 y posteriores los hashes utilizan otro algoritmo?

Pienso que aunque Moodledata tenga la obligación de estar fuera del área pública, los archivos de sesión deberían de estar cifrados por algún algoritmo two ways string. Imagina que existe una segunda instalación de Moodle en el mismo servidor, la segunda no tendría constancia de que ruta es la pública si esta se origina dentro de la primera.

Por otro lado, no hice pruebas para determinar si el hash de alguna de las sesiones se utilizaba en algún momento para que la cookie continuase con vida ¿no estaría bien que la password no se escribiese en disco?

  • Una Cookie que se genere con una primera validación y sea funcional durante el tiempo que esté configurada dicha sesión, en la que no salve contenido directo de la base de datos en un archivo...

Posiblemente tenga demasiadas pajas mentales...ojo morado jeje

Saludos! 

Promedio de valoraciones: -
En respuesta a German Sanchez Garces

Re: Carpeta sessions y los hashes md5 recuperados de las tablas.

de Iñaki Arenaza -
Imagen de Desarrolladores Imagen de Desarrolladores de plugins Imagen de Documentadores Imagen de Moderadores Imagen de Moodlers de gran ayuda

Algunos comentarios al respecto sonrisa

  1. Cifrar los archivos de sesión tiene un coste computacional (gasto de CPU) que habría que medir en cada caso. Hay que recordar que esos ficheros se leen al menos una vez por cada petición a Moodle (cada .php que se ejecuta). Y que hay que escribirlos al menos una vez al final de cada petición. Seguramente no es un coste brutal, pero hay que tenerlo también en cuenta sonrisa
  2. Si se usa la extensión de securización de PHP llamada Suhosin, ésta cifra dichos ficheros de sesión si se le indica (la configuración por defecto es cifrarlos). Usar PHP-Suhosin es siempre una buena idea (aunque no se cifren los ficheros de sesión guiño)
  3. Desde Moodle 1.9.7 se usa "Salado de contraseñas" http://docs.moodle.org/19/es/report/security/report_security_check_passwordsaltmain El salado se configura automáticamente en las nuevas instalaciones; para las actualizadas desde versiones más antiguas en el área de notificaciones se recomienda a los administradores que utilicen dicha funcionalidad para aumentar su seguridad. Con el salado de contraseñas, la rotura de las mismas por fuerza bruta o con diccionarios o rainbow tables se dificulta enormemente. Además, las "sales" de cada instalación de Moodle pueden (y DEBERIAN) ser diferentes. Con lo cual incluso si se comparte servidor eso no ayudaría a romper las contraseñas de las otras instalaciones.
  4. En realidad si se tiene acceso al directorio con los ficheros de sesión, no hace falta ni romper las contraseñas. El nombre del fichero de sesión es directamente el valor de la cookie de sesión. Con lo cual simplemente manipulando la cookie para que tenga ese valor automáticamente suplantamos al usuario propietario de esa sesión. De forma 100% limpia y transparente. De hecho, de cara a Moodle, somos el usuario en cuestión. Esto no es un fallo específico de Moodle. Esto es algo universal que afecta a todas las aplicaciones web que usen cookies para mantener sesiones. Es consecuencia del modelo de funcionamiento de HTTP, y por tanto algo prácticamente imposible de evitar.

Por otra parte coincido contigo que estaría bien que la contraseña no se escribiera en el disco (de hecho no hace falta que sea parte de la sesión para nada). Sospecho que es consecuencia de almancenar el objeto $USER en la sesión, ya que se usa de forma intensiva para un montón de operaciones. Y también sospecho que el objeto $USER se construye (parcialmente) obteniendo el registro de la tabla mdl_user directamente, que incluye la contraseña. No he mirado el código para confirmarlo, pero tiene bastante lógica [Edición: he mirado el código, y efectivamente es como sospechaba].

En todo caso, como pretendía aclarar arriba, si alguien tiene acceso a tus ficheros de sesión (aunque sólo sea a sus nombres) ya estás "muerto" (estén o no las contraseñas en los ficheros de sesión, y seas capaz o no de romper las contraseñas).

Saludos. Iñaki.

Promedio de valoraciones:Útil (2)