NW機器

Fortinet製品における認証バイパスの脆弱性(CVE-2022-40684)に対するFortiOSでの緩和策について

※本記事の内容は、2022年10月18日現在の公開情報およびセキュアヴェイルグループにて、実機を用いた独自の検証結果をもとに記載しており、メーカの見解と異なる可能性があります。
※本記事の検証結果は脆弱性の影響を緩和できることをお約束するものではありません。
※検証を行った製品はFortiGate(FortiOS)のみとなります。
※具体的な脆弱性の内容や対応方法、設定内容の確認方法やバージョンアップ方法は購入元の代理店様や運用・保守ベンダー様へお問い合わせください。

更新履歴

2022/10/18 新規公開

はじめに

2022年10月10日にFortinet社より一部製品において認証をバイパスされる可能性のある脆弱性が発表されました。
本脆弱性を悪用された場合、認証されていない攻撃者でも特別に細工された HTTP または HTTPS 要求を用いることで管理インターフェースで操作を実行できる可能性があります。

脆弱性の概要

後述のセキュリティアドバイザリによるとFortinet社では本脆弱性を悪用した攻撃を観測しているとのことです。
また、本脆弱性のPoC(概念実証プログラム)が公開されており、今後悪用が拡大することが懸念されます。

【影響を受ける製品】

    • FortiOS バージョン7.2.0から7.2.1まで
    • FortiOS バージョン7.0.0から7.0.6まで
    • FortiProxy バージョン7.2.0
    • FortiProxy バージョン7.0.0から7.0.6まで
    • FortiSwitchManager バージョン7.2.0
    • FortiSwitchManager バージョン7.0.0
      ※FortiOS バージョン5.xおよび6.xは本脆弱性の影響はありません。

【参考情報】

実機での検証結果

上記、Horizon3.aiのPoCによると、認証バイパスが発生し得るのは、FortiGateが提供するREST APIであることが見て取れます。本来、REST APIへのアクセスには認証が必要です。しかし、認証ロジックにおいて不備があるため、HTTPヘッダを細工したリクエストを送信することで、認証をバイパスしてREST APIへのアクセスが可能となっています。

以下、弊社検証環境内で実行してみた様子です。PoCに記載の情報を参考に、パラメータは多少変更しております。

【検証環境】
機種:FortiGate 100F
ファームウェア:v7.0.1 build0157 (GA)

  1. REST APIへ、認証を行わず、特別な細工をせずアクセスした場合
    →結果は401 Unauthorized
  2. REST APIへ、認証を行わず、HTTPヘッダを細工しアクセスした場合
    →結果は「200 OK」

REST APIからは、FortiGate設定情報の参照はもちろん、編集も行えます。管理者パスワードの編集こそできないようですが、PoCにて行われているように、管理者のSSHキーを任意のものに編集する手順を経てSSHにて管理者ログインを行うことも可能となります。その他にも、ファイアウォールポリシーを任意の設定に編集することで、自由にFortiGate配下のネットワークにアクセスを行うことなども想定でき、悪用された場合には致命的な影響が発生すると考えられます。

Trusted Host(信頼されるホストにログインを制限)は本脆弱性の緩和策として有効か?

弊社で運用監視サービスを提供させていただいている顧客のFortiGateもそうですが、実環境においては多くの場合、インターネットに接するインタフェースでは管理者アクセスを有効にしていない、または、有効にしていてもIPアドレスで制限を行っているかと思います。

この、”IPアドレスで制限を行う”については、本脆弱性に対する緩和策としてFortinet社公開情報ページに記載の設定方法は、FortiGateのlocal-in-policyを用いるようになっており、弊社において標準的に用いているTrusted Host(※)設定は、果たして有効なのか、無効なのか、という点が公開されている情報からでは不明でした。
※日本語UIでは「信頼されるホストにログインを制限」、英語UIでは「Restrict login to trusted hosts」、CLIでは「trusthost」として表示される設定を指します。

そこで、弊社検証環境内で、本脆弱性の緩和策として、Trusted Host(信頼されるホスト)設定によるIPアドレス制限の有効性についても検証を行いました。

先程の「1.」「2.」の画面キャプチャは、いずれも、Trusted Host(信頼されるホスト)設定において登録されている、つまり、FortiGateへのログインを許容するIPアドレスに該当する端末からのアクセス試行でした。(より現実的な環境とするため、FortiGateのインターネットに接するインタフェースにて管理者アクセスを有効にした上で、Trusted Host(信頼されるホスト)設定を行い、インターネット越しで端末からアクセスを行っています)

この状態から、Trusted Host(信頼されるホスト)設定を編集し、当該端末のIPアドレスを除外します。つまり、端末のIPアドレスはFortiGateへのログインを許容するIPアドレスではなくなります。(local-in-policyは、当初より設定していません。)

  1. REST APIへ、Trusted Host(信頼されるホスト)設定において登録されていないIPアドレスの端末から、認証を行わず、HTTPヘッダを細工しアクセスした場合
    →結果はコネクションタイムアウト

なお、「3.」のとき、FortiGate側のパケットキャプチャの結果です。TCPスリーウェイハンドシェイクの段階で、成立していないことが確認できます。

