Cookies als Hintertür: der versteckte Kanal, der Web-Shells in PHP auf Linux-Servern aktiviert

In Linux-Servern, die PHP-Anwendungen hosten, entsteht eine störende Praxis: Angreifer verwenden HTTP-Cookies als Kontrollkanal, um Web-Shells zu aktivieren und Remote-Code auszuführen. Anstatt Bestellungen in URL-Parametern oder Anforderungsstellen zu senden - sichtbarer und einfach zu auditieren Kanäle - verbergen bösartige Akteure die Anweisungen innerhalb von Cookie-Werten, die PHP-Code in Laufzeit durch die superglobale Variable verbraucht $_ COOKIE. Dies verwandelt bösartige Interaktion in etwas, das unbemerkt zwischen dem normalen Verkehr der Website geht.

Der Wert dieser Technik liegt in seinem Ermessen. Ein Cookie ist Teil der üblichen Last von HTTP-Anfragen und, es sei denn, Cookie-Header werden ausdrücklich inspiziert, viele Überwachungslösungen betrachten es nicht als primärer Vektor von Befehlen. Cookie-gesteuerte Web-Shells bleiben während des täglichen Gebrauchs der Anwendung inaktiv und wecken nur dann auf, wenn sie eine bestimmte Kombination von Cookie-Werten erhalten, die vom Angreifer bereitgestellt werden, wodurch der beobachtbare Footprint auf den Datensätzen und das Betriebsgeräusch reduziert wird.

Es gibt verschiedene Möglichkeiten, dieses Ausführungsmodell umzusetzen. Einige Angreifer platzieren einen obfuscierten PHP-Ladegerät, der mehrere Überprüfungen in der Laufzeit durchführt und, wenn Cookies eine erwartete Struktur erfüllen, decodiert und eine sekundäre Nutzlast ausführt. In anderen Varianten erhält das Skript strukturierte Fragmente in verschiedenen Cookie-Feldern, die dann zusammengesetzt werden, um operative Funktionen zu komponieren: Dateiverwaltung, Decodierung und in einigen Fällen von schädlichem Code auf Festplatte zur Ausführung. Es gibt auch einfachere Versionen, in denen ein einzelnes Cookie als Auslöser fungiert: Wenn sein Wert dem entspricht, was erwartet wird, führt der Server Befehle, die vom Schauspieler gesendet werden.

Persistence verstärkt das Problem. In mehreren Zwischenfällen haben Angreifer den ersten Zugriff auf Linux-Hosting-Umgebungen durch legitime Anmeldeinformationen erhalten, die gestohlen wurden oder bekannte Schwachstellen ausnutzen. Mit diesem Zugriff installieren sie geplante Aufgaben (Cron-Jobs), die regelmäßig Routinen rufen, die den unterdrückten PHP-Ladegerät regenerieren. So, selbst wenn das Antwort-Team die schädliche Datei entfernt, kann die geplante Aufgabe sie automatisch neu erstellen. Diese Trennung zwischen Persistenz (cron) und Aktivierung (Cookies) schafft eine "selbstreparierende" Architektur, die schwer zu löschen ist, ohne auf beiden Fronten zu intervenieren.

Die Ausrottung ist ein weiterer gemeinsamer Nenner. Verstecken Sie sensible Logik und verwenden Sie Gating mithilfe von Cookies minimiert den interaktiven Pfad, der von Angreifern hinterlassen wird: wenige eindeutige Einträge in den Protokollen, Dateinamen, die legitim und scheinbar normaler HTTP-Verkehr erscheinen. Das Ergebnis ist ein post-persistenter Eingriffszugriff, der für lange Zeiträume latent bleiben kann, ausgefilterte Daten oder als Trampolin für Seitenbewegungen dienen kann.

Das Erkennen und Beantworten dieser Technik erfordert unterschiedliches Denken an die Signale. Überprüfung von Cookie-Header-orientierten Protokollen, Erkennung von ungewöhnlichen Mustern in Namen und Längen von Cookies, und aktive Suche von obfuscated PHP Inhalt in Web-Verzeichnungen sind notwendige Schritte. Sie müssen auch die programmierten Aufgaben überprüfen und jede Datei-Erstellung in öffentlichen Ordnern mit legitimen Management-Events oder Bereitstellungen korrelieren. Vertiefte Inspektionstools für Pakete und Firewall / Web Application Firewall Regeln, die Header untersuchen können helfen, Anwendungen mit verdächtigen Cookies zu identifizieren.

