Thema: SSL-Zertifikate / SSL/TLS-Protokoll

[SiLæncer]

Die niederländische SSL-Zertifizierungsstelle DigiNotar hält sich nach wie vor bedeckt, was das ganze Ausmaß des kürzlich aufgeflogenen Hackereinbruchs betrifft. Einen Hinweis liefert der Quellcode des Chromium-Projekts, aus dem Google Chrome hervorgeht: Die Liste der blockierten Zertifikate wurde von 10 auf stattliche 257 Seriennummern ausgebaut. Ein Kommentar im Quelltext lässt kein Zweifel daran, dass die neu hinzugefügten Zertifikate von DigiNotar ausgestellt wurden. Ob sich noch weitere prominente Webseiten unter den gesperrten Zertifikaten befinden, ist derzeit noch unklar. Neben dem Wurzelzertifikat der CA haben die Chromium-Entwickler sicherheitshalber auch zwei davon abgeleitete Intermediate-Zertifikate in die Blacklist aufgenommen.

Zumindest die Sperrung des Wurzelzertifikates wurde mit der kürzlich veröffentlichten Chrome-Version 13.0.782.218 bereits in den stabilen Entwicklungszweig übertragen. Bei dieser Gelegenheit hat Google auch das integrierte Flash-Plugin auf die bereits vor einer Woche erschienene Version 10.3.183.7 aktualisiert. Da das Flash-Update keine kritischen Lücken schließt, sah Google hier wohl keinen Grund zur Eile. Auch Mozilla hat reagiert und heute Firefox in den Versionen 6.0.1 und 3.6.21 veröffentlicht. Die einzige Änderung ist, dass der Browser dem Wurzelzertifikat von DigiNotar nicht länger vertraut. Thundbird wurde ebenfalls auf Version 6.0.1 aktualisiert, SeaMonkey trägt nun die Versionsnummer 2.3.2.

Operas Sicherheitsteam gab bekannt, nicht mit einem Update auf das Problem reagieren zu müssen: Für Opera sind die falschen Zertifikate kein Problem, da es deren Gültigkeit beim Besuch einer HTTPS-Seite anhand einer Sperrliste, der Certificate Revocation List (CRL), überprüft. Auf der CRL befinden sich Zertifikate, die vom Herausgeber zurückgerufen wurden. Findet Opera das Zertifikat in der Liste, wird die Verbindung nicht als sicher angezeigt. Zwar nutzen auch sämtliche andere Browser CRLs, doch einige geben die Überprüfung einfach auf, wenn sie die Liste nicht erreichen können und halten die Verbindung dennoch für sicher.

Bei einer Man-in-the-middle-Attacke (MITM) kann der Angreifer in diesem Fall also einfach den Zugriffsversuch auf die CRL blockieren und unentdeckt das inzwischen zurückgezogene Zertifikat ausliefern. Deshalb müssen die Browserhersteller, die zugunsten des Anwenderkomforts auf eine strikte Überprüfung der Liste verzichten, nun mit Updates reagieren. Windows nutzt ab Vista eine zentral von Microsoft verwaltete Whitelist vertrauenswürdiger CAs zurück, die sogenannte Microsoft Certificate Trust List. Von dieser wurde die gehackte Zertifizierungsstelle bereits entfernt.

Wenn im Internet Explorer unter "Optionen,
Inhalte, Zertifikate, Vertrauenswürdige
Stammzertifizierungstellen" DigiNotar
nach einem Klick auf "Erweitert" noch Rechte hat,
hat das Update von Microsofts Whiteliste nicht gegegriffen.
Entfernen Sie in diesem Fall die Häkchen von Hand.
Bild vergrössern

Auch der Internet Explorer profitiert von dieser Liste. In der Theorie soll die Aktualisierung dieser Liste automatisch geschehen, auf unseren Redaktionsrechnern ist dies jedoch nicht in allen Fällen passiert, sodass der IE 9 dort das DigiNotar-Wurzelzertifikat sang- und klanglos akzeptierte. Für Windows XP und Windows Server 2003 sollen separate Sicherheitsupdates folgen.

Besonders ernst scheint es DigiNotar nicht mit der Sicherheit genommen zu haben, wie Mikko Hypponen von F-Secure berichtet. Er hat auf dem Webserver der Zertifizierungsstelle Textdateien entdeckt, die darauf hindeuten, dass der Server schon seit 2009 mehrfach von verschiedenen Hackergruppen kompromittiert wurde. Mit dem Problem, dass nun sämtliche Browser eine Warnmeldung beim Besuch einer Seite mit DigiNotar-Zertifikat anzeigen, geht das Unternehmen laut Sophos locker um: 99,9 Prozent der Warnmeldungen könne man getrost ignorieren.

Quelle : www.heise.de

[SiLæncer]

Bei dem Hackerangriff auf die niederländische SSL-Zertifizierungsstelle DigiNotar haben die Eindringlinge auch zwölf Zertifikate für die Domain *.torproject.org erzeugt, wie die Entwickler des Anonymisierungsnetzwerks berichten. Demnach wurden am 18. Juli dieses Jahres die ersten sechs und am 20. Juli weitere sechs Zertifikate widerrechtlich für die Domain des Projekts ausgestellt – und das, obwohl DigiNotar den Einbruch bereits am 19. Juli erkannt und alle falschen Zertifikate zurückgezogen haben will.

