[FYI] OpenSSL-Schlüssel in Debian/Ubuntu sind unsicher

[Joe User]

http://www.golem.de/0805/59657.html
http://www.heise.de/newsticker/meldung/107808

Demnach müssen Debian/Ubuntu/etc-User sämtliche Schlüssel/Zertifikate erneuern, viel Spass ;)

Noch ein Grund mehr Debian und seine Derivate nicht mehr einzusetzen...

[thorsten]

Als ich die security-mail heute kurz nach zwei bekam, dachte ich nur "Hoffentlich liest das nicht der Markus" - aber zu spät ](*,)

EDIT:
Um aber noch was produktives beizusteuern hier der Hinweis wie ich meine hostkeys erneuert habe:

Code: Select all

mkdir -p /etc/ssh/backup
mv /etc/ssh/*host* /etc/ssh/backup/
ssh-keygen -b 1024 -t dsa -f /etc/ssh/ssh_host_dsa_key -N ''
ssh-keygen -b 2048 -t rsa -f /etc/ssh/ssh_host_rsa_key -N ''
chmod 0600 /etc/ssh/ssh_host_*
chmod 0644 /etc/ssh/ssh_host_*pub
/etc/init.d/ssh restart

Oder mit den debian-Bordmitteln

Code: Select all

rm /etc/ssh/*host*
dpkg-reconfigure openssh-server
service ssh restart

Mittels ssh-keygen -R $HOST kann dann der alte key aus der clientseitigen ~/.ssh/known_hosts entfernt werden. Gerade wenn die Datei gehashed ist, erspart einem das evtl. ein wenig Editierarbeit...

[frey]

Es gibt schon die ersten Tools die alle möglichen SSH Schlüssel erzeugen und mit denen man sich auf den Systemen einloggen kann.
Wird nicht mehr lange dauern bis die ersten Brute Force Attacken los gehen :?
http://metasploit.com/users/hdm/tools/debian-openssl/

[nyxus]

Und vielleicht noch der Hinweis an die Nostalgiker, daß es für Sarge zumindest bisher keine Updates gab. Ein Wechsel zu Etch ist spätestens jetzt anzuraten.

[frey]

Sarge ist von dem Fehler nicht betroffen. Der Fehler gibt erst seit Etch.
Also ist Sarge in dieser Hinsicht sicherer :-D

[nyxus]

Sarge ist von dem Fehler nicht betroffen. Der Fehler gibt erst seit Etch.
Also ist Sarge in dieser Hinsicht sicherer :-D

Gerade wollte ich meinen Beitrag editieren (habe erst nach dem Schreiben mein erstes Käffchen in der Hand und es bemerkt). Aber danke für die Korrektur.

[EdRoxter]

Wie schön, dass PuTTYgen davon nicht betroffen ist. Meine User würden sonst weinen... :)

[Joe User]

Wie schön, dass PuTTYgen davon nicht betroffen ist. Meine User würden sonst weinen... :)

Per PuTTYgen lassen sich auch openSSH-Keys importieren, insofern könnten auch einzelne Deiner User betroffen sein. Debian/Ubuntu in einer VM zum Generieren der Schlüssel reicht ja schon aus, gibt ja genug derartige HowTos im Netz. Man kann sich nie sicher sein wann Murphy wieder zuschlägt...

[EdRoxter]

Neinnein, ich hab die Keys an einer Windoofs-Maschine komplett selbst generiert und den Usern zugewiesen, und das eben mit Puttygen selbst. Und natürlich habe ich alle Pubkeys nun überprüft und es sind nach wie vor ausschließlich die eingerichtet, die ich selbst generiert hab. So paranoid bin ich dann doch. :)

Und wenn eine Verwundbarkeit bei Putty festgestellt wird.. Tja, dann darf ich wohl wieder ran. :)

[daemotron]

http://metasploit.com/users/hdm/tools/d ... epkza7.jpg

Nicht von mir, bin leider nicht selbst auf sowas gekommen :D

[nyxus]

http://metasploit.com/users/hdm/tools/d ... epkza7.jpg

Nicht von mir, bin leider nicht selbst auf sowas gekommen :D

Der "Code" kommt aus den sehr empfehlenswerten XKCD-Comics: http://xkcd.org/

[Roger Wilco]

Da ist noch einer auf der gleichen Seite: http://img502.imageshack.us/img502/2996 ... jp7aw9.jpg ;)

[blnsnoopy26]

Hab heute auch das Sicherheitsupdate gleich gemacht nach dem ich das hier gelesen hatte und hätte mich fast ausgesperrt :lol:
Hatte ne Zeile nicht gelesen das alte Keys dann nicht mehr funktionieren - zum glück hatte ich noch eine Aktive Verbindung offen und habe vorher noch zur Sicherheit Login per Password erlaubt so das ich mich dann immer noch einloggen konnte.

neuen pubkey erstellt und nu geht wieder alles bis jetzt :-D :)

Voher bekam ich die nette Meldung:

Code: Select all

May 16 23:42:46 s17 sshd[9375]: Public key xxxxxx blacklisted (see ssh-vulnkey(1))

Mit meinem neuen pubkey jetzt die Meldung

Code: Select all

May 17 00:11:43 s17 sshd[2667]: Accepted publickey for xxxx from xxx.xx.xx.xx port xxx ssh2

:) :)

[fulltilt]

Was ist eigentlich mit den ganzen .pem in /usr/lib/courier/rootcerts ?

[Joe User]

Was ist eigentlich mit den ganzen .pem in /usr/lib/courier/rootcerts ?

Wenn sie auf einem betroffenen System erstellt wurden, müssen selbstverständlich auch diese ersetzt werden.

[fulltilt]

Danke,

habe bislang nichts zu den rootcerts in /usr/lib/courier/rootcerts finden können ... diese wurden / werden wohl bei der Installation von courier / courier-ssl automatisch angelegt ...
Wie kann man diese neu generieren bzw. ist das mit einem courier Update möglich?

Was ist eigentlich mit den ganzen .pem in /usr/lib/courier/rootcerts ?

Wenn sie auf einem betroffenen System erstellt wurden, müssen selbstverständlich auch diese ersetzt werden.

[Joe User]

Wie kann man diese neu generieren bzw. ist das mit einem courier Update möglich?

Ich habe keine Ahnung was Debian da treibt, aber die nötigen Schritte müssen irgendwo im courier-ssl.deb vermerkt sein...

[fulltilt]

Ich habe keine Ahnung was Debian da treibt, aber die nötigen Schritte müssen irgendwo im courier-ssl.deb vermerkt sein...

EDIT:
Habe mal versucht die rootcerts in /usr/lib/courier/rootcerts mit einer Neuinstallation von courier-pop-ssl courier-imap-ssl zu erneuern ... da scheint sich nichts zu ändern.
Die meisten waren von Feb. 07 und das Erstellungsdatum ist auch nach einer Neuinstallation noch gleich - also keine Änderung.
Keine Ahnung ob die überhaupt ersetzt werden sollen ...

Danke Dir,

z.Z. sind kaum ausreichende Infos über sonstige Baustellen (rootcerts) zu bekommen, ist mir auch nur zufällig aufgefallen. Da tauchen sicherlich noch andere Locations auf. Ich denke ich werde courier-ssl komplett entfernen und alles neu anlegen zur Sicherheit.

[Joe User]

Offenbar sind nicht nur unter Debian generierte Keys betroffen, sondern auch alle auf vermeintlich sicheren Systemen erstellte DSA-Keys:
http://www.fsfe.org/en/fellows/tonnerre ... akness_faq

I have put my securely generated public SSH user key onto a Debian system. Should I replace it?

This depends. If your key is an RSA key, it is not compromitted simply by putting the public key onto a server and authenticating against it. The SSH 2.0 protocol, as described in RFCs 4252 and 4253, part of the token being signed as challenge by the user is the “session identifier”, which is a hash from the key exchange. This effectively prevents replay attacks of authentication processes done using a non-vulnerable SSH key, because the random material used as challenge is not only controlled by the vulnerable SSH host, but also by the non-vulnerable client. Thus, the data your SSH key has to sign as a challenge is not vulnerable to the weak PRNG of the SSH server, and thus cannot compromise your key.

This is however not true for DSA keys. DSA has a weakness when used in the Diffie-Hellmann key exchange process, rendering it basically uneffective. If the attacker gets hold of the random number used by the Debian SSH server in the key exchange process, this can be used to calculate the private DSA key from the public key with a complexity of 216, being 65'536.

[danton]

Was ist eigentlich mit den ganzen .pem in /usr/lib/courier/rootcerts ?

Das sind die Stammzertifikate der verschiebenden Zertifizierungsstellen wie Thawte, TC Trustcenter usw.
Die kannst du nicht neu generieren, sondern sie müssen von der jeweiligen Zertifizierungsstelle neu erstellt und zur Verfügung gestellt werden, wenn sie betroffen sein sollten.

[fulltilt]

Danke,
nur wie soll man das wissen - oder spielt das bei den Stammcerts keine Rolle?
Da liegt unter anderem auch noch eine ca.crt und sub.class2.server.ca.crt dabei.

Was ist eigentlich mit den ganzen .pem in /usr/lib/courier/rootcerts ?

Das sind die Stammzertifikate der verschiebenden Zertifizierungsstellen wie Thawte, TC Trustcenter usw.
Die kannst du nicht neu generieren, sondern sie müssen von der jeweiligen Zertifizierungsstelle neu erstellt und zur Verfügung gestellt werden, wenn sie betroffen sein sollten.

[danton]

Ich habe die beiden von dir genannten Dateien auf meinem System nicht. Evtl. mal ein selbst erstelltes CA, von dem es Zertifikate sind?

Code: Select all

openssl x509 -in filename.crt -noout -text

zeigt dir das Zertifikat in lesbarer Form an. Die PEM-Dateien lassen sich auch per einfachem cat, more oder less anzeigen.
Die beiden crt-Dateien können u.U. natürlich unsicher sein, kommt halt drauf an, wie alt sie sind.

[fulltilt]

Danke danton,

das ist seltsam - nach dem Datum stammen diese beiden von 2005 - also nicht von mir erstellt.
Dieses System wurde vor einem Jahr erst installiert.
Ich hau die jetzt einfach mal weg :roll:

Ich habe die beiden von dir genannten Dateien auf meinem System nicht. Evtl. mal ein selbst erstelltes CA, von dem es Zertifikate sind?

Code: Select all

openssl x509 -in filename.crt -noout -text

zeigt dir das Zertifikat in lesbarer Form an. Die PEM-Dateien lassen sich auch per einfachem cat, more oder less anzeigen.
Die beiden crt-Dateien können u.U. natürlich unsicher sein, kommt halt drauf an, wie alt sie sind.