Mostrando entradas con la etiqueta vulnerabilidad. Mostrar todas las entradas
Mostrando entradas con la etiqueta vulnerabilidad. Mostrar todas las entradas

martes, 22 de agosto de 2017

Solución para fallo de seguridad en el Router Vodafone Fibra (Huawei HG253s V2)

El router que Vodafone España proporciona a los clientes de fibra tiene un fallo de seguridad muy grave, que fue publicado en 2015 por Vincen Dominguez. Este fallo permite acceder a ciertas páginas del portal web del router sin autenticación. Pudiendo obtener así información como la contraseña de la red WiFi o sobre los dispositivos conectados al router (mas información aquí).

El fallo sigue estando presente a día de hoy. Sin embargo, el acceso a la configuración del router está limitado por defecto a las direcciones IP de confianza (de Vodafone) y a la red interna. 


Configuración por defecto Router Vodafone Fibra


Viendo la captura parecería que el router se encuentra protegido de conexiones desde el exterior. Pero no es así. Se olvidaron de incluir el servidor HTTPs en los ajustes, por lo que aunque se pueda bloquear de manera sencilla el acceso por HTTP, no es así en el caso de HTTPs. Por lo tanto, conociendo la IP pública del router, la vulnerabilidad sigue siendo explotable.


Redirección del puerto 443

Como primer intento para solucionarlo, activé una redirección del puerto 443 a un dispositivo inexistente en la red. El router permite hacer este ajuste, pero mueve el servidor HTTPs al puerto 8443. De esta manera se puede dificultar un poco el trabajo del atacante, por ser menos probable el análisis de ese puerto, pero no representa una solución válida para la vulnerabilidad. Además, el router no permite redirecciones en el puerto 8443, por lo que solo se podemos elegir entre el puerto 443 y el 8443.

El router no permite la redirección del puerto 8443

Regla en el Firewall del router

Tras dejar de un lado la solución de la redirección de puertos, decidí intentar añadir una regla al Firewall del router. Aunque a priori pueda parecer una tarea sencilla, es en realidad bastante tedioso. Es necesario conseguir la contraseña de la cuenta de admin del router y después conectarse por SSH para añadir el ajuste. Además esta modificación no es persistente, por lo que el servidor volverá a estar disponible si se reinicia el router (e.g. por un corte de suministro eléctrico).

Obtención de la contraseña de administración del router

Aunque la contraseña del usuario admin está disponible en numerosos hilos de Internet, esta es modificada por Vodafone desde la central al arrancar el router y Vodafone no la proporciona a los clientes. El procedimiento está explicado en esta entrada del blog Bitcloud, pero se encuentra un poco desactualizada.

Como se dice en el citado artículo, es necesario desconectar el router de la red de Vodafone y restaurar los ajustes de fábrica. Para ello, hay que presionar (por ejemplo, con un clip) el botón de reset del router durante 20-30 segundos hasta que todas las luces del equipo se apaguen y después soltar y esperar a que se reinicie. Una vez se ha reiniciado, debemos entrar al portal de administración del router (nuestra puerta de enlace predeterminada que deberíamos de recibir por DHCP) y autentificarnos con los credenciales por defecto (usuario: admin contraseña: VF-EShg253).

Una vez dentro del portal web router, se debe activar el Port mirroring en ethwan, ajuste disponible en la pestaña Status & Support. Usando el navegador Chrome, nos pregunta donde guardar un archivo .cap. Elegimos la ubicación y, mientras la descarga sigue activa, conectamos de nuevo el router a la red de Vodafone. Pasado un tiempo, el portal web nos cortará el acceso y la conexión a Internet debería funcionar correctamente desde nuestro ordenador. Ya que Chrome borrará el archivo .cap al cancelar la descarga, antes de cancelarla hacemos una copia del fichero .crdownload temporal que se ha creado y le cambiamos la extensión a .cap.


Contraseña de administración en Wireshark


