RackBlogger

Es war nun einige Wochen lang recht still hier im Blog, ich habe mir vorgenommen das wieder zu ändern.

Los geht’s aus aktuellem Anlass mit Klartext-Passwörtern. Das Controlpanel “Plesk” steht derzeit wieder im Kreuzfeuer, da laut dem Sicherheitsexperten Brian Krebs ein sogenannter “0day exploit” die Runde macht und gleichzeitig die Sicherheitslücke vom Februar 2012 für bittere Nachwirkungen sorgt. Damals konnte durch eine SQL-Injection in der Remote-API von Plesk völlig anonym auf betroffene Systeme zugegriffen werden, wobei im großen Stile die Benutzerpasswörter ausgelesen wurden. Diese speichert Plesk in der Tabelle psa.accounts unverschlüsselt und nicht gehashed.

Parallels hat natürlich reagiert und neben dem Bugfix auch ein Tool zur Massen-Änderung von Passwörtern bereitgestellt. Blöd ist nur, dass die kompromittierten Passwörter nicht auf eine Blacklist gesetzt wurden - so haben viele Endkunden die neuen (kryptischen) Passwörter einfach wieder zurück geändert. Wie will man sonst auch seine Kunden dazu “zwingen”, wirklich ein neues Passwort zu verwenden?

Nun, die Tatsache, dass in einer Remote-API eine SQL-Injection möglich war, ist eigentlich schon schockierend genug - es gibt viele Methoden um so etwas zu vermeiden (von der statischen Code-Analyse bis zur Verwendung von Prepared Statements). Aber das Passwörter jeglicher Art im Klartext gespeichert werden ist kein Programmierfehler, sondern meiner Meinung nach grobe Fahrlässigkeit. Auf Unix/Linux-System werden seit zig Jahren alle Account-Passwörter gehashed (anfangs nur mit crypt(), inzwischen schon mit komplexen SHA256-Hashes). MySQL ist nun auch nicht gerade für maximale Zugriffssicherheit bekannt (zumindest möchte ich mal behaupten, dass es für einen normalen Systembenutzer einfacher ist, in MySQL einzusteigen als /etc/shadow auszulesen).

Es gibt durchaus das Problem, dass einem Controlpanel ein reiner Hash des Benutzerpassworts nicht reicht - das ist beispielsweise bei E-Mail-Passwörtern häufig der Fall. Wir lösen das so, indem E-Mail-Clients sich nur über das CRAM-MD5-Verfahren am Mailserver anmelden dürfen (PLAIN macht keinen Sinn, da Passwörter völlig unverschlüsselt über den Äther gesendet würden). Auf dem Mailserver kann statt dem Klartext-Passwort nun das “vorgehashte” Passwort abgelegt werden - eine Speicherung im Klartext ist überflüssig (bei Dovecot ist es das Passwort-Schema CRAM-MD5).
Warum Plesk aber selbst das Admin-Passwort mit einem einfachen Shell-Befehl ausgeben kann, entzieht sich meiner Vorstellungskraft. Und wie mit diesem Panel betriebene Webserver eine PCI-Zertifizierung erhalten, obwohl wissentlich kritische Passwörter unverschlüsselt bleiben, ist ebenfalls fragwürdig.

Programmierfehler kann jeder machen - keine Frage. Ich kann auch nicht dafür garantieren, dass es bei LiveConfig keine Sicherheitslücken gibt (das wird vermutlich niemand können). Wir können aber unser Bestes tun, um so etwas zu vermeiden und im “worst case” den potenziellen Schaden zu minimieren: Passwörter werden grundsätzlich nur als gesalzene Hashes gespeichert, kritische Daten (etwa Private Keys für SSL-Zertifikate) werden stark verschlüsselt, SQL-Injections durch Prepared Statements unmöglich gemacht, und so weiter. Ein System ist eben nur so sicher wie seine schwächste Stelle.

Und zum Thema “automatische Passwörter” folgt in Kürze der nächste Beitrag.

