Qbi's Weblog

Lest ihr regelmäßig Bugreports oder Meldungen über Schwachstellen bei SSL/TLS? Wie fühlt ihr euch so? Zur Erinnerung:

Ausschnitt aus einer Folie aus dem MUSCULAR-Programm der NSA

• 22. Februar 2014: Apple wird wegen des goto-fail-Bugs belächelt
• 3. März 2014: Die freie Bibliothek GnuTLS hat einen ähnlich schweren Bug
• 7. April 2014: OpenSSL vermeldet die Heartbleed-Schwachstelle

Das heißt, drei Monate in Folge gab es schwere Sicherheitslücken in Software zur Verschlüsselung. Ganz unwillkürlich fühlt man sich an die Folien aus dem NSA-Programm MUSCULAR erinnert.

Die letztgenannte Schwachstelle ist vermutlich die bislang schwerste. Denn damit ist es möglich, den Arbeitsspeicher eines Computers auszulesen. Dies funktioniert sowohl auf der Seite des Servers wie auch beim Clientprogramm. Dazu ist es notwendig, dass das Programm OpenSSL verwendet und eine Erweiterung von SSL namens Heartbeat aktiviert hat. Dies ist beispielsweise bei Android in der Version 4.1.1 der Fall. Mozilla Firefox hingegen nutzt die NSS-Bibliothek und ist nicht betroffen. Die Webserver nutzen hingegen recht oft die OpenSSL-Bibliothek und sind damit betroffen, falls die Version 1.0.1 bis 1.0.1f von OpenSSL verwendet wird. Sollte jemand von euch die Software nutzen, so upgraded auf mindestens 1.0.1g oder deaktiviert Heartbeat in OpenSSL. Gerade letzteres kann man aus meiner Sicht problemlos tun. Denn bisher fand ich keinen sinnvollen Anwendungsfall für Heartbeat.

Doch wie funktioniert diese Lücke eigentlich? Heartbeat (RFC 6520) ist eine Erweiterung für TLS. Ein Teilnehmer einer Verbindung sendet beliebige Daten an den Empfänger. Dieser antwortet mit einer Kopie dieser Daten und zeigt somit, dass die Verbindung noch steht und alles in Ordnung ist. Das Problem dabei ist, dass in einer Anfrage zwei Längenfelder vorhanden sind. Ein Angreifer sendet einfach ein Byte Daten und behauptet, er hätte 64 kB gesendet. OpenSSL liest nun die 64 kB aus dem eigenen Puffer und sendet die Daten zurück an den Angreifer. Der Angreifer kann den Angriff immer und immer wieder starten und erhält so eventuell immer wieder ein neues Stück Arbeitsspeicher (siehe Kommentar von Florian Diesch). Bruce Schneier hat mit seinen Worten vollkommen recht:

Catastrophic" is the right word. On the scale of 1 to 10, this is an 11.
https://www.schneier.com/blog/archives/2014/04/heartbleed.html

Ich hatte in meinem 30C3-Vortrag schon ein OpenSSL-Beispiel reingenommen. Das sollte zeigen, wie kompliziert es sein kann, mit der Software sicheren Code zu schreiben. Auch andere sind, über die Codequalität gestolpert. Daher sind Leute gefragt, die einen detaillierten Blick auf OpenSSL werfen und die Software verbessern. Dazu zählt auch die bessere Lesbarkeit des Codes oder gute Dokumentation.

Wenn ihr wissen wollt, ob ihr betroffen seit, schaut lokal auf die OpenSSL-Version, nutzt die Zeile openssl s_client -connect example.com:443 -tlsextdebug 2>&1| grep ‘server extension “heartbeat” (id=15)’ || echo safe oder verwendet den Testservice von Lutz Donnerhacke oder Filippo Valsorda.

Weiterlesen:

Passwort und Nutzername im Dump der Daten von Yahoo! Mail