Die Tor-Entwickler geben an, dass die Sicherheit des Anonymisierungsnetzwerks durch die ausgestellten Zertifikate nicht direkt beeinträchtigt sei. Allerdings konnte ein Angreifer damit die Webseite des Projekts manipulieren, um dem Opfer etwa eine modifizierte Version des Tor-Clients unter zu schieben. Die Tor-Macher beklagen, dass sie nicht aktiv von DigiNotar über den Zwischenfall informiert wurden und erst durch einen Anruf bei der CA eine Liste mit den Seriennummern der falschen Zertifikate bekommen haben. DigiNotar gab gegenüber den Tor-Entwicklern an, dass sie die betroffenen Zertifikate längst für ungültig erklärt hätten.

Allerdings weist derzeit nichts darauf hin, dass dies auch tatsächlich passiert ist. Die Entwickler haben in den öffentlich zugänglichen Sperrlisten der Zertifizierungsstelle (Certificate Revocation List, CRL) keinerlei Hinweise auf eine Sperrung der betroffenen Seriennummern gefunden. Interessanterweise wurden die Zertifikate mit einer Gültigkeit von nur einem Monat ausgestellt und sind seit dem 19. August abgelaufen. Dies sehen die Entwickler als möglichen Grund dafür, dass DigiNotar es nicht mehr für nötig hält, die Zertifikate in die CRL aufzunehmen.

Laut einem Bericht der niederländischen Webseite nu.nl gab es weitere prominente Opfer, darunter der Blog-Hoster WordPress, Yahoo, das Addon-Verzeichnis von Mozilla Firefox und das iranische Blog-Portal Baladin. Finanzielle Absichten stecken offenbar nicht hinter dem Angriff; laut dem Bericht wurden keine Zertifikate für Finanzinstitute ausgestellt.

Auch für Google.com wurde missbräuchlich mindestens ein Zertifikat erstellt und auch aktiv zum Abhören iranischer Google-Nutzer genutzt, wodurch der Vorfall schließlich auch aufgefallen ist. Google Chrome bringt seit Version 13 eine Liste vertrauenswürdiger CAs mit, die zur Ausstellung von Zertifikaten für die Google-Domain in Frage kommen. Gibt es eine Abweichung, wie im aktuellen Fall, zeigt der Browser eine Warnung an. Das Google-Zertifikat wurde bereits am 10. Juli ausgestellt und laut DigiNotar bei den Aufräumarbeiten nach dem Einbruch "übersehen".

Über die Gesamtzahl der ausgestellten Zertifikate kann man derzeit nur spekulieren. Einen Anhaltspunkt liefert eine Änderung im Quelltext von Chrome, welche die Seriennummern von 247 DigiNotar-Zertifikaten auf die Blacklist setzt. Ob nach der Panne mit dem Google-Zertifikat nun wirklich alle falschen Zertifikate gesperrt wurden, ist weiter unklar. Nach den Beobachtungen des Internet Storm Center ist die Anzahl der gesperrten Zertifikate der CA im Juli und August gegenüber den Vormonaten sogar deutlich zurück gegangen. Neben Google haben unter anderem auch Mozilla und Microsoft der CA das Vertrauen inzwischen generell entzogen.

Quelle : www.heise.de

[SiLæncer]

Bei dem Angriff auf die Zertifizierungsstelle DigiNotar im Juli wurden mehr als doppelt so viele Zertifikate ausgestellt wie bisher angenommen. Die niederländische Regierung hat den Entwicklern des Tor-Projekt eine Liste mit 531 Zertifikaten ausgehändigt, in der sich auch die Domains zahlreicher Geheimdienste wiederfinden: Die Angreifer konnten jeweils mehrere Zertifikate für www.sis.gov.uk (MI6), www.cia.gov und www.mossad.gov.il ausstellen. Auch für diverse Microsoft-Domains wurden missbräuchlich Zertifikate ausgestellt, darunter microsoft.com, windowsupdate.com, login.live.com und skype.com. Weitere Prominente Opfer sind facebook.com, twitter.com, aol.com, android.com und secure.logmein.com.

Zudem haben die Angreifer die Wildcard-Zertifikate *.*.org und *.*.com ausgestellt, die jedoch von keinem Browser akzeptiert werden dürften. Zur Ausstellung beliebiger weiterer Zertifikate waren offenbar diverse Intermediate-Zertifikate gedacht, die auf Namen wie Thawte Root CA, Equifax Root CA und VeriSign Root CA ausgestellt worden sind. Mit der Liste wird ein Bericht von vergangener Woche bestätigt, laut dem die Angreifer auch für google.com, wordpress.com, addons.mozilla.org, login.yahoo.com und torproject.org Zertifikate ausstellen konnten.

