PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : debian ssl-zertifikate viel zu schwach



Seiten : [1] 2

derRichard
15.05.08, 10:44
hi!

jeder der einen debian (oder ubuntu) server betreibt sollte schnellstens openssl updaten und _alle_ zertifikate neu generieren.

http://metasploit.com/users/hdm/tools/debian-openssl/

//richard

p.s: und sich überlegen ob er debian wirklich noch vertrauen soll...

shogun
15.05.08, 11:00
Hallo,

ich weiss ja nicht, wie das bei Debian ist, aber bei Ubuntu sind die neuen Versionen schon raus.
Und das neugenerieren der Schlüssel übernimmt er auch gleich beim Update mit.

Gruß
Thomas

PierreS
15.05.08, 11:02
Im Prinzip müssen alle Zertifikate, die auf Debian-Systemen generiert wurden neu erstellt werden. Indirekt sind dann auch andere Distris "betroffen", wenn sich z.B. die Leute mit einem der schwachen keys anmelden.

BananaJoe
15.05.08, 11:03
So einfach ist es dann doch nicht... Ich denke mal eher der Bug ist der absolute Supergau!

derRichard
15.05.08, 11:10
hi!

nur als kleiner hinweis:
_jedes_ ssl-zertifikat (ssh, https, openvpn, etc..), das in den letzten zwei jahren mit der openssl-version von debian erstellt wurde kann in der praxis angegriffen werden.

das ist keine lücke, die einfach durch das einspielen eines patches behoben werden kann.

//richard

Dodobo
15.05.08, 11:29
Das heißt auch, sämtliche Internet-Transaktionen per https waren und sind unsicher, da die meisten Webserver auf Linux und auf Debian laufen?

Freude. ;)

Oder wird hier bloß heiß gekocht, weil es mal nur 90 statt 99% sicher ist? (Wen juckt das außer die ganzen übereifrigen, sicherheitsfanatischen Admins? Wer nutzt das dann wirklich aus?)

shogun
15.05.08, 11:29
Nochmal:

Bei mir hat er mit der Installation der Updates das Neugenerieren der Schlüssel gleich angestoßen.
Ich brauchte nur zu Bestätigen, dass ich die Schlüssel neu generieren will.

derRichard
15.05.08, 11:32
hi!

das betrifft nur debian (und die debian-basierenden distributionen).
und die sicherheit ist jetzt nicht von 99% auf 90% runter, sonder auf 0%.
auf dem von mir geposteten link finden sich _alle_ möglichen keys, die das debian-openssl erstellen kann.
das sind nur 32768 pro möglicher keylänge. die kann man in ein paar stunden alle durchtesten und schon hat man gewonnen.

//richard

derRichard
15.05.08, 11:35
Nochmal:

Bei mir hat er mit der Installation der Updates das Neugenerieren der Schlüssel gleich angestoßen.
Ich brauchte nur zu Bestätigen, dass ich die Schlüssel neu generieren will.

wir reden hier aber nicht nur von mini-servern mit einem ssh-zertifikat, das man schnell tauschen kann.

es gibt auch leute, die betreiben certificate authorities, die müsse _alle_ zertifikate zurückrufen. (stichwort vpn-server)

//richard

d@tenmaulwurf
15.05.08, 11:37
hi!

das betrifft nur debian (und die debian-basierenden distributionen).
und die sicherheit ist jetzt nicht von 99% auf 90% runter, sonder auf 0%.
auf dem von mir geposteten link finden sich _alle_ möglichen keys, die das debian-openssl erstellen kann.
das sind nur 32768 pro möglicher keylänge. die kann man in ein paar stunden alle durchtesten und schon hat man gewonnen.

//richard

AFAIK sind das nur Hashes, nicht die kompletten Keys.

marce
15.05.08, 11:39
Nochmal:

Bei mir hat er mit der Installation der Updates das Neugenerieren der Schlüssel gleich angestoßen.
Ich brauchte nur zu Bestätigen, dass ich die Schlüssel neu generieren will.
und was ist mit all den authorized_keys, die Debian-User auf ihren Root-Servern, in VPN-Gateways, https-Zertifikaten, ... eingetragen haben? Die müssen auch alle neu generiert und verteilt werden.

