☰

PHP eval(gzinflate(base64_decode(..)))-Hack – wie kann verhindert werden, dass das erneut passiert?

tag-icon • tag-icon security php hacking vulnerabilities
PHP eval(gzinflate(base64_decode(..)))-Hack – wie kann verhindert werden, dass das erneut passiert?

Kürzlich wurde eine unserer Websites gehackt. In die Datei index.php wurde PHP-Code eingeschleust, der ungefähr so ​​aussah:

Auswertung (gzinflate(base64_decode('s127ezsS/...bA236UA1')));

Der Code führte dazu, dass eine andere PHP-Datei (cnfg.php) eingebunden wurde, was zur Anzeige von pharmazeutischem Spam führte (der jedoch nur für Googlebot und andere sichtbar war). Das sieht aus wie der Pharma-Hack für WordPress, nur dass wir die besagte Software nicht verwenden. Der Code wurde inzwischen entfernt, aber ich möchte solche Vorkommnisse in Zukunft verhindern.

Mir ist bewusst, dass es sich hier um ein ziemlich weitreichendes Problem handelt und unzählige Sicherheitslücken dafür verantwortlich sein könnten, aber ich dachte, ich erwähne dies einfach mal für den Fall, dass jemand in der Vergangenheit bereits Erfahrungen mit einem solchen Problem gemacht hat.

Welche potenziellen Sicherheitslücken könnten das Hochladen dieser PHP-Dateien ermöglichen? Und was kann ich tun, um dies in Zukunft zu verhindern?

Prost

Antwort1

Sie müssen herausfinden, wie es dorthin gekommen ist.

  • Hatte der Angreifer über SFTP/SCP Zugriff auf das Dateisystem?
    • Wenn dies passiert ist, müssen Sie Ihre Fernzugriffsmethoden sperren
  • Hat der Angreifer ein Uploader-Skript oder einen Fehler in einem vorhandenen Skript verwendet, der es ihm ermöglichte, Dateien zu ändern?
    • Korrigieren Sie das Skript und ändern Sie die Berechtigungen für Ihre Skripte und Webinhalte, sodass der Webserverprozess sie nicht ändern kann. Der Webserver sollte darauf beschränkt sein, Dateien in einem Datenverzeichnis irgendwo zu ändern. Ihre Skripte und Dateien sollten im Allgemeinen nicht Eigentum des Webservers sein oder von diesem geschrieben werden können.
  • War das Skript Teil der von Ihnen installierten Schadsoftware?
    • Ich habe solche Dinge schon als Teil von WordPress-Vorlagen gesehen. Ein ahnungsloser Benutzer hat Vorlagen von einer beliebigen Website heruntergeladen. Diese Vorlagen enthielten eine Funktion zum Ausführen von Code von einem externen Webserver. In Kombination mit schlechten Berechtigungseinstellungen ermöglichte dies dem Angreifer, andere Dinge zu ändern.

Antwort2

Nur eine Warnung.

