El plan Conectar Igualdad tiene como fin la entrega de netbooks a las escuelas secundarias públicas en Argentina, y ya cuenta con dos millones de equipos entregados. Yo fuí uno de los alumnos que la recibieron, y ya hablé de ésta anteriormente en mi blog, primero con una crítica y luego con un post informativo para quitarle la publicidad.
En el día de hoy vengo a hablar acerca de las medidas de seguridad que se implementan tanto en las computadoras de los alumnos como en las de los profesores, o en los mismos servidores de la escuela que también se entregan junto a las netbooks.
Antes de empezar, me gustaría aclarar que el material publicado a continuación tiene fines educativos, y si alguien quiere darle un uso menos ético se puede sentir libre de hacerlo, pero bajo su propia responsabilidad.
Servidores
Dentro del colegio hay Access-Points en cada aula. Estos se encuentran conectados a un sistema central, para poder conectar a los alumnos y profesores a los servidores de la escuela. Estos servidores son máquinas virtuales que corren en un servidor bastante potente. La primera es más sencilla y corre un servidor Web que nos provee algunas aplicaciones y actividades, y la otra funciona como servidor de Theft Deterrent, el programa que gestiona los certificados de arranque que evitan el bloqueo de las computadoras.
Encontrando servidores de Theft Deterrent por Google
Un servidor de Theft Deterrent debería estar disponible solamente en la red local, ya que la gracia del sistema de bloqueo es que el dueño del equipo se conecte regularmente a un AP de su escuela para que se le renueven los arranques. Sin embargo, si buscamos en Google con un dork personalizado podemos encontrar servidores abiertos al público. Si una computadora de esa escuela es robada, el atacante podría renovar sus arranques conectándose a Internet y no necesariamente teniendo que ir regularmente a la escuela.
El dork a continuación es bastante sencillo y podría ser mejorado para obtener mayor cantidad de resultados o menos falsos positivos, aunque para mí fue más que suficiente: title:”Learning Series” inurl:tdserver
Vulnerabilidad XSS en los servidores de Theft Deterrent
La interfaz de administración web del servidor es vulnerable a un ataque de Cross Site Scripting en la página de login de alumno, ubicada en el path /tdserver/student/student_login.php, donde en el argumento GET hwid podemos inyectar código HTML o Javascript, y con esto podríamos robar una sesión legítima de un administrador con un poco de ingeniería social.
Routers con configuraciones por defecto
El enrutador usado no está debidamente configurado: el usuario y contraseña para acceder al panel de administración son los mismos que vienen por defecto (admin/1234). Algo bastante curioso es que ni siquiera es necesario buscar las contraseñas por internet en alguna página tipo Routerpasswords, sino que el mismo router la dice cuando intentamos acceder:
Una vez que accedemos al router con estas passwords por defecto, podemos administrarlo remotamente, pudiendo realizar una algunos cambios no deseados por los administradores:
Software
La netbook es entregada con una distribución bastante floja de Linux basada en Ubuntu y con una partición de Windows 7. Ambas tienen una gran cantidad de programas instalados por defecto relacionados con el estudio.
Linux: SSH activado por defecto
Como dije anteriormente, la distibución de Linux que viene integrada es sinceramente desastrosa, y no estoy hablando solamente de la baja calidad del diseño, sino también de las pésimas configuraciones incluidas.
Un ejemplo de esto es que vienen con el servidor de SSH activado por defecto, algo que no vi que pase en ninguna otra distribución de Linux. Estando en la misma red que una netbook corriendo ese Linux podríamos controlar el equipo remotamente. El usuario que viene por defecto es alumno, y la contraseña que tiene es la misma que el usuario. Este usuario tiene privilegios de sudo, con lo cual también se pueden ejecutar comandos como root, el usuario más privilegiado del sistema:
Identificación remota del propietario de la netbook
Para que la red funcione correctamente, cada equipo tiene que tener un nombre (hostname) diferente. En la guía oficial de Topschool nos recomiendan que sean del estilo Exomate001, Exomate002, etc. El problema es que en algunos colegios el patrón para los hostnames no es un número cualquiera, sino información más sensible.
Uno de estos casos se da en la Escuela Técnica Raggio, en la cual el nombre del equipo es el DNI de la persona seguido del año en el que ingresó, como se indica en su web. Haciendo un escaneo sobre la red de la escuela podemos saber todos los DNIs de alumnos y profesores del colegio, y hacerles un ataque dirigido o APT de una manera sencilla.
E-Learning Class
Siempre que se usan las netbooks en clase, los profesores obligan a los alumnos a usar el E-Learning Class. Este programa privativo y solamente disponible para Windows le permite al profesor gestionar la clase mediante el control de los equipos de los alumnos.
El protocolo que usa el programa, como muchos de los protocolos privativos, tiene bastantes brechas de seguridad de las cuales voy a hablar a continuación.
Cuando el programa del alumno nos da la opción de “conectarnos” al profesor, lo que realmente hace es informarle que se quiere conectar, y escuchar en el puerto UDP/4805 para recibir los paquetes supuestamente provenientes del maestro. Digo supuestamente porque no se hace una verificación de la IP o de algún access token del paquete, por lo que cualquier atacante puede generar un paquete malintencionado para el alumno. A continuación muestro la manera de hacer esto.
Cambiando el proxy remoto de la víctima
El programa le da al profesor la opción de cambiar remotamente la configuración de la computadora del alumno. Viendo un poco lo que nos permitía, me resultó bastante interesante la idea de cambiar el proxy por defecto de Windows, lo que nos permitiría capturar una gran parte del tráfico en Internet de la víctima, aun estando ésta desconectada de la escuela, debido a que la cofiguración persiste.
Para simplificar el ataque, hice un script que envíe un paquete personalizado a nuestra víctima, indicándole que cambie la configuración de su proxy. Su uso es bastante sencillo: cuando el alumno se encuentra conectado a un profesor, corremos el script pasándole como primer argumento su IP, seguido de la IP y el puerto de nuestro proxy. Veamos un ejemplo:
El ícono que remarqué en la bandeja del sistema indica que estamos conectados al profesor. Como se ve en la configuración, no se está usando ningún servidor proxy. Ejecutemos el script a ver qué pasa:
Siendo 192.168.2.6 la IP de la víctima y 123.123.123.123 la del servidor con el proxy. Una vez que se envía el paquete, veamos la configuración remota del alumno:
Como vemos, la configuración se cambió efectivamente. La mayoría de las aplicaciones usarán esta dirección como intermediario para internet, lo que nos podría permitir el monitoreo del tráfico de la víctima.
Código fuente del script que envía paquetes que cambian el proxy:
Ejecución remota de comandos en la víctima
Si lo anterior no fue suficiente, también podemos ejecutar comandos y aplicaciones remotamente, ya que el programa de profesor puede hacer esto y no hay una autenticación, como dije anteriormente.
Este proceso es un poco más difícil que el anterior, ya que el programa usa un sistema de checksum (verificación de la integridad) del paquete cuyo funcionamiento no pude entender todavía. Por lo tanto, debemos generar el paquete con una computadora con el E-Learning del profesor y enviarlo a nuestro propio equipo que use Windows y esté conectado al profesor. Mientras tanto, con otro script que hice sniffamos los paquetes buscando el indicado que ejecuta comandos en el alumno. Más tarde, enviaremos el mismo paquete a nuestra víctima.
Veamos más detallado el proceso para ejecutar el símbolo del sistema en la víctima:
Como primer paso corremos el script sniff_cmd.py para que capture el paquete cuando nos lo envíen. Antes que todo se debe instalar scapy para Windows.
El sniffer está corriendo, procedemos a ejecutar el comando desde el profesor:
Hecho esto el sniffer debería haber capturado el paquete:
El paquete es guardado en un archivo de nombre packet, y puede ser fácilmente reenviado a nuestra víctima con netcat. Usemos el siguiente comando: nc -u -w 1 xxx.xxx.xxx.xxx 4805 < packet
Con esto le indicamos que se comunique vía UDP, con un timeout de 1 segundo (enviamos el paquete y cierra la conexión, no nos importa recibir datos) a la IP de la víctima en el puerto 4805 que es en el que la aplicación escucha. Con un “<” le indicamos que le envíe el contenido del archivo packet, el paquete capturado. Hecho esto ya se debería estar ejecutando el cmd en nuestra víctima:
Códiigo fuente del sniffer:
Descarga del E-Learning para el docente: http://www.mediafire.com/?eye4x6kdrhnboec
Descarga del E-Learning para el alumno: http://dl.dropbox.com/u/45126758/student_2.0.38.154.exe
Sistema de bloqueo
Las netbooks tienen integradas un sistema anti-robos bastante avanzado. Para evitar el bloqueo el alumno se debe conectar regularmente a los servidores del colegio, donde automáticamente se le entrega un certificado para cuando arranque, el cual tiene una cantidad máxima de arranques y una fecha límite. Si se supera la fecha o la cantidad de arranques, la próxima vez que se encienda el ordenador este se bloquerá, y teóricamente la única manera de desbloquearlo será introduciendo un código de 10 digitos u obteniendo un certificado desde un pendrive generado por el administrador.
El bloqueo se realiza por hardware, un TPM no dejará encender correctamente cuando el certificado o los arranques hayan expirado.
Postergando el bloqueo cambiando la fecha
Un método bastante sencillo para evitar el bloqueo de la computadora es mediante el cambio de la fecha en el BIOS. Aunque ésta tarde o temprano se vaya a bloquear porque no le queden encendidos, en algunos casos podremos usarla un largo tiempo (en mi escuela me llegaron a dar 2000 arranques en un solo certificado)
Desbloqueo permanente por hardware
Si lo que queremos es anular el sistema de bloqueo para siempre, tengo amigos que lo que hicieron fue desarmar la computadora para hacer falso contacto con el chip TPM, provocando que el BIOS no lo tome en cuenta. Esto se puede ver más en detalle en este post o en el siguiente video:
Me gustaría aclarar que esto anula la garantía y hacerlo podría hacer que nos quiten el equipo los de Conectar Igualdad si este se encuentra en comodato.
Conclusión
Por más que el plan Conectar Igualdad en sí y los fines de este me parezcan una excelente idea, me parece que deben plantearse un poco mejor el tema de la seguridad. Hay más de una vulnerabilidad bastante grave expuesta en este artículo, por lo que espero que puedan ser resueltas.
Una medida que están tomando los aministadores es instalar Huayra, otra distribución mucho mejor de Linux que la que incluyen ahora. Quieren que sea el sistema operativo que bootee por defecto, por lo que los usuarios lo probarían y quizás se quedarían con este, en vez de usar solamente Windows y dejar a GNU/Linux de adorno en la computadora.
No hay comentarios:
Publicar un comentario
gracias por visitarnos, y participar