Der Gesamtumfang überrascht: Bislang ging man aufgrund von Änderungen im Quellcode von Google Chrome lediglich von 247 falschen Zertifikaten aus. Damit handelt es sich um den bislang schwerwiegendsten Einbruch bei einer Certificate Authority (CA). Unklar ist derzeit, wer hinter dem Angriff steckt und wie viele der Zertifikate für die Überwachung von Internetnutzern genutzt wurden. Zumindest mit Google-Zertifikat wurden im Iran bereits aktiv Gmail-Nutzer ausspioniert.

Einen Hinweis auf den Urheber des Hacks liefert ein Zertifikat, das auf die zum Zeitpunkt der Ausstellung ungültige Domain RamzShekaneBozorg.com ausgestellt wurde. Laut dem Blogeintrag auf der Seite des Tor-Projekts ist der Domainname persisch und bedeutet übersetzt "great cracker", der Name des Zertifikate-Inhabers "Hameyeh Ramzaro Mishkanam" bedeutet "I will crack all encryption" – ich knacke jede Verschlüsselung.

Unterdessen mehren sich die Beschwerden der betroffenen Domaininhaber, da sich DigiNotar nicht unmittelbar mit ihnen in Verbindung gesetzt hat. Die Mozilla-Entwickler kritisieren das Vorgehen der kompromittierten Zertifizierungsstelle harsch: "Die Statements, die DigiNotar und der Mutterkonzern VASCO über das Ausmaß und die Auswirkungen der Kompromittierung gemacht haben, waren bestenfalls unvollständig und schlimmstenfalls bewusst irreführend."

Quelle : www.heise.de

[SiLæncer]

Die kritische Infrastruktur bei der kompromittierten Zertifizierungsstelle DigiNotar war unzureichend geschützt. Das geht aus dem Zwischenbericht (PDF) des Sicherheitsunternehmens Fox-IT hervor. Demnach standen die CA-Server zwar in einer sicheren Umgebung, waren jedoch über das Management-LAN erreichbar. Dadurch konnte sich der Angreifer wohl von außen zu den CA-Servern weiterhangeln. Die Server seien mit einem schwachen Passwort geschützt gewesen, das man leicht per Brute Force hätte knacken können.

Alle CA-Server waren dem Bericht zufolge Mitglied einer Windows-Domain, sodass der Angreifer mit den einmal erbeuteten Zugangsdaten auf sämtliche Server zugreifen konnte. Auf kritischen Servern entdeckten die Sicherheitsexperten Schadsoftware, die von gängiger Antivirensoftware mühelos erkannt wird – eine solche war auf den Systemen allerdings nicht installiert. Zudem war die Software auf den öffentlich zugänglichen Webservern laut dem Bericht veraltet.

Auf den kompromittierten Systemen fanden die Ermittler zudem neben ganz profanen Security-Tools wie Cain & Abel auch speziell für diesen Einsatz zugeschnittene Tools und Skripte. Das Skript, das der Hacker offenbar zur Signierung der falschen Zertifikate eingesetzt hat, nutzt ein spezielles API, das nur im Umfeld von CAs eingesetzt wird. In diesem Skript hat sich der Angreifer in englischer Sprache mit den Worten verewigt: "Ich weiß, dass euch mein Können schockiert. […] Es gibt keine Hardware oder Software auf dieser Welt, die meine heftigen Attacken stoppen kann."

Signiert ist das "Bekennerschreiben" mit den persischen Worten "Janam Fadaye Rahbar", was man mit "Ich opfere mich für den großen Führer" übersetzen kann. Diese Worte finden sich auch in dem Manifest, das schon der mutmaßliche Comodo-Hacker ins Netz gestellt hat. Ob es sich um dieselbe Person handelt oder eine Gruppe von Hackern den gleichen Spruch benutzt, ist unklar.

Der Zwischenbericht bestätigt die Zahl der 531 durch den Angreifer ausgestellten Zertifikate. Allerdings sei nicht auszuschließen, dass darüber hinaus bei dem Vorfall noch weitere Zertifikate ausgestellt wurden, da nach dem Einbruch Log-Dateien gelöscht wurden. Aus diesem Grund wurde laut Bericht auch das Google-Zertifikat nach der ersten Analyse des Einbruchs nicht zurückgerufen – DigiNotar wusste schlicht und ergreifend nicht von dessen Existenz.

Der Angreifer hatte auch Zugriff auf den CA-Server PKIoverheid, der von den niederländischen Behörden genutzt wird. Allerdings sind die Log-Dateien hier vollständig, was nach Meinung der Experten darauf hindeutet, dass der Server nicht missbraucht oder manipuliert wurde, berichtet Fox-IT. Zwar fanden sie hier zwei Seriennummern von bis dato unbekannten Zertifikaten, es sei jedoch möglich, dass diese von der CA-Software temporär erzeugt worden sind oder durch einen Bug entstanden seien, so die Experten.

Bei der Logfile-Auswertung des OCSP-Responders, an den die Browser beim Besuch einer von DigiNotar signierten Seite eine Anfrage senden, stelle sich heraus, dass bislang wohl nur das Google.com-Zertifikat im großen Stil für Abhörmaßnahmen missbraucht wurde. Es gingen rund 300.000 verschiedene Anfragen (Unique IPs) ein, davon über 99 Prozent aus dem Iran.

