Thema: OpenSSH/OpenSSL/OpenVPN

[SiLæncer]

Der quelloffene SSH-Server und -Client von OpenSSH ist in Version 4.2 erschienen. Das neue Release fixt diverse, kürzlich veröffentlichte Sicherheitslücken und weitere Fehler und führt neue Leistungsmerkmale ein.

Zu den gestopften Sicherheitslecks gehört ein Fehler in der Behandlung von dynamisch zugewiesenen Port-Forwards. Durch diesen wurden fälschlicherweise so genannte "GatewayPorts" aktiviert, wenn keine explizite Adresse spezifiziert wurde, auf welcher der Server lauschen soll. GatewayPorts ermöglichen den Zugriff auf einen weitergeleiteten Port nicht nur vom authentifizierten SSH-Client, sondern binden den Port an das externe Interface des SSH-Servers. Damit ist der Zugriff auf diesen aber jedermann möglich.

Die Entwickler haben ebenfalls eine Lücke in der GSSAPI -- eine Programmschnittstelle zur Client-Server-Authentifizierung -- geschlossen, durch die ein nicht authentifizierter, über ein anderes Protokoll angemeldeter Benutzer unter bestimmten Umständen ein beglaubigtes GSSAPI-Zertifikat erhalten konnte. Hierzu musste allerdings die Option GSSAPIDelegateCredentials in der SSH-Konfiguration aktiviert sein.

Zu den Neuerungen in dem Paket zur gesicherten Internet-Kommunikation zählen eine neue Kompressionsmethode, die die zlib-Kompression erst nach erfolgreicher Benutzeranmeldung aktiviert. Dies soll das Ausnutzen von Sicherheitslöchern in der zlib-Bibliothek erschweren, die in der Vergangenheit mehrere kritische Lücken offenbarte. Ältere OpenSSH-Versionen bis OpenSSH 3.5 verweigern durch diese Änderung die Zusammenarbeit mit der neuen Fassung, wenn in der Konfiguration die Kompression mit der zlib erzwungen wird. Sie sollten daher auf den aktuellen Stand gebracht werden. Weiterhin haben die Entwickler erneut Code-Audits gegen Fehler bei der Behandlung von vorzeichenbehafteten Integers und solchen ohne Vorzeichen durchgeführt.

Auf der OpenSSH-Mailingliste ist ein ausführliches Changelog zu finden.

Quelle und Links : http://www.heise.de/security/news/meldung/63628

[SiLæncer]

Die OpenSSH-Entwickler haben die Version 4.3 des weit verbreiteten Pakets für verschlüsselte Verbindungen herausgegeben. Die neue Verison bereinigt zahlreiche kleinere Fehler und bringt ein neues, experimentelles Feature zum Aufbau von VPN-Verbindungen mit.

Das neue Release beseitigt eine Sicherheitslücke, die es lokal angemeldeten Angreifern unter Umständen ermöglichte, bei Nutzung von Secure Copy (scp) dem kopierenden Benutzer Code unterzuschieben, der mit dessen Berechtigungen ausgeführt wird. Das Werkzeug ssh-keygen zur Erzeugung von SSH-Schlüsseln erzeugt nun DSA-Schlüssel mit fester Schlüssellänge von 1024 Bit – die vorher unterstützten längeren Schlüssel widersprachen der DSA-Spezifikation.

Ähnlich wie bei OpenVPN können nun auch OpenSSH-Server und -Client über virtuelle tun- und tap-Schnittstellen beliebige Pakete tunneln. Dies soll den Aufbau echter VPNs ermöglichen. Dieses Feature ist aber noch experimentell und wird derzeit nur unter OpenBSD, Linux, NetBSD (ausschließlich IPv4) und FreeBSD angeboten. Unterstützung für andere Betriebssysteme, die virtuelle tun- oder tap-Schnittstellen anbieten, könnte in künftigen OpenSSH-Versionen einziehen.

