情報処理安全確保支援士試験 過去問 2019年(令和元年) 春期 午後Ⅱ 問1
マルウェア感染と対策
N社は、従業員数5,000名の化学メーカであり、総務部、営業部、製造部及び情報システム部(以下、情シスという)がある。また、国内に工場がある。N社のLAN構成を図1に示す。
N社では、全従業員に一つずつ利用者IDが割り当てられ、その利用者IDとパスワードが認証サーバに登録される。タブレットPC、問合せ用PC及びD-PC(以下このの三つを併せて、社内PCという)へのログオン時並びに内部メールサーバ及びファイルサーバへのアクセス時には、認証サーバを使用して認証が実施される。イントラポータルサーバは、認証サーバと連携して、ベーシック認証を使用している。
総務部では、無線LAN接続型のタブレットPCを導入している。無線LANの暗号化では、WPA2を使用している。W-APでは、不正な端末の接続を防ぐための対策として、次の機能を使用している。
- 登録済みMACアドレスをもつ端末だけを接続可能とする接続制御
- 総務部に所属する従業員の利用者IDだけに接続を許可するIEEE 802.1X認証
IEEE 802.1X認証では、認証サーバと連携して、利用者IDとパスワードを使用している(EAP-PEAP)。
プロキシサーバでは、各機器からの全てのアクセスについて、アクセスログを取得している。
N社では、クラウドサービスを利用して、会社情報や製品情報を公開するWebサイトを運用している。Webサイトには、訪問者からの問合せを受け付けるためのフォームが用意されており、訪問者が問合せ内容を入力すると、その内容が電子メール(以下、メールという)でN社の特定のメールアドレス宛てに送信される。フォームにはファイルを添付する機能はないので、問合せメールにファイルが添付されることはない。万一、このフォーム以外から、この特定のメールアドレス宛てにメールが届いた場合は、そのメールは破棄される。問合せ用PCは、問合せメールを受信するための専用のD-PCで、他の用途には使用していない。また、問合せメールを他の社内PCで受信することはない。問合せ用PCから回答メールを送信する場合、回答メールの送信元メールアドレスには送信専用のメールアドレスを使用している。
FW1のルールを表1に、FW2のルールを表2に示す。
| 項番 | 送信元 | 宛先 | サービス | 動作 | ログ取得 |
|---|---|---|---|---|---|
| 1 | インターネット | 外部DNSサーバ | DNS | 許可 | する |
| 2 | インターネット | 外部メールサーバ | SMTP, SMTPS | 許可 | する |
| 3 | 外部DNSサーバ | インターネット | DNS | 許可 | する |
| 4 | 外部メールサーバ | インターネット | SMTP, SMTPS | 許可 | する |
| 5 | 内部メールサーバ | 内部メールサーバ | SMTP | 許可 | する |
| 6 | 内部メールサーバ | 外部メールサーバ | SMTP | 許可 | する |
| 7 | 内部IP | プロキシサーバ | 代替HTTP | 許可 | する |
| 8 | プロキシサーバ | インターネット | HTTP, HTTPS, FTP | 許可 | する |
| ... | ... | ... | ... | ... | ... |
| 15 | 全て | 全て | 全て | 拒否 | する |
注記2:項番が小さいルールから順に、最初に合致したルールが適用される。
注1):N社内で使用している全てのプライベートIPアドレスを示す。
| 項番 | 送信元 | 宛先 | サービス | 動作 | ログ取得 |
|---|---|---|---|---|---|
| 1 | 内部IP | インターネット | 全て | 拒否 | する |
| 2 | 内部IP | プロキシサーバ | 代替HTTP | 許可 | する |
| 3 | 内部IP | 内部メールサーバ | SMTP, POP3 | 許可 | する |
| 4 | 内部IP | 内部DNSサーバ | DNS | 許可 | する |
| 5 | 内部IP | 認証サーバ | LDAP, LDAP over TLS | 許可 | する |
| 6 | 問合せ用PC | 全て | 全て | 拒否 | する |
| 7 | 外部メールサーバ | 内部メールサーバ | SMTP | 許可 | する |
| 8 | 内部メールサーバ | 外部メールサーバ | SMTP | 許可 | する |
| ... | ... | ... | ... | ... | ... |
| 22 | 全て | 全て | 全て | 拒否 | する |
FW1とFW2は、ステートフルパケットインスペクション型である。FW1には、ペイロードの内容に基づくアプリケーション層での通信の挙動を分析し、マルウェアの動作に伴う不正な通信を検出して遮断できる機能(以下、L7FW機能という)がある。
インシデント発生
4月12日 13:00頃、セキュリティ情報共有団体から、「あるC&C (Command and Control) サーバを調査していたところ、そのサーバに対するN社からの通信記録を発見した。」との連絡が届き、その通信に関して、表3の情報が提供された。
| 送信元IPアドレス | aaa.bbb.ccc.ddd1) |
|---|---|
| 宛先IPアドレス | C&CサーバのIPアドレス |
| 宛先TCPポート番号 | 443 |
| 通信が開始された時刻 | 4月10日 14:00:00 |
情報提供を受けて、N社のCSIRTメンバが招集された。N社のCSIRTのリーダであるR課長は、メンバのP君に対して、情報処理安全確保支援士(登録セキスペ)であるW主任の支援を受けながら、直ちに状況を確認するよう指示した。P君は、表3の情報の真偽を確めるために、まずaのログを確認してN社から当
該通信が発信されていたとの確証を得た後、通信を開始した端末を特定するためにbのログを確認した。その結果、問合せ用PCからC&Cサーバに向けてHTTPSと思われるセッションが確立していたことが確認できた。
問合せ用PCの調査
状況の報告を受けたR課長は、問合せ用PCの調査を指示した。P君は、決められたインシデント対応手順に従い、まず問合せ用PCのHDDのコピー(以下、複製HDDという)を作成した。コピーは①ファイル単位ではなくセクタ単位で全セクタを対象とした。原本であるHDDはそのまま保全した。次に、予備のD-PCを新たな問合せ用PCとして設定して、問合せメールへの回答業務を継続できるようにした。
感染経路の調査
P君が、複製HDDの中に残っていた直近6か月分の問合せメールについて調査したところ、本文にURLが記載されたメールが幾つかあった。その全てのURLのサイトを調査したが、どのサイトも改ざんの報告はなく、関連したとしてもマルウェアに感染するおそれがないサイトだった。
問合せメールによるマルウェア感染がC&Cサーバとの通信の原因である可能性は低いと考えたP君は、調査方針をW主任に相談し、複製HDD内のログ及び関連機器内のログを調査することにした。その結果、図2の調査結果が得られた。
- 複製HDD内のログを調査したところ、4月10日 10:00に、あるIPアドレス(以下、被疑IPという)から問合せ用PCへのリモートデスクトップログオンが成功していた。そのログオンには、総務部のB さんの利用者IDが使用されていた。
- DHCPサーバ内のログを調査したところ、被疑IPは、4月10日 9:30から11:30までの間、あるPC(以下、被疑PCという)に割り当てられていた。
- W-AP内のログを調査したところ、4月10日 9:30に、被疑PCが発信元である、Bさんの利用者IDを用いたIEEE 802.1X認証要求が成功していた。
- 認証サーバ内のログを調査したところ、4月10日 9:30及び10:00に、Bさんの利用者IDの認証成功の記録があった。一方、4月10日 10:00から2月1日まで遡って確認したが、Bさんの利用者IDで認証失敗した記録はなかった。
- Bさんに話を聞いたところ、4月10日は休暇を取得していたとのことだった。念のために、タブレットPCのログを調査したが、4月10日に使用された形跡はなかった。
この調査結果から、P君は、攻撃者がBさんの利用者IDとパスワードを入手し、それらを利用して無線LAN経由で問合せ用PCに不正にログオンしたと判断した。
そこで、W主任は、不正なPCをW-APに接続させないための対策として、IEEE 802.1X認証の方式をEAP-TLSに変更する案を提案した。
また、複製HDDの分析を続けたところ、マルウェアと思われるファイルが残っており、実行されていた痕跡があった。
無線LANの脆弱性
P君は、総務部のW-APは、MACアドレスによる接続制御をしているのに、攻撃者がなぜ接続できたのか疑問に思い、W主任に聞いてみた。W主任は、②WPA2を使用していても、無線LANの通信が傍受されてしまうとBさんが利用しているタブレットPCのMACアドレスを攻撃者が知ることができることと、③攻撃者が、自分の無線LAN端末を総務部のW-APに接続可能にする方法をP君に説明した。
また、IEEE 802.1X認証で使用するBさんの利用者IDとパスワードを攻撃者が入手する方法について、次のように話した。
W主任: 最近、KRACKsと呼ばれるWPA2への攻撃手法が報告され、攻撃用のサンプルコードも公表されている。この攻撃を高い確率で成功させるためには、攻撃者は不正なW-APを設置し、正規のW-APと端末との間の中間者として動作させる必要がある。この攻撃が成功すると、WPA2で暗号化したパケットを解読されるおそれがある。N社は、4月10日より前に、この攻撃に遭っていながら、攻撃に気付かなかったのではないか。
P君は、KRACKsについて調べてみた。その結果、KRACKsは、攻撃者が特定の通信に介入することによって、WPA-TKIPおよびWPA2が使用するAES-CCMPというプロトコルの暗号を解読するものであることが分かった。解読の手段は、AES-CCMPの場合、CTRモードにおける初期カウンタ値を強制的に再利用させるものであった。AES-CCMPは、AESというブロック暗号とCTRモードという暗号モードをベースとしている。
暗号モード
P君は、暗号モードについても調べてみた。ブロック暗号を利用して長い平文を暗号化するには、平文をブロックに分割し、各ブロックに対して暗号化処理を適用する必要がある。ブロック暗号の適用方法を暗号モードと呼ぶ。最も単純な暗号モードはECBモードである。
暗号モードのうち、ECBモードとCTRモードの仕組みを図3に示す。
一般的なブロック暗号のブロック長は、64〜128ビット程度なので、暗号化のためTCP/IPパケットをヘッダも含めて平文ブロックに分割すると、④パケットがもつある特徴から、同一端末間の異なるパケットにおいて、同一の平文ブロックが繰り返し現れることが想定される。そのため、その平文の内容は高い確率で推測可能である。仮にTCP/IPパケット全体をECBモードで暗号化した場合、cが繰り返して現れることになり、暗号の解読が容易になるおそれがある。
CTRモードでは、暗号ブロックは、dとeの排他的論理和である。無線LANの場合、攻撃者は暗号化されたパケットを入手可能であるので、その暗号化されたパケットに対応するdが推測できた場合、eは容易に算出できる。これを踏まえるとCTRモードでは、初期カウンタ値の再利用の強制によって、同一のeを使用して異なるパケットの暗号文を作成してしまう可能性がある。
ここまで調べたP君は、イントラポータルサーバへのアクセスはHTTPであり、かつ、ベーシック認証を使用しているので、WPA2の通信を解読されると利用者IDとパスワードの流出に直結してしまうことに気付いた。
不審なW-APの発見と対策
無線LAN経由で侵入された可能性のある時期には、タブレットPCはKRACKsへの対策がされていなかったので、P君は、KRACKsによる攻撃を受けた可能性を調査する必要があると考えた。そこでP君は、W主任に相談して、攻撃者が不正なW-APを設置していないか、N社の周囲の無線状況を調査した。その結果、総務部のW-APと同一のSSIDが設定された不審なW-APが、N社敷地外にあることを発見し、KRACKsによる攻撃を受けたと結論付けた。
そこで、W主任は、KRACKsによってWPA2の通信が解読された場合でも被害を防ぐ対策として、イントラポータルサーバへのアクセスをHTTPSに変更する案を提案した。
L7FW機能の実効性の確認
一方、R課長は、FW1にはL7FW機能があることを思い出した。しかし、今回のインシデントでは、FW1が、マルウェアによる通信を不正な通信として検出した形跡はなく、通過させていた。この件について、R課長はP君に調査を指示した。
P君が、bのログを分析したところ、4月10日の10:00以降、問合せ用PCが発信元であるHTTPSと思われる通信が、通常よりも大幅に増加していた。これらの通信の大半は、表3のC&CサーバのIPアドレスを含む不審なIPアドレスへの通信であったことから、マルウェアによるものと推測された。一方、問合せ用PCが発信元であるHTTP通信は、ほとんどなかった。
続いてP君が、FW1の機能の設定状態を確認したところ、L7FW機能は有効化されていたが、HTTPS通信によって送受信されるデータを復号する機能(以下、HTTPS復号機能という)はライセンスがないので有効化されていなかった。この状態では、HTTPS通信に対してL7FW機能は効果がないことも分かった。P君は、これら一連の内容をR課長に報告した。
R課長は、インシデントの調査を終了し、W-APのIEEE 802.1X認証の方式を
EAP-TLSに変更する案と、イントラポータルサーバへのアクセスをHTTPSに変更する案を実施するとともに、残りの対策の検討に移ることにした。
未知マルウェア対策の改良
R課長は、今後、HTTPS通信を利用するマルウェアが増えると思われるので、社内PCについて、何らかの対策を打つ必要があると考え、W主任に検討を指示した。
W主任は、追加の費用が発生しない範囲で実施できる対策として、プロキシサーバがもつ、特定のURLへの接続を禁止するブラックリスト機能の適用を検討した。
HTTP通信の場合、プロキシサーバでは内容をfことができる。しかし、HTTPS通信の場合、社内PCからプロキシサーバにCONNECTメソッドによって接続要求を送る時点では平文でWebサーバのg名とポート番号が渡されるが、社内PCとWebサーバの間でTLSセッションが成立して暗号通信路が確立した後は、プロキシサーバでは内容をfことはできない。そのため、HTTPS通信の場合、実質的にブラックリストに登録できるのが、URLのg部とポート番号部だけであり、h部は指定できないことや、そもそもブラックリストに登録すべきURL情報が必要なタイミングで入手できないことから効果が期待できないとの結論となった。
そこで、追加の費用の発生も視野に入れた対策として、W主任は、ライセンスの購入によるHTTPS復号機能の有効化(以下、対策1という)及び社内PCのマルウェア対策の強化(以下、対策2という)の二つを考えた。それぞれの対策の内容は、表4のとおりである。
| 項目 | 対策1 | 対策2 |
|---|---|---|
| 概要 | FW1のHTTPS復号機能のライセンスを購入し、同機能を有効にする。 | 未知のマルウェアを検出するソフトウェアを購入し、社内PCに導入する。 |
| 期待する効果 | HTTPS通信であっても、FW1のL7FW機能を用いて、マルウェアによる不正通信を検出できる。 | (省略) |
| 考慮すべき点 | HTTPS復号機能によって、FW1の性能低下のおそれがある。 HTTPS以外の暗号通信には効果がない。 |
(省略) |
W主任は、⑤マルウェアが窃取した情報を社内PCから社外に送信する経路がFW1を経由したHTTPS以外にもあり、対策1とL7FW機能だけでは全ての経路を検査することはできないので、対策2も併せて実施する必要があると考え、P君に対策1及び対策2の検討を指示した。
対策1と対策2の検討
P君が、対策1と対策2の検討に当たり、HTTPS復号機能の動作の詳細を確認したところ、N社のLANでは図4に示す通信の流れになることが分かった。
また、HTTPS復号機能は、図5のとおりになることが分かった。
- 事前準備
- FW1が発行した自己署名証明書をiとして全ての社内PCに登録する。
- HTTPS復号機能による外部Webサーバのディジタル証明書の取り扱い
- FW1が、外部WebサーバへのHTTPSリクエストを検出した際に、宛先IPアドレスを変換し、FW1を終端として社内PCとの間でTLSセッションの確立を開始する。
- FW1は、ディジタル証明書及び対応する秘密鍵を作成する。
- FW1は、作成したディジタル証明書及び対応する秘密鍵を利用して社内PCとFW1の間でTLSセッションを確立する。
- FW1は社内PCとのTLSセッションの確立とほぼ同時に、クライアントとして外部Webサーバとの TLS セッションも確立する。
- 双方のTLSセッションが確立したら、FW1はその間で通信内容の転送を行う。
- 片方のTLSセッションの確立に失敗した場合は、もう片方のTLSセッションも終了する。
P君がFW1の製造元に対策1の実施を検討している旨を伝えたところ、無料で30日間だけ同機能を利用できる評価用ライセンスの発行を提案されたので、早速、評価用ライセンスを適用し、CSIRTメンバのD-PCから発信される通信で評価してみた。その結果、HTTPS復号機能には、通信の種類によっては制約があることが分かった。通信の種類と制約を表5に示す。
| 項番 | 通信の種類 | 制約の内容 | 制約の原因 |
|---|---|---|---|
| 1 | j | (省略) | 図4の流れの中で、FW1は、社内PCがもっているクライアント証明書に対応した秘密鍵を利用することができない。 |
| 2 | 外部Webサーバのサーバ証明書に軽微な不備がある場合に、利用者が不備を無視してアクセスする。 | (省略) | 外部Webサーバとにサーバ証明書の検証条件を変更するということができない。 |
| 3 | k | (省略) | FW1には、FW1の製造元によって安全性が確認されたCAのディジタル証明書だけが、信頼されたルートCAのディジタル証明書としてインストールされている。 |
P君は、これらの制約の回避方法を運用手順に含めることにした。表5の項番1の場合は、FW1のHTTPS復号機能の例外リストに外部Webサーバを追加することにした。例外リストにWebサーバを追加すると、例外的に復号機能を適用せず社内PCとWebサーバの間で直接HTTPS通信を行うことができる。例外とする場合には、業務上の必要性があること、及び正当なWebサーバであることを所定の手順で確認することにした。表5の項番2及び3の場合も、必要な内容を運用手順に含めた。
続いて、P君は、対策2の検討を行い、具体策をまとめた。W主任は、P君の報告を受けて、対策1と対策2の実施案をまとめた。実施案は、R課長からCSIRT責任者である情シス担当統括役に報告され、承認の上で実施された。以後、N社では、マルウェアによるインシデントは発生していない。