• Netzpolitik.org: HeartBleed: Ein OpenSSL-Bug, der weitreichende Folgen haben könnte
• Heise: Passwort-Zugriff: Heartbleed-Lücke mit katastrophalen Folgen
• Heise Security: So funktioniert der Heartbleed-Exploit
• Zeit: Heartbleed – auf der Gruselskala bis 10 ist es die 11
• Ars technica: Critical crypto bug exposes Yahoo Mail, other passwords Russian roulette-style
• Vox: The heartbleed bug, explained
• existential type crisis : Diagnosis of the OpenSSL Heartbleed Bug
• The Register: Anatomy of OpenSSL’s Heartbleed: Just four bytes trigger horror bug
• Erweiterung Chromebleed für Google Chrome
• pacemaker – Client Exploit

Do not login to Yahoo! The OpenSSL bug #heartbleed allows extraction of usernames and plain passwords! pic.twitter.com/OuF3FM10GP

— Mark Loman (@markloman) 8. April 2014

Das Desaster um die niederländische Zertifizierungsstelle DigiNotar zieht derzeit immer noch seine Kreise. Mir scheint es noch zu früh, um hier etwas dazu zu schreiben. Vielmehr will ich ein paar Worte verlieren, wie ich „meine eigene CA betreibe“. Denn schon seit längerem vertraue ich nicht, den von den Browsern mitgelieferten Zertifizierungsstellen (CA). Zumeist lösche ich alle und gebe dann einzeln Vertrauen.

Der beste Weg, um einem SSL-Zertifikat zu vertrauen, wäre, sich bei dem Betreiber zu melden und über einen sicheren Kanal den Fingerprint des Zertifikats zu klären. Mein Browser zeigt mit für die Seite Wikipedia-SSL-Seite den Fingerprint (SHA-1) BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E an. Wenn ich bei der Wikipedia anrufe und diese mir denselben nennen, so habe ich das korrekte Zertifikat. Dabei nehme ich natürlich an, dass das Telefon ein sicherer Weg zum Austausch der Informationen ist. Aber beispielsweise druckt die lokale Sparkasse eben diesen Fingerprint auf ihre Dokumente. Damit kann ich das als Kunde leicht verifizieren.

Wie das Beispiel Wikipedia aber schon zeigt, ergibt sich da ein Problem.Woher bekomme ich den Fingerprint? Muss ich bei Jimmy Wales direkt anrufen oder gar nach FloridaKalifornien¹ reisen? Hier kam nun meine Idee ins Spiel.

Ich habe auf diversen Servern einen Zugang, d.h. ich kann mich von der Ferne einloggen und dann dort arbeiten. Die Rechner stehen in verschiedenen Netzen und zum Teil auf verschiedenen Kontinenten. Nun logge ich mich auf den Servern ein, lade das Zertifikat herunter und lasse mir den Fingerprint anzeigen. Wenn dieser auf allen Rechner gleich ist, dann gehe ich davon aus, dass ich das korrekte Zertifikat angezeigt bekomme. In dem Fall akzeptiere ich das und vertraue dem. Sollten die Fingerprints abweichen, dann akzeptiere ich das nicht und recherchiere dem in der Regel ein wenig hinterher.

Jörg Sommer hat das nun ein wenig automatisiert und ein zsh-Skript (Quelltext weiter unten) geschrieben. Das wird folgendermaßen aufgerufen:

ssl-fp-check [-l] sslsi.te[:port] ssh1 [ssh2] [ssh3] ...

Dabei ist sslsi.te die Webseite, die geprüft werden soll. Ohne die Angabe eines Ports verwendet das Skript standardmäßig 443. Danach wird eine oder mehrere SSH-Verbindungen angegeben. Das Skript wird nun versuchen, sich überall einzuloggen und gibt dann den Fingerprint aus. Für den Fall, dass es auf dem Zielsystem kein OpenSSL gibt, existiert die Option -l. Dabei wird dann ein Tunnel gebaut und das lokale installierte OpenSSL verwendet.

Also für Wikimedia habe ich folgendes eingeben:

ssl-fp-check secure.wikimedia.org a b c d
a: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E
b: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E
c: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E
d: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E

Die SSH-Server a, b, c und d gaben also denselben Fingerprint aus. Also würde ich dem ganzen doch vertrauen.

Ich werde das Skript jetzt wahrscheinlich immer verwenden. Es macht das Leben doch deutlich einfacher.

Man höre und staune: Heute wurde OpenSSL 1.0 veröffentlicht. Aus der Meldung:

