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. 

jueves, 2 de marzo de 2017

MitM

Se que hay muchísima información sobre ataques man-in-the-middle en Internet. Sin embargo, tener tantos recursos disponibles puede hacer difícil encontrar lo básico para empezar. Con esta idea en mente, hoy quiero resumir las principales herramientas MitM disponibles para Linux y la forma de hacer con ellas un ARP spoofing, capturando el tráfico de la víctima.

Un ataque man-in-the-middle consiste en situarse en medio de la comunicación de dos partes sin que estas lo detecten. En el caso de redes locales (LAN), donde se suele compartir dominio de broadcast con los objetivos, se suele recurrir al envenenamiento de la caché ARP de la víctima o víctimas y de su puerta de enlace o gateway. Así el atacante puede escuchar todo el tráfico entre la víctima o víctimas e Internet

ARP es un protocolo que permite traducir direcciones IP a MAC, permitiendo a los dispositivos identificarse entre ellos a partir de la dirección IP. Este protocolo no tiene ningún tipo de autenticación, por lo que un atacante puede falsificar mensajes ARP (ARP spoofing), haciendo creer a la víctima que es el servidor o puerta de enlace con la que se quiere comunicar. Para poder capturar la respuesta del servidor, también se debe engañar a este o al router a través del cual se accede, siendo en este caso un MitM full-duplex. En caso contrario se considera half-duplex.

De esta forma el tráfico de la víctima pasa por la máquina del atacante, que lo debe reenviar al destinatario real (evitando que la víctima se quede sin conexión). Cabe destacar que, aunque todo el tráfico pase por la máquina del atacante, si la conexión está cifrada entre el servidor y la víctima, tener acceso a ese contenido es prácticamente imposible. Existen sin embargo métodos para sortear este problema, ya sea obligando al objetivo a establecer la conexión cifrada con la máquina atacante (en cuyo caso necesitaríamos que la víctima aceptase nuestro certificado o que su navegador confiase en nuestra autoridad certificadora) o forzando el uso de conexiones no seguras (e.g. SSLStrip).

La herramienta más extendida para MitM probablemente sea Ettercap, que lleva en funcionamiento desde 2001. Aún así existen otras soluciones, como BetterCAP o MITMf que implementan funcionalidades que me hace tenerlas en cuenta. Por ahora solo voy a comentar como hacer ARP spoofing y captura de tráfico con cada una de las herramientas, sin profundizar en otros aspectos o funcionalidades.

Ettercap

Ettercap lleva disponible bastantes años, por lo que muchas distribuciones Linux permiten instalarlo desde los repositorios del sistema. Además es de código abierto y debido a su amplio uso existe una gran cantidad de plugins disponibles para extender sus funcionalidades. Sin embargo estos se escriben en un lenguaje propio de Ettercap, incrementando la curva de aprendizaje.

Para realizar un ARP spoofing se puede emplear el siguiente comando (10.0.1.18 es dirección IP de la víctima y 10.0.1.1 es la de la puerta de enlace o gateway, aunque en este caso no importa el orden):
ettercap -T -M arp:remote /10.0.1.18// /10.0.1.1//
Por defecto, Ettercap solo captura el tráfico entre las direcciones indicadas. Para que capture también aquellos paquetes que tienen otro destino final (i.e. Internet) se debe de usar el modo remote. También se puede realizar el ataque en modo half-duplex (tráfico solo en un sentido) con la opción one-way, evitando así atacar directamente la puerta de enlace o servidor.


Una cuestión a tener en cuenta al realizar este procedimiento con Ettercap es que no activa automáticamente el reenvío de paquetes IP (IP forwarding), por lo que es necesario hacerlo de forma manual para evitar que la víctima se quede sin conexión.


Por defecto, Ettercap muestra todo el tráfico capturado, lo que en mi opinión no es muy útil, ya 
que hace díficil encontrar lo que se pueda estar buscando

Empleando la opción quiet (-q), Ettercap no muestra cada paquete y podemos consultar las conexiones que se están interceptando (Connections list) pulsando la letra c.


Se puede ver que la salida por pantalla de Ettercap no es del todo idónea. En todo caso, siempre se puede guardar la captura con la opción -w y abrirla luego en Wireshark. O también escuchar el tráfico directamente con este mismo programa.

BetterCAP