Microsoft, dessen Sicherheitsforschungsteam dieses Verhalten dokumentiert hat, empfiehlt eine Kombination von Präventions- und Detektionsmaßnahmen: Anwendung von Multifaktor-Authentifizierung in Hosting-Panels, SSH und administrativen Schnittstellen; Überwachung des anomalen Zugriffs; Einschränkung der Leistungsfähigkeit von Befehlsinterpretern von Web-Anwendungskomponenten; Prüfung von Cron-Jobs und programmierten Aufgaben; und Begrenzung der Shell-Funktionen von Bedienfeldern. Sie sind spezifische Empfehlungen, die sowohl den ersten Eintrag als auch die Beharrlichkeit und die Kontrolle des Fernzugriffs angreifen.

Zusätzlich zu diesen Maßnahmen, gute Praxis in der Verwaltung von Sitzungen und Cookies reduziert das Risiko, dass ein Vektor als "natürlich" als Cookie böswillige Zwecke dienen. Ressourcen wie die Session-Management-Leitfäden von OWASP sorgen dafür, dass Cookies in Web-Umgebungen generiert, übertragen und gespeichert werden ( OWASP Session Management Cheat Sheet) Kennen Sie den Betrieb des Superglobals $_ COOKIE und wie PHP diese Werte aussetzt, ist auch für Code-Audits und Revisionen nützlich ( PHP offizielle Dokumentation zu Cookies)

Behavior-basierte Erkennungen und anomaly-fokussierte Regeln sind oft effektiver als diejenigen, die bei osfusciertem Code und nicht-traditionellen Kanälen unterzeichnet werden. Die Sicherheitsgemeinschaft unterhält Dokumentationen und Warnungen über Web-Shells und Persistenztechniken, die dazu beitragen, diese Angriffe zu kontextualisieren und operative Reaktionen vorzubereiten, z.B. in Bedrohungsspeichern und Referenzrahmen wie MITRE ATT & CK ( MITRE ATT & CK - Web Shells) oder in Ausschreibungen von nationalen Agenturen ( CISA - Warnungen an Web Shells)

Wenn Sie für einen Server oder eine Hosting-Plattform verantwortlich sind, ist die empfohlene Aktion nicht nur auf einen Vorfall zu reagieren, sondern die Praktiken der minimalen Angriffsfläche zu überprüfen: den administrativen Zugriff aushärten, begrenzen, welche Webserver-Prozesse Dolmetscher anrufen, Änderungen in der cron- und öffentlichen Dateistruktur steuern und eine Telemetrie aktivieren, die HTTP-Header-Analyse beinhaltet. Diese Maßnahmen verringern die Wahrscheinlichkeit, dass ein Cookie eine Hintertür wird.

Kurz gesagt, die Verwendung von Cookies als Kontrollkanal für Web-Shells spiegelt eine Entwicklung im Handwerk von Angreifern wider: Sie suchen legitime und scheinbar harmlose Möglichkeiten, Befehle zu verstecken und dauerhaften Zugriff zu erhalten. Defending erfordert nicht nur Patches und Aushärtung, sondern mehr Aufmerksamkeit, wie HTTP-Header verwaltet und aufgezeichnet werden und auf die vordere Linie der Administration: Anmeldeinformationen, cron und Control Panels. Um die Forschung und die Empfehlungen zu vertiefen, bleiben die Dokumentationen und Blogs von Sicherheitsanbietern und offiziellen Agenturen ein Muss; beginnend mit Bedrohungsanalyse-Repositorien und Good-Practice-Guide helfen, Aktionen zu priorisieren.

Quellen und zusätzliche Lesung: Microsofts Sicherheits-Blog enthält Forschung und Warnungen im Zusammenhang mit diesen Techniken ( Microsoft Security Blog), während Agenturen wie CISA und Frameworks wie MITRE ATT & CK kontext- und operative Beratung zur Erkennung und Minderung bieten.