Zu viele CUPS: Die Bedrohung durch DDoS
Redaktion und weitere Kommentare von Tricia Howard
Zusammenfassung
Forscher von Akamai haben eine neue Angriffsmethode mit CUPS bestätigt, die für DDoS-Angriffe (Distributed Denial of Service) genutzt werden könnte. (CVE-2024-47850)
Forschungen zeigen, dass das Angriffssystem nur ein einziges Paket an einen anfälligen und mit dem Internet verbundenen CUPS-Dienst senden muss, um den Angriff zu starten.
Das Akamai Security Intelligence and Response Team (SIRT) hat festgestellt, dass mehr als 198.000 Geräte für diese Angriffsmethode anfällig und über das öffentliche Internet zugänglich sind – etwa 34 % davon könnten für DDoS ausgenutzt werden (mehr als 58.000).
Von den über 58.000 anfälligen Geräten wiesen Hunderte eine „Endlosschleife“ von Anfragen auf.
Die wenigen Ressourcen, die zum Start eines erfolgreichen Angriffs erforderlich sind, verdeutlichen die Gefahr: Ein Angreifer bräuchte nur wenige Sekunden, um jeden anfälligen CUPS-Dienst zu übernehmen, der derzeit über das Internet verfügbar ist – und dabei entstehen ihm weniger als ein US-Cent an Kosten auf modernen Hyperscaler-Plattformen.
Die CVEs
Am 26. September 2024 hat Sicherheitsforscher evilsocket RCE-Schwachstellen (Remote Code Execution) im Common Unix Printing System (CUPS) aufgedeckt . Kurz gesagt könnte ein Angreifer per Remotezugriff IPP-URLs (Internet Printing Protocol) manipulieren, um schädliche Befehle auszuführen. Das kann durch Verkettung vier verschiedener Schwachstellen geschehen.
CVE-2024-47176 in cups-browsed, die eine Anfrage an eine von einem Angreifer kontrollierten Adresse auslöst
CVE-2024-47076 in libcupsfilters, die die vom Server des Angreifers zurückgegebenen Daten weder validiert noch bereinigt, sondern direkt an den Rest des CUPS-Systems weiterleitet
CVE-2024-47175 in libppd, wobei Eingaben erneut nicht bereinigt, sondern in eine temporäre Datei geschrieben werden
CVE-2024-47177 in cups-filters, die die Ausführung eines willkürlichen Befehls ermöglicht
Mehr zur Geschichte von CUPS
Bei der Überprüfung der technischen Informationen zu den Schwachstellen haben wir festgestellt, dass eine andere Angriffsmethode nicht zur Sprache kam: DDoS. DDoS ist nach wie vor eine gängige Angriffsmethode, die dazu dient, Opfer im Internet zu belästigen und zu stören – von großen Branchen und Regierungen bis hin zu kleinen Content Creatorn, Online-Shops und Spielern. Obwohl sich die ursprüngliche Analyse auf die RCE konzentriert, die schwerwiegendere Folgen haben kann, kann die Schwachstelle auch leicht für DDoS-Verstärkung ausgenutzt werden.
Das Problem tritt auf, wenn ein Angreifer ein speziell gestaltetes Paket sendet, das statt einer Druckeradresse die Adresse eines Ziels angibt. Für jedes gesendete Paket generiert der anfällige CUPS-Server eine größere und teilweise von Angreifern gesteuerte IPP/HTTP-Anfrage, die an das angegebene Ziel gerichtet ist. Infolgedessen ist nicht nur das Ziel betroffen: Auch der Host des CUPS-Servers wird zum Opfer, da der Angriff seine Netzwerkbandbreite und CPU-Ressourcen verbraucht.
Exploit
Ein einfaches Skript kann verwendet werden, um das schädliche UDP-Paket an eine anfällige CUPS-Instanz zu senden. Die spezielle Payload weist CUPS an, eine IPP/HTTP-Anforderung an das Ziel und den Port zu senden, die vom Angreifer angegeben wurden. Die Schwachstelle entsteht, wenn cups-browsed versucht, den URI abzurufen, der zum Herunterladen der IPP-Attributdatei angegeben wurde.
Dieser PPD-Datei-URI ist etwas willkürlich und kann vom Angreifer geändert werden. Beim Testen haben wir festgestellt, dass diese URI-Payload auf 989 Byte erweitert werden kann. Diese Erweiterung wird zweimal in die IPP/HTTP-Anfrage aufgenommen: einmal in den HTTP-Headern und erneut in den POST-Daten, die an das Zielsystem weitergeleitet werden.
Durch diese Erweiterungstechnik könnten Angreifer die Auswirkungen CUPS-basierter DDoS-Angriffe weiter verstärken, indem sie zusätzliche Bandbreite und Ressourcen in den Zielnetzwerken und -systemen beanspruchen. Abbildung 1 ist eine visuelle Darstellung eines solchen Angriffs.
Fig. 1: Network diagram of attack flow
Angriffssystem
Einer der beunruhigendsten Aspekte dieser Bedrohung ist, wie wenig Ressourcen Angreifer benötigen, um einen Angriff zu starten. Abbildungen 2 und 3 zeigen, dass das Angriffssystem nur ein einzelnes Paket an einen anfälligen, über das Internet verfügbaren CUPS-Dienst senden muss, damit das System, auf dem CUPS ausgeführt wird, den Angriff startet.
./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
Abb. 2: Staging des Exploits
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
Abb. 3: Ausgehendes UDP-Paket (geändert zu einer nicht funktionsfähigen Payload)
Zielsystem
Am Ende entsteht ein CUPS-Dienst, der versucht, eine IPP-Attributdatei abzurufen, bei der es sich jedoch in Wirklichkeit um die Angaben des Angreifers handelt. Das im UDP-Paket angegebene Ziel empfängt eingehende TCP-Verbindungen von dem System, auf dem CUPS ausgeführt wird (Abbildung 4).
Fig. 4: CUPS service establishing a connection to the target
Wenn wir uns die beiden empfangenen Pakete genauer ansehen, die die tatsächlichen Anfragedaten enthielten, sehen wir die rohe IPP-Anfrage und die zugehörigen POST-Daten, die teilweise vom Angreifer gesteuert werden und teilweise vom CUPS-Dienst stammen (Abbildung 5).
Fig. 5: IPP/HTTP request received by the target
In den Protokollen für den cups-browsed-Daemon können Sie sehen, dass die durchsuchten Versuche, die IPP-Attribute abzurufen, letztendlich die Anfragen an den Zielhost erzeugen (Abbildung 6).
Fig. 6: Cups-browsed logs
Auswirkungen und Anfälligkeit
Um eine umfassende Analyse zu gewährleisten, haben wir verschiedene Muster von Maschinen getestet und beobachtet, sowohl im kontrollierten Labor als auch im Internet. Diese Muster wirken sich stark auf die Angriffsszenarien und Verstärkungsfaktoren aus.
Das Akamai SIRT hat das globale Internet auf Geräte überprüft und analysiert, die anfällig für diese Schwachstelle und über das öffentliche Internet zugänglich sind (mehr als 198.000 Geräte). Hierbei haben wir uns auf Daten gestützt, die uns von evilsocket bereitgestellt wurden. Auf Grundlage dieser Daten haben wir festgestellt, dass etwa 34 % dieser Geräte (über 58.000) anfällig für diesen Angriff waren.
Darüber hinaus haben unsere Tests ergeben, dass einige dieser aktiven CUPS-Server nach dem Empfang der ursprünglichen Anfragen wiederholt ein Beacon zurücksenden – einige von ihnen tun dies scheinbar endlos als Reaktion auf HTTP/404-Antworten. Hunderte dieser Systeme in freier Wildbahn haben jeweils Tausende von Anfragen erstellt und an unsere Testsysteme gesendet.
Das zeigt, dass diese Schwachstelle potenziell eine hohe Verstärkung ermöglicht und Unternehmen, die diese betroffenen Server ausführen, erhebliche Probleme verursachen kann. In unseren Tests haben wir auch Sondierungsversuche gegen gültige HTTPS-geschützte Websites durchgeführt. Dabei konnten wir bestätigen, dass einige der anfälligen CUPS-Server in der Lage waren, TLS-Handshakes (Transport Layer Security) durchzuführen. Die Möglichkeit, TLS zu beeinflussen, erhöht den Angriffsschaden zusätzlich, da Serverhardware und Ressourcen durch den Handshake und die Ver-/Entschlüsselungsverarbeitung zusätzlich belastet werden.
Veraltete Technologie schlägt wieder zu
Wir sollten beachten, dass auf vielen dieser identifizierten Maschinen sehr alte CUPS-Versionen ausgeführt wurden, beispielsweise Version 1.3, die ursprünglich 2007 veröffentlicht wurde. Es ist nicht ungewöhnlich, dass einige Unternehmen Computer mit extrem veralteter Hardware und Software laufen lassen, und es ist unwahrscheinlich, dass diese Geräte in absehbarer Zeit aktualisiert werden. Hieraus ergibt sich eine hervorragende Gelegenheit für böswillige Angreifer: Sie können die veraltete Hardware zur DDoS-Verstärkung nutzen oder (in diesem Szenario aufgrund der RCE) Botnets für verschiedene Zwecke erstellen, darunter auch DDoS.
Schätzwerte für die Verstärkung
Da die Verstärkungsraten erheblich variieren können, haben wir sowohl ein durchschnittliches Szenario als auch ein Worst-Case-Szenario abgedeckt, um Lesern die Bewertung der potenziellen Bedrohung zu erleichtern.
Letztendlich bestimmt die Targeting-Anweisung die Größe der Payload, doch für Basisberechnungen verwenden wir eine UDP-Paketgröße von mindestens 30 Byte und ein maximal erweitertes UDP-Paket von 1.028 Byte für den Worst Case. Dieses Paket verwendet die IPP-URI-Anweisung und erweitert es um 989 Byte (Maximalwert während unserer Tests), die dupliziert und in den resultierenden Angriffsverkehr einbezogen werden.
Im Worst Case beobachteten wir einen endlosen Strom versuchter Verbindungen und Anfragen, die als Ergebnis einer einzigen Sondierungsanfrage entstanden waren. Dieser Strom scheint kein Ende zu haben und wird fortgesetzt, bis der Daemon beendet oder neu gestartet wird. Das könnte in diesem Szenario als unendliche Verstärkung betrachtet werden. Während der Tests der über 58.000 antwortenden Geräte zeigten einige Hundert dieses Muster.
Etwa 62 % (mehr als 35.900) der Systeme haben als Reaktion auf unser UDP-Paket mindestens 10 TCP/IPP/HTTP-Anfragen an unser Zielsystem gesendet. Insgesamt betrug die Antwortrate bei den über 58.000 antwortenden Geräten (einschließlich der Endlosantworter) durchschnittlich 45 Antworten, was wir zur weiteren Berechnung der potenziellen Verstärkungsraten verwenden werden.
Im Szenario mit der Mindest-Payload (30 Byte) haben wir festgestellt, dass der Zielcomputer eine vollständige TCP-Verbindung und zwei Pakete mit Payloads empfangen hatte. Das erste Paket enthält die HTTP-Anfrage und die Header, das zweite enthält die POST-Daten für die Anfrage (Abbildung 7).
Fig. 7: Minimal viable amplification flow
Diese Pakete (226 Byte und 174 Byte) umfassen insgesamt 400 Byte. Wenn wir davon ausgehen, dass wir diese Verbindungen und Anfragen 45 Mal pro CUPS-Reflektor erhalten, sind das 18.000 Byte an resultierendem Datenverkehr pro 30-Byte-Sondierungsanfrage – oder ungefähr ein 600-facher Verstärkungsfaktor bei einem durchschnittlichen Versuch.
Eine geringere Verstärkung bedeutet nicht, dass die Wirkung geringer ist
Das Worst-Case-Szenario zeigt andere Ergebnisse abseits der Paketgröße. Wenn wir den gleichen Test mit maximal erweiterten UDP-Payloads von 1.028 Byte ausführen (Abbildung 8), ergibt sich zwar ein viel größerer Datenfluss, der an das Ziel gerichtet ist, aber eine geringere Verstärkung.
Fig. 8: Maximally padded attack payloads arriving at the target
In diesem Szenario kommt unsere Zwei-Pakete-Payload immer noch an, doch die entsprechenden Größen betragen jetzt 1.217 Byte und 1.164 Byte, was insgesamt 2.381 Byte ergibt. Bei der Annahme des gleichen Durchschnitts von 45 Antworten pro Reflektor ergeben sich insgesamt 107.000 Byte an Traffic pro 1.028-Byte-Sondierungsanfrage und unsere Verstärkungsrate sinkt auf das 104-Fache.
Obwohl die Verstärkungsrate gesunken ist, beträgt die im Zielnetzwerk verbrauchte Bandbreite fast das Sechsfache der Mindest-Payload. Das würde auch dazu führen, dass der HTTP-Zielserver Ressourcen für die Verarbeitung dieser Anfragen zuweisen muss. Obwohl es die Verstärkungsraten nicht verbessert, stellt dieses Szenario einen problematischeren (und realistischeren) Angriff für Verteidiger dar.
Skalierung dieser Möglichkeiten
Wenn wir annehmen, dass alle 58.000 identifizierten CUPS-Hosts in dieselbe Kampagne aufgenommen werden, könnte dies zu einer Flut von einem Gigabyte an eingehendem Angriffstraffic pro minimal erweitertem UDP-Paket führen. Im Szenario mit maximaler Erweiterung könnte sogar eine 6-GB-Datenflut entstehen. Obwohl diese Bandbreitenzahlen vielleicht nicht weltbewegend erscheinen, würden sie dennoch dazu führen, dass das Ziel in beiden Szenarien etwa 2,6 Millionen TCP-Verbindungen und HTTP-Anfragen verarbeiten muss.
DDoS-Optionen in CUPS
Angriffe dieser Art sind Teil des beunruhigenden Trends: Die technische Zugangsbarriere für Cyberkriminelle, die solche Angriffe durchführen können, nimmt immer weiter ab – sie dirigieren anfällige Systeme über das Internet, um Opfern eine anhaltende Trafficflut zu senden. Noch schlimmer ist, dass dieser Angriff durch Senden eines einzigen Pakets an über das Internet verfügbare CUPS-Dienste erreicht werden kann. Ein Angreifer bräuchte nur wenige Sekunden, um jeden anfälligen CUPS-Dienst zu übernehmen, der derzeit über das Internet verfügbar ist – und dabei entstehen ihm weniger als ein US-Cent an Kosten auf modernen Hyperscaler-Plattformen.
Wie die Recherche von evilsocket zeigt, gibt es im Internet etwas mehr als 198.000 Geräte, die auf UDP-Sonden reagieren – und das SIRT fand heraus, dass hiervon etwa 34 % (mehr als 58.000) in einer Weise auf unsere UDP-Sondierungsanfrage reagiert haben, die leicht für DDoS ausgenutzt werden könnte.
Ein Remoteangreifer, der eine speziell gestaltete Payload verwendet, kann diese Sicherheitsanfälligkeit ausnutzen, um den cups-browsed -Daemon dazu zu bringen, ausgehende TCP-Verbindungen zu einem Dritten zu erstellen. Wenn dieses Ziel zufällig einen HTTPS-Server auf dem Zielport ausführt, muss der Server Zyklen und Ressourcen aufwenden, um diese Anfragen und Daten zu analysieren und zu verarbeiten, was den Angriff möglicherweise noch wirkungsvoller macht. Im Fall von CDNs und Caching ist es unwahrscheinlich, dass die in der POST-Anfrage angegebenen URLs vorhanden sind, was zu einem 404-Fehler führt, der Cachetreffer umgeht und diese Payloads an die Ursprungsserver weiterleitet.
Basierend auf den von evilsocket durchgeführten Untersuchungen sind viele Verteilungen und Versionen von CUPS betroffen. Letztendlich liegt die Schwachstelle in „cups-browsed“ im Paket mit „cups-filters“, wenn eine Anfrage zum Hinzufügen eines Druckers über UDP eingeht. Es scheint schadensbegrenzende Maßnahmen von mehreren Linux-Distributionen zu geben, die cups-browsed bis localhost binden oder cups-browsed vollständig daran zu hindern, Ports abzuhören.
Schadensbegrenzende Maßnahmen für CUPS-Schwachstellen
Die Entscheidung, ob Sie CUPS auf die neueste Version aktualisieren oder es gänzlich entfernen, hängt vollständig von den spezifischen Anforderungen Ihres Systems ab. Wenn Ihr System auf Druckfunktionen angewiesen ist, sorgt die Aktualisierung auf die neueste Version von CUPS für mehr Sicherheit, Performance und Unterstützung für moderne Geräte. Wenn das Drucken jedoch für Ihre Einrichtung unnötig ist, kann das Entfernen von CUPS Ihr System vereinfachen, potenzielle Schwachstellen verringern und Ressourcen sparen.
Letztendlich sollte diese Entscheidung darauf basieren, wie wichtig die Druckfunktionen für Ihre Umgebung sind und wie wichtig es ist, ein aktuelles, sicheres System zu pflegen. Zumindest sollten Verteidiger – wenn das Entfernen oder Aktualisieren der CUPS-Software nicht praktikabel ist – die Serviceports (UDP/631) durch eine Firewall schützen, insbesondere wenn sie über das Internet zugänglich sind.
Cyberkriminelle machen sich neu gemeldete Schwachstellen schnell zunutze: Viele neue Versionen werden innerhalb von nur sieben Tagen nach der ersten Offenlegung ausgenutzt. Das Patching nimmt Zeit in Anspruch und Hacker sind bestrebt, diese anfällige Übergangszeit zu nutzen. Viele Unternehmen vernachlässigen auch die Aktualisierung einiger ihrer älteren Software, was es für Hacker besonders lukrativ macht, neue Schwachstellen wie diese auszunutzen.
DDoS-Abwehr für Opfer
Für Opfer eines DDoS-Angriffs, der über anfällige CUPS-Systeme gestartet wurde, gibt es einige Trafficmerkmale, die dabei helfen, Angriffstraffic im Netzwerk oder in der Web Application Firewall (WAF).
Alle Anfragen, die vom CUPS-Dienst stammen, beginnen mit POST /printers/ oder POST /classes/. Und während die Payload hinter der Zeichenfolge /printers/ vom Angreifer gesteuert werden kann, ist das beim anfänglichen Teil der Payload nicht der Fall. Zusätzlich sind die User-Agent -Zeichenfolgen von CUPS sehr informativ und verwenden das Format CUPS/[VERSION] sowie einen Verweis auf IPP. Das sind sehr einzigartige Zeichenfolgen im UA und werden üblicherweise nicht im organischen Traffic beobachtet.
Es gibt auch statische Elemente in HTTP-Headern und POST-Daten. Die Einstellung Content-Type -Header von application/ipp und die Payload- printer-uri in den POST-Daten sind beide statische Werte, die wir während des Tests identifiziert haben (Abbildung 9).
Fig. 9: Highlighted values in observed traffic that could aid in detection and blocking
Um Verteidiger zu unterstützen, haben wir auch eine Snort-Regel eingeführt, mit der diese Flows, die über Klartext-Sockets in Ihr Netzwerk gelangen, identifiziert werden können (Abbildung 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;)
Abb. 10: Snort-Regel für CUPS-Angriffstraffic
Wie bereits erwähnt, haben wir in freier Wildbahn Systeme gefunden, die vor der Bereitstellung ihrer HTTP-Payloads HTTPS-Handshakes durchführen würden. Verteidiger, die HTTPS verwenden, sollten diese Abgleichregeln in ihre WAF-Konfigurationen und nicht in ihre Netzwerküberwachungssysteme implementieren.
Fazit
Neue DDoS-Angriffsvektoren werden manchmal von gering qualifizierten, opportunistischen Angreifern gefunden und oft schnell ausgenutzt. Diese Schwachstelle in CUPS und die große Anzahl an Geräten, die auf diese Weise ausgenutzt werden könnten, lassen uns glauben, dass Verteidiger wahrscheinlich CUPS-basierte Angriffe erleben werden.
Bis Kommunikations- und Reparaturbemühungen greifen und die Anzahl anfälliger und über das Internet verfügbarer Geräte (derzeit über 58.000) abnimmt, vermuten wir, dass dieser Angriffsvektor in freier Wildbahn eingesetzt werden wird. Wir hoffen, dass Verteidiger, Netzwerkbetreiber und Systemadministratoren die Botschaft erhalten und im Interesse aller schnell ihre jeweiligen Anfälligkeiten zu beheben – oder zumindest darauf vorbereitet sind, Angreifer zu identifizieren und abzuwehren, die diese Risiken in Zukunft nutzen könnten.
Wir möchten uns bei evilsocket (Simone Margaritelli) für seine wertvolle Hilfe und seinen Beitrag bedanken.♥️