Hier (http://stefan.ploing.de/2008-05-15-debian-und-openssl-schonzeit-ist-vorbei) hat ein Bekannter von mir das recht anschaulich zusammengefasst...

Rain_maker
15.05.08, 11:57
Nur mal so als kleines Beisiel, wann es wirlich eklig wird.

Ein Arbeitskollege von mir hat Zugriff auf einen Cluster, auf welchem er "Molecular Modelling" betreiben kann.

Die Anzahl der Kisten im Cluster liegt IIRC im Bereich mehrerer hundert Kisten, auf allen läuft Debian und jeder der wahrscheinliche mehreren Tausend berechtigten User greift via SSH zu.

In der Haut des/der Admins, die nun sehr wahrscheinlich mehrere Tausend Keys neu erstellen und an _alle_ berechtigten User verteilen dürfen/müssen (und davon sind sicher nicht alle "IT-affin", also kann man sich die Masse der "Beschwerdemails" a la "Hilfe mein Login geht auf einmal nicht mehr" schon in etwa vorstellen) will ich jedenfalls nicht stecken.

marce
15.05.08, 12:05
Naja, das ist ja nur eine reine Fleißarbeit :-)

Viel interessanter ist herauszufinden, wie viele böse Menschen es durch den bereits verfügbaren Exploit geschafft haben, sich einen gratis-Account auf div. Servern zu holen?

Oder VPN-Gateways von Firmen, die evtl. Zugriff auf sensible Geschäftsdaten preisgegeben haben, weil sich jeder Yogi mit einem bel. PC am VPN anmelden konnte?

Für mich wäre die Meldung ein guter Grund, erst mal jeden Debianrechner in meiner Umgebung herunterzufahren und einem ausgiebigen Security-Audit zu unterziehen.

Wenn man dann noch überlegt, was denn alles von Debian und *buntu geforkt ist - kann einem ernsthaft schlecht werden...

-hanky-
15.05.08, 12:16
Habe ich gestern auch gelesen... hammerhart.

Das ist wohl in der Tat des Security-Super-GAU des Jahres. Es ist mir ehrlich gesagt aber auch wirklich unbegreiflich wie man mal eben so, offensichtlich ohne Plan was man tut, an Paketen herumpatchen kann. Allerdings war ich auch noch nie ein Freund der Art und Weise wie Debian ( und damit indirekt oder direkt auch Ubuntu ) an Paketen herumbastelt.

Bei mir hat Debian mittlerweile jeglichen Kredit verspielt. Erst gibt es 2005 wochenlang niemanden der sich um Sicherheitspatches kümmert und dann wird einfach so an kritischen Paketen herumgespielt.

@ marce: Danke für den Link, das Problem wird dort sehr schön und verständlich erläutert.

@ Dobodo: Das ist eine der krassesten Lücken in letzter Zeit und um das so einzuschätzen muss man kein "übereifriger, sicherheitsfanatischer Admin" sein! Das ist nicht mal eben so eine theoretische Lücke ohne großartige praktische Auswirkungen sondern das betrifft tausende Systeme. Wenn man wie du ganz offensichtlich keine Ahnung hat wovon man redet sollte man sich informieren oder den Rand halten!

@ Rain_Maker: Der Admin wird seinen Spass haben... Bei der Gelegenheit fällt mir gerade auf dass es wohl etliche Unis im Land gibt mit Servern auf Debian-/Ubuntu-Basis. Hab eben mal nachgeschaut, an meiner wird zum Glück OpenSuse bzw. Fedora genutzt...

-hanky-

Rain_maker
15.05.08, 12:35
Naja, das ist ja nur eine reine Fleißarbeit :-)

ACK.

Das Problem dürfte hier auch eher auf der anderen Seite liegen (bzw. sitzen *g*), zumindest weiß ich recht sicher, daß die Struktur auf Clientseite da sehr viel heterogener als "normal" (aka >= 95% sind Windowskisten auf denen dann putty läuft) ist.

Wenn man das also irgendwie automatisiert, im Sinne von $USER loggt sich via $SSH-CLIENT seines $BETRIEBSSYSTEMS ein und es wird automatisch ein neuer Key angeboten, der abgenickt werden muss, dann muss da eben etwas mehr als nur Putty berücksichtigt werden.

Aber auch das ist natürlich nur Fleißarbeit.

Von eventuellem Fehlverhalten von $USER jetzt mal ganz abgesehen (aka "Meldungen des Systems werden nicht gelesen und vor allem auch mit einem beherzten Klick auf Abbrechen quittiert"), aber OK, das ist dann ne andere Geschichte ....



Viel interessanter ist herauszufinden, wie viele böse Menschen es durch den bereits verfügbaren Exploit geschafft haben, sich einen gratis-Account auf div. Servern zu holen?


*AUTSCH*

