Menú Security Signal

May 6, 2020

Hacking en tiempos de Coronavirus Pt. 1: El punto de entrada!

by Alejandro Parodi

Es de público conocimiento que Coronavirus y la cuarentena forzaron que todas las empresas implementen velozmente la metodología de trabajo remoto, mejor conocida como Home Office.

En consecuencia se pudo ver un crecimiento de documentación relacionada a los riesgos del trabajo remoto, y las buenas políticas de ciberseguridad que una empresa y/o una persona deberían tomar para proteger la integridad de su negocio.

Sin embargo, es importante a tener en cuenta que en un modelo de trabajo Home Office, existen dispositivos dentro de la infraestructura local de las personas que no pueden ser controladas por las empresas.

Entendiendo esto, el equipo de Research de Security Signal se planteo las siguientes preguntas: ¿Es posible tomar control de la red local de una persona confinada en su casa? Se da por seguro que sí, pero… ¿cómo lo lograría un atacante?

El resultado fue una Prueba de Concepto de como un atacante podría encadenar 3 vulnerabilidades para tomar control remoto de una red local por medio de un link HTML.

Es importante destacar que a fin de facilitar la lectura de este documento, dividiremos las entregas en 3 Post: Hacking en tiempos de Coronavirus Pt. 1: El punto de entrada!, Hacking en tiempos de Coronavirus Pt. 2: Encadenando vulnerabilidades!, Hacking en tiempos de Coronavirus Pt. 3: Estoy en casa, pero no puedes verme!.

El punto de entrada:

La estrategia de nuestro Research no fue tomar control de un laptop en especifico, sino lograr conectarnos de forma remota a la red local de una persona y luego poder realizar ataques a esta red de forma indetectable, o lo más posible.

Una práctica común fue que las empresas forzaron a sus empleados a utilizar diferentes tipos de Software como Antivirus y VPNs, sin embargo no lo hicieron con sus proveedores de internet ni sus Routers domésticos.

Debido a esto centramos nuestro foco en este tipo de dispositivos, ya que es de publico conocimiento que en general no cumplen las políticas mínimas de seguridad que una empresa necesita y son difíciles de mantener ya que una vez instalados no cuentan con un proceso automatizado de actualizaciones de firmware.

Como detalle aún más pintoresco, una vez que los proveedores de internet instalan el dispositivo, el mismo no es modificado / actualizado a menos que este falle, por lo que existen múltiples dispositivos obsoletos (con vulnerabilidades criticas conocidas) dentro de las casas de millones de personas.

La medida general de seguridad que se tiene en cuenta por los ISPs al momento de proteger estos dispositivos es la siguiente: Se los configura para no estar expuestos a Internet, por lo que si un atacante quisiera abusar de estos solamente podría hacerlo en el contexto de la red local (LAN) ¿Cierto?

Esta medida parece ser infalible, pero si la miramos en detalle nos da el primer eslabón para nuestra cadena de vulnerabilidades:

Primer eslabón: Cross-Site Request Forgery

A grandes rasgos, una vulnerabilidad de CSRF, permite utilizar el navegador de una víctima para realizar solicitudes HTTP en su nombre por medio de JavaScript.

En general todos los Routers Domésticos solicitan autenticación para acceder su panel de configuración, si bien un ataque de CSRF puede utilizarse para realizar acciones como un usuario Autenticado, el equipo de Security Signal decidió tomar la perspectiva de un usuario no autenticado y considerar que el dispositivo no se encuentra configurado con credenciales por defecto (Por lo que un atacante no puede autenticarse en el dispositivo).

Así, la vulnerabilidad de CSRF simplemente fue utilizada para forzar a la víctima a enviar una solicitud HTTP a la/las IP internas que generalmente tiene asignado un Router domestico. Por ej: 192.168.0.1.

De esta forma un atacante podría superar la protección de no exposición a internet de estos dispositivos, ya que por medio de un link HTML + JavaScript malicioso, ejecutado en un navegador podríamos forzar a un dispositivo miembro de la red local (por ej: un PC) a enviar una solicitud a el Router Domestico situado en la misma Red Local.

Y así es como se vería un ataque:

CSRF to attack an Internal Network Device

Si se considera como escenario base, que el dispositivo no tiene credenciales por defecto y que un usuario no se encuentra actualmente autenticado al Router Domestico, la única alternativa que un atacante tiene para ejecutar acciones sobre el Router es por medio de un problema de autenticación, esto nos lleva al segundo eslabón de nuestra cadena de vulnerabilidades.

