Recientemente he tenido la ocasión de visitar webs de múltiples colegios de Sevilla por razones personales. Por deformación profesional no he podido evitar valorar por encima la seguridad de algunas de las webs visitadas.
Como podréis imaginar, los resultados no han sido muy buenos. Os resumo lo que he encontrado. No voy a dar nombres aquí, aunque si alguno tiene interés que me haga un DM en twitter y ya veremos.
La buena noticia es que, todavía, no hay mucha información sensible en los colegios que tenían vulnerabilidades. Pero eso no es ningún consuelo si imaginamos que la inclusión de nuevos servicios e información probablemente sea más rápida que la adopción de nuevas medidas de seguridad.
Colegio 1
Colegio privado bilingüe de renombre y bastante caro para gente exclusiva. Su web da un poco de pena porque parece traída directamente de los 90.
Se nota que está hecha a mano y que no utilizan ningún framework o software a medida. Está hecha en PHP. Nada más ver algunos de los enlaces nos podemos hacer una idea del problema: http://colegio1.com/index.php?main=datos/pollos.php
El contenido de la URL indicada en el parámetro main es empleado para poblar un iframe en la página resultante. Como podéis imaginar, modificandolo podemos hacer que muestre cualquier otro sitio. Y además, no sólo permite http://, podemos hacer que sea javascript: o data:
Una vez podemos ejecutar javascript en el navegador de alguien desde un sitio que no es nuestro, lo que podemos hacer depende de nuestra imaginación. Por ejemplo, phishing, desacreditación, SPAM, etc.
O mejor aún, ejecutar BeEF sobre el cliente y convertirlo en zombie. Desde BeEF es posible controlar el navegador del usuario e, incluso, explotar vulnerabilidades en el navegador, Flash o Java.
Echad un ojo al BeEF y decidme si os parece que el XSS no es importante.
Colegio 2
Otro colegio privado bilingüe muy afamado y de difícil acceso. De apariencia su web es mucho más moderna y cuidada con un diseño más profesional. Está desarrollada en PHP.
La web es informativa excepto por una sección de acceso privada (con usuario y contraseña) y un formulario de envío de datos. El formulario de envío de datos te deja enviar un mensaje a distintos departamentos.
Echando un ojo al código HTML nos encontramos la direcciones de correo a las que se envía el mensaje (para cada departamento) y el mensaje que se envía. Si cambiamos esos datos… ¡sorpresa! el formulario envía el correo a quién queramos con el mensaje que queramos desde la cuenta info@colegio2.com.
Por lo tanto, podemos suplantar al colegio con comunicaciones falsas personalizadas (si conocemos a alguien con niños en el colegio) o podemos emplearlo para enviar SPAM, ataques de phishing o cualquier otra idea maligna que se nos ocurra.
Se ve que los que han hecho la web no han pensado en la posibilidad de que se puedan usar comillas simples. Asi que si incluyes una, cierras el ‘string’ y puedes insertar comandos en el software que envía los mensajes.
Respecto a la autenticación de usuarios, pasa lo mismo. Con poner una comilla ya ves que hay SQLi. El clásico ' OR 1=1; -- te permite entrar como el primer usuario a la zona privada.
Colegio 3
El tercer colegio es un centro privado concertado normalito. Su web es simple, está desarrollada en PHP y tiene un menú en Flash para diferentes secciones.
No parece tener nada dinámico ni de acceso a simple vista. De hecho, varias secciones aparecen vacias o con ‘noticias de prueba’.
Sin embargo, probando la URL http://colegio3.com/admin nos encontramos un formulario de acceso para administración. Probando el clásico admin/admin podemos entrar como el único administrador de la plataforma. Nos permite crear usuarios, publicar noticias, poner texto en secciones, etc.
Colegio 4
Colegio privado de fama local sólo para infantil y primaria. Su página está desarrollada toda en Flash con un diseño rayante y, en mi opinión, poco efectivo.
Lo primero que notas es que el fichero Flash es colegio4_web2.swf por lo que si pruebas colegio4_web.swf puedes ver la version anterior.
En este caso, no hay nada demasiado grave en la versión anterior, aunque sí gracioso. Aparece una sección sobre webcams que no está en la nueva web. Lamentablemente esta sección indica que las webcams no son accesibles debido a que no hay consenso entre los padres.
En la nueva web, nos encontramos con una sección privada que pide ‘una contraseña’. Analicemos el código, a ver qué hace.
Empleando la herramienta flare, como vimos recientemnte, podemos ver el código del fichero colegio4_web2.swf. Resulta que hace dos peticiones de ‘carga de variables’, una a acceso.php y otra a datos.php.
Al parecer esto es bastante común en Flash. La aplicación carga un conjunto de variables de una web mediante una petición HTTP. Por supuesto, haciendo lo mismo podemos obtener y analizar tranquilamente esa información que suele ser del tipo clave1=valor1&clave2=valor2, etc.
Esto puede exponer información adicional y desvelar URLs internas. En el caso de este colegio (solicitado datos.php), podemos obtener las URLs de todas las fotos publicadas en la web. Por otro lado, acceso.php espera recibir una contraseña como valor y devuelve un conjunto de variables donde indica si la contraseña es váilda y el tipo de acceso que tiene. Así que, para pervertir al Flash, sólo hace falta capturar esa petición y modificarla como si tuviéramos acceso a todo.
Lamentablemente, en este caso no parece que haya mucha información, no estoy seguro de si es porque está sin terminar o porque hay que hacer algo más que se me ha escapado. Pero no deja de ser curioso este sistema que ‘no parece muy seguro’. Además, da la impresión de que cada ciclo formativo tiene una contraseña distinta, no por usuario.
En fin, esperemos que no activen las webcams con este nivel de seguridad.
Discusión
Estuve viendo webs de otros colegios a los que no pude sacar nada con el tiempo y conocimientos limitados que tengo. Es curioso porque estos centros usan Drupal, WordPress o la plataforma educativa Helvia (presente en los centros TIC aunque no siempre expuesta al exterior). Parece que utilizar un software ya hecho da más garantías que que te lo hagan de cero.
Eso sí, en ningún caso he visto HTTPS y en casi ninguno páginas de error personalizadas
Estoy seguro de que alguna vulnerabilidad tendrán, pero habrá que dedicar mucho más tiempo y esfuerzo. He de decir que estas pruebas las hice en un ratillo empleando únicamente curl y, en algunos casos, sqlmap. No he lanzado ningún analizador web automatico, que igual podría dar con otros problemas.
En cualquier caso, quiero resaltar la importancia de pensar un poco en la seguridad en el diseño antes de cometer estos errores tan tontos y de la importancia de revisar lo que se ha hecho.
.