(Bis vor kurzem konnte man zumindest noch zu recht behauten, daß ein mit PubKey gesicherter SSH-Zugriff kein potentielles Einfallstor darstellt, das relativiert sich natürlich jetzt gewaltig.)



Oder VPN-Gateways von Firmen, die evtl. Zugriff auf sensible Geschäftsdaten preisgegeben haben, weil sich jeder Yogi mit einem bel. PC am VPN anmelden konnte?


*AUTSCH²*



Für mich wäre die Meldung ein guter Grund, erst mal jeden Debianrechner in meiner Umgebung herunterzufahren und einem ausgiebigen Security-Audit zu unterziehen.


So langsam werden die Ausmaße etwas deutlicher; ich habe mir gestern mal mit meinen recht beschränkten Kenntnissen der Materie nur ein paar Minütchen überlegt, was jetzt so alles anstehen könnte.

Ehrlicherweise auf alles, was hier schon steht, bin ich auch nicht gekommen, und ich bin mir fast sicher, daß das eine oder andere Szenario bisher vergessen wurde, aber schon die paar "ekligen Gemeinheiten", die mir so spontan eingefallen sind, haben zu leichter Übelkeit geführt.

Nett auch (das fiel mir so spontan ein)

Man loggt sich auf $ONLINESHOP via https ein um seinen Warenkorb zu füllen usw. usf. ... (das Übliche halt).

Der "man-in-the-middle" hat dann unter Umständen grossen "SCHABSS" daran, mal den halben Katalog zu bestellen und das Theater, das auf den Kunden zukommt, dürfte nicht gerade gut fürs Herz und die Nerven sein.

Das ist zwar purer "Online-Vandalismus" ohne grossen eigenen Nutzen für den Angreifer, aber bei (D)DoS hat sich das ja auch "bewährt".



Wenn man dann noch überlegt, was denn alles von Debian und *buntu geforkt ist - kann einem ernsthaft schlecht werden...

Jepp, könnte sein, daß Pillen gegen Reisekrankheit in nächster Zeit guten Absatz finden .....

@-hanky-
Bei uns an der Uni ist in dem Fall "zum Glück" auch auf Linux-Clientseite Fedora Standard, ein paar der für mich interessanten Server laufen auf RH, also Schwein gehabt.

Greetz,

RM

fuffy
15.05.08, 12:39
Hi!


Hier (http://stefan.ploing.de/2008-05-15-debian-und-openssl-schonzeit-ist-vorbei) hat ein Bekannter von mir das recht anschaulich zusammengefasst...

"In kritischen Umgebungen müssen auch ssh-Keys, die zwar mit einer nicht kompromittierten Version generiert wurden, aber deren Secret Key auf einem System mit schwachem ssh-Host-Key lag, als kompromittiert betrachtet werden."
Hmm, auf von mir betreuten Kisten gabs zwar nen schwachen Host-Key (inzwischen alle neu generiert), aber meinen Secret-Key hat von denen noch keine gesehen. ssh-copy-id überträgt doch nur den Public-Key. Dann dürfte sich niemand per Key anmelden können. Mein SSH-Key wurde nicht auf einem Debian-System erzeugt.

Gruß
fuffy

PierreS
15.05.08, 13:05
Wenn man paranoid ist, müsste man sogar davon ausgehen, daß alle auf Debian basierten Server in den letzten zwei Jahren kompromittiert wurden. Damit wären alle Daten, die in dieser Zeit über jene Server gegangen sind "öffentlich". :-)

Schließlich kann man ja nicht davon ausgehen, daß dieses Problem zwei Jahre lang niemandem aufgefallen ist...

Newbie314
15.05.08, 13:06
Jetzt wäre ein Firefox- Add On nützlich das warnt wenn man sich per https mit einem Server verbindet der eines dieser Zertifikate nutzt...

Das würde für den nötigen Druck bei den Anbietern sorgen die Änderungen zügig durchzuführen ....

Dodobo
15.05.08, 13:44
Sollte man nun also keine https-Dienste wie Onlinebanking oder Webshops mehr mit Knoppix CD durchführen? Nur gut, dass es für solche Fälle noch das kleine Puppy Linux auf Slackware-Basis gibt. :D