El archivo .cap obtenido puede ser abierto con Wireshark, y como se muestra en la captura, empleando el filtro adecuado permite obtener las credenciales del usuario admin que Vodafone ha configurado. En mi caso el usuario admin es el número 1, pero es posible que cambie en cada dispositivo.

Accediendo por SSH

Una vez hemos obtenido las credenciales de administrador, debemos activar el acceso por SSH al router desde el portal web (en Settings > Access Control elegimos Allow para SSH en la red LAN)


Guardamos los ajustes (Apply) y ya podemos conectarnos por SSH al router. En Windows podéis usar el PuTTY y en Linux el comando ssh, en ambos casos con los siguientes parámetros:
  • Host / Dirección IP: La dirección IP privada del router
  • Usuario: admin
  • Contraseña: La obtenida en el paso anterior
Una vez conectados, os debería de aparecer la siguiente consola:



 Esta consola tiene muy pocas opciones, pero con el comando shell se abrirá BusyBox:


En esta terminal ejecutaremos el comando su para obtener privilegios de administrador y después añadiremos la regla de iptables que bloqueará las conexiones al servidor HTTPS (aunque el servidor esté escuchando en el puerto 8443 se debe usar esta regla, ya que el puerto es convertido en la tabla nat de iptables, que se comprueba antes que filter):

iptables -I INPUT -p tcp --dport https -j DROP
Tras ejecutar este comando, las conexiones al servidor HTTPs serán bloqueadas (incluso desde la LAN, pero seguimos teniendo acceso por HTTP). Para cerrar la conexión se puede usar el comando exit 3 veces (cerrar sesión de super usuario, cerrar BusyBox, y cerrar conexión ssh)

Persistencia

He tratado de  hacer el cambio persistente (conservado tras el reinicio del router) pero no lo he conseguido. Creé un script en /etc/init.d/ y lo añadí en el /etc/inittab, pero parece que no es ejecutado al inicio o no funciona correctamente. En todo caso, aunque creo que esta solución es interesante a modo provisional, es bastante compleja para ser realizada por cualquier usuario.

Finalmente, la solución ha pasado por emplear una Raspberry Pi que comprueba periódicamente si el router tiene el puerto 443 abierto. En caso de detectarlo abierto se conecta automáticamente por SSH y añade la regla al Firewall del router. El script está disponible en GitHub y ha sido probado en Raspbian.

Servicio técnico de Vodafone

Me he puesto en contacto con el servicio técnico de Vodafone, y los empleados recurrían a cambiarme la contraseña de administrador del router, modificarme las redirecciones de puertos o colgarme. Finalmente, el técnico que sí entendió el problema, no pudo replicar el fallo desde la central (?) y no me ofreció ninguna solución, ya que me indicó que aunque podía solicitar un cambio de router, el modelo que recibiría sería el mismo.

Por lo tanto, para evitar que datos sensibles de nuestra red WiFi estén disponibles en Internet por culpa de una vulnerabilidad (¡descubierta en 2015!), es necesario realizar todo este proceso, sin ningún apoyo por parte de la compañía, que ni siquiera proporciona las credenciales de la cuenta de administración del router.


viernes, 17 de marzo de 2017

Raspaudit

Hoy voy hablar del que fue mi Trabajo de Fin de Grado: Sistema de auditora de redes corporativas usando software libre sobre una Raspberry Pi. El proyecto está escrito en su mayoría en Python, y está formado por un módulo principal que se ejecuta en la Raspberry y que realiza una serie de análisis en la red y un servidor web Django/Apache que funcionaba en un servidor remoto.

Raspberry

Para realizar los distintos análisis, en la Raspberry se ejecuta un script principal, main.py, que se encarga de enviar la información al servidor y de llamar a los tres scripts que realizan cada uno uno de los análisis: pasivo, puertos-servicios y vulnerabilidades.

