log4jの脆弱性(CVE-2021-44228)は意外とIPSやWAFでの検知が難しいかも

ども。こんばんは。

週末にビッグな脆弱性の話題が飛び込んできました。

通称log4shellと呼ばれるこの脆弱性はApache Log4j 2.15.0より前の2系のバージョンに影響があるとされています。

サーバサイドはじめ多くのJavaで書かれたプログラムに影響するのではないでしょうか。

【参考】

この脆弱性の厄介なところは、外部からクラスファイルを読み込めてしまうことによる影響と内部のロギングに利用していることで、影響範囲が膨大なところではないでしょうか。
例えばデバッグ目的でユーザからの入力をログに出したりするようなケース…ありえすぎる…

脆弱性のあるlog4jにとある文字列が渡されることで、JNDIという機能を通じて外部のladp/ldapsサーバ、dnsサーバ、rmiサーバと通信してしまう、更にladp(だけ?)サーバの応答を細工することでクラスファイルを読んで実行してしまうようです。
※ldapじゃなくてdnsにするとdnsクエリが飛びます。脆弱性が有効か試す上ではdnsが利用される可能性もありますね。

JNDI Lookupについて調べてみると「jndi:ldap」という感じの文字列が含まれるのでこれをWAFとかで弾いちゃえばいいじゃん、という気がしますが、そんなに単純でも無いようで、もうちょっと考えないとWAF やIPSが比較的簡単にバイパスされる恐れがあります。

以下参考ツイート。

実際に以下のサイトを参考においらもdocker上で脆弱なspring-bootを使ってテストしてみました。

https://github.com/christophetd/log4shell-vulnerable-app

参考ツイートはもちろん、こんな感じでもexploitは成立しました。
※別で用意したサーバにちゃんとldap通信が飛んできました。

${lower:j}ndi:ldap〜

現在各セキュリティ製品ベンダーから続々と対応するシグネチャが出ていると思います。

上記のようなパターンにも対応できているのかは要確認だと思われます。(実際においらは検証しましたが細かくは書きません…)

log4jの対策済みバージョンへの更新はもちろんですが、上記のようなバイパスの可能性はあるとしても、IPSやWAFがある場合は、シグネチャを有効化しておくことに越したことはないとは思います。今後上記のようなパターンに対応してくる可能性もあると思いますので。

【追記】
ちなみに、影響を少しでも抑えるという意味では、ファイアウォールやiptables/firewalldなんかで不要なLDAP通信を遮断するのも有効ではないかと思われます。そもそもインターネット直抜けでLDAP通信なんてそんなに無いだろうし、あったとしても宛先が限定できると思います。

クラウドとかだとアウトバウンド方向の通信の制御は最近あまりしない気もしますが、一昔前だと割と外向きもファイアウォールで制御してた気がするんですよね。
今回エクスプロイトが成立するかのチェックにDNSが使われるケースがありますが、DNSも本来であれば設定されたDNSサーバ以外のDNSサーバへの通信は塞いでおけばという気もします。
※昔気質の「DMZ」があるイメージのとあるネットワーク屋の感想ですが。。。

 

ではでは。またの機会に。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

This site uses Akismet to reduce spam. Learn how your comment data is processed.