Wenn Sie FileZilla als Ihren FTP-Client verwenden, gibt es Malware, die Ihre FTP-Anmeldeinformationen aus der Filezilla-KLARTEXTDATEI (huch!) abgreift und diese Informationen verwendet, um Malware-Code (gekennzeichnet durch den Codetyp #b58b6f# um einen „gzinflate(base64_decode)“-Befehl herum einzufügen. Auf diese Weise werden Ihre Dateien angegriffen/kompromittiert.

Schauen Sie in Ihrem Ordner %APPDATA%/Roaming/Filezilla nach. Eine der XML-Dateien dort enthält alle Ihre FTP-Website-Anmeldeinformationen (Benutzer/Passwort/usw.) im KLARTEXT! Und die Leute von FileZilla weigern sich, diese offensichtliche Sicherheitslücke zu schließen.

Meine Empfehlung: Löschen Sie FileZilla von Ihrem Computer (und Sie müssen den Ordner in Ihrem APPDATA-Ordner manuell löschen).

Wenn Sie einen sicheren FTP-Client benötigen, verwenden Sie WinSCP (www.winscp.net). Dort können Sie ein Hauptkennwort festlegen und alle Ihre Site-Anmeldeinformationen werden verschlüsselt.

Nur eine Warnung... Rick... J

Antwort3

Es gibt eine Vielzahl von Möglichkeiten, wie dies eingedrungen sein könnte. Eine Information, die dabei hilft, dies einzugrenzen, ist, welche Art von Hosting Sie haben (Shared, Dedicated, Virtual) und wer Ihr Host ist. Einige mögliche Einstiegspunkte sind

  • Kompromittierung des Administratorkontos
  • Kompromiss ausdeinFTP-/SSH-/Webkonsolen-/usw.-Konto bei Ihrem Anbieter. Wenn Sie Ihr Passwort jemals über ein unverschlüsseltes Protokoll (wie FTP) senden, hören Sie damit auf.
  • Kompromiss ausdeineigene lokale Entwicklungsmaschine
  • Die Sicherheitslücke liegt in der Serversoftware auf dem Server, beispielsweise Apache oder einem seiner Module.

  • Sicherheitslücke auf Anwendungsebene im PHP Ihrer Site:

    • Verwenden Sie Software von Drittanbietern und ist diese ggf. auf dem neuesten Stand?
    • Haben Sie einen erheblichen Teil Ihrer eigenen Programmierung auf der Site geschrieben? Wenn ja, gibt es eine Million Möglichkeiten, wie Sie eine Lücke geschrieben haben könnten. Überprüfen Sie alle Methoden, die Daten berühren, die aus Benutzereingaben stammen (REQUEST/GET/POST/COOKIES/FILES). Wenn Sie Datei-Uploads zulassen, speichern Sie diese Dateien ungefiltert in einem webseitig sichtbaren Verzeichnis? Wenn ja, könnte jemand ein PHP-Skript hochladen und es dann einfach anzeigen. Include/Require-Anweisungen sind besonders beliebte Ziele, wenn Sie eine Template-Lösung wie die folgende verwenden:

    <?php include $_GET['page'] . '.php'; ?>

Wie kann man ein erneutes Auftreten verhindern?

  • Stellen Sie sicher, dass Sie der Sicherheit Ihres Hosts absolut vertrauen. Rufen Sie ihn an und befragen Sie ihn zu seinen Sicherheitsrichtlinien, wie schnell er seine Dienste patcht, wenn Schwachstellen auftauchen usw.
  • Verzichten Sie auf billiges Shared Hosting und zahlen Sie für dediziertes oder virtuelles Hosting. Weniger Leute, die den Server nutzen, bedeuten weniger Angriffspunkte.
  • Halten Sie Ihre eigenen Anwendungen/Bibliotheken von Drittanbietern auf dem neuesten Stand. Tragen Sie sich in deren Mailingliste, RSS-Feeds oder andere Dienste ein, um über deren Veröffentlichungen auf dem Laufenden zu bleiben.
  • Überprüfen Sie Ihren eigenen Code. Wenn Sie dazu nicht genug Erfahrung haben, suchen Sie sich jemanden, der Sie dafür bezahlt.
  • Behalten Sie Ihre Site in einer Versionskontrolle wie Git oder Subversion. Behalten Sie Ihr Produktionsverzeichnis als Arbeitskopie, damit Sie Änderungen an Ihrer Codebasis leicht erkennen können (aber stellen Sie sicher, dass Sie den Zugriff auf Metadaten wie .git- und .svn-Verzeichnisse blockieren).

Antwort4

Vielleicht möchten Sie versuchenhttp://www.hardened-php.net/suhosin/Dies hätte unter anderem eval() deaktivieren können. Wenn cnfg.php remote gehostet wurde, hätte dies möglicherweise auch die Einbindung verhindert.

Gewähren Sie dem Benutzer, unter dem der Webserver läuft, möglichst keinen Schreibzugriff auf die PHP-Dateien.

verwandte Informationen