Artikel mit ‘sicherheit’ getagged

Wieso drehen bei Dropbox alle so am Rad?

Sonntag, 10. April 2011

Vor kurzem rauschte eine Meldung durch den Online-Blätterwald: Sicherheitslücke beim Online-Speicher Dropbox lauteten beispielsweise die reißerischen Titel.

Ich komme da nicht ganz mit. Unter einer Sicherheitslücke verstehe ich klassischerweise einen Umstand, der es Leuten ermöglicht, ohne Authentifizierung Dinge zu tun, für die sie sich normalerweise anmelden müssten. Genau das ist hier aber nicht der Fall – vielmehr geht es um etwas viel Einfacheres: Es geht um die Erschleichung eines Zugriffs durch den Klau von Authentifizierungsdaten. Das ist, um’s mal vorsichtig zu sagen, ein alter Hut und auch kein Dropbox-spezifisches Problem. Jeder, der auf seinem Rechner irgendwo Passwörter gespeichert hat, sei es im Browser, sei es in einem FTP-Client, unterliegt einer völlig vergleichbaren „Sicherheitslücke“: Wer in jenen Rechner einbricht und diese Daten kopiert, hat damit Zugriff auf die Accounts des betreffenden Users. Gleiches gilt beispielsweise auch für Cookies: Wer einen Cookie stehlen kann, stiehlt damit implizit auch den Zugang, der hypothetisch hinter diesem Cookie steht. Viele Cookies dienen ja dazu, jemanden im Lauf einer Session wiederzuerkennen, ohne dass er sich für jeden Seitenaufruf erneut identifizieren muss – der Cookie ersetzt also die Authentifizierung mit Username und Passwort. Insofern halte ich das für hanebüchen, die „Entdeckung“ als „Sicherheitslücke“ zu bezeichnen.

Im Grunde passen Cookies sogar als noch besserer Vergleich zu Dropbox als abgespeicherte Passwörter. Die Authentifizierung bei Dropbox funktioniert nämlich so, dass man bei Einrichtung des Clients auf einem Rechner seine Dropbox-Zugangsdaten angibt, der Client authentifiziert sich damit und besorgt sich eine sogenannte Host-ID. Diese wird dann abgespeichert und dient dann künftig – anstelle der Zugangsdaten – als Authentifizierung. Der „Angriff“ basiert darauf, die Datei zu klauen, in der die Host-ID steht. Insofern entspricht das Verfahren exakt dem Vorgang, sich an einer Website mit Username und Passwort anzumelden, die eine Option „[X] angemeldet bleiben“ bietet und daraufhin einen Cookie setzt, der eine lange Gültigkeit hat oder sogar nie verfällt: Die ursprünglichen Zugangsdaten werden ersetzt durch einen anderen Authentifizierungsmechanismus, der unabhängig von den Zugangsdaten besteht. Den Cookie kann ein Trojaner stehlen – und damit die Identität des Bestohlenen.

Und auch in einem weiteren Punkt gleicht die Dropbox-Authentifizierung Cookies: Der Sicherheitsexperte, der die „Lücke“ aufdeckte, verweist nämlich darauf, dass nicht einmal das Ändern des Passworts helfen würde, denn: Das wirkt sich nicht auf die Host-ID aus, die völlig eigenständig als Authentifizierung dient. Man könnte also sogar formulieren: Man braucht die Anmeldung mit Benutzername und Passwort nicht zur Nutzung der Dropbox, sondern lediglich zur Generierung der Host-ID; am Webinterface analog dazu zur Generierung des Cookies.

Benutzern muss doch klar sein, dass, wenn sie ihren Rechner rebooten, ihr Smartphone aus- und wieder einschalten … dass, wenn dann trotzdem der Zugriff auf die Dropbox auf „magische“ Weise immer noch ohne Eingabe irgendwelcher Zugangsdaten funktioniert, irgendeine Art von Authentifizierung hinterlegt sein muss. Dass das nicht übermäßig sicher ist, kann da doch ernsthaft keine Überraschung sein; dafür hat’s doch wohl bitte keinen Experten gebraucht, der das „aufdeckt“, sondern nur etwas gesunden Menschenverstand.

