Panoramica

Questo repository documenta la ricerca sulla sicurezza condotta su ArubaOS 8.13.2.0 LSR nell'ambito del programma HPE Networking Bug Bounty su Bugcrowd. Tutta la ricerca è stata eseguita su un'istanza di laboratorio autorizzata (macchina virtuale ArubaMC-VA-US) utilizzando le immagini firmware e l'OVA forniti dal programma al link firmware ufficiale.

Sono state identificate e segnalate sei vulnerabilità. I risultati riguardano lo stack IP/ICMP, l'interfaccia di gestione XML (porta 32000) e il servizio FTP (porta 21). Tutti i test sono stati effettuati in pre-autenticazione — nessuna credenziale amministrativa o sessione attiva è stata utilizzata per alcun risultato documentato qui.

Risultati

Superficie d'attacco

Tutti i risultati documentati sono in pre-autenticazione. La superficie d'attacco è composta da tre componenti:

Riepilogo tecnico

Riscontro 1 — XXE in pre-auth → SSRF HTTP

Il parser XML sulla porta 32000 risolve le dichiarazioni di entità esterne SYSTEM senza autenticazione. Confermato tramite:

• Cattura di pacchetti a livello di rete: GET /test HTTP/1.0 avviata dal controller verso l'infrastruttura dell'attaccante
• Log sshd del sistema target: Bad protocol version identification 'GET / HTTP/1.0' from 127.0.0.1 — prova lato server dell'esecuzione di SSRF registrata dal controller stesso
• DTD esterno recuperato 3 volte in modo indipendente dal server HTTP dell'attaccante
• 9 porte interne confermate aperte tramite le risposte SSRF <dialog>success</dialog>

Risposta del triage: "teorico / nessun PoC valido" — non affrontata dopo quattro elementi di prova inclusi il log sshd. La prima RaR è scaduta senza risposta.

Riscontro 2 — Riflessione ICMP + amplificazione Smurf

Il gestore dell'ICMP Echo non valida gli indirizzi IP sorgente rispetto ai binding della tabella ARP né applica il reverse path filtering (BCP38/uRPF). Richieste ICMP Echo Request con IP sorgente spoofato fanno sì che il controller consegni risposte non richieste alla sorgente falsificata. Indirizzi sorgente broadcast fanno sì che il controller risponda a ff:ff:ff:ff:ff:ff, consegnando la risposta a tutti gli host sul segmento L2.

Prove: due catture di pacchetti indipendenti da due macchine fisicamente separate. La cattura lato vittima mostra una risposta Echo non richiesta su un host che ha inviato zero richieste ICMP.

Risposta del triage: "funzionalità di rete prevista" — la pcap lato vittima non è stata affrontata.

Riscontro 3 — Ghost Leak (TTL=0 + over-read della IP Total Length)

Il gestore dell'ICMP Echo si fida di IP_Total_Length senza convalidarlo rispetto alla dimensione effettiva del frame ricevuto. L'invio di IP_Total_Length=46 con dati IP effettivi di 28 byte fa sì che il gestore legga 18 byte oltre il limite del pacchetto dal buffer di ricezione di rete, rimandandoli in echo nella risposta.

L'attacco utilizza pacchetti TTL=0 (la RFC 791 ne impone lo scarto), rendendolo invisibile a router, IDS, firewall e sistemi di logging. 27/27 pacchetti forgiati con TTL=0 hanno ricevuto risposta — tasso di risposta del 100%.

Stesso meccanismo di CVE-2003-0001 (EtherLeak) e CVE-2021-3031 (Palo Alto PAN-OS), entrambi accettati dai rispettivi vendor.

Risposta del triage: "solo byte azzerati" — attribuendo la caratteristica di padding pulito della NIC virtuale VirtualBox all'assenza di vulnerabilità.

Analisi del firmware

Nell'ambito della ricerca sul riscontro 5 (non pubblicata qui), le immagini firmware degli AP distribuite tramite il servizio FTP sono state sottoposte a reverse engineering. Risultati chiave dell'analisi statica di tutte e quattro le immagini firmware:

Formato firmware: Aruba Image Container (.ari) — compresso LZMA, non cifrato. Il corpo utilizza la firma del codice (X.509) piuttosto che la cifratura per la riservatezza.

Piattaforme AP coperte:

Risultati notevoli del firmware:

• Tutte e quattro le immagini firmware contengono certificati X.509 DER in chiaro a fine file, firmati da Aruba Networks Code Signing CA1, con formato Subject CN ARUBA-PROD-{SERIAL}::{MAC} che incorpora indirizzi MAC AP di produzione reali
• Gli stessi due certificati compaiono su tutte e quattro le piattaforme firmware (riuso dell'identità tra piattaforme)
• Linux 3.12.19 (AP ARM32) — EOL dal 2014. Linux 4.1.45 (AP ARM64) — EOL dal ~2022
• arm64.ari contiene /dev/tpm-cert (chip TPM), hardware MACsec (EIP-62/EIP-217), funzione gponPassword
• Nomi in codice interni degli AP esposti nelle stringhe del firmware: Glenmorangie (AP-304/305), Aberlour (AP-303H), Bunker (AP-365/367), Aultmore (AP-555), Hendricks (AP-58x)
• Hostname dei server di build esposti: jenkins@c96556966d48, jenkins@317fcb08bd82, jenkins@aec499ab9b0f, jenkins@352b80449f0a

Cronologia

Nota sul pattern di triage

Cinque delle sei segnalazioni hanno ricevuto risposte N/A. L'unica segnalazione che ha raggiunto la revisione del vendor (d13d0e83) è quella con la dimostrazione d'impatto più diretta (credenziale → download di file). Le restanti cinque — che includono prove pcap a livello di rete, log dei daemon lato server e citazioni dirette di precedenti CVE — sono state chiuse a livello di triage.

Nel caso del riscontro 1, la prima Request for Response è scaduta senza alcuna risposta. Nel caso dei riscontri 2, 3 e 6, le risposte del triage non affrontano le prove specifiche presentate. In nessun caso la chiusura del triage è stata tecnicamente riconciliata con le prove allegate.

La comunità della sicurezza è invitata a esaminare i singoli write-up e a farsi una propria valutazione.

Divulgazione responsabile

Tutti i risultati sono stati inviati al HPE Networking Product Public Program su Bugcrowd prima della pubblicazione. Il programma ha classificato i riscontri 1, 2, 3, 4, 5 e 6 come non vulnerabilità.

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