Auch TrendMicro hat einen drastischen Anstieg von OCSP-Anfragen an DigiNotar aus dem Iran registriert. Besonders besorgniserregend ist die Tatsache, dass die Zugriffe laut TrendMicro von über 40 verschiedenen ISPs und Unis ausgingen. Eine derart großflächlig angelegte Abhörmaßnahme ist kaum ohne staatliche Hilfe umzusetzen.

[Update]Der mutmaßliche Comodo- und DigiNotar-Hacker hat eine weiteres Manifest veröffentlicht. Darin gibt er an, Zugriff auf vier weitere Certificate Authorities zu haben, um sich jederzeit beliebige Zertifikate auszustellen. Namentlich nennt er in seinem Manifest jedoch nur GlobalSign. Daneben will er auch der Hacker gewesen sein, der im Juni in die Server des israelischen Zertifikatsherausgeber StartCom eingedrungen ist.[/Update]

Quelle : http://www.heise.de/newsticker/meldung/DigiNotar-Hack-Kritische-Infrastruktur-war-unzureichend-geschuetzt-1337378.html

[SiLæncer]

Microsoft hat Patches für sämtliche Windows-Versionen veröffentlicht, die die Root-Zertifikate von Diginotar entfernen. Etliche große Linux-Distributionen stellen entsprechende Updates bereit. Ein Patch für Mac OS X ist noch nicht verfügbar.

Die meisten Betriebssystemhersteller haben inzwischen auf die kompromittierten Root-Zertifikate des niederländischen Unternehmens Diginotar reagiert und entsprechende Updates oder Patches bereitgestellt.

Microsoft weist in dem Security Advisory 2607712 auf fünf Root-Zertifikate von Diginotar hin, die durch entsprechend bereitgestellte Patches für Windows ab XP bis 7 in 32- und 64-Bit-Versionen entfernt werden. Patches liegen auch für alle Versionen von Windows Server 2003 und 2008 bereit. Microsoft warnt davor, dass die Zertifikate für Phishing- oder Man-in-the-Middle-Angriffe über den Internet Explorer genutzt werden könnten.

Zahlreiche Linux-Distributionen haben ebenfalls bereits seit dem Wochenende reagiert und entsprechende Updates für Mozilla- und weitere Anwendungen in ihren Repositories bereitgestellt, darunter CentOS, Debian, Mandriva, Opensuse und Suse Enterprise Linux. Für Ubuntu und Red Hat sind bereits seit Freitag ebenfalls Updates verfügbar.

Für Mac OS X und iOS steht noch kein offizielles Update zur Verfügung. Nutzer können die Zertifikate von Diginotar allerdings entweder löschen oder als "nicht vertrauenswürdig" einstufen.

Gestern wurde bekannt, dass die Angreifer auf die CA-Server von Diginotar insgesamt 531 gefälschte Zertifikate ausgestellt haben, darunter die von Skype und Wordpress, Facebook, Microsoft, Mozilla, Yahoo und dem Tor-Projekt.

Diginotar hatte dazu einen von Fox-IT erstellten Bericht zu dem Einbruch veröffentlicht. Demnach liegt die Vermutung nahe, dass es den Angreifern vor allem darum ging, Nutzer im Iran auszuforschen. Zudem kommt Fox-IT zu dem Schluss, dass das Netzwerksetup von Diginotar nicht sicher genug war, um solche Angriffe abzuwehren.

Quelle : www.golem.de

[SiLæncer]

Nach der Kompromittierung des niederländischen Zertifikatsausstellers DigiNotar hat sich Mozilla in einer mahnenden E-Mail an alle CAs gewandt, deren Wurzelzertifikate in Firefox und Thunderbird enthalten sind. Die für den Zertifkatsmanager verantwortliche Kathleen Wilson fordert die CAs auf, eine Sicherheitsüberprüfung der Public Key Infrastructure (PKI) vorzunehmen und das Ergebnis bis zum 16. September an Mozilla zu senden.

Zudem fordert Wilson, dass Sperrlisten für besonders prominente Domains wie Google.com oder Facebook.com eingerichtet werden. Bevor ein Zertifikat für eine solche Domain ausgestellt wird, sollen die CAs dies manuell überprüfen. Auch das Prüfverfahren, das in einem solchen Fall angewandt wird, sollen die CAs Mozilla gegenüber offenlegen.

Erlaubt die CA einer weiteren Partei das Ausstellen von Zertifikaten, muss die CA das Ausstellen durch eine Whitelist einschränken oder sämtliche Details über den Aussteller und deren Geschäftspraktiken an Mozilla schicken. Zudem sollen alle Benutzeraccounts, die zum Ausstellen von Zertifikaten berechtigt sind, durch eine Mehr-Faktor-Authentifizierung geschützt werden.

Entfernt man das Zertifikat einer kompromittierten CA aus der Liste der vertrauenswürdigen CAs, funktionieren die von ihr ausgestellten Zertifikate durch Cross Signing mit einer anderen CA unter Umständen weiter. Deshalb verlangt Mozilla jetzt einen besseren Überblick über die Verflechtungen zwischen den CAs und will eine Liste über alle Cross-Signing-Partner der Zertifizierungsstellen.