Con la intención de suplir las carencias de Ettercapevilsocket comenzó el desarrollo de esta herramienta de código abierto. En ciertas distribuciones como Kali Linux esta herramienta puede ser instalada directamente desde los repositorios. En el resto de distribuciones solo necesitamos el entorno RubyGems y seguir los pasos que se indican en la web oficial (en inglés).

Una vez instalada, para capturar el tráfico entre 10.0.1.18 y la puerta de enlace (detectada automáticamente por BetterCAP), solo hay que ejecutar el siguiente comando:
bettercap -T 10.0.1.18 --full-duplex

Por defecto, BetterCAP trabaja en modo half-duplex, para que capture tráfico en ambos sentidos hay que usar la opción --full-duplex. Con esta herramienta no es neceario activar IP forwading ya que lo hace automáticamente por nosotros.

Captura con BetterCAP

En comparación con Ettercap, BetterCAP muestra la información de una manera más resumida y organizada. Es mucho más cómodo que bucear entre toda la información que aparece con Ettercap, y en caso de querer hacer un análisis más exhaustivo del contenido siempre se puede guardar la captura (opción --sniffer-output) y analizarla luego con Wireshark.

Además, BetterCAP también resuelve las direcciones IP, obteniendo así el nombre del dominio junto con el recurso solicitado dentro de este, lo que facilita averiguar que páginas visitó la víctima de un vistazo. Para peticiones HTTPS (cifradas), solo obtenemos el nombre del dominio, pero no el recurso, ya que esa información no se transmite en claro. 

En este caso concreto, no obtenemos el dominio que introdujo la víctima (google.es) sino https://arn09s11-in-f163.1e100.net, que es el resultado de hacer una consulta DNS inversa (e.g. dig -x 172.217.22.163) de la dirección IP de destino. De todas formas, me sigue pareciendo más útil y claro que lo que muestra Ettercap.


MITMf

Lo primero que hay que tener en cuenta con esta herramienta es que, aun usando Kali Linux, la instalación es un poco más compleja en los casos anteriores. Sin embargo, tampoco es difícil, y los pasos a seguir están recogidos aquí (en inglés). Eso sí, la ruta que emplean para el comando source /usr/bin/virtualenvwrapper.sh no es correcta para Kali Linux. Para cualquier distribución, podéis comprobar la ruta del script con el siguiente comando:
find / | grep virtualenvwrapper.sh
Una vez instalado, para realizar un ataque análogo a los anteriores, podemos usar el siguiente comando (10.0.1.23 es dirección de la víctima y 10.0.1.1 es la puerta de enlace o gateway):
./mitmf.py -i eth0 --spoof --arp --target 10.0.1.23 --gateway 10.0.1.1
La información mostrada por MITMf es similar a la de BetterCAP, aunque, al contrario que esta, también trata de identificar el navegador y el sistema operativo de la víctima
Sin embargo, BetterCAP tiene como punto positivo que también muestra conexiones HTTPs y el marcado por colores hace más fácil la lectura de los datos.

Caputura de MITMf que muestra las conexiones de la víctima y realiza fingerprinting básico del navegador y del sistema operativo de la víctima.

Conclusiones

En general, para realizar un ataque MitM simple, cualquiera de las herramientas realiza la tarea correctamente. En cuanto a la información que muestra por defecto, la de BetterCAP es más clara, y MITMf realiza fingerprinting básico del navegador y del sistema operativo de la víctima. Sin embargo, en cualquier caso las capturas se pueden guardar en formato PCAP y ser analizadas más adelante, por lo que tampoco decanta claramente la balanza.

En cuanto a las herramientas que incluye cada una de ellas, Ettercap, posiblemente por su antigüedad, tiene una gran cantidad de plugins disponibles, escritos en un lenguaje específico. Para BetterCAP, los plugins se pueden realizar en cualquier lenguaje, ya que los paquetes se reenvían a ellos, actuando como un proxy. Además, incluye por defecto utilidades para crear conexiones HTTPS suplantando al servidor o para realizar ataques de tipo SSLStrip. Finalmente, MITMf incluye una gran cantidad de plugins: inyección/modificación de tráfico, SSLStrip+, secuestro de sesiones, JavaScript Keylogger...

Por tanto, todas las herramientas proporcionan características básicas similares, y la elección de una u otra debería venir dada por las características avanzadas que se necesiten en cada situación concreta. Para ver una comparativa más extensa entre BetterCAP y MITMf, con comentarios de los creadores de ambas herramientas, podéis consultar este hilo de Reddit (en inglés)