In der Sicherheitstechnik kennt man im Grunde drei Möglichkeiten der Authentifizierung: Geheimes Wissen (z. B. ein Passwort), Besitz (z. B. ein Haustürschlüssel) und Biometrie (körperliche Merkmale, die in der Regel nur schwer kopierbar oder fälschbar sind). Die Übergänge sind hier fließend: Melde ich mich an einem Dienst mit einem Passwort an, stellt jenes geheimes Wissen dar, das man mir nicht stehlen kann, sondern mich höchstens zur Preisgabe zwingen kann. Speichere ich das Passwort aber ab, z.B. im Browser oder sonstwo, mutiert es zu Besitz – man muss mich nicht mehr foltern; man muss mir nur noch die Datei klauen, in der das Passwort steht.

Es sollte keine Überraschung sein, dass jedes dieser Verfahren für sich genommen schwach ist. Menschen kompromittieren geheimes Wissen, in dem sie sich Trivialpasswörter ausdenken, überall das gleiche Passwort nehmen oder es gleich durch Aufschreiben oder Abspeichern in Besitz konvertieren. Besitz kann man stehlen; Besitz von klassischen Gegenständen setzt zumindest schon mal einen Einbruch voraus, Besitz von Dateien schon nur noch einen Trojaner auf dem Rechner, und wenn ich mir anschaue, wieviele Leute nicht mal ihr Betriebssystem aktuell halten und bei wievielen Freunden ich schon Malware von der Platte kratzen durfte, halte ich „Besitz“ schon fast für die fahrlässigste Möglichkeit der Authentifizierung. Biometrie allein bringt’s auch nicht – die Geschichten, wo Computer Menschen eben gerade nicht zuverlässig erkennen bzw. umgekehrt zuviele Menschen als zu einem biometrischen Merkmal passend erkennen, gibt es mehr als genug. Wir selbst waren eine Zeitlang in einem Rechenzentrum mit Fingerabdruckscanner und haben in drei Vierteln der Fälle in der Sicherheitsschleuse festgehangen, weil der Scanner uns nicht korrekt erkannte. Umgekehrt dürfte der Fingerabdruck des früheren Innenministers Schäuble spätestens seit der Veröffentlichung praktischer Fingerabdruck-Klone in der Datenschleuder, der Zeitschrift des CCC, eins der am häufigsten kopierten biometrischen Merkmale sein.

Was man also braucht, um Sicherheit zu erhöhen, sind Kombinationen von Verfahren. Das ist auch gar nicht weiter kompliziert: Jeder, der schon mal einen Geldautomaten benutzt hat, hat damit beispielsweise bereits die Kombination aus Besitz (ec-Karte) und geheimem Wissen (PIN) angewendet – keins davon hätte ihm alleine schon Bargeld verschafft. Selbst Kombinationen aus zwei identischen Verfahren sind sicherer als eins allein – um im Bankenumfeld zu bleiben: Mit einer PIN komme ich zwar ins Onlinebanking rein; um auch Überweisungen zu tätigen, brauche ich aber auch eine TAN. Mit einer TAN ohne PIN komme ich umgekehrt aber nicht mal ins System. Mit dem zunehmenden Umbau der Systeme auf TANs, die aufs Handy geschickt werden oder die man mit einem optischen Leser generiert, der wiederum die eingesteckte ec-Karte voraussetzt, wird hier verstärkt geheimes Wissen mit Besitz (Handy, oder TAN-Generator mit eingesteckter ec-Karte) gekoppelt.

Auch am Rechner gibt es schon lange Beispiele für Kombinationsverfahren: Browser, in denen man Passwörter abspeichern kann (womit die Datei, in der sie gespeichert werden, das Passwort zu Besitz mutieren lässt), können diese Datei auch verschlüsseln. Rufe ich nun den Browser auf und möchte eins der gespeicherten Passwörter nutzen, muss ich zunächst das Passwort eingeben, um die Passwortdatei zu entschlüsseln – Besitz und Wissen. Wer mit SSH-Keys arbeitet, wird diese typischerweise ebenfalls verschlüsselt haben und einen SSH-Agent starten, der zunächst die Passphrase zur Entschlüsselung des Keys abfragt und dann so den als Datei hinterlegten Key nutzbar macht – Besitz und Wissen.