Bisher war die VPN-Unterstützung von OpenSSH sehr eingeschränkt. Es konnte nur einzelne TCP-Verbindungen zwischen Client und Server tunneln. Eine ausführliche Liste der beseitigten Fehler und der Änderungen in der neuen Version finden sich in der Ankündung der Entwickler.

Siehe dazu auch:

    * OpenSSH 4.3 released, Ankündigung der neuen OpenSSH-Version
    * Homepage von OpenSSH mit Downloads für diverse Plattformen


Quelle und Links : http://www.heise.de/security/news/meldung/69122

[SiLæncer]

Zwar sollte SSH mit der unsicheren Protokollversion 1 eigentlich nicht mehr eingesetzt werden, dennoch erlauben manche SSH-Server in der Standardeinstellung noch die Verbindungsaufnahme eines Clients damit. In OpenSSH wurde nun ein Implementierungsfehler gefunden, mit dem ein Client den Server durch SSHv1-Pakete aus dem Tritt bringen kann. Dazu genügt es laut Fehlerbericht, dass eine SSH-Nachricht mehrere identische Blöcke enthält. In der Folge belegt der ssh-Serverdienst die Resourcen der CPU für eine gewisse Zeit vollständig. Angreifer können diese Schwachstelle für DoS-Attacken ausnutzen.

Das OpenBSD-Team hat in seinem CVS Updates bereitgestellt, die das Problem lösen sollen. Außer rPath hat bislang kein weiterer Linux-Distributor aktualisierte Pakete veröffentlicht.

Siehe dazu auch:

    * openssh denial of service CVE-2006-4924 and client unclean exit CVE-2006-4925, Fehlerbericht von rPath
    * Openssh Multiple minor issues, Fehlerbericht in den Gentoo-Datenbank

Quelle und Links : http://www.heise.de/security/news/meldung/78730

[SiLæncer]

SSH-Schwachstellen sorgten in letzter Zeit immer wieder für Schlagzeilen. Nun hat es Gerüchten zufolge CentOS/Red Hat Enterprise Linux (RHEL) erwischt.

Basierend auf einem Posting im Forum Web Hosting Talk vermuten Sicherheitsexperten eine unspezifizierte Schwachstelle im Software-Paket OpenSSH Server beziehungsweise im davon verwendeten OpenSSL 4.3. Aktuelle Angriffe heizen die Gerüchte, dass eine Schwachstelle existiert, weiter an.

Experten vermuten, dass die Schwachstelle durch Red Hats Update-Politik in die Software gelangte. Die Verantwortlichen neigen dazu, ältere Software-Versionen mit Patches sicher und kompatibel zu halten und anschließend weiterhin anzubieten. Es wird angenommen, dass beim Patchen ein Fehler unterlief und die Schwachstelle so ins System gelangte.

Auf Nachfragen von heise Security bestätigten die zuständigen Entwickler nicht, dass eine Schwachstelle existiert. Sie gaben allerdings an, über die Gerüchte informiert zu sein und derzeit die Situation zu beobachten, um mehr Informationen zu erhalten. Sollten sich die Gerüchte als zutreffend herausstellen, so die Entwickler, werde man "so schnell wie möglich reagieren."

Quelle : www.gulli.com

[SiLæncer]

Die Gerüchte um einen möglichen Zero-Day-Exploit für eine bislang unbekannte Sicherheitslücke in älteren Versionen (4.3) von OpenSSH haben sich auch nach mehreren Tagen nicht bestätigt. Vielmehr handelt es sich bei den beobachteten Einbrüchen in einige Systeme vermutlich um erfolgreiche Brute-Force-Attacken.

Auch der OpenSSH-Maintainer und Entwickler Damien Miller glaubt nicht an einen Zero-Day-Exploit. Die Analyse eines Angriffs auf einen der betroffenen Server ließ nicht erkennen, dass eine Lücke ausgenutzt wurde, sondern zeigte nur simple Brute-Force-Attacken.

