Más funcionalidades para tu red corporativa: un enfoque basado en técnicas hacking (I)


Seguridad Seguridad Web Desarrollo Web Seguridad de la Información Tecnología Router Hardware Redes Ingeniería

Recientemente nos hemos encontrado con una petición un tanto curiosa, y tras analizar el problema hemos ofrecido una solución algo inusual. Por supuesto, pensando en los que desconozcan el verdadero significado de "hacking", todo dentro de la legalidad. Al fin y al cabo no se trata de otra cosa que mejorar el trabajo que debían haber realizado los fabricantes de un router comercial.

Nos explicamos. Resulta que una pequeña empresa ha ido conservando (problema heredado) las infraestructuras iniciales adquiridas y se ha visto en un proceso de crecimiento corporativo que les ha ido dificultando la migración y evolución, a tenor de las opciones inicialmente escogidas. Generalmente se ha tratado de la adquisición de dispositivos de redes, tales como routers y switches, de bajo y medio coste. Su propósito solventa la mayoría de necesidades que requerían, hasta que ha dejado de ser así. Realmente no hablamos de algo tan drástico como la denegación de acceso o la imposibilidad de desplegar prototipos y servicios, pues hubieran adquirido nuevas infraestructuras sin pensarlo. Pero sí ha dificultado el trabajo colaborativo, los protocolos de calidad de servicio y las prioridades internas de la red corporativa.

Teniendo en cuenta los costes de renovación y amortización, la PYME ha ido reutilizando la misma infraestructura por multitud de equipos y sedes, de forma que al abordar este problema en uno de sus grupos de trabajo, podrían reutilizarlo en el resto, reduciendo costes. Tras analizar los dispositivos vimos el principal cuello de botella para facilitar la gestión y automatización de procesos internos: el router central.

Hay ocasiones en los que los clientes matan moscas a cañonazos, pero entendemos las razones históricas y monetarias. Al fin y al cabo todos hemos pecado de ello en alguna ocasión. Por este motivo, nuestro objetivo ha sido claro: tratar de proporcionar una API a un router administrado comercial, así como un servicio asociado de gestión al mismo, sabiendo que el fabricante solo proporciona un interfaz web con el que operar de forma manual. Otras dos soluciones alternativas (mucho más costosas para estos casos) habrían sido migraciones a routers/firmwares open-source, por ejemplo, utilizando OpenWRT, o haber optado por un router profesional de gama alta con administración remota.

Hace unos años hicimos un trabajo de análisis de portales de autenticación de routers, por lo que desempolvamos todo aquel material y refrescamos conocimientos. Por desgracia para nosotros y este trabajo, los tiempos cambian, y con ello, los mecanismos, protocolos y utilerías de autenticación. Por supuesto, nos encontramos al otro lado, pues siempre debería ser positivo si esto hace aumentar la seguridad sin comprometer la usabilidad ni la funcionalidad. Es decir, las técnicas utilizadas por el router TP-Link C7 Archer son novedosas, y no se puede reutilizar trabajo previo. Al menos de forma directa.

Hicimos un primer barrido a los manuales, listas de notificación e incluso la comunicación oficial con TP-Link. También repasamos proyectos con los que hemos trabajado en alguna ocasión, como OpenWRT, pfSense y sus asociados. Después de esta exploración inicial podemos concluir que no hay información sustancial de la capa que pretendemos saltar para satisfacer a nuestro cliente.

Nos ponemos manos a la obra, y comenzamos realizando una exploración generalista tanto del proceso de autenticación como de la interacción con los paneles y la información ofrecida por el router. Vemos que las necesidades de nuestro cliente se pueden llegar a suplir, pues mediante una combinación de software externo del sistema (un computador a modo de servidor DMZ siempre activo) unido a la información mostrada por este router, se puede llegar a construir una solución más que aceptable.

Una vez que vemos posible el objetivo desde el punto de vista funcional, comenzamos a explorar los detalles de implementación del sistema. Por supuesto, también de forma generalizada, pues tratamos de entender y reconocer patrones, frameworks, librerías y técnicas usadas por todo el aplicativo web del router.

analizando el flujo de trabajo del inicio de sesión y efiniendo la estrategia