Ich sehe also nicht, wo bei Dropbox da jetzt die Sicherheitslücke liegen soll. Es mag vielleicht irritierend sein, weil für den User nicht transparent ist, dass die Anmeldung faktisch via Besitz (Datei mit Host-ID) und nicht via Wissen passiert, weil sie nicht wissen, wie genau das alles im Hintergrund funktioniert. Aber auch wenn der Dropbox-Client einfach nur die Zugangsdaten in einer Datei abgespeichert hätte, wäre Wissen zu Besitz geworden, nur mit dem Unterschied, dass dann das Ändern des Passworts des Dropbox-Accounts Wirkung zeigen würde. Aus technischer Sicht finde ich den Unterschied allerdings zugegebenermaßen marginal. Wer häufiges Ändern von Passwörtern ernsthaft als „Sicherheitsmethode“ ansieht, dem ist vermutlich egal oder nicht bewusst, dass bis zur Passwortänderung schon längst alle möglichen Daten abgeschnorchelt oder gar unbemerkt verändert worden sein können. Die Sicherheit ist schließlich mit dem Einbruch kompromittiert – eine spätere Passwortänderung kann das nicht mehr ungeschehen machen.

Dropbox trägt also eigentlich nur an einem Schuld: Dass sie kein Kombinationsverfahren für die Authentifizierung forcieren. Dabei wäre es doch nun ein Leichtes, die Datei mit der Host-ID zu verschlüsseln und als Basis für eine Entschlüsselung ein vom User eingegebenes Passwort zu nehmen oder meinetwegen auch nur ein paar mit dem Finger aufs Smartphone geschmierte Linien – wobei eben wichtig ist, dass das nicht einfach dergestalt realisiert wird, dass die Software die Datei mit der Host-ID „freigibt“, sondern schon tatsächlich so, dass die Datei mit der Host-ID damit so verschlüsselt ist, dass der Besitz der Datei alleine tatsächlich nicht ausreicht, auch wenn man diese „hintenrum“ kopiert.

Aber vermutlich wäre das den meisten schon zu kompliziert. Man lobt Dropbox ja nun vor allem wegen seiner Einfachheit. Dem Sicherheitsexperten gehört insofern Dank, als dass er vielleicht ein wenig Sensibilität dafür weckt, wie Authentifizierung tatsächlich funktioniert. Das ändert aber nichts daran, dass die Mehrheit der User, wenn sie nicht gezwungen wird, vermutlich immer die bequemste Authentifizierung wählen wird, nämlich „merk dir meine Daten für immer und lass mich dann in Frieden“. Hieraus dann speziell Dropbox einen Vorwurf zu machen, halte ich für unredlich und an der Sache vorbei.

SSL-Client-Zertifikate mit Chrome

Donnerstag, 14. Oktober 2010

SSL-Zertifikate gibt’s von einer Menge Anbietern. Wir nehmen unter anderem auch die Dienste von StartCom in Anspruch, bei denen wir am ehesten den Eindruck haben, dass die auch selbst was von Sicherheit verstehen – ein Eindruck, den fatalerweise viele SSL-Zertifizierungsstellen nicht machen.

Zu diesem Eindruck trägt auch bei, dass StartCom konsequent auf SSL-Client-Zertifikate zur Authentifizierung setzt, und nicht auf das klassische Paar aus Benutzername/Passwort. Technisch gesehen läuft das so, dass man einen kleinen Assistenten durchläuft, der eine Browserfunktion anwirft, die einen privaten Schlüssel direkt im Browser erzeugt und ablegt (sprich, er wird nie an den Website-Betreiber übermittelt) und anschließend auf dieser Basis dann ein Zertifikat generiert, was dann direkt in den Browser importiert wird. Ist der Prozess abgeschlossen, kann man sich mit diesem Zertifikat gegenüber der Website ausweisen. Im Prinzip ist das ein gutes Beispiel, wie man starke Authentifizierung wirklich bequem und einsteigerfreundlich machen kann, denn der ganze Prozess ist sehr einfach gestaltet und lässt sich auch ohne besondere Vorkenntnisse durchlaufen. Die Frage, die unerfahrene Anwender dabei noch am ehesten stellen, ist von daher weniger „Was muss ich hier machen?“, sondern eher „Wieso funktioniert das einfach so, ich musste ja nicht mal ein Passwort eingeben?!“ – tja, willkommen in der manchmal doch ganz schönen Welt von SSL.

