Übersicht

Dieses Repository dokumentiert Sicherheitsforschung, die im Rahmen des HPE Networking Bug-Bounty-Programms auf Bugcrowd an ArubaOS 8.13.2.0 LSR durchgeführt wurde. Die gesamte Forschung wurde auf einer autorisierten Laborinstanz (virtuelle Maschine ArubaMC-VA-US) unter Verwendung der vom Programm unter dem offiziellen Firmware-Link bereitgestellten Firmware-Images und OVA durchgeführt.

Sechs Schwachstellen wurden identifiziert und eingereicht. Die Befunde umfassen den ICMP-IP-Stack, die XML-Verwaltungsschnittstelle (Port 32000) und den FTP-Dienst (Port 21). Sämtliche Tests erfolgten ohne Authentifizierung (Pre-Auth) — für keines der hier dokumentierten Befunde wurden Admin-Anmeldedaten oder aktive Sitzungen verwendet.

Befunde

Angriffsfläche

Alle dokumentierten Befunde erfolgen ohne Authentifizierung. Die Angriffsfläche besteht aus drei Komponenten:

Technische Zusammenfassung

Befund 1 — Pre-Auth XXE → HTTP SSRF

Der XML-Parser auf Port 32000 löst SYSTEM-Deklarationen externer Entitäten ohne Authentifizierung auf. Bestätigt durch:

• Paketmitschnitt auf Wire-Level: vom Controller initiierte Anfrage GET /test HTTP/1.0 an die Infrastruktur des Angreifers
• Eigenes sshd-Protokoll des Zielsystems: Bad protocol version identification 'GET / HTTP/1.0' from 127.0.0.1 — serverseitiger Nachweis der SSRF-Ausführung, vom Controller selbst aufgezeichnet
• Externe DTD wurde 3-mal unabhängig vom HTTP-Server des Angreifers abgerufen
• 9 interne Ports wurden über <dialog>success</dialog>-SSRF-Antworten als offen bestätigt

Triage-Antwort: "theoretical / no valid PoC" — nach vier Beweisstücken, einschließlich des sshd-Protokolls, nicht behandelt. Die erste RaR lief ohne Antwort ab.

Befund 2 — ICMP-Reflexion + Smurf-Verstärkung

Der ICMP-Echo-Handler validiert Quell-IP-Adressen weder anhand der ARP-Tabellenbindungen noch wendet er Reverse-Path-Filtering (BCP38/uRPF) an. Gefälschte ICMP-Echo-Requests führen dazu, dass der Controller unaufgeforderte Antworten an die gefälschte Quelle liefert. Broadcast-Quelladressen führen dazu, dass der Controller an ff:ff:ff:ff:ff:ff antwortet und die Antwort an alle Hosts im L2-Segment zustellt.

Nachweis: Zwei unabhängige Paketmitschnitte von zwei physisch getrennten Maschinen. Der Mitschnitt auf der Opferseite zeigt eine unaufgeforderte Echo-Reply an einem Host, der keinerlei ICMP-Requests gesendet hat.

Triage-Antwort: "expected network functionality" — der Opfer-seitige pcap wurde nicht behandelt.

Befund 3 — Ghost Leak (TTL=0 + IP-Total-Length-Überlesen)

Der ICMP-Echo-Handler vertraut IP_Total_Length, ohne die tatsächliche Größe des empfangenen Frames zu validieren. Wird IP_Total_Length=46 bei tatsächlichen IP-Daten von 28 Bytes gesendet, liest der Handler 18 Bytes über die Paketgrenze hinaus aus dem Netzwerk-Empfangspuffer und gibt diese Bytes in der Antwort wieder.

Der Angriff verwendet TTL=0-Pakete (RFC 791 schreibt deren Verwerfung vor), wodurch er für Router, IDS, Firewalls und Protokollierungssysteme unsichtbar ist. 27/27 präparierte TTL=0-Pakete erhielten Antworten — 100% Antwortrate.

Gleicher Mechanismus wie CVE-2003-0001 (EtherLeak) und CVE-2021-3031 (Palo Alto PAN-OS), beide von den jeweiligen Herstellern akzeptiert.

Triage-Antwort: "only zeroed bytes" — die saubere Padding-Eigenschaft der virtuellen VirtualBox-NIC wurde als Abwesenheit einer Schwachstelle interpretiert.

Firmware-Analyse

Im Rahmen der Untersuchung zu Befund 5 (hier nicht veröffentlicht) wurden die über den FTP-Dienst verteilten AP-Firmware-Images per Reverse Engineering analysiert. Wichtige Erkenntnisse aus der statischen Analyse aller vier Firmware-Images:

Firmware-Format: Aruba Image Container (.ari) — LZMA-komprimiert, nicht verschlüsselt. Der Body verwendet Codesignierung (X.509) anstelle einer Vertraulichkeitsverschlüsselung.

Abgedeckte AP-Plattformen:

Bemerkenswerte Firmware-Erkenntnisse:

• Alle vier Firmware-Images enthalten Klartext-X.509-DER-Zertifikate am Dateiende, signiert von Aruba Networks Code Signing CA1, mit Subject-CN-Format ARUBA-PROD-{SERIAL}::{MAC}, in die echte Produktions-AP-MAC-Adressen eingebettet sind
• Dieselben zwei Zertifikate erscheinen auf allen vier Firmware-Plattformen (plattformübergreifende Identitätswiederverwendung)
• Linux 3.12.19 (ARM32-APs) — EOL seit 2014. Linux 4.1.45 (ARM64-APs) — EOL seit ca. 2022
• arm64.ari enthält /dev/tpm-cert (TPM-Chip), MACsec-Hardware (EIP-62/EIP-217), gponPassword-Funktion
• In Firmware-Strings offengelegte interne AP-Codenamen: Glenmorangie (AP-304/305), Aberlour (AP-303H), Bunker (AP-365/367), Aultmore (AP-555), Hendricks (AP-58x)
• Offengelegte Build-Server-Hostnamen: jenkins@c96556966d48, jenkins@317fcb08bd82, jenkins@aec499ab9b0f, jenkins@352b80449f0a

Zeitleiste

Anmerkung zum Triage-Muster

Fünf von sechs Einsendungen erhielten N/A-Antworten. Die einzige Einsendung, die eine Herstellerprüfung erreichte (d13d0e83), ist diejenige mit der unkompliziertesten Auswirkungsdemonstration (Anmeldedaten → Dateidownload). Die übrigen fünf — darunter Wire-Level-pcap-Beweise, serverseitige Daemon-Protokolle und direkte CVE-Präzedenzzitate — wurden auf Triage-Ebene geschlossen.

Im Fall von Befund 1 ist die erste Request for Response ohne jede Antwort abgelaufen. Im Fall der Befunde 2, 3 und 6 gehen die Triage-Antworten nicht auf die konkret eingereichten Beweise ein. In keinem Fall wurde der Triage-Abschluss technisch mit den beigefügten Beweisen abgeglichen.

Die Sicherheits-Community ist eingeladen, die einzelnen Write-ups zu prüfen und sich ein eigenes Urteil zu bilden.

Verantwortungsvolle Offenlegung

Alle Befunde wurden vor der Veröffentlichung an das HPE Networking Product Public Program auf Bugcrowd eingereicht. Das Programm hat die Befunde 1, 2, 3, 4, 5 und 6 als keine Schwachstellen eingestuft.

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