Immerhin ließ sich der US-Webhoster HostGator von den Gerüchten ins Bockshorn jagen und sperrte vorsorglich sämtliche SSH-Zugänge auf den Kundenservern, egal ob diese zur Authentifizierung Passwörter oder Public Key benutzten. Der HostGator-Support bestätigte sogar die Lücke in seinen Kundenforen und gab vor, an einem Patch zu arbeiten – was die Befürchtungen weiter nährte.

Auslöser der Spekulationen waren Postings auf Mailinglisten mit Logs von Einbrüchen der ominösen Gruppe Anti-Sec in verschiedene Server, bei der immer wieder das Tool 0pen0wn/openPWN auftauchte. Unter anderem knackte die Gruppe den Server der Sicherheitsseite astalavista.com Mitte Juni und zuletzt einen Anbieter für Server-Mangement. Auf die Aufklärungsversuche der Betreiber von Astalavista reagierte Anti-Sec, indem sie in den Server von Charalambous Glafkos, einem Mitbetreiber von Astalavista, einbrachen (Log hier). Allen Logs war zu entnehmen, dass das Tool offenbar in OpenSSH-Installation mit Version 4.3 erfolgreich einbrechen konnte.

Die Version ist beispielsweise auf CentOS/Red Hat Enterprise Linux (RHEL) anzutreffen, auch auf Debian Etch ist die aktuelle Version OpenSSH-Version 4.3. Zwar ist die Versionsnummer schon einige Jahre alt – verfügbar ist Version 5.2 –, allerdings pflegen die Entwickler Patches für ältere Versionen zurückzuportieren, sodass die Software sicherheitstechnisch durchaus auf dem aktuellen Stand ist. Auch das Red Hat Security Response Team konnte keine Lücke erkennen und fragte offiziell auf der OpenSSH-Entwickler-Mailingliste nach, wo Damien Miller dann Stellung nahm.

Zusammenfassend lässt sich feststellen, dass eine bislang unbekannte Gruppe wohl mehr oder minder gezielt in die Seiten missliebiger Personen oder anderer Gruppen eingedrungen ist. Die prahlerisch veröffentlichten Logs führten dann zu Spekulationen, aus denen durch "stille Post" und "ich kenn da jemanden der gehört hat" schließlich ein bedrohlicher Zero-Day-Exploit wurde. Viel FUD um nichts. Administratoren sollten dennoch weiterhin ihre Server und SSH-Zugänge im Auge behalten – Angriffe gibts schließlich immer.

Quelle : www.heise.de

[SiLæncer]

Die OpenSSL-Entwickler haben die Versionen 0.9.8o und 1.0.0a vorgelegt, in denen sie nur sicherheitsrelevante Probleme gelöst haben. So lässt sich ein Fehler im ASN.1-Parser ausnutzen, um mit präparierten Strukturen einer "Cryptographic Message Syntax"-Nachricht (CMS) in nicht erlaubte Speicherbereiche zu schreiben. Möglicherweise lässt sich der Fehler ausnutzen, um Code in ein System zu schleusen und ein System zu kompromittieren. In dem OpenSSL-Zweig 0.9.8 ist CMS standardmäßig nicht aktiviert, im Zweig 1.0.0 ist es jedoch aktiviert.

Ein nicht initialisierter Puffer in der Funktion EVP_PKEY_verify_recover() der Version 1.0.0 lässt sich zudem missbrauchen, um einen ungültigen RSA-Schlüssel als gültig erscheinen zu lassen. Da bislang kaum eine Anwendung diese erst kürzlich eingeführte Funktion nutzt, ist die Tragweite des Problems gering. Nach Angaben der Entwickler greift bislang nur das OpenSSL-Tool pkeyutl darauf zurück.

Siehe dazu auch:

    * Two security flaws have been fixed in OpenSSL 0.9.8o and OpenSSL 1.0.0a.

Quelle : www.heise.de

[SiLæncer]

