Oder auch: The Sicherheitslücke strikes back. Im März machten Meldungen die Runde, dass eine Lücke im Plesk-Admin dazu genutzt werden konnte, um administrativen Zugriff auf das System zu erhalten. Wie sich jetzt zeigt hätte Plesk den Hinweis, doch man nach dem Einspielen des Patches alle Passwörter zu resetten, wesentlich plakativer auf die Seite schreiben sollen.
Wieso? Während wir uns vor kurzem noch darüber kaputt gelacht haben, dass LinkedIn Passwörter mit SHA1 ohne Salt verschlüsselt geht Plesk noch einen Schritt weiter, um es dem Angreifer möglichst einfach zu machen: Sie verschlüsseln die Passwörter erst gar nicht (bzw. erst seit Version 11). Wer also gedacht hat, dass das Problem mit dem Einspielen des Patches aus der Welt sei, weil eventuell gestohlene Passwörter ja erst geknackt werden müssten: Think again.
Besitzer von Plesk bis zur Version 10 können zur Beweisführung folgendes machen:
cat /etc/psa/.psa.shadow
präsentiert das Root-Passwort für die MySQL-Datenbank (das auch gleichzeitig das Admin-Passwort für Plesk ist) im Klartext. Und das ist nicht einmal ein Geheimnis, in der Plesk-KB wird genau das als Lösung beschrieben, sollte man mal sein Passwort vergessen haben!
Und auch sämtliche Passwörter für das Admin-Panel stehen unverschlüsselt in der Datenbank. Wer also einen Blick in psa – accounts wirft sollte sicherstellen, dass er sitzt.
Passwörter, die durch die Lücke im März gewonnen wurden, werden derzeit aktiv genutzt, um Webseiten zu kompromitieren. Aktuell wohl überall mit dem gleichen Schadcode, der in php, asp(x), html und js-Dateien eingefügt wird und bislang noch ziemlich eindeutig daran zu erkennen ist, dass er zwischen den Kommentaren /*km0ae9gr6m*/ und /*qhk6sa6g1c*/ eingeschlossen ist.
Da der Angriff über den Plesk-Admin stattfindet zeigen sich in den Logfiles der betroffenen Webauftritte keinerlei Auffälligkeiten. Die findet man aber in den Plesk-Access-Logs unter /usr/local/psa/admin/logs/ bzw. im Activity-Log, das man sich über die Plesk-Oberfläche laden kann. Aus letzterem geht auch hervor, mit welchem Benutzernamen zugegriffen wurde. Anders als bei UnmaskParasites aber vermutet gehe ich von automatisierten Angriffen aus, die Einträge im Log sind viel zu dicht beieinander als das da jemand manuell klicken würde.
Abhilfe
Nach meinem aktuellen Kentnisstand wird außer dem Einschleußen des Codes nichts weiter mit dem Server gemacht – obwohl man quasi alle Möglichkeiten hätte.
- Zunächst gilt es also, sofern noch nicht geschehen, den Patch einzuspielen.
- Danach durchsucht man den Server nach infizierten Dateien und säubert diese. Unter Linux kann man dazu grep und sed benutzen. Unter Windows wird man um eine Analyse des Plesk-Access-Logs nicht herumkommen.
- Abschließend setzt man alle Passwörter zurück. Von Plesk gibt es ein entsprechendes Script.
Zusätzlich kann man noch folgendes machen:
- Wer die Netze, von denen Zugriffe auf den Plesk-Admin erfolgen, klar definieren kann, kann den Zugriff auf dem Admin entsprechend einschränken: Einstellungen – Administratorzugriff einschränken.
- Den Plesk-Admin mit einem serverseitigen Passwortschutz versehen. Eine entsprechende Anleitung findet sich hier.