バグ レポート - 2022 年 1 月版

Kevin McGrath 著· 2022 年 2 月 2 日

サイバー セキュリティのコミック リリーフ

はじめに

オミクロンは、ギリシャ語のアルファベットの 15 番目の文字です。数学ではドナルド・クヌースがランダウの記号のことをオミクロンと呼びました。プトレマイオスの書「アルマゲスト」ではゼロを表し、アイソプシーでは 70 を意味していました。しかし、ほとんどの人にとっては、単なる「ひたすら、いつまでたっても、終わらない」パンデミックを意味するだけでしょう。 さて、2022 年 1 月に最も多く使われたこの単語に関する哲学的無駄話はこのくらいにしておきましょう。本記事は、脆弱性に関する情報をお伝えするのが目的です。本題に入りましょう。内容の濃い 1 月のバグ レポートをお届けしましょう。

• CVE-2022-0185: 入力の確認を怠るのは Java 開発者のみにあらず。
• CVE-2021-42392: まさかLog4shell が終わると本気で思ってましたか?
• CVE-2022-21907: 小さいワームも忘れてはいけません。
• CVE-2021-4034: PwnKit に sudo では不十分なら、どうなるのか?

CVE-2022-21907: HTTP.sys のワーム化可能なバグ

問題の概要

2022 年 1 月の火曜日のパッチ リリースでは、Microsoft の HTTP.sys カーネル ドライバーのワーム化する脆弱性で新年が始まりました。これは、7 か月の間に tHTTP.sys で見つかった 2 つ目のワーム化する脆弱性です。このドライバーのコードの成熟度を考えれば、これはかなり驚きの出来栄えです。幸い、CVE-2021-31166 と 21907 のせいでインターネットが崩壊することはありませんでした。21907 は 31166 の不完全な修正を用いて、HTTP トレーラーのサポート (チャンク化したメッセージ末尾のメタデータ) を利用します。エクスプロイトが、最後のチャンクの TRAILER ヘッダーの存在に依存するかという点は不明です。RFC では OPTIONAL としています。ネットワーク製品の署名作成のヘッダーで TRAILER をあてにできないのであれば、それは潜在的な問題です。

豆知識: PoCs は こちらの GitHub を参照してください。

豆知識をもう 1 つ: すでに悪用され始めています！ 脅威について最新の情報を知りたければ、McAfee Insights は必見です。

IIS だけが HTTP.sys を使用しているように見えるかもしれませんが、実はそうではありません。HTTP.sys は、コア HTTP を処理するコードを提供しているカーネル ドライバーです。他のサブシステムで次のコードを使用します:

• ADFS
• WinRM
• インテル® ドライバー & サポート・アシスタント

サービスが使用しているドライバーを確認する方法は、以下のとおりです:

PS > netsh http show servicestate

これにより、現在システムで実行されているリクエスト キューとそれに関連する URL が一覧表示されます。

幸いなことに、Server 2019 や Windows 10 1809 のアップデートを気にかけていなかった人は、レジストリでトレーラー サポートを有効にしない限り問題ないでしょう。

対象:

240 万人の Twitter ユーザー。自分の環境で IIS を利用する人。Docusign を使用している人 (特にこのパンデミック下において、Docusign を経由した法的拘束力のある契約書の数を考えると、これは重大な問題です)。最近の市場レポートによると、インターネット サイトのおよそ 7% が IIS を使用しています。Microsoft でさえインターネット接続するシステムはそれほど多くないので、MS 以外にも IIS を使っているサイトはたくさんあります。もちろん、Windows で脆弱性のあるデフォルトのバージョンを使っている人も対象です:

• Windows 10 2004 以降 (ARM と x64 の両方)
• Windows Server 20H2 以降

対処法

とにかくパッチです。Microsoft は、公表と同時に脆弱性に対するパッチをリリースしました。パッチが適用できない場合は、インターネットに接続できないようにすることが望ましいです。残念ながら、現在の Windows のバージョンでは、適用可能なホストベースの緩和策はありません。

