Auf der Suche nach einem sicheren Hoster schlägt sich Hacker Dirk P. bei fünf weiteren Firmen durch. Er erforscht deren Datendickicht und sieht sich in jedem Fall von seinen Entdeckungen enttäuscht. Statt eine Lichtung mit sauber administrierten Rechnern zu finden, wird er sogar selbst das Ziel eines Angriffs.

In meinen ersten beiden Artikeln ([1],[2]) berichtete ich über die gravierenden Sicherheitsmängel bei einem größeren deutschen Webhoster. Offenbar sind einige Admins nicht nur in der Lage, ihr System stümperhaft zu konfigurieren, obendrein ignorieren sie konkrete Hinweise auf Sicherheitslücken. Durch diese Erkenntnis aufgeschreckt nahm ich auch die Provider meiner anderen Domains genauer ins Visier.

In zwei Fällen wollte ich nur Domainnamen registrieren, aber keinen Webspace belegen. Es sollte billig sein, und genau das bekommen die Kunden für ihr Geld auch. Der erste Billiganbieter ist, der privaten Homepage des Geschäftsführers nach zu urteilen, ein Feierabendprojekt. Der Chef hat einen Root-Server mit installiertem Confixx gemietet und losgelegt. Der Einstieg ins Hosting-Geschäft ist tatsächlich so einfach, aber die Sicherheit bleibt dabei auf der Strecke.

01 /usr/share/webmin/changepass.pl /etc/webmin admin zgrb4320ad57
02 /usr/share/webmin/changepass.pl /etc/webmin root zgrb4320ad57

Verkauft und verloren

Ich musste nicht lange suchen. Die Setup-Dateien der MySQL-Datenbanken enthalten das Datenbank-Root-Passwort im Klartext. Es steht auch in der Confixx-Konfigurationsdatei, beide Files sind unnötigerweise für alle Benutzer lesbar. Nach einer kurzen E-Mail an den Support prüfte ich den Status erneut: Eine der beiden Schwachstellen war behoben, die andere bestand weiter. Außerdem hielt es der Hoster nicht für nötig, das Passwort zu ändern. Ich habe also weiterhin vollen administrativen Zugriff auf seine Confixx-Datenbank.

Der zweite Anbieter macht es nicht besser. Die Firma vertreibt eigentlich Windows-Hosting, hat vor einiger Zeit aber einen insolventen Linux-Hoster aufgekauft. Das zugehörige Know-how war offenbar nicht Teil des Deals. Auf den Linux-Maschinen ist Confixx in einer verwundbaren Version 2.0 installiert. Ich versuchte es mit der längst bekannten Backup-Sicherheitslücke[1] und erhielt prompt ein Tarfile von »/root«. Beim Durchstöbern der Datei ».bash_history« fielen mir einige sehr interessante Einträge auf (Listing 1).

Einladung zum Einbruch

Das Root-Passwort im Klartext – einfacher hätten mir die Admins das Eindringen ins System kaum machen können. Klar, dass ich der Einladung folge. Passwörter haben direkt auf der Kommandozeile nichts zu suchen, da Programmparameter standardmäßig für alle Benutzer lesbar sind. Solange der Prozess läuft, sieht jeder lokale Angreifer diese heiklen Informationen. Noch gravierender ist das dauerhafte Speichern in der History. Der Aufwand, den das System treibt, um das Passwort in »/etc/shadow« zu verschlüsseln, wird damit nutzlos.

Auch beim Passwort selbst haben sich die Admins kräftig verschätzt. Es ist noch im alten DES-Verfahren verschlüsselt und besitzt daher nur acht signifikante Stellen. Ein Login gelingt auch mit »zgrb4320«, die vier angehängten Buchstaben sind irrelevant. Hier empfiehlt sich der Umstieg auf MD5. Diese Technik erlaubt längere Passwörter und sollte daher auf allen Systemen Standard sein. Zudem sind MD5-Passwörter selbst bei gleicher Länge schwerer zu knacken. John the Ripper[3] testet auf einem modernen PC einige tausend MD5-Passwörter pro Sekunde, bei DES sind es einige hunderttausend.

Die Confixx-Lücke war lange bekannt, daher entschied ich mich für eine bissige Form der Therapie. Ich hinterließ in »/root« eine Datei mit dem prägnanten Namen »Hallo Root :->« und in »/« eine Bash mit gesetztem Set-UID-Bit auf Root. Danach sandte ich die in Listing 2 abgedruckte E-Mail an den Support.

Offene Hintertür

Meine Root-Shell hätte ich kaum noch auffälliger platzieren können, sie trug den Namen »root-shell«. Bei einem verantwortungsbewussten Admin dürfte sie nur einige Stunden überdauern, maximal bis zum nächsten Morgen. Laut »last root« hat sich aber niemand als Root eingeloggt, sodass ich ein paar Tage später erneut eine Erinnerungs-Mail schrieb. Erst geraume Zeit später meldete sich Root auf dem Server an. Seine Aktionen nahm ich mit einem sarkastischen Lachen zur Kenntnis – Listing 3 zeigt warum.

