バグレポート| 2022年6月

緊迫したサイバーセキュリティ対応の合間に
Your Cybersecurity Comic Relief

June 2022 Cybersecurity Comic Relief

なぜ、最も重要な脆弱性は、いつも祝日に判明するのでしょうか。皆がテクノロジーから離れて気分転換しようとしていた米国のメモリアルデーの週末を見計らったかのように、CVE-2022-26134が公開されました。こういうバグがあると、早く仕事に戻ることになります。休暇が台無しになったという愚痴はこれくらいにして、今月の最悪でクールなバグを紹介します。勝者は次のとおりです：

 


CVE-2022-26134

${ return this.JavaVuln++; }

CVE-2022-26134は、その核心において、認証されていないコマンドを直接Javaインタープリタにインジェクションするものです。より具体的には、この脆弱性は、JavaのObject-Graph Navigation Language (OGNL) Expression Languageを経由しています。ほとんどのバグは、長い説明と技術的なウォークスルーを必要としますが、この脆弱性は、まず悪用ペイロードを見れば簡単に理解できます。

Figure 1: Demonstration of CVE-2022-26134 using cURL (encoded)
Figure 1: Demonstration of CVE-2022-26134 using cURL (encoded)

ASCII 16進数をすらすら読めない人のために：

Figure 2: Demonstration of CVE-2022-26134 using cURL (decoded to ASCII)
Figure 2: Demonstration of CVE-2022-26134 using cURL (decoded to ASCII)

どうですか？このexploitのリクエストは、OGNLが何であるかを知るより先に簡単に理解できます。

このバグがどのように動作し、なぜこんなに簡単なのか。まるでわたしみたいなナード達を技術的に満足させなければならないわけですが、要するにユーザーが提供したURIは、最終的にOGNL式評価器に到達してURI内の変数を解決しようとします。その結果、Javaコードを実行するために利用できるのです。

この脆弱性は認証されず、Confluence サーバの権限で実行されることを指摘することが重要…つまり間違いなくルートではないですよね？

対象

この脆弱性は悪用するのが非常に簡単なため、すでに膨大な数のPOCがウェブ上で公開されています。このレポートの中にもあります。この脆弱性はこれまでも、そしてこれからも活発に悪用されるでしょうし、Confluence はいまだに手動アップデートという難解な方法を使っているのだから、これはまずいですよね。そのため、多くの未パッチのシステムがまだ野放しになっていて、この先、将来的に CVE-2022-26134 を標的としたエクスプロイトの試みが行われるものと予想します。

Shodan で検索したところ Confluence サーバーが13k以上公開されていて、Confluence ユーザーの多くは企業なので、この脆弱性による影響は計り知れません。

Figure 3: Shodan.io search results for Confluence servers
Figure 3: Shodan.io search results for Confluence servers

対処法