Besteht bei der CA der Verdacht, dass sie ebenfalls Opfer einer Hackerangriffs gewesen sein könnte, soll sich der Betreiber sofort mit Mozilla in Verbindung setzen müssen. Wie viele der kleineren CAs das jedoch tatsächlich beherzigen werden, ist fragwürdig: Denn sobald die Browserhersteller das Wurzelzertifikat aus dem Lieferumfang entfernen, ist die Geschäftsgrundlage der CA zerstört.

Unterdessen gibt das österreichische CERT in einem Zwischenbericht IT-Verantwortlichen Tipps an die Hand, wie sie sich vor den Folgen des DigiNotar-Hacks schützen. Das CERT rät, noch im Einsatz befindliche DigiNotar-Zertifikate gegen Zertifikate einer anderer CAs auszutauschen sowie Wurzelzertifikate und Widerrufslisten auf den neuesten Stand zu bringen. Zudem sollen sich die Unternehmen einen Notfallplan für den Fall zurecht legen, in dem die CA, die für das Unternehmen Zertifikate ausstellt, kompromittiert wird.

Quelle : www.heise.de

[SiLæncer]

Als Folge des DigiNotar-Hacks stellt die Firma GlobalSign seit vergangenen Dienstag keine Zertifikate mehr aus, weil sie zunächst ihre Systeme prüft. Ein bislang Unbekannter hatte behauptet, auch die Certification Authority (CA) gehackt zu haben. Bislang konnte GlobalSign aber nur Beweise für einen Einbruch in den Webserver finden, auf dem die Site www.globalsign.com läuft. Dieser Server sei aber stets isoliert von allen anderen Systemen gelaufen, wie das Unternehmen betont. Man arbeite weiterhin daran, die normale Arbeit wieder aufzunehmen: Am morgigen Montag soll es weitergehen.

Quelle : www.heise.de

[SiLæncer]

Die Forscher Juliano Rizzo und Thai Duong wollen kommenden Freitag auf der Sicherheitskonferenz ekoparty in Buenos Aires ein Tool namens BEAST (Browser Exploit Against SSL/TLS) vorstellen, mit dem ein Angreifer im gleichen Netz via SSL übertragene Browsercookies abgreifen und entschlüsseln können soll. Dazu führen die Forscher einen sogenannten "Block-wise chosen-plaintext"-Angriff (PDF) auf die verschlüsselten Pakete durch.

Dies setzt voraus, dass der Angreifer den Browser dazu bewegen kann, beliebige Werte über den verschlüsselten Kanal an den die Gegenstelle zu senden. Da der Angreifer nun sowohl den Klartext als auch den verschlüsselten Text kennt, kann er darauf auf die eingesetzte Entropie schließen und den Knackaufwand erheblich verringern. Gegenüber The Register gab Rizzo an, dass er dadurch ein verschlüsselt übertragenes PayPal-Cookie in unter zehn Minuten knacken könne.

Das eigentliche Geheimnis steckt in der Manipulation der Pakete – HTTPS-Seiten sind durch ihre Verschlüsselung eigentlich ausreichend davor geschützt. Die Forscher gaben lediglich an, dass BEAST zum einen auf JavaScript-Code basiert, der in den Browser des Opfers injiziert werden muss. Den Rest soll dann ein Netzwerksniffer erledigen. Wie das genau funktioniert, ist derzeit unklar und sorgt in der Sicherheitsszene für rege Diskussionen.

Voraussetzung für den Angriff ist, dass die verschlüsselte Kommunikation noch über Version 1.0 des TLS-Protokolls erfolgt. Bereits die im Jahr 2006 beschlossenen Version 1.1 ist nicht mehr auf diesem Weg angreifbar. In der Praxis werden aber wie vor fast alle HTTPS-Verbindungen über TLS 1.0 abgewickelt. Konkrete Vorschläge für Abhilfe gibt es noch nicht. Das auf vielen Servern eingesetzte OpenSSL unterstützt derzeit nur in der Entwicklerversion 1.0.1 das überarbeitete TLS 1.1.

Quelle : http://www.heise.de/newsticker/meldung/Tool-soll-SSL-Cookies-in-zehn-Minuten-knacken-1346257.html

[SiLæncer]

Der niederländische Zertifikatsherausgeber DigiNotar wird nach dem SSL-Debakel von seinem Eigner Vasco liquidiert. Das teilte Vasco in einer Stellungnahme mit. Man habe Insolvenz für das Unternehmen in den Niederlanden angemeldet.

Zuvor hatte die niederländische Regierung bereits die Kontrolle über DigiNotar übernommen, unter anderem auch, um weiteren Schaden von der niederländischen PKI "PKIoverheid" abzuwenden. Daneben hatte die niederländische Aufsichtsbehörde für Telekommunikation (OPTA) der Zertifizierungsstelle das Ausstellen weiterer qualifizierter Zertifikate untersagt, und sämtliche Browser-Hersteller hatten die Wurzelzertifikate aus ihren Produkten verbannt.