Der Sicherheitsexperte Georgi Guninski hat auf ein Sicherheitsproblem im neueren OpenSSL-Zweig 1.0 hingewiesen, durch den ein SSL-Server einen Client kompromittieren könnte. Dazu genügt es offenbar, ein präpariertes Zertifikat an den Client zu senden, um in der Funktion ssl3_get_key_exchange (in ssl\s3_clnt.c) einen Zugriff auf bereits deallokierten Speicher zu provozieren. Normalerweise führt dies nur zum Absturz der Anwendung, unter Umständen lässt sich aber so auch eingeschleuster Code starten.

Guninski hat seinem auf der Mailing-Liste Full Disclosure veröffentlichten Hinweis ein Zertifikat nebst fehlerhaftem Key zum Nachvollziehen des Problems beigefügt. Auf einem aktuellen Ubuntu-System 10.04 mit OpenSSL 0.9.8k führte das Zertifikat, das zu einem nur 4006 Bit langem RSA-Key gehört (und bei dem q nicht prim ist), in einem kurzen Test der heise-Security-Redaktion nur zu einem Warnhinweis, das Zertifikat sei fehlerhaft.

Da aktuell so gut wie keine Linux-Distribution OpenSSL 1.0.x nutzt, dürfte die Tragweite der Lücke relativ gering sein. Ein Update der OpenSSL-Entwickler gibt es noch nicht, immerhin werden die Umstände des Problems auf der OpenSSL-Entwicklerliste bereits diskutiert.

Quelle : www.heise.de

[SiLæncer]

Wenn ein Prozess sehr viele Kindprozesse hat, die über die Krypto-Bibliothek OpenSSL Zufallszahlen abrufen, den Zufallszahlengenerator aber nicht selbst initialisieren, kommen eventuell innerhalb des Programms die gleichen Zufallszahlen mehrfach zu Anwendung. Konkret bedeutet das, dass sich zum Beispiel Verschlüsselung unter Umständen knacken ließe. Noch ist nicht entschieden, ob die OpenSSL-Entwickler oder -Nutzer ihren Code ändern müssen.

Das Problem tritt auf, wenn das Hauptprogramm zunächst den Zufallszahlengenerator (PRNG, pseudo random number generator) initialisiert und danach mit dem Unix-Systemaufruf fork neue Kind-Prozesse erzeugt. Diese Kinder bekommen eine eindeutige Prozess-IDs (PID). Die OpenSSL-Bibliothek verwendet diese PID intern, damit danach nicht alle Sub-Prozesse die gleichen Zufallszahlen bekommen. Allerdings gibt es im Betriebssystem-Kern einen Maximalwert für die PID: Ist er erreicht, bekommt der nächste Prozess eine niedrige ID, die noch kein anderer verwendet. Dadurch kann ein Child dieselbe PID erhalten wie ein früher erzeugtes und dann von OpenSSL dieselbe Zufallszahensequenz geliefert bekommen.

Der ganze Artikel

Quelle : www.heise.de

[SiLæncer]

Die Open-Source-Bibliothek für Krypto-Funktionen OpenSSL enthält auch eine Implementierung des Pseudo-Zufallszahlen-Generators "Dual EC DRBG" – das ist der mit der NSA-Backdoor. Dummerweise enthielt diese Implementierung einen Fehler, der dazu führt, dass die Funktion keine Zufallszahlen ausspuckt, sondern nur einen Fehler. Der Generator hat also über Jahre hinweg nie funktioniert – und niemand hat es gemerkt, weil niemand ihn verwendet hat.

Anders in der kommerziellen Krypto-Bibliothek BSAFE von RSA. Die setzte den trojanisierten Zufallszahlen-Generator sogar als Default ein. Entwickler, die auf die Voreinstellungen der Krypto-Experten von RSA vertrauten, haben damit dann beispielsweise Produkte erstellt, deren geheime Krypto-Schlüssel sich erraten lassen. Das Beispiel der Open-Source-Bibliothek legt nahe, dass es jedoch keinen echten Bedarf für diesen Zufallszahlen-Generator gab.