Ach ja, bis heute werden in Plesk 10 (v10.4.4#36) die Passwörter nicht verschlüsselt!

Ein sehr interessanter Artikel auf wired über ein 9-jähriges Mädchen, dass über das ihr angebotene Schulessen gebloggt hat, hat mich eben sehr an einen meiner ersten Blogbeiträge erinnert.

Was will uns dieses Verkehrsschild sagen?

Wen es interessiert: dieses Schild hat tatsächlich eine tiefere Bedeutung, steht alles in einem Wikipedia-Artikel. Wenn nur alles so eindeutig geregelt wäre…

Nach einem Update auf einer CentOS 6.2 Instanz unter VirtualBox bootete diese komischerweise immer direkt in eine Kernel Panic.

Das Problem ließ sich lösen, indem man in den Systemeinstellungen der VM den Chipsatz von “PIIX3″ auf “ICH9″ ändert.

(nur falls noch jemand dieses Problem hat - erspart viel Debugging…)

Irritierte Kunden rufen hier seit einer Weile an, da Mail an web.de-Adressen mit folgender Fehlermeldung gebounced werden:

Nemesis ESMTP Service not available
554 No SMTP service

So wie es aussieht, besteht da scheinbar ein (ernsteres) Problem bei web.de. Nur der MX “mx-ha03.web.de” weist nämlich die Mails ab, “mx-ha02.web.de” akzeptiert nach wie vor E-Mails.

Kurzfristige Lösung auf dem Mailserver: einfach die “kaputte” MX-Adresse ins Nirwana routen lassen:

route add -host 213.165.67.104 dev lo
route add -host 213.165.67.104 reject

Nicht schön, erfüllt aber seinen Zweck. Und nicht vergessen, das dann wieder irgendwann herauszunehmen.

[Nachtrag] Ein Entwickler bei web.de ist über diesen Beitrag auf den Fehler aufmerksam geworden. Kurz gesagt liegt in einer sehr seltenen Konstellation ein Fehler vor, der nun beseitigt wird. Wer diese Fehlermeldung sonst noch erhält dürfte aber in den allermeisten Fällen einen Konfigurationsfehler auf der eigenen Seite haben.

So, bin nun von der CeBIT-Eröffnung zurück im Hotel (wo genau verrate ich nicht, da es für CeBIT-Verhältnisse unverschämt günstig ist )

Am Ende gab es noch eine beeindruckende Live-Schaltung zur ISS:

Derzeit lese ich übrigens das Buch “Limit” von Frank Schätzing. Die über 1300 Seiten schrecken am Anfang vielleicht etwas ab, aber jede einzelne Seite ist es wert! Absolut spannend und empfehlenswert. Und in diesem Zusammenhang wirkt das Bild aus der ISS irgendwie vertraut und futuristisch zugleich.

Ab morgen früh geht’s dann los - am Stand A50 in Halle 26 präsentieren wir unser Hosting Control Panel LiveConfig (falls das hier jemand noch nicht mitbekommen hat )

Heute ist mal wieder die Paketliste für Debian Security Updates korrupt.

Beim “aptitude update” erhält man folgende Fehlermeldung:

[ ERR] Reading package lists
E: Encountered a section with no Package: header
E: Problem with MergeList /var/lib/apt/lists/security.debian.org_dists_squeeze_updates_main_binary-amd64_Packages
E: The package lists or status file could not be parsed or opened.
E: Couldn't rebuild package cache

In den nächsten Stunden oder Tagen dürfte sich das Problem ohnehin erledigen, wenn die Paketliste wieder aktualisiert wird.

Wer nicht so lange warten möchte, kann mit folgendem Befehl die betroffene Datei “reparieren”:

sed -ie 's/^None$//' /var/lib/apt/lists/security.debian.org_dists_squeeze_updates_main_binary-amd64_Packages

Danach noch mal “aptitude update” ausführen - das war’s.

Zumindest auf der CeBIT. Von Halle 9 in Halle 26.

Bei heise online gab’s heute einen entsprechenden Bericht, der sich auf eine Meldung der HAZ bezieht. Die armen Standbauer. Aber für die Deutsche Messe war das sicher auch keine leichte Entscheidung.
Naja, wir fahren trotzdem hin. Der Geländeplan der CeBIT wurde bereits aktualisiert, wir passen in den nächsten Tagen noch die Infos auf unseren eigenen Webseiten an. Wer übrigens noch eine Freikarte braucht, um unser Hosting Control Panel zu bewundern, sollte am besten gleich einen Termin vereinbaren!