Am 13.05.2008 kam eine Meldung über den Heise-Ticker, dass Debian durch einen Patch eine Schwachstelle bei der Schlüsselgenerierung eingepflegt hat. Das Brisante daran ist, dass dieser Patch vor nahezu zwei Jahren eingespielt wurde.
Was passiert genau dabei? Der Patch hat dafür gesorgt, dass der Zufallszahlengenerator aus den Prozess-IDs gefüttert wird. Der Wertebereich ist unter Linux mit 1-32767 äußerst eingeschränkt. Jede Software, die diesen Generator benutzt, erzeugt somit schwache Schlüsselpaare. Dazu gehört z.B. SSH. Jeder Rechner, der nach dem September 2006 mit Debian oder Ubuntu installiert wurde, generiert somit bei der Installation ein schwaches Host-Key-Pärchen. Jeder Benutzer, der unter Ubuntu oder Debian einen neuen Private Key zum Einloggen generiert hat, hat somit auch ein schwaches Schlüsselpärchen generiert. Damit können die Schlüssel sehr schnell geknackt werden.
Was heißt das in der Konsequenz? Das heißt, dass alle mit Debian oder Ubuntu erzeugten Schlüssel die nach dem September 2006 generiert wurden neu generiert werden müssen. Macht man über den üblichen Weg ein Software Upgrade, wird das für die SSH Host Keys automatisch erledigt. Loggt man sich danach auf so einem aufgefrischtem Rechner ein, wird man abgewiesen mit dem Hinweis, dass in der known_hosts-Datei der Schlüssel nicht mehr passt. Der Eintrag in dieser Datei sollte daher gelöscht werden. Das SSH-Paket hat jetzt ein neues Tool: ssh-vulnkey, mit dem die Schlüssel in der authorized_keys-Datei überprüft werden können. Schwache Schlüssel sollten aus dieser Datei entfernt werden. Zusätzlich lässt ein SSH-Daemon diese Schlüssel beim Einloggen nicht mehr zu. Das Neugenerieren eines Schlüssels ist dabei kein Problem. Eher ist es problematisch, dass der Public Key auf Dutzenden von Rechnern untergebracht sein kann. Ein weiteres Problem sind SSL-Zertifikate, so wie sie für Webseiten verwendet werden. Selbst, wenn man keine selbstsignierten Zertifikate verwendet und Zertifikate kauft, wird der Private Key selbstgeneriert. In der Konsequenz müssen nicht nur die Zertifikate neu generiert bzw. gekauft werden, sondern der Private Key muss komplett neu samt Certificate Request generiert werden.
In einem Unternehmen wie itemis mussten nicht weniger als 30 Zertifkate neu generiert werden. Diese mussten natürlich auch auf den Hosts installiert werden. Hierbei kam wenigstens die modellgetriebene Serverkonfiguration unterstützend zum Einsatz. Die Entwicklungsrechner haben zwar selbstsignierte Zertifikate, aber gerade für die öffentlich zugänglichen Server mussten neue Zertifkate gekauft werden. Zusätzlich kam die Überprüfung der SSH-Schlüssel. Die Software-Upgrades haben die Host Keys automatisch erneuert. Die Überprüfung und der Ersatz der User-Schlüssel hat aber sehr viel mehr Aufwand gekostet. Alles in Allem hat dieser Vorgang zwei Tage Arbeit gekostet.
Hat sich der Aufwand gelohnt? Wer hier nein sagt, handelt schlichtweg grob fahrlässig! Im Moment ist es nur Aufwand. Aber langfristig möchte man sich nicht der Gefahr aussetzen, dass Daten ausspioniert werden oder gar Rechner gehackt werden. Die heutige Meldung begründet diese Sorge. Es lassen sich ohne wenig Probleme von außen Rechner ermitteln, die sich hacken lassen!
Wer mehr zu diesem Thema lesen möchte und wie man mit dieser Schwachstelle umgeht, können Sie hier lesen:
http://www.heise.de/security/Der-kleine-OpenSSL-Wegweiser–/artikel/108001
Es gibt auch ein Tool, das schwache Schlüssel ausfindig machen kann. Es hat aber den Nachteil, dass es nicht alle Schlüssel erkennt. Im Zweifel sollte man lieber einen Schlüssel zu viel als zu wenig neu generieren:
http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
Sorry, the comment form is closed at this time.