RSA baute Dual EC DRBG 2004 als Voreinstellung in die Bibliothek ein und kassierte dafür – wie es Veröffentlichungen aus den Unterlagen von Edward Snowden nahelegen – von der NSA 10 Millionen US-Dollar. Spätestens seit 2007, vermutlich sogar früher, wussten die Krypto-Experten von RSA von ernstzunehmenden Zweifeln an dessen Zuverlässigkeit.

Wie die Open-Source-Konkurrenz zeigt, hätten sie ihn jederzeit durch eine der existierenden Alternativen ersetzen können. Haben sie aber nicht; erst nach der Veröffentlichung der diesbezüglichen Snowden-Dokumnete reagierte RSA. Auch das kürzlich veröffentlichte, angebliche RSA-Dementi erklärt dieses Versäumnis nicht – genau so wenig wie es eine der anderen, konkreten Anschuldigungen entkräftet.

Bei OpenSSL wurde Dual EC DRBG für einen ungenannten Sponsor eingebaut, der die komplette Umsetzung des NIST-Zufallszahlen-Standards SP800-90A (PDF) beaufragte. Er war jedoch nie voreingestellt. Der erst jetzt gefundene Fehler soll auch nicht mehr behoben werden, erklären die Entwickler. In kommenden OpenSSL-Versionen wird Dual EC DRBG statt dessen entfernt.

Quelle und Links : http://www.heise.de/newsticker/meldung/OpenSSL-mit-kaputter-Hintertuer-2072370.html

[SiLæncer]

Die Fork ist ihnen nicht genug: Jetzt wollen die OpenBSD-Entwickler auch die API von OpenSSL ablösen. ReSSL soll das Nutzen von Verschlüsselung einfacher machen, egal welche SSL-Bibliothek im Hintergrund steht.

Die OpenBSD-Entwickler schicken sich an, OpenSSL einen Schritt mehr zu ersetzen. Mit LibreSSL entwickelt man bereits eine Fork der weit verbreiteten SSL-Bibliothek – nun wollen die Entwickler aber auch das OpenSSL-API ablösen. LibreSSL ist mit diesem Programmierinterface voll kompatibel, auf lange Sicht zufrieden sind die Entwickler aus dem OpenBSD-Lager damit aber nicht. Es habe sich herausgestellt, dass die OpenSSL-API "so schlecht ist, dass es sich nicht lohnt, sie zu erhalten."

So jedenfalls Entwickler Ted Unangst, der sich auf einem Vortrag zu den bisherigen Fortschritten bei LibreSSL auf der EuroBSDcon dafür aussprach, ein komplett neues API zu entwickeln. Das nennt er "Reimagined SSL" oder einfach ReSSL. Ziel der neuen Schnittstelle soll es sein, es Entwicklern die Nutzung einfacher zu machen. Man soll sich nicht um Internas wie das Aushandeln von Zertifikaten und die Kodierung von Paketen kümmern müssen. Der Programmierer sagt "Ich will eine verschlüsselte Verbindung" und die API erledigt genau das – so der Plan von Unangst. Um dahin zu kommen, wollen die Entwickler jegliche Kompatibilität mit der OpenSSL-API über Bord werfen.

ReSSL soll nicht an den LibreSSL-Stack gebunden sein und auch andere Bibliotheken unterstützen. Diese erledigen die eigentliche Arbeit im Hintergrund, während ein Programmierer sich nur um die API zu kümmern braucht. ReSSL soll so konzipiert werden, dass es sich einfach in bestehende Programmiersprachen einbinden lässt, unabhängig davon, welcher SSL-Stack im Hintergrund die Arbeit macht. So soll die API eben auch OpenSSL nutzen können.