Damit ist nach gerade einmal drei Wochen seit Bekanntwerden des CA-Hacks das Unternehmen, dass nicht nur Server von Kunden sichern sollte und für den Staat der Niederlande ein wichtiges Trustcenter betrieb, de facto aufgelöst. Vasco bietet selbst 2-Faktor-Authentifizierungslösungen an, betont jedoch, dass die eigenen Systeme von der DigiNotar-Kompromittierung nicht betroffen sind.

Quelle : www.heise.de

[SiLæncer]

Als Abhilfe gegen die vergangene Woche einer größeren Öffentlichkeit bekannt gewordene Schwachstelle in SSL/TLS wird von Sicherheitsspezialisten der Einsatz von RC4 vorgeschlagen. Der Stromchiffrieralgorithmus nutzt anders als AES, das auf den meisten Servern zum Einsatz kommt, keinen Cipher-Block-Chaining-Mode (CBC). CBC ist aber, so wie er bis SSL 3.0/TLS 1.0 implementiert ist, gegen sogenannte Chosen-Plaintext-Attacken anfällig.

Kern des Problems sind die nicht für jeden Block zufällig erzeugten Initialisierungsvektoren (IV), die dafür sorgen sollen, dass gleiche Blöcke nicht das gleiche Chiffrat erzeugen. Mit einer Art Ratespiel (educated guesses) ist es auf diese Weise möglich, verschlüsselt übertragene Cookies erheblich schneller als mit Brute-Force zu ermitteln. Dafür muss sich ein Angreifer allerdings per Man-in-the-Middle-Attacke (MitM) in die Verbindung eines Opfers zum Server einklinken und im Kontext des Opfers mit dem Server kommunizieren.

Der Google-Sicherheitsanalyst Adam Langley hat dazu weitere Details veröffentlicht. Demnach gelangt ein ominöser JavaScript-Code, über den vergangene Woche noch gerätselt wurde, im Rahmen der MitM-Attacke über ein iFrame in den Browser des Opfers. Das Skript schickt dann tausende von präparierten SSL-Request an den Server und wertet die Antworten aus. Zur Automatisierung dieser Attacke hatten die beiden Sicherheitsforscher Thai Duong und Juliano Rizzo das Tool BEAST (Browser Exploit Against SSL/TLS) vorgestellt.

Das Problem lässt sich mit einer Umstellung auf den seit 2006 verabschiedeten Standard TLS 1.1 lösen, dort sind die IVs bei CBC zufällig, sodass die beschriebene Attacke nicht mehr funktioniert. Allerdings ist die Umstellung offenbar nicht so einfach zu bewerkstelligen, weil nicht alle Server und Browser den Standard unterstützen.

Chrome und Firefox benutzen nach Analysen des Sicherheitsspezialisten Thierry Zoller die Network Security Services (NSS), die nur TLS 1.0 unterstützen. Auch Windows Vista, XP, 2000 und Server 2003 sowie Server 2008 können standardmäßig noch kein TLS 1.1. Erst Windows 7 und Server 2008 R2 können TLS 1.1 nutzen. Opera 10 hingegen arbeitet sogar mit TLS-1.2-Server zusammen. Das Ändern der Browserkonfiguration nützt aber nichts, wenn der Server es nicht unterstützt.

Das in der Regel bei Apache-Webserver eingesetzte OpenSSL bietet beispielsweise noch kein TLS 1.1, dort hilft nur der Wechsel auf GnuTLS oder die Umstellung auf RC4. Die eingesetzten Ciphersuiten lassen sich in der OpenSSL-Konfigurationsdatei ssl.conf vorgeben. Eine Anleitung zum Umstellen eines IIS 7 findet man hier: Cipher Suite Mitigation for BEAST (PDF).

Google hat derweil einen Fix in die Developer-Version implementiert, der bereits im Jahre 2004 von den OpenSSL-Entwicklern vorgeschlagen wurde. Um dem Angreifer die Kontrolle über den einzuschleusenden Klartext zu erschweren, werden Pakete aufgeteilt und jedem Paket ein leeres vorangestellt.

Bislang halten sich die meisten Hersteller und Webserver-Betreiber bei der Einschätzung des Problems zurück, wohl auch, weil das Tool BEAST noch nicht öffentlich verfügbar ist.

Quelle : http://www.heise.de/newsticker/meldung/Erste-Loesungen-fuer-SSL-TLS-Schwachstelle-1349687.html

[SiLæncer]

Der Softwarekonzern Microsoft hat eine Warnung veröffentlicht, in der er auf das potenzielle Spionagerisiko bei Einsatz des Modes CBC in Kombination mit AES hinweist. Microsoft schlägt als einen Workaround den Wechsel auf die Stromverschlüsselung mittels RC4 vor, die für die gemeldete Chosen-Plaintext-Attacke nicht anfällig ist. Eine Anleitung dazu hat Microsoft veröffentlicht.

Für den Einsatz von RC4 müsste der Administrator in der Liste der Verschlüsselungssammlungen beispielsweise TLS_RSA_WITH_RC4_128_MD5 ganz nach vorne stellen, damit diese Ciphersuite dem Client als erste vorgeschlagen wird. Ob der diese akzeptiert, steht jedoch auf einem anderen Blatt. Deshalb schlägt Microsoft den Wechsel auf TLS 1.1 vor.