Segundo eslabón: Authentication Bypass

Una vulnerabilidad de Authentication Bypass en una aplicación es de los problemas más peligrosos ya que permite a un usuario realizar acciones (en general administrativas) sin estar autenticados.

Debido a los bajos recursos de hardware que tienen este tipo de dispositivos, la mayoría de los Dashboard Web, en realidad son “pequeñas” aplicaciones desarrolladas en C/C++ y por lo general son compiladas sin ningún flag de seguridad (DEP, ASLR, etc). Además, incluyen multitud de librerías privadas desarrolladas por el Vendor y ejecutan funcionalidades ocultas o no documentadas de forma insegura.

Esto abre un abanico de oportunidades para cualquier atacante en busca de vulnerabilidades, así como también a vulnerabilidades de corrupción de memoria que pueden desencadenar la ejecución de funciones privilegiadas sin autenticación y/o autorización.

Además, ciertos Vendors incluyen funcionalidades de soporte (backdoors) en el firmware de los dispositivos para acceder a estos en caso de “necesitar repararlos” por algún motivo.

Basta con buscar en la frase: “Router Authentication Bypass” en: https://cve.mitre.org/ para obtener un muy significativo listado de dispositivos que ya se conocen vulnerables a este tipo de ataques, como puede verse en la siguiente imagen:

Una vez detectada una vulnerabilidad de Authentication Bypass, el próximo paso de nuestra cadena de vulnerabilidades sería ejecutar alguna funcionalidad que se pudiera abusar para lograr Remote Code Execution.

Tercer eslabón: Remote Code Execution

Para este etapa, es necesario detectar una funcionalidad que pueda ser abusada y lograr ejecutar código o comandos arbitrarios en el dispositivo.

Un atacante podría lograr Remote Code Execution abusando multitud de funcionalidades básicas como:

1) La funcionalidad de actualización manual de firmware para lograr instalar uno modificado con Malware.

2) Funcionalidades de mantenimiento mal sanitizadas como Ping y Traceroute que podrían abusarse e inyectar comandos arbitrarios.

3) Funcionalidades de NAS (Storage) que permitan sustituir archivos del sistema por medio de Path Traversal.

También, podría utilizar vulnerabilidades de corrupción de memoria como se detalla en nuestro articulo: https://www.secsignal.org/en/news/exploiting-routers-just-another-tp-link-0day/ para lograr su cometido.

Hipótesis de explotación:

Encadenando estas 3 vulnerabilidades es posible para un atacante lograr ejecutar código arbitrario en algún dispositivo conectado de una red local (LAN) que no se encuentra expuesto a internet, forzándolo a conectarse con un servidor remoto (Reverse Shell) bajo el control de un atacante, utilizando solo HTML y JavaScript.

Para esto el atacante debería crear un sitio malicioso con contenido HTML y JavaScript (O inyectar JS malicioso en un sitio web concurrido) que fuerce el navegador de la víctima a ejecutar una solicitud Cross-Site Request Forgery (CSRF) que estará a cargo de bypassear la Autenticación de Router Domestico y como ultimo paso triggerear el Remote Code Execution que conectaría al Router con un Servidor Remoto controlado por el atacante.

Esto puede verse reflejado en el siguiente gráfico:

CSRF + Auth. Bypass + RCE to Reverse Shell

Una explicación de los pasos ejecutados en el gráfico anterior puede verse a continuación:

Primer paso: Una víctima desprevenida accede a un enlace malicioso por medio de un ataque de Phishing o un sitio web de gran tráfico infectado por JS.

Segundo paso: El navegador ejecuta una Solicitud CSRF (Bypasseando la no exposición a internet del Router Domestico), y abusa de forma automática (por medio de JavaScript AJAX/XHR + Timeouts) las vulnerabilidades de Authentication Bypass + Remote Code Execution.

Tercer paso: El Router ejecuta comandos arbitrarios y envía una conexión saliente (las cual no es bloqueada por los Firewalls en general) del tipo Reverse Shell a un servidor bajo el control de un atacante.

Si te gustó este artículo podrás ver en nuestras próximas entradas como encontrar las vulnerabilidades comentadas en este post , como generar un Exploit Chain completo para abusar de este escenario y como backdoorizar el Router Domestico y utilizarlo como túnel (pasarela/tunneling) entre el servidor del atacante y la red interna de la víctima, utilizando de forma encubierta el Router comprometido para atacar cualquier dispositivo de la red local de la víctima.