Kritischer Punkt bei der Umsetzung des Plans ist die Tatsache, dass Entwickler ihre Programme anpassen müssten, um mit ReSSL zu arbeiten. Ob die neue Schnittstelle die OpenSSL-API verdrängen kann, wird sich zeigen müssen. Ist er fertig geschrieben, wird sich der neue Code erst einmal im Einsatz bewähren müssen.

Quelle : www.heise.de

[SiLæncer]

Wer der NSA das Leben schwer machen will, kann das Fernwartungsprotokoll mit einigen Handgriffen auf der Kommandozeile abhärten.

Laut den neuesten Snowden-Veröffentlichungen befindet sich auch das Fernwartungsprotokoll SSH längst im Fadenkreuz der NSA. Dieses wird von Unix-Administratoren bevorzugt eingesetzt, um Server aus der Ferne zu bedienen. Wie man SSH möglichst sicher konfiguriert, erklärt Software-Entwickler stribika. Dabei geht er genau auf die zur Verfügung stehenden Algorithmen ein und erklärt Vor- und Nachteile der einzelnen Optionen. Zusätzlich gibt es noch ein paar generelle Ratschläge zur Schlüsselverwaltung und anderen Best Practices.

Quelle : www.heise.de

[SiLæncer]

Die Entwickler der besonders auf Linux oft genutzten Kryptobibliothek OpenSSL haben eine Reihe von Lücken geschlossen. Updates stehen für drei Entwicklungszweige der Software bereit.

Das OpenSSL-Team hat acht Sicherheitslücken in der Kryptobibliothek geschlossen und entsprechende Updates veröffentlicht. Das Risiko von zwei Lücken bewerten sie als moderat; sie können genutzt werden, um Server lahmzulegen. Von den anderen Lücken geht laut den Entwicklern eine niedrige Gefahr aus.

Eine der Lücken kann dazu führen, dass ein Server einem Client eine Verbindung aufzwingt, bei der der Schlüsselaustausch mit ECDH statt dem ECDHE-Verfahren stattfindet – was zum Verlust von Forward Secrecy führt (CVE-2014-3572). Das führte bei einigen Lesern bereits zu Aufregung, ist Forward Secrecy doch eine sehr wichtige Eigenschaft. Doch erstens betrifft es nur korrekt authentifizierte Verbindungen, ist also nicht für Angriffe durch Dritte geeignet. Und zweitens funktioniert der Angriff nur mit ECDSA-Zertifikaten, die kaum verbreitet sind. Die Risikobewertung "Low" geht also durchaus in Ordnung. In einem weiteren Fall kann sich ein Client ohne privaten Schlüssel am Server anmelden, was allerdings nur bei einer Konfiguration des Servers der Fall ist, die laut der OpenSSL-Entwickler "praktisch nicht anzutreffen" ist (CVE-2015-0205).

Die Entwickler haben die Lücken in den Versionen 1.0.1k, 1.0.0p und 0.9.8zd geschlossen. Quellcode für die Updates kann auf der Webseite des OpenSSL-Projektes heruntergeladen werden.

Quelle : www.heise.de

[SiLæncer]

Alles ist geknackt ...alles? Nein!

Wir befinden uns im Jahre 2015 n.Chr. Das ganze Internet wird von der NSA kontrolliert... Das ganze Internet? Nein! Eine von unbeugsamen Kryptographen und Entwicklern bevölkerte Open Source Welt hört nicht auf, dem Eindringling Widerstand zu leisten. Und das Leben ist nicht leicht für die Legionäre, die als Besatzung in den befestigten Lagern NSA, GCHQ, CSEC, GCSB und ASIS liegen ..

Der letzte Asterix-Comic bezog sich noch auf die römischen Eroberer und das kleine unbeugsame Dorf in Gallien. Der nächste könnte durchaus in der Welt der Five Eyes spielen. Der Zaubertrank von heute besteht aus Kryptographie und offenen Systemen, die geheimen Zutaten sind die geheimen Schlüssel von PGP, OTR, SSH und SSL, während die Römer schon Teile des Geheimrezepts in Händen halten.

