CUPS の重大な Linux RCE — 判明している内容と予備対応の方法
エグゼクティブサマリー
多くの Unix 系ホストに影響を与えると考えられる一連の重大なリモートコード実行(RCE)脆弱性が、2024 年 9 月 26 日に 公開 されました。
脆弱性が確認されたコンポーネントは、Common Unix Printing System(CUPS)、特に cups-browsedです。
攻撃を成功させるためには、次の 4 つの脆弱性の連鎖が必要です。CVE-2024-47176、CVE-2024-47076、CVE-2024-47175、CVE-2024-47177。
このブログ投稿では、脆弱性の詳細を共有し、技術的な情報開示を分析した上で、パッチを待つ間にリスクに備え、リスクを緩和するために行うべき推奨事項を提供しています。
はじめに
2024 年 9 月 23 日、セキュリティ研究者の Simone Margaritelli 氏 が、脆弱性開示に関してソーシャルメディアで詳細を共有しました。Margaritelli 氏は 投稿の中で、3 週間前に開発者に公開した重大な脆弱性について説明しています。それは、すべての GNU/Linux マシンに影響を及ぼす可能性がある未認証 RCE の脆弱性です。
2024 年 9 月 26 日に、 技術開示 の全体が公開されました。合計 4 つの脆弱性があります。
CVE-2024-47176 : cups-browsedに存在し、攻撃者が制御するアドレスへのリクエストを強制する
CVE-2024-47076 : libcupsfiltersに存在し、攻撃者のサーバーから返されたデータの検証やサニタイズをせず、CUPS システムの他の部分に渡す
CVE-2024-47175 : libppdに存在し、同じく入力をサニタイズせず、一時ファイルに書き込む
CVE-2024-47177 : cups-filtersに存在し、任意のコマンドの実行が可能
このブログ投稿の目標は、改善プロセスをできるだけスムーズに行えるよう、各組織で予備対応を取れるようにすることです。そのために、脆弱性攻撃チェーンの技術的な概要と、パッチを待つ間にネットワーク管理者が使用できるリスク緩和手順を(セグメンテーションの推奨事項として)提供します。
どのような予備対応をとれるか
攻撃者が RCE の脆弱性を悪用するためには、脆弱なソフトウェアと(当然ながら)リモートアクセスという 2 つの要素が必要です。脆弱なコンポーネントは CUPS であることがわかっているので、パッチを(利用可能になったときに)適用するか、このコンポーネントに特有の緩和策を適用するだけですが、ここで取るべき行動は、より広範にリモートアクセスに関して対策を取ることだと考えています。
まずは、緊急性の高い内容から始めましょう。
CUPS の外部公開と攻撃の可能性
ここで議論する脆弱性のあるコンポーネントは、 CUPSで、これはコンピューターをプリントサーバーとして動作させるサービスです。とても広く使用されており、さまざまな Unix 系のマシン上で見られます。
このサービスは非常に一般的であり、元々他のマシン(さらにはインターネット)に向けて外部公開される傾向があるため、悪用する価値が高い攻撃対象となり得ます。印刷サービスにおけるこれまでの脆弱性、たとえば CVE-2021-34527(PrintNightmare) や CVE-2010-2729でも、この攻撃ベクトルの潜在的な影響の大きさが示されています。
この「正式な」開示の前から、当社は CUPS が脆弱なコンポーネントであると想定していました。Margaritelli 氏の GitHub アカウントを確認していて、興味深い小さなことに気づきました。2024 年 9 月 17 日付けの Apple CUPS リポジトリのフォークで、これは最初の投稿の数日前です(図 1)。
また、この 問題 は cups-browsed の GitHub でも投稿されていて、主な脆弱性による後の影響について Margaritelli 氏(@evilsocket)が引用されています。(ここにはいくつか上質な解説もありますので、ポップコーンを用意してお読みください)
攻撃の分析
この攻撃は特に複雑ではありませんが、悪用を成功させるためには複数の手順が必要です。図 2 はこのプロセスの概要を示していますが、さらに詳細な解説が書かれている 開示ブログ の全文をお読みになることをお勧めします。
ステップ 1:まず、cups-browsed デーモンは受信 UDP 接続をポート 631 でリッスンしています。これは検出されたプリンターをシステムに追加するのが目的です。攻撃者がこのデーモンと通信すると、攻撃対象のマシンに、悪性のアドレスを正規のプリンターとして強制的に登録することができます。これが CVE-2024-47176 です。
ステップ 2:次の部分は、悪性の「プリンター」の登録時に発生します。登録手順の一環で、 libcupsfilters は攻撃者にアウトバウンド要求を送信し、Internet Printing Protocol(IPP)によってプリンター属性を要求します。プリンターは、その属性の一部として、 PostScript Printer Description (PDD)ファイルを定義できます。正規な使用ではプリンターの機能を定義するものです。これが、サニタイズや制約を受けることなく .ppd ファイルに書き込まれます。これが、CVE-2024-47076 と CVE-2024-47175 です。
これで、悪意のある .ppd ファイルが作成されました。では、その中からどのようにコマンドを実行するのでしょうか。
ステップ 3:PPD に cupsFilter2 ディレクティブを入力します。これは、新しい印刷ジョブが作成されるたびに、さまざまなフィルター(実行可能ファイル)を実行します。フィルターディレクティブを使用して、任意のコマンドインジェクションに対して脆弱性がある foomatic-rip フィルターを実行します。これが CVE-2024-47177 です。
状況の確認
Shodan を使用して、 世界中のおよそ 75,000 台のマシンで、ほとんどの場合デフォルトの 631 ポートを使用して CUPS がインターネットに公開されていることを確認できました(図 3)。
次のフィルターを使用すると、公開されている CUPS サーバーを Shodan で照会できます。
product:"CUPS (IPP)"
その他の知見
Akamai 独自のトラフィックデータに関する分析情報から、さまざまなプラットフォームで CUPS サービスが実行されているのを確認できました。Ubuntu、macOS、CentOS、Debian、Fedora、OpenShift、Oracle Linux Server、Red Hat、Rocky Linux、SUSE、openSUSE、AlmaLinux、Amazon Linux などがあります。
Akamai エコシステムの Linux マシンのうち、合計 10.1% がポート 631(CUPS ポート)をオープンしています。ただし、該当のマシンのうち、このポートで外部トラフィックを定期的に受信するのは 3% だけです。
これらの数字から、CUPS サービスが外部に公開されることは一般的ではないことが示されていますが、それでも、自組織での外部公開状況を評価し、それに応じてセキュリティポリシーを確認することは重要です。
インターネットへの外部公開の解析
攻撃者が組織に侵入する最も一般的な方法の 1 つは、インターネットに公開されたサービスを利用することです。CUPS はこのようなサービスの一例に過ぎず、問題がここで終わらないのは明らかです。Akamai のトラフィックデータに関する知見を利用して、多数の組織のさまざまなサービスの公開状況を評価しました。
Akamai のデータによると、Linux マシンの約 5.4% がインターネットに公開されていて、外部ソースから届くトラフィックを受信しています(図 4)。
このトラフィックに影響するネットワークポリシーの検査によって、 これらのマシンの 19.3% が、デフォルトでは着信インターネットトラフィックを許可していることがわかりました。 これは、着信トラフィックのフローを制限または制御する特定のネットワークポリシーが存在しないことを意味します。
公開されているサービスは攻撃ベクトルになりやすいため、組織ではアクセス制御を確認して強化することが重要です。
推奨事項
脆弱性はまだ公開されておらず、パッチ発行のスケジュールも未定のため、その公開までの予備対応として最適なのは、ネットワーク内のすべての「フリクション」ポイント(Linux マシンのリスト、インターネットへの公開、果ては CUPS の使用など)と、それらに関するセグメンテーションポリシーをマッピングすることです。
すべてをマッピングしたら、セグメンテーションポリシーを適用して、攻撃が発生した場合の影響範囲を制限することをお勧めします。これは現在の状況に関係なく有効な対応です。なぜなら、 Linux のラテラルムーブメント は SSH や RCE に限るものではないためです。
自組織での CUPS の使用の確認
マシン上で CUPS が実行されているか確認するためには、サービス名とプロセス名を検索します。さまざまな Unix システムやディストリビューションにわたる観察から、以下の名前のプロセスが CUPS の使用を示している可能性があります。
cups-browsed (影響を受けるプロセス)
cupsd
cancel.cups
lpq.cups
cupsfilter
lpc.cups
lp.cups
cupsaccept
cups-lpd
lpstat.cups
lpr.cups
cupsctl
osquery を展開している組織であれば、次のクエリーを使用して、システムで CUPS を使用している可能性があるかどうかを識別できます(Akamai Guardicore Segmentation のお客様は Insight 機能を使用してこのクエリーを実行できます)。
ポート 631 をリッスンしているマシンを検知:
SELECT pid, port, protocol, family, address, path
FROM listening_ports
WHERE port = 631
CUPS 関連の可能性がある実行中のプロセスを検知:
SELECT name, parent, cwd, cmdline, pid, start_time, path
FROM processes
WHERE path LIKE '%cups%'
インターネットへの公開の確認
Shodan などの公開スキャンサービスを使用して、CUPS などのインターネットに公開されているサービスを識別できます。
Akamai Guardicore Segmentation のお客様は、[Reveal]タブの[Internet Connection]フィルターを使用して、インターネットからトラフィックを受信するすべてのサービスとマシンを視覚化できます(図 5)。
セグメンテーションによる影響範囲の制限
次のようなシナリオを考えてみます。脆弱性が公開されていますが、想定も予備対応もしていません。誰かが悪用手順を作り、攻撃者がそれを使用してネットワークに侵入するとします。
それからどう動くでしょう。ドメインコントローラーに接続し、ネットワーク全体を感染させ、ボットネット/クリプトマイナー/ランサムウェア/トロイの木馬をドロップして、検知されずに脱出するかもしれません。また、複雑な偵察スキャンを実行し、複数のラテラルムーブメントを繰り返すなど、より積極的に活動する必要があるかもしれません。この場合は、侵害を検知してそれに対応する機会が十分に得られます。
侵害は発生し続けるため、セグメンテーションが非常に重要になります。この現在の RCE が問題でなくても、また別の ゼロデイ 脆弱性が生じます。フラットなネットワークは簡単なターゲットですが、攻撃者がやりにくい状況にすれば、攻撃者があきらめる(攻めやすい場所に移動する)かもしれません。十分に時間をかけさせ、失敗やミスを誘ったり、検知するためのアクションを実行させることもできます。
セキュリティ体制を改善する 2 つの手順
セキュリティ体制を大幅に向上させるための比較的簡単な手順が 2 つあります。DMZ の実装とアプリケーションサーバーのセグメント化です。
DMZ の実装。インターネットに接続されたサーバーは本質的に高いリスクを伴います。したがって、ネットワークの他の部分への完全なアクセスを許すべきではありません。そうしたサーバーがネットワークのより機密性の高い部分にアクセスできないようにするために、サーバーに境界/DMZ を実装すると、攻撃者ははるかに動きにくくなります。
アプリケーションサーバーのセグメント化。通常、類似のアプリケーションサーバーをまとめてセグメンテーションできます。また、アプリケーションロジックに基づいて、インバウンドトラフィックとアウトバウンドトラフィックを制限するのも容易です。
たとえば CUPS サーバーの例では、ポート(UDP 631)とプロセス(cupsd)がわかっており、技術的に必要なのは実際のプリンターへのトラフィックを生成することだけです。従って、CUPS サーバーのアプリケーションセグメントを作成して、特定の入力トラフィックを許可し、ほとんどのトラフィックを排除することができます。
そうすれば、攻撃者が CUPS を悪用してサーバーに侵入したとしても、プリンターに乗り移ることぐらいしかできず、印刷ジョブは、それほど恐れるべきものではありません。
さらに詳しく
セグメンテーションを適用してセキュリティ体制を強化できる、他のクイックウィンソリューションもあります。これについては、 実用的なセグメンテーションに関するブログ記事をお読みください。