Log4shell（CVE-2021-44228）の社内SEとしての対応
2021年12月9日にTwitterへLog4jの脆弱性に関する投稿がありました。
Log4jとはJavaベースのログ出力ライブラリですが、名前自体は聞いたことない方が多いのではと思います（かくいう私も初耳）。
このページをご覧の社内SE各位はすでにLog4jがどういうもので、今回の脆弱性ことLog4shellがどういうものなのか調べに調べてご存じかと思います。
そこで本記事ではLog4shellについて深くは触れず、簡単に特徴を踏まえて社内SEとしての対応方針について考えを掲載することにします。
Log4shellの特徴
- 攻撃が非常に簡単（トリガーは特殊なHTTPリクエスト投げるだけ、PoCも公開済み）
- 影響範囲が広い（Log4jはウェブサーバに限らずネットワーク機器で使われていることも）
- バージョン範囲が広い（2016年リリースの初期バージョンから2021年までの約5年分のバージョンが対象）
- 悪用されたときの影響が大きい（任意コードが実行されるため、ほぼ攻撃者の操り人形と化す）
脆弱性対応（通常）
通常の脆弱性対応は日々の情報収集、該当製品を使っているか確認、影響の評価、必要な措置の実行といった形で進めていきます。
１．日々の情報収集によって公表される脆弱性情報をキャッチします。
２．深刻だったり影響の大きな脆弱性の場合は、その製品を社内で使っているかどうかを確認します。
この確認をするためには情報資産の棚卸や把握ということを日常的にできている必要がありますが、ここでは割愛。
３．次に、その脆弱性が悪用された場合に自社にとってどのような影響があるのか、いわばリスク評価を行います。
日々あらゆる脆弱性情報が公開されていますが、実は対応の必要なものはわずかだったりします。
４．影響の評価の結果、対応の必要ありとなればパッチを当てたり回避策を適用したり、サービスの停止を伴う場合は社内アナウンスの計画といった作業になります。
ざっくり簡単に脆弱性対応の通常の流れを書き出してみました。
通常対応の問題点
今回のLog4shellでは通常と同じ対応をしていると後手に回ってしまい、対策する前に悪用される可能性があります。
既に述べたLog4shellの特徴にある通り、今回の脆弱性は影響範囲が広い＆PoC公開済み＆深刻な脆弱性という質の悪いものです。
特に影響範囲の広さが対応が後手になる要因になりそうです。
通常対応の２番で公開された脆弱性情報の製品を使っているかどうか確認、という作業がありますが”Log4jの特定のバージョンで脆弱性がある”という情報はありますが、”具体的にどの製品でLog4jの特定バージョンが使われているか”という一覧のリストのような情報はまだありません。
これはLog4jがオープンライブラリで汎用性が高く、色々な製品で利用されているために引き起こされた状況です。
つまりLog4jの存在なんて聞いたこともない社内SEからすれば、どのサーバーのどのアプリでLog4jが動いているのかどうかすら分からない状況に陥ります。
そうなると脆弱性の影響を受ける製品が何かなのかが分からないので、対応２番の確認ができなくなってしまいます。
こうなると基本はベンダに頼らざるを得ないのですが、そうなると時間はどんどん過ぎていき影響範囲の把握をしている間に悪用されてしまう本末転倒な事態を招きかねません。
Log4shellの対応
通常対応では後手に回るお話をしたところで、じゃあどうするのかという話になります。
公開or社内で分割
完全に私見ではありますが、今回の対応は２番の作業を進める対象の優先順位をつけることがよいかと思います。
ゼロトラスト全盛の時代に逆行するようですが、社内ネットワークにあるイントラサーバーとインターネットに公開されているWEB,DNS,ルータ,FWなどなどでは攻撃を受ける可能性というのはやはり全く違うわけです。
今回のLog4shellに関していえば、公開サーバに攻撃を仕掛けようとするならばshodanみたいなサイトで適当な公開サーバを探してHTTPリクエストを送ってみるだけです。
おそらく各所で観測されている攻撃パターンもほぼ公開サーバを狙ったものでしょう。
つまり、守り手の立場（ブルーチーム）的には公開サーバ―系を対応の最優先と位置付けます。
その他のサーバー類については公開系の応急処置が終わってから、２番の作業を時間をかけてやればよいと思います。
自前でできるか、ベンダ依頼か
さらに公開サーバ―系を次の2種類に分類します。
- A.社内SEのスキルでLog4jのバージョン確認ができるもの
- B.社内SEのスキルではLog4jのバージョンはおろか存在有無すら分からないもの
Aに関してはさっさとLog4jのバージョンを確認しましょう。WindowsでもLinuxでも”Log4j”でファイル検索かければLog4jを使っているかどうかすぐに分かります。
あとは有志の方がまとめられている確認方法を使ってバージョンを確認しましょう。
また、バージョン確認ができれば回避策も実施できるはずです。
最新バージョンへのアップが望ましいですが、環境変数の設定だけで回避することも可能なので対応は各社で色々な事情を総合的に踏まえて判断することになろうかと思います。
さて問題はBの方です。公開系だけどメンテはベンダに一任してて触ったこともないし、そもそもどこをどう見ればよいのか全く分からないというパターンです。
方針としては”できることをやって当座をしのぎつつベンダの対応を待つ”という戦略をとります。
もしその機器がネットワーク機器（ルータやFW）の場合はメーカーのHPを確認してみてください。もしかすると既にLog4shellの対象かどうか、対象の場合は対応パッチが公開されているかもしれません。
また、ルータやFWはインターネット側からWEB管理画面にアクセスできるようになっていないか要確認です。
なっている場合は無効にすることでHTTPリクエスト自体をインターネットから処理しないのでLog4shellの悪用が防止できます。
WAFを既にかましている方は、そのWAFがLog4shellを検知・防御できるか確認しましょう。
内向きの通信だけでなく外向きの通信監視を強化することも有効です。WEBサーバから外向きLDAP通信が発生したらLog4shell悪用の可能性ありです。
・・・といった感じで少しでも悪用されない、悪用されても気付けるような準備を進めましょう。
上長への報告
どのレベルの上長に報告するのか、によって内容は随分と変わりますが、ここでは部課長級と想定します。
ITの話が理解してもらえる方に報告する場合はおよそこんな感じでしょうか。
”Log4jというライブラリにリモートコード実行の脆弱性が発見された。自社への影響の全体像を調査するにはかなり時間がかかるうえ、悪用されるとリモートで任意のコードが実行されてしまうことから、インターネット公開系を優先して調査・対応したい。社内系の調査は公開系の調査と緊急対応が終わり次第着手したい”
ITの話があまり理解してもらえない方にはこんな感じでしょうか。
”自社が社外にサービス提供している○○システムにセキュリティの問題があるかもしれないので調査したい。会社の中のシステムも影響があるかもしれないが、社外への影響を最小限にとどめるために○○システム関係の調査を先にやってから会社の中のシステムは調査したい”
実際にはもっとたくさんの報告や議論が起きると思いますが、自分の場合はおおよそ上記のスタンスで臨むことになるかと思います。
一次報告はこれくらいにして、次回報告は公開系調査が終わるか目途がついた段階で、回避策の適用方法やサービスの停止見込み等と一緒に行うとよいのではないでしょうか。
まとめ
公開系を優先して影響の調査をしよう
ベンダ依存の範囲はそれ以外の部分でカバーしつつ対応まで時間稼ぎ