Dazu haben die Redmonder zwei Fix-it-Tools veröffentlicht, die TLS 1.1 im Internet Explorer und Windows-Servern aktivieren. Standardmäßig ist nur TLS 1.0 aktiviert, obwohl etwa der Internet Explorer TLS 1.1 und TLS 1.2 unterstützt. Die Optionen lassen sich dort auch ohne Fix-it-Tool unter Internetoptionen/Erweitert setzen oder löschen. Auf Windows-Servern ist die manuelle Konfiguration etwas mühseliger, da man in der Registry bestimmte Schlüssel für den Secure Channel (schannel) ändern muss. Daher empfiehlt sich dort der Einsatz der Fix-it-Tools.

Die Firefox-Entwickler diskutieren unterdessen noch, wie man das Problem am besten löst, ohne die Kompatibilität mit Webservern zu beeinträchtigen. Allerdings tun sie das bereits seit Ende Juni. Damals hatte Thai Duong den Entwickler Dan Veditz bereits auf das drohende Problem hingewiesen und wie sich die Schwachstelle mit Websockets und Java Applets ausnutzen lässt. Aktuell unterstützt Firefox nur TLS 1.0.

Quelle : www.heise.de

[SiLæncer]

Als mögliche Interims-Lösung für die gemeldete SSL/TLS-Schwachstelle diskutieren die Firefox-Entwickler, das Java-Plug-in von Oracle im Browser zu deaktivieren. Das Java-Plug-in macht das Ausnutzen der von Rizzo und Duong vergangene Woche demonstrierten Schwachstellen nämlich erst möglich. So zeigten sie, wie sich Cookies von beliebigen Webseiten trotz verschlüsselter Verbindung rekonstruieren ließen.

Für ihren Chosen-Plaintext-Angriff auf den bei TLS zumeist verwendeten Cipher-Block-Chaining-Mode (CBC) müssen Rizzo und Duong nämlich die Same Origin Policy (SOP) des Browsers aushebeln, um auch mit Servern kommunizieren zu können, die nicht aus der Domain stammen, aus der etwa das Java-Applet stammt.

Die SOP soll zwar genau dies verhindern, offenbar gibt es aber einen bislang unbekannten Fehler in Java, mit dem sich das bewerkstelligen lässt. So gesehen wäre nach Meinung der Firefox-Entwickler nun eigentlich Oracle am Zug, das Problem zunächst in Java zu lösen. Die haben aber bislang nicht reagiert, sodass nun erwogen wird, mit einem Firefox-Update sämtliche Java-Plug-ins aus Sicherheitsgründen abzuschalten. Das würde aber bei einigen Anwendern zu Funktionsausfällen führen. Firefox-Häuptling Johnathan Nightingale nennt den Facebook-Videochat als Beispiel sowie diverse Unternehmensanwendungen.

Google hat eine andere Lösung in die Chrome-Entwicklerversion implementiert: Um dem Angreifer die Kontrolle über den einzuschleusenden Klartext zu erschweren, werden Pakete aufgeteilt und jedem Paket ein leeres vorangestellt. Das führte bisherigen Meldungen zufolge bislang nur bei wenigen Sites zu Problemen. Wann Google den Workaround in die stabile Version einfließen lässt, ist jedoch nicht bekannt.

Microsoft hat als Lösung das Umschalten von TLS 1.0 auf TLS 1.1 empfohlen, dass muss jedoch der Server unterstützen – und bislang tun dies wenige. Zudem ist nach Meinung einiger Firefox-Entwickler das Problem damit nicht wirklich gelöst, da Java seinen eigenen TLS-Stack benutzt – und der unterstützt nur die verwundbare TLS-Version 1.0.

Quelle : www.heise.de

[SiLæncer]

Ein neues Programm für DoS-Angriffe sorgt in der Securityszene für Gesprächsstoff. Da es Lücken im SSL-System angreift, sollen auch mittelgroße Webserver mit einem einzigen PC lahmgelegt werden können.

Die deutsche Hackergruppe "The Hackers Choice" (THC) hat ihr Programm "THC-SSL-DOS" zum öffentlichen Download bereitgestellt. Nach Darstellung seiner Entwickler soll das Tool bereits seit einigen Monaten in der Hackerszene umgehen, inzwischen sei es aber so verbreitet, dass man eine breitere Öffentlichkeit darüber informieren müsste.

THC-SSL-DOS gilt als besonders gefährlich, weil es für Denial-of-Service-Attacken keine große Anzahl von Rechnern, wie etwa die eines Botnets, benötigt. Das Programm überflutet einen Webserver nicht wie sonst üblich mit normalen Seitenabrufen oder anderen unverschlüsselten Protokollen, sondern versucht, möglichst schnell möglichst viele SSL-Verbindungen aufzubauen.

