8:00 Uhr
Ich schaue mir wie immer morgens die Serverstatistik an. Das Programm Cacti bereitet mir vielfältige Daten als Diagramm auf. So zum Beispiel auch die CPU-Last einer Maschine. In CPU-Last-Diagramm eines Servers ist direkt um Mitternacht herum eine extreme Lastspitze zu sehen:
Das ist seltsam.
8:05 Uhr
Ich logge mich per SSH auf den Server ein und nehme mir die Logdateien vor. Gleich in der ersten stoße ich auf eine weitere Spur. In im „Slow-Query“-Log von MySQL sind SQL-Abfragen zu sehen, die nur langsam abgearbeitet werden konnten. Just um Mitternacht wurden einige Abfragen an die Datenbank geschickt, die den MySQL-Befehl „BENCHMARK()“ enthalten. Auch das ist seltsam, denn diesen Befehl verwendet man eigentlich nur, um Leistungsdaten des Servers zu ermitteln. Sendet man diesen Befehl exzessiv, könnte man den Server mit einer Denial-of-Service-Attacke außer Gefecht zu setzen.
8:15 Uhr
Zunächst suche ich die Web-Software, die auf dem Server läuft, nach einem Skript ab, das diesen MySQL-Befehl nutzt – Fehlanzeige. Das ist alarmierend, denn zur fraglichen Zeit war niemand auf dem Server eingeloggt. Das bedeutet, dass jemand per SQL-Injection über ein WordPress-Skript selbst gebaute SQL-Abfragen an die Datenbank schicken kann, was ein großes Sicherheitsrisiko ist, um es noch vorsichtig auszudrücken.
8:25 Uhr
Auf dem Server läuft WordPress 2.1.3. Die 2.2er-Version läufit nicht, denn ständig auf die neueste Version zu aktualisieren ist ein großer Kostenfaktor, besonders wenn das Weblog gut besucht ist und ständig unter Strom steht. Außerdem sollen die Zweige 2.0 und 2.1 neben der aktuellen Version 2.2 weitergepflegt werden. Auf http://wordpress.org/download/release-archive/ steht:
„… the latest in the 2.0 or 2.1 series … are both actively maintained.“
Kürzlich wurde in der Version 2.2 eine SQL-Injection-Lücke entdeckt. Das betraf aber nur Code, der mit Version 2.2 eingeführt wurde. Sollte es sich um eine neue Lücke in Version 2.1.3 handeln? Ich war zunächst etwas ratlos und recherchierte weiter im Web.
8:40 Uhr
Auf SecurityFocus.com suche ich nach Lücken speziell zu WordPress 2.1.3. Dort sehe ich unter anderem eine SQL-Injection-Lücke vom Mai 2007. Die Lücke ist also schon über einen Monat alt und es gibt keinen Patch! Ich traue meinen Augen nicht. Die Beschreibung verrät, dass über das Skript /wp-admin/admin-ajax.php JEDER SQL-Abfragen an die Datenbank schicken kann. Man muss nichtmal eingeloggt sein. In der Version 2.2 ist der Fehler behoben. Der Entdecker der Lücke liefert zum Glück ein Beispielskript mit, das die Lücke demonstriert. Ist dieses Exploit-Skript erfolgreich, soll es den Kennwort-Hash des WordPress-Administrators liefern, was bei einem weiteren Angriff auf den Server eine große Hilfe für Cracker wäre.
8:50 Uhr
Ich lade mir das Skript runter, schaue es mir an und modifiziere es so, dass es läuft. Dabei sehe ich, dass der Angreifer wohl genau dieses Skript für den Angriff auf „meinen“ Server genutzt hat, denn der erwähnte „BENCHMARK()“-Befehl ist zu sehen und auch sonst ähneln die erzeuten SQL-Befehle sehr stark denen, die ich im Sloq-Queries-Log gefunden hatte.
9:00 Uhr
Ich lasse den Exploit laufen. Zum Glück ist das Skript nicht erfolgreich. Ich greife meine eigenen WordPress-Installationen an und schaue, was passiert. Nichts – eine gute Nachricht.
9:30 Uhr
Ich frage mich, was man nun tun kann, um diese Lücke zu schließen. Eine Aktualisierung auf 2.2 kommt eigentlich nicht in Frage. Ich betreue sechs WordPressen, die teilweise mehrere Millionen Hits pro Tag haben, da kann man nicht mal eben während des Betriebs an der Software herumfummeln. Außerdem werden die Funktionen von WordPress 2.2 nicht vermisst.
Die Lücke selbst schließen wäre eine Möglichkeit. Ich verwerfe sie allerdings nach einem automatischen Vergleich des 2.1.3-Codes mit der Version 2.2. Die Unterschiede sind zu groß, als dass man eine Art schnellen Backport machen könnte. Möglich wäre das schon. Aber mir ist das Risiko, damit Stunden zu verbringen zu groß und außerdem habe ich keine echte Möglichkeit, die Wirksamkeit des Backport-Patches zu testen, denn der originale Exploit schlug ja schon fehl. Dazu kommt noch, dass die Datei /wp-admin/admin-ajax.php in beiden Versionen gleich ist (oder wars nahezu gleich?), so dass man erstmal herausfinden muss, um welche Stellen man sich überhaupt kümmern muss. Das kommt also auch nicht in Frage.
Eine andere, etwas weniger elegante Möglichkeit wäre es, für das Verzeichnis /wp-admin eine HTTP-Auth-Abfrage per htaccess einzubauen, damit admin-ajax.php nicht von jedem aufgerufen werden kann. Der Nachteil ist dabei, dass alle WordPress-Autoren sich quasi doppelt einloggen müssen – einmal per HTTP-Auth und einmal in WordPress selbst. Aber diese Absicherung ist innerhalb weniger Minuten in alle Installationen eingebaut, erledigt den Job und ist schön günstig.
11:00 Uhr
Nachdem alle betroffenen WordPress-Nutzer informiert und einverstanden sind, baue ich die Abfragen ein. Das lässt alle wieder ruhig schlafen.
17 Antworten zu „Ein Vormittag im Leben eines SysAdmins“
— was ist Deine Meinung?
Wäre doch mal interessant zu wissen, wie 1 Jahr später der Tag des Sys-Admins ausschaut. Hat sich da was verändert? Ins negative oder positive? 🙂
Ich frage mich :
Wie kann ein Serveradmin dann mal in die Ferien gehen ?
Holt man sich dann einen kompetenten Kollegen der die Server betreut, oder fährt die Angst mit in die Ferien ?
Interessanter Artikel.
Tja leider ist man als Serveradmin immer der Böse! Echt undankbar. In einem Moment sagen sie: Ja ist echt toll geworden – oder – Läuft ja super
Aber wehe es geht ma 5 Minuten nichts…
Vielen Dank für den netten Artikel. (Boshafterweise) Beruhigend zu sehen, dass es auch anderen so geht.
Der Artikel zeigt auch leicht verständlich, dass es nicht reicht wordpress* schnell selbst zu installieren, es dann aber nicht administrieren zu können. Meines erachtens eine negative Seite von komfortablen Installationsprogrammen.
@mi-o-o-im: Von solch einer Lösung (englisch: security by obscurity – Sicherheit durch Unverständlichkeit/Verschleierung) kann ich nur abraten. Man wiegt sich damit selbst in Sicherheit, während halbwegs versierte Angreifer die Sicherheitslücke weiter zur Verfügung steht. Sie werden dabei keine so leicht erkennbare Spuren hinterlassen.
* bitte durch eine beliebige andere Software ersetzen
Netter Artikel. Eigentlich schade, dass man ständig auf der Hut vor Sicherheitslöchern sein muss. Gerade die bekannteren CMS bieten da natürlich eine große, vermutlich lohnende Angriffsfläche im Web.
nicht schlecht, soein SysAdmin-Leben,
um 11.00 Uhr ist Feierabend 😉
aber interessanter Artikel, Danke
@Anes Sabitovic
Das möchte ich stark bezweifeln.
Mein Part verlief heute nicht so toll. Ein Server _wurde_ gehackt.
Kann ich bestätigen. Ist echt der Horror. Wenn wochenlang alles läuft, dann hört man nichts von den Leuten. Bei den kleinsten Ausfällen rasselt es an Beschwerden.
Ist echt ein undankbarer Job…
Matthias
Da bin ich nur froh, nicht Deinen Job zu haben. Das Web ist einfach zu unsicher.
Ich wollte auch nicht in einem Haus wohnen und wissen, dass da gestern „einer“ eingebrochen ist und ich weiß nicht wie und wo und ob der wiederkommt…
Aber wahrscheinlich der ganz normale Adminhorror.
LG.
@mi.o-o-im
Das sollte gehen. Wenn in der Datenbank Links in diesen Ordner weisen, müsste man auch dort entsprechend suchen und ersetzen.
Etwas ähnliches habe ich mit dem WP-Kommentarskript gemacht, seitdem kommt (im Vergleich zu vorher) fast kein Kommentarspam mehr rein.
Angreifbar ist man dann nur noch für Leute, die sich vor Handarbeit nicht fürchten, aber den automatisierten Angriffen kann man zum guten Teil aus dem Weg gehen.
BTW das Bild zeigt nicht die angesprochene Lastspitze, das nur zur Erklärung. 🙂
Mir kam gerade folgender Gedanke (vielleicht nicht ausgereift genug):
Was ist wenn ich die URL unter der der Adminbereich erreichbar ist verändere?
Also statt „/wp-admin/“ dann „/schlagmichtot/“ und mit Hilfe von sed alle Vorkommen in den Dateien von „/wp-admin/“ durch „/schlagmichtot/“ ersetzen. Müsste doch auch klappen.
@iKA: Die Installationen sind aus Lastgründen auf mehrere Server verteilt. Derzeit ist das noch günstiger als einen Serververbund zu administrieren.
… und ich frage mich nur, warum der Admin einzelne WordPressinstallationen verwendet und nicht eine einzige die von allen verwendet werden kann und per Script aktualisiert wird, naja, sonst aber ein netter Artikel. 🙂
Sehr nett geschrieben 🙂 Fast schon wie der BAFH 😀
Hallo,
Dein Bericht zeigt eindeutig, dass es im Netz böse Menschen gibt. Wer sonst sollte die dr.web.de Seite eingreifen. Die ist die beste Quelle für alle Webworker.
Weiter aufpassen!