13 noviembre 2012

Conectar Igualdad y su [in]seguridad

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.

Saludos!

Contribución por cortesía de  

12 comments :

Eduardo dijo...

Mil gracias por la entrada, magnífica como todas!!

Un pequeño apunte, el enlace a DB de la aplicación de Teacher está roto.
Gracias de nuevo!

sh4r3m4n dijo...

Hola Eduardo, perdón por lo del profesor, se cayó el link recién. En http://www.mediafire.com/?eye4x6kdrhnboec también lo podés bajar. Saludos!

Koky dijo...

Hace un puente en el TPM y listo, que tanto servidor y servidor

Lorenzo_Martinez dijo...

He actualizado el enlace que fallaba con el que ha puesto Matías. Por cierto, un gran trabajo!

Rodolfo dijo...

Me da un poco de verguenza la verdad, cosas tan basicas pasadas muy por alto. Alguien con un poco de curiosidad ya las saca, no necesitas ser muy "hacker". Vamos que un Router con admin/1234 y que encima te lo dice no se ve todos los dias.

Pero por otro lado, me gusta ver a chicos metiendoles mano y probando cosas, esa curiosidad hace que aprendan mas que con lo que viene instalado por default, por el solo hecho de cambiarlo, investigar y probar muchas cosas.

Horacio Paidón dijo...

Que temita eh..... bastante al desnudo lo dejaron con este articulo.... Perfecta crítica.... para demostrar que hay que capacitar mejor a los que diseñan estos sistemas.... SOy administrador de red... y con esto me veo abordado.. lo que hago es poner una clave al bios para frenar una de estas causas.... ya si abren los equipos... los mismos alumnos saben que se les puede retirar el mismo y perder garantia.

sh4r3m4n dijo...

Hola Horacio, por más que cambiarle la contraseña al BIOS sea otra medida para evitar los bloqueos, no es la mejor: no es necesario acceder al BIOS para cambiarle la fecha interna. No se puede (creo) desde Windows, pero en sistemas Linux sí, con el comando hwclock --systohc
Además se le puede quitar la contraseña al BIOS con algunos programas o dejándola un tiempo largo sin batería.
Saludos!

Sergio Orbe dijo...

Respecto a lo primero que trata el artículo de los TD server, hay varias cosas que no son ciertas:

1)Si hacés la búsqueda que decís en google, (al menos yo) solo veo servidores de uruguay y rumania... no encontré ninguno de argentina. Principalmente porque en TopSchool, que es el soft de los servidores, la VM en la que está alojado el TD Server no tiene ningún tipo de conexión a internet.
Además, los encargados de administrar estos servidores son los Referentes Técnicos de cada escuela. Supongamos que uno de estos RT es malo y quiere que ese servidor sea público en internet: Simplemente no puede, porque no tiene forma de cambiar la configuración de red de esa VM.

2)Ponele que sí pudieras encontrar el servidor en google y pudieras acceder desde internet. Cada netbook de los chicos, está asociada con un único TD server, por lo que tendrías que tener la suerte, además, de que ese servidor que encontraste en internet, sea justo a el cual esa netbook está asociada. También, el proceso para migrar una netbook de un TD server a otro es bastante más complicado y tiene mucho más seguridad.

JavierAR dijo...

Con tantos conocimientos que tenes, deberías saber que desbloquear la maquina por hardware no se puede, y lo que estas haciendo, mostrar la forma en la que se hace, es ilegal.

juan carloss dijo...

dejaaa de hablar asiii lo del gobierno es injusto para todoss q aprobados con 10 diezz y promedioo 10 XD igual nos lo blokeaa ..la net..y tiene q enviarle a bs aires para q lo desblokeee el gobiernoo ...ha¡¡¡ XD q mal para eso q no nos de net se va a hacer asi XD cerra el picoo de desir mas seguridad ..si cada dia hay mas gatosss en las calles q primeroo resuelva ese problema antes de meterce con informatica XD¡¡¡

diego dijo...

chupate un pene, anda a otro lado

Lucas dijo...

JAJAJA. No se puede desbloquear por hardware? Que raro... Como habré hecho con la netbook de mi hermano, jaja. Ya enserio, estudié electrónica durante 4 años, informática hace 3 aproximadamente y puedo asegurarte que lo único que necesitas para desbloquear el integrado que bloquea la pc es puentear las tomas del IC para que, como dice el artículo, deje de tomarlo el BIOS al bootear. Nada del otro mundo, si tenés un poco de conocimiento en electrónica solo te queda analizar el IC y fijarte cual tenés que puentear. Otro dato, si puenteas mal tenes la posibilidad de cagar la máquina entera (teniendo que sacar el integradoc ompleto y hacer una desviación de datos, cosa compleja y hasta imposible si no se tienen las herramientas y conocimientos adecuados)