ども。こんばんは。
週末にビッグな脆弱性の話題が飛び込んできました。
通称log4shellと呼ばれるこの脆弱性はApache Log4j 2.15.0より前の2系のバージョンに影響があるとされています。
サーバサイドはじめ多くのJavaで書かれたプログラムに影響するのではないでしょうか。
【参考】
- 「やばすぎる」 Javaライブラリ「Log4j」にゼロデイ脆弱性、任意のリモートコードを実行可能 iCloudやSteam、Minecraftなど広範囲のJava製品に影響か
- Apache Log4jの任意のコード実行の脆弱性（CVE-2021-44228）に関する注意喚起
この脆弱性の厄介なところは、外部からクラスファイルを読み込めてしまうことによる影響と内部のロギングに利用していることで、影響範囲が膨大なところではないでしょうか。
例えばデバッグ目的でユーザからの入力をログに出したりするようなケース…ありえすぎる…
脆弱性のあるlog4jにとある文字列が渡されることで、JNDIという機能を通じて外部のladp/ldapsサーバ、dnsサーバ、rmiサーバと通信してしまう、更にladp(だけ？)サーバの応答を細工することでクラスファイルを読んで実行してしまうようです。
※ldapじゃなくてdnsにするとdnsクエリが飛びます。脆弱性が有効か試す上ではdnsが利用される可能性もありますね。
JNDI Lookupについて調べてみると「jndi:ldap」という感じの文字列が含まれるのでこれをWAFとかで弾いちゃえばいいじゃん、という気がしますが、そんなに単純でも無いようで、もうちょっと考えないとWAF やIPSが比較的簡単にバイパスされる恐れがあります。
以下参考ツイート。
${jndi:${lower:l}${lower:d}a${lower:p}://loc${upper:a}lhost:1389/rce}
log4j bypass lol
Lessons learned: Don't use Java.
— stypr (@brokenpacifist) December 10, 2021
実際に以下のサイトを参考においらも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」があるイメージのとあるネットワーク屋の感想ですが。。。
ではでは。またの機会に。