Beispielanalyse von per Webshell hochgeladenen Rückverfolgbarkeitsereignissen

Inspektion und Inspektion

Zuallererst verstehe ich, dass ich nicht herausfinden muss, wo der hochgeladene Speicherort angezeigt wird. Ich muss mich beim Server anmelden, um eine WebShel-Inspektion durchzuführen und festzustellen, ob er angegriffen wurde von anderen. Es gibt Hintertüren und so weiter. Obwohl es sich bei der gemeldeten IP-Adresse um die IP-Adresse unseres Unternehmens handelt, was können wir tun, wenn der Server angegriffen wird, wenn einige Webshells übersehen und von anderen erfolgreich hochgeladen, aber nicht erkannt werden? Also ging ich hoch, um den Server zu inspizieren, lud dieses Webshell-Kill-Tool zum Töten hoch, benutzte netstat -anpt und iptables -L, um festzustellen, ob eine Hintertür eingerichtet war, überprüfte, ob ein Mining-Programm die CPU belegte usw., das werde ich tun Gehen Sie hier nicht auf Details ein. Glücklicherweise wurde der Server nicht kompromittiert und ich begann darüber nachzudenken, was mit diesem Upload-Punkt passiert ist.

Überprüfung der Sicherheitslücke beim Hochladen von Dateien

Zuerst fragte ich den Entwickler, der mich kontaktiert hatte, nach der Adresse dieses öffentlich zugänglichen Servers. Nachdem ich die Adresse erhalten hatte, stellte ich fest, dass die Adresse bekannt vorkam das, das ich vor nicht allzu langer Zeit getestet habe. Zu diesem Zeitpunkt war ich etwas verwirrt und konfrontierte den Entwickler mit den Berichtigungsinformationen. Nach dem letzten Test stellte ich fest, dass der Upload-Ort eine Whitelist-Einschränkung verwendet, die nur das Hochladen von JPEG, PNG und anderen Bildformaten erlaubt. Zu diesem Zeitpunkt stellte ich auch fest, dass der Upload-Pfad und der Dateiname zwar durch eine Whitelist eingeschränkt waren, dem hochgeladenen Dateinamen eine Zufallszahl hinzugefügt wurde und die Zeitregeln übereinstimmten war anders als andere. Es wurde vorgeschlagen, eine Berichtigung durchzuführen, da dies sonst dazu führen würde, dass die Datei Schwachstellen enthält. Er teilte mir mit, dass die Berichtigung tatsächlich durchgeführt wurde und der Pfad nicht mehr zurückgegeben wurde.

Umgehung der Dateisuffixkodierung

Nachdem ich die letzten behobenen Probleme besprochen und überprüft hatte, habe ich meine Meinung klargestellt. Dann habe ich mich auf der Website angemeldet, um den Grund zu überprüfen. Da es auf der Website nur einen Ort zum Hochladen von Bildern gibt, habe ich versucht, das Paket zu erfassen. Nachdem ich das Paket mit dem Repeater wiedergegeben hatte, stellte ich fest, dass das zurückgegebene Paket den Datei-Upload nicht zurückgab Dann habe ich verschiedene Umwege ausprobiert, aber das Ergebnis ist nicht gut. Am Ende konnte ich nach langem Überlegen keine Ergebnisse erzielen und fragte dann die Cloud-Plattform, was der Grund für den Alarm sei, der ihnen übermittelt wurde. Nachdem ich die Feedback-Ergebnisse der Cloud-Plattform gelesen hatte, stellte ich fest, dass dies kein großes Problem darstellt. Die hochgeladene Datei hat keine Ausführungsberechtigung und der Dateiname wurde nicht zufällig geändert. Aber warum wurde dieses JSP erfolgreich hochgeladen? Okay, das verwirrt mich.

Als ich mir die von der Cloud-Plattform bereitgestellten Webshel-Daten genau ansah, stellte ich fest, dass der Dateiname Base64-Codierung verwendet. Ich war sehr verwirrt darüber, warum ich ihn bereits codieren muss Funktion? Als ich es das letzte Mal getestet habe, war es keine Codierung. Plötzlich fiel mir der Schlüssel zum Problem ein, und dann verwendete ich das Decoder-Modul von burpsuite, um den Dateinamen „1.jsp“ mit Base64 in „MS5Kc1A=" zu kodieren, und sendete dann anstelle dieses Uploads einen erfolgreichen Feedback-Statuscode von 200 Fehler-Feedback-Statuscode von 500 Fehler.

Das Problem besteht also darin, dass die Forschungs- und Entwicklungsmitarbeiter während des Korrekturvorgangs die Base64-Kodierung für den Dateinamen verwendeten, was dazu führte, dass der Dateiname während des Speichervorgangs mit Base64 dekodiert wurde, und als ich die Datei hochlud, änderte ich auch die Suffix .jsp Mit dieser Base64-Kodierung wurde .jsp auch während des Speichervorgangs erfolgreich dekodiert. Die Forschung und Entwicklung hat nach der Dekodierung keine Whitelist-Einschränkungen eingeführt. Tatsächlich ist diese Art der Codierungsänderung unnötig. Schließlich wurde die Zufallszahl zum Ändern des Dateinamens verwendet, und das Codieren ist etwas überflüssig. Aus diesem Grund verursacht das Ändern eines Programmfehlers mehr Fehler.

Das obige ist der detaillierte Inhalt vonBeispielanalyse von per Webshell hochgeladenen Rückverfolgbarkeitsereignissen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!