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
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.
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:
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: http://pastebin.com/PuNbRBQc
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ódigo fuente del sniffer: http://pastebin.com/gvLV3WLv
Descarga del E-Learning para el docente: http://dl.dropbox.com/u/13495925/aplicaciones/elearningteacher-win7.zip
Descarga del E-Learning para el alumno: http://dl.dropbox.com/u/45126758/student_2.0.38.154.exeSistema 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!
Fuente: http://www.securitybydefault.com/2012/11/conectar-igualdad-y-su-inseguridad.html (el artículo es propio, fue publicado anteriormente en Secbydefault)
Tomado de: http://licenciaparahackear.wordpress.com/2012/11/13/conectar-igualdad-y-su-inseguridad/
Entradas
No hay comentarios:
Publicar un comentario