Schwerer Bug in OpenSSL entdeckt

d4f said:
Ich empfehle eine persönliche Überbringung an alle Kunden!
Click to expand...
Entschuldigung. Auf welchem Planeten lebst du? Bei mehr als 10 Kunden wirst du dann viel Spaß haben.

d4f said:
Meine Kundschaft sträubt sich noch immer dagegen dass deren Computer über secure USB-Sticks gebootet werden müssen bevor sie ins CP einloggen dürfen. Aber das ist halt die einzige Methode die üblichen Missbrauchfälle durch Trojaner zu umgehen...
Click to expand...

Wäre ein sicherer Weg. Macht sicherlich viel Spaß dem Kunden das zu erklären. Wie willst du das Prüfen, dass der Kunde von einem sicherem Stick gebootet hat? Vielleicht ist dieser ja auch kompromittiert. Wenn du schon so bedacht bist, solltest du auch das in Betracht ziehen. Ach ja, was ist wenn z.B. das BIOS des Kunden mit irgendwas befallen ist?

Letztendlich gibt es nur einen Mittelweg zwischen Sicherheit und Kundenfreundlichkeit. Der Weg per Mail wird von so ziemlich jedem Provider gegangen, der mehr als 100 Kunden hat. Da spielt es keine Rolle, wie sicher das ist. Es ist einfach nicht mehr wirtschaftlich das über den persönlichen Kontakt zu machen.
 
Entschuldigung. Auf welchem Planeten lebst du?
Click to expand...
Die Administration sollte endlich ein "Achtung, Sarkasmus" Smiley in das Forum einfügen. Mein Ziel ist, auf zu zeigen dass alle gängigen Kommunikationskanäle über welche ein entsprechender Link geschickt wird potentiell bedeutend gefährlicher sind als eine SSL-Verbindung.
Das notwendige Equipment zum Mitlesen und Entschlüsseln von GSM A5/1 Verbindungen kriegt man für 100-200$ auf eBay, zum Mitlesen von unverschlüsselten Emails über Wlan braucht es nicht mal das.


Wie willst du das Prüfen, dass der Kunde von einem sicherem Stick gebootet hat?
Click to expand...
Du hast Recht, ein getrennter Rechner ist besser.

Da spielt es keine Rolle, wie sicher das ist.
Click to expand...
Aaaah, jetzt sind wir bei der Ironie der Sache angekommen. Ein potentiell gefährlicher aber in Praxis nur sehr komplex anwendbarer Bug wird umgangen indem man ein bekannt gefährliches Medium verwendet und das (höhe) Risiko schlicht akzeptiert. Ergo ist es in der Regel weniger gefährlich wenn man schlicht nichts tut!
Aber so kann der Anbieter schön die Schuld auf den Kunden schieben - dass Opa Kleinmann nicht mal so wirklich weiss was TLS ist geschweige denn wie man das im "Computer-Brief" einstellt ist egal - Hauptsache es ist nie Schuld des Anbieters. Opa hätte ja einen Internetführerschein machen können, da wird das bestimmt erklärt.
Erinnert irgendwie an "Ihr Passwort muss mindestens 8 Zeichen lang sein mit Sonderzeichen" und darauffolgender "Sicherheits"frage "In welcher Straße haben Sie als Kind gewohnt"
 
Last edited by a moderator:
Meines Erachtens stimmt das so nicht.
Der Bug ermöglicht ein read out of bounds. Laut Fefe wird von OpenSSL ein eigenes Malloc verwendet, welches vom Kernel größere Blöcke anfordert und diese dann selbst in 64kB Blöcke einteilt.
Daher findet der read IMMER persönliche Daten wie Passwörter und Nutzernamen.

Diese kommen dann mit dem Payload an den Angreifer zurück (da dieser eine beliebige request length behaupten kann), da der Reply aufgefüllt wird auf die volle Payloadgröße, obwohl der ursprüngliche Request kleiner war, was dann mit dem obigen OPENSSL_malloc zu dem Problem führt, dass tatsächlich sensible Daten zurückgeschickt werden, statt nur Datenmüll, eben weil dort nur Daten von OpenSSL zu finden sind.

Das deckt sich auch mit der Empfehlung von Fefe, dass tatsächlich alle Passwörter sicherheitshalber geändert werden sollten und mit der Behauptung der ursprünglichen Entdecker, dass sie ohne Probleme an Nutzernamen, Passwörter, Emails und sonstiges kamen.

Edit:
http://www.heise.de/security/artikel/So-funktioniert-der-Heartbleed-Exploit-2168010.html

Heise stellt es auch so dar, dass tatsächlich sensible Daten mit dem Payload zurückgeschickt wurden. MITM/Sniffing sind daher NICHT notwendig, es reicht, wenn ich einen Server häufig genug anfrage, dann werde ich - mit etwas Zeit - auch genug Userdaten zusammensammeln.
 
Last edited by a moderator:
Richtig, ich habe in der Firma aus dem HTTPS-Server Logins von Kunden als komplette HTTP-Requests samt Post-Daten bekommen können, bei unseren Webspaceservern hatte ich sogar irgendwelche RSA PRIVATE KEYS bekommen (waren aber nicht unsere SSL Zertifikate, weiß selbst noch nicht, ob das besser oder schlechter ist).
Wir sind auf jedenfall gerade dabei überall alle Zertifikate zu tauschen.
 
Hoppela, dann ziehe ich meine Behauptung zurück. Mir war nach dem Lesen der Dokumente nur klar dass Openssl-interne Daten leaken, aber nicht dass Transferdaten enthalten sind!
 
Mir berichtete ein befreundeter Admin davon, dass er in seiner Gentoo/Apache Testinstallation direkt und wirklich als ASCII die PrivateKeys des SSL Zertifikates extrahieren konnte. Das ist natürlich schon so ziemlich worst case, aber auch bei uns war das echt uncool.

IMHO das allerschlimmste (und etwas, was vielleicht nicht alle/ich zuerst auch nicht realisieren): Das ist der Speicher eures Servers! Auch .htaccess Basic-Auth ist angreifbar! Ich konnte aus unserem normalerweise nur intern zugreifbarem Bereich über die Lücke von extern interne Daten auslesen und sehen, was meine Kollegen gerade machen. Das ist natürlich Worst Case^42.
 
Wie ist denn das, wenn der Server nur HTTPS macht als Reverse-Proxy und Load-Balancer? Sind dann auch potenziell Session-Inhalte betroffen oder nur der Private Key? In dem Fall würde es ja dann reichen, den Key zu tauschen.
 
Dann bin ich froh, dass die verwundbaren Load Balancer noch nicht in Produktion waren. Die aktuelle Umgebung läuft zum Glück mit F5 Big-IP und die waren nicht betroffen.

Wenn man die Erklärungen der Lücke im Netz liest, dann erscheint einem das schon irgendwie wie eine Ansammlung von WTFs. Variabler (exorbitant großer) Payload, der eigentlich völlig unnütz ist gepaart mit ungeprüften Längenangaben aus dem Request, die einfach so verwendet werden.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top