Im Sommer 2013 enthüllte Edward Snowden, dass die Dienste der Five Eyes (USA, GB, AUS, NZ, CA) unsere privaten Nachrichten an praktisch allen zentralen Kommunikationsknoten mitlesen. Verschlüsselung hilft dagegen, erklärte Snowden in seinen ersten Interviews. Welche Verschlüsselung hilft und welche nicht, das versucht der zur Jahreswende erschienene Spiegel-Artikel aufzuzeigen, an dem die Tor-Entwickler Appelbaum und Gibson, Dokumentarfilmerin Poitras, Ex-CCC-Sprecher Müller-Maguhn, GNUNet-Maintainer Grothoff, Reporter Michael Sontheimer und der Spiegel-Ressortleiter der Netzwelt Stöcker mitgewirkt haben.

Der ganze Artikel

Quelle : www.heise.de

[SiLæncer]

Wenn Nutzer von Apple- und Android-Geräten eine der Millionen für den Angriff Freak anfälligen Webseiten ansurfen, kann ein Man-in-the-Middle die verschlüsselten Verbindungen knacken. Angreifer können nicht nur Daten mitlesen, sondern auch manipulieren.

Das von einer Gruppe von Sicherheitsforschern entdeckte Angriffsszenario Freak (Factoring attack on RSA-EXPORT Keys) erlaubt es, mit SSL/TLS geschützten Datenverkehr zu entschlüsseln und so etwa sensible Daten von Android- und Apple-Geräte und Mac-Computern mit OS X abzugreifen. Dem aktuellen Informationsstand nach sollen Windows und Linux nicht davon betroffen sein. Freak soll insgesamt Millionen von Webseiten kompromittieren. Ein Scan der Universität Michigan von mehr als 14 Millionen über HTTPS ausgelieferten Internetseiten habe ergeben, dass mehr als 36 Prozent anfällig für die Attacke seien. Das hat ein Team des französischen Forschungsinstitut Inria in Zusammenarbeit mit Microsoft im Zuge der Analyse des State-Machine-Projektes herausgefunden. Bemerkenswert ist, dass viele Content Delivery Networks (CDNs) wie etwa Akamai betroffen zu sein scheinen.

Der ganze Artikel

Quelle : www.heise.de

[SiLæncer]

Der Freak-Angriff kompromittiert unzählige verschlüsselte Webseiten und Angreifer könnten sensible Daten ausspionieren. Ob man für die Attacke anfällig ist, hängt aber vom eingesetzten Betriebssystem, Webbrowser und der besuchten Internetseite ab.

Das Angriffsszenario Freak (Factoring Attack on RSA-EXPORT Keys) erlaubt es, mit SSL/TLS geschützten Datenverkehr zu entschlüsseln. Angreifer könnten so etwa die Kommunikation zwischen Nutzer und besuchter Webseite mitschneiden und im schlimmsten Fall sensible Daten mitlesen.

Ein erfolgreicher Angriff setzt immer eine bestimmte Kombination aus Betriebssystem und Webbrowser voraus. Denn diese Kombination bestimmt, ob das System des Nutzers dazu gebraucht werden kann, schwache Krypto-Schlüssel zu akzeptieren. Ob man vom Freak Attack betroffen ist, zeigt ein Test auf.

Derzeit gibt es keine Anzeichen, dass Linux-Nutzer für die Attacke anfällig sind. Apple will nächste Woche Updates für iOS und OS X anbieten. Google verteilt angeblich bereits Patches an Partner und hält betroffene Webseiten-Betreiber dazu an, die schwachen Export-Cipher zu deaktivieren.

Auswahl betroffener Browser (aktuelle Version):

Android-Browser (zu erkennen an der blauen Weltkugel)
Safari (iOS, OS X, Windows)
Chrome (Standard-Browser ab Android 4.4)
Auswahl nicht betroffener Browser (aktuelle Version):

