Visão Geral

Este repositório documenta a pesquisa de segurança conduzida no ArubaOS 8.13.2.0 LSR como parte do Programa de Bug Bounty da HPE Networking no Bugcrowd. Toda a pesquisa foi realizada em uma instância de laboratório autorizada (máquina virtual ArubaMC-VA-US) usando as imagens de firmware e o OVA fornecidos pelo programa no link oficial de firmware.

Seis vulnerabilidades foram identificadas e submetidas. As descobertas abrangem a pilha IP/ICMP, a interface de gerenciamento XML (porta 32000) e o serviço FTP (porta 21). Todos os testes foram pré-autenticação — nenhuma credencial de administrador ou sessão ativa foi usada para qualquer descoberta documentada aqui.

Descobertas

Superfície de Ataque

Todas as descobertas documentadas são pré-autenticação. A superfície de ataque consiste em três componentes:

Resumo Técnico

Descoberta 1 — XXE Pré-Auth → SSRF HTTP

O parser XML na porta 32000 resolve declarações de entidade externa SYSTEM sem autenticação. Confirmado via:

• Captura de pacotes em nível de rede: GET /test HTTP/1.0 iniciado pelo controlador para a infraestrutura do atacante
• Log do próprio sshd do sistema alvo: Bad protocol version identification 'GET / HTTP/1.0' from 127.0.0.1 — evidência no lado do servidor da execução de SSRF registrada pelo próprio controlador
• DTD externo buscado 3 vezes de forma independente a partir do servidor HTTP do atacante
• 9 portas internas confirmadas como abertas via respostas SSRF <dialog>success</dialog>

Resposta da triagem: "teórico / sem PoC válido" — não abordado após quatro itens de evidência, incluindo o log do sshd. O primeiro RaR expirou sem resposta.

Descoberta 2 — Reflexão ICMP + Amplificação Smurf

O manipulador de Echo ICMP não valida endereços IP de origem contra as associações da tabela ARP nem aplica filtragem de caminho reverso (BCP38/uRPF). Requisições de Echo ICMP com origem forjada fazem o controlador entregar respostas não solicitadas à origem forjada. Endereços de origem de broadcast fazem o controlador responder para ff:ff:ff:ff:ff:ff, entregando a resposta a todos os hosts do segmento L2.

Evidência: Duas capturas de pacotes independentes, de duas máquinas fisicamente separadas. A captura do lado da vítima mostra um Echo Reply não solicitado em um host que enviou zero requisições ICMP.

Resposta da triagem: "funcionalidade de rede esperada" — o pcap do lado da vítima não foi abordado.

Descoberta 3 — Ghost Leak (TTL=0 + leitura além do limite de IP Total Length)

O manipulador de Echo ICMP confia em IP_Total_Length sem validar o tamanho real do quadro recebido. Enviar IP_Total_Length=46 com dados IP reais de 28 bytes faz o manipulador ler 18 bytes além do limite do pacote a partir do buffer de recepção da rede, ecoando esses bytes na resposta.

O ataque usa pacotes TTL=0 (o RFC 791 determina o descarte), tornando-o invisível para roteadores, IDS, firewalls e sistemas de log. 27/27 pacotes forjados com TTL=0 receberam respostas — taxa de resposta de 100%.

Mesmo mecanismo de CVE-2003-0001 (EtherLeak) e CVE-2021-3031 (Palo Alto PAN-OS), ambos aceitos por seus respectivos fornecedores.

Resposta da triagem: "apenas bytes zerados" — atribuindo a característica de preenchimento limpo da NIC virtual do VirtualBox à ausência de vulnerabilidade.

Análise do Firmware

Como parte da pesquisa sobre a descoberta 5 (não publicada aqui), as imagens de firmware dos APs distribuídas via serviço FTP foram submetidas a engenharia reversa. Principais descobertas da análise estática de todas as quatro imagens de firmware:

Formato do firmware: Aruba Image Container (.ari) — compactado com LZMA, não criptografado. O corpo usa assinatura de código (X.509) em vez de criptografia de confidencialidade.

Plataformas de AP cobertas:

Descobertas notáveis no firmware:

• Todas as quatro imagens de firmware contêm certificados X.509 DER em texto claro ao final do arquivo, assinados por Aruba Networks Code Signing CA1, com formato de CN do Subject ARUBA-PROD-{SERIAL}::{MAC} incorporando endereços MAC reais de APs de produção
• Os mesmos dois certificados aparecem em todas as quatro plataformas de firmware (reutilização de identidade entre plataformas)
• Linux 3.12.19 (APs ARM32) — EOL desde 2014. Linux 4.1.45 (APs ARM64) — EOL desde ~2022
• arm64.ari contém /dev/tpm-cert (chip TPM), hardware MACsec (EIP-62/EIP-217), função gponPassword
• Codinomes internos de APs expostos em strings do firmware: Glenmorangie (AP-304/305), Aberlour (AP-303H), Bunker (AP-365/367), Aultmore (AP-555), Hendricks (AP-58x)
• Hostnames de servidores de build expostos: jenkins@c96556966d48, jenkins@317fcb08bd82, jenkins@aec499ab9b0f, jenkins@352b80449f0a

Linha do Tempo

Nota sobre o Padrão de Triagem

Cinco das seis submissões receberam respostas N/A. A única submissão que chegou à revisão do fornecedor (d13d0e83) é a que apresenta a demonstração de impacto mais direta (credencial → download de arquivo). As outras cinco — que incluem evidências de pcap em nível de rede, logs de daemons do lado do servidor e citações diretas de precedentes de CVE — foram encerradas no nível de triagem.

No caso da descoberta 1, o primeiro Request for Response (Pedido de Resposta) expirou sem qualquer resposta. No caso das descobertas 2, 3 e 6, as respostas da triagem não abordam as evidências específicas enviadas. Em nenhum caso o encerramento da triagem foi tecnicamente reconciliado com as evidências anexadas.

A comunidade de segurança é convidada a revisar os write-ups individuais e formar sua própria avaliação.

Divulgação Responsável

Todas as descobertas foram submetidas ao HPE Networking Product Public Program no Bugcrowd antes da publicação. O programa classificou as descobertas 1, 2, 3, 4, 5 e 6 como não vulnerabilidades.

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