it-swarm.com.de

Welche Kunden sind nachweislich anfällig für Heartbleed?

Auf mehrereSeiten wird wiederholt, dass Angreifer bis zu 64 KB Speicher vom Server oder Client abrufen können, der eine für Heartbleed anfällige OpenSSL-Implementierung verwendet (CVE-2014-0160) ). Es gibt DutzendevonTools , die den Fehler in Serveranwendungen aufdecken.

Bisher habe ich kein einziges Tool gesehen, das den Fehler in Clientanwendungen ausnutzt. Ist es so schwer, den Fehler bei Kunden auszunutzen? Sind Kunden tatsächlich verwundbar oder nicht?

73
Lekensteyn

Tatsächlich ja sind Clients anfällig. Bisher wurde die Aufmerksamkeit auf Server gerichtet, da diese viel offener für die Nutzung sind. (Fast) jeder kann eine Verbindung zu einem öffentlichen HTTP/SMTP/... Server herstellen.

Dieser Blog beschreibt, wie der Fehler tatsächlich funktioniert (er erwähnt dtls_process_heartbeat(), aber tls_process_heartbeat() ist in gleicher Weise betroffen). Diese Funktion wird sowohl für Clients als auch für Serveranwendungen verwendet, daher sollten auch Clients anfällig sein.

Gemäß RFC 6520 sollten während eines Handshakes keine Herzschläge gesendet werden. In der Praxis akzeptiert OpenSSL Herzschläge direkt nach dem Senden eines ServerHello (dies ist die Aufgabe von ssltest.py von Jared Stafford). Bei weiteren Tests habe ich festgestellt, dass Server Clients missbrauchen können, indem sie ein Heartbeat-Recht senden, nachdem auch das ServerHello gesendet wurde. Es löst den gleichen Fehler aus.

Ein Proof of Concept finden Sie in meinem Repo unter https://github.com/Lekensteyn/pacemaker . Aus seiner README:

Die folgenden Clients wurden vor dem Handshake gegen 1.0.1f getestet und haben Speicher verloren:

  • MariaDB 5.5.36
  • wget 1.15 (leckt Speicher früherer Verbindungen und eigenen Status)
  • curl 7.36.0 (https, FTP/IMAP/POP3/SMTP mit --ftp-ssl)
  • git 1.9.1 (getesteter Klon/Push, leckt nicht viel)
  • nginx 1.4.7 (im Proxy-Modus verliert der Speicher früherer Anforderungen)
  • links 2.8 (Lecks Inhalt früherer Besuche!)
  • KDE 4.12.4 (Kioclient, Dolphin, getestet https und ftps mit kde4-ftps-kio)
  • Exim 4.82 (ausgehendes SMTP)

Es wurde gezeigt, dass tatsächlich 64 KB Speicher (65535 Byte) zurückgegeben werden können. Es wurde auch gezeigt, dass Clients (wget, KDE Dolphin, ...) Daten wie frühere Anforderungen, die möglicherweise Kennwörter enthalten, verlieren können.

66
Lekensteyn

Ich habe ein Metasploit-Modul geschrieben, um dies zu testenEs wird derzeit überprüft, sollte aber relativ bald in der Hauptniederlassung erscheinen. Die erste Version wird zu diesem Zeitpunkt in den Hauptzweig eingefügt.

https://github.com/rapid7/metasploit-framework/blob/38a2614fbee1851252462c858057738c06a9f2ab/modules/auxiliary/server/openssl_heartbeat_client_memory.rb

Im Gegensatz zum serverseitigen Angriff müssen Sie den größten Teil von TLS implementieren, da die Heartbeat-Antwort mit dem SSL-Sitzungsschlüssel verschlüsselt wird. Ich habe mit wget, curl und der openssl-Befehlszeile getestet. Ein interessanter Leckerbissen ist, dass der Angriff gegen wget und openssl (1) unabhängig von der Zertifikatsüberprüfung erfolgreich ist. Für die Curl-Binärdatei ist -k oder ein gültiges Zertifikat erforderlich, damit die Sitzung lange genug geöffnet bleibt, damit der Angriff funktioniert. Bei diesen relativ synthetischen Tests konnte ich den TLS-Sitzungsschlüssel (AES-128-CBC) zuverlässig verlieren, dies bietet jedoch nicht viel, da der Server während des Handshakes denselben Schlüssel kennt.

EDIT1 : Es sieht so aus, als würde der Schrittmachercode dies erreichen, ohne den vollständigen TLS-Handshake auszuführen (noch besser!). Ich würde mich für Testergebnisse interessieren, die Leute zwischen den Implementierungen haben könnten. IOW, ist der Schrittmacher in Fällen erfolgreich, in denen der Client aufgrund eines selbstsignierten Zertifikats die Verbindung trennen würde?

EDIT2 : Die im Schrittmacher verwendete Methode @Lekensteyn (Herzschlag nach dem Server Hello senden) ist ein besserer Ansatz, da die CA-Validierung kein Problem darstellt. Ich habe eine neue Metasploit-PR eingereicht, die standardmäßig diesen Modus verwendet und den TLS-Verhandlungscodepfad mithilfe der Option NEGOTIATE_TLS beibehält (setzen Sie NEGOTIATE_TLS für den alten Modus auf true). Requisiten an @Lekensteyn!

26
HD Moore

Es ist möglich, den Fehler in Clients auszunutzen. Dieser Tester kann verwendet werden, um beliebigen Clients eine "böse" URL zu geben und zu prüfen, ob sie den Köder nehmen oder nicht. Ich habe 3 Top-100-Websites gefunden (ich werde sie hier nicht nennen), die URLs mit Clients abrufen, die ab dem 09.04.2014 anfällig waren.

8
Brad

Wenn Sie ein Android Gerät) haben, können Sie eine der Heartbleed-Apps installieren, die die Sicherheitsanfälligkeit testen, wie diese:

https://play.google.com/store/apps/details?id=com.lookout.heartbleeddetector

Ich habe dies auf zwei Android Handys, eines mit 4.3 und eines mit 4.4, getestet und beide berichten, dass sie anfällig sind, aber für beide wird OpenSSL nicht verwendet, also ist alles gut ....

Everything is OK!

Also ist alles in Ordnung. Gut, dass keine Apps OpenSSL verwenden. Aber was ist, wenn ich eine App installiere, die sie verwendet? Werde ich benachrichtigt? Ich denke nicht!

Das 4.4-Telefon ist brandneu von Sony und hat nach dem ersten Gebrauch ein Systemupdate heruntergeladen, aber ich nehme an, dass dies nicht wichtig genug ist, um behoben zu werden?!

0
SPRBRN