Damals hatte ich diesen ganzen Prozess mit Firefox abgewickelt. Mittlerweile nutze ich im Alltag fast nur noch Chrome, genaugenommen die freie Variante Chromium, für die Tom „spot“ Calloway Fedora-Pakete pflegt. In puncto SSL unterscheidet sich Chromium von Firefox: Unter Linux benutzt es nämlich die NSS-Funktionalität des Systems, statt einen eigenen Keystore zu basteln (was ich für eine äußerst gute Idee halte), während Firefox auf allen Plattformen einen eigenständigen Keystore nutzt. Natürlich können die Client-Zertifikate in Form von PKCS#12-Dateien exportiert und im jeweils anderen Tool importiert werden – das nur so zum Hintergrund.

Nun laufen auch Client-Zertifikate irgendwann aus, so dass ein neues fällig wurde. Also habe ich den Client-Zertifikats-Assistenten von StartCom angeworfen – diesmal aber im Chromium. Nun ist aber gerade jenes „Certificate Enrollment“ derzeit noch eine Baustelle und läuft beileibe nicht „einfach so“ rund, wie ich es oben beim Firefox noch so gelobt habe. Und damit meine ich nicht, dass es mehr Handarbeit bräuchte, sondern dass es schlicht überhaupt nicht erfolgreich funktioniert. Hätte ich mal vorher nachgeschaut – hatte ich aber nun mal nicht.

Das vorläufige Ende vom Lied: Chromium hat es durchaus geschafft, einen privaten Schlüssel in der NSS-Datenbank zu erstellen. Mit dem Import des darauf basierenden Zertifikats hat das aber leider nicht geklappt: „Fehler 207 (net::ERR_CLIENT_CERT)“ war alles, was ich zu sehen bekam – sprich, das war ein Schuss in den Ofen – und zwar noch ein schlimmerer, als ich dachte: Die naheliegendste Lösung, den Key einfach wegzuschmeißen und ein neues Client-Zertifikat zu erstellen (diesmal dann wieder im Firefox) klappt nämlich auch nicht: StartCom lässt es nicht zu, ein Client-Zertifikat zu erstellen, wenn ein vorheriges noch gültig ist.

Dunkle Wolken ziehen am Horizont auf. Das von StartCom generierte Client-Zertifikat kann ich über deren Toolbox immer wieder beziehen; das ist nicht das Problem – nur funktioniert es eben nur in Kombination mit dem Key. Und das ist genau das Problem: Im Chromium (bzw. in der NSS-Datenbank) habe ich den Key, bekomme aber das Client-Zertifikat nicht rein. Der Firefox könnte zwar das Client-Zertifikat importieren, aber da er den Key nicht hat, schlägt das fehl.

Mein nächster Gedanke war: „Bei SSL-Server-Zertifikaten hantieren wir ja auch immer mit einer Datei für den privaten Schlüssel und einer Datei mit dem Zertifikat. Wieso also nicht einfach den Key aus der NSS-Datenbank exportieren und in Firefox importieren – und dann, wenn der Firefox den Key hat, kann er ja wohl auch das Zertifikat aus der Toolbox importieren.“

Denkste. Christopher wies mich direkt darauf hin:

Nein, Firefox kann nur Keys nur in PKCS-Dingsbums importieren, nicht roh. Also kannst es versuchen, aber bei Firefox…

Wäre ja nett gewesen, überhaupt bis zum diesem Punkt zu kommen. Faktisch ist es nämlich gar nicht möglich, nur den Key aus der NSS-Datenbank zu exportieren. Exportieren geht nur im PKCS#12-Format, und das besteht zwingend aus Key und Zertifikat. Nelson B Bolyard schreibt:

Bare private keys by themselves?
NSS utility programs are intended to NOT do that.
The idea is to NOT make it easy for the user to ruin his own security.

Ja, toll. Ich will aber nicht meine Security ruinieren; ich weiß ja, was ich hier tue und warum. Und ich habe mir beileibe auch nicht aus freien Stücken ausgesucht, so vorzugehen. Chris ergänzt: „Abandon all hope, ye who enter here“. Wie wahr.

So oder so: Dieser Weg war wohl ein Schuss in den Ofen. Also vielleicht doch anders herum, sprich, „irgendwie“ an das Zertifikat kommen und das manuell in die NSS-Datenbank mit reinpacken. Nur wie? Erstmal müsste man dazu wissen, wie denn die URL heißt, unter der man das Zertifikat bekommen kann. Und das ist nicht so ganz einfach, denn die Toolbox vom StartCom ist völlig ajaxisiert; man kann sich nicht einfach irgendwo mal schnell eine URL rauskopieren. Abhilfe schafft das Firefox-Plugin Live HTTP Headers, das die HTTP-Header jeglicher Browserkommunikation mitschneidet – also auch die der Ajax-Kommunikation. Und siehe da: Klappt prima, und ich komme auf eine URL in dieser Form:

https://www.startssl.com/getcrt.ssl?certID=...

Genau was ich brauche!

Leider ist es damit nicht getan, denn Firefox versucht beim Aufruf dieser URL sofort, das Zertifikats zu importieren – was natürlich nicht geht, weil der dazu passende private Schlüssel im Keystore vom Firefox ja fehlt. Ich will das Zertifikat ja auch eigentlich nicht importieren, sondern herunterladen, sprich: als Datei speichern. Das Problem kann man grob damit vergleichen, wenn man die URL eines Bilds direkt im Browser eingibt: Dann wird man ja auch nicht gefragt, ob man das Bild anzeigen oder speichern will, sondern es wird eben einfach angezeigt. Mit einem entscheidenden Unterschied: Ich kann dann immer noch über das Kontextmenü „Bild speichern unter …“ auswählen und das Bild auf die Platte bannen. Hier wird aber ja gerade gar nichts angezeigt – ergo hilft mir das Kontextmenü (und auch das Datei-Menü, das einen gleichnamigen Punkt bietet) überhaupt nicht weiter.

Der Workaround, auf den ich schließlich gekommen bin, gehört zu der Kategorie, bei der man sich mit einem herzhaften „D’oh!“ an die Stirn schlagen möchte. Also: Wo kann man sonst noch über das Kontextmenü Dinge direkt abspeichern? Richtig, bei Links, „Ziel speichern unter …“. Zwar ist die StartCom-Toolbox wie gesagt ajaxisiert und bietet daher keinen solchen Link, aber das macht nichts: Da wir ja nun die URL kennen, bauen wir uns einfach selbst einen Link in einer lokalen Datei, rufen diese via file:///tmp/link.html im Firefox auf, rechte Maustaste auf den Link, Ziel speichern unter, und voilà: Das Zertifikat ist im PEM-Format mit der Endung .p7b auf der Festplatte gespeichert.

Damit ist die größte Klippe umschifft. Nun gilt es nur noch, diese Datei in die NSS-Datenbank zu importieren, wo bereits der zugrundeliegende Key wartet:

certutil -d sql:$HOME/.pki/nssdb -A -t "u,u,u" -n "Jonas Pasche" -i cert.p7b

Klappt sofort – und spontan kann Chromium das SSL-Client-Zertifikat benutzen. Der Vollständigkeit halber soll es aber auch in den Firefox. Also exportieren wir es aus der NSS-Datenbank; um genau zu sein, exportieren wir Zertifikat und Key, denn es gibt ja nur beides in Kombination:

pk12util -d sql:$HOME/.pki/nssdb -o export.p12 -n "Jonas Pasche"

Die resultierende Datei kann dann schließlich problemlos in Firefox importiert werden – und ein ätzendes Problem mit einem zunächst verwaisten Key in der NSS-Datenbank hat seinen sauberen Abschluss gefunden.

Bleibt noch zu sagen, dass dieser ganze Krampf rein akademischer Natur war. Es hätte nämlich auch gereicht, sich in der StartCom-Toolbox ein neues Client-Zertifikat mit einer anderen E-Mail-Adresse generieren zu lassen. Entscheidend für die Anmeldung an der Toolbox ist schließlich nicht die Mail-Adresse, sondern die damit verbundene Identität, und da sämtliche Client-Zertifikate, die ich in meinem Account ausstelle, auch auf meine Identität verweisen, kann ich auch alle gleichermaßen für den Login benutzen. An dieser Stelle soll nicht unerwähnt bleiben, dass diese letzte – natürlich viel einfachere – Variante dem wie immer hervorragenden StartCom-Support eingefallen ist. Danke dafür!

Was ist eigentlich SQL-Injection?

Dienstag, 27. April 2010