[FortiGateホスト名] (root) # diagnose sniffer packet wan2 'host [端末IPアドレス]'
interfaces=[wan2]
filters=[host [端末IPアドレス]]
7.761979 [端末IPアドレス].59072 -> [FortiGateIPアドレス].443: syn 1471024581
8.027091 [端末IPアドレス].59073 -> [FortiGateIPアドレス].443: syn 1286127335
8.776865 [端末IPアドレス].59072 -> [FortiGateIPアドレス].443: syn 1471024581
9.039068 [端末IPアドレス].59073 -> [FortiGateIPアドレス].443: syn 1286127335
10.785195 [端末IPアドレス].59072 -> [FortiGateIPアドレス].443: syn 1471024581
11.049442 [端末IPアドレス].59073 -> [FortiGateIPアドレス].443: syn 1286127335
14.789911 [端末IPアドレス].59072 -> [FortiGateIPアドレス].443: syn 1471024581
15.054773 [端末IPアドレス].59073 -> [FortiGateIPアドレス].443: syn 1286127335
22.790104 [端末IPアドレス].59072 -> [FortiGateIPアドレス].443: syn 1471024581
23.055219 [端末IPアドレス].59073 -> [FortiGateIPアドレス].443: syn 1286127335
29.928029 [端末IPアドレス].59075 -> [FortiGateIPアドレス].443: syn 1036076684
30.189267 [端末IPアドレス].59076 -> [FortiGateIPアドレス].443: syn 4023994051
30.929005 [端末IPアドレス].59075 -> [FortiGateIPアドレス].443: syn 1036076684
31.195024 [端末IPアドレス].59076 -> [FortiGateIPアドレス].443: syn 4023994051
32.945769 [端末IPアドレス].59075 -> [FortiGateIPアドレス].443: syn 1036076684
33.207796 [端末IPアドレス].59076 -> [FortiGateIPアドレス].443: syn 4023994051
36.948230 [端末IPアドレス].59075 -> [FortiGateIPアドレス].443: syn 1036076684
37.213145 [端末IPアドレス].59076 -> [FortiGateIPアドレス].443: syn 4023994051
44.953385 [端末IPアドレス].59075 -> [FortiGateIPアドレス].443: syn 1036076684
45.217409 [端末IPアドレス].59076 -> [FortiGateIPアドレス].443: syn 4023994051
^C
21 packets received by filter
0 packets dropped by kernel

以上、弊社検証結果においては、本脆弱性の緩和策として、Trusted Host(信頼されるホスト)設定によるIPアドレス制限の有効性が認められました。そのため、Trusted Host(信頼されるホスト)設定が適切に行われていれば、不特定多数の攻撃者からの侵害を受ける可能性は低いと考えられます。
※Trusted Host(信頼されるホスト)は、すべての管理者ユーザに正しく設定されている必要があります。特定の管理者のみでも、Trusted Host(信頼されるホスト)が設定されていない場合は動作が異なる可能性があります。根本的な対策としては、修正済みバージョンへのバージョンアップ、不要な管理インターフェースの外部公開の停止等、Fortinet社のセキュリティアドバイザリをご参照ください。

なお、本検証結果については、2022年10月17日時点で公開されている情報をもとに実施したものであり、今後公開される情報等によっては、結果が変わる可能性があることをご理解ください。

最後に

本記事をご覧になられている方ご自身のFortiGateのバージョンや設定内容につきましては、製品購入元の販売店様や保守ベンダー様へご確認いただければと思いますが、弊社セキュアヴェイルでは、創業より20年間SOCサービスを提供し続けており、他ベンダー様で導入されたファイアウォール製品の運用も承っています。運用にご不安をお持ちのお客様は、お気軽にお問い合わせください。

SOCサービスお問い合わせ窓口 ⇒ https://www.secuavail.com/product/netstare/

記載されている会社名、システム名、製品名は一般に各社の登録商標または商標です。

当社製品以外のサードパーティ製品の設定内容につきましては、弊社サポート対象外となります。

LogStare CollectorでのAWS WAFログの取得方法とログレポート前のページ

LSC v2.3.3 build 221024 リリースノート次のページ

ピックアップ記事

  1. ログフォワーダー「okurun.jar」について
  2. IoT機器「Raspberry pi」とLogStare Collectorで温…
  3. 自社製品をAMIにしてAWSマーケットプレイスへ出品
  4. Zabbixヒストリデータのレポート生成について

関連記事

  1. NW機器

    FortiGateにてGUIにトラフィックログを表示するための設定方法

    FortiGateではトラフィックログを収集できますが、FortiGa…

  2. NW機器

    Allied Telesis(インテリジェント・エッジ・スイッチ)にSNMP v1/SNMPv2c設…

    当記事では、Allied Telesis社のインテリジェント・エッジ・…

  3. NW機器

    FortiGateのVDOM毎にログの転送先syslogサーバ指定を行う設定について

    当記事では、FortiGateのVDOM毎にログの転送先syslogサ…

  4. NW機器

    Cubro社Packetmasterによる複数のSyslog/SNMP-Trap転送を可能にする

    当記事では、Cubro社のPacketmasterを使用して、既存環境…

  5. NW機器

    D-Link製レイヤ2スマートスイッチにおけるSYSLOG/SNMP設定

    当記事では、D-Link製レイヤ2スマートスイッチにSYSLOG/SN…

Microsoft365もっと活用セミナー

ナレッジステアはセキュアヴェイルグループが運営しています

ネットワーク管理者向けセキュリティセミナー

無料で使えるシステム監視・ログ管理ソフト

  1. NW機器

    PaloAltoのIPsec IKEv1 Phase1におけるトラブルシューティ…
  2. SNMPを触ってみた

    ログ分析・監視テクニック

    SNMPとは?新入社員が生まれてはじめて触ってみた!
  3. ログ分析・監視テクニック

    nProbeであらゆる通信をログに記録し可視化する
  4. NW機器

    SonicWall UTMにSyslog送信設定を追加する方法について
  5. AWS/Azure

    AWSマーケットプレイス上から無償版のLogStare Collectorを試す…
PAGE TOP