BEAST: SSL 3.0/TLS 1.0 am Ende?

Am Wochenende wollen die Sicherheitsexperten Thai Duong und Juliano Rizzo auf der Konferenz ekoparty in Argentinien einen erfolgreichen Angriff auf die verbreitetste Variante der SSL/TLS-Verschlüsselung vorstellen. Sie werden ihre Javascript-Anwendung BEAST (Browser Exploit Against SSL/TLS) vorstellen. Diese soll aktuell in der Lage sein, innerhalb von 10 Minuten ein PayPal-Cookie zu entschlüsseln.

Kurz nach dem Zertifikats-Desaster von DigiNotar bedroht der Angriff von Doung und Rizzo abermals die SSL-Verschlüsselung. Ihre Erkenntnisse bringen die am häufigsten eingesetzte Version SSL 3.0/TLS 1.0 ins Wanken. Zwar wurden bereits zwei weitere Versionen (2006 TLS 1.1 und 2008 TLS 1.2) veröffentlicht, allerdings herrscht eine Art Angebot-Nachfrage-Problem, das die Umsetzung verhindert. Einerseits fehlt in OpenSSL die Unterstützung für TLS 1.1 und 1.2 und damit die Implementierung für Linux-Server, auf der anderen Seite unterstützen auch die meisten Browser bisher nur SSL 3.0/TLS 1.0.

Dies könnte sich nun ändern. Durch den erfolgreichen Angriff steht praktisch die gesamte SSL-Verschlüsselung auf dem Spielstand. OpenSSL und die Browserhersteller werden sich zeitnah um die Unterstützung der aktuellen TLS-Protokolle bemühen müssen, falls nicht doch ein Patch gegen die Lücke gefunden wird. Dies könnte sich allerdings als steiniger Weg erweisen. Laut Duong und Rizzo standen sie seit Mai in engem Kontakt mit den Browser-Herstellern und Anbietern von SSL-Implementierungen. Allerdings sorgte jeder vorgeschlagene Fix für Probleme bei zumindest einem Teil der SSL-Anwendungen.

Internetnutzern bleibt nur, auf eine schnelle Behebung der Probleme zu hoffen. Da BEAST auf Javascript aufsetzt, können Browsererweiterungen wie NoScript oder Notscript das Risiko auf fremden Seiten mindern. Einen vollständigen Schutz bieten sie allerdings nicht. Sollte es Kriminellen gelingen, den Code in eine Webseite einzuschleusen, die der Nutzer als vertrauenswürdig ansieht, wäre auch dieser Schutz ausgehebelt. Auch bei einem “Man-in-the-Middle”-Angriff wäre dies wirkungslos.

Weitere Infos / Quelle: The Register

Datenbanken, Klartext-Passwörter und Verschlüsselung

Sicherheitslecks und Hackerangriffe auf bekannte Seiten gab es in den letzten Monaten zur Genüge. Erstaunlicherweise gibt auch 2011 noch große Unternehmen, die Passwörter im Klartext in ihren Datenbanken speichern. So brachte ein Hack bei Sony Pictures die Passwörter von über einer Million Nutzer im Klartext zum Vorschein. Auch die REWE-Gruppe beauftragte einen Dienstleister, der sämtliche Kundenpasswörter unverschlüsselt speicherte.

Unverständlich ist dabei, wie Dienstleister mit solch offenkundiger Inkompetenz den Auftrag erhalten konnten. Ebenso unverständlich ist, wie der Fehler dem Auftraggeber bzw. der IT-Sicherheit entgehen konnte. Bereits bei der Vergabe des Auftrags muss die Sicherheit der Anwendung einen wichtigen Stellenwert einnehmen.

Wer heutzutage noch Passwörter im Klartext speichert, ist dem Stand der Technik bzw. des Wissens um Jahre hinterher. Einen solchen Dienstleister auf die eigenen Webseite und die eigenen Kunden “loszulassen” ist mehr als fahrlässig. Wenn in Ihrer Datenbank Passwörter unverschlüsselt gespeichert sind, besteht dringender Handlungsbedarf.

Manchmal stößt man bei der Prüfung bereits vorhandener Webanwendungen auch auf Kurioses. So habe ich bereits ein Script gesehen, bei dem der Entwickler offenbar nachträglich eine Verschlüsselung der Passwörter hinzufügte. Anstatt aber nun die bereits vorhandenen Passwörter ebenfalls zu hashen wurden nur neu erstellte Passwörter gesichert. Die Nutzer, die ihr Passwort nicht änderten, waren weiterhin gefährdet und es entstand eine wild durchmischte Datenbank.

Oftmals ist aber auch falsch verstandener Stolz ein Problem. Viele Entwickler programmieren eigene Passwort-Funktionen. Sei es, um “Kompetenz” zu signalisieren, um den Projektaufwand und damit ihre Bezahlung zu erhöhen oder auch wenn sie ein eigenes CMS verwenden bzw. vermarkten wollen.

Fehlende kryptographische Grundlagen oder schlampige Umsetzung einer eigenen Passwortverschlüsselung sorgt in den meisten Fällen aber dafür, dass die Verschlüsselung schlechter ausfällt, als bei etablierten Systemen wie z.B. phpass.

Die Passworterstellung und -verschlüsselung sollte etablierten Systemen wie dem erwähnten phpass oder dem ggf. verwendeten Framework überlassen werden. Letztlich wird sowohl dem Auftraggeber, als auch dem Entwickler ein Gefallen getan. Der Auftraggeber erhält ein sichereres Produkt, der Entwickler hat mehr Zeit für Features – oder er spart Zeit und kann seine Dienstleistung günstiger anbieten.

Die Zeiten, in denen sich ein Programmierer damit “auszeichnen” konnte, wenn er möglichst viel selbst programmiert, sind eindeutig vorbei.