Offensichtlich hat der Admin ein »ls -la« im Wurzelverzeichnis abgesetzt, die Datei »root-shell« prompt übersehen und sich erst mal wieder ausgeloggt. Dass Root anschließend sein Passwort ändert, wirkt dann unfreiwillig komisch. Aus Sicherheitsgründen entfernte ich meine Root-Shell wieder.

Update-Schlamperei

Ein weiterer Webhoster – der dritte auf meiner Liste – hat bei den Sicherheitsupdates seiner Webserver geschlampt. Ich wurde beim Besuch einer von mir betreuten Website misstrauisch, als mein Browser eine Javascript-Fehlermeldung produzierte. Es stellte sich heraus, dass jemand meine Seiten manipuliert hatte. Offensichtlich wollte ein Cracker Sicherheitslücken in den Browsern der Besucher nutzen.

Die Ursache war schnell gefunden: Auf dem Server lief ein verwundbarer Apache 2.0.49, obwohl es mit 2.0.50, 51 und 52 gleich drei Updates gibt. Im Apache-Changelog[7] alarmiert eine ganze Reihe von »SECURITY«-Einträge jeden guten Admin, dass ein Update dringend angeraten wäre. Doch ganze drei Monate passiert bei diesem Hoster nichts, erst meine Beschwerde an den Support bringt ihn auf Trab.

Dicke Fische

Auch die großen Spieler im Hosting-Wettkampf – einer ist mein Kandidat vier – administrieren nicht immer sorgfältig. Glücklicherweise fand ich auf meiner Jagd bislang keine Sicherheitsfehler, aber ich darf mehr Leistungen in Anspruch nehmen, als ich bezahle.

Neben CGI-Skripten[1] nutze ich auch Cronjobs kostenlos, allerdings wird meine Crontab immer wieder gelöscht. Ich ging der Sache auf den Grund und stellte fest, dass sie nachts um 04:46 verschwindet. Kunden, die dafür bezahlen, richten ihre Cronjobs über ein Webinterface ein. Aus den hinterlegten Daten werden nachts die Crontabs neu erzeugt. Da es für meinen Account keine Config-Daten gibt, verschwindet meine Crontab.

Mit einer einfachen Idee gelang es mir aber, diesen Vorgang zu überstehen. Einer meiner Cronjobs startet eine Minute vor dem Generieren der Crontabs und führt folgendes Kommando aus:

sleep 60; crontab ~/etc/crontab

So re-installiert sich meine Crontab selbstständig. Der Provider könnte dies einfach unterbinden, wenn er »cron. allow« und »cron.deny« mit Benutzernamen füllen würde.

Profi gesucht

Bisher habe ich keinen Provider gefunden, der durchgängig vernünftig administriert. Mehr Leistung erhalten als bezahlen, das klingt zwar zunächst ganz gut, aber es spricht nicht für Professionalität. Ich wollte daher erst mal von den auffälligsten Providern weg. In der Webhoster-Liste[4] hielt ich Ausschau nach einem neuen Anbieter, Nummer fünf in meiner Datenreise.

Neben der detaillierten Suche in der Providerdatenbank interessierten mich die Bewertungen anderer Benutzer. Eine sicherheitstechnische Beurteilung kann ich hier aber nicht erwarten. Ich entschied mich daher für einen Webhoster, dessen Support sehr gute Noten erhält. Der Support spiegelt hoffentlich auch die Qualität der Administration und somit die Sicherheit wider.

01 Bitte folgen sie dieser Anleitung :->
02 
03 ssh root@server16.xxxxxx.com
04 ls -l /root
05 ls -l /
06 
07 *staunen*
08 *Panik bekommen*
09 
10 Zum Kiosk gehen und aktuelles Linux-Magzin kaufen.
11 Seite 56 aufschlagen und lesen.
12 [Anmerkung: Das bezieht sich auf den ersten Artikel in 10/04]
13 
14 ---------- ls -l / ----------
15 -rw-r--r--    1 root     root       481247 Apr 15  2004 System.map
16 drwxr-xr-x    2 root     root         4096 Dec  5  2003 bin
17 drwxr-xr-x    2 root     sys          4096 Apr 15  2004 boot
18 drwxr-xr-x    2 root     root         4096 Jul 25  2003 cdrom
19 drwxr-xr-x    9 root     root        24576 May 13 11:19 dev
20 drwxr-xr-x   51 root     root         4096 Oct  1 00:18 etc
21 drwxr-xr-x    2 root     root         4096 Jul 25  2003 floppy
22 drwxrwsr-x   16 root     staff        4096 Apr 11  2004 home
23 drwxr-xr-x    2 root     root         4096 Jul 25  2003 initrd
24 drwxr-xr-x    5 root     root         4096 Dec  5  2003 lib
25 drwx------    2 root     root        16384 Jul 25  2003 lost+found
26 drwxr-xr-x    2 root     root         4096 Feb  8  2002 mnt
27 drwxr-xr-x    2 root     root         4096 Jul 25  2003 opt
28 dr-xr-xr-x   84 root     root            0 May 13 11:18 proc
29 -rw-------    1 root     root      2097120 May 12 18:20 quota.group
30 -rw-------    1 root     root      2097120 May 12 18:20 quota.user
31 drwxr-xr-x   10 root     root         4096 Sep  9 01:37 root
32 -rwsrwsr-x    1 root     root       511400 Sep  9 00:44 root-shell
33 drwxr-xr-x    2 root     root         4096 May 12 18:20 sbin
34 drw-rw-rw-    3 root     root       106496 Oct 18 02:06 tmp
35 drwxrwxrwx    2 root     root       110592 Oct 18 01:48 tmp2
36 drwxr-xr-x   14 root     root         4096 Jul 27  2003 usr
37 drwxr-xr-x   20 operator operator     4096 Mar 25  2004 var
38 -rw-r--r--    1 root     root      1201497 Apr 15  2004 vmlinuz

