金曜日から一気に話題が広がった感のあるLog4j2の件です。細かい話はCVE – CVE-2021-44228を参照。Microsoftからもアナウンスがでてました。

• Microsoft’s Response to CVE-2021-44228 Apache Log4j 2 – Microsoft Security Response Center (日本語訳）
• Guidance for preventing, detecting, and hunting for CVE-2021-44228 Log4j 2 exploitation – Microsoft Security Blog
• Log4j – Apache Log4j Security Vulnerabilities

まだ調査中という感じではありますが。基本的にはFixしたバージョンに更新することですが、更新が難しい場合は緩和策としてLOG4J_FORMAT_MSG_NO_LOOKUPS環境変数を設定するとかしましょう。

上記のアナウンスにもありますが当面はAzure ADで不審なアクセスを拒否するようにしたり追跡したりできるようにするとか、あとはAzure Application GatewayやAzure Front Door、Azure WAFは脆弱ではないという判断なので、そちらを活用してアプリを保護するとかも。（後ろのユーザーアプリケーションはその限りではないので）（参考：Azure WAFでlog4jの脆弱性（CVE-2021-44228）対策をしてみる。 | 技術的な何か。 (level69.net)）（あくまで緩和策。基本はちゃんとアップデートしたりしましょう）

※そのうち公式でルールセットがでそう。 → 追記を参照。

Azure App ServiceのTomcatやJava SE、JBoss EAP、FunctionsのランタイムなどマネージドなランタイムではLog4j2は配布されません。が、ユーザーアプリが使っている場合は影響を受ける可能性があります。基本的にはFixしたバージョンへアップデートするのが良いですがダメな場合は起動オプションを指定できるのでそちらで無効化するようにできます。
※アプリケーション設定で JAVA_OPTS を追加して -Dlog4j2.formatMsgNoLookups=true などを追加する感じ。

App Service for Containersの場合はDockerfileなどで構成する感じですかね。

Azure Functionsの場合、DedicatedとPremiumはApp Serviceと同様に、Consumptionの場合はWindowsとJavaでアプリケーション設定の名称がちょっと異なる（Linuxは languageWorkers__java__arguments 、Windowsは languageWorkers:java:arguments ※WindowsでもLinuxと同じでいける気がしますけど）けどこちらにJAVA_OPTSと同じように設定すればいいようです。

※なんにせよLog4j2 2.9以前はこのオプション使えないみたいなので、その場合は素早く2.17.0にアップデートして再デプロイしましょう。（2.9以前の場合、JndiLookupクラスをclasspath: zip -q -d log4j-core-*.jarから除外すれば最低限緩和できるぽいですが、、）

デスクトップアプリなどへの影響もあるので、しばらくはネットワークやアウトバウンドの監視、Azure ADやMDMだったり活用してしのいでいきましょう。

※ElasticsearchとかはLog4j2使ってるけどJava Security Managerで制御してるからリモートコードは実行できないよという話もありますが、、

2021.12.15追記

Microsoft 365 Defenderでこの脆弱性に対する攻撃を検出するクエリとかの話がでていました。

• Guidance for preventing, detecting, and hunting for CVE-2021-44228 Log4j 2 exploitation – Microsoft Security Blog

Microsoft 365 Defender for Cloudやfor IoT、Azure Sentinelなどでも使えるクエリや手法も書かれてるので参考に。Azure Firewall Premiumを使った検知/保護についても書かれています。Azure WAFについては944240のルールセットが更新されてこの脆弱性に対する保護機能が強化されたようです。