Ce dépôt documente la recherche en sécurité menée sur ArubaOS 8.13.2.0 LSR dans le cadre du programme public de bug bounty HPE Networking sur Bugcrowd. Toutes les recherches ont été effectuées sur une instance de laboratoire autorisée (machine virtuelle ArubaMC-VA-US) à l'aide des images firmware et de l'OVA fournis par le programme via le lien firmware officiel.

Six vulnérabilités ont été identifiées et soumises. Les découvertes couvrent la pile IP ICMP, l'interface de gestion XML (port 32000) et le service FTP (port 21). Tous les tests ont été effectués en pré-authentification — aucun identifiant administrateur ni aucune session active n'a été utilisé pour les découvertes documentées ici.

Découvertes

Surface d'attaque

Toutes les découvertes documentées s'effectuent en pré-authentification. La surface d'attaque se compose de trois éléments :

Résumé technique

Découverte 1 — XXE pré-auth → SSRF HTTP

Le parseur XML sur le port 32000 résout les déclarations d'entités externes SYSTEM sans authentification. Confirmé via :

• Capture de paquets au niveau fil : GET /test HTTP/1.0 initiée par le contrôleur vers l'infrastructure de l'attaquant
• Journal sshd du système cible : Bad protocol version identification 'GET / HTTP/1.0' from 127.0.0.1 — preuve côté serveur de l'exécution du SSRF enregistrée par le contrôleur lui-même
• DTD externe récupérée 3 fois de manière indépendante depuis le serveur HTTP de l'attaquant
• 9 ports internes confirmés ouverts via les réponses SSRF <dialog>success</dialog>

Réponse du triage : « théorique / pas de PoC valide » — non traitée après quatre éléments de preuve incluant le journal sshd. La première RaR a expiré sans réponse.

Découverte 2 — Réflexion ICMP + Amplification Smurf

Le gestionnaire d'Echo ICMP ne valide pas les adresses IP source par rapport aux liaisons de la table ARP ni n'applique de filtrage de chemin inverse (BCP38/uRPF). Des requêtes Echo ICMP usurpées amènent le contrôleur à envoyer des réponses non sollicitées à la source usurpée. Les adresses source de diffusion (broadcast) amènent le contrôleur à répondre à ff:ff:ff:ff:ff:ff, ce qui délivre la réponse à tous les hôtes du segment L2.

Preuves : deux captures de paquets indépendantes provenant de deux machines physiquement distinctes. La capture côté victime montre une réponse Echo non sollicitée sur un hôte qui n'a envoyé aucune requête ICMP.

Réponse du triage : « comportement réseau attendu » — la pcap côté victime n'a pas été traitée.

Découverte 3 — Ghost Leak (TTL=0 + dépassement de lecture de la longueur totale IP)

Le gestionnaire d'Echo ICMP se fie à IP_Total_Length sans vérifier la taille réelle de la trame reçue. L'envoi de IP_Total_Length=46 avec des données IP réelles de 28 octets amène le gestionnaire à lire 18 octets au-delà de la limite du paquet dans le tampon de réception réseau, et à renvoyer ces octets dans la réponse.

L'attaque utilise des paquets TTL=0 (RFC 791 impose leur abandon), ce qui la rend invisible pour les routeurs, IDS, pare-feu et systèmes de journalisation. 27/27 paquets forgés à TTL=0 ont reçu une réponse — taux de réponse de 100 %.

Même mécanisme que CVE-2003-0001 (EtherLeak) et CVE-2021-3031 (Palo Alto PAN-OS), tous deux acceptés par leurs fournisseurs respectifs.

Réponse du triage : « uniquement des octets à zéro » — attribuant la caractéristique de bourrage propre à la NIC virtuelle VirtualBox à l'absence de vulnérabilité.

Analyse du firmware

Dans le cadre des recherches sur la découverte 5 (non publiée ici), les images firmware des points d'accès distribuées via le service FTP ont été rétro-ingéniérées. Principaux résultats de l'analyse statique des quatre images firmware :

Format du firmware : Aruba Image Container (.ari) — compressé en LZMA, non chiffré. Le corps utilise une signature de code (X.509) plutôt qu'un chiffrement de confidentialité.

Plateformes AP couvertes :

Résultats notables de l'analyse du firmware :

• Les quatre images firmware contiennent des certificats X.509 DER en clair en fin de fichier, signés par Aruba Networks Code Signing CA1, avec un CN de sujet au format ARUBA-PROD-{SERIAL}::{MAC} intégrant de véritables adresses MAC de production des AP
• Les deux mêmes certificats apparaissent sur les quatre plateformes firmware (réutilisation d'identité multiplateforme)
• Linux 3.12.19 (AP ARM32) — fin de vie depuis 2014. Linux 4.1.45 (AP ARM64) — fin de vie depuis ~2022
• arm64.ari contient /dev/tpm-cert (puce TPM), le matériel MACsec (EIP-62/EIP-217), la fonction gponPassword
• Les noms de code internes des AP exposés dans les chaînes du firmware : Glenmorangie (AP-304/305), Aberlour (AP-303H), Bunker (AP-365/367), Aultmore (AP-555), Hendricks (AP-58x)
• Noms d'hôte des serveurs de build exposés : jenkins@c96556966d48, jenkins@317fcb08bd82, jenkins@aec499ab9b0f, jenkins@352b80449f0a

Chronologie

Note sur le schéma de triage

Cinq des six soumissions ont reçu des réponses N/A. La seule soumission qui a atteint l'examen du fournisseur (d13d0e83) est celle dont la démonstration d'impact est la plus directe (identifiants → téléchargement de fichier). Les cinq autres — qui incluent des preuves pcap au niveau fil, des journaux de démons côté serveur et des citations directes de précédents CVE — ont été clôturées au niveau du triage.

Dans le cas de la découverte 1, la première demande de réponse a expiré sans aucune réponse. Dans le cas des découvertes 2, 3 et 6, les réponses du triage ne traitent pas les preuves spécifiques soumises. Aucune clôture de triage n'a été techniquement réconciliée avec les preuves jointes.

La communauté sécurité est invitée à examiner les rapports individuels et à se faire sa propre évaluation.

Divulgation responsable

Toutes les découvertes ont été soumises au programme public HPE Networking Product sur Bugcrowd avant publication. Le programme a classé les découvertes 1, 2, 3, 4, 5 et 6 comme non-vulnérabilités.

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