Stattdessen unterstützt der Hoster ebenfalls die unfreiwillige Anti-Diskriminierungs-Kampagne “Gebt Skript-Kiddies eine Chance”. Er hinterlegte – wie viele Mitbewerber auch – das MySQL-Root-Passwort für alle Benutzer lesbar im Filesystem. In den Konfigdateien für Sysweb[5] (einer Alternative zu Confixx) und für PHP-MyAdmin fand ich einen entsprechenden Eintrag. Für PHP-MyAdmin wäre der noch nicht mal notwendig, das Klartext-Passwort ist ein vollkommen unnötiges Sicherheitsrisiko.

Mimosenhafte Reaktion

Damit konfrontiert behob der Support die Lücke zwar sofort – aber reagierte danach so: Erst löschte er einen Teil meiner Daten und sperrte dann sogar den gesamten Account. Als ich mit der Firma telefonierte, um den Vorfall zu klären, zeigte man sich pikiert. Ich hätte sensible Daten ausgespäht, hieß es. Man prüfe derzeit, ob die Tat juristisch verfolgt werden solle.

Scheitern erwünscht

Einen Erfolg dieses Vorhabens bezweifle ich (siehe Kasten “Haftung der Hoster”). Zwar kennt das StGB den Straftatbestand “Ausspähen von Daten” (nach § 202a), aber der setzt voraus, dass die Daten auch gegen fremde Zugriffe geschützt sind. Auf öffentlich lesbare Konfigurationsdateien, in denen Passwörter im Klartext stehen, trifft das sicherlich nicht zu. Hier sollte sich der Provider ernsthaft Gedanken um sein eigenes Mitverschulden machen.

Außerdem soll ich mir Leistungen erschlichen haben. Gemeint sind damit die Cronjobs, die ich auch bei diesem Hoster eingerichtet hatte. Die sind laut Systemkonfiguration jedoch freigeschaltet, mein Account ist nicht in »cron.deny« gelistet. Der Provider sollte sich wieder an seiner eigenen Nase packen.

Bei diesen Vorwürfen war ich erst mal sprachlos. Der Provider verkannte sein eigenes Versagen und hackte stattdessen auf seinem Kunden herum, der keinerlei Sicherheitssperren überwunden hatte, weil es einfach keine gab. Letztlich hat der Provider dann doch auf eine Anzeige verzichtet.

Alles wieder da

Ich hatte zwar die gesamte Homepage als Backup auf meinem eigenen Rechner, wollte das Löschen der Daten aber nicht so auf sich beruhen lassen. Selbst wenn ein Verdacht vorliegt, dürfte die Firma meine Daten nicht einfach löschen. Ein Admin müsste von Berufs wegen etwas von Datensicherheit verstehen. Es hätte völlig ausgereicht, die Dateien oder Accounts vorläufig zu sperren, statt sie gleich zu löschen.

Auf meine Anfrage versprach der Provider ein Backup meines Homeverzeichnisses. Am nächsten Tag erhielt ich auch eine E-Mail mit einem passwortgeschützten Download-Link, das heruntergeladene Backup war allerdings leer. Ich nahm die Website dann auf einem anderen Server wieder in Betrieb und spielte mein eigenes Backup zurück, um den Schaden zu beheben.

Die schlechten Erfahrungen bei meiner Hoster-Jagd bestätigen, wie wichtig es ist, sich um seine Daten selbst zu kümmern. Unsicher administrierte Rechner locken Cracker geradezu an und führen dazu, dass sie fremde Files manipulieren. Und sogar der Hoster selbst stellt sich gelegentlich als unmittelbare Gefahr für die Inhalte dar. (fjl)

01 exit
02 ps aux | grep nobody
03 ls -la
04 ls -la
05 cd /
06 ls -la
07 last root
08 exit
09 passwd
10 passwd