-
Website-Betreibern, die Nutzerdaten SSL-verschlüsselt entgegennehmen kann man vertrauen, heisst es immer wieder. Das könnte bald nur noch bedingt gelten. Einige Anbieter stellen SSL-Website-Zertifikate ohne jede Authentifizierung des Antragstellers bereit. Die Folge: Anwender haben keinerlei Informationen darüber, für welchen Empfänger sie ihre Daten verschlüsseln; die Verschlüsselung ist damit nahezu nutzlos.
SSL-Zertifikate enthalten zusätzlich zum öffentlichen Schlüssel den Namen der Website, die diesen verwendet. Diese Information beglaubigen Unternehmen ("Certificate Authorities", CAs) wie Verisign, die teilweise viel Geld für solche Server-Zertifikate verlangen. Viele Authorities sind in den beiden zurzeit dominierenden Webbrowsern Internet Explorer und Mozilla bereits als vertrauenswürdig eingestuft. Für den Browser-Nutzer bedeutet das, dass er ein Zertifikat dieser Stellen nicht mehr manuell auf seine Echtheit überprüfen muss -- sofern er den CAs seines Browsers vertraut.
"Diese Unternehmen ziehen Ihnen nur das Geld aus der Tasche", tönt das israelische Start-Up-Unternehmen StartCom und richtete gerade eine eigene Zertifizierungsstelle ein. "SSL ist dazu da, den Traffic zwischen Browser und Server zu verschlüsseln. Punkt!" Daher biete man über ein Webfrontend nun von StartCom bestätigte Zertifikate an, die der Webmaster zur SSL-Verschlüsselung einsetzen könne.
Schon bei der Schlüsselerstellung geht StartCom nicht sonderlich seriös vor: Der "Certificate Creation Wizard" erzeugt den Private Key auf dem Server der israelischen Firma und übermittelt ihn dem Website-Betreiber über eine (SSL-gesicherte) Web-Seite. Eine Garantie, dass nicht eine Kopie des geheimen Schlüssels bei StartCom verbleibt, erhält er nicht. Mit einer solchen Kopie wäre es möglich, alle verschlüsselten Verbindungen des Servers zu dechiffrieren. Bei seriösen Anbietern erzeugt der Anwender seinen geheimen Schlüssel lokal; an die CA übermittelt er nur den Zertifizierungsantrag, den diese unterschrieben zurück sendet.
./.
Welchen Sinn soll eine Zertifizierungsstelle ohne Überprüfung des Antragsstellers, wie sie zum Beispiel auch der Chaos Computer Club (CCC) betreibt, dann eigentlich haben? "Keinen", glaubt auch Karlsen. SSL-gesicherte Seiten ohne irgendwelche Anhaltspunkte über die Identität des Betreibers führen Verschlüsselung ad Absurdum. Schließlich könnte am anderen Ende der Verbindung genauso gut ein Bösewicht sitzen wie irgendwo unterwegs.
./.
(hob/c't)
Der ganze Artikel (http://www.heise.de/newsticker/meldung/56750) mit Links
Quelle: www.heise.de
Anmerkung von mir:
Ich denke, das ist eine Authority, die man, falls schon eingetragen, sofort löschen sollte. Auch in Zukunft ist das Teil für mich verbrannt.
Ein geheimer Schlüssel, der den Erstellungs-Ort verlässt, ist absolut unsicher.
Da wird das ganze System unterlaufen. Kriminelle werden das sicher auch schon (zu nutzen) wissen. Zertifikate lassen sich ja verketten...
Insbesondere ist nichts schlimmer als vermeintliche Sicherheit, auf die man sich verlässt.
Traue niemandem weiter als Du ihn schmeissen kannst...
Jürgen
-
Operas jüngste Version wartet mit einer Sicherheitsfunktion auf, die Anwender besser erkennen lassen soll, ob sie sich eventuell auf einer Phishing-Seite befinden. So blendet der Browser bei SSL-gesicherten Verbindungen nicht nur das Schloßsymbol ein, sondern zeigt sogar noch Inhalte des SSL-Zertifikats an. Andere Browser zeigen bei gültigen Zertifikaten nur das Schloß an. Für weitere Hinweise, etwa von wem das Zertifikat stammt oder von wem es ausgestellt wurde, muss der Anwender selbst den Inhalt aufrufen.
Nach Meinung von Geotrust, einem der weltweit größten Herausgeber digitaler Zertifikate, könnte Operas neue Funktion aber den Anwender in falscher Sicherheit wiegen. Der Browser zeigt nämlich ausgerechnet den Teil eines Zertifikats an, dessen Inhalt von vielen Herausgebern bei der Antragstellung nicht sorgfältig genug überprüft wird. Zertifikate enthalten neben dem Server-Namen (Common Name - CN) auch Angaben des Antragsteller (Organisation - O, Abteilung - OU und Land -C), die zusammgefasst den eindeutigen Distinguished Name (DN) ergeben. Opera 8 zeigt nun zusätzlich die Organisation (O) an, die sich etwa von Phishern durch Vortäuschung falscher Tatsachen bei einer Certification Authority (CA) beliebig formulieren lässt.
Geotrust hat dazu auf seinen Seiten drei Demos veröffentlicht, die dieses Problem veranschaulichen. Dem Opera-Nutzer wird ein zur Seite passender Zertifikatsinhalt präsentiert, der ihn glauben lässt, auf der richtigen Seite zu sein -- obwohl eigentlich der Domain-Name nicht stimmt. Dazu trägt auch bei, dass vielen Anwender die Funktion eines Zertifiktes nicht bewußt ist: Ein Zertifikat bindet einen öffentlichen Schlüssel nämlich nur an eine Identität. Ob die dahintersteckende Person oder Firma vertrauenswürdig ist, bleibt offen.
Anwender sollten also bei Seiten, die vertrauliche Daten abverlangen, auch weiterhin aufmerksam sein -- insbesondere wenn ein Link in einer Mail sie dorthin geführt hat. Derzeit ist nur der Common Name, also der Server-Name, im Zertifikat vor Manipulation geschützt. Die Ursache des Problems hat Geotrust indes auch bereits ausgemacht. So bemängelt der Dienstleister in seinem Report den laxen Prüfungsprozess vieler anderer Zertifizierungstellen und insbesondere deren Subunternehmer und Reseller -- ohne allerdings Namen zu nennen. Mittlerweile könne man nicht mehr allen CAs vertrauen. Zukünftig werde es wahrscheinlich Empfehlungen geben, welche CA kritische Prüfungen durchführe. Anwender sollten dann nicht nur darauf achten für wen ein Zertifikat ausgestellt ist, sondern auch von wem.
Quelle und Links : http://www.heise.de/newsticker/meldung/58845
-
Nach Angaben des Internet Storm Centers (ISC) haben die Online-Betrugsversuche in den USA eine neue Qualität erreicht, um Anwendern noch überzeugendere Phishing-Seiten zu präsentieren. So wird im Artikel "Phollow the Phlopping Phish" ein Fall geschildert, bei der die Betrüger eine Domain registrierten, um Kunden der Bank Mountain America in die Falle zu locken. Nicht nur, dass die Adresse mit www.mountain-america.com relativ unverdächtig aussah (die richtige Adresse lautet www.mtnamerica.com), zudem haben die Phisher ihren Webserver mit einem gültigen SSL-Zertifikat ausgestattet.
Besucher der Seiten konnten also selbst mit einer genauen Prüfung des Zertifikates nicht feststellen, dass sie auf einer Phishing-Seite gelandet waren. Alle im Zertifikat angegebenen Daten waren scheinbar korrekt. Selbst eine zusätzliche Überprüfung der Identität über den Dienstleister ChoicePoint, nach eigenen Angaben der führende US-Dienstleister für die Überprüfung von Identitäten, bestätigte die Echtheit der Seite. Laut ChoicePoint war die Domain auf Mountain America in Salt Lake City, dem Stammsitz der Bank, registriert.
Besonders prekär: ChoicePoints Daten stammten vom Zertifikatsaussteller Equifax, einem Reseller von GeoTrust, der auch bereits das SSL-Zertifikat herausgab. Wie es zu der Fälschung kommen konnte, ist indes nicht klar. Auf Nachfrage bekam das ISC die Antwort, dass für einen Zertifikatsantrag mehrere Dokumente erforderlich seien. Unter anderem würden amtliche Belege wie Gewerbescheine, Auszüge aus Handelsregistern und dergleichen gefordert. Dass nun auch Betrüger die Prüfungsprozedur durchstanden haben, ist gerade für GeoTrust besonders peinlich. Noch im April 2005 bemängelte der Dienstleister die laschen Prüfungsprozesse vieler anderer Zertifizierungsstellen und insbesondere deren Subunternehmer und Reseller.
Damit zeigt sich einmal mehr, dass auch Zertifikate nicht der Weisheit letzter Schluss sind, um Anwender vor Betrügern zu schützen. Ein Zertifikat bindet im Regelfall ohnehin nur einen öffentlichen Schlüssel an eine Identität. Ob die dahintersteckende Person oder Firma vertrauenswürdig ist, lässt ein SSL-Zertifikat offen. Ein Dammbruch stellt der neue Fall aber nicht dar, wenn Anwender weiterhin nur die bereits bekannten Adressen ihrer Banken per Bookmark besuchen. Als zusätzliche Maßnahme sollten die Banken die Fingerprints ihrer Zertifikate veröffentlichen, damit im Zweifelsfall ein Vergleich möglich ist. Allerdings ist damit zu rechnen, dass ein großer Teil der Anwender damit überfordert sein dürfte.
Siehe dazu auch:
* Phollow the Phlopping Phish, Artikel vom ISC
Quelle und Links : http://www.heise.de/security/news/meldung/69598
-
Eine Analyse des Pseudozufallszahlengenerators (PRNG) von Windows 2000 hat bedenkliche Schwächen zutage gefördert. Israelische Wissenschaftler konnten erstmals die Funktionsweise des bislang unveröffentlichten Algorithmus rekonstruieren und einer Untersuchung unterziehen. Sie entwickelten Angriffe gegen den Generator, mit denen sich die erzeugten Zufallszahlen unter Umständen zurückberechnen oder vorhersagen lassen. Inwieweit sich die Erkenntnisse der Forscher auch auf die Zufallszahlengeneratoren von Windows XP oder Vista übertragen lassen, ist bislang nicht bekannt.
Die Vorhersagbarkeit von Pseudozufallszahlen eines Computersystems hat teils schwerwiegende Auswirkung auf die darauf laufenden Krypto-Anwendungen wie Verschlüsselungsprogramme, Banking-Software, DRM-Systeme oder SSL. Aus den Zahlen lassen sich unter Umständen die geheimen Schlüssel ableiten, mit denen solche Programme die verarbeiteten Daten gegen unbefugten Zugriff schützen. Ein PRNG, wie er von Windows 2000 eingesetzt wird, führt bei jedem Aufruf diverse Rechenoperationen auf seinen internen Zustandsregistern aus und versetzt sie damit in einen neuen Zustand. Einen geringen Teil der neuen Zustandsdaten liefert er als Zufallswert – in der Regel nach mehreren internen Durchläufen – an das aufrufende Programm zurück.
Wichtigstes Ergebnis der Wissenschaftler ist, dass sich aus einem einmal bekannten inneren Zustand die zuvor ausgegebenen Zufallszahlen mit einer Angriffskomplexität von 223 berechnen lassen, was in ihren Augen auf ein fehlerhaftes Generator-Design zurückzuführen ist. Angriffe dieser Komplexitätsklasse lassen sich in der Regel bereits mit PC-Hardware in kürzester Zeit berechnen. Außerdem läuft der Generator im Kontext der aufrufenden Anwendung und nicht wie auf anderen Systemen üblich im Kernel-Space. Dies erleichtert Angreifern erheblich, den inneren Zustand des PRNG auszulesen, beispielsweise durch eine Pufferüberlauf-Schwachstelle in der anvisierten Applikation.
Eine weitere Schwachstelle entdeckten die Wissenschaftler in der unsicheren Initialisierung der Zustandsregister. Demnach verwendet der Windows-PRNG zum Teil dafür diejenigen Daten, die sich zum Zeitpunkt seiner Initialisierung im Stack-Bereich des aufrufenden Programmes befinden. Die Werte auf dem Stack sind jedoch unter Umständen vorhersagbar.
Außerdem erfolgt laut den Forschern zu selten eine Auffrischung des internen PRNG-Zustandes mit Entropiedaten des Systems (etwa aus Mausbewegungen, Festplatten-Jitter oder Netzwerk-Delays): lediglich nach jeweils 128 KByte produzierten Zufallsdaten fließen die schwer vorhersagbaren Entropiedaten in die Zustandsregister ein. Dies führt dazu, dass sich aus einem bekannten inneren Zustand alle Zufallszahlen innerhalb des 128-KByte-Fensters berechnen lassen.
Berichte über einen Pufferüberlauf im PRNG, über den Angreifer unter Umständen in Windows-Systeme einbrechen können, ließen sich indes nicht bestätigen. Zum Ausnutzen der nun entdeckten Schwächen muss ein Angreifer bereits über lokalen Zugriff auf den Windows-Rechner verfügen. Die vorgestellten Angriffe sind auch nur bedingt praxistauglich, weil sie zusätzlich bekannte Schwachstellen in den angegriffenen Applikationen oder Debugging-Möglichkeiten voraussetzen, um den internen PRNG-Zustand auslesen zu können. Dass in nächster Zeit darauf basierende, konkrete Angriffe gegen reale Applikationen entwickelt werden können, ist eher unwahrscheinlich.
Quelle : www.heise.de
-
Berichten US-amerikanischer Medien zufolge hat Microsoft eingräumt, dass der Pseudozufallszahlengenerator (PRNG) in Windows XP an den gleichen Problemen krankt wie der in Windows 2000. Ein Sicherheitsproblem sehen die Redmonder darin jedoch nicht; sie wollen die Schwächen folglich erst mit Windows XP Service Pack 3 (SP3) ausbügeln, das für das erste Halbjahr 2008 angekündigt ist. Ob es noch einen Fix für Windows 2000 geben wird, ist weiterhin ungewiss; Vista soll hingegen nicht betroffen sein.
Erst kürzlich hatten Wissenschaftler in einer Arbeit publiziert, dass die Zufallszahlen in Windows 2000 zu einfach zu erraten seien und der Generator selbst ungenügend gesichert sei. Dies hätte teils schwerwiegende Auswirkungen auf die Sicherheit der auf dem System laufenden Krypto-Anwendungen wie Verschlüsselungsprogramme, Banking-Software, DRM-Systeme oder SSL. Eine direkte Bedrohung stellt es jedoch nicht dar, weil ein möglicher Angreifer zuvor auf alle Fälle Zugang zum System erlangen müsste.
Quelle : www.heise.de
-
Die deutsche Zertifizierungsstelle TC Trustcenter beteuert, sie sei quasi zu Unrecht auf die Liste der CAs geraten, die noch MD5 einsetzen. Für Kunden stelle man "seit längerer Zeit [...] nur noch Zertifikate aus, die andere Verfahren verwenden". Lediglich für ein paar eigene Server habe man noch MD5-basierte Zertifikate verwendet. Das macht zwar in der Tat das konkrete Angriffsszenrio unmöglich; das Vertrauen der Anwender fördert es jedoch nicht. Immerhin hat Trustcenter jetzt begonnen, die Zertifikate auszutauschen.
Tim Callan von Verisign versichert in seinem Blog, dass man das Problem bereits "gelöst" habe. So habe man schon seit Längerem geplant, MD5 auszumustern und die meisten Verisign-Zertifikate setzen ohnehin kein MD5 mehr ein. Bei RapidSSL habe man den Ausstieg nun vorgezogen und benutze für die Zertifizierung kein MD5 mehr. Des Weiteren habe man sichergestellt, dass all die anderen Zertifikate, die man verkaufe, für diesen Angriff nicht anfällig seien – was immer das heißen mag.
Einen Anlass, Zertifikate, die das unsichere MD5-Verfahren einsetzen, zu widerrufen oder auszumustern, sieht Callan hingegen nicht; schließlich richte sich der Angriff nicht gegen bereits ausgestellte Zertifikate. Allerdings biete man Kunden, die das wünschen, einen kostenlosen Umtausch des Zertifikats an. Fast schon demonstrativ nutzt die RapidSSL-Site jedoch weiterhin ein Zertifikat, das mit MD5 signiert wurde.
Wie auch TC Trustcenter geht es Verisign in erster Linie um die eigenen Kunden – und die sind durch den Angriff nicht direkt bedroht. Die Gefahr durch gefälschte CAs betrifft vor allem Endanwender, die sich nicht mehr sicher sein können, ob ein Zertifikat echt und somit der geplante Online-Kauf wirklich sicher ist. Und dazu, wie die sich vor gefälschten Zertifikaten schützen könnten oder wie man jetzt MD5 möglichst schnell aus der Vertrauenskette herausbekommt, äußern sich weder Verisign noch TC Trustcenter.
Einen Schritt weiter geht da das US-CERT, das in einem Advisory konstatiert:
Verwenden Sie den MD5-Algorithmus nicht mehr
Software-Entwickler, Zertifizierungsstellen, Website-Betreiber und Anwender sollten den Einsatz von MD5 in jeder Hinsicht vermeiden. Wie bereits frühere Forschung zeigte, sollte man ihn als kryptografisch geknackt und für den weiteren Einsatz unbrauchbar betrachten.
Ein Hintergrundartikel auf heise Security zu den Konsequenzen der erfolgreichen Angriffe auf MD5 analysiert die Bedrohung und zeigt auch die noch etwas kargen Möglichkeiten, sich vor gefälschten Zertifikaten zu schützen.
Siehe dazu auch:
* 25C3: Erfolgreicher Angriff auf das SSL-Zertifikatsystem, News-Meldung auf heise Security
* Konsequenzen der erfolgreichen Angriffe auf MD5, Hintergrundartikel auf heise Security
Quelle : http://www.heise.de/security/Zertifizierungsstellen-reagieren-auf-MD5-Hack--/news/meldung/121164
-
Einem Sicherheitsexperten ist es gelungen, die digitale Unterschrift eines Windows-Programmes auf ein anderes zu übertragen, ohne dass diese ihre Gültigkeit verliert. Didier Stevens, der den Angriff in seinem Blog präsentierte, machte sich dabei zunutze, dass Microsofts Authenticode-Standard für Code-Signaturen auch den schwachen Hash-Algorithmus MD5 zulässt. So konnte Stevens zwei Programme erstellen, die die selbe Code-Unterschrift besitzen, sich aber unterschiedlich verhalten.
Derartige Kollisionsangriffe gegen MD5 haben in der Vergangenheit bereits für einigen Wirbel gesorgt. Prominentestes Beispiel ist wohl die Arbeit einer Forschergruppe, die sich auf diese Weise ein Herausgeber-SSL-zertifikat beschaffen konnte, das alle gängigen Browser als verstrauenswürdig einstufen. Der Angriff gegen Authenticode erfordert nur minimale Änderungen der bereits erhältlichen Tools zur Kollisionsberechnung, da Authenticode-Signaturen die Dateiprüfsumme und den Zeiger auf die Signatur einer Windows-Programmdatei nicht berücksichtigen, da sich diese durch den Signaturprozess verändern.
Eigentlich soll das Code-Signing sicherstellen, dass das Betriebssystem in sicherheitskritischen Situationen nur von höherer Stelle abgesegneten Programmcode ausführt, ohne dass der Anwender eine Warnmeldung zu sehen bekommt. Ein Angriff auf die Code-Signatur ließe sich daher beispielsweise ausnutzen, um weitgehend unbemerkt Schadprogramme auf ein System zu schmuggeln und durch den Nutzer starten zu lassen. Auch die Installation von Treibern erfordert gültige Code-Signaturen, damit sie den Anwender nicht mit Warndialogen konfrontiert.
Der von Stevens gezeigte Angriff ist jedoch in der Praxis weitgehend irrelevant. Nach dem derzeitigen Stand der Forschung müsste man eine vertrauenswürdige Instanz, deren Code-Signaturen Windows als vertrauenswürdig einstuft, dazu bringen, eine präparierte Datei mit einer MD5-basierten Signatur zu unterschreiben. Die Voreinstellung von Microsofts SignTool für Authenticode-Unterschriften sieht jedoch den sichereren SHA1-Hash für die Signatur vor, sodass man kaum an eine solche Unterschrift gelangen dürfte. Doch egal ob Schadcode oder nicht: Weil das Gros der Programme und auch viele Treiber keine gültige Code-Signaturen tragen, dürften die meisten Anwender ohnehin gewohnt sein, Warnungen bei fehlenden oder nicht vertrauenswürdigen Code-Signaturen unbeachtet wegzuklicken.
Quelle : www.heise.de
-
Was zunächst wie ein Phishing-Angriff auf Kunden der Bank of America erscheint, stellt sich bei näherer Betrachtung als mögliche neue Waledac-Kampagne heraus. Statt eines neuen Zertifikats erhalten die Opfer einen Spambot.
Die Masche ist nicht ganz neu, wird jedoch nicht so oft angewendet. Sie erhalten eine Mail (vorgeblich) von Ihrer Bank, in der Sie dazu aufgefordert werden ein Online-Zertifikat zu erneuern. Dazu sollen Sie sich auf der Website Ihrer Bank anmelden, ein Link wird freundlicherweise gleich mitgeliefert. Nachdem Sie Ihre Zugangsdaten auf der gefälschten Bank-Website eingegeben haben, erhalten Sie eine EXE-Datei zum Download angeboten.
Diese Kreuzung aus Phishing (Identitätsdiebstahl) und Malware-Verbreitung haben Online-Kriminelle am Pfingstwochenende bei Kunden der Bank of America versucht. Die Versender schicken die Mails Spam-artig, also ungezielt heraus, denn sie wissen nicht, wer Kunde bei welcher Bank ist. Die Mails kommen mit einem Betreff wie "You need to update the certificate for your account" und gefälschten Absenderangaben. Der enthaltene Link führt zu einer Nachahmung der Website der Bank of America, die auf einem von etlichen Zombie-PCs eines Botnet liegt.
Nach Eingabe der Anmeldedaten startet der Download einer 80 KB große Datei namens "sophialite.exe". Dabei handelt es sich jedoch nicht um ein SSL-Zertifikat sondern um einen Spambot. Er nistet sich tief im System ein und verschickt dann massenhaft Spam-Mails. Wie G.N. White vom Internet Storm Center vermutet, sieht der Schädling nach einer neuen Variante aus der Waledac-Familie aus.
Die Antivirushersteller sind sich in dieser Frage nicht so ganz einig, immerhin erkennen die Mehrzahl der Virenscanner den Schädling inzwischen - darauf kommt es letztlich an.
Quelle : www.pcwelt.de
-
Schwächen im Hash-Algorithmus MD-5 machen viele Seiten, die auf SSL-Verschlüsselung setzen, angreifbar. Deswegen will der Erfinder von SSL, Dr Taher Elgamal, nun Anreize dafür schaffen, angreifbare Zertifikate schneller auszutauschen.
Die Schwächen in MD-5 wurden bereits im vergangenen Jahr bekannt. Durch Erzeugen sogenannter Hash-Kollisionen, also anderen Daten, die einen identischen Hash ergeben, können Angreifer gefälschte Websites mit gefälschten Zertifikaten kreieren. Diese kann der Webbrowser aufgrund des identischen Hash-Wertes nicht vom Original unterscheiden. Die gefälschten Seiten könnten dann beispielsweise zum Diebstahl sensibler Daten oder zur Verbreitung von Malware benutzt werden.
Um dieses Szenario auszuschließen, müssen die Betreiber von Websites auf neuere und sicherere Hash-Algorithmen ausweichen. Dazu müssen sie neue Zertifikate beantragen, die dann den neuen Algorithmus verwenden. Dieser Prozess jedoch geht bislang nur sehr schleppend vorwärts. Elgamal schlug daher vor, dass VeriSign, die größte Vergabestelle für derartige Zertifikate, SSL-Zertifikate, die mit sichereren Hash-Algorithmen wie SHA-2 signiert sind, zu einem Vorzugspreis anbieten sollte.
Zudem sprach sich der Sicherheits-Guru für bessere Prüfverfahren in den Webbrowsern sowie einen besseren Schutz vor im Internet verbreiteter Malware (vor allem durch sogenanntes Sandboxing, bei dem Code in einer abgeschlossenen Umgebung abläuft) aus.
Quelle : www.gulli.com (http://www.gulli.com)
-
Warnungen bei Unstimmigkeiten von SSL-Zertifikaten auf Web-Servern halten Anwender kaum davon ab, eine Webseite zu besuchen, haben Forscher der Carnegie Mellon University herausgefunden. In ihren Beobachtungen hatten mehr als 55 Prozent der Probanden die Warnmeldungen einfach ignoriert und weggeklickt. Neu ist diese Erkenntnis sicher nicht, allerdings haben die Forscher nun offenbar erstmals die Quantität des Problems vermessen.
Demnach ist das Verständnis von Zertifikaten bei den meisten Anwender fundamental falsch. So waren sie bei ihrer Meinung nach vertrauenswürdigen Webseiten bei Fehlermeldungen weniger misstrauisch als bei nicht vertrauenswürdigen. Der Versuch einer Man-in-the-Middle-Attacke bei einer Banking-Seite würde demzufolge weniger Argwohn wecken, als bei einer unbekannten Shopping-Seite. Nach Angaben der Forscher missverstehen viele den Umstand, dass ein Zertifikat nur attestieren soll, auf der richtigen Seite gelandet zu sein. Ob der Betreiber vertrauenswürdig ist, sagt ein SSL-Zertifikat nicht.
Das Problem sei, das Anwender die Fehlermeldungen des Browsers bei Problemen mit dem Zertifikat nicht richtig deuten könnten, etwa wenn ein Zertifikat abgelaufen sei oder die aufgerufene Domain nicht mit der Servernamen im Zertifikat übereinstimmte. Dazu komme, dass derartige Probleme auch immer wieder regulär wegen technischer Fehler aufträten und Anwender gewohnheitsmäßig die Meldungen wegklickten.
Wirklich repräsentativ ist die Studie jedoch nicht. Es wurde nur das Verhalten von 100 Probanden mit verschiedenen Webbrowsern untersucht. Laut Untersuchung hätten dabei Nutzer des Firefox-Browser am wenigsten Warnmeldungen ignoriert, da dieser eine "einfachere" Sprache und bessere Dialoge aufweise. Die Forscher haben daraufhin mit eigenen Warnmeldungen experimentiert. Ihre Ergebnisse wollen sie auf dem kommenden Usenix Security Symposium veröffentlichen.
Quelle : www.heise.de (http://www.heise.de)
-
Der Sicherheitsspezialist Jacob Appelbaum (http://www.appelbaum.net/) hat auf der Hacker-Mailingliste Noisebridge (https://www.noisebridge.net/wiki/Noisebridge) ein SSL-Zertifikat und den dazugehörigen privaten Schlüssel veröffentlicht, mit denen ein Webserver in verwundbaren Browsern keine Fehlermeldung provoziert – egal für welche Domain er das Zertifikat ausliefert. Phisher könnten dies etwa für Phishing-Angriffe ausnutzen und ihren Server als legitimen Bankserver ausgeben – was erst bei genauerer Prüfung des Zertifikats auffliegen würde.
Anzeige
Für seinen Trick hat Applebaum das Zertifikat nach der von Moxie Marlinspike auf der Black Hat demonstrierten Methode manipuliert und im Namensfeld (CN, Common Name) ein Nullzeichen (\0) eingetragen.
Anders als Marlinspike hat Appelbaum das Nullzeichen aber nicht zwischen dem Domainnamen und den Namen der im Besitz von Marlinspike befindlichen Domain thoughtcrime.org eingetragen. Vielmehr hat er durch den Eintrag *\00thoughtcrime.noisebridge.net quasi eine Wildcard-Zertifikat für beliebige Domainnamen geschaffen.
(http://www.heise.de/bilder/146129/0/1)
Die ältere Version 3.0.11 des Firefox-Browser akzeptierte das präparierte Zertifikat klaglos.
In einem ersten Test der heise-Security-Redaktion führte der Aufruf (nach der zusätzlichen Installation des Intermediate-Zertifikats des Ausstellers IPS CA im Webserver) in verwundbaren Browsern zu keiner Fehlermeldung. Glücklicherweise gibt es jedoch seit mehreren Wochen Updates für alle populären Browser, damit diese nicht mehr auf den Trick mit der Null hereinfallen.
Auch viele andere Produkte und Frameworks, die Verbindungen mit SSL sichern und dazu Server-Zertifikate verifizieren, sind bereits aktualisiert. Aus diesem Grund sieht Appelbaum auch keine Probleme damit, sein "Internet-Zertifikat" zu veröffentlichen. Entwickler hätten nun nach seiner Meinung ein Zertifikat in der Hand, um ihre eigenen Programme auf die Schwachstelle zu testen.
Allerdings sollten Anwender nicht automatisch davon ausgehen, dass ihre Applikationen die Lücke nicht mehr aufweisen. So hat beispielsweise der Hersteller RIM für seine BlackBerry-Produkte erst gestern das Update für das Zertifikatsproblem veröffentlicht.
Quelle : www.heise.de
-
Schwachstellen im SSL/TLS-Protokoll lassen sich Berichten zufolge von Angreifern ausnutzen, um in geschützte Verbindungen eigene Inhalte einzuschleusen. Betroffen wären neben HTTPS auch alle anderen Protokolle wie IMAP, die zur Transportsicherung TLS einsetzen. Über die genauen Auswirkungen des Problems wird noch diskutiert. Möglich wäre aber offenbar, etwa HTML-Inhalte von Webseiten während der Übertragung zu manipulieren und beispielsweise Schadcode zu injizieren.
Knackpunkt der Probleme ist statt eines Implementierungsfehlers ein Designfehler im TLS-Protokoll bei der Neuaushandlung der Parameter einer bestehenden TLS-Verbindung (TLS Renegotiation). Diese findet beispielsweise statt, wenn ein Client auf einem Webserver auf einen geschützten Bereich zugreifen will und der Server ein SSL-Client-Zertifikat zur Authentifizierung anfordert. Allerdings sieht das Protokoll offenbar keine eindeutig authentifizierte Zuordnung eines Client-Requests auf eine bestimmte URL zu dem anschließend ausgelieferten Client-Zertifikat vor – der Server nimmt es einfach als korrekt an. Die Entdecker der Probleme sprechen daher in diesem Zusammenhang von einem "Authentication Gap".
Ein Angriff könnten laut Bericht etwa so funktionieren: Ein Angreifer schleift sich in die Verbindung zwischen Client und Server ein und baut mit dem Server eine HTTPS-Verbindung auf. Die Verbindung zum Client hält er zunächst kurzfristig in einem unvollendeten Zustand. Anschließend schickt er an den Server einen HTTPS-Request auf einen geschützten Bereich, der daraufhin eine Neuaushandlung für eine völlig neue Verbindung startet und das Client-Zertifikat anfordert. Alle folgenden Pakete leitet der Angreifer nun unverändert zwischen Server und Client weiter. Abschließend wird der HTTP-Request des Angreifers im Kontext des Clients ausgeführt, beispielsweise ein POST-Request für ein geschütztes Formular.
Konkret wurden die Probleme auf aktuellen Versionen der Webserver von Microsoft IIS und der Apache Foundation httpd nachvollzogen. Daneben ist auch OpenSSL betroffen. Ben Laurie hat bereits einen Patch entwickelt, der aber das eigentliche Problem nicht beseitigt, sondern nur nur die Neuaushandlungen verhindert. Über eine nachhaltige Lösung wird diskutiert. Möglich wäre ein frühzeitiges Ausliefern von Client-Zertifikaten noch vor dem Anfordern einer konkreten URL. Nebenbei soll die TLS Channel Bindings Working Group der IETF an einem Draft arbeiten. Möglicherweise gibt es daher schon eine Lösung.
Quelle : www.heise.de
-
Das OpenSSL-Project (http://www.openssl.org/) hat auf eine Schwachstelle im SSL/TLS-Protokoll reagiert, die am 4. November bekannt wurde . Eine neue Version (OpenSSL 0.9.8l) soll mögliche Angiffe auf die Crypto-Bibliothek unterbinden.
Bei der Schwachstelle geht es um einen Designfehler im TLS-Protokoll bei der Neuaushandlung der Parameter einer bestehenden TLS-Verbindung (TLS Renegotiation). Diese findet beispielsweise statt, wenn ein Client auf einem Webserver auf einen geschützten Bereich zugreifen will und der Server ein SSL-Client-Zertifikat zur Authentifizierung anfordert.
Das TLS-Protokoll sieht offenbar keine eindeutig authentifizierte Zuordnung eines Client-Requests auf eine bestimmte URL zu dem anschließend ausgelieferten Client-Zertifikat vor – der Server nimmt es einfach als korrekt an. Die Entdecker der Probleme sprechen daher in diesem Zusammenhang von einem "Authentication Gap".
Die Entwickler von OpenSSL haben diese Sicherheitslücke im Protokoll nicht gefixt, sondern schlicht die TLS Renegotiation per Voreinstellung komplett abgeschaltet. Eine Neuaushandlung der Parameter sei damit generell nicht mehr möglich, schreibt das OpenSSL-Projekt in den "Release Notes". Es geht folglich zunächst darum, die Folgen der Schwachstelle zu mildern, eine Behebung der Ursache kann sich noch Wochen hinziehen.
Ein Experte vom Internet Storm Center rät zur Vorsicht bei der Anwendung des Updates. Bevor man die neue Version in eine Produktivumgebung einspiele, solle man sie mit der Web-Applikation und allen verwendeten Clients testen. Es könne durchaus zu Funktionsstörungen kommen, wenn die TLS Renegotiation verhindert wird.
Quelle : www.heise.de
-
Ein neuer Hack für den Microblogging-Dienst Twitter beweist, dass eine vor Kurzem bekannt gewordene SSL-Schwachstelle auch praktisch ausnutzbar ist.
Anil Kurmus, einem türkischer Studenten, der bald in Zürich seinen Master-Abschluss bekommen wird, gelang es offenbar, den sogenannten SSL Renegotiation Bug (gulli:News berichtete) für einen Hack gegen Twitter auszunutzen. Bisher waren zahlreiche Experten davon ausgegangen, dass der Bug zu kompliziert und "esoterisch" sei, um ihn in der realen Welt auszunutzen - zu kompliziert in der Durchführung und mit einem zu beschränkten Ergebnis. Kurmus bewies das Gegenteil, indem er es schaffte, die verschlüsselt übertragenen Login-Daten von Twitter-Accounts mitzulesen.
Die Durchführung des Hacks war dabei sehr kreativ. Der Bug erlaubt es nicht, ohne weiteres Daten mitzulesen - möglich ist lediglich ein Injizieren eigener Daten in die verschlüsselte Nachricht. Das allerdings reichte Kurmus: Er injizierte einen Befehl, der dem Twitter-Server befahl, die Login-Daten nach erfolgter Entschlüsselung in eine Twitter-Nachricht zu schreiben.
Kurmus sagte, er habe beweisen wollen, dass es nicht so schwer sei, diese Schwachstelle auszunutzen. "Vielleicht haben einige andere Leute das selbe getan und es nicht öffentlich gemacht, deswegen glaube ich, dass es wichtig ist, dass die Leute diesen Bug ernster nehmen," erklärte er.
Twitter, so Kurmus, sei für den Angriff ideal gewesen, da in jeder Nachricht Benutzername und Passwort enthalten seien. Zudem habe es die API des Dienstes leicht gemacht, die Daten in eine Nachricht zu schreiben und an sich selbst zu schicken. Zudem würden die von vielen Benutzern verwenderen Third-Party-Clients SSL-Fehler ignorieren, so dass Kurmus bei seinem Angriff leicht unbemerkt bleiben konnte.
Die von Kurmus ausgenutzte Lücker bei der SSL-Implementierung von Twitter wurde vom Sicherheitsteam des Microblogging-Dienstes letzte Woche geschlossen. Offenbar hatte Kurmus, wie in Kreisen der "White Hats" üblich, den Entwicklern Zeit gegeben, ihren Dienst abzusichern, bevor er mit seinen Erkenntnissen an die Öffentlichkeit ging.
Bis heute gibt es keine SSL-Implementierung, in der die Schwachstelle behoben ist. Es gibt allerdings bei einigen Anbietern Workarounds, die eine Ausnutzung des Bugs verhindern - wobei allerdings Kompatibilitätsprobleme nicht auszuschließen sind. Einzig OpenSSL soll zumindest nah daran sein, einen wirksamen Patch liefern zu können. Andere Anbieter dürften länger brauchen. So ist es durchaus wahrscheinlich, dass andere Internetseiten und Dienste noch immer angreifbar sind.
Quelle : www.gulli.com
-
Für die Anfang November vorigen Jahres bekannt gewordene TLS-Renegotiation-Schwachstelle im Design des SSL/TLS-Protokolls zeichnet sich eine Lösung ab, die das Problem beheben soll. Die IETF hat dazu RFC 5246 (The Transport Layer Security [TLS] Protocol Version 1.2) erweitert und die neue TLS-Extension renegotiation_info eingeführt, die kryptografisch relevante Informationen einer Verbindung speichert. Bislang fehlte dem TLS-Protokoll eine eindeutig authentifizierte Zuordnung eines Client-Requests vor einer TLS-Renegotiation zu dem Request nach der Neuaushandlung. Die Erweiterung nimmt nun zusätzliche Informationen auf, die den Zustand einer TLS-Verbindung speichern sollen ("secure_renegotiation", "client_verify_data" und "server_verify_data").
Durch die Lücke ist es Angreifern möglich, eigene Pakete in gesicherte SSL-Verbindungen einzuschleusen und so beispielsweise Webanwendungen zu manipulieren. Auf diese Weise war es einem Entwickler bei Testangriffen auf Twitter gelungen, per SSL übertragene Tweets eines Opfers an eigene Tweets anzuhängen und auf diese Weise an die Authentifzierungsdaten im Cookie zu gelangen. Die Schwachstelle ermöglicht es jedoch nicht, eine SSL-Verbindung direkt im Klartext mitzulesen.
Ursache des Problems ist ein Designfehler im TLS-Protokoll bei der Neuaushandlung der Parameter einer bestehenden TLS-Verbindung. Diese kann zu unterschiedlichen Anlässen auftreten, beispielsweise wenn ein Client auf einem Webserver auf einen geschützten Bereich zugreifen will und der Server ein SSL-Client-Zertifikat zur Authentifizierung anfordert.
Hier sieht das Protokoll keine eindeutig Zuordnung des Requests auf eine bestimmte URL zu dem anschließend ausgelieferten Client-Zertifikat vor – der Server nimmt es einfach als korrekt an. Die Entdecker der Probleme sprechen daher in diesem Zusammenhang von einem "Authentication Gap". Eine bildliche Darstellung eines möglichen Angriffs ist hier zu finden.
Als Workaround hatten die meisten Hersteller einfach TLS-Renegotiation abgeschaltet. Zu größeren Störungen hat dies aber offenbar nicht geführt. Mit der Verabschiedung des Drafts "Transport Layer Security (TLS) Renegotiation Indication Extension" können die Hersteller nun an einem Patch arbeiten, der TLS-Renegotiation wieder aktiviert, sie aber zugleich sicherer macht. Bis dahin müssen aber noch zahlreiche Tests durchgeführt werden; insbesondere die Interoperabilität und Rückwärtskompatibiltät verschiedener Implementierungen muss sichergestellt sein. Ein Überblick über den Status der einzelnen Hersteller gibt es hier (http://www.phonefactor.com/sslgap/ssl-tls-authentication-patches).
-
Rund 300 Websites, darunter die der CIA, des Anonymisierungsdienstes Tor, der Suchmaschine Yahoo und des Payment-Dienstes PayPal, stehen derzeit unter einem merkwürdigen Angriff. Die Webserver werden dabei mit zahlreichen rechenintensiven SSL-Anfragen "bombardiert".
Die Angreifer, die bereits seit einigen Tagen aktiv zu sein scheinen, stellen zahlreiche Webserver-Anfragen über den SSL-Verschlüsselung anbietenden HTTPS-Port. SSL-verschlüsselte Verbindungen, die normalerweise für die Übertragung vertraulicher Daten genutzt werden, verbrauchen auf dem Server mehr Ressourcen als unverschlüsselte Verbindungen. Außer dem Verbindungsaufbau und dem Senden einiger offenbar sinnloser Daten unternehmen die Angreifer, infizierte "Zombie"-PCs, nichts. Sie fragen keine Ressourcen vom Webserver ab. Sicherheitsexperten haben noch keine Erklärung für das Verhaltensmuster, das nicht zu den Charakteristika eines normalen DDoS-Angriffs passt. Es scheint nicht das Ziel der Angreifer zu sein, die Seiten durch Überlastung aus dem Netz zu befördern, auch wenn dies bei schwächerer Hardware in Einzelfällen vorkommen kann. Die Experten überlegen, ob dieses Verhalten womöglich eine Art Tarnung ist, um die Bots wie "normale" Clients aussehen zu lassen, wissen aber nicht, wieso der Betreiber dafür einen derartigen Aufwand betreiben sollte.
Sicherheitsforscher vermuten, dass das kürzlich runderneuerte Pushdo-Botnet hinter den Angriffen steckt. Die Dimension der Angriff ist durchaus ernstzunehmend. Laut Sicherheitsexperte Steven Adair ist "eine unerwartete Traffic-Zunahme von einigen Millionen Anfragen, die sich auf einige Hunderttausend IP-Adressen verteilen", wahrscheinlich. "Dies könnte ein ernstes Problem sein, wenn man normalerweise nur einige Hundert oder Tausend Anfragen am Tag hat oder wenn man keine unbegrenzte Bandbreite hat," so Adair.
Hilfreiche Abwehrstrategien sind derzeit noch Mangelware. Als Sofortmaßnahme empfehlen Experten einen Wechsel der IP-Adresse. Sie fordern jeden, der effektivere Strategien findet, auf, sich zu melden.
Quelle : www.gulli.com
-
Die Electronic Frontier Foundation (EFF) warnt davor, dass staatliche Stellen SSL-gesicherte Verbindungen mittlerweile wahrscheinlich routinemäßig abhören könnten.Sie verweisen dabei unter anderem auf den Entwurf einer Forschungsarbeit (PDF-Datei (http://files.cloudprivacy.net/ssl-mitm.pdf)) in der die Wissenschaftler Christopher Soghoian and Sid Stamm Anhaltspunkte für diese Vermutung zusammentragen und eine mögliche Abwehrstrategie beschreiben.
Harte Fakten können die beiden jedoch nicht liefern. Sie legen zunächst dar, dass viele Regierungen Unternehmen routinemäßig zur Kooperation bei Überwachungsmaßnahmen zwingen. In den USA sei das Statut, nach dem Firmen zur Kooperation gezwungen werden könnten, "außerordentlich breit ausgelegt". So habe man beispielsweise einen Navigationsgerätehersteller dazu gebracht, zum Mitschneiden der Gespräche in einem Fahrzeug das eingebaute Mikrofon zu aktivieren. VeriSign, der größte Anbieter von SSL-Zertifikaten, sei außerdem an Geschäften zum Outsourcing von Telekommunikationsüberwachung beteiligt.
Konsequenterweise müssten, so ihre Schlussfolgerung, Regierungsstellen auch die Möglichkeit haben, Zertifikatsdienstleister wie VeriSign zum Ausstellen beliebiger SSL-Zertifikate zu zwingen ("compel"). In vielen Ländern gebe es ohnehin staatliche Certificate Authorities (CA), die in den gängigen Browsern als vertrauenswürdige Root-Instanzen hinterlegt sind. Internet Explorer, Firefox, Safari und Chrome vertrauen blind über 100 Herausgeberzertifikaten, darunter von VeriSign, der Telekom, aber auch etwa der Netzwerverwaltungsbehörde CNNIC, die der Chinesischen Regierung untersteht.
Präsentiert ein Webserver ein von ihnen unterschriebenes Zertifikat, signalisieren sie dem Anwender durch ein Schlosssymbol oder eine grüne Adressleiste, dass die Verbindung vertrauenswürdig sei. Doch das SSL-Konzept basiert auf der Vertrauenswürdigkeit der Zertifikatsherausgeber (CAs). Wer über die Kopie des geheimen Schlüssels eines Herausgeberzertifikates oder über ein Intermediate-Zertifikat einer großen CA verfügt, kann SSL-Zertifikate "on-the-fly" fälschen und verschlüsselte Verbindungen abhören.
Soghoian und Stamm fanden darüber hinaus auch eine kommerzielle Hardware-Appliance, die durchgeleitete SSL-Verbindungen unbemerkt abhören kann. Der Hersteller Packet Forensics wirbt damit, dass man zum Betrieb des Gerätes lediglich eine Kopie eines legitimen Zertifikatschlüssels benötigt. Er weist auch ausdrücklich darauf hin, dass man einen solche Kopie etwa per Gerichtsbeschluss erlangen kann.
In dem Paper zitieren die Forscher den Packet-Forensics-Chef Victor Oppelman damit, dass die Appliance bereits bei Kunden aus den USA und anderen Ländern im Einsatz sei. Der Produktwerbetext umgarnt die Zielgruppe unmissverständlich: "Ihre Ermittler werden wahrscheinlich die besten Beweise sammeln, solange sich Nutzer in der falschen Sicherheit von Web-, E-Mail und VoIP-Verschlüsselung wiegen."
Soghoian und Stamm beschreiben als möglichen Schutz ein Firefox-Add-on, das Zertifikatsinformationen aller besuchten SSL-Websites speichert. Bei jedem Aufruf vergleicht es die aktuellen Daten damit und warnt, wenn eine der CAs im Zertifikatspfad aus einem anderen Land kommt als bisher. Änderungen wie ein wegen Ablaufs des alten neu ausgestelltes Zertifikat lösen keine Warnung aus. Die Wissenschaftler setzen dabei auf den gesunden Menschenverstand: "Wenn Nutzer in China erfahren, dass ihre verschlüsselte Verbindung zu Google Mail plötzlich ein Zertifikat einer chinesischen CA verwendet, dürften sie vermutlich merken, dass etwas nicht stimmt."
Studien besagen allerdings, dass die meisten Nutzer Warnmeldungen einfach wegklicken. Außerdem würde das vorgeschlagene Verfahren, wie die Wissenschaftler selbst einräumen, nicht davor schützen, dass Bürger von US-Stellen ausgespäht werden, da US-Firmen den Zertifikatsmarkt quasi beherrschen. So verwenden viele Web-Sites in Deutschland Zertifikate von VeriSign. Und schließlich bietet das Firefox-Add-On namens Certloc, das sie demnächst veröffentlichen wollen, auch keinen Schutz für andere Anwendungen für E-Mail oder Internet-Telefonie.
Quelle : www.heise.de
-
Präparierte TLS-Pakete können einen OpenSSL-Server oder -Client zum Absturz bringen. Ursache ist ein Fehler in der Funktion ssl3_get_record() zur Verarbeitung von SSL-Records. In SSL-Records werden die Daten zwischen den Endpunkten übertragen. Falsch formatierte Records führen laut Bericht der OpenSSL-Entwickler zu einem Speicherzugriffsfehler.
Grundsätzlich sind die Versionen OpenSSL 0.9.8f bis einschließlich 0.9.8m betroffen. Allerdings kommt der Fehler nicht überall zum Tragen, sondern ist abhängig vom C-Compiler. Wo "short" als 16 Bit langer Integer definiert ist, ist nur 0.9.8m verwundbar – das trifft jedoch fast immer zu. Abhilfe bringt ein Update auf die OpenSSL-Version 0.9.8n .
Siehe dazu auch:
* "Record of death" vulnerability in OpenSSL 0.9.8f through 0.9.8m (http://openssl.org/news/secadv_20100324.txt) , Fehlerbericht von OpenSSL
Quelle : www.heise.de
-
Der Herausgeber von SSL-Zertifikaten Comodo wurde nach Angaben des Tor-Entwicklers Jacob Appelbaum und laut einem Blogeintrag der Mozilla Foundation möglicherweise kompromittiert. In der Folge gelangten Kriminelle an neun Zertifikate bereits existierender Webseiten, darunter auch addons.mozilla.org. Ob der Fehler auf die mangelnde Prüfung bei der Ausstellung oder auf die Kompromittierung der Infrastruktur von Comodo zurückzuführen ist, ist derzeit offiziell nicht bekannt.
Was zunächst wie ein Problem von Comodo aussieht, zwingt nun jedoch die Hersteller der Browser dazu, Gegenmaßnahmen zu ergreifen und Updates zu veröffentlichen. Kriminelle könnten sonst Anwender etwa auf eine nachgemachte Seite für Firefox-Plug-ins umlenken und dort infizierte Add-ons zur Installation anbieten – da das Server-Zertifikat auf addons.mozilla.org ausgestellt wäre und gültig ist, schöpft der Anwender keinen Verdacht, und Firefox schlägt keinen Alarm. Ähnliche Angriffe wären auch auf das Online-Banking denkbar.
PKI-Infrastrukturen sehen das Zurückziehen von kompromittieren Zertifikaten vor, wozu die Anbieter entweder Zertifikatssperrlisten (CRL) zum Download oder die Online-Prüfung via Online Certificate Status Protocol (OCSP) anbieten. Der Browser soll dann das gerade vom Server angebotene Zertifikat prüfen können. Daher hieß es seitens der Herausgeber von Zertifikaten (Certificate Authority, CA) in solchen Fällen jahrelang "Alles kein Problem".
So weit die Theorie. In der Praxis zeigt sich nun jedoch, dass sich die Abfrage via CRL und OCSP blockieren lässt, ohne dass ein Browser in der Standardeinstellung auf dieses Problem hinweisen würde. In der Folge versagt die Prüfung, der Anwender wird nicht gewarnt. Aus diesem Grund hat Comodo wohl die Hersteller aller wichtigen Browser kontaktiert und ihnen die Seriennummern der betreffenden Zertifikate zukommen lassen. Die Seriennummer sollen nun als Blacklist im Browser fest einkodiert werden, um auch ohne CRL und OCSP einen Alarm zu verursachen.
Google hat bereits vergangene Woche mit Chrome 10.0.648.151 reagiert, die Mozilla Foundation hat die Blacklist gerade noch in Firefox 4 einpflegen können, die neuen Versionen Firefox 3.6.16 und Firefox 3.5.18 enthalten die Liste ebenfalls. Für den Internet Explorer ist nach Angaben der Tor-Entwicklers Jacob Appelbaum, der seit vergangener Woche in Kontakt mit den Herstellern und Comodo steht, ein Mitigation Pack auf dem Weg. Zu Update-Planungen von Opera und Apple ist derzeit nichts bekannt.
Der Vorfall zeigt erneut, dass das gesamten Konzept von SSL und der Vertrauensstellung der Anwender gegenüber den Certificate Authorities auf tönernen Füßen steht. Letztlich wird einem Zertifikat auch dann vertraut, wenn es von einem CA-Reseller ausgestellt ist, in dessen Herkunftsland man vermutlich aus Sicherheitsgründen nicht mal Urlaub machen möchte. Und selbst wenn dann ein Missbrauch publik wird, funktionieren die dafür vorgesehenen Techniken nicht. Es ist Zeit, ein neues Konzept zu entwickeln – sogenannte EV-SSL-Zertifikate gehören auf jeden Fall nicht dazu.
Quelle : www.heise.de
-
Microsoft hat ein außerplanmäßiges Update für Windows veröffentlicht, mit dem neun SSL-Zertifikate gesperrt werden, die kürzlich in die Hände von Kriminellen gelangt sind. Die Schuld trägt Comodo als Herausgeber der Zertifikate.
Das System des Unternehmens wurde kompromittiert, so dass Hacker insgesamt neun Zertifikate von bereits existierenden Websites erhalten konnten. Sämtliche Browser-Hersteller müssen ihre Produkte nun mit einem Update versorgen, das die Zertifikate auf eine Blacklist setzt. Google beseitigte die Sicherheitslücke mit Chrome 10.0.648.151, Mozilla setzte die notwendigen Änderungen noch mit Firefox 4.0 um.
Nun hat auch Microsoft ein entsprechendes Update für Windows bzw. den Internet Explorer veröffentlicht. Es wird seit der letzten Nacht via Windows Update angeboten. Informationen darüber findet man im Security Advisory 2524375 (http://www.microsoft.com/technet/security/advisory/2524375.mspx). Eine manuelle Downloadmöglichkeit für Windows 7, Vista, XP sowie die Server-Versionen bietet die Microsoft Knowledge Base (http://support.microsoft.com/kb/2524375).
Laut Microsoft sind die folgenden Domains von den gestohlenen SSL-Zertifikaten betroffen:
login.live.com
mail.google.com
www.google.com
login.yahoo.com (3 Zertifikate)
login.skype.com
addons.mozilla.org
Global Trustee
Im schlimmsten Fall könnten die Kriminellen die SSL-Zertifikate nutzen, um nachgemachte Websites zu gestalten, die dem Besucher Schadsoftware unterschieben. Da der Browser ein gültiges Zertifikat erkennt, wird kein warnender Hinweis ausgegeben. Manipulieren die Angreifer DNS-Einträge, könnten sogar sehr viele Anwender auf die schadhafte Website umgelenkt werden.
Eigentlich hatten die Herausgeber von SSL-Zertifikaten einen Mechanismus implementiert, der in genau solchen Fällen aktiv werden soll und den Browser darüber informiert, dass ein Zertifikat nicht gültig ist, da es gestohlen wurde. Doch in der Praxis stellte sich nun heraus, dass sich die dafür benötigten Anfragen des Browsers blockieren lassen und die Schutzmechanismen somit nicht zum Einsatz kommen.
Quelle : http://winfuture.de
-
Comodo hat weitere Informationen zu der Kompromittierung seiner Certificate Authority veröffentlicht, bei der ein unbekannter Angreifer an SSL-Zertifikate für bereits bestehende Webseiten gelangt ist. Zu den Domains gehören login.live.com, mail.google.com, www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org sowie ein nicht näher bezeichneter "Global Trustee".
Die Kompromittierung erfolgte den Ermittlungen zufolge über den Account eines Resellers, der sogenannte Certificate Signing Request (CSR) prüft und an die Systeme von Comodo weiterreicht. Ein CSR ist ein Antrag auf Signierung eines öffentlichen Schlüssels durch eine CA und wird heutzutage per Weboberflache eingereicht. Der Eindringling gelangte an die Zugangsdaten des Resellers; konkrete Angabe zum Reseller macht Comodo nicht. Es soll sich jedoch um einen Anbieter in Südeuropa handeln, was sehr viel Interpretationsspielraum lässt.
Mit den Zugangsdaten loggte sich der Unbekannte, dessen Spuren nach Teheran führen, ein und erzeugte neun CSRs, wobei er für login.yahoo.com gleich drei einreichte. Laut Comodo lässt sich allerdings nicht mehr nachvollziehen, ob er wirklich alle beantragten Zertifikate auch erhielt. Comodo bestätigt nur, dass ein Zertifikat für login.yahoo.com bereits im Internet benutzt wurde.
Comodo will die Kompromittierung innerhalb weniger Stunden entdeckt und die Zertifikate zurückgezogen haben. Ob ein Zertifikat zurückgezogen wurde, können Browser über die Abfrage von Sperrlisten (CRL) oder das Online Certificate Status Protocol (OCSP) prüfen. Allerdings funktioniert dies nicht immer zuverlässig, weshalb Comodo die Browserhersteller kontaktierte, damit diese die Seriennummern der Zertifikate in eine statische Blacklist eintragen. Google und Mozilla hatten bereits reagiert, Microsoft hat am gestrigen Mittwoch ein Update für den Internet Explorer veröffentlicht, das diese Aufgabe erledigt.
Die Beobachtungen des OCSP-Responders haben laut Comodo bislang keine Hinweise ergeben, dass ein Anwender eine Webseite mit einem der Zertifikate aufgerufen hätte, was in Anbetracht der Blockiermöglichkeiten wenig Aussagekraft hat. Der Zertifikatsherausgeber betont, dass zu keiner Zeit ein System von Comodo kompromittiert wurde, es seien keine privaten Schlüssel aus den Hardware-Security-Modulen (HSM) ausgelesen worden.
Äußerst interessant ist der Schluss, den Comodo aus dem Vorfall zieht: Vieles spreche dafür, dass hinter den Angriffen die iranische Regierung stecke, die vermutlich die Kommunikationsinfrastruktur von Oppositionellen ausspähen will. Die Regierung habe die Kontrolle über das DNS, dass die Angriffe ohnehin erst möglich mache; der Vorfall ziele hauptsächlich auf Server mit Mail- und VoIP-Diensten sowie Social-Networking-Seiten.
Quelle : www.heise.de
-
Nutzer von Apples Webbrowser Safari sind immer noch durch die gefälschten Zertifikate für Windows Live, Yahoo, Skype und Google bedroht. Die schlaffe Update-Politik ist Wasser auf die Mühlen der Apple-Kritiker. Die Konkurrenz hat nämlich schon längst reagiert: Google mit der Chrome-Version 10.0.648.151, die Mozilla Foundation mit Firefox 3.6.16 und auch Microsoft hat Windows und damit dem Internet Explorer ein Update spendiert. In Firefox 4 stehen die gefälschten Zertifikate ebenfalls bereits auf der schwarzen Liste.
Verschlimmert wird die Situation noch dadurch, dass Apple bei Mac OS X die vorhandene Zertifikatsüberprüfung über OCSP (Online Certificate Status Protocol) und CRL (Certificate Revocation List) standardmäßig ausgeschaltet hat. Der Aussteller Comodo hat die gefälschten Zertifikate nämlich längst gesperrt. Die Konkurrenz prüft seit Jahren standardmäßig zumindest den Online-Status. Mac-Anwender hingegen müssen dazu zunächst das Programm "Schlüsselbundverwaltung" starten und dort unter Einstellungen im Reiter "Zertifikate" drei Optionen setzen: die beiden oberen Optionen auf "Bester Versuch", die Priorität auf "OSCP".
Sicherheit kann aber letztlich nur ein Update durch Apple bieten. Die für einen Zertifikatscheck eingesetzten Mechanismen OSCP und CRL sind nämlich alles andere als perfekt. Ein Angreifer, der mit einem gefälschten Zertifikat hantiert, könnte als Man-In-The-Middle auch die Antworten auf Prüfanfragen unterbinden. Die Browser warnen die Anwender dabei offenbar nicht oder zumindest nicht ausreichend. Das kann man aber nur zum Teil den Browser-Herstellern anlasten, haben es doch die Zertifizierungsstellen über Jahre versäumt, die dafür erforderliche, leistungsfähige und ausfallsichere Infrastruktur aufzubauen. Und regelmäßige Fehlalarme über nicht erreichbare OCSP-Server erhöhten die Sicherheit letztlich auch nicht. (adb)
Quelle (http://www.heise.de/newsticker/meldung/Safari-Anwender-durch-kompromittierte-Zertifikate-gefaehrdet-1215718.html)
-
Obwohl Mozilla beim gerade veröffentlichten Firefox 4 sowie mit Updates für Firefox 3.5/3.6 auf die Kompromittierung von Comodos Certificate Authority reagiert hat, hat die Organisation kaum eigene Erkenntnisse dazu veröffentlicht. In einem Blog-Posting (http://blog.mozilla.com/security/2011/03/25/comodo-certificate-issue-follow-up/) legt Mozilla nun nach und bezeichnet das eigene Verhalten als Fehler.
Wie die Autoren schreiben, hatte Comodo bereits am Morgen des 16. März über die Gefahr informiert. Anschließend zog Mozilla mit dem Einbau einer Blacklist die Konsequenzen und veröffentlichte am 22. März Firefox 4 sowie die Updates für Version 3.5 und 3.6.
Parallel zur Veröffentlichung erläuterte Mozilla einige Informationen zu diesen Anpassungen in einer Release Note. Mozilla war etwa besorgt, dass der Angreifer die gerade eingefügten Sicherheitsmaßnahmen blockieren könnte. Im Nachhinein war diese Informationspolitik aber die falsche Entscheidung, geben die Mozilla-Mitarbeiter zu: Man hätte die Nutzer viel schneller über die Bedrohung, die mögliche Schadensbegrenzung sowie über die damit zusammenhängenden Folgen informieren sollen.
Des Weiteren habe Mozilla Commdo aufgefordert, einen vollständigen Bericht des Vorfalls zu veröffentlichen, das Online Certificate Status Protocol (OCSP) auf Zugriffe auf die Zertifikate zu überwachen und die Registration Authority (RA) stillzulegen. Laut Mozilla hat Comodo diese drei Forderungen erfüllt. Bei der Überwachung des OCSP gab es keine Anzeichen auf eine Nutzung oder Blockade der betroffenen Zertifikate. Als letzten Punkt fordert Mozilla, dass Comodo Zwischenzertifikate (intermediate certs) anstelle der Root-Zertifikate nutzt sowie jede RA mit eigenen betreibt.
Quelle : www.heise.de
-
Ein einzelner, vermutlich iranischer Hacker will für die unautorisierte Erzeugung und Ausstellung von SSL-Zertifikaten für Webserver wichtiger Anbieter verantwortlich sein. Bislang steht unter anderem die iranische Regierung in Verdacht den Angriff begangen zu haben, um mit den Zertifikaten möglicherweise die Kommunikation von Oppositionellen im eigenen Land auszuspähen.
Auf der Textschnipsel-Seite Pastebin.com wurde ein Manifest veröffentlicht, in dem ein sich selbst als Comodo-Hacker bezeichnender 21-jähriger Details zu dem Einbruch zu dem Vorgang veröffentlicht. Sicherheitsexperten halten die Darstellung des Hacks zwar für glaubwürdig, zweifeln aber dennoch daran, dass eine Einzelperson dahinter steht.
Laut seinem Manifest will der Hacker zunächst in den Webserver des italienischen Comodo-Resellers InstantSSL.it eingebrochen sein – deren Dienste sind in der Tat seit vergangener Woche nicht mehr erreichbar. Auf dem Webserver sei er auf eine .NET-Bibliothek gestoßen, mit der der Reseller die Anträge (CSR) bei Comodo und GeoTrust für die Ausstellung eines Zertifikats einreicht. Beim Dekompilieren der in C# geschriebenen Bibliothek sei auf die festcodierten Zugangsdaten für den Comdo- und GeoTrust-Accout gestoßen.
Da die in der DLL hinterlegten URLs für GeoTrust nicht funktionierten, nutzte er das Comodo-Konto. Zwar habe er sich zum Einreichen seiner CSRs zunächst in die Funktionsweise der API einarbeiten müssen. Dies habe er, der sich selbst in seinem Manifest mehrfach selbst als äußerst talentiert bezeichnet, jedoch in 15 Minuten erledigt. Damit gelang es ihm dann die Anträge einzureichen, laut Comodo für die Domains login.live.com, mail.google.com, www.google.com, login.yahoo.com, login.skype.com und addons.mozilla.org.
Über seine Motive macht der offenbar patriotische Hacker keine klaren Angaben. Anscheinend ist er beim Versuch, RSA-Schlüssel zu faktorisieren, vom Hölzchen aufs Stöckchen gekommen und hat sich mangels Erfolg dann dem Knacken von CAs gewidmet.
Comodo hat bislang keine weiteren Informationen herausgegeben, die die Darstellung bestätigen oder sie entkräften könnten. Das Pen-Test-Unternehmen Errata Security findet zumindest die technische Darstellung schlüssig. Man selber stoße bei Sicherheitsanalysen ebenfalls oft auf hardcodierte Zugangsdaten in Dateien, von denen die Entwickler annehmen würde, dass sie dort niemand auslesen könne.
Der Metasploit-Entwickler H.D. Moore bezweifelt auf Twitter, dass einer alleine den Einbruch gemeistert hat. Mikko Hyyponen von F-Secure will ebenfalls an keinen Einzeltäter glauben. "Sollen wir wirklich glauben, dass ein einzelner Hacker in eine CA einbricht und sich dann statt eines Zertifikat für paypal.com eines für yahoo.com ausstellt?", fragt er. Angesichts der Fähigkeiten der Täter, die zum Erlangen der Zertifikte nötig waren, gibt es aber auch Spekulationen, dass die Fähigkeiten nun auch für ein Ablenkungsmanöver ausreichen, wie es das Manifest sein könnte.
Quelle : www.heise.de
-
Der kürzliche Sicherheitsvorfall bei der SSL-CA Comodo beziehungsweise deren Reseller GlobalTrust beschäftigt mittlerweile die Ermittlungsbehörden. Sowohl die US-Bundespolizei FBI als auch die italienischen Behörden - GlobalTrust ist in Italien ansässig - befassen sich mit dem Vorfall, bei dem mehrere gefälschte Zertifikate für namhafte Websites ausgestellt wurden.
Bei dem Vorfall waren Zertifikate zu insgesamt neun namhaften Websites, darunter Subdomains von Mozilla, ICQ und Skype, missbräuchlich ausgestellt worden. Nun wird ermittelt. Wie Comodo-CEO Melih Abdulhayoglu am gestrigen Dienstag gegenüber Pressevertretern mitteilte, gibt es momentan "laufende Ermittlungen", an denen sowohl das FBI als auch die italienische Polizei beteiligt ist.
"Wir lassen die Behörden diese Sache handhaben und herausfinden, was genau hier passiert ist," erklärte Abdulhayoglu. Über den Stand der Ermittlungen konnte er allerdings nichts sagen. Auch das FBI kommentierte die Vorgänge nicht.
Eine der Aufgaben der Behörden wird auch sein, die Echtheit eines kürzlich auf einer Pastebin-Seite aufgetauchten Bekennerschreibens zu überprüfen. Darin hatte einer unter den Nicknames "ComodoHacker" und "ichsunx" agierende Person mutmaßlich iranischer Herkunft die Verantwortung für den Angriff übernommen. Es ist wahrscheinlich, dass es sich hierbei tatsächlich um den Angreifer - oder womöglich ein Mitglied der verantwortlichen Gruppe - handelt, da als Beweis der originale "Secret Key" des Mozilla-Zertifikats veröffentlicht wurde.
Derweil dürften sich Sicherheitsexperten die Köpfe zerbrechen, wie derartige Vorfälle in Zukunft verhindert werden können. Zwar kam der Angriff durch Sicherheitslücken und Unachtsamkeiten sowohl bei Comodo als auch bei GlobalTrust zustande. Der Angriff zeigt jedoch auch grundsätzliche Probleme des SSL/TLS-Verfahrens auf, die weitaus weniger leicht zu beheben sein dürften.
Quelle : www.gulli.com
-
Die kürzlich erfolgte Kompromittierung bei der SSL-CA Comodo hatte offenbar einen größeren Umfang als bisher angenommen. Wie Comodo am heutigen Mittwoch einräumte, waren neben dem bisher bekannten Opfer GlobalTrust auch zwei weitere Reseller betroffen. In diesen Fällen wurden allerdings keine gefälschten Zertifikate ausgestellt.
Bei dem Angriff vor rund zwei Wochen waren neun verschiedene gefälschte Sicherheitszertifikate für namhafte Websites ausgestellt worden. Die Zertifikate mussten daraufhin zurückgezogen und von den Browser-Herstellern auf eine Blacklist gesetzt werden. Bislang war man davon ausgegangen, dass lediglich ein Comodo-Reseller, GlobalTrust, betroffen war. Nun bemerkte man jedoch, dass dies offenbar nicht zutrifft.
Sicherheitsexperten betonen, dass die Kompromittierung zweier weiterer Reseller die Kritik an Comodos Trust-System noch verschärfen dürfte. Die beiden bisher nicht namentlich genannten Unternehmen wurden im selben - mutmaßlich von einem iranischen Angreifer ausgehenden - Hack kompromittiert wie GlobalTrust. Das entdeckte Comodo offenbar erst heute bei IT-forensischen Untersuchungen. Die Zugriffsrechte der beiden betroffenen Reseller seien mittlerweile aufgehoben worden, teilte Comodo-CTO Robin Alden mit. Er betonte, dass es in diesen beiden Fällen nicht zu einer missbräuchlichen Vergabe von SSL-Zertifikaten gekommen sei.
Alden erklärte, Comodo implementiere derzeit bessere Schutzmaßnahmen, um derartige Vorfälle zukünftig zu verhindern. So wird derzeit eine bessere Autentifizierungs-Technologie an die Reseller verteilt. Dies wird nach Angaben Aldens voraussichtlich rund zwei Wochen dauern. Bis dahin soll Comodo alle Validierungs-Verfahren seiner Reseller selbst überprüfen, um Missbrauch zu vermeiden. Zudem plant man, Resellern künftig nicht mehr zu ermöglichen, Zertifikate direkt mit dem Root-Zertifikat zu signieren. Diese Praxis hebelt mögliche Schutzmaßnahmen gegen missbräuchliche Vergabe von Zertifikaten aus und wurde daher unter anderem von Mozilla - einem der Opfer des Angriffs auf GlobalTrust - öffentlich kritisiert.
Quelle : www.gulli.com
-
ComodoBR, brasilianischer Partner des Zertifikatsherausgebers Comodo, ist offenbar einem Angriff zum Opfer gefallen. Dabei wurden per SQL-Injection Teile der Datenbank ausgelesen, darunter Daten von Kunden und deren eingereichte Zertifikatsanträge.
Die Anträge enthalten zwar keine für Angreifer missbrauchbaren Informationen, dennoch handelt es sich um ein schwerwiegendes Sicherheitsproblem, denn die Datensätze enthielten auch Zugangsdaten von Mitarbeitern von ComodoBR. Ob sich ein Unbefugter damit eigene Zertifikate hätte ausstellen können, ist allerdings unklar. Im März gelang es einem Hacker, sich durch eine Schwachstelle in den Servern eines italienischen Comodo-Partners mindestens ein Zertifikat für eine bereits existierende Domain auszustellen. Die Browser-Hersteller mussten daraufhin ein Update zum Sperren der Zertifikate verteilen.
Bei dem aktuellen Angriff hat der Hacker nach eigene Angaben prüfen wollen, wie es um die Sicherheit weiterer Comodo-Partner bestellt ist. Das Python-Tool sqlmap half ihm beim Finden der SQL-Injection-Schwachstellen, wie auf auf Pastebin dokumentiert. Mit der URL
https://www.comodobr.com/comprar/compra_codesigning.php?prod=8 UNION ALL SELECT 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14 -- -
gelang es ihm nach eigenen Angaben, die Tabellen der Datenbank auszulesen.
Comodo betont, dass die eigene Sicherheit durch den Angriff nicht bedroht war. Reseller und Partner hätten keinen Zugriff auf die Datenbanken.
Quelle : www.heise.de
-
Aus Sicherheitsgründen hat die israelische Certificate Authority (CA) StartSSL sämtliche Dienste zum Ausstellen von Zertifikaten vorerst abgeschaltet. Offenbar haben Angreifer versucht, die Sicherheitssysteme zu überwinden und in die Server einzudringen.
Gegenüber heise Security erklärte der StartSSL-CEO Eddy Nigg, dass die Angreifer ähnliche Ziele verfolgt hätten, wie bei den Einbrüchen in der Server von Resellern des Mitbewerbes Comodo: Das unbefugte Ausstellen von SSL-Zertifikaten (für bereits existierende Domains). Allerdings sei es den Angreifern in diesem Fall nicht gelungen. Die Ermittlungen zu dem bereits am 15. Juni stattgefundenen Vorfall dauern noch an. Die Sicherheit bereits ausgestellter Zertifikate sei laut StartSSL jedoch nicht gefährdet.
Die zum StartCom gehörenden CA ist eine der wenigen, bei der Anwender kostenlos SSL-Zertifikate mit einen Jahr Laufzeit erhalten können. Die Wurzelzertifikate sind in allen modernen Browsern enthalten, bei der Nutzung auf eigenen Servern muss man unter Umständen noch ein Intermediate-Zertifikat ausliefern. Der Praxis-Artikel "SSL für lau - Kostenlose Zertifikate einrichten (http://www.heise.de/security/artikel/SSL-fuer-lau-880221.html)" zeigt, wie man StartSSL-Zertifikate beantragt (sofern die Seite wieder zu Verfügung steht) und auf einem Apache-Webserver einrichtet.
Quelle : www.heise.de
-
Möglicherweise hat sich die iranische Regierung ein gültiges Zertifikat für Google-Domains erschlichen, um Nutzer von Google Mail zu überwachen. Das Zertifikat wird inzwischen von Google, Microsoft und Mozilla blockiert. Am Wochenende berichtete ein nach eigener Auskunft im Iran lebender Nutzer von Google Mail, dass Google Chrome beim Aufruf der mit SSL gesicherten Site einen Zertifikatsfehler meldete. Offenbar hat eine kürzlich in Chrome eingeführte Sicherheitsfunktion auf das merkwürdige Zertifikat aufmerksam gemacht. Chrome prüft nämlich nicht nur, ob das Zertifikat gültig ist, sondern auch, ob es von der richtigen CA stammt.
Verschiedene Sicherheitsexperten wie Moxie Marlinspike bestätigten, dass das vom holländischen Unternehmen DigiNotar ausgestellte und für alle google.com-Domains (*.google.com) gültige Zertifikat offenbar missbraucht wurde. Ein Pastebin-Eintrag demonstriert die Echtheit. Der Verfasser des Eintrags fordert die "digitale Todesstrafe" für DigiNotar, da durch das unbedachte Vorgehen des Dienstleisters Menschenleben in Gefahr gebracht wurden.
Die Electronic Frontier Foundation schreibt in ihrem Blog, dass das kompromittierte Zertifikat wahrscheinlich von der iranischen Regierung verwendet wurde, um Nutzer von Google Mail zu überwachen. Ausgestellt wurde das betroffene Zertifikat am 10. Juli, also vor gut fünf Wochen. An wen das Wildcard-Zertifikat übergeben wurde, ist allerdings ebenso unbekannt wie die Tatsache, ob noch weitere Zertifikate betroffen sind. Microsoft hat vorsichtshalber das DigiNotar-Root-Zertifikat aus der Microsoft Certificate Trust List in Windows entfernt und so alle Zertifikate von DigiNotar unbrauchbar gemacht.
Verschiedene Softwarehersteller haben inzwischen reagiert: Google wird DigiNotar-Zertifikate aus seinem Browser Chrome entfernen. Ebenso wird die Mozilla Foundation per Update dafür sorgen, dass Firefox, Sea Monkey und Thunderbird den DigiNotar-Zertifikaten nicht mehr vertrauen. Wer nicht auf das Update warten will, findet auf einer Mozilla-Seite Informationen, wie das Zertifikat von Hand gelöscht werden kann. Microsoft hat das Security Advisory 2607712 veröffentlicht. In einem dazu gehörenden Blogbeitrag erklärt das Unternehmen, dass Nutzer der Windows-Versionen ab Windows Vista keine Schritte unternehmen müssen: Das betreffende Zertifikat werde automatisch blockiert.
Für Windows XP und Windows Server 2003 wird es gesonderte Sicherheitsupdates geben, da diese Systeme nicht die zentral verwaltete Microsoft Certificate Trust List verwenden. Der Vorfall ist bereits der zweite seiner Art binnen weniger Monate. Im März wurde der Dienstleister Comodo gehackt, so dass gültige SSL-Zertifikate für eine ganze Reihe hochkarätiger Domains – darunter auch Google Mail – entwendet werden konnten.
Quelle und Links : http://www.heise.de/newsticker/meldung/Neuer-SSL-Gau-Falsches-Google-Zertifikat-blieb-fuenf-Wochen-unentdeckt-1333070.html
-
Nachdem am Wochenende ein widerrechtlich ausgestelltes Zertifikat aktiv für die Überwachung iranischer Gmail-Nutzer genutzt wurde, meldet sich jetzt der Aussteller des Zertifikats zu Wort: Demnach hat der Herausgeber DigiNotar bereits am 19. Juli dieses Jahres einen Einbruch in seine Systeme festgestellt, bei dem die Angreifer mehrere Zertifikate generieren konnten. Auch das nun eingesetzte Zertifikat für *.google.com befand sich darunter.
DigiNotar hat daraufhin das Ausmaß des Einbruchs untersucht und alle widerrechtlich ausgestellten Zertifikate zurückgerufen. Wie sich nun herausstelle, wurden dabei jedoch Zertifikate übersehen, wie auch die DigiNotar zugeben muss: "Wir haben festgestellt, dass mindestens ein falsches Zertifikat nicht zurückgezogen wurde. Nachdem uns die niederländische Regierungsorganisation Govcert darauf aufmerksam gemacht hat, haben wir das unverzüglich nachgeholt.".
Die Angreifer hatten es gezielt auf die für die Ausstellung von SSL- und Extended-Validation-SSL-Zertifikaten (EVSSL) zuständige Infrastruktur abgesehen. DigiNotar will keine Zertifikate mehr ausstellen, ehe nicht weitere Sicherheitsprüfungen von externen Dienstleistern durchgeführt wurden. Warum das allerdings erst jetzt passiert, lässt das Unternehmen offen – schließlich hat der Einbruch bereits Mitte Juli stattgefunden. Eine Lösung soll bis zum Ende der Woche bereitstehen.
Der Mutterkonzern VASCO versucht seine Aktionäre mit warmen Worten zu beruhigen: "Im ersten Halbjahr lagen die Einnahmen aus dem SSL- und EVSSL-Geschäft bei unter 100.000 Euro. VASCO erwartet nicht, dass der Zwischenfall bei DigiNotar signifikanten Auswirkungen auf künftige Einnahmen oder Business-Pläne haben wird." Den im Iran lebenden Nutzern von Google Mail, die möglicherweise über einen Zeitraum von mehreren Wochen durch die iranische Regierung überwacht wurden, wird dies nur wenig trösten. Sie haben sich durch die vermeintliche sichere Verbindung zum Google-Server in falscher Sicherheit gewogen.
Man kann derzeit nicht ausschließend, dass DigiNotar weitere bei dem Einbruch ausgestellte Zertifikate bei der Sperrung übersehen hat. Deshalb haben sich die Browserhersteller zu einem radikalen Schritt entschieden: Sie wollen künftig keinen DigiNotar-Zertifikaten mehr vertrauen. Google, Mozilla und kündigten bereits Updates an, welche die CA aus der Liste der vertrauenswürdigen Herausgeber entfernen. Microsoft nutzt hierzu die zentral verwalteten Certificate Trust List, wovon Windows-Versionen ab Vista automatisch profitieren. Für Windows XP und Windows Server 2003 wird es gesonderte Sicherheitsupdates geben.
Eine von Mozilla veröffentlichte Anleitung, die beschreibt, wie man das Root-Zertifikat von Hand aus Firefox löscht, hat sich unterdessen als wirkungslos herausgestellt. Tests in der Redaktion ergaben, dass DigiNotar dadurch zwar zunächst aus der Liste der vertrauenswürdigen Herausgeber verschwindet. Wenn man das Einstellungsfenster erneut öffnet, ist jedoch wieder alles beim alten.
Quelle : www.heise.de
-
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.
(http://www.heise.de/imgs/18/7/0/5/6/0/6/d61fbf590f154f79.png)
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 (http://www.heise.de/newsticker/meldung/CA-Hack-Noch-mehr-falsche-Zertifikate-1334098.html?view=zoom;zoom=1)
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
-
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
-
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
-
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
-
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.
(http://scr3.golem.de/screenshots/1108/diginotar/thumb620/2011-09-07%2009.53.19%20am.png)
Microsoft weist in dem Security Advisory 2607712 (http://www.microsoft.com/technet/security/advisory/2607712.mspx) 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
-
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
-
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
-
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
-
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
-
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
-
Der Softwarekonzern Microsoft hat eine Warnung veröffentlicht (https://technet.microsoft.com/en-us/security/advisory/2588513), 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 (http://support.microsoft.com/kb/2588513) 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 (http://support.microsoft.com/kb/245030) muss. Daher empfiehlt sich dort der Einsatz der Fix-it-Tools.
Die Firefox-Entwickler diskutieren (https://bugzilla.mozilla.org/show_bug.cgi?id=665814) 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
-
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
-
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 (http://seclists.org/fulldisclosure/2011/Oct/779) 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
-
(http://www.heise.de/imgs/18/7/2/9/6/2/2/5686a51f813fec27.png)
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 (https://www.eff.org/files/colour_map_of_CAs.pdf)) in mehr als 50 Ländern.
Quelle : www.heise.de
-
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
-
Die Google-Forscher Adam Langley und Ben Laurie schlagen in ihrem Paper Certificate Authority Transparency and Auditability (http://www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf) neue Maßnahmen vor, um die Public-Key-Infrastruktur (PKI) hinter HTTPS vertrauenswürdiger zu machen. Die Idee der Forscher beruht auf öffentlich einsehbaren Listen, in denen alle jemals ausgestellten Zertifikate der Zertifizierungsstellen aufgeführt sind.
Das aktuell genutzte Konzept für sichere Webseiten hat zwei Probleme: Wenn sich ein Angreifer etwa durch einen Einbruch bei einer der weit über 100 Zertifizierungsstellen ein Zertifikat für einen Server wie eBay.com besorgt, haben Endanwender keine Chance, diesen Betrug zu bemerken. Auf der anderen Seite kann auch eine Firma wie eBay nicht feststellen, ob unter Umständen eine CA in China unberechtigter Weise ein Zertifikat für ihre Server ausgestellt hat.
Beide Probleme seien nach Meinung der Forscher mit einer öffentlichen Liste in den Griff zu bekommen. Die Browser sollen künftig beim Aufruf einer HTTPS-Seite prüfen, ob sich das vom Server ausgelieferte Zertifikat tatsächlich auf einer solchen Liste befindet. Ist das nicht der Fall, stuft der Web-Browser das Zertifikat als nicht vertrauenswürdig ein. Außerdem können Firmen die Listen aktiv überwachen, um missbräuchlich ausgestellte Zertifikate zu entdecken. Kriminelle, die an falsche Zertifikate gelangt sind, hätten dadurch keine Chance mehr, diese einzusetzen. Um die Integrität der Listen zu gewährleisten, sollen sogenannte Merkle-Signaturbäume zum Einsatz kommen.
Ob und wann die Vorschläge in die Tat umgesetzt werden, ist bislang noch völlig offen. Einen alternativen Ansatz verfolgt Sicherheitsexperte Moxie Marlinspike mit seiner Firefox-Erweiterung Convergence (http://convergence.io/).
Quelle : www.heise.de
-
Der Webserver des niederländischen Zertifikatsherausgebers Gemnet ist gehackt worden. Das berichten niederländische Medien. Der anonyme Hacker verschaffte sich Zugang zur Datenbank, indem er eine PHPMyAdmin-Installation zur Verwaltung der Datenbank nutzte. Laut Bericht soll die Datenbank nicht mit einem Passwort gesichert gewesen sein.
Der virtuelle Einbrecher informierte darauf eine bekannte IT-Nachrichten-Website über das Datenleck. Diese benachrichtige die Muttergesellschaft von Gemnet, dem niederländischen Telekommunikationsriesen KPN, der eine sofortige Untersuchung veranlasste. Ähnlich wie DigiNotar stellt Gemnet Zertifikate für die niederländische PKI aus.
Durch die Sicherheitslücke und ein schwaches Administrator-Kennwort soll es dem Hacker gelungen sein, die Kontrolle über den Webserver zu erlangen. Auf diesem fand der Eindringling sicherheitsrelevante Informationen vor, darunter technische Details zum VPN, das KPN mit diversen niederländischen Unternehmen sowie öffentlichen Einrichtungen und Behörden wie der Polizei, dem Finanzamt und dem Ministerium für Sicherheit und Justiz verbindet.
Aus den gefundenen Dokumenten geht weiter hervor, dass der Zugang zum VPN aus den Behörden nicht in allen Fällen verschlüsselt stattfand. Auch sollen unsichere Tools wie telnet als Administratorzugang zur Firewall eingesetzt worden sein. In einer offiziellen Mitteilung zum Vorfall betont KPN, dass der Hack nur den Webserver und nicht die PKI-Server betreffe. Es soll deshalb nicht möglich gewesen sein, unberechtigt Zertifikate auszustellen. Die Gemnet-Website hat KPN während die Untersuchung nach dem Umfang der Sicherheitslücke läuft vom Netz getrennt.
Quelle : www.heise.de
-
Der SSL-GAU rund um den niederländischen Zertifikatsanbieter Diginotar hatte das Potenzial zu einer "internationalen Krise", gegen die die fortlaufenden Sicherheitsangriffe auf Sony "wie Peanuts" zu bewerten wären, erklärte Stefan Ritter vom Bundesamt für Sicherheit in der Informationstechnik (BSI) auf dem CAST-Forum zu Public Key-Infrastrukturen. Ein Vertreter der Zertifikatsherausgeber präsentierte unterdessen neue Maßnahmen, die die Gefahr eindämmen sollen.
"Die eigentlich für uns völlig uninteressante Firma" war als Zertifikatsanbieter Dienstleister für Notare und die niederländische Regierung und operierte als Zwischen-CA für die staatliche PKI-Overheid (Obrigkeit), die unter anderem die Zertifikate für die elektronische Identifikation aller Bürger der Niederlanden ausgibt. Eine unglaubliche Fülle von Schwachstellen bei Diginotar führte dazu, dass über den Zertifikatsprovider über 500 falsche SSL-Zertifikate in Umlauf kamen.
Der Leiter des Computernotfallteams des Bundes (CERT-Bund) bewertete diesen Vorgang als extrem gefährlich, weil die Niederlande über eine sofortige Schließung von Diginotar praktisch den elektronischen Kontakt zur Bevölkerung verloren hätte. Außerdem franste der Fall aus, als die Diginotar-Kunden zu KPN Getronic wechselten, das ebenfalls Sicherheitsprobleme hatte und seine Zertifikatsangebote für zwei Wochen vom Netz nehmen musste. Eine internationale Dimension erreichte der Fall auch dadurch, dass sich ein Hacker zu den Sicherheitseinbrüchen bei Diginotar bekannte, der behauptete, weitere Zertifikatsanbieter kompromittiert zu haben.
Angesichts des Ausmaßes, in dem zertifikatsbasierte Verfahren eingesetzt werden (SSL/TLS, Code-Signing, Authentifikation, gesicherte E-Mail usw.) zwinge der Fall zum Umdenken bei PKI-Systemen, erklärte Ritter. Zwar sei das Code-Signing von Malware bisher eher selten, dennoch habe das BSI bereits neun Zertifikate gefunden, die von Malware benutzt wurden.
Axel Treßel vom CAB-Forum, dem Zusammenschluss der Zertifikatsanbieterstellte, präsentierte die als Reaktion auf den Vorfall zusammengestellte Liste von Minimalanforderungen, die die CAs bis zum 1.07.2012 erfüllen müssen. Insbesondere dürfen Zertifikate dann maximal 5 Jahre, ab dem 1.4.2015 nur noch 39 Monate gültig sein. Außerdem muss vor Ausgabe eines Zertifikates mit unabhängigen Quellen überprüft werden, ob der Antragsteller, also die Person oder Organisation existiert. Ferner verpflichten sich die Provider zu einem jährlichen Risk-Assessment und stichprobenhaft vierteljährlich die Zertifikate zu prüfen. Auch die Anforderungen an einen 24*7 zur Verfügung stehenden Sperrdienst wurden erhöht.
In der zweiten Jahreshälte 2012 will die europäische Union die sogenannte eSignatur Directive veröffentlichen, mit der sichere, grenzüberschreitende elektronische Identifikations- und Authentifizierungsprozesse standardisiert werden. Im Zentrum der Directive steht die übergreifende Zusammenarbeit der Zertifikatsdienste-Provider auf europäischer wie auf internationaler Ebene.
Quelle : www.heise.de
-
Die Sicherheitsforscher Juliano Rizzo und Thai Duong greifen ein Jahr nach BEAST erneut SSL/TLS-verschlüsselte Verbindungen an, wie ThreatPost berichtet. In rund zwei Wochen wollen sie auf der ekoparty mit CRIME erneut einen Angriff vorstellen, durch den man Cookies aus fremden HTTPS-Verbindungen klauen kann.
Der ganze Artikel (http://www.heise.de/security/meldung/Entwickler-des-BEAST-Angriffs-auf-SSL-legen-nach-1702069.html)
Quelle : www.heise.de
-
Viele Programme, die Verschlüsselung nutzen, sind unsicher: Forscher der Universität von Texas und Austin und der Standford Universität fanden in vielen E-Commerce Web-Applikationen, bekannten Messaging-Diensten wie Trillian oder AIM und reihenweise in Cloud-Diensten unwirksame Verschlüsselung vor. Sie machen dafür vor allem die verwendeten Bibliotheken verantwortlich.
Secure Socket Layer – kurz SSL – ist der Defacto-Standard für sichere, verschlüsselte Internet-Verbindungen. Für dessen Sicherheit ist es jedoch von entscheidender Bedeutung, dass ein Programm die Identität der Gegenstelle, konkret also deren Zertifikat, überprüft. Und genau hier sehen die Forscher das Problem: "Die Überprüfung von Zertifikaten ist in vielen wichtigen Programmen und Bibliotheken komplett kaputt", lautet das Fazit ihrer Untersuchung The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software.
Der ganze Artikel (http://www.heise.de/newsticker/meldung/SSL-Zertifikate-und-der-gefaehrlichste-Code-der-Welt-1736699.html)
Quelle : www.heise.de
-
Der türkische Zertifikatsherausgeber Türktrust hat einen fatalen Fehler begangen: Er hat zwei SSL-Zertifikate ausgestellt, die sich wiederum selbst zum Ausstellen von Zertifikaten für beliebige Domains eignen. Mit einem der sogenannten SubCA-Zertifikate wurde ein SSL-Zertifikat für *.google.com ausgestellt, welches auch zum Einsatz kam. Laut Türktrust handelt es sich bei dem Vorfall um eine Verkettung unglücklicher Umstände, Hinweise auf einen Missbrauch gebe es nicht.
Google hat am Heiligabend festgestellt, dass Chrome-Nutzern bei der Nutzung von Google-Diensten ein Zertifikat präsentiert wurde, das gar nicht im Auftrag des Unternehmens ausgestellt wurde. Bei der Analyse des Zertifikats stelle sich heraus, dass es von einem SubCA-Zertifikat der Zertifizierungsstelle Türktrust ausgestellt wurde, woraufhin sich Google kurz drauf mit der türkischen Firma in Verbindung setzte.
Der ganze Artikel (http://www.heise.de/security/meldung/Fatale-Panne-bei-Zertifikatsherausgeber-Tuerktrust-1776879.html)
Quelle : www.heise.de
-
SSL/TLS ist die Basis für sichere Internet-Verbindungen; für die Verschlüsselung kommt dabei sehr häufig das bereits 1987 von Ron Rivest erfundene RC4 zum Einsatz. Gegen diesen Algorithmus haben Forscher jetzt einen Angriff vorgestellt, der zumindest den Anfang einer gesicherten Übertragung entschlüsseln kann. Der Angriff ist zwar noch eher theoretischer Natur, zeigt aber deutlich, dass Handlungsbedarf besteht.
Der ganze Artikel (http://www.heise.de/security/meldung/Erneuter-Krypto-Angriff-auf-SSL-TLS-Verschluesselung-1822963.html)
Quelle : www.heise.de
-
Der Internet-Gigant will seine Zertifikats-Infrastruktur überholen und warnt vorsichtshalber schon mal vor möglichen Problemen. Ab August tauscht Google seine SSL-Zertifikate aus, um neue, längere Schlüssel einzusetzen. Betroffen ist auch das Google-Root-Zertifikat, mit dem Google all seine eigenen Zertifikate unterschreibt.
Der ganze Artikel (http://www.heise.de/newsticker/meldung/Google-erneuert-SSL-Zertifikate-1869150.html)
Quelle : www.heise.de
-
Die von Mozilla entwickelte Verschlüsselungsbibliothek NSS unterstützt in der aktuellen Version den aktuellen TLS-Standard 1.2. Das könnte die in Firefox und Chrome verwendete SSL-Verschlüsselung verbessern. Die Unterstützung für AES im authentifizierten Modus GCM fehlt allerdings noch.
Obwohl der Verschlüsselungsstandard TLS 1.2 bereits fünf Jahre alt ist, hält er erst langsam Einzug in die Browserwelt. Mit der jüngsten Version 3.15.1 erhält nun auch die von Mozilla entwickelte NSS-Bibliothek, die unter anderem von Firefox und Chrome verwendet wird, Unterstützung für die aktuelle SSL-/TLS-Version. Noch nicht unterstützt wird von NSS allerdings die authentifizierte Verschlüsselung im sogenannten Galois-/Counter-Mode von AES.
Der ganze Artikel (http://www.golem.de/news/tls-1-2-bald-bessere-verschluesselung-fuer-firefox-und-chrome-1307-100370.html)
Quelle : www.golem.de
-
Auf die Verschlüsselung von Windows kann man sich nicht wirklich verlassen, denn über eine weitgehend unbekannte Funktion kann Microsoft dem Betriebssystem jederzeit neue Stammzertifikate unterschieben. Mit solchen Stammzertifikaten lassen sich dann beliebige andere Zertifikate beglaubigen.
Der ganze Artikel (http://www.heise.de/security/meldung/Windows-Dynamische-Zertifikat-Updates-gefaehrden-SSL-Verschluesselung-1925115.html)
Quelle : www.heise.de
-
Wenn man den Inhalt einer SSL-Verbindung analysieren will, muss man die verschlüsselten Daten dekodieren. Firefox und Chrome können die verwendeten Schlüssel so protokollieren, dass Wireshark das on-the-fly erledigt.
Wenn man SSL nicht als Man-in-the-Middle über einen Proxy wie Burp aufmachen will, braucht man das Schlüsselmaterial, um an die verschlüsselten Nutzdaten zu gelangen. Das geht leichter als man denkt. Zeigt die dokumentierte Umgebungsvariable SSLKEYLOGFILE auf eine beschreibbare Datei, protokollieren Firefox und Chrome diese Daten. Da die keinesfalls in die falschen Hände geraten sollten, legt man dazu unter Linux vorsichtshalber gleich ein geschütztes Verzeichnis an:
Der ganze Artikel (http://www.heise.de/security/artikel/Browser-SSL-entschluesselt-1948431.html)
Quelle : www.heise.de
-
628 der meistbesuchten Websites waren für den folgenschweren SSL-Bug anfällig – und sind es zum Teil sogar noch immer. Tests belegten, dass die Lücke auch Zugriff auf vertrauliche Daten wie Klartext-Passwörter erlaubt.
Nach und nach wird klar, welcher Schaden bereits durch die fatale Sicherheitslücke in dem Krypto-Framework OpenSSL entstanden ist oder noch entstehen wird. Bei einer Überprüfung der laut Alexa 10.000 meistbesuchten Websites erlaubten 628 Server intime Einblicke in ihren Arbeitsspeicher. Darunter befinden sich allerhand prominente Namen wie etwa die HypoVereinsbank, Yahoo, Flickr, Kaspersky, der Zahlungsabwickler AfterBuy, Yahoo, Sparkasse.at, BitTorrent sowie viele mehr. Am gestrigen Dienstag berichteten wir bereits über die Anfälligkeit von Adobe, Web.de, VeriSign und weiteren. Die Liste lässt sich beliebig fortsetzen.
Der ganze Artikel (http://www.heise.de/security/meldung/Passwort-Zugriff-Heartbleed-Luecke-mit-katastrophalen-Folgen-2166861.html)
Quelle : www.heise.de
-
Der Heartbleed-Exploit macht sich eine Schwachstelle in der Umsetzung der Heartbeat-Erweiterung des TLS-Protokolls in OpenSSL zunutze. Er funktioniert erstaunlich einfach und absolut zuverlässig.
Der sogenannte Heartbeat soll es eigentlich Server und Client ermöglichen, eine TLS-Verbindung am Leben zu halten. Zu diesem Zweck sendet einer der Kommunikationspartner eine Payload mit beliebigem Inhalt an das andere Ende. Der Kommunikationspartner schickt dann exakt die selben Daten zurück, um zu zeigen, dass die Verbindung nach wie vor in Ordnung ist.
Das Problem bei der Umsetzung der TLS-Heartbeat-Funktion in OpenSSL war, dass das Programm nicht überprüft, wie lang die empfangene Payload tatsächlich ist – der Empfänger glaubt dem Absender einfach. Der kann in das dafür vorgesehene Feld payload_length im Header des Payload-Paketes beliebige Werte schreiben, bis hin zur maximal in der Spezifikation vorgesehenen Größe von 64 KByte. Lügt der Absender bei der Größe der Payload, kann er letztlich Speicher der Gegenstelle auslesen. Dieser Heartbleed-Angriff funktioniert in beide Richtungen, aber im Folgenden sei angenommen, dass ein böser Client einen verwundbaren Server angreift.
Der ganze Artikel (http://www.heise.de/security/artikel/So-funktioniert-der-Heartbleed-Exploit-2168010.html)
Quelle : www.heise.de
-
Kleines Erklärvideo hierzu von Sempervideo :) :
-
Das eigentlich längst veraltete SSLv3 ist die Achillesferse der Verschlüsselung im Internet: Damit gesicherte Verbindungen lassen sich dechiffrieren. Und der Angreifer kann erzwingen, dass das schwache Protokoll zum Einsatz kommt. Zeit zu handeln.
Forscher von Google haben vorige Nacht einen neuen Angriff namens Poodle vorgestellt, mit dem sich im Prinzip nahezu alle verschlüsselten Verbindungen im Internet knacken lassen. Die Wurzel des Übels ist das eigentlich längst veraltete Protokoll SSLv3. Es ist über 15 Jahre alt, wird jedoch als Fallback immer noch von nahezu allen Servern und Browsern unterstützt.
Der ganze Artikel (http://www.heise.de/security/meldung/Poodle-Experten-warnen-vor-Angriff-auf-Internet-Verschluesselung-2424122.html)
Quelle : www.heise.de
-
Ein Poodle-Angriff passiert in zwei Stufen: Zunächst erzwingt der Angreifer durch gezielte Manipulation des Verbindungsaufbaus einen Verbindung nach dem Protokollstandard SSLv3. Dann nutzt er dessen Schwächen aus, um Teile der ausgetauschten Daten zu dechiffrieren
Der Poodle-Angriff richtet sich gegen verschlüsselte Internet-Verbindungen; der Angreifer muss sich dazu grundsätzlich in der Position eines Man in the Middle (MitM) befinden, bei dem alle Netzwerk-Pakete vorbei kommen. Das kann also die NSA mit einem entsprechenden Zugang am Internet-Knoten oder die nette junge Frau mit dem Laptop am Tisch nebenan sein, die ins gleiche WLAN eingebucht ist, wie Sie. Das Erzwingen von SSLv3 funktioniert deshalb, weil nahezu alle Server und Clients das noch als Fallback unterstützen und sich von der Gegenstelle darauf herunter handeln lassen.Verweigert eine der beiden Seiten den Einsatz von SSLv3, ist der Angriff nicht möglich.
Außerdem muss der Angreifer Script-Code auf dem Gerät des Opfers ausführen können. Den kann er als MitM etwa in eine unverschlüsselte Web-Seite einbauen, die der Anwender gerade öffnet. Er ist allerdings dann darauf angewiesen, dass der auch tatsächlich ausgeführt wird. Das dürfte bei den meisten Browsern der Fall sein; bei einem Mail-Programm oder dem Twitter-Client des Smartphones jedoch eher nicht.
Der ganze Artikel (http://www.heise.de/security/artikel/Poodle-So-funktioniert-der-Angriff-auf-die-Verschluesselung-2425250.html)
Quelle : www.heise.de
-
Hier eine schöne Erklärung um den Poodle los zu werden :
7zvQw
-
heise Security hat getestet und festgestellt, dass einige Mail-Provider bereits auf die jüngsten Angriffe auf Verschlüsselung reagiert haben – aber längst nicht alle. Schlimmer noch sieht es bei den Servern für das Online-Banking via HBCI aus.
Zunächst die gute Nachricht: Ein Kurztest von heise Security zeigte, dass mittlerweile fast alle Mail-Provider nachgebessert haben und die mehrfach angemahnte Perfect Forward Secrecy auf ihre Webmail- und IMAP-Servern anbieten. Also alle getesteten außer Apple und Arcor. Weniger gut sieht die Situation bei dem gerade durch den Poodle-Angriff in Verruf geratenen SSLv3-Standard aus.
Der ganze Artikel (http://www.heise.de/security/meldung/SSL-Verschluesselung-Noch-viel-Arbeit-fuer-Mail-Provider-und-Banken-2429414.html)
Quelle : www.heise.de
-
Wer die Kaspersky-Funktion "Sichere Verbindungen untersuchen" aktiviert, macht sein System potenziell für den Poodle-Angriff auf SSLv3 anfällig.
Die Schutz-Software Kaspersky Internet Security sorgt dafür, dass der Rechner unter Umständen für den Poodle-Angriff auf SSL-verschlüsselte Verbindungen anfällig ist – und zwar auch dann, wenn man das betroffene SSLv3-Protokoll explizit im Browser deaktiviert hat. Dies hat unser Leser Claus Berghammer gemeldet, heise Security konnte das Problem nachvollziehen.
Der ganze Artikel (http://www.heise.de/security/meldung/Kaspersky-Schutzsoftware-senkt-Sicherheit-von-SSL-Verbindungen-2482344.html)
Quelle : www.heise.de
-
Eine Google-Mitarbeiterin hat den In-Flight-Internetdienst Gogo dabei erwischt, wie er ihr ein gefälschtes SSL-Zertifikat untergeschoben hat. Gogo behauptet, die Maßnahme werde angewendet, um Video-Streaming über den Wolken unter Kontrolle zu halten.
(http://2.f.ix.de/scale/geometry/600/q75/imgs/18/1/4/1/1/9/9/9/gogo-ssl-spoof-0d17aabd6eaf4d9d.png)
Eine Google-Sicherheitsforscherin hat auf einem Flug entdeckt, dass der In-Flight-Internetdienst Gogo gefälschte SSL-Zertifikate für bestimmte Webseiten verteilt. Beim Aufrufen von YouTube bekam sie ein Zertifikat ausgehändigt, das nicht von Googles CA sondern von Gogo ausgestellt wurde. Gogo wird von vielen US-Airlines verwendet, um Internet auf Langstreckenflügen zur Verfügung zu stellen.
Mit einem Man-in-the-Middle-Angriff wie ihn die Google-Forscherin beobachtete, kann der Anbieter den eigentlich als sicher geltenden HTTPS-Datenverkehr mitschreiben. Gogo-Technikchef Anand Chari sagte gegenüber US-Magazin Fast Company, man wende die Technik an, um Video-Streaming zu drosseln oder zu blocken – Nutzerdaten würden nicht gespeichert. Allerdings brüstete sich der Gogo-Ableger Aircell bereits 2009 damit, dass der Dienst mehr Informationen an Strafverfolgungsbehörden weitergeben kann, als vom Gesetz verlangt wird.
SSL bereitet logistische Probleme
SSL/TLS-Traffic stellt viele Anbieter von Internetdiensten in Flugzeugen vor Probleme, da sich diese Art von Daten nur schwer untersuchen lassen und schlecht zwischenzuspeichern ist. Auf Grund der begrenzten Bandbreite bei In-Flight-Internet cachen die Dienste in der Regel so viele Inhalte wie möglich. Ein Video, dass einmal im Zwischenspeicher an Bord liegt, muss nicht mehrmals über die schmale Bandbreite der Satelliten-Antenne geschoben werden.
Andere Anbieter von In-Flight-Internet blocken HTTPS-Verbindungen von Grund auf. Eine solche Lösung ist für Nutzer sicherlich störender, da bestimmte Seiten, die ausschließlich SSL-Verbindungen akzeptieren, dann nicht mehr funktionieren.
Quelle : www.heise.de
-
Online-Betrüger missbrauchen SSL-Zertifizierungsstellen, um sich Zertifikate für Phishing-Seiten ausstellen zu lassen, warnen Sicherheitsforscher. Schuld daran seien laxe Richtlinien der Zertifizierer.
In einem Beobachtungszeitraum von einem Monat haben sich Online-Betrüger hunderte Zertifikate für Phishing-Seiten von SSL-Zertifikatsstellen wie etwa Comodo und Symantec ausstellen lassen. Phishing-Seiten wie zum Beispiel banskfamerica.com oder itunes-security.net sollen mit den Zertifikaten vertrauenswürdiger wirken. Davor warnen die Sicherheitsforscher von Netcraft.
Schuld daran seien laxe Richtlinien der SSL-Zertifikatsstellen. In vielen Fällen müssen Betrüger nur nachweisen, dass sie die Kontrolle über eine Domain haben. Postwendend erhalten sie innerhalb weniger Minuten ein Zertifikat, erläutern die Sicherheitsforscher.
Auch die kostenlosen 90-Tage-Test-Zertifikate von Comodo seien bei Betrügern beliebt. Strenger bei der Ausstellung von SSL-Zertifikaten sind Netcraft zufolge Digicert und Entrust, da diese umfangreichere Richtlinien an den Tag legen.
Cloudflare beliebt bei Online-Betrügern
Mit 41 Prozent stellte Cloudflare die meisten SSL-Zertifikate für Phishing-Seiten im August 2015 aus, berichten die Sicherheitsforscher. Dabei setzt der Internet-Dienstleister auf eine Partnerschaft mit Comdo und Globalsign.
Cloudflare erlaubt für alle von sich gehosteten Server gratis den verschlüsselten Zugriff per SSL/TLS. Bereits Anfang dieses Jahres sorgte der Internet-Dienstleister durch das Ausstellen von Zertifikaten für Paypal-Phishing-Seiten für negative Schlagzeilen.
Quelle : www.heise.de
-
Eine Sicherheitsfirma schätzt, dass für 9 Prozent aller SSL-Endpunkte im Netz die privaten Schlüssel bekannt sind. Damit könnten Angreifer sich als diese Server ausgeben und Router, Modems und VoIP-Telefone im selben Netz ausspionieren.
Viele Endbenutzer-Geräte wie Router und NAS-Systeme recyclen Schlüssel und Zertifikate für SSH- und SSL-Verbindungen und liefern die privaten Schlüssel gleich mit. Forscher der Sicherheitsfirma SEC Consult haben nun die öffentlich zugängliche Firmware von mehr als 4000 Geräten untersucht und dabei 580 solcher privater Schlüssel ausheben können. Da diese öffentlich zugänglich sind, kann sich nun ein Angreifer im selben Netz mit den betroffenen Geräten verbinden und als legitimer Gesprächspartner ausgeben.
So gut wie alle namhaften Hersteller betroffen
Betroffen sind Kabel- und DSL-Router, Modems, Internet Gateways, VoIP-Telefone und mit dem Internet verbundene Kameras. Von den 580 von den Forschern gefundenen Schlüsseln werden mindestens 230 momentan aktiv genutzt. SEC Consult schätzt, dass 9 Prozent aller SSL-Endpunkte im Netz betroffene Zertifikate einsetzen – insgesamt 3,2 Millionen Systeme. Außerdem sollen 6 Prozent aller öffentlich auffindbaren SSH-Hosts betroffen sein.
SEC Consult fand über 900 betroffene Produkte von 50 Herstellern, die auf diese Art geschlampt haben. Die Liste liest sich wie ein Who's Who der namhaften Hersteller von Routern: Alcatel-Lucent, Cisco, D-Link, DrayTek, Huawei, Linksys, Netgear, TP-Link, Trendnet, Tenda und Zyxel. Die Deutsche Telekom, General Electric, Motorola und Vodafone sind auch betroffen. Aber auch die Festplatten-Hersteller Seagate und Western Digital sind auf der Liste – deren NAS-Geräte bohren sich gerne per UPNP Weiterleitungen durch die Router-Firewall und exponieren so die Sicherheitslücke im öffentlichen Netz.
Daniel von Broadcom und sein Zertifikat
Einige der privaten Schlüssel finden sich auf Geräten verschiedener Hersteller wieder. Wahrscheinlich stammen diese von OEMs, die ihre Hardware an andere Firmen weiterverkaufen. In einem Fall fanden die Forscher ein Zertifikat aus einem Broadcom-SDK, das auf einen gewissen Daniel ausgestellt ist und sich auf fast einer halben Million Geräte im öffentlichen Netz wiederfinden lässt.
Auch mehrere Internet-Dienstanbieter wie CenturyLink in den USA, China Telecom, Telstra und Telefónica beziehungsweise Moviestar in Spanien scheinen in ihrer Router-Firmware Mist gebaut zu haben. Viele von ihnen setzen durch die unachtsame Verwendung von privaten Schlüsseln hunderttausende ihrer Kunden einem Sicherheitsrisiko aus.
Fixes lassen auf sich warten
Die SEC-Forscher haben bereits im August das CERT/CC der Carnegie Mellon über das Problem informiert. Das CERT hat viele der betroffenen Hersteller informiert und einige haben damit begonnen, die Lücken zu stopfen. Mehr Informationen zum Umgang der einzelnen Hersteller mit dem Problem und eventuell zur Verfügung stehenden Updates finden sich im Advisory des CERT/CC.
Nutzer von Geräten der betroffenen Hersteller sollten Updates, soweit möglich, zügig einspielen. Bei manchen Geräten können Zertifikate und Schlüssel vom Nutzer in Eigenregie geändert werden, was allerdings nicht trivial ist und im schlimmsten Fall dazu führen kann, dass die Geräte nicht mehr korrekt funktionieren. Nutzer, die diesen Lösungsansatz erwägen, sollten sich mit dem Hersteller ihres Gerätes in Verbindung setzen – oft ist dies aber einfacher gesagt als getan.
Quelle : www.heise.de
-
Die SSL/TLS-Zertifizierungsstelle Let's Encrypt öffnet ihre Pforten und ab sofort kann jeder kostenlose Zertifikate beantragen, die von gängigen Webbrowsern als vertrauenswürdig eingestuft werden.
Ab sofort ist keine Einladung mehr nötig, um Zertifikate bei der Zertifizierungsstelle (CA) Let's Encrypt zu beantragen, denn die öffentliche Beta ist eröffnet. Das Ganze ist kostenlos und funktioniert so einfach wie nie.
Facebook als neuer Sponsor
Während der geschlossenen Betaphase wurden der CA zufolge über 26.000 Zertifikate ausgestellt. Die Sponsoren von Let's Encrpyt sind unter anderem Akamai, Cisco und Mozilla. Diese haben sich zur Internet Security Research Group (ISRG) zusammengefunden, um HTTPS zum Standard im Internet zu machen. Neuerdings ist auch Facebook mit an Bord.
Der ganze Artikel (http://www.heise.de/newsticker/meldung/Let-s-Encrypt-startet-oeffentliche-Beta-Kostenlose-SSL-TLS-Zertifikate-fuer-jedermann-3031699.html)
Quelle : www.heise.de
-
Im Rahmen eines Sicherheits-Updates verkündet das OpenSSL-Team, dass die Versionen 0.9.8 und 1.0.0 keine weiteren Updates mehr erhalten werden. Deren Nutzer sollten dringend auf neuere Versionen umsteigen.
Das OpenSSL-Team stellt neue Versionen der Krypto-Bibliothek bereit. Die aktualisierten Pakete OpenSSL 0.9.8zh, 1.0.0.0t, 1.0.0.1q und 1.0.2e beheben insgesamt 5 Sicherheitslücken, von denen drei als "Moderate" und zwei als "Low" eingestuft sind.
Wenig Informationen
Die konkreten Angaben zu den einzelnen Schwachstellen sind spärlich und sehr schlecht aufbereitet. So erläutert das OpenSSL Sicherheits-Advisory zwar lang und breit, dass Angriffe auf die Schwachstelle CVE-2015-3193 (Moderate) sehr schwierig und unwahrscheinlich seien. Eine Angabe dazu, was denn die Auswirkung erfolgreicher Angriff wären, fehlt jedoch. Dabei ist dies eine der wichtigen Standardangaben zur Bewertung des Risikos einer Lücke.
Bei CVE-2015-3195 heißt es lediglich "OpenSSL will leak memory"; ob das zu exzessiv erhöhtem Speicherverbrauch oder wie bei Heartbleed zur Preisgabe von Informationen an einen Angreifer führt, wird nicht erklärt. Letztlich bedeutet das für Admins wohl, dass sie die Updates auf Verdacht installieren müssen.
Alte Zöpfe
Im Security Advisory erklären die Entwickler auch in fetten Lettern, dass es voraussichtlich keine weiteren Updates für die Versionen 0.9.8 und 1.0.0 mehr geben wird. Deren Nutzer sollten also jetzt unbedingt mindestens auf Version 1.0.1 oder besser gleich auf das aktuelle 1.0.2 umsteigen. Die jetzt abgekündigten Versionen sind auch immerhin zehn beziehungsweise fünf Jahre alt. Die im März 2012 vorgestellte Version 1.0.1 war ein Meilenstein, weil sie die Unterstützung von TLS 1.2 brachte.
Quelle : www.heise.de
-
Die Tätigkeit von Let's Encrypt als Zertifizierungsstelle wurde noch nicht der vorgeschriebenen Sicherheitsprüfung unterzogen. Trotzdem stellt die CA schon Zertifikate aus.
Let's Encrypt verteilt schon fleißig Zertifikate, denen die Webbrowser vertrauen. Doch jetzt gibt es Beschwerden, dass die Zertifizierungsstelle (CA) IdenTrust das Intermediate-CA-Zertifikat von Let's Encrypt gar nicht signieren durfte. Aktuell setzt Let's Encrypt auf einen Cross-Zertifizierung von IdenTrust. Denn Betriebssysteme und Webbrowser vertrauen dieser CA.
Alle Root-CAs sind im CA/Browser-Forum organisiert. Die CAs müssen sich dabei an die Spielregeln des Forums halten und etwa vorgeschriebene Sicherheitsprüfungen durchlaufen. Bisher hat Let's Encrypt keine vollständige Prüfung (Audit) absolviert. Darum wurde die Aufnahme in das CA/Browser-Forum vorerst zurückgestellt.
Für die Übergangszeit behelfen sie sich mit einem Intermediate-CA-Zertifikat, dass IdenTrust ihnen ausgestellt hat. Genau das hätten die aber aufgrund des fehlenden vollständigen Audits gar nicht tun dürfen, so die Logik der Beschwerdeführer des Anbieters für Sicherheitslösungen PSW Group. Heise Security hat bei den beteiligten Parteien nachgehakt.
Der ganze Artikel (http://www.heise.de/newsticker/meldung/Audit-und-Web-Client-Kritik-an-SSL-TLS-Zertifizierungsstelle-Let-s-Encrypt-3031849.html)
Quelle : www.heise.de
-
Let's Encrypt geriet in die Kritik, da die vorgeschriebene Sicherheitsprüfung noch nicht vorlag, die CA aber schon Zertifikate ausstellte. Nun ist sind die Audit-Berichte plötzlich online einsehbar.
Die Zertifizierungsstelle Let's Encrypt hat die Prüfungsberichte (Audit) veröffentlicht, die das Unternehmen BrightLine ausgestellt hat. Somit erfüllt die Zertifizierungsstelle nun die Spielregeln des CA/Browser-Forums, in dem alle Root-CAs organisiert sind, und darf offiziell Zertifikate ausstellen.
Let's Encrypt war in die Kritik geraten, weil die vorgeschriebene Sicherheitsprüfung bis vor kurzem noch nicht vorlag, die CA aber schon fleißig Zertifikate verteilte. Das sorgte für Misstrauen, da die Grundlage des CA-Systems auf Audits und Regeln fußt, die die CAs fristgerecht einhalten müssen.
Audit seit September abgeschlossen
Seltsam mutet an, dass Let's Encrypt die Berichte erst jetzt veröffentlicht, denn die Prüfungsberichte sind vom 9. September 2015. Zudem war das vollständige Audit ursprünglich für den November angekündigt. Weder BrightLine noch Let's Encrypt hatten auf eine Anfrage von heise online bezüglich des Audits, die anscheinend seit September dieses Jahres vorliegenden Prüfungsberichte erwähnt.
Quelle : www.heise.de
-
Ab Anfang nächsten Jahres wird Google Chrome keine neu ausgestellten SHA-1-signierten SSL-Zertifikate von öffentlichen CAs mehr akzeptieren. SHA-1 gilt seit zehn Jahren als unsicher, wird aber immer noch von HTTPS-Sites verwendet.
(http://1.f.ix.de/scale/geometry/695/q75/imgs/18/1/7/1/6/5/7/6/Screen_Shot_2015-12-04_at_16-2da1bc77661b252f.png)
Seit zehn Jahren gilt das Hash-Verfahren SHA-1 als unsicher, trotzdem ist es immer noch bei vielen HTTPS-Sites im Einsatz. Die drei großen Browser-Hersteller Google, Microsoft und Mozilla haben allerdings schon vor einiger Zeit angekündigt, demnächst keine SHA-1-signierten SSL-Zertifikate mehr zu akzeptieren.
Google hat jetzt seinen konkreten Zeitplan für das Ende der SHA-1-Unterstützung veröffentlicht. Ab Anfang 2016 wird Google Chrome neue SSL-Zertfikate mit SHA-1-Signatur, die von einer öffentlichen CA ausgestellt wurden, nicht mehr akzeptieren und einen Zertifikatsfehler anzeigen. Spätestens ab dem 1.1.2017 wird Chrome dann gar keine SHA-1-signierten Zertifikate mehr akzeptieren.
Auch Mozilla verabschiedet sich langsam von SHA-1: Firefox soll ab Anfang nächsten Jahres ebenfalls vor SHA-1-signierten Zertifikaten warnen. Ebenso will sich Microsoft nächstes Jahr von SHA-1 trennen. Das CA/Browser Forum, in dem über die Zertifizierungsstandards der Zertifikats-Aussteller und Browser entschieden wird, will ab dem 1. Januar 2016 das Ausstellen neuer SHA-1-Zertifikate nur noch in Sonderfällen erlauben.
Facebook und das Content Delivery Network Cloudflare weisen allerdings darauf hin, dass in Entwicklungsländern noch viele Geräte verbreitet sind, die die Nachfolge-Algorithmen für SHA-1 nicht beherrschen. Facebook eine Funktion entwickelt, die dynamisch SHA-1-Zertifikate ausliefert, wenn der Client diese benötigt: Der Server entscheidet anhand der Informationen des Clients beim TLS-Handshake, ob er ein SHA-1- oder ein SHA-2-Zertifikat ausliefert. Facebook und Cloudflare haben diesen Code bereits im Einsatz.
Quelle : www.heise.de
-
HTTPS-Webseiten wecken Vertrauen. Doch auch Online-Gauner können sich oft über Umwege vertrauenswürdige Zertifikate ausstellen. Nun haben Kriminelle das erste Let's-Encrypt-Zertifikat genutzt, um Vertrauenswürdigkeit vorzugaukeln.
Online-Gauner waren in der Lage, sich eine Subdomain für eine legitime Domain einzurichten und dafür erfolgreich ein Let's-Encrypt-Zertifikat zu beantragen, warnt Trend Micro. Die Subdomain soll auf einen Server verweisen, der unter Kontrolle der Kriminellen steht und Werbung mit Schadcode verteilt. Trend Micro will den Namen der betroffenen Domain erst veröffentlichen, wenn die Verantwortlichen das Problem im Griff haben.
Das Online-Gauner SSL-Zertifikate einsetzen, ist nichts neues. Hierbei handelt es sich jedoch um den ersten bekannt gewordenen Fall, in dem Kriminelle ein kostenloses Zertifikat von Let's Encrypt einsetzen.
Das Anlegen einer Subdomain ist nicht ohne weiteres möglich. Denkbar wäre, dass die Online-Gauner auf irgendeinem Weg an die Zugangsdaten für die Domain-Verwaltung gekommen sind. Wie das passiert ist, erläutert Trend Mirco nicht.
Opfer in Sicherheit wägen
Mit der legitimen Domain und dem Zertifikat im Rücken wollen die Kriminellen ihre bösartige Webseite, die ein Exploit-Kit beinhaltet und einen Online-Banking-Trojaner verteilt, vertrauenswürdig erscheinen lassen.
Der Schadcode soll sich in einer Werbeanzeige verstecken, die an Webseiten verteilt wird. Aus Gründen der Glaubwürdigkeit soll die Anzeige einen Bezug zur legitimen Domain aufweisen.
In einem Zeitraum von elf Tagen Ende vergangenen Dezember hat Trend Micro zufolge einen Spitzenwert von rund 500.000 Zugriffen verzeichnet. Ziele seien dabei in erster Linie japanische Nutzer gewesen.
CA als Filter für gefährliche Inhalte?
Beantragt ein Admin ein Zertifikat bei Let's Encrpyt, muss er beweisen, dass der Server tatsächlich über die (Sub-) Domain erreichbar ist (Domain Validation), für die das Zertifikat ausgestellt werden soll. Bei diesem Prozess wird der Inhalt der Webseite nicht überprüft.
Let's Encrypt sieht den Aufgabenbereich einer CA nicht darin, Inhalte zu filtern. Dabei verweisen sie in einem Statement auf Unternehmen wie etwa Google und Microsoft, die eine komplexe Infrastruktur zum Aufspüren von gefährlichen Webseiten betreiben.
Davon profitiert auch Let's Encrypt, denn neben der Domain-Validation-Prüfung greift die Zertifizierungsstelle noch auf Googles Safe Browsing API zu, um Webseiten zu überprüfen und im Zweifelsfall kein Zertifikat auszustellen.
Um Missbrauch weiter einzuschränken, setzt Let's Encrypt auf vergleichsweise kurzlebige Zertifikate, die drei Monate lang gültig sind. Mit dem Let's-Encrypt-Client kann ein Admin eine erneute Beantragung und Prüfung automatisieren.
Quelle : www.heise.de
-
Eine Entwicklungsversion vom Webbrowser Firefox zeigt ab sofort Warnungen an, wenn Webseiten mit einem TLS-Zertifikatt von Symantec besucht werden.
Mozilla baut sein Misstrauen gegenüber Symantec weiter aus, die aktuelle Nightly-Version 63 von Firefox stuft TLS-Zertifikate der Zertifizierungsstelle (CA) als nicht vertrauenswürdig ein. Das geht aus Einträgen auf der Mozilla-Webseite Bugzilla hervor.
Der Grund dafür ist, dass Symantec sich in der Vergangenheit nicht immer an die auf Vertrauen fußenden Spielregeln beim Ausstellen von Zertifikaten gehalten hat. Unter anderem haben sie mehrfach unberechtigterweise Zertifikate auf google.com ausgestellt.
Bahn.de betroffen
Den nun erfolgten Schritt kündigte Mozilla im eigenen Security-Blog bereits im Juli an. Ab 5. September sollen sich die Beta-Version und ab 23. Oktober die normale Version von Firefox identisch verhalten.
Wenn eine Webseite mit einem TLS-Zertifikat von Symantec besucht wird, warnt eine Meldung davor, dass Angreifer Passwörter oder Kreditkarten-Daten mitschneiden könnten. Diese Warnung taucht zum Beispiel auf, wenn man mit der Nightly-Version die Webseite der Deutschen Bahn besucht. In einem Bugzilla-Beitrag sammeln Firefox-Nutzer weitere betroffene Webseiten.
Feldzug gegen Symantec
Davon sind auch Webseiten mit Zertifikaten von beispielsweise Equifax, Geotrust, RapidSSL, Thawte und Versign betroffen, die Symantec über die Jahre aufgekauft hat. Um Seitenbesucher nicht zu verunsichern, sollten Web-Admins betroffene Zertifikate austauschen. Dafür bietet Digicert ein kostenloses Austauschprogramm an.
Symantec hat 2017 seinen Rückzug als Zertifizierungsstelle bekanntgegeben und die Sparte für 950 Millionen US-Dollar an Digicert verkauft. Neben Firefox misstraut auch Chrome TLS-Zertifikaten von Symantec. Auch Apple schenkt der CA seit Anfang August kein Vertrauen mehr.
Quelle : www.heise.de