Windows Server 1909 または Windows 10 1809 を実行している場合、デフォルトでは脆弱性はありません。脆弱性のステータス確認をする場合は、以下のとおり実行してください。

PS > Get-ItemProperty "HKLM:\System\CurrentControlSet\Services\HTTP\Parameters" | Select-Object EnableTrailerSupport

返された値が 0 でない場合、システムは脆弱です。これを緩和するには、次のとおり実行してください。

PS > Set-ItemProperty "HKLM:\System\CurrentControlSet\Services\HTTP\Parameters" -name EnableTrailerSupport -Value 0

もしくは、単純にレジストリ キーを削除してください。

模範的な対応

適用可能なパッチが用意されているのは良いニュースです。ぜひとも適用してください！もし仮に、パッチを適用できないなんらかの事情があるとしても悩まないでください。Trellix はこの脆弱性に対する NSP (Network Security Platform) のシグネチャを提供しています。ともかく、署名データベースを更新しているかということは、最低限確認しましょう！

CVE-2021-42392: Log4Shell を狙う H2

問題の概要

これは、JNDI リモート クラス ローディングの処理における Log4Shell に似た脆弱性です。Log4j に存在するバグを利用するわけではありませんが (Log4j は必要ですらありません)、同じ基礎技術である JNDI を利用します。攻撃者が制御する URL でデータベースにアクセスすると (入力はサニタイズしましたね… 大丈夫ですよね?)、H2 RDBMS のコンテキストでリモート コードを実行できますが、しかし、もちろんデータベースに対して、すべてのクエリをサニタイズし、パラメータ化して保存しているので、そのようなことは起こりません。もちろんです。

対象:

Log4J を含め、H2 を利用するプロジェクトが 7,000 近くあると言われています。本当に Log4jJ が問題だったのかなどと疑いを抱いている間にも、Log4Shell が名前を変えて、Log4j のユーザー以外にも到達してくるかもしれませんよ? どこにでも根をはびこらせるのです…

対処法

H2 データベースのバージョン 1.1.100 から 2.0.204 が影響を受けます。2022 年 1 月 5 日以降のバージョン 2.0.206 では、脆弱性を修正済みです。少なくともバージョン 2.0.206 へのアップデートが理想的です。

データベース エンジンを変更することもできますが、これはかなり極端な解決方法だと思われます。宿主を殺して病気を治すというやり方は、医学の世界と同様、IT の世界でも推奨されない行為です。

Java の利用をやめますか? 上記と似ているように思えますが、こちらは正解です。現実問題として、明らかにこれが最善策です。Java はサーバーの上にあるべきではなく、コーヒーカップの中にあるべきです。

模範的な対応

パッチを当てたり、Java のコードをすべて放棄して他の言語に変えたり、データベース エンジンを交換しなくても、Trellix がカバーしています。エクスプロイト自体は Log4Shell と同類のものに見えます。

Trellix はさまざまな角度からお客様を保護しています (詳細については、こちらのナレッジ ベースの記事をご覧ください)。

• ENS (Endpoint Security) のエキスパート ルールにより、メモリー内の危険なパターンをピックアップすることができます。こちらのブログで紹介しています。
• ENS (Endpoint Security)、VSE (VirusScan Enterprise)、MWG (McAfee Web Gateway) は、「望ましくない可能性があるソフトウェア」の検出により、Exploit-CVE-2021-44228.C というタイルで汎用検出を提供可能です。また、この脆弱性を悪用しているキャンペーンに関連したハッシュのサンプルのリストによって、検出を補強します。
• NSP (Network Security Platform) でも、ユーザー定義シグネチャ (既出のナレッジ ベースの記事のリンク先にて提供) により、この攻撃を検出可能です。
• MVISION Endpoint Detection and Response (EDR)、McAfee Active Response (MAR) も、リアルタイム検索 (RTS) クエリで脆弱なシステムの検知に使われています。
• McAfee SIEM にアップデート (Exploit Content Pack バージョン 4.1.0) が適用され、潜在的なエクスプロイトの試みに対しても警告するようになりました。

