DVB-Cube BETA <<< Das deutsche PC und DVB-Forum >>>

PC-Ecke => # Security Center => Thema gestartet von: SiLæncer am 06 September, 2005, 11:58

Titel: OpenSSH/OpenSSL/OpenVPN
Beitrag von: SiLæncer am 06 September, 2005, 11:58

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

Titel: OpenSSH auf dem Weg zum vollwertigen VPN
Beitrag von: SiLæncer am 01 Februar, 2006, 18:25

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

Titel: DoS-Schwachstelle in OpenSSH
Beitrag von: SiLæncer am 27 September, 2006, 17:52

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

Titel: SSH-Schwachstelle in Red Hat und CentOS?
Beitrag von: SiLæncer am 08 Juli, 2009, 20:48

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 (http://www.webhostingtalk.com/showthread.php?t=873301) 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 (http://www.gulli.com)

Titel: Gerüchte um Zero-Day-Exploit für OpenSSH bestätigen sich nicht
Beitrag von: SiLæncer am 09 Juli, 2009, 16:50

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 (http://www.heise.de)

Titel: OpenSSL-Updates beseitigen Schwachstellen
Beitrag von: SiLæncer am 03 Juni, 2010, 13:20

Die OpenSSL-Entwickler haben die Versionen 0.9.8o und 1.0.0a vorgelegt (http://www.openssl.org/source/), 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 (http://www.openssl.org/news/secadv_20100601.txt).

Quelle : www.heise.de

Titel: Schwachstelle in OpenSSL 1.0.x
Beitrag von: SiLæncer am 10 August, 2010, 12:06

Der Sicherheitsexperte Georgi Guninski hat auf ein Sicherheitsproblem im neueren OpenSSL-Zweig 1.0 (http://www.heise.de/meldung/OpenSSL-1-0-0-ist-da-966764.html) 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

Titel: OpenSSL erzeugt zu oft den gleichen Zufall
Beitrag von: SiLæncer am 26 August, 2013, 13:30

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 (http://www.heise.de/newsticker/meldung/OpenSSL-erzeugt-zu-oft-den-gleichen-Zufall-1942299.html)

Quelle : www.heise.de

Titel: OpenSSL mit kaputter Hintertür
Beitrag von: SiLæncer am 26 Dezember, 2013, 18:43

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

Titel: ReSSL: Der nächste Schritt weg von OpenSSL
Beitrag von: SiLæncer am 30 September, 2014, 18:54

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

Titel: l+f: SSH mit Alu-Hut
Beitrag von: SiLæncer am 06 Januar, 2015, 20:10

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 (https://stribika.github.io/2015/01/04/secure-secure-shell.html), 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

Titel: Die ersten OpenSSL-Updates des Jahres stehen an
Beitrag von: SiLæncer am 09 Januar, 2015, 13:49

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 (http://www.openssl.org/news/secadv_20150108.txt) 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 (http://openssl.org/source/) kann auf der Webseite des OpenSSL-Projektes heruntergeladen werden.

Quelle : www.heise.de

Titel: SSH, SSL, IPsec -- alles kaputt, kann das weg?
Beitrag von: SiLæncer am 09 Januar, 2015, 18:31

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 (http://www.heise.de/security/artikel/SSH-SSL-IPsec-alles-kaputt-kann-das-weg-2514013.html)

Quelle : www.heise.de

Titel: Freak Attack: SSL-Verschlüsselung von Millionen Webseiten angreifbar
Beitrag von: SiLæncer am 04 März, 2015, 13:37

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 (http://www.heise.de/newsticker/meldung/Freak-Attack-SSL-Verschluesselung-von-Millionen-Webseiten-angreifbar-2566444.html)

Quelle : www.heise.de

Titel: Schutz vor Freak Attack: Diese Browser sind betroffen
Beitrag von: SiLæncer am 05 März, 2015, 19:50

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

Titel: Freak Attack: Hotfix legt Windows Update lahm
Beitrag von: SiLæncer am 07 März, 2015, 15:00

Microsoft bietet einen Workaround an, um die Gefahr des Freak-Angriffes unter Windows abzuwehren. Allerdings funktioniert nach dem Befolgen der Anleitung auf einigen Systemen das Herunterladen von Updates nicht mehr. HTTPS-Webseiten sind auch betroffen.

(http://1.f.ix.de/scale/geometry/600/q75/imgs/18/1/4/4/6/5/6/0/winupdate2-6a24d771a17ee2f3.png)

Der von Microsoft empfohlene Workaround, um die Freak-Lücke in der Krypto-Infrastruktur von Windows zu stopfen, kann auf Systemen dazu führen, dass Windows Update nicht mehr richtig funktioniert. Heise Security konnte das in eigenen Tests nachstellen. Die von Microsoft vorgeschlagene Modifikation der Krypto-Algorithmen führt außerdem dazu, dass einige über HTTPS ausgelieferte Webseiten nicht mehr zu erreichen sind. Dazu gehören unter anderem die Online-Banking-Angebote mehrerer Banken.

Der ganze Artikel (http://www.heise.de/security/meldung/Freak-Attack-Hotfix-legt-Windows-Update-lahm-2570391.html)

Quelle : www.heise.de

Titel: Re: Freak Attack: SSL-Verschlüsselung von Millionen Webseiten angreifbar
Beitrag von: Hans Vader am 07 März, 2015, 19:55

Titel: OpenSSL liefert Freak-Update
Beitrag von: SiLæncer am 19 März, 2015, 17:36

Mit neuen Versionen der Kryptobibliothek OpenSSL schließt das Team des Open-Source-Projektes eine ganze Reihe von Schwachstellen; darunter auch die Freak-Lücke. Admins sollten die Updates umgehend einspielen.

OpenSSL-Nutzer aufgepasst: In der besonders auf Linux-Systemen eingesetzten Kryptobibliothek OpenSSL klaffen zahlreiche Schwachstellen; zwei davon stuft das Entwickler-Team mit einem hohen Sicherheitsrisiko ein. Die vier neuen Versionen 1.0.2a, 1.0.1m, 1.0.0r und 0.9.8zf stopfen die Lücken und stehen ab sofort zum Download bereit.

Der ganze Artikel (http://www.heise.de/security/meldung/OpenSSL-liefert-Freak-Update-2581175.html)

Quelle : www.heise.de

Titel: Beliebige SSL-Zertifikate durch Missbrauch der Uralt-Internettechnik BGP
Beitrag von: SiLæncer am 10 August, 2015, 19:29

Das für das globale Internet unabdingbare Border Gateway Protocol (BGP) lässt sich leicht manipulieren. Ein Hacker beschrieb auf der Black Hat, wie man darüber gültige SSL-Zertifikate für beliebige Domains ausstellen lassen kann.

Gleich zwei Sicherheitsexperten haben im Rahmen der Hackerkonferenz Black Hat 2015 über die Probleme im Zusammenhang mit dem Border Gateway Protocol gesprochen. Wim Remes von Rapid 7 weist darauf hin, dass mit dem Internet der Dinge zwar Millionen oder gar Milliarden neuer Gerätschaften ins Netz gehängt werden – die technische Grundlage des Internets aber immer noch die gleiche ist wie bei dessen Geburt.

So sorgt nach wie vor das BGP für die Verbindung der Autonomen Systeme (AS), die früher typischerweise nur bei Internetserviceprovidern standen, inzwischen aber auch von größeren Unternehmen selbst betrieben werden. Die AS leiten Datenverkehr untereinander so weiter, dass die Kosten möglichst niedrig bleiben. Die zur Verfügung stehende Bandbreite spiele hierbei keine Rolle, erläuterte Remes.

Hat ein Angreifer einen BGP-Router unter Kontrolle, kann er einzelne Routen entführen: Er lässt den AS-Betreiber IP-Präfixe aussenden, die gar nicht in seinen Bereich fallen. Andere BGP-Router haben ab Werk keine Möglichkeit, diese Angaben zu prüfen und leiten dem manipulierten AS-Betreiber brav sämtlichen für diese IP-Adressen bestimmten Traffic zu.

Der ganze Artikel (http://www.heise.de/newsticker/meldung/Beliebige-SSL-Zertifikate-durch-Missbrauch-der-Uralt-Internettechnik-BGP-2774454.html)

Quelle : www.heise.de

Titel: Triple-Seven: OpenSSH-Schwachstelle leakt geheime Schlüssel
Beitrag von: SiLæncer am 14 Januar, 2016, 18:49

Eine unfertige Option, die bei OpenSSH seit 2010 standardmäßig aktiviert ist, führt dazu, dass gekaperte Server die geheimen Schlüssel der sich verbindenden Nutzer auslesen können. Updates, welche die Lücke schließen, stehen bereit.

Im OpenSSH-Code schlummerten seit 2010 Schwachstellen (CVE-2016-0777 und -0778), die es bösartigen Servern erlauben, den Speicherinhalt des Clients auszulesen – inklusive der sensiblen privaten Schlüssel. Auf Grund der CVE-Nummern hat die Schwachstelle in sozialen Netzwerken bereits den Spitznamen "Triple-Seven" bekommen. Betroffen sind alle OpenSSH-Versionen von 5.4 bis einschließlich 7.1; das Update 7.1p2 schließt die Lücke. Außerdem gibt es Patches für OpenSSh 5.8 und 5.7.

Die Bugs befinden sich im sogenannten Roaming Support, einer OpenSSH-Funktion die nie komplett eingeführt wurde. Zwar unterstützen die Clients die Option seit OpenSSH 5.4, im Server-Code wurde sie aber nie freigeschaltet. Mit der Roaming-Funktion sollten die beiden Enden der SSH-Verbindung ihre Kommunikation wieder aufnehmen können, wenn sie unvermittelt abreißt. Wer die Patches nicht einspielen kann, sollte die Roaming-Funktion in der SSH-Konfigurationsdatei (global oder in der Nutzer-spezifischen Datei im Home-Verzeichnis) mit folgendem Befehl abschalten: UseRoaming no

Angreifbar sind alle ungepatchten OpenSSH-Clients in der Standardkonfiguration. Allerdings ist ein Man-in-the-Middle-Angriff nicht möglich, das Opfer muss sich also mit einem bösartigen Server verbinden. Auch kann die Schwachstelle nur ausgenutzt werden, nachdem das Opfer sich bereits erfolgreich angemeldet hat, weshalb Linux-Distributor Red Hat die Lücke nur als "moderat" einschätzt. Kompromittierte SSH-Server können aber immerhin bei jeder Anmeldung eines Clients dessen geheimen Schlüssel auslesen.

Quelle : www.heise.de

Titel: OpenSSL fixt kritische Sicherheitslücke
Beitrag von: SiLæncer am 28 Januar, 2016, 19:00

Admins sollten ihre Server mit den aktualisierten OpenSSL-Versionen 1.0.1r und 1.0.2f absichern. Denn unter Umständen könnten Angreifer sonst den Schlüsselaustausch belauschen und Verbindungen dechiffrieren.

Die OpenSSL-Version 1.0.2 ist anfällig für eine kritische Sicherheitslücke, die Angreifern das Entschlüsseln von TLS-gesicherten Verbindungen ermöglicht. Darüber hinaus beseitigen soeben veröffentlichte Sicherheits-Updates auch eine minderschwere Lücke, die auch 1.01 betrifft. Die fehlerbereinigten Versionen 1.0.1r und 1.0.2f stehen ab sofort zum Download bereit.

Die kritische Lücke betrifft den Schlüsselaustausch via Diffie Hellman (DH, CVE-2016-0701). Für den setzt OpenSSL traditionell einige wenige, bekanntermaßen sichere Primzahlen ein. Seit Version 1.0.2 kann man jedoch auch eigene DH-Parameter erzeugen, die dann auch individuelle Primzahlen enthalten. Dabei erzeugt openssl auch unsichere Primzahlen, die es einem Angreifer erlauben, den privaten DH-Exponenten zu ermitteln, mit dem man dann den ausgetauschten Schlüssel errechnen und somit die verschlüsselten Daten dechiffrieren kann.

Böses Recycling

Das wird dann zum akuten Sicherheitsproblem, wenn die Option SSL_OP_SINGLE_DH_USE nicht gesetzt ist, wie es standardmäßig der Fall ist. Dann nämlich verwendet ein Server-Prozess für seine gesamte Lebenszeit den gleichen DH-Exponenten. Ein Angreifer könnte also mit einem einmal ermittelten DH-Exponenten alle weiteren Verbindungen des Prozesses attackieren. Allerdings glaubt das SSL-Team, dass viele beliebte Applikation den SINGLE_DH_USE aktivieren ("it is believed"), nennen dafür jedoch keine Beispiele.

Dieses Problem ist besondere relevant, weil erst kürzlich Forscher demonstriert haben, dass sich Diffie-Hellman mit zu kurzen Schlüsseln angreifen lässt, wenn man sehr aufwendige Berechnungen im Voraus durchführt; selbst das Knacken von 1024-Bit-DH läge in der Reichweite der NSA, rechneten die Forscher vor. Allerdings bezogen sich die Vorab-Berechnungen immer jeweils nur auf eine bestimmte Primzahl. Man könnte sich also einem Angriff auch durch die Wahl exotischer Primzahlen entziehen. Besser ist es jedoch, Diffie Hellman mit 2048 Bit durchzuführen.

Da bisher nicht klar ist, welche Server-Applikationen von dem Problem betroffen sind, empfiehlt es sich, nach dem Upgrade auf die neue Version auch eventuell vorhandene DH-Parameter-Dateien durch neue zu ersetzen.

Gefahr durch SSLv2

Das minderschwere Problem betrifft die Unterstützung von SSLv2 (CVE-2015-3197). Versäumt es ein Server, dieses längst veraltete Protokoll explizit abzuschalten, kann ein bösartiger Client eventuell schwache SSLv2-Verbindungen auszuhandeln. Es ist also keineswegs ausreichend, etwa alle SSLv2-Cipher-Suiten zu verbieten. Heise Security empfiehlt deshalb bereits seit langem eine Konfiguration mit

SSLProtocol All -SSLv2 -SSLv3

etwa für Apache-Server. Zudem soll OpenSSL nun noch besser gegen die Logjam-Attacke abgesichert sein und eine Downgrade auf Diffie-Hellmann-Schlüsselaustausch mit weniger als 1024 Bit verhindern. Interessant ist übrigens auch, dass das OpenSSL-Team gemäß dem Security-Advisory erst am 12. Januar von der kritischen Lücke erfahren hat und somit bereits nach wenig mehr als zwei Wochen Updates bereits stellt.

Quelle : www.heise.de

Titel: Admins an Deck: OpenSSL veröffentlicht Sicherheitsupdates
Beitrag von: SiLæncer am 22 September, 2016, 17:02

Über mehrere Lücken können Angreifer Server lahmlegen, die OpenSSL einsetzen. Updates stehen bereit.

Neue Versionen der Kryptobibliothek OpenSSL schließen insgesamt 14 Sicherheitslücken. Eine davon stellt laut den Entwicklern ein hohes Risiko für betroffene Server da, bei einer anderen wird das Risiko als moderat eingeschätzt. Die restlichen Lücken haben die niedrigste Prioritätsstufe. Angreifer können die Lücken dazu missbrauchen, den Server lahmzulegen. Ausführung von Schadcode ist durch die Lücken nicht möglich.

Administratoren sollten ihre OpenSSL-Installationen so schnell wie möglich aktualisieren. Je nach eingesetztem Entwicklungszweig sollten die Systeme auf OpenSSL 1.1.0a, 1.0.2i oder 1.0.1u umgestellt werden. Auf Linux-Systemen werden die Updates in der Regel über die Repositories der entsprechenden Distribution verteilt. Quellcode der neuen Versionen kann auf der Webseite des OpenSSL-Projektes heruntergeladen (https://www.openssl.org/source/) werden.

Weitere Details zu den geschlossenen Lücken finden sich in einem Security Advisory (https://www.openssl.org/news/secadv/20160922.txt) der Entwickler.

Quelle : www.heise.de

Titel: Neue Sicherheits-Updates: OpenSSL hat sich verpatcht
Beitrag von: SiLæncer am 27 September, 2016, 13:46

Admins sollten aufpassen, welche abgesicherten OpenSSL-Versionen sie einspielen: Die Patches aus der vergangenen Wochen haben zwei weitere Lücken aufgerissen. Aktualisierte Versionen stehen bereit.

Das OpenSSL-Team hat sich mit seinen Sicherheits-Updates aus der vergangenen Woche weitere Lücken in der Krypto-Bibliothek eingehandelt. In einer aktuellen Sicherheits-Warnung empfehlen sie Admins, die jüngst veröffentlichten verwundbaren Versionen 1.0.2i und 1.1.0a zu überspringen.

Die Lücke in Version 1.1.0a stuft das Team als kritisch ein. Über einen Speicherfehler könnte ein Angreifer unter Umständen Systeme abstürzen lassen und sogar eigenen Code ausführen. Admins sollten zügig die fehlerbereinigte Version 1.1.0b installieren.

Aufgrund eines fehlenden Checks könnten Dritte Server mit OpenSSL 1.0.2i zum Absturz bringen. Version 1.0.2j führt den Check wieder ein.

Quelle : www.heise.de