Wenn es um Sicherheitsprobleme geht, werfen die entsprechenden Security-Advisories gerne mit Begriffen wie „cross-site scripting“, „cross-site request forgery“ oder „sql injection“ um sich. Aus aktuellem Anlass können wir mal ein praktisches Beispiel einer real existierenden Software nehmen (deren Name lieber ungenannt bleibt), mit der man mandantenfähig Rechnungen erstellen kann, die sich ein Kunde auf seinem Webspace installiert hat. Sie lief anfangs nicht, und die Basis seiner Anfrage war dann eher erstmal der Wunsch nach „Könnt ihr das zum Laufen bringen“-Support. Nachdem ich mir dazu kurz einige der fraglichen PHP-Dateien angeschaut hatte, wurde daraus dann aber eher ein kleines Lehrstück, das ich hier gerne (bis auf die Usernamen) unverändert weitergebe.

[...]

Es sieht mir auf den ersten Blick so aus, als könne man da sehr viel
verbessern, wenn ich das mal vorsichtig so sagen darf. ;-)  Ich sehe
schon auf den ersten Blick Angriffspunkte für SQL Injection sowie eine
Abhängigkeit von register_globals = On. Das erste ist ein handfester
Fehler; das zweite eröffnet eventuelle Angriffspunkte, die nicht sein
müssten. Freundlich gesagt sieht man der Software an, das sie von 2006
ist. :)

Willst du mal sehen, wie das mit SQL Injection funktioniert?

Gib mal bei der Anmeldung als Benutzername deinen Zugang "max" ein
und dann als Passwort dieses hier:

        '||ID='1

Schwupps, bist du drin. Das klappt mit "moritz" genauso. Und mit jedem
anderen auch.

Hintergrund ist, dass in der mod/authent.php ausgeführt wird:

        $result=$dbverbindung->run_sql("SELECT ID,User,Pwd FROM Admin WHERE User='"
          .$user."' AND Pwd='".$pwd."'");

Das heißt, wenn du "max" und "geheim" angibst, steht da:

        SELECT ID,User,Pwd FROM Admin WHERE User='max' AND Pwd='geheim'

Genauso steht dann aber auch da, wenn du mein Trick-Passwort anwendest:

        SELECT ID,User,Pwd FROM Admin WHERE User='max' AND Pwd=''||ID='1'

Also "selektiere alle User, deren Name 'max' ist und bei denen das
Passwort leer ist (was nie vorkommt), oder alle User, deren ID = 1 ist".

Das "Schöne" ist: Es wird so einfach der User 1 selektiert. Dass du da
"max" angibst, tut überhaupt nichts zur Sache. Siehe hier:

        mysql> SELECT ID,User,Pwd FROM Admin WHERE User='moritz' AND Pwd=''||ID='1';
        +----+--------+---------+
        | ID | User   | Pwd     |
        +----+--------+---------+
        |  1 | max    | geheim  | 
        +----+--------+---------+
        1 row in set (0.00 sec)
        
Aber: Da mod/authent.php immer den Namen aus dem _Formular_ in die
Session als angemeldeten User übernimmt, musst du nicht mal die numerische
ID kennen. Es reicht, dass das SQL-Statement _irgendeinen_ Datensatz
zurückliefert; dann schreibt es den Namen aus dem Formular in die
Session. Sprich, beim vorigen SQL-Statement wäre ich dann als "moritz"
angemeldet, obwohl das SQL-Statement deinen Account geliefert hat. Ich
brauche also nur einen beliebigen Benutzernamen sowie '||ID='1, dann
komme ich rein.

Richtig WÄRE im Programmcode übrigens:

        $result=$dbverbindung->run_sql("SELECT ID,User,Pwd FROM Admin WHERE User='"
          .mysql_real_escape_string($user)."' AND Pwd='".mysql_real_escape_string($pwd)."'");

Allerdings müsste man solche Fehler an ...

        $ grep -r ">run_sql" . | wc -l
        92