CVE-2022-0185: Linux カーネル名前空間のアンダーフロー......

問題の概要

表面的には、CVE-2022-0185 はレガシー コード パスの単純な整数アンダーフローです。コンテナーを使っている人にとっては幸運なことに、そのレガシー コード パスは FSC (ファイル システム コンテキスト) 内にあります。FSC はファイル コンテキスト API (FCAPI) に置き換えられましたが、後方互換性をサポートするために、脆弱なパスを含む一部の機能が保持されました。コンテナー プロセス自体のコンテキストでは、整数アンダーフローは攻撃者に無制限の書き込みを許してしまいます。コンテナーにアクセスできる攻撃者は、この脆弱性を悪用して、基になるホストを攻撃し、このノードで実行されている他のすべてのコンテナーにアクセスが可能になります。Kubernetes (k8s) のような一般に普及したツールについて考慮すると、信頼されていないユーザーの存在は、プロセス分離のためコンテナーを使用するユーザーにとって潜在的な不安材料になります。この問題は、非特権名前空間を使用するコンテナー、unshare コマンドを許可するコンテナー、または CAP_SYS_ADMIN 特権 (デフォルトではオフ) を持つコンテナーのみに影響します。Docker コンテナーでは、unshare コマンドは、デフォルトでは seccomp フィルターによってブロックされています。残念なことに、k8s ユーザーの seccomp フィルターは、デフォルトではオンになっていません。そのため、あらゆる Kubernetes クラスターが危険にさらされていることになります。

過去を振り返りすぎると、それは進歩を遅らせることになります。この世のあらゆる素晴らしいものからゆっくりと精気を奪います。つまり、たいていの場合、後方互換性のせいで素敵なものと巡り合えなくなってしまうのです。

対象:

コンテナーを動かしている人なら誰でも、潜在的に対象となりうるでしょう。そして、ユーザーにコンテナーの実行を許可している管理者も同様です。さらには、お持ち帰りのテイクアウトでコンテナーを使う人さえも対象になる可能性があります。少し過剰反応してしまいましたが、少なくとも、共有サーバー上でコンテナーを実行している人は、しっかりとこのことに留意する必要があります。基盤のカーネルがアップデートされたとわかるまでは、サーバーからミッションクリティカルなものが削除される可能性があります。

この脆弱性に関する詳細なブログ記事で PoC コードを公開しています。この時点では、悪意あるアクターがこの脆弱性を武器化するのは時間の問題です。私たちは皆、注意しなくてはなりません。

対処法

もしあなたがホストをコントロールしているならば、カーネルをアップデートする必要があります。それが不可能な場合 (所有者が拒否している場合など) は、次のように実行してください。

# sysctl -w kernel.unprivileged_userns_clone = 0

CAP_SYS_ADMIN 特権を持つコンテナーのみに、この脆弱性を制限します。また、コンテナーからこの特権を削除することで、この脆弱性を緩和できます (デフォルトではオフになっています)。

Redhat は、コンテナーを実行しないシステムに対して、単純に名前空間を完全に無効化することを推奨しています。

# echo "user.max_user_namespaces=0" > /etc/sysctl.d/userns.conf # sysctl -p /etc/sysctl.d/userns.conf

これで、そのホストはコンテナーを実行できない状態になります。コンテナーを使っていないのであれば、これはとりあえずは良いアイデアでしょう。

模範的な対応

この時点では、パッチを当てるか、緩和策を適用するのが最善の方法です。コンテナーは分離メカニズムとして使用されるため、外部プロセスが実行中のコンテナーを可視化することはまずありません。パッチを適用したホストで実行するか、k8s で seccomp フィルターを有効にしてください。

CVE-2021-4034: PwnKit

問題の概要

