膨大な数の CUPS：DDoS の脅威
編集・協力：Tricia Howard
エグゼクティブサマリー
Akamai の研究者は、分散型サービス妨害攻撃（DDoS）の実行に悪用される可能性のある CUPS を使用した新たな攻撃ベクトルを確認しています。(CVE-2024-47850)
調査によると、攻撃を行うシステムは、公開されている脆弱な CUPS サービスに、インターネット接続を使用して 1 つのパケットを送信するだけで攻撃を開始できます。
Akamai Security Intelligence and Response Team（SIRT）は、19 万 8,000 台以上のデバイスが、公衆インターネットでアクセスでき、こうした攻撃ベクトルに対して脆弱な状態になっており、そうしたデバイスのおよそ 34%（5 万 8,000 台以上）が DDoS 攻撃に使用される可能性があることを発見しました。
5 万 8,000 台以上の脆弱なデバイスのうち、数百台のデバイスはリクエストの「無限ループ」の状態になっていました。
限られたリソースで攻撃を成功させることができることが、危険性をさらに高めています。 攻撃者はインターネット上で現在公開されているあらゆる脆弱な CUPS サービスをわずか数秒で悪用しており、最新のハイパースケーラープラットフォームを使用することでコストを 1 セント未満に抑えることができます。
CVE
2024 年 9 月 26 日、セキュリティ研究者の evilsocket は 、 Common Unix Printing System（CUPS）内のリモートコード実行（RCE）の脆弱性について明らかにしました。要するに、攻撃者は インターネット・プリンティング・プロトコル（IPP）の URL をリモートで操作して、 悪性のコマンドを実行できます。4 つの異なる脆弱性を連結することで、こうしたことを実現できます。
CVE-2024-47176 ： cups-browsedに存在し、攻撃者が制御するアドレスへのリクエストを強制する
CVE-2024-47076 ： libcupsfiltersに存在し、攻撃者のサーバーから返されたデータの検証やサニタイズをせず、CUPS システムの他の部分に渡す
CVE-2024-47175 ： libppdに存在し、同じく入力をサニタイズせず、一時ファイルに書き込む
CVE-2024-47177 ： cups-filtersに存在し、任意のコマンドの実行が可能
CUPS のストーリーをもっと読む
脆弱性に関する技術的な記述を確認したところ、別の攻撃ベクトルについては説明されていないことがわかりました： DDoS。DDoS は、主な業界や政府機関から小規模コンテンツ制作者、オンラインショップ、ゲーマーに至るまで、インターネット全体で被害者に嫌がらせをし、混乱させるために使用される、現実的な攻撃ベクトルであり続けています。当初の分析では、より深刻な結果をもたらす可能性のある RCE に焦点を当てていましたが、DDoS 増幅もこうしたケースで悪用されやすい状態にあります。
攻撃者が、追加すべきプリンターとしてターゲットのアドレスを指定するように細工されたパケットを送信すると、問題が発生します。パケットが送信される度に、脆弱な CUPS サーバーは、指定されたターゲットに向けて、部分的に攻撃者が制御する大規模な IPP／HTTP リクエストを生成します。 その結果、ターゲットが影響を受けるだけでなく、CUPS サーバーのホストも被害に遭います。攻撃はネットワーク帯域幅と CPU リソースを消費するためです。
悪用
シンプルなスクリプトを使用して、悪性の UDP パケットを CUPS の脆弱なインスタンスに送信できます。細工されたペイロードにより、CUPS は IPP／HTTP リクエストを攻撃者が指定したターゲットとポートに送信します。 この脆弱性は、 cups-browsed が IPP 属性ファイルをダウンロードするために指定された URI を取得しようとすると現れます。
この PPD ファイル URI はある程度任意であり、攻撃者によって変更される可能性があります。テストでは、この URI ペイロードを 989 バイトに水増しできることがわかりました。こうした水増しは、IPP／HTTP リクエストに 2 回含められます。1 回は HTTP ヘッダーに、もう 1 回は標的となるシステムに向けられる POST データに含められます。
攻撃者は、こうした水増し手法を使用して、標的となるネットワークとシステムの帯域幅とリソースをさらに消費することで、CUPS に向けた DDoS 攻撃の影響をさらに悪化させる可能性があります。図 1 は、そうした状況を視覚的に示したものです。
Fig. 1: Network diagram of attack flow
攻撃を行うシステム
こうした脅威の最も厄介な側面の 1 つに、非常に少ないリソースで攻撃を実行できるということが挙げられます。図 2 と図 3 は、 攻撃を行うシステムは、公開されている脆弱な CUPS サービスに、インターネット接続を使用して 1 つのパケットを送信するだけで攻撃を開始できます。
./cups.py [CUPS_IP] [TARGET_IP]:1337 attacker_controlled-payload%20goes.here
Sending UDP Payload to target [TARGET_IP] and port 1337
Bytes Sent: 78
図 2：ステージングの悪用
09:05:03.072432 IP 192.168.12.143.43937 > X.X.X.X.631: UDP, length 78
0x0000: 4500 006a 1991 4000 4011 2ed5 c0a8 0c8f E..j..@.@.......
0x0010: xxxx xxxx aba1 0277 0056 bb25 3020 3000 .......w.V.%0.0.
0x0020: 6874 7470 3a2f 2fxx xxxx 2exx xx2e xxxx http://xxx.xx.xx
0x0030: 2exx xxxx 3a31 3333 372f 7072 696e 7465 .xxx:1337/printe
0x0040: 7273 2f61 7474 6163 6b65 725f 636f 6e74 rs/attacker_cont
0x0050: 726f 6c6c 6564 2d70 6179 6c6f 6164 2532 rolled-payload%2
0x0060: 3067 6f65 732e 6865 7265 0goes.here
図 3：UDP パケットの発信（機能しないペイロードに変更）
標的システム
最終的に CUPS サービスは、IPP 属性ファイルであると考えられるものを取得しようとしますが、実際には、攻撃者が指定したものは何でも取得しようとします。UDP パケットで指定されたターゲットは、CUPS を実行しているシステムからの着信 TCP 接続の受信を開始します（図 4）。
Fig. 4: CUPS service establishing a connection to the target
実際のリクエストデータを含む受信した 2 つのパケットを詳しく調べると、未加工の IPP リクエストと、（CUPS サービスから送信された）部分的に攻撃者が制御する POST データを確認できます（図 5）。
Fig. 5: IPP/HTTP request received by the target
IPP 属性の取得時に参照しようとすると、最終的に、標的となったホストに対してこうしたリクエストが生成されることが、cups-browsed デーモンのログからわかります（図 6）。
Fig. 6: Cups-browsed logs
影響とリスク
包括的な分析を行うために、制御されたラボとインターネットの両方で、マシンからさまざまなパターンをテストし、観察しました。こうしたパターンは、攻撃のシナリオと増幅要因に大きく影響します。
Akamai SIRT は evilsocket から提供されたデータに基づいて、公衆インターネットでアクセス可能で、こうした欠陥に対して脆弱な（19 万 8,000 台以上の）デバイスのグローバルインターネットをスキャンして分析しました。そのデータから、そうしたデバイスの約 34%（5 万 8,000 台以上）がこうした攻撃に対して脆弱であることがわかりました。
さらにテストで、 こうしたアクティブな CUPS サーバーの一部は、最初のリクエストを受信後、繰り返しビーコンを送り返し、その一部は HTTP／404 応答に対応してエンドレスにビーコンを送り返すように見えます。オンライン上のこうしたシステムのうち、何百ものシステムが、それぞれ何千ものリクエストを確立し、それをテストシステムに送信しました。
これは、こうした脆弱性による潜在的な増幅がかなり大きく、影響を受けるサーバーを運用している組織に重大な問題をもたらす可能性があることを示しています。 また、脆弱な CUPS サーバーの一部が、有効な HTTPS によって保護された Web サイトに対するプロービングの実行から Transport Layer Security（TLS）ハンドシェイクを完了できたこともテストで確認しました。TLS に影響を与える可能性があり、それによってハンドシェイクと暗号化／復号化処理によるサーバーのハードウェアとリソースの消費に関するオーバーヘッドにさらに負担をかけ、状況がさらに悪化することにもなります。
旧式のテクノロジーの弊害
特定されたこうしたマシンの多くは、2007 年に最初にリリースされたバージョン 1.3 など、CUPS の非常に古いバージョンで実行されていることに注意する必要があります。マシン上で非常に古いハードウェアやソフトウェアを稼働させたまま放置している組織は珍しくなく、そうしたデバイスがすぐに更新される可能性は低いです。 こうした状況は、攻撃者にとって格好のチャンスです。攻撃者は、DDoS 増幅のために旧式のハードウェアを悪用することも、（こうしたシナリオでは RCE を前提として）DDoS を含むさまざまな目的のためにボットネットを構築することもできます。
増幅率の推定
増幅率は大きく異なるため、平均的なシナリオと最悪のシナリオの両方を取り上げて、読者が潜在的な脅威を評価しやすいようにしています。
最終的に、こうしたペイロードのサイズはターゲティングディレクティブによって決まりますが、ベースラインの計算では、必要最小限の 30 バイトの UDP パケットと、最悪の場合の最大限水増しされた 1028 バイトの UDP パケットを使用します。このパケットは IPP URI ディレクティブを使用し、それに 989 バイト（テスト中に検出された最大値）を入力します。これは複製され、結果として発生する攻撃トラフィックに含められます。
最悪のシナリオでは、1 つのプローブの結果として、接続やリクエストの試みが無限に続くような状態が観察されました。こうした流れには終わりがないように見え、デーモンを終了させるか、または再起動するまで続きます。こうしたシナリオのこのような状態は無限増幅と考えられます。5 万 8,000 以上の応答システムをテストし、数百のシステムがこのパターンに陥りました。
約 62%（3 万 5,900 以上）のシステムが、UDP パケットに応答して、少なくとも 10 個の TCP／IPP／HTTP リクエストを標的システムに送信しました。全体的に、5 万 8,000 以上の応答システム（一定期間の無限応答システムを含む）の応答率は平均 45 応答で、これを使用して潜在的な増幅率をさらに計算します。
必要最小限のプローブ（30 バイト）シナリオでは、標的のマシンが完全な TCP 接続と、ペイロードを含む 2 つのパケットを受信したことがわかります。最初のパケットには HTTP リクエストとヘッダーが含まれ、2 つ目のパケットにはリクエストに対応する POST データが含まれます（図 7）。
Fig. 7: Minimal viable amplification flow
この 2 つのパケット（226 バイトと 174 バイト）は合計 400 バイトです。これらの接続を取得し、CUPS リフレクターごとに 45 回リクエストすると仮定すると、結果として 30 バイトのプローブごとに 18,000 バイトのトラフィックが生成されます。つまり、増幅定数は 平均的な試行の 約 600 倍になります。
増幅率が低いと影響が小さい訳ではない
最悪のシナリオでは、パケットサイズ以外の結果も異なります。1,028 バイトの最大限水増しされた UDP ペイロードを使用して、これと同じテストを行うと（図 8）、ターゲットに対する流れが大幅に大きくなりますが、増幅が小さくなります。
Fig. 8: Maximally padded attack payloads arriving at the target
このシナリオでは、依然として 2 つのパケットペイロードが到達しますが、それぞれサイズは 1,217 バイトと 1,164 バイトになり、合計 2,381 バイトになります。リフレクターあたりの応答率が同じ平均 45 応答と仮定すると、1,028 バイトプローブあたりのトラフィックの合計は 107,000 バイトになり、増幅率は 104 倍に低下します。
増幅率は低下しましたが、 ターゲットネットワークで消費される帯域幅は、必要最小限のペイロードのほぼ 6 倍になります。その結果、標的となる HTTP サーバーは、こうしたリクエストを処理するためにリソースを割り当てる必要も生じます。そのため、このシナリオでは増幅率は高まらないものの、防御担当者にとってより厄介な（そして切実な）攻撃になります。
こうした可能性の拡大
5 万 8,000 台以上のすべての特定された CUPS ホストが同じキャンペーンに捕らえられたとすると、着信攻撃トラフィックが最小限の例よりも UDP パケットあたり 1 GB 増加する可能性があります。最大限水増しされたシナリオでは 6 GB 増加する可能性があります。こうした帯域幅の数値は驚くべき問題とは見なされないかもしれませんが、どちらのシナリオでもターゲットは約 260 万の TCP 接続と HTTP リクエストを処理する必要があります。
CUPS の DDoS オプション
こうした性質の攻撃は、こうした攻撃、つまり脆弱なシステムに、インターネットを介して被害者に大量のトラフィックを送信し続けるように指示するという攻撃を攻撃者が実行するうえで、技術的な参入障壁が低下し続けているという厄介な傾向の一部となっています。さらに悪いことに、インターネット上に公開されている CUPS サービスに 1 つのパケットを送信するだけで、こうしたことができます。 攻撃者はインターネット上で現在公開されているあらゆる脆弱な CUPS サービスをわずか数秒で悪用しており、最新のハイパースケーラープラットフォームを使用することでコストを 1 セント未満に抑えることができます。
evilsocket の調査で指摘されているように、インターネット上で UDP プローブに応答するデバイスが 19 万 8,000 台以上あり、SIRT は、そのうちの約 34%（5 万 8,000 台以上）が DDoS 攻撃に悪用されやすい方法で UDP プローブに到達していることを確認しています。
リモート攻撃者は、細工されたペイロードを使用してこうした脆弱性を悪用し、 cups-browsed デーモンを取得して、サードパーティへのアウトバウンド TCP 接続を実行する可能性があります。前述のターゲットが標的とされるポートの HTTPS サーバーをたまたま実行している場合、サーバーはこうしたリクエストとデータを解析して処理しようとしてサイクルとリソースを消費し、攻撃の影響がさらに大きくなる必要があります。CDN とキャッシングの場合、POST リクエストで指定されている URL が存在する可能性は低いため、結果として、キャッシュヒットをバイパスして、こうしたペイロードをオリジンサーバーに転送する 404 エラーが発生します。
evilsocket が実施した調査によると、CUPS の多くの配布とバージョンに影響が及びました。最終的に、脆弱性は「cups-browsed」内にあり、これは「cups-filters」でパッケージ化されます。これはUDP 経由でプリンターの追加リクエストを受信した時に発生します。 cups-browsed を localhost にバインドする、または cups-browsed でリスニングを完全に無効にする、複数の Linux ディストリビューションからの緩和策があるようです。
CUPS の脆弱性の緩和
最新バージョンの CUPS にアップデートするか、または CUPS を完全に削除するかは、システム固有のニーズに応じて判断します。システムが印刷機能に依存している場合は、最新バージョンの CUPS にアップデートして、最新のデバイスに対応するようにセキュリティ、パフォーマンス、サポートを向上させます。一方で、セットアップに印刷が不要な場合は、CUPS を削除してシステムをシンプル化し、潜在的な脆弱性を低減させ、リソースを節約することができます。
最終的に、その環境での印刷機能の必要性と最新のセキュアなシステムを維持する重要性に基づいて、こうした判断を行う必要があります。少なくとも、CUPS ソフトウェアの削除やアップデートが現実的でないとしても、広範なインターネットからアクセスできる場合は特に、サービスポート（UDP／631）をファイアウォールで保護する必要があります。
攻撃者はほとんどの場合、新たに報告された脆弱性を迅速に悪用しており、多くの新しいリリースが最初に公開されてからわずか 7 日以内に悪用されています。パッチ適用には時間がかかり、ハッカーはそうした脆弱な移行期間を積極的に活用しています。多くの組織が古いソフトウェアの一部のアップデートを怠っていて、これがハッカーにとって特に利益の出やすい場合があるため、こうした新たな脆弱性の悪用に拍車がかかっています。
被害者のための DDoS 緩和
脆弱な CUPS システムから開始された DDoS 攻撃の被害者がネットワーク上や Web Application Firewall（WAF）上の攻撃トラフィックについて注意を喚起し、確認し、削減する際に役立つトラフィックの特性がいくつかあります。
CUPS サービスから発信されるリクエストはすべて POST /printers/ または POST /classes/ で始まり、文字列 /printers/ の後のペイロードは攻撃者が制御できますが、ペイロードの最初の部分は制御できません。 また、文字列 CUPS User-Agent は非常に有益な情報で、 CUPS/[VERSION]という形式と IPP への参照を使用します。 これらは UA 独自の文字列で、通常、オーガニックトラフィックでは見られません。
HTTP ヘッダーと POST データには静的な要素もあります。 application/ipp の Content-Type ヘッダーと、POST データのペイロード printer-uri は、当社がテストで特定した両方とも静的な値です（図 9）。
Fig. 9: Highlighted values in observed traffic that could aid in detection and blocking
防御担当者を支援するために、プレーンテキストソケットを介してネットワークへのこうした流れを特定する際に役立つ Snort ルールも用意しています（図 10）。
alert http any any -> any any (msg:"CUPS Reflected DDoS IPP Request";
pcre:"/POST \/printers\/|POST \/classes\//"; http_method;
content:"Content-Type: application/ipp"; http_header;
content:"User-Agent: CUPS/"; http_header;
content:"printer-uri"; http_client_body;
metadata:service http;
reference:url,https://akamai.com/blog/security-research/2024/october-cups-ddos-threat;
sid:100004; rev:2;)
図 10：CUPS 攻撃トラフィックの Snort ルール
前述のように、当社は HTTP ペイロードを配信する前に HTTPS ハンドシェイクを完了させるシステムをオンライン上で見つけたため、HTTPS を使用する防御担当者は、ネットワーク監視システムではなく WAF 設定にこうした一致規則を実装することを検討する必要があります。
結論
新しい DDoS 攻撃ベクトルは、スキルの低い日和見主義的な攻撃者に発見され、多くの場合すぐに悪用されます。当社は、CUPS と大量のデバイスにはこうした方法で悪用される可能性のある脆弱性があることを確認し、防御担当者が CUPS ベースの攻撃に遭遇する可能性が高いと確信するようになりました。
メッセージングやクリーンアップの取り組みが、インターネットにさらされている脆弱なデバイスの数（現在 5 万 8,000 台以上）を減らす効果を発揮するまで、このベクトルはオンラインで悪用され続けると思われます。当社は、防御担当者、ネットワーク事業者、システム管理者がこのメッセージを受け取り、全員がそれぞれのリスクに迅速に対処するか、または少なくとも今後、リスクを悪用する可能性のある攻撃者を特定して阻止する準備をすることを期待しています。
また、 evilsocket（Simone Margaritelli） の貴重なサポートと情報提供に感謝いたします。♥️
