Descripción general

Este repositorio documenta la investigación de seguridad realizada sobre ArubaOS 8.13.2.0 LSR como parte del Programa de Bug Bounty de Redes de HPE en Bugcrowd. Toda la investigación se realizó en una instancia de laboratorio autorizada (máquina virtual ArubaMC-VA-US) utilizando las imágenes de firmware y la OVA proporcionadas por el programa en el enlace oficial de firmware.

Se identificaron y enviaron seis vulnerabilidades. Los hallazgos abarcan la pila IP/ICMP, la interfaz de gestión XML (puerto 32000) y el servicio FTP (puerto 21). Todas las pruebas fueron pre-autenticación — no se utilizaron credenciales de administrador ni sesiones activas para ninguno de los hallazgos documentados aquí.

Hallazgos

Superficie de ataque

Todos los hallazgos documentados son pre-autenticación. La superficie de ataque consta de tres componentes:

Resumen técnico

Hallazgo 1 — XXE pre-auth → SSRF HTTP

El analizador XML del puerto 32000 resuelve declaraciones de entidades externas SYSTEM sin autenticación. Confirmado mediante:

• Captura de paquetes a nivel de cable: solicitud GET /test HTTP/1.0 iniciada por el controlador hacia la infraestructura del atacante
• Registro del propio sshd del sistema objetivo: Bad protocol version identification 'GET / HTTP/1.0' from 127.0.0.1 — evidencia del lado del servidor de la ejecución del SSRF registrada por el propio controlador
• DTD externa obtenida 3 veces de forma independiente desde el servidor HTTP del atacante
• 9 puertos internos confirmados abiertos mediante respuestas SSRF <dialog>success</dialog>

Respuesta del triaje: "teórico / sin PoC válido" — no abordado después de cuatro elementos de evidencia, incluido el registro de sshd. El primer RaR expiró sin respuesta.

Hallazgo 2 — Reflexión ICMP + Amplificación Smurf

El manejador de Echo ICMP no valida las direcciones IP de origen contra los enlaces de la tabla ARP ni aplica filtrado de ruta inversa (BCP38/uRPF). Las solicitudes de Echo ICMP con origen falsificado (spoofed) hacen que el controlador entregue respuestas no solicitadas a la fuente falsificada. Las direcciones de origen de broadcast hacen que el controlador responda a ff:ff:ff:ff:ff:ff, entregando la respuesta a todos los hosts del segmento L2.

Evidencia: Dos capturas de paquetes independientes procedentes de dos máquinas físicamente separadas. La captura del lado de la víctima muestra una Respuesta de Echo no solicitada en un host que envió cero solicitudes ICMP.

Respuesta del triaje: "funcionalidad de red esperada" — el pcap del lado de la víctima no fue abordado.

Hallazgo 3 — Ghost Leak (TTL=0 + sobre-lectura de longitud total IP)

El manejador de Echo ICMP confía en IP_Total_Length sin validarla contra el tamaño real de la trama recibida. Enviar IP_Total_Length=46 con solo 28 bytes de datos IP reales hace que el manejador lea 18 bytes más allá del límite del paquete desde el búfer de recepción de red y los repita en la respuesta.

El ataque utiliza paquetes con TTL=0 (RFC 791 exige su descarte), lo que lo hace invisible para routers, IDS, firewalls y sistemas de registro. 27 de 27 paquetes manipulados con TTL=0 recibieron respuesta — una tasa de respuesta del 100%.

Mismo mecanismo que CVE-2003-0001 (EtherLeak) y CVE-2021-3031 (Palo Alto PAN-OS), ambos aceptados por sus respectivos proveedores.

Respuesta del triaje: "solo bytes a cero" — atribuyendo la característica de relleno limpio de la NIC virtual de VirtualBox a la ausencia de vulnerabilidad.

Análisis del firmware

Como parte de la investigación del hallazgo 5 (no publicado aquí), se aplicó ingeniería inversa a las imágenes de firmware de AP distribuidas a través del servicio FTP. Hallazgos clave del análisis estático de las cuatro imágenes de firmware:

Formato del firmware: Aruba Image Container (.ari) — comprimido con LZMA, no cifrado. El cuerpo utiliza firma de código (X.509) en lugar de cifrado de confidencialidad.

Plataformas de AP cubiertas:

Hallazgos notables del firmware:

• Las cuatro imágenes de firmware contienen certificados X.509 DER en texto claro al final del archivo, firmados por la Aruba Networks Code Signing CA1, con formato de CN del sujeto ARUBA-PROD-{SERIAL}::{MAC} que incorpora direcciones MAC reales de AP de producción
• Los mismos dos certificados aparecen en las cuatro plataformas de firmware (reutilización de identidad entre plataformas)
• Linux 3.12.19 (AP ARM32) — fin de vida útil (EOL) desde 2014. Linux 4.1.45 (AP ARM64) — EOL desde ~2022
• arm64.ari contiene /dev/tpm-cert (chip TPM), hardware MACsec (EIP-62/EIP-217) y la función gponPassword
• Nombres clave internos de los AP expuestos en las cadenas del firmware: Glenmorangie (AP-304/305), Aberlour (AP-303H), Bunker (AP-365/367), Aultmore (AP-555), Hendricks (AP-58x)
• Nombres de host del servidor de compilación expuestos: jenkins@c96556966d48, jenkins@317fcb08bd82, jenkins@aec499ab9b0f, jenkins@352b80449f0a

Cronología

Nota sobre el patrón de triaje

Cinco de seis envíos recibieron respuestas N/A. El único envío que llegó a revisión del proveedor (d13d0e83) es el que tiene la demostración de impacto más directa (credencial → descarga de archivos). Los cinco restantes — que incluyen evidencia pcap a nivel de cable, registros de demonios del lado del servidor y citas directas de precedentes de CVE — se cerraron en el nivel de triaje.

En el caso del hallazgo 1, la primera Solicitud de Respuesta (Request for Response) expiró sin respuesta alguna. En el caso de los hallazgos 2, 3 y 6, las respuestas del triaje no abordan la evidencia específica presentada. En ningún caso se reconcilió técnicamente el cierre del triaje con la evidencia adjunta.

Se invita a la comunidad de seguridad a revisar los write-ups individuales y formarse su propia evaluación.

Divulgación responsable

Todos los hallazgos se enviaron al Programa Público de Productos de Redes de HPE (HPE Networking Product Public Program) en Bugcrowd antes de su publicación. El programa ha clasificado los hallazgos 1, 2, 3, 4, 5 y 6 como no vulnerabilidades.

Vesqer / JM00NJ — netacoding.com — github.com/JM00NJ