CVE-2021-4034、通称 PwnKit は、PolKit (かつては、PolicyKit として知られていました) のロジック バグを利用します。PolKit は、システム全体のポリシー管理キットで、特権のないプロセスが特権プロセスへ安全に (少なくとも安全だと信じられていた) アクセスできるようにします。特に、このバグは pkexec というツールに存在します (何らかの理由で、sudo では不十分であり、sudo と全く同じことをする、別の setuid プログラムの必要性を感じたため)。argc 変数が少なくとも 1 であると仮定しています。典型的なプログラム呼び出しでは、当然明白なことです。ほぼ間違いなく情報漏えいの兆候なので、ランタイムによって拒否されるべきなのですが、逃れる方法があるのです…

通常、pkexec の使用時には、認証情報を要求するポップアップ ウィンドウが表示されます。この脆弱性は、その認証チェックを回避し、単に root として実行されます。失敗に対処する方法は、ただ王国の鍵を渡して、自分を褒めることだからです。

これは、6 か月間で 2 つ目の polkit の脆弱性です。CVE-2021-3560 も、polkit の呼び出しに dbus メカニズムを使用して、認証情報チェックを回避します。どちらも同じ root の欠陥が利用されているようです。ついでにお話すると、根本原因が最初に報告されたのは 2013 年のことですが、の作者は悪用への直接的なパスを見い出せませんでした。そのため、この哀れなパッチは見放されたまま、輝く日を待っていたのです。9 年という長い歳月を経て、魅力的なパッチで輝きましょう！日の目を見せてあげませんか。

対象:

これは、昨年の最大級のローカル特権昇格バグと呼んでも異議はありませんね? この脆弱性は、古い polkit バイナリを実行しているほとんどの主要な Linux ディストリビューションで動作するので、1 月 25 日以降にパッチを適用していない Linux を実行している人すべてが、脆弱な状態にさらされています。Debian は独自のフォークを保守しているため、polkit のバージョン番号は少し複雑です。もし、

• 0.105-26ubuntu1.2 on Ubuntu 20.04 (LTS) 以前
• 0.105-31ubuntu0.1 on Ubuntu 21.10 以前
• 0.105-31+deb11u1 on Debian bullseye 以前、もしくは
• polkit-0.115-11.el8_4.2 on RedHat Enterprise Linux (RHEL) 8.4 EUS 以前

であるならば、脆弱な状態にあります。繰り返しになりますが、1 月 25 日以降にパッチを適用していない場合は脆弱性が存在します。また、PoC コードが公開されているので、これが積極的に悪用される日も近いでしょう。

すべてのユーザーを信頼しているのですか?In that case, you have nothing to worry about. Compromised accounts are readily available. ユーザーを信用しているにしても、フィッシングか、クラッキングか、何による侵害かにかかわらず、どこかの侵害されたアカウントと認証情報を共有しているユーザー アカウントまで信用して良いという話にはならないはずですが。

このバグは Linux で発見されましたが、BSD を含む他の UNIX ディストリビューションでも polkit が使用されています。少なくとも OpenBSD では、argc が 0 のプログラムの実行を拒否するなど、常にこのバグに対する緩和策を講じています。Solaris も polkit を使用していますが、Oracle は Solaris に関して秘密主義であり、セキュリティ情報さえも有料です。顧客を手放さないためには良い方法ですけどね！

対処法

アップデートです。パッチは主要な Linux ベンダーから提供されています。すぐに適用する必要があります。再起動は必要ありません。もしパッチを適用しないという選択をするのであれば、pkexec の setuid ビットを削除しましょう。

# chmod 0755 /usr/bin/pkexec

残念ながら、これで pkexec は本来設計された機能は失いますが、情報漏えいよりはマシだと思いませんか?

RedHat の Security Bulletins は、RHEL に特化した緩和策を掲載しています。

模範的な対応

すべての Linux ディストリビューションから調整してリリースしたものなので、本当にただ適用すれば良いだけです。変則的なログインの起点は記録され、フラグが立てられ、他にも認証がない場合はできる限りブロックされることを指摘しておきます。多要素認証を使用していますよね? MFA は外部から脅威がシステムにアクセスできないよう、悪用を阻止します。内部の脅威に関しては、読者への課題としておきます。