Wobei das Anmelden an SSL-Servern ohne Berechtigung ja das eigentliche Übel ist, so wie ich das hier rauszulesen scheine. GMX Webmail, manche Webshops...unverschlüsselt...Gang und Gebe...leider, aber die Welt ist deswegen auch noch nicht zusammengebrochen. Vielleicht fällt ja morgen eine Atombombe oder ein Asteroid vom Himmel, dann hat sich das Debian-Problem erledigt. Wenn nicht, Glück gehabt, ist vielleicht dann auch nicht so schlimm. :D Wer was kaputtmachen will, schafft das auch, schwitzen dürfen die Admins, die besondere Verantwortung tragen. Privat muß man halt damit leben - und ich wette, wenn ich jetzt sofort 100 Einkäufe auf Debian-basierten Webshops machen würde, das nicht ein einziger Unfug aufgrund der Lücke geschehen würde. Das beruhigt mich,. egal, was die ganzen Admins hier reden. :D Ansonsten mach ich von meinem Rücktrittsrecht Gebrauch oder weise den Anbieter auf die Lücke hin. Ich lebe entspannt weiter, trotz der Lücke. ;) Gefährlicher sind wohl Autos mit abgefahrenen Reifen und Bremsen...

fuffy
15.05.08, 13:50
Sollte man nun also keine https-Dienste wie Onlinebanking oder Webshops mehr mit Knoppix CD durchführen?
Clientseitig hast du kein Problem, wenn du z.B. Iceweasel einsetzt, da Iceweasel wie alle Mozilla-Produkte NSS verwendet. Wenn aber der Server deiner Bank oder des jeweiligen Webshops Debian (oder eine darauf basierende Distribution) einsetzt, ist es möglich, dass Dritte mithören. Du solltest dich also besser gar nicht auf SSL-Verschlüsselung verlassen, wenn du nicht den Server-Key auf seine Sicherheit überprüft hast.

Gruß
fuffy

Veierabend
15.05.08, 13:51
Sollte man nun also keine https-Dienste wie Onlinebanking oder Webshops mehr mit Knoppix CD durchführen? Nur gut, dass es für solche Fälle noch das kleine Puppy Linux auf Slackware-Basis gibt. :D
Und was bringt dir Puppy, wenn dein Online Banking auf nem Debian Server stattfindet der noch keinen neuen Schlüssel hat? Dabei ist es völlig egal welches OS die Client Rolle übernimmt :p

Edit: zu langsam :D

Dodobo
15.05.08, 14:01
Ja, ich sag ja, authentifizieren (noch dazu bei ner Bank) is nich, aber wenn jemand meine Bestellung abhört, is das nich so brisant. Ich krieg die ja eh nochmal unverschlüsselt per Email zugeschickt, manchmal noch mit dem Passwort im Klartext. :D Is trotzdem noch nie was passiert. Mehr Gedanken würd ich mir da mal machen, dass mittlerweile recht preiswert Schnurlostelefone für jedermann abhörbar sind, vielen langweilig ist und die Bank oder Shops einen z.B. zur Authentifikation nach dem Geburtsdatum fragen, was man wiederum als Bekannter weiß oder auf HPs, in Bloqs (Glückwünsche) und Studivz etc. nachlesen kann. Oder um Shops, welche einen anhand Kundennummer und Geburtsdatum ODER Wohnort einfach was telefonisch was bestellen lassen, und bei jeder Bestellung die Kundennummer dick auf die Außenseite des Paketes drucken. Aber irgendwo muß Sicheheit ja mal anfangen, und wo, wenn nicht bei Linux oder Debian...

War ja schon meine Eingangsfrage/-feststellung, dass https nun eigentlich für den Arsch ist. Aber was kann noch passieren? Bankdaten sind ggf. eh schon in irgendeinem Datensatz, weil irgendein Rechner verseucht ist (meist Windows-Clients der Mitarbeiter der Firmen, wo man was bestellt etc.). Kann man nur Kontoauszüge gucken und ab und zu mal die Kontodaten wechseln alle paar Jahre.

Und Unterschriften bei Beträgen unter 1000 EUR vergleicht auch kaum eine Bank...allerdings muß man dazu dann vor Ort sein, um solche Überweisungen einzulösen. DAS ist doch mal ne Lücke...bzw. AUCH eine Lücke. Wir sind von Lücken UMZINGELT...

Übrigens: Mein PW-Erinnerungsfrage bei GMX wird mit Miauzmiau beantwortet. :D
(Is nich wahr!)

Okay, back zur Lücke... ;)

jfried
15.05.08, 14:53
Hi hanky,


Habe ich gestern auch gelesen... hammerhart.

[...] Allerdings war ich auch noch nie ein Freund der Art und Weise wie Debian ( und damit indirekt oder direkt auch Ubuntu ) an Paketen herumbastelt.