El análisis pasivo, tras obtener una dirección IP de la red por medio de DHCP, captura todo el tráfico que recibe sin enviar ningún tráfico a la red. De esta forma se evita activar cualquier alarma que pueda variar la información obtenida. La dificultad de esta parte radica en la falta de información existente, tanto sobre el formato de los paquetes de los protocolos analizados (algunos no eran detectados por Scapy, por lo que se necesitaba leerlos en hexadecimal) como en lo referente a Scapy, el cual tiene una curva de aprendizaje bastante elevada.

Este análisis, está implementado por medio de la potente librería Scapy, que facilita el manejo paquetes con Python. Gracias al tráfico que las máquinas envían a direcciones de broadcast (NetBIOS, SSDP...), se puede obtener informaron de las máquinas como su nombre o su sistema operativo y, en el caso de Windows, también la versión de este. Para comentar más detalladamente el análisis pasivo, escribiré una entrada sobre el tema más adelante.

El segundo análisis realizado es el de puertos y servicios. Partiendo de la lista de máquinas ya detectadas se emplea nmap por medio de la librería python-nmap para analizar los puertos y servicios de los nodos de la red y refinar la información sobre el sistema operativo de estos. Solo se estudian los puertos más comunes (e.g. 80, 443, 137...) y aquellos que se sabe que usan las máquinas por haberlos empleado para enviar tráfico broadcast. Por defecto, se emplea la opción -T0, para reducir las probabilidades de detección.

Finalmente se emplea OpenVAS (un conjunto de herramientas de análisis de vulnerabilidades), junto con la librería openvas.omplib, para analizar los puertos detectados como abiertos por nmap en busca de vulnerabilidades. Los principales retos para conseguir que esta etapa se realizara correctamente se debieron a la falta de documentación de OpenVAS, tanto para la instalación como para el procesado en Python de los resultados obtenidos, y en los limitados recursos de la Raspberry, que hacen necesario iniciar la carga de OpenVAS varios minutos antes de su uso. Por lo tanto, esta se realiza justo antes de empezar el análisis pasivo, dando tiempo más que suficiente para la carga de las librerías de detención de vulnerabilidades, que es lo que más tiempo lleva.

Durante todos los análisis, main.py envía cada cierto tiempo la información al servidor en formato JSON. Durante el último (vulnerabilidades), además de enviar un resumen de los resultados en JSON, se sube también al servidor el informe HTML generado automáticamente por OpenVAS. Aunque en las primeras pruebas este tráfico se enviaba por la propia red a auditar, se decidió después emplear una conexión auxiliar (3G/4G o WiFi) para ello, reduciendo el uso de la red objetivo. En todo caso toda la información se envía cifrada usando HTTPS.

Servidor

El servidor es el que recibe la información de la(s) Raspberries y la muestra de forma gráfica para el usuario. Para recibir la información (en JSON y HTML), dispone de una dirección /upload a donde se conectan las Raspberries. La autenticación de estas se realiza por medio del certificado que llevan instalado, garantizando la seguridad de la comunicación. En cambio, los usuarios finales necesitan un nombre de usuario y una contraseña para acceder. 

La interfaz gráfica ofrecida muestra (de izquierda a derecha):

  • Una lista de los dispositivos (Raspberries) de los que se ha recibido información
  • La lista de redes auditadas para el dispositivo seleccionado
  • Un gráfico de las máquinas detectadas
  • La información de la máquina seleccionada en el gráfico, junto con el enlace al informe de OpenVAS correspondiente en HTML, en caso de estar disponible.

Aplicación web Raspaudit

Conclusiones

En términos generales el proyecto cumplió con lo que me había propuesto. Se realiza un análisis bastante completo de las máquinas con las que se comparte dominio de broadcast y se envía la información a un servidor remoto por medio de una conexión independiente. 

Sin embargo, sí mejoraría la interfaz web, tanto en cuanto a su apariencia (por ahora no es responsive) como en funcionalidades (e.g. mayor opciones para controlar las Raspberries directamente desde la aplicación web). Además, extensiones como la auditora de redes WiFi pueden ser interesantes de cara a obtener más información relevante sobre las redes de una organización.