地球の半分の人々にとってついに春が訪れ、そして同じことが繰り返されます：花が咲き、鳥がさえずり、季節性アレルギーが本格化します。まさに一年で最高の時期です。しかし、普遍的な事があります。死、税金、バグレポート、そしてJavaがあなたの人生を台無しにします。Trellixは、そのうちの一つをお届けできることを誇りに思います。今月は、本当に際立った脆弱性を取り上げました。Shadow Councilは、どの脆弱性を選ぶべきかということに時間をかけず、明らかに選ぶべきものを深く掘り下げることに時間を費やしました。
「Spring4Shellは3月下旬に報告されているのに、なぜ4月のバグレポートで扱うのか」と思うかもしれませんが、簡単に言ってしまえば、時間とは社会的な構成要素であるということです。詳しく言えば、この脆弱性は3月末（03/29）に報告されましたが、その重要性が明らかになった時には、すでに3月のレポートで扱うにはタイミングが遅すぎたということです。今更だとしても、取り上げないよりはよいでしょう。
目次
CVE-2022-21449 またの名を “Psychic Signatures”: Java
暗号はサイバーセキュリティにおいて数少ない良いもののうちの一つだとよく言われますが、それには理由があります。しかし残念ながら、暗号は配信するだけという点では冗談のようなもので、どんなに優れた暗号アルゴリズムでも実装におけるミスまで防ぐことはできません。さらに残念なことには、「暗号は冗談のようなもの」というのは、事実、JavaのECDSA実装について完璧に言い表しているのです。ForgeRockのNeilMadden氏によると、Java 15のリリースに伴い、オリジナルのネイティブコード実装がJavaで書き換えられ、そのECDSA署名検証を簡単にバイパスできるようにする致命的なバグがあることがわかりました。Madden氏はまず2021年11月にこの脆弱性をOracleに開示しましたが、Oracleがその半年後に2022年4月のCPU（ritical Patch Update）でようやくこの問題に対処した後、それを公表しないことを選択しました。記事の中でMadden氏は、ドクター・フーで万能型IDカードとして使われるサイキックな力を持つ白紙のカードにちなんで、この脆弱性を「Psychic Signatures」と名付けています。まさにぴったりですね。
楕円曲線暗号の集中コースで訓練でもしない限り、CVE-2022-21449の仕組みを完全に理解することは無理でしょう。この控えめなレポートで扱える内容をはるかに超えていますので、簡単に説明すると、ECDSA署名は次の2つの値から成り立っています：rとsです。ECDSA signatureはある楕円曲線方程式の左右が本当に等しいかどうかを確認します。左がrであり、右が（ある意味）sと同等であるかということを確認します。この法廷式が計算上 true (0 = 0) if both r and s are zeroになる場合に、メッセージの内容や使用されるkeyに関係なく、シグネチャが常に“valid”になります。そのためには、ECDSA algorithmがif either r or s are zeroの場合にシグネチャを拒否します。 Javaの新しい実装では、このステップをスキップしているのです。00ps…
対象：
ECDSAは配管のようなものです。私たちはいつも配管を使いますが、ほとんどの人は何か問題が起こるまでそれについて考えることはありません。Java の ECDSA 配管によって動くさまざまなものには、一般的な Web 認証/承認標準であるJavaのECDSA配管を利用したさまざまなフィクスチャには、 JWT、SAML、WebAuthnなど多くが含まれ、サーバー上の機密リソースへのアクセス制限や、セキュリティ・ドメインをまたがるユーザーのSSO（Single Sign-On、シングルサインオン）の管理も担っています。さらに厄介なことには、一部のSSL証明書はJavaのECDSAを使用して生成した署名を利用し、この場合、攻撃者はこの脆弱性を利用して暗号化されたトラフィックをman-in-the-middle（仲介役）にすることができます。OracleのCVSS評価7.5という非常に保守的な評価に惑わされて、この脆弱性が大したことないなどと思ってはいけないということです。Oracleは、バージョンついて4月のCPUより前のJava 15、16、17、18がすべて脆弱であり、影響を受けると指摘しています。
悪名高いLog4Shellと比較するとCVE-2022-21449の範囲は確実に小さいですが、Log4ShellがサードパーティのJavaライブラリのバグであるのに対し、今回はJavaランタイム自体のバグであることは言うまでもありません。さらに、Psychic Signaturesは簡単に悪用できて、PoCコードはすでに存在しているので、現在のところ実際に悪用されているという証拠はないものの、悪用される可能性は決して低くないということです。つまり、もしLog4Shellが気になるのであれば、おそらくこれも気になるはずです。
対処法：
いつものことですが、Oracleの4月のCPUは完全にこの脆弱性を緩和しているため、早急にパッチを当てることが最善策です。すぐに対処できない場合は、すべてのJCA(Java Cryptography Architecture) プロバイダーをこのバグのないオープンソース実装であるBouncyCastleに変更することを検討してください。もし、組織・企業が影響を受けているかどうか気になる場合は、Log4Shellの後に作ったお使いの環境にあるJavaを参照するソフトウェアすべてのリストを再度見直してみることをお勧めします。他には、JFrogはGitHubで、任意のJAR/WARファイルをスキャンして脆弱性の存在を確認するツールを公開しているので、これが使えるかもしれません。
CVE-2022-26809: MSRPC
CVE-2022-26809 は、今月の他の 2 に比べるとそれほどキャッチーな名称ではありませんが、重要性と名前には何ら因果関係はありません。火曜日のMicrosoftのパッチの一部として4月12日に公開されました。この脆弱性は、MSRPC（Microsoft Remote Procedure Call）において、完全リモートで、認証前で、ゼロクリックの脆弱性です。Windows オペレーティングシステムのコアコンポーネントであり、デフォルトで有効になっており、ネットワークからアクセス可能で、OS を破壊しなない限りは無効にすることができません。驚くのはそれだけではありません。
この脆弱性は、北京に拠点を置くサイバーセキュリティ企業Cyber KunlunがMicrosoftに提出したものです。SMB（Server Message Block）プロトコルを攻撃ベクトルとして利用したエクスプロイトをMicrosoftにもたらしました。その結果、当初、MicrosoftのセキュリティアップデートガイドではSMBが利用するTCPポート139と445をブロックすることを推奨していました。これらのポートは MSRPC 固有のものではありませんが、MSRPC が SMB を転送に利用できるため、これらのポートを開放したままだと脆弱性を悪用される可能性があります。この理屈で考えれば、MSRPC over TCP と MSRPC over HTTP にも同じことが言えるかもしれません。
この脆弱性を悪用するために必要な具体的な詳細について、現在のところ信頼できる情報としては、 AkamaiとMalwareTechが行ったパッチの差分に基づくハイレベルな分析以外はほとんど見当たりません。この両者のソースによると、パッチにはRPC パケットの処理を担当する関数においてヒープオーバーフローの可能性から保護するための整数オーバーフローチェックがいくつか追加され、おそらくリモートコード実行が可能だと推測できます。
対象：
この脆弱性を利用するエクスプロイトは簡単にワーム化する可能性があり、マルウェアキャンペーンの第一の媒介となるため、環境内にWindowsフットプリントを持つ組織はこれを非常に真剣に受け止める必要があります。 Microsoftは、Windows 7 / Server 2008以降のほぼすべてのバージョンのWindowsが脆弱な状態にあることも明らかにしています。Windows Updateが大幅に遅れているからといって助かったとは思わないでください。特にヘルスケア業界は注意してください。
ありがたいことに、この記事の執筆時点ではCVE-2022-26809の正当なPoCコードはないようです。犯罪者がインターネットに公開されているポート445を備えた700,000台のWindowsマシンのすべてにペイロードを送信し始める前に、食い止めるだけの猶予があります。
70万台全部にパッチがあたっているはず…ですよね？
対処法：
壊れたレコードのように、確固たる良心を持って、今すぐシステムにパッチを適用するよう言い続けます。本当に、「今すぐに！」です。RPCを完全に無効にすることは不可能なので、パッチをあてることがWindowsマシンを安全に保つために、唯一、確実な手段なのです。しかし、リスクを軽減する代替手段を提供することもまた重要であると考えます。今すぐパッチを適用できない場合は、ペリメータ（境界）ファイアウォールでTCPポート135（TCP経由のMSRPC）、139、445（SMB経由のMSRPC）、593（HTTP経由のMSRPC）をブロックすることから始めてください。しかし、最終的に優れたファイアウォール規則は、必要なサービスのためにポートをホワイトリスト化することです。勝ち目のないゲームで、モグラたたきのように反射的に危険なものをにブラックリスト化することではありません。
CVE-2022-22965 またの名を “Spring4Shell”: Spring Framework
Spring4Shellが何であるかを適切に説明するためには、まず何がそうでないかを説明することが重要です。これは、同時期に公開された表面的に似た脆弱性であるCVE -2022-22963ではなく、Spring Cloud Functionでサーバーサイドコードインジェクションを可能にする脆弱性です。3月下旬、この2つの脆弱性が公開されてから72時間に、Twitter上ではこの2つの脆弱性を混同して「Spring4Shell」と呼ぶ人が多く、誤った情報が拡散されました。しかし、Spring4ShellはCVE-2022-22965のみを指すのが正統派です。両方ともCVSSスコア9.8ですが、Spring4Shellの方がはるかに悪影響を及ぼします。そのため、今回ご紹介するリストに入れて、似て非なる酷い方を除外しました。
この脆弱性のターゲットであるSpring Frameworkについて簡単に説明すると、VMwareによって開発された非常に人気のあるオープンソースフレームワークです。dependency injection、 data binding、model-view-controllerのSpring MVCとリアクティブデザインのSpring WebFluxの両方のWebフレームワークなどの機能をサポートするエンタープライズレベルのJavaアプリケーション開発を支援します。Spring Frameworkが開発者に提供する機能の1つに、HTTPリクエストを特定のハンドラメソッドにマッピングする機能があります。この機能はパラメータバインディングと呼ばれ、同じHTTPリクエストで提供されたパラメータに基づいてオブジェクトをインスタンス化し、そのメンバーに自動的にデータを入力することができます。
さらに古いバグであるCVE-2010-1622は、この機能をJavaの組み込みgetClassLoader()メソッドと組み合わせて悪用し、TomcatのClassLoaderオブジェクトを操作して攻撃者側のコントローラサーバからJARファイルをロードさせてRCEを達成するものでした。Springは、getClassLoader()をパラメータバインディングの仕組みから除外するチェックを追加することで、この攻撃ベクトルに迅速にパッチを適用しました。しかし、Java 9のモジュールの導入によってClassLoaderにアクセスする別の手段が追加され、Springの以前のパッチがバイパスされてCVE-2022-22965が生まれました。Spring4Shellの悪用は、その先祖と違いTomcatのAccessLogValveクラスを介してWebルートにカスタム.jspファイルを書き込むことにより、Tomcatを実行しているターゲットサーバー上にwebshell（名前の由来）を作成することがほとんどですが、リクエストパラメータ結合を悪用するという点で根本的にほぼ同じ脆弱性です。
対象：
この影響に関しては、良いニュースと悪いニュースがあります。まず良いニュースは、Spring Frameworkを利用するすべてのJavaアプリがデフォルトで脆弱であるわけではないということです。次のすべての基準に当てはまる場合、アプリが脆弱であるといえます。
- JDK>=9.0を使用
- Webアプリケーションアーカイブ（WAR）としてパッケージ化
- スタンドアロンサーブレットコンテナにデプロイ
- Servletはspring-webmvcまたはspring-webfluxパッケージをとして依存関係（dependency、ディペンデンシー）がある
- Spring Framework 5.2.20/5.3.18（パッチ公開時）より古いバージョンを使用
悪いニュースは、このレースにおいてこの犯罪者がかなり先陣を切っていることです。これは、Springのパッチと同時に予定されていたCVEの公開に先立って、脆弱性の詳細とPoCエクスプロイトがリークされたことに一部起因しています。実際、ハニーポットでは、公開からわずか2日後の3月31日にSpring4Shellの悪用が検知され、それ以降も悪用の試みが続けられています。最初に公開されたPoCコードは、Tomcatサーブレットコンテナを使用するSpringアプリケーション固有のものでしたが PayaraサーブレットとGlassfishサーブレットの両方に脆弱性があることがSpringによって確認されたそうです。
実は、さらに悪いニュースがあります。Trendmicroの報告によると、Spring4Shellはすでに、Miraiボットネットマルウェアを復活させた大規模なキャンペーンに利用されているとのことです。既視感があります。
対処法：
Spring Frameworkを5.2.20/5.3.18以上にアップデートすることが最善の解決策であることは明らかですが、Springはセキュリティガイダンスで緩和策を掲載しています。
- Tomcatを少なくとも8.5.78/9.0.62/10.0.20にアップグレードしてください。これは脆弱性全体を緩和するものではありませんが、この脆弱性の悪用で最も一般的な方法であるTomcatの攻撃ベクトルを緩和します。
- Javaを9未満のバージョンにダウングレードすると、CVE-2022-22965を可能にするモジュールバイパスが削除されます。ただし、古いバージョンのJavaを利用すると、独自のセキュリティリスクが発生する可能性があります。
- setAllowedFields()によって、ユーザにバインドさせたいパラメータのみをホワイトリスト化することが有効な緩和策です。setDisallowedFields()によって、エクスプロイトが使用するフィールドをブラックリスト化することも可能です。残念ながら、このフィールドをグローバルに設定するとローカルでオーバーライドされてしまう危険性があります。さらに厄介なことに、プロパティは直感的に理解できないほど大文字と小文字を区別すると判明しました（case-sensitive）。この「癖」は明文化されていないため、多くの緩和策に穴があります。この問題はCVE-2022-22968として追跡され、Spring Frameworkのバージョン5.2.21と5.3.19で修正されていますが、しかし、「意図したとおり機能する」とは明言されていません。
※本ページの内容は2022年５月４日（US時間）更新の以下のTrellix Storiesの内容です。
原文： The Bug Report – April 2022 Edition
著者： Mark Bereza