Chrome (iOS, Linux, OS X, Windows)
Internet Explorer 11
Firefox (Android, Linux, OS X, Windows)

Damit potentielle Angreifer den Bug der betroffenen Browser ausnutzen können, dass sie unsichere Schlüssel annehmen, muss der Nutzer eine Webseite besuchen, die die schwachen Export-Cipher anbietet. Forscher der Universität Michigan haben Anfang dieser Woche eine Liste mit entsprechenden Internetseiten zusammengestellt.

Wer eine betroffene Kombination bestehend aus Betriebssystem und Webbrowser einsetzt und auf Nummer sicher gegen will, kann eine Webseite vor dem Besuch testen. Wenn im Ergebnis in den Cipher Suites also Verfahren mit RSA_EXPORT auftauchen, ist der Server vom möglichen Rückfall auf unsichere 512-Bit-Schlüssel betroffen.

Ruhe bewahren

Selbst wenn alle für einen erfolgreichen Angriff nötigen Punkte erfüllt sind, braucht man nicht in Panik zu verfallen. Denn bei dem möglichen Man-in-the-Middle-Angriff muss es sich um eine gezielte Attacke handeln: Zuhause müsste sich ein potentieller Angreifer erst Zugang zum Router der Zielperson verschaffen. In einem öffentlichen Netzwerk, etwa in einem Café, kann der Freak Attack aber durchaus gefährlich sein. Auch Geheimdienste könnten ihn unter Umständen nutzen, um massenweise Traffic abzugreifen und zu entschlüsseln.

Aktuell ist nicht bekannt, dass der Freak Attack aktiv in Gebrauch ist. Ivan Ristic von den SSL Labs bei Qualys sagte auf Anfrage von heise Security, der Angriff sei zwar theoretisch einfach auszuführen. In der Realität sind aber so viele Variablen involviert, dass sich ein Angriff auf beliebige Nutzer als schwierig darstellt.

[UPDATE 05.03.2015, 18:15]

Der Freak-Attack-Test wurde mittlerweile von den Sicherheitsforschern aktualisiert und es scheinen doch mehr Webbrowser betroffen zu sein. Zudem sind nun wohl auch Linux-Nutzer vor dem Angriff nicht sicher. Heise Security hat sich bei den Sicherheitsforschern zu den Hintergründen der Änderungen der Test-Kriterien erkundigt. Eine Antwort steht noch aus.

Nach aktuellem Stand des Tests sehen die Ergebnisse für einzelne Browser wie folgt aus:

Auswahl betroffener Browser (aktuelle Version):

Android-Browser (zu erkennen an der blauen Weltkugel)
Blackberry Browser
Chrome (Android, OS X)
Dolphin (Android, iOS)
iCab (iOS)
Internet Explorer
Mercury (Android, iOS)
Opera/Opera mini (Android, iOS, Linux, OS X)
Safari (iOS, OS X, Windows)
UC Browser (Android)

Auswahl nicht betroffener Browser (aktuelle Version):

Chrome (iOS, Linux, Windows)
Firefox (Android, Linux, OS X, Windows)
Opera (Windows)
Puffin (iOS)

[UPDATE 05.03.2015, 18:40]

J. Alex Halderman, Assistenz-Professor Universität Michigan, teilte gegenüber heise Security mit, dass die für den Freak-Test präparierten Server nicht korrekt konfiguriert waren und den Internet Explorer fälschlicherweise als sicher einstuften.

Das Testverfahren, dass die Forscher anwenden, hat das grundsätzliche Problem, dass es ein Nichtzustandekommen einer verschlüsselten Verbindung manchmal so interpretiert, als wäre der Browser sicher. Da diese Verbindung aber auch aus anderen Gründen abgebrochen werden könnte, führt das manchmal zu False Positives. Trotzdem versicherte Halderman, "False Postives sind sehr unwahrscheinlich. Falls der Test also sagt, dass Ihr Browser angreifbar ist, sollten Sie das glauben."

Quelle : www.heise.de