... Stellen in Ordnung bringen. Da kann man's auch gleich selber
schreiben. (Dass das Problem nicht nur beim Login vorliegt, sondern bei
jedem SQL-Statement, zeigt mir auch, dass das kein "Bug" ist, den der
Autor dort versehentlich eingebaut hat, sondern dass ihm grundlegendes
Verständnis vom Design von Webapplikationen fehlt. Ist ja nicht so, dass
die PHP-Dokumentation das nicht alles haarklein erklären würde..! Da
findet sich Code wie der von ihm fast 1:1 in der Doku - als Beispiel
dafür, wie man's NICHT macht.)

[...]

Folge: Der Kunde verpackt das installierte PHP-Script noch hinter einer .htaccess-Datei zum „übergeordneten“ Passwortschutz. Da es sich um eine Anwendung handelt, die er ausschließlich selbst einsetzt und die keinen Dritten zur Verfügung stehen wird, ist dies hier ein – vom Sicherheitsaspekt her – akzeptabler Kompromiss. Dass man üblicherweise lieber Software von Leuten einsetzen sollte, die ihr Handwerk verstehen, versteht sich hoffentlich von selbst.

Passwörter: Nicht mit SSH-Keys

Sonntag, 13. April 2008

Jetzt arbeiten wir schon seit vielen Jahren kaum noch mit traditionellen Passwörtern, sondern sind auf SSH-Keys umgestiegen. Im Rahmen eines Wartungsvertrags für einen dedizierten Server haben wir die vereinbarten Arbeiten durchgeführt, bis der Kunde verwundert fragte, wer uns denn das neue root-Passwort mitgeteilt habe. Nun ja: Niemand eben. Aus diesem Grund mal eine kleine Zusammenstellung von praktischen Links insbesondere für Windows-Nutzer (unter Linux und MacOS X ist die Nutzung von SSH ja ohnehin eher verbreitet):

Auf der Website von PuTTY bekommt man neben dem SSH-Client selbst auch einen Schlüsselgenerator für SSH-Key sowie einen optionalen SSH-Agent zum Cachen der entschlüsselten Keys. Kai Billen hat eine gute deutsche Anleitung für alles verfasst. Noch Fragen?

Darum sollte man Maschinen nach einer root-Kompromittierung plätten

Donnerstag, 03. April 2008

Zugegeben: Wir arbeiten zwar in einem gehobenen Hosting-Segment, allerdings nicht im Enterprise- oder Hochsicherheitsbereich. Und schließlich geht es hier um Maschinen, die zwar unserer Kontrolle unterstehen, die aber nicht uns gehören, so dass letztlich der Kundenwunsch den Ausschlag gibt, was zu tun ist. Im konkreten Fall ging es um eine Maschine, deren root-Zugang kompromittiert wurde. Das ist extrem selten, immerhin pflegen wir die unserer Betreuung unterstehenden Maschinen gut, so dass Sicherheitslücken in als root laufenden Diensten so gut wie nie zum Tragen kommen, bevor das Update eingespielt ist – aber „so gut wie nie“ ist eben nicht „nie“.

Dem Kundenwunsch entsprechend sollte die Maschine allerdings nicht vollständig geplättet und neu aufgesetzt werden, sondern (nach Schließung der Sicherheitslücke) lediglich gesäubert werden. Das ist an sich auch unproblematisch, da wir Prüfsummen aller ausführbaren Programme erstellen und somit Kompromittierungen im Allgemeinen gut erkennen können, sofern sie nicht so weit gehen, dass Kernelmodule installiert werden, die ein Rootkit vollständig verbergen. Wir kennen in einem solchen Fall aber letztlich auch unsere Grenzen, sprich, wir sind Webhoster und keine Security-Leute. Dieses Feld überlassen wir lieber Leuten, die sich damit auskennen, so wie wir uns in unseren Dingen gut auskennen. Nun, wie gesagt, die Maschine wurde nach Kundenwunsch und nach unserem besten Wissen und Gewissen gesäubert und ging kurz darauf wieder in Betrieb.

Warum dann allerdings die Maschine wenige Tage später erneut kompromittiert wurde, war uns zunächst ein Rätsel, zumal sich an der installierten Software keine Lücken mehr zeigten.

Die Lösung: Bei der vorherigen Kompromittierung hatten die Angreifer dem Systemuser games ein Passwort gegeben – und sich ganz trivial eingeloggt. Und aus eben diesem Grund sollte man Maschinen nach einer root-Kompromittierung im Regelfall immer plätten: Es ist praktisch ausgeschlossen, alles zu finden, was ein Angreifer installiert hat, egal wie gewissenhaft man vorgeht. Zugegeben: Ein Passwort auf einem User, der normalerweise keins hat (und damit auch keinen Login), war erschreckend trivial. Wir schämen uns – und setzen’s auf unsere Liste von Dingen, die nach einer root-Kompromittierung zu prüfen sind, sollte ein Neuaufsetzen der Maschine keine Option sein.


Impressum