パッチを当てることが最善の防御です。詳細はこちら でご覧ください。Confluence サーバーのフルアップデートが不可能な場合、脆弱性のある “.jar” ファイルをここからダウンロードし、Confluence のインストールディレクトリに上書きすることで、手動でパッチを適用することができます。しかし、インストールファイルを上書きする場合は、バックアップをとってください。Confluence サーバーがどこにあるかわからない場合は、”${” という文字を含む URI にフラグを立てたりブロックしたりすることも有効です。Trellixの顧客の場合には、すでにNetwork Security platformに複数のネットワーク署名が組み込まれているため、保護されています。


CVE-2022-30190

Microsoft Officeのトラブルシューターがトラブってる

CVE-2022-30190（通称：Follina）は、VirusTotalへのアップロードで初めて発見されました。このVirusTotalへのアップロードと、次のTwitterの投稿により、この真のゼロデイが世界中に知られることになりました。

Figure 4: MSDT troubleshooter argument command injection
Figure 4: MSDT troubleshooter argument command injection

Microsoft Word のリモートテンプレート機能を使用すると、悪意を持って細工されたドキュメントを使用して、Windows カスタムプロトコルハンドラ経由でリモート URL の “ms-mdt:/” 部分を解決することができます。解決された後、URLは直接Microsoft Support Diagnostic Tool (msdt.exe)に渡されます。この脆弱性は、PowerShellによって解析されるMSDTツールの “IT-BrowseForFile “引数に存在します。つまり、通常PowerShellでできることはすべて、このバグを経由して “IT-BrowseForFile “パラメーターを通して行われる可能性があるということです。

対象

要するに、この脆弱性はOffice 365のすべてのバージョンに影響し、2013から2021までのスタンドアロンOfficeスイートでマクロを無効にしていても動作することが確認されています。Office の「保護されたビュー」では、ドキュメントがリッチテキスト形式（RTF）ドキュメントに変換されていない限り、この脆弱性Follinaを防ぐことができると判断されているのです。ということで、やはりパッチが完全に適用されるまでは、未知のファイルには要注意です。

これこそ、まさしく、真のゼロデイであり、多くのランサムウェアギャングがこの脆弱性を利用して戦いに勝とうと活発に悪用していることが観察されていますので、改めてここでも注意喚起しておきます。Trellixはこのバグを積極的に監視しています。より詳細な情報は、 こちらでご覧いただけます。

対処法

この攻撃から環境を保護するためには、Microsoft がこちらでリリースしている公式パッチを適用することが最善策です。パッチを適用できない場合でも、Trellix製品に組み込まれた保護機能がサポートします。詳細については、こちらの knowledge base articleをご覧ください。最後に、回避策をご紹介します。この回避策によって、Follinaバグから保護できます。

  1. Run Command Prompt as Administrator.
  2. To back up the registry key, execute the command “reg export HKEY_CLASSES_ROOT\ms-msdt filename“
  3. Execute the command “reg delete HKEY_CLASSES_ROOT\ms-msdt /f”.

上記の回避策で”ms-msdt:/”URLのレゾリューションを防ぎます。


CVE-2022-22980

Spring4shell 復活か?

CVE-2022-22980は、 今年初めに公開されたSpring4Shellの脆弱性に酷似した、Springフレームワークの最新の脆弱性です。この脆弱性は、Spring4Shellと同様に、Spring Expression Language (SpEL) のインジェクションを利用して、リモートホスト上でコードを実行するものです。この脆弱性で悪用されるSpEL関数は、“@Query” と “@Aggregation-annotated” のクエリメソッドです。これらのメソッドは、ユーザから提供されたデータが、クエリパラメータのプレースホルダを介して結合される前にサニタイズされない場合にのみ、脆弱性が生じます。SpEL界隈の人にとって（筆者もそうですが）、クエリパラメータプレースホルダは、 “o.owner.id = ?#{ some-expression }” という表現で、スタティックパラメータとしてアクセスするのではなく、 “o.owener.id = [1]”という形で表します。パラメータのプレースホルダの表現については、こちら で詳しく解説しています。さて、どのように悪用されるのか気になりますか？もし、プレースホルダーがサニタイズされずに直接ユーザー入力を消費する場合、以下のPOCからわかるように、Javaコードを直接渡すことでこのバグが悪用される可能性があります。

Figure 5: Proof of concept exploit opening calculator for CVE-2022-22980
Figure 5: Proof of concept exploit opening calculator for CVE-2022-22980

対象

もしすでに今年の初めにSpring4Shellの脆弱性の影響を受けたのなら、おそらくこのCVEも目を光らせておくべきでしょう。パッチを当てるべきJavaマシンをすべて見つけることが、毎月の儀式になりつつあります。

具体的には、Spring Data MongoDB V3.4.0またはV3.3.0-V3.4を使っているアプリケーションは、脆弱である可能性が高いといえます。

対処法

もはや恒例のお約束といった感じですが、とにかく、まずはSpring Data MongoDBの最新版3.4.1+または3.3.5+にパッチを当てることです。もしパッチが適用できない環境なら、静的パラメータ参照に“?1” ではなく“[1]”を用いて、クエリメソッドの前にユーザーが入力した内容をサニタイズすることで、安全を確保することができるでしょう。

最後の緩和策は、こちらです: “Reconfigure the repository factory bean through a BeanPostProcessor with a limited QueryMethodEvaluationContextProvider“（限定的な QueryMethodEvaluationContextProvider を持つ BeanPostProcessor を介して、リポジトリfactory bean を再構成する）

最後の緩和策はVMWares security disclosure page から直接引っ張ってきたものです。“factory bean”とは、一体なんのことなのかよくわかりませんが、誰かにとっては間違いなく、何かしらの意味があるのでしょう。なにやら、おいしそうな感じではあります。

※本ページの内容は2022年7月6日（US時間）更新の以下のTrellix Storiesの内容です。
原文： The Bug Report – June 2022 Edition
著者： Sam Quinn