Proceso exploratorio inicial en la búsqueda de patrones, librerías y técnicas de implementación usadas. Nuestro objetivo es llegar a manipular y procesar automáticamente componentes del interfaz de gestión de la izquierda.

El software ha cambiado significativamente con respecto a previas versiones y modelos con los que hemos trabajado, por lo que no solo ha mejorado en cuanto a su calidad sino en la complejidad de las técnicas y protocolos internos (entre el gestor frontend y el servicio interno del router). Desde luego sus desarrolladores se han aplicado y se han volcado de lleno en la comunicación asíncrona y la construcción dinámica. Por supuesto, todo esto dificulta nuestro análisis así como la progresiva modificación de funcionalidades y los ciclos de desarrollo-evaluación-depuración para llegar a nuestro objetivo. En definitiva, complica el contra-desarrollo y la inyección de nuestro código.

Ya que no pretendíamos realizar un complicado diseño y una reconstrucción arquitectural, nos centramos en tener el objetivo relativamente rápido, a costa de sacrificar un análisis más profundo, una mejor adaptabilidad a cambios internos y una mayor mantenibilidad ante nuevas características. Algunos de los primeros pasos que realizamos fue construir un esquema del protocolo de comunicación y los protocolos criptográficos utilizados, así como clasificar las funcionalidades -a grandes rasgos- teniendo en cuenta los recursos utilizados. Como ejemplo, se usan tres claves criptográficas, dos de las cuales van rotando con el paso del tiempo (AES y variantes hash), encapsuladas como blob streams mediante ajax, cifradas a su vez por la clave inicial (RSA). Además, la semilla de autenticación funciona a modo de sesión, que se invalida en diferentes regiones y con un periodo de tiempo como límite (algo lógico). Curiosamente, han realizado una implementación que nos recuerda al protocolo SSL para la fase inicial del portal de autenticación. Por otro lado, han dejado abierta la comunicación HTTP para la gestión (susceptible de ataques man-in-the-middle bajo la misma red), cosa que no entendemos, pues un intruso en la red local podría escalar y acceder al control de la red.

Este diseño complica las pruebas rápidas y la inyección parcial sobre los contenidos generados, por lo que tuvimos que ponernos a capturar trazas para una posterior regeneración del flujo. Fue un proceso un tanto tedioso, pero de esta manera mantuvimos una captura de todos los elementos utilizados por sesión, pudiendo realizar modificaciones del protocolo y replicar el funcionamiento con las características añadidas. Tras analizar las trazas y poder realizar tantas inspecciones y ejecuciones como viésemos necesarias, procedimos a realizar una prueba de concepto manual, simulando nuestras interacciones por medio de scripting visual. De este modo, agilizamos la construcción de bloques de inyección para las tramas generadas, y directamente verificábamos pequeñas pruebas en el proceso de autenticación y sus distintos estados, validando nuestras ideas antes de realizar ningún tipo de automatización.

Una vez generadas las pruebas de concepto con el proceso de autenticación, simulamos el mismo comportamiento con las tramas capturadas, comenzando a desarrollar código automático para diferentes regiones. Algunas son el intercambio de claves criptográficas, el envío de autenticación, la recepción de valores base o la propagación de claves secundarias. Se realizaron pruebas de concepto en donde se contrasten condicionantes dinámicos para manipular tanto el contenido como el flujo de determinadas tramas, afectando satisfactoriamente el proceso. Los condicionantes son estados que varían y afectan a otros estados posteriores, dependiendo de las restricciones temporales y condiciones, como por ejemplo la validez de tokens de intercambio criptográfico. El objetivo no es otro que preparar un entorno fácilmente modificable por si surgen cambios del protocolo (actualización de firmware) o de las características funcionales (necesidades y soluciones para el cliente). Una vez verificada con éxito esta "simulación", comenzamos a trabajar la automatización.

Como el siguiente paso es el proceso de automatización visual hasta conseguir ofrecer la solución integral para nuestro cliente, lo posponemos para la segunda parte de este artículo.

Este sitio web emplea cookies propias y de terceros para analizar el tráfico y ofrecerle una mejor experiencia. Al navegar o utilizar nuestros servicios el usuario está aceptando su uso.Más información.