Analyse unsicherer Dekomprimierungs-GetShell-Instanzen, die durch Rückverfolgbarkeit entdeckt wurden

Als wir kürzlich einem Kunden dabei halfen, einen Einbruchsvorfall aufzuspüren, stellten wir fest, dass der Hacker die „ZIP-Dekomprimierungsfunktion“ der Website nutzte, um eine Webshell hochzuladen, bevor er Zugriff auf den Server erhielt. Da diese Methode zur Ausnutzung von Lecks im Hinblick auf die „Angriffsnutzlaststruktur“ und den „tatsächlichen Dekomprimierungspfad“ relativ repräsentativ ist und die Branche der Schwachstelle „unsichere Dekomprimierung“ immer noch nicht genügend Aufmerksamkeit schenkt. Aus diesem Grund haben wir diesen Bericht geschrieben, in dem wir den Prozess der Intrusion Tracing und Schwachstellenerkennung erläutern und einige Sicherheitsvorschläge aus den beiden Dimensionen Sicherheitsentwicklung und Sicherheitsschutzlösungen für Hundeprodukte vorlegen, in der Hoffnung, der Branche davon zu helfen.

Es ist erwähnenswert, dass das CMS zwar entsprechende Verteidigungskonfigurationen vorgenommen hat, die JSP-Datei jedoch nicht ausgeführt wird, wenn Sie sie direkt in das Stammverzeichnis des CMS schreiben, und ein 403-Fehler gemeldet wird. Der Angreifer nutzte die automatische Bereitstellungsfunktion des Kriegspakets und nutzte die Idee des „Verzeichnisdurchlaufs“, um das Kriegspaket aus dem Stammverzeichnis des CMS herausspringen zu lassen.

1. Rückverfolgbarkeit von Einbrüchen

Das Betriebs- und Wartungspersonal eines Unternehmens entdeckte während seines Einsatzes spät in der Nacht bestimmte Anomalien im System. Um das Problem so schnell wie möglich zu untersuchen, kontaktierte es das Haiqing-Labor intervenierte, um die Rückverfolgbarkeit und Analyse der Quelle durchzuführen und anschließende Entsorgungspläne bereitzustellen.

Durch die Überprüfung der Tomcat-Protokolldatei /logs/localhost_access_log.yyyy-MM-dd.txt können wir feststellen, dass der Angreifer die Anmeldeschnittstelle der Website („POST /cmscp/login.do“) gesprengt hat. Die Zugriffshäufigkeit der (Schnittstelle ist sehr hoch), wie in der Abbildung dargestellt.

Hinweis: Der HTTP-Statuscode bei erfolgreichem Blast ist 302 und der HTTP-Statuscode bei fehlgeschlagenem Blast ist 303.

Um festzustellen, ob der Angreifer einen Website-Trojaner hochgeladen hat, scannen Sie mit der Webshell-KI-Erkennungs-Engine von Website Security Dog das Webapps-Verzeichnis von Tomcat. Es kann festgestellt werden, dass die Datei „/admin/login.jsp“ lautet als Webshell erkannt (der Hacker hat dies getan). Die Benennung einer Webshell ist etwas verwirrend, wie in der Abbildung gezeigt.

Nach weiterer manueller Bestätigung kann festgestellt werden, dass es sich bei der JSP-Datei tatsächlich um eine Webshell handelt. Und es hängt mit der automatischen Bereitstellung der Datei admin.war zusammen, wie in der Abbildung gezeigt.

Wie wird dieses Kriegspaket auf den Server hochgeladen? Analysieren Sie weiterhin die Protokolldateien und konzentrieren Sie sich bei der Analyse auf die „Schnittstelle, bei der es sich möglicherweise um eine Datei-Upload-Funktion handelt“. Es kann vorläufig festgestellt werden, dass der Hacker die Funktionen ZIP-Upload und ZIP-Dekomprimierung verwendet hat, bevor er diese Webshell verwendet hat, wie im Bild gezeigt.

Suchen Sie die Datei test5.zip, die von der Dateidekomprimierungsschnittstelle auf dem Server aufgerufen wird. Nach der Analyse können Sie feststellen, dass der Pfad, in dem sich admin.war befindet, „test5.zip…“ ist. Daher handelt es sich bei der ZIP-Datei um eine schädliche Datei, die sorgfältig von Hackern erstellt wurde. Dadurch wird der Dekomprimierungspfad des Kriegspakets nicht mehr zum Standardverzeichnis „/uploads/1“, sondern zum Verzeichnis „webapps“ von Tomcat, wie in der Abbildung dargestellt.

Hinweis: So generieren Sie die schädliche Zip-Datei in diesem Artikel

(1) Führen Sie das folgende Python-Skript aus, um test5.zip zu generieren:

import zipfile if __name__ == "__main__": try:binary = b'<script>alert("helloworld")</script>'zipFile = zipfile.ZipFile("test5.zip", "a", zipfile.ZIP_DEFLATED) info = zipfile.ZipInfo("test5.zip")zipFile.writestr("../../../safedog.html", binary)zipFile.close()except IOError as e: raise e

(2) Ziehen Sie das War-Paket mit Webshell nach „test5.zip“. “, wie in der Abbildung gezeigt.

2. Code-Audit

Durch die vorherige Intrusion-Traceability-Analyse kann vorläufig der Schluss gezogen werden, dass dieser Angriff mit der „ZIP-Dekomprimierungsschnittstelle“ des CMS zusammenhängt (GET /cmscp/core/web_file_2/unzip .do?ids= {ids}&parentId={parentId}) sind eng miteinander verbunden. Diese Schnittstelle entspricht der Unzip-Methode von WebFileUploadsController.java, wie in der Abbildung gezeigt.

Verfolgen Sie die Methode zum Entpacken und stellen Sie fest, dass sich die spezifische Implementierung in WebFileControllerAbtractor.java befindet. Es ist ersichtlich, dass beim Dekomprimieren der ZIP-Datei die Unzip-Methode der AntZipUtil-Klasse aufgerufen wird, wie in der Abbildung gezeigt.

Wenn wir die unzip-Methode der AntZipUtil-Klasse weiterverfolgen, können wir feststellen, dass

diese Methode keine Parameterüberprüfung durchführt

für den Dateinamen im ZIP-komprimierten Paket, bevor die Datei geschrieben wird. Das Schreiben eines solchen Codes führt zu einer Sicherheitslücke beim Durchlaufen von Verzeichnissen, wie in der Abbildung gezeigt.

Derzeit hat Haiqing Lab die Schwachstelle an CNVD gemeldet und den Hersteller aufgefordert, die Schwachstelle zu beheben.

3. Zusammenfassung

Anhand dieses Beispiels können wir feststellen, dass die Sicherheit der Dekomprimierungsfunktion der Website-Sicherheit großen Schaden zufügen kann (nehmen Sie als Beispiel die Spring Integration Zip-Entwicklungskomponente, die auch CVE-2018 ausgesetzt war). -1261 „Unsichere Dekomprimierungsschwachstelle“). Wenn das Geschäft der Website Dekomprimierungsfunktionen umfasst, wird empfohlen, der Dimension der Sicherheitsentwicklung mehr Aufmerksamkeit zu schenken. Darüber hinaus bietet Safe Dog auch entsprechende Produktverteidigungslösungen an.

Im Hinblick auf die Sicherheitsentwicklung wird empfohlen, dass Entwickler bei der Implementierung des Dekomprimierungsalgorithmus eine Selbstprüfung und Einschränkungen hinsichtlich der folgenden Aspekte durchführen:

(1) Ob die Erweiterung von Dateien im komprimierten Paket begrenzt werden soll

Zum Beispiel : .war, .jsp, jspx, .jsp::$DATA (betrifft nur Windows-Hosts)

(2) Ob der tatsächliche Dekomprimierungspfad der Dateien im komprimierten Paket begrenzt werden soll

(3) Ob die Gesamtmenge begrenzt werden soll Größe der Dateien im komprimierten Paket (bei komprimierten Paketen **Denial-of-Service-Angriff verursacht durch)

(4) Ob dem Webanwendungsverzeichnis angemessene Berechtigungen gewährt werden sollen

Darüber hinaus empfehlen wir Benutzern auch, zuverlässig zu wählen und professionelle Sicherheitsprodukte, wie zum Beispiel Benutzer, die Sicherheitshundeprodukte installiert haben. Sobald ein Sicherheitsvorfall auftritt, erhalten Sie automatisch eine Alarm-SMS vom System, um so schnell wie möglich einzugreifen, um größere Verluste zu vermeiden.

Im Hinblick auf „Safe Dog Product Defense“ wird Benutzern empfohlen, den Website-Hintergrundschutz von „Website Security Dog“ und „Yunyu“ sowie die Dateiverzeichnisschutzfunktionen von Server Dog und das Web-Backend zu verwenden von Yunyu und Website Safety Dog Die Pfadschutzfunktion kann vor Brute-Force-Verhalten im Hintergrund der Website schützen.

Die Hintergrundschutzfunktion von Yunyu ist wie im Bild gezeigt:

Die Hintergrundschutzfunktion von Website Security Dog ​​ist wie im Bild gezeigt:

Serverordner-Verzeichnisschutzfunktion:

Das obige ist der detaillierte Inhalt vonAnalyse unsicherer Dekomprimierungs-GetShell-Instanzen, die durch Rückverfolgbarkeit entdeckt wurden. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!