Squidbleed: 29 Jahre alter Squid-Proxy-Bug leakt HTTP-Requests im Klartext

Der Squid-Proxy, einer der am weitesten verbreiteten Open-Source-Web-Proxys, hat eine kritische Sicherheitslücke, die unter dem Namen Squidbleed bekannt wurde. Die Lücke ermöglicht es Angreifern, fremde HTTP-Requests im Klartext mitzulesen, inklusive darin enthaltener Passwörter, Session-Tokens und API-Keys. Besonders brisant: Der Fehler liegt in einer FTP-Parsing-Funktion aus dem Jahr 1997 und ist in der Standardkonfiguration ausnutzbar.

Meldung und Einordnung

Forscher von Calif.io haben eine Heap-Overread-Lücke im Squid-Proxy entdeckt und veröffentlicht. Die Schwachstelle trägt die CVE-Kennung CVE-2026-XXXXX (CVSS 7.5, hoch) und betrifft alle Squid-Versionen seit mindestens 1997. Der Fehler befindet sich in der Funktion, die FTP-Protokoll-Daten parst. Ein entfernter, nicht authentifizierter Angreifer kann durch gezielte FTP-Anfragen einen Heap-Overread auslösen, der Speicherbereiche anderer Proxy-Nutzer offenlegt.

Die Lücke ist besonders gefährlich, weil sie in der Standardkonfiguration von Squid ausnutzbar ist. Keine speziellen Einstellungen oder Berechtigungen sind nötig. Jeder, der Traffic durch den gleichen Squid-Proxy senden darf, kann potenziell die HTTP-Requests anderer Nutzer mitlesen. In Unternehmensnetzen, in denen Squid als zentraler Forward-Proxy eingesetzt wird, betrifft das potenziell alle Mitarbeiter.

Technische Details für Admins

Der Heap-Overread entsteht in der FTP-Response-Parsing-Funktion von Squid. Wenn ein Client eine FTP-Anfrage über den HTTP-Proxy stellt, parst Squid die FTP-Antworten. Ein speziell präparierter FTP-Server kann eine Antwort senden, die den Parser dazu bringt, über das Ende des reservierten Heap-Speichers hinauszulesen. Die ausgelesenen Daten stammen aus benachbarten Heap-Regionen, in denen sich die HTTP-Requests anderer Clients befinden können.

Risiko für KMU und Betrieb

Viele kleine und mittlere Unternehmen setzen Squid als zentralen Web-Proxy ein, um den Internetzugriff zu kontrollieren, zu cachen und zu protokollieren. In solchen Konfigurationen teilen sich alle Mitarbeiter denselben Proxy. Ein Angreifer, der Zugriff auf diesen Proxy hat (etwa über ein kompromittiertes Gerät im Netzwerk oder einen externen Client mit Proxy-Zugang), kann die HTTP-Requests aller anderen Nutzer mitlesen.

Das betrifft nicht nur explizite Passwörter in Login-Formularen, sondern auch Session-Cookies, API-Tokens, Authentifizierungs-Header und andere sensible Daten, die in HTTP-Requests übertragen werden. In Zeiten von HTTPS ist der Request-Inhalt zwar verschlüsselt, aber die Metadaten (Host, Pfad, Cookies, Header) sind im Klartext sichtbar, wenn sie über den Proxy laufen.

Was Admins jetzt prüfen sollten

1. Squid-Version prüfen: squid -v zeigt die installierte Version. Liegt sie unter 6.15 oder 5.10, ist das System verwundbar.
2. Update einspielen: Die offiziellen Squid-Pakete für Debian, Ubuntu, RHEL und andere Distributionen enthalten inzwischen die gefixten Versionen. apt update && apt upgrade squid oder äquivalent.
3. Proxy-Zugriff kontrollieren: Prüfen Sie die ACLs (Access Control Lists) in der squid.conf. Nur autorisierte Clients sollten den Proxy nutzen dürfen. http_access allow-Regeln restriktiv halten.
4. Monitoring aktivieren: Überwachen Sie die Squid-Logs auf ungewöhnliche FTP-Anfragen oder verdächtige Zugriffsmuster. Ein plötzlicher Anstieg von FTP-Requests über den HTTP-Proxy kann auf Ausnutzungsversuche hindeuten.
5. HTTPS-Only-Richtlinie prüfen: Wenn möglich, sollten alle internen Dienste und Webanwendungen auf HTTPS umgestellt werden. Auch wenn der Squidbleed-Bug Metadaten preisgibt, schützt HTTPS den eigentlichen Request-Body.
6. Segmentierung prüfen: In größeren Umgebungen sollten verschiedene Nutzergruppen (Mitarbeiter, Gäste, Server) über separate Proxy-Instanzen getrennt werden, um die Angriffsfläche zu verkleinern.
7. Alternativen evaluieren: Für sicherheitskritische Umgebungen kann der Einsatz alternativer Proxys wie HAProxy, Nginx oder Träfik in Betracht gezogen werden, die keine FTP-Parsing-Funktion haben.

Betriebscheck nach der Meldung

1. Ist die Squid-Version auf allen Servern bekannt und dokumentiert?
2. Sind alle Squid-Instanzen auf Version 6.15 oder 5.10 aktualisiert?
3. Gibt es Squid-Instanzen, die nicht mehr aktiv gemanaged werden (Vergessene Testsysteme, alte Container)?
4. Sind die Proxy-ACLs so restriktiv wie möglich konfiguriert?
5. Werden die Squid-Zugriffslogs regelmäßig auf Anomalien überprüft?
6. Gibt es eine Dokumentation, welche Dienste und Anwendungen den Squid-Proxy nutzen?

Admin-Einschätzung

Der Squidbleed-Bug ist ein Paradebeispiel für die Risiken von Legacy-Code in kritischer Infrastruktur. Ein FTP-Parser aus dem Jahr 1997, der nie für die heutige Bedrohungslage ausgelegt war, kann in der Standardkonfiguration ausgenutzt werden. Die Lücke ist technisch weniger spektakulär als eine Remote-Code-Execution, aber die praktische Auswirkung ist für Unternehmen, die Squid als zentralen Proxy einsetzen, erheblich.

Positiv ist, dass die Squid-Entwickler schnell reagiert haben und Patches in den stabilen Versionen 6.15 und 5.10 bereitstehen. Admins sollten das Update prioritär behandeln, aber nicht in Panik verfallen. Die Lücke erfordert Zugriff auf den Proxy, was die Angriffsfläche in gut segmentierten Netzwerken begrenzt. Trotzdem gilt: Jeder ungepatchte Squid-Proxy ist ein Risiko, das schnell behoben werden sollte.

Passende Anleitungen auf S-EDV

1. Linux-Server absichern: UFW-Firewall und Fail2ban – Grundlegende Absicherung für Server, die Squid oder andere Dienste betreiben.
2. Docker und Docker Compose auf Linux installieren (Ubuntu/Debian): die Self-Hosting-Grundlage – Wer Squid in Containern betreibt, findet hier die Basis für das Setup.

Quellen

1. The Hacker News: 29-Year-Old Squid Proxy Bug Squidbleed Can Leak Cleartext HTTP Requests
2. BleepingComputer: Squidbleed: 29-year-old Squid proxy bug leaks HTTP reqüsts
3. Calif.io: Squidbleed Disclosure