Bei mir hat Debian mittlerweile jeglichen Kredit verspielt. Erst gibt es 2005 wochenlang niemanden der sich um Sicherheitspatches kümmert und dann wird einfach so an kritischen Paketen herumgespielt.
[...]
-hanky-

ich will jetzt nichts schoenreden, aber hier hat eher das Prinzip von Opensource nicht gegriffen. Der Debian Entwickler hat auf der OpenSSL Mailingliste nachgefragt ob er diese Zeile bedenkenlos entfernen kann und Ihm wurde das bestätigt.

(http://marc.info/?l=openssl-dev&m=114651085826293&w=2)


Viele Grüße

jfried

Toobles
15.05.08, 15:01
Naja, wo steht da das es um Debian geht? Richtig, nirgendwo. Das Ganze erweckt eher den Eindruck das es nur um das Debuggen von OpenSSL geht.
Außerdem steht da weder das es um einen Patch für Debian geht, noch wurde der Patch an OpenSSL weitergegeben.

Ich kann da echt nicht erkennen wo OpenSSL Schuld haben soll.

Newbie314
15.05.08, 15:14
wenn du nicht den Server-Key auf seine Sicherheit überprüft hast.

Wie mache ich als Laie das am einfachsten ? Nicht dass ich glaube dass jemand meinen Bank-Login knackt, aber falls meine Bank die Lücke in ein paar Tagen noch offen hätte würde ich das gerne bemerken und eine entsprechende Beschwerdemail loswerden....

cane
15.05.08, 18:15
Wie mache ich als Laie das am einfachsten ?

http://security.debian.org/project/extra/dowkd/dowkd.pl.gz

mfg
cane

Newbie314
15.05.08, 19:41
Klasse Tool, vor allem da in Perl geschrieben. Etwas dünn finde ich die Anleitung.
Wenn ich richtig verstanden habe ist wenn ich

./dowkd.pl host www.postbank.de eingebe und das System ohne Fehlermeldung zurückkommt alles in Ordnung ?

Wenn das so ist ist bei den Servern bei denen ich auf ssl bestehe alles in Butter ;)

Dodobo
15.05.08, 20:42
Schade um die neue Knoppix... :( Dauert wieder nen Jahr...

Newbie314
15.05.08, 20:46
??? Dodobo: das betrifft dich doch gar nicht ! Nur wenn du einen Server oder einen Login per SSL Keys zulassen würdest .. und dann müsstest du nur die Keys auf einem System generieren bei dem der Fehler behoben ist... und sie dem Knoppix System übergeben.

Der Fehler betrifft nur Keys die mit der fehlerhaften Lib generiert werden ....

@cane: ich habe natürlich ein "netstat" gemacht bevor ich meine Frage gestellt habe. Das Script verbindet sich definitiv über SSL mit dem host ..

marce
15.05.08, 20:54
hier sind auch noch ein paar interessante Infos:
http://wiki.debian.org/SSLkeys

Additionally, simply the use of DSA keys may have compromised them. A strong key (i.e., generated with a 'good' OpenSSL) but used locally on a machine with a 'bad' OpenSSL must be considered to be compromised. This is due to an 'attack' on DSA that allows the secret key to be found if the nonce used in the signature is reused or known.
Liste bei Debian betroffener Apps:

# OpenSSH (both server and user keys)
# OpenVPN
# OpenSWAN/StrongSWAN
# DNSSEC
# key material for X.509
# encfs
# Tor
# postfix, exim4, sendmail and other MTAs when using SSL/TLS
# cyrus imapd
# courier imap/pop3
# dovecot with imaps/pops support
# apache2 (ssl certs)
# dropbear
# cfengine
# puppet
# xrdp
# tinc
# vsftpd SSL certificates for FTPS
# proftpd SSL/TLS certificates for FTPS
# ftpd-ssl SSL certificates for FTPS
# telnetd-ssl SSL certificates for SSL-Telnet
#DomainKeys (DK) and DKIM


??? Dodobo: das betrifft dich doch gar nicht ! Nur wenn du einen Server oder einen Login per SSL Keys zulassen würdest .. und dann müsstest du nur die Keys auf einem System generieren bei dem der Fehler behoben ist... und sie dem Knoppix System übergeben.
(1) Knoppix wird auch oft installiert
(2) LiveCDs werden oft genutzt, um quasi als nicht-kompromitierbares statisches, sicheres System für die Keyerstellung verwendet zu werden.


Der Fehler betrifft nur Keys die mit der fehlerhaften Lib generiert werden ....
... und das können sehr viele sein. Siehe die Liste oben.

Debian ist eben auch nicht selten in der Welt.