Thema: SSL-Zertifikate / SSL/TLS-Protokoll

[Jürgen]

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 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

[SiLæncer]

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

[SiLæncer]

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

[SiLæncer]

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

[SiLæncer]

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

[SiLæncer]

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

[SiLæncer]

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

[SiLæncer]

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

[SiLæncer]

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

[SiLæncer]

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

[SiLæncer]

Der Sicherheitsspezialist Jacob Appelbaum hat auf der Hacker-Mailingliste 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.

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

[SiLæncer]

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

[SiLæncer]

Das OpenSSL-Project 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

[SiLæncer]

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

[SiLæncer]

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.