Und siehe da, eine Legacy-Site, die wir für einen Kunden gehostet haben, hatte eine Version von FCKEditor, die es jemandem ermöglichte, den gefürchteten c99madshell-Exploit auf unseren Webhost hochzuladen.
Ich bin kein großer Sicherheitsexperte – ehrlich gesagt bin ich nur ein Entwickler, der derzeit aufgrund eines Personalausfalls für S/A-Aufgaben verantwortlich ist. Dementsprechend wäre ich für jede Hilfe dankbar, die Sie als Server-Faulter bei der Einschätzung des Schadens durch den Exploit leisten könnten.
Um Ihnen ein paar Informationen zu geben:
Die Datei wurde in ein Verzeichnis innerhalb des Webroots hochgeladen: „/_img/fck_uploads/File/“. Der Apache-Benutzer und die Apache-Gruppe sind so eingeschränkt, dass sie sich nicht anmelden können und keine Berechtigungen außerhalb des Verzeichnisses haben, aus dem wir Websites bereitstellen.
Alle Dateien hatten 770 Berechtigungen (Benutzer rwx, Gruppe rwx, andere keine) – etwas, das ich beheben wollte, aber mir wurde gesagt, ich solle damit warten, da es keine „hohe Priorität“ habe (hoffentlich ändert sich das). Es scheint also, dass die Hacker das Skript problemlos hätten ausführen können.
Nun konnte ich c99madshell.php selbst nicht finden – nur ein paar andere HTML-Dateien mit russischem Text und ein paar .xl- und .html-Dateien mit Inline-PHP, die Versionen des Madshell-Hacks waren. Nach ein wenig Recherche sieht es jedoch so aus, als würde sich der Hack nach der Ausführung selbst zerstören – großartig.
Meine erste Einschätzung wäre jedenfalls folgende:
Es ist nicht erforderlich, den gesamten Host neu aufzubauen, da es aufgrund der Isolation des Apache-Benutzers/der Apache-Gruppe nicht möglich sein sollte, an Passwörter auf Systemebene zu gelangen.
Diese Sicherheitslücke muss behoben werden, indem Uploads so eingeschränkt werden, dass sie keine Ausführungsberechtigung haben. Die Version von FCKEditor muss aktualisiert werden, um das ursprüngliche Exploit-Ziel zu korrigieren. Außerdem muss eine Konfiguration auf Serverebene hinzugefügt werden, die die Ausführung von PHP-Skripten im Upload-Verzeichnis verhindert.
Ich sollte die DB-Passwörter für die App ändern – da die Konfigurationsdatei für die Datenbankverbindung im Web-Root liegt, hätte der Hacker sie höchstwahrscheinlich abgreifen können und damit auch das DB-Passwort.
Wie dem auch sei, bitte gebt mir euren Input dazu, was ich dem Boss sagen soll. Natürlich wäre es ideal, den Neuaufbau des gesamten Hosts zu vermeiden – aber wenn wir das tun müssen, um sicherzustellen, dass wir keine gehackte Maschine betreiben, dann ist es das, was wir tun müssen.
Ich bin wirklich dankbar für eure Hilfe. Zögert auch nicht, nach weiteren Informationen zu fragen (ich würde gerne Befehle ausführen bzw. mit euch zusammenarbeiten, um den Schaden einzuschätzen). Diese verdammten Hacker :(.
Antwort1
Wie andere bereits gesagt haben, wäre die offizielle „sichere“ Reaktion natürlich der Wiederaufbau der Maschine.
Die Realität der Situation könnte das verhindern. Sie können ein paar Dinge ausführen, um nach Kompromissen zu suchen:
- Chkrootkit- Tests auf allgemeine Anzeichen einer Gefährdung des Servers
- Wenn es sich um ein RPM-System handelt, prüft 'rpm -Va|grep 5' alle installierten RPM-Binärdateien und meldet eine „5“, wenn sich die MD5-Summe geändert hat. Ein Neuaufbau ist erforderlich, wenn Sie Inkonsistenzen finden, die nicht durch die angepasste Binärdatei erklärt werden.
- Suchen Sie in /tmp nach verdächtigen Objekten.
- Überprüfen Sie „ps fax“ auf abnormale Prozesse. Wenn „ps“ kompromittiert ist oder andere Techniken verwendet werden, könnten immer noch versteckte Prozesse ausgeführt werden.
- Wenn Sie bei Ihrer Suche IRGENDWELCHE Dateien gefunden haben, deren Eigentümer nicht Apache ist, wurden Ihre Systemkonten definitiv kompromittiert und müssen neu erstellt werden.
An Ihrer Systemkonfiguration vorzunehmende Korrekturen:
- Deaktivieren Sie Uploads durch FCKeditor, wenn möglich
- Stellen Sie sicher, dass Ihre temporären Verzeichnisse auf NOEXEC gesetzt sind, um zu verhindern, dass Programme von dort ausgeführt werden
- Alle PHP-Skripte sollten auf dem neuesten Stand sein
- Wenn Sie es etwas ausgefallener mögen, installieren Sie mod_security, um während der Laufzeit der PHP-Skripte nach Exploits Ausschau zu halten
Es gibt eine Menge Sachen, die ich auslasse, aber das wären die ersten Schritte, die ich unternehmen würde. Je nachdem, was Sie auf dem Server ausführen und wie wichtig dessen Sicherheit ist (wickeln Sie CC-Transaktionen ab?), kann ein Neuaufbau erforderlich sein, aber wenn es sich um einen Server mit „geringer Sicherheit“ handelt, reicht es möglicherweise aus, die oben genannten Punkte zu überprüfen.
Antwort2
Sie müssen den Host neu aufbauen. Sie wissen nicht, welche Art von Angriffen zur Rechteausweitung gegen den Host durchgeführt wurden, und Sie können auch nicht absolut sicher sein, dass keine Trojaner, Keylogger oder Rootkits installiert sind.
Wenn Sie einmal kompromittiert sind, gibt es keine andere Möglichkeit als einen Neuaufbau auf der Basis von Bare Metal.
Antwort3
Kurz gesagt - ich würde den Server neu aufbauen.
Wenn sie Zugriff auf einen lokalen Benutzer haben (jetzt hatten sie Zugriff als Apache-Benutzer), können sie lokale Exploits ausführen. Sie sollten also davon ausgehen, dass der gesamte Server kompromittiert ist. Sie sollten auch andere Server überprüfen.
Welche Distribution verwenden Sie? Wenn sie RPM-basiert ist, können Sie die Signaturen der Dateien überprüfen. Starten Sie die Installations-CD und führen Sie RPM -V aus, um die Pakete zu überprüfen.
Antwort4
Ich weiß, das ist nicht das, was Sie gerne hören würden, aber ich würde Ihnen wirklich empfehlen, die Daten zu sichern, den Server neu aufzubauen und alle Daten erneut zu importieren.
Überprüfen Sie auch andere Websites, um sicherzustellen, dass diese nicht die einzige ist, die vom Hack betroffen ist. Wenn alle Skripte Ihres Servers als ein Apache-Benutzer ausgeführt werden ( nodoby/ www_data/was auch immer Ihre Distribution verwendet), kann alles, was auf eine Site schreiben kann, mit ziemlicher Sicherheit auch auf die anderen schreiben.
Ändern Sie nicht nur alle Passwörter, sondern stellen Sie auch sicher, dass alle SSH-Schlüssel auf dem Server und auf allen anderen Servern ungültig gemacht werden (d. h. widerrufen Sie die öffentlichen Schlüssel, wo auch immer sie gespeichert sind, anstatt nur den privaten Schlüssel zu löschen) und dass die Passwörter auf allen anderen Systemen auf/über diesen Server geändert werden, für die Sie möglicherweise ein Passwort eingegeben haben (oder ein Passwort in einer Datei gespeichert haben).