Diese Secure Socket Layer arbeiten mit Verschlüsselung, sodass zwischen dem anfragenden PC und dem Server zunächst eine sichere Verbindung ausgehandelt werden muss. Das benötigt viel mehr Rechenleistung als andere Anfragen. Die meisten großen DoS-Angriffe der letzten Monate, wie die von Anonymous mittels Programmen wie "LOIC" oder "RefRef", arbeiteten nicht mit SSL-Anfragen.

Der Darstellung von THC zufolge reicht bereits ein Notebook mit einer DSL-Verbindung, um einen Server mit schwacher SSL-Implementation lahmzulegen, wenn dieser Server mit bis zu 30 GBit/s angebunden ist. Damit wären auch mittelgroße Webangebote durch das Programm gefährdet. Abhilfe soll es nur durch Load Balancer oder dedizierte SSL-Beschleuniger geben, die noch nicht flächendeckend verbreitet und teuer sind. Wie schnell das DSL des Angreifers sein muss, gibt THC aber bisher nicht genau an.

In einem Interview mit THC-Mitgliedern, das unter anderem über die Security-Mailingliste Full Disclosure verbreitet wird, geben die Hacker an, dass sie vor allem auf Schwächen im SSL-System hinweisen wollen. Dabei geht es nicht nur um technisch schwache Umsetzungen. Vor allem, dass es Generalschlüssel für SSL-Zertifikate gibt, die immer häufiger entwendet werden, ist den Hackern ein Dorn im Auge.

Quelle : www.golem.de

[SiLæncer]

Der steile Anstieg der ungültig erklärten Zertifikate ist
unter anderem auf den verstärkten Einsatz von
Verschlüsselung zurückzuführen.

In einem Hintergrundartikel zur Sicherheit von SSL konstatiert Peter Ecklersley von der Electronic Frontier Foundation, dass in den letzten vier Monaten mindestens fünf Certificate Authorities (CAs) kompromittiert wurden. Ecklersley extrahierte diese Information aus den von den CAs veröffentlichten Sperrlisten für Zertifikate.

Diese sogenannten Certificate Revocation Lists (CRL) enthalten Zertifikate, die nicht mehr als gültig erachtet werden sollen. Herausgeber sperren Zertifikate aus verschiedenen Gründen – etwa weil der Kunde einen Geschäftsbereich aufgegeben hat (Cessation of operation) oder ihm der geheime Schlüssel abhanden kam (Key Compromise). Spannend sind die insgesamt 248 Fälle, in denen der der Herausgeber der CRL als Begründung angab, dass die zuständige Certificate Authority kompromittiert wurde. Bis Juni 2011 war das nur bei 55 Zertifikaten der Fall. Diese fast zweihundert, zwischenzeitlich gesperrten Zertifikate wurden von fünf verschiedenen CAs ausgestellt.

Das sind also mindestens fünf CAs, die innerhalb von nur 4 Monaten geknackt wurden, um missbräuchlich falsche Zertifikate auszustellen. Und diese Zahl ist nur eine untere Grenze. In der großen Mehrzahl der Fälle – insgesamt über 900.000 Mal – zog es der Herausgeber der CRL vor, das Begründungsfeld leer zu lassen. Das Problem mit solchen Einbrüchen bei CAs ist, dass jeder der akzeptierten Zertifikatsherausgeber Zertifikate für jede Web-Seite ausstellen kann. Browser werden sie klaglos schlucken – für Google-Mail genauso wie für das Online-Banking der Deutschen Bank. Und laut SSL Observatory vertrauen unsere Browser insgesamt über 600 CAs (PDF) in mehr als 50 Ländern.

Quelle : www.heise.de

[SiLæncer]

Die Zertifizierungsstelle (Certificate Authority, CA) der zum niederländischen Telekommunikationskonzern KPN gehörenden Tochter KPN Corporate Market hat die Ausgabe von Secure-Socket-Layer-Zertifikaten (SSL) gestoppt. Grund dafür ist, dass Hacker die Sicherheitsmechanismen überwunden und einen der Server kompromittiert haben. Im Rahmen einer gründlichen Überprüfung angesichts der vergangenen Einbrüche bei Zertifikatsherausgebern wurden Programme entdeckt, die für DDOS-Angriffe auf andere Rechner dienen. Die gefundenen Spuren deuten darauf hin, dass der Einbruch bei KPN bereits vor vier Jahren erfolgte und seitdem unentdeckt blieb.

KPN hält es für unwahrscheinlich, dass bisher ausgegebene Zertifikate kompromittiert wurden, kann es aber auch nicht ausschließen. Sie sollen dennoch vorerst ihre Gültigkeit behalten. Vorsorglich hat der Telekommunikationsanbieter die Webserver ausgetauscht. Zudem will KPN keine neuen SSL-Zertifikate ausgeben, bis der Einbruch restlos aufgeklärt ist.

In einem ähnlichen Fall haben Microsoft und Mozilla am vergangenen Donnerstag allen Zertifikaten der malayischen CA Digicert das Vertrauen entzogen. Von dieser waren 22 Zertifikate aufgetaucht, die nur einen schwachen 512-Bit-Schlüssel verwenden und denen notwendige Zertifikatserweiterungen und Widerrufinformationen fehlten.

Quelle : www.heise.de