FortiMailを侵入経路としたインシデントについての事例紹介

はじめに

インシデントレスポンスチームの戸祭 隆行です。

今回は、弊社で提供しているインシデントレスポンスサービスにおける対応事例を紹介します。

2022年3～4月にかけて対応したインシデントにおいて、インターネットに公開されているFortimailが侵入口であると強く考えられる不正アクセスを確認しました。特筆すべきは、PoCが公開されていない、認証無しでSQLインジェクションが可能な脆弱性（CVE-2021-24007）が利用された可能性がある点です。ただし、状況証拠から推測したものであり、明確な証跡があるわけではありません。

一部の脆弱性管理プロセスにおいて、PoCが公開されていない脆弱性は危険度が低いと判断され、パッチ適用が後回しにされることがあります。そのため一般的な注意喚起も兼ねて、本事例を紹介します。

なお、情報保護の観点から影響のない範囲で意図的に情報を変更している部分があります。

インシデント発覚

インシデント発覚の発端は、環境内部のDomain Controller（以下DC）でのEDR検知でした。

検知内容は、攻撃者が資格情報の窃取を試みたものでした。以下の検知内容の通りprocdumpコマンドでのLsassプロセスのダンプ操作を行ったほか、情報を持ち去るためのアーカイブ作成が検知されました。

当該サーバはインターネットからは到達不可能であるため、横展開により侵害されたと想定されます。侵入元を特定するためフォレンジック調査を行ったところ、DMZにあるFortiMailの仮想アプライアンスのIPアドレスからの不審なRDP接続が確認されました。

FortiMailにRDP接続を発信する機能があるか確認したところ、ビルトインのRDPクライアント機能はないことがわかりました。一方で、FortiMailのPOCが公開されている悪用しやすい脆弱性をクイックに調査したところ存在は確認できなかったため、不正なプログラムによりRDP接続が行われた可能性も低いと判断しました。そのため、設定ミスや設計不備により不適切に設定されたポートフォワーディング機能などにより、攻撃者の端末から発信されたRDP接続がFortiMailを介して中継されたのではないかとこの時点では考えていました。

この点を明らかにするため当該FortiMailのフォレンジックを行い、FortiMailがどのような方法で侵入経路にされたのかを明らかにしました。

FortiMailを侵入経路にした手口の調査

データの取得・復元

FortiMailのWeb GUIやCLIを操作して得られる情報は限定的なものでした。そのため、直接ファイルシステムを調査する必要がありました。

FortiMailの仮想ディスクは、メインの一部のパーティションにReiserFSというやや古いファイルシステムが使われていますが、一般的なUbuntuではReiserFS用のカーネルモジュールが用意されているため、容易に解析することが可能です。仮想ディスク内のファイルシステムを解析システムにマウントすることで、FortiMailの内部的な設定ファイルや、生のログファイル等を入手しました。また、ReiserFSに対応したフォレンジックツールX-Ways Forensicsを使用して、ファイル・ディレクトリのタイムライン分析を行い、不審事象のあった時期に操作されたファイルを調査しました。

なかでもインシデント調査に有用なものは、FortiMailのシステムイベントログ/klogでした。ログイン・ログオフをはじめ、設定変更など重要なシステム関連のログが記録されるものです。

しかし一部の日付のログがなく、また以下のようにファイルシステム上のログファイル名を見ると、日付に不審な乱れが見られました。本FortiMailは定期的に状態をロギングするため、停止していない限り何の操作もしなくともログは記録されるはずです。現用中のFortiMailが数日間停止したままになるとは考えにくいため、システムの不具合によりログが消えたか、攻撃者により意図的に削除されたと考えました。

このため、仮想ディスク全体を走査しシステムイベントログを復元しました。次のグラフの通り、日単位で見ると2022-03-09以外では、現存するログと同量程度以上のログが発見されており、ログの復元は高い確率で成功していたと考えられます。なお、グラフにした範囲だと2022-02-28および03-01近辺のログ量が突出して多く見えますが、半年などの広いスパンで見ると通常の量の範囲内となります。

復元期間の一部を抜粋し1時間単位でグラフ化すると、2022-03-08の22時ごろまでは復元できているであろうことがわかります。2022-03-08 23時~ 03-10 0時まではログが得られませんでした。しかし後述の調査で注目すべき、十分な期間のログが得られたと考えています。

ポートフォワーディング関係の設定不備

まず、初めに疑っていたポートフォワーディング関係の設定を確認しました。調査すべき機能は2種類あり、1つ目はFortiMailが標準機能としてもつポートフォワーディング機能で、2つ目はSSHポートフォワーディング機能です。