The OpenSSL project team is pleased to announce the release of version 1.0.0 of our open source toolkit for SSL/TLS. This new OpenSSL version is a major release and incorporates many new features as well as major fixes compared to 0.9.8n. For a complete list of changes, please see http://www.openssl.org/source/exp/CHANGES.

The most significant changes are:

• RFC3280 path validation: sufficient to process PKITS tests.
• Integrated support for PVK files and keyblobs.
• Change default private key format to PKCS#8.
• CMS support: able to process all examples in RFC4134
• Streaming ASN1 encode support for PKCS#7 and CMS.
• Multiple signer and signer add support for PKCS#7 and CMS.
• ASN1 printing support.
• Whirlpool hash algorithm added.
• RFC3161 time stamp support.
• New generalised public key API supporting ENGINE based algorithms.
• New generalised public key API utilities.
• New ENGINE supporting GOST algorithms.
• SSL/TLS GOST ciphersuite support.
• PKCS#7 and CMS GOST support.
• RFC4279 PSK ciphersuite support.
• Supported points format extension for ECC ciphersuites.
• ecdsa-with-SHA224/256/384/512 signature types.
• dsa-with-SHA224 and dsa-with-SHA256 signature types.
• Opaque PRF Input TLS extension support.
• Updated time routines to avoid OS limitations.

Um die auch hier angesprochene OpenSSL-Lücke wird zwischen den OpenSSL-Team und Debian eine Diskussion geführt. Der Paketbetreuer von Debian fragte damals auf der Liste openssl-dev nach und Ulf Möller, einer der Entwickler, antwortete. Die OpenSSLer behaupten nun, es sei die falsche Liste gewesen und die Debianer haben darauf eine großartige Antwort.

Kürzlich meldete sich Ulf Möller nochmal zu Wort. In seiner Antwort auf die Frage ging er nicht davon aus, dass der Quellcode gepatcht werden soll und dass sein Gegenüber natürlich grundsätzlich ein Verständnis für den Quellcode entwickelt hat. Aus der Diskussion entwickelte sich das schöne Zitat:

Und jetzt komme ich mir vor wie ein Arzt, der dachte, dass er mit einem Kollegen über Operationstechniken diskutiert hat, und nun plötzlich erklären soll, wieso er das Kettensägenmassaker nicht verhindert hat.

Über die schwere Sicherheitslücke im OpenSSL-Paket von Debian wurde in verschiedenen Quellen berichtet. Wer mehr Informationen haben will, findet im Debian-Wiki Anweisungen. Außerdem stehen bei Zak B. Elep Hinweise und HD Moore stellte auch eine nette Seite zusammen. Doch was bedeutet diese Lücke für Tor? Gibt es da überhaupt Probleme?

In der Tat gibt es da richtig große Probleme, wie auch das Advisory zeigt. Tor nutzt für seine Krypto sehr intensiv OpenSSL und ist damit direkt betroffen. Roger Dingledine, einer der Entwickler, hat in einem längeren Artikel im Blog zu Problemen Stellung genommen.

Eines der entstandenen Probleme sind Tor-Server, die schwache Schlüssel einsetzen. Insgesamt handelt es sich um mindestens ein Siebtel aller Server. Angreifer können hier alle möglichen Attacken fahren und insbesondere auch unten bestimmten Bedingungen in die Pakete schauen. Effektiv wird also die Verschlüsselung aufgehoben. Die Tor-Entwickler haben daher alle derartigen Schlüssel gesperrt und ein Server mit einem veralteten Schlüssel kann in Zukunft nicht mehr als Server agieren.

Weiterhin verteilen Verzeichnisserver die Informationen über Tor-Server an die Tor-Clients. Die neueste Protokollversion ist die V3. Wer dies nutzt, könnte ein Problem bekommen. Hier schafft die neueste Tor-Entwicklerversion 0.2.0.26-rc Abhilfe. Dort werden ausschließlich korrekte Schlüssel ausgeliefert und die schwachen sind gesperrt.

Peter Palfrader hat sehr schnell reagiert und eine neue Version des Debian-Paketes hochgeladen. Wenn du also Debian, Ubuntu oder ähnliches nutzt, solltest du schnellstens die aktuellste Version installieren, um dich vor den obigen Problemen zu schützen.