1つ目に関して、FortiMailのコンフィグを確認したところ、本機能は無効の状態でした。

システムイベントログからも過去に有効にされたことを示す設定変更ログは発見されませんでした。

2つ目に関して、SSHの内部的な設定ファイル（/etc/ssh/sshd_config）も確認しましたが、こちらもポートフォワーディングを禁止する設定が入っている状態でした。FortiMailでは、たとえシステム管理者でも通常の方法ではファイルシステム上の設定ファイルを自由に直接書き換えることは不可能です。そのため、過去に有効だったとも考えられませんでした。

つまり、単純なポートフォワーディングの悪用ではなさそうだとわかりました。FortiMail上で悪性なプログラムを実行されたことを疑い、調査を続けました。

FortiMailの侵害を示唆する不審なイベントログの発見

次に、どのような操作が行われたか、システムイベントログを調査していきました。

結果的に、インシデントに関連したログインログは発見されず、アップロード操作を示唆する以下の形式のログが2件見つかりました。

弊社の検証の限りでは、このログはファイルアップロードに使用されたユーザーインターフェース（Web GUI, REST API等）によらず同形式で出力されます。しかしUIフィールド（ ui=の部分）が空白のため、どのような方法でアップロードしたか知ることができません。これを知るためには、UIフィールドに値が入っている前後のログイン・ログオフログ等を見るしかありません。

前述のアップロードログの後に、ui=(null)となっている不審なログオフのログが発見されました。

通常はUIフィールドには「console」、または「ssh」、「GUI」、「RESTAPI」といったものがIPアドレスと一緒に記録されます。弊社の検証の限りでは、通常利用ではui=(null)となったケースはありませんでした。つまり、普通は発生し得ない不審なログオフログということになります。なお、このログオフログに対応するログインログは記録されていませんでした。

ログインログ無しでまずアップロードログがあったことや、ui=(null)となっている不審なログオフログが発見されたことから、通常のログイン処理を経ずに攻撃が行われた可能性が考えられます。

本FortiMailはインターネット上へWeb GUIを公開していたため、Web GUIの脆弱性利用を疑いました。しかし残念ながらWeb GUI用のWebサーバのログは仮想ディスクから発見されず、詳細な調査はできませんでした。推測とはなりますが、公開されたPOCがなく悪用する難易度が高いものの、認証無しで利用可能な脆弱性CVE-2021-24007（認証無しでSQLインジェクションが可能な脆弱性）等を用いてインターネットへ公開していたログインページ等を攻撃され、攻撃用のファイルをアップロードされたことが疑われます。

Webshellの発見

発見されたアップロードログに関して、アップロードされたファイルを調査したところ、ファイルシステムのタイムライン分析により、2種類のWebshell実行ファイルを発見しました。

1種目のWebshellは、BusyBoxというツールを用いたWebShellの機能を持つELF実行ファイルでした。Busyboxは標準的なUNIXプログラム（UNIXコマンド）を1つにまとめたツールです。これを用いて、FortiMail上でUNIXコマンドを自由に使用できるようにするWebshellでした。

以下がデコンパイル結果をもとにした疑似コードです。

本Webshellは、44個のUNIXコマンドがFortiMail内に存在するかを調べ、なければBusyboxの実行ファイルへのシンボリックリンクを張り、コマンドが使用できるようにします。実行するコマンドはHTTPリクエストのクエリストリングから取得します。

Busyboxの実行ファイルは、/var/spool/tmp/.upload-1_upuserfileにアップロードされたものを/var/spool/tmp/busyboxにリネームして使用します。

本WebshellはBusyboxを使いUNIXコマンドの使用準備をしているため、UNIXコマンドが一部しか使えないようなNW機器や、Dockerなどで使われる軽量なOSイメージをターゲットにしたWebshellの可能性があります。

2種目のWebshelは、Pythonで書かれ、PyInstallerでELF実行ファイルにしたもので、AESによる通信の暗号化機能をもつWebshellです。

以下がデコンパイル結果をもとにしたPythonコードです。AESの鍵等はマスクしています。

Webshellの機能は、upload・download・OSコマンドの実行の3点です。

• upload
  • 指定されたファイルへ、指定されたデータをアップロード（=書き込む)機能です
  • クエリストリングを用い、uploadという文字列と、書き込み対象のファイル名が連結して渡されます
  • POST等のリクエストボディ用い、ファイルへ書き込むべきデータが渡されます
• download
  • 指定されたファイルのデータをダウンロードする機能です
  • クエリストリングを用い、downloadという文字列と、読み込み対象のファイル名が連結して渡されます
• OSコマンド
  • OSコマンドを実行する機能です
  • POST等のリクエストボディを用い、実行するOSコマンドが渡されます

なお、通信は全てWebshell実行ファイルにハードコードされたAESの鍵や初期化ベクトルを用いて、「AES暗号化したあとBASE64エンコード」/「BASE64デコードしたあとAESで復号」されます。

侵害の流れ

攻撃者は上記のWebshellを利用して、HTTP/Sトンネリングツール等を設置・実行して、インターネット上の攻撃者からのRDP通信を中継させ、環境内のDCへアクセスして資格情報窃取を行ったと考えられます。なおDCの侵害に関しては、侵入方法を明確に特定することはできませんでした。トンネリングツールの実行ファイルについても発見できず、証拠隠滅のために消去されたと考えています。

今回のケースでは侵害方法は明確に判明しませんでしたが、外部に公開されたFortiMailを恐らく何らかの脆弱性を使い侵害され、DCの侵害まで繋がりました。その結果、前述の通りDCでの資格情報の窃取や、FortiMailでのログファイルの削除が確認され、またそのほかにもFortiMailからのメール情報の窃取が確認されるなど、大きな被害が発生しました。

POCが公開されていない脆弱性でも巧妙に利用され大きな被害につながることがあります。今回の事例もその一例であったかもしれません。このようなリスクを低減するためにも、危険性の高い脆弱性に関しては、POC公開の有無にかかわらず適切な管理を行うことが求められます。

IOC

2種のWebshell関係の情報をIOCとして記載します。

IOCタイプのFile-Pathはファイルが発見されたファイルパス、URI-PathはWebshell利用時のURIパスと推測されたもの、MD5-Hashはファイルのハッシュ値です。

（※これらのファイルの存在確認は、弊社で検証した限りFortiMailの通常の操作では不可能でした。ベンダへお問い合わせいただくか、フォレンジックをご依頼ください。）

今回見つかったWebshellでは、UNIXコマンドが十分に利用できない環境でもBusyboxを用いてUNIXコマンドを使えるようにするなど、他のNW機器等でも通用する工夫が見られました。そのためFortiMailに限らず適用できるIOCの可能性があります。

対策

FortiMailに限らず、インターネット等外部へサーバやNW機器を公開すると、たとえ強力なパスワードや二要素認証で保護されていても、ログインページ等へのアクセスだけで利用可能な脆弱性が存在する可能性が存在します。

外部公開時のリスクを意識し、以下に示す対策を取る必要があります。

外部公開を制限

サービス提供に必須ではない場合、不特定多数に公開することは避けます。例として、接続元IPアドレスを個別に/または利用地域ごとなどで制限をする必要があります。

脆弱性管理

リリースから1-2年程度のファームウェアでも危険な脆弱性が発見されている場合があります。攻撃に利用されるリスクを減らすため、脆弱性管理（脆弱性情報の把握、対応が必要かの判断）をしっかり行う必要があります。

今回のケースでは、約2年前のファームウェアを使用していましたが、ログインページ等にアクセスできれば認証不要で利用可能な脆弱性が存在しました。利用された可能性があるとして挙げた脆弱性CVE-2021-24007は、FortiMail の6.4.4バージョン以降では修正されているため、脆弱性管理によりファームウェアアップデート等の対応をしていれば利用されず済んだと考えられます。

社内の通信を制限

端末間の通信は最低限のみ許可し、横展開を抑制することが必要です。

今回のケースでは、DMZから内部サーバセグメントへの通信制御が適切にされておらず、社内環境での横展開にRDP接続が使用されました。業務に必要な通信を洗い出し、それ以外の不要な（特に横展開に使われやすい）通信をブロックしておく必要があります。

まとめ

インターネットへ公開していたFortiMailを侵害され、社内環境に入ってこられてしまった事例を紹介しました。せっかくのセキュリティアプライアンスでも、適切な脆弱性管理を怠ると新たなAttack Surfaceを作り侵害の窓口となってしまうことがあります。

今回はCVE-2021-24007を利用した可能性があり、POCが公開されていないものの実際に攻撃に利用された恐れがあるためこのような脆弱性に注意が必要です。サーバやNW機器の外部公開のリスクを意識し、公開先の制限や、脆弱性管理、そして社内端末間の通信の適切な制限が大事です。