Die 10 katastrophalsten Sicherheitslücken – Teil 1

Unser Blogjahr startete mit den 10 interessantesten Hackerangriffen. Aufgrund der positiven Resonanz stellen wir Ihnen diese und kommende Woche die 10 katastrophalsten Sicherheitslücken vor.

Platz 10: Google veröffentlicht geheime Whois-Daten

Das Unternehmen Cisco wurde im März 2015 auf ein Leck im Google Apps-Service aufmerksam, durch das über 280.000 eigentlich als geheim geltende Adressen verschiedener Domaininhaber öffentlich einsehbar waren. In Zusammenarbeit mit dem Registrar eNom bietet Google Apps die Möglichkeit, .com-Domains registrieren zu können, ohne Daten in der Whois-Abfrage zu hinterlassen. Eine offenbar beliebte Funktion, denn weit über 90 % aller registrierten Domaininhaber setzen auf diese Privatsphäre-Schutzoption. Schon Mitte 2013 tauchte jedoch ein Bug auf, der Anfang 2015 für die Offenlegung von mehr als 280.000 geheimen Whois-Daten sorgte.

Die sogenannte „Whois Privacy Protection“ bewirkt, dass Anschrift, Name, E-Mail-Adresse sowie Telefonnummer eines Domaininhabers online für jedermann zugänglich ist. Dies soll vorrangig vor Identitätsdiebstahl bewahren. Jedoch bewirkte ein Softwarefehler in Google Apps das Gegenteil, wie Cisco seinerzeit auf seinem Blog mitteilte. Beim alljährlichen Verlängern der jeweiligen Domainregistrierung soll beim Nutzen der Funktion eigentlich „Whois Privacy Protection Service Inc.“ als Firmeninhaber stehen, als Name „Whois Agent“. Als Folge der Panne standen dort jedoch die tatsächlichen Nutzerdaten.

Google hat sich für die Panne entschuldigt und den Fehler auf Ciscos Kontakt hin behoben. Die Daten der Nutzer waren jedoch weiterhin einsehbar, da verschiedene Dienste, etwa Domaintools, die Whois-Einträge zahlloser Domänen regelmäßig archivieren.

Platz 9: Twitters Sicherheitslücke wurde aktiv ausgenutzt

Der Micro-Blogging-Dienst Twitter hatte im Jahre 2009 ein ernstes Problem: eine Cross-Site-Scripting-Lücke wurde aktiv ausgenutzt, um einen Wurm zu platzieren, der sich selbstständig auf Twitter verbreitete. Erste Wurm-Codes tauchten auf und eine Demo erlaubte einen Test: dabei öffnete sich ein Popup mit Datenschnipseln des Cookies. Farbflächen tauchten in Tweets auf, die zum Beispiel automatisierte Retweets auslösten. Das Deaktivieren von JavaScript schützte vor dem Angriff.

Twitter schaltete die Timeline öffentlicher Tweets auf seiner Website zeitweise ab. Twitter-Clients, die die Twitter-API nutzen, waren nicht betroffen, sodass man Services wie Tweetdeck, aber auch die mobile Twitter-Seite (m.twitter.com) gefahrlos nutzen konnte. Die Zwangs-Twitter-Pause zahlreicher User hielt bis zum 21. September 2010 an, als Del Harvey, die das Twitters Trust & Safety Team leitete, twitterte, dass das Problem nun behoben sei.

Platz 8: fataler Verschlüsselungsfehler in iOS und OS X

Er ging als „goto fail“ in die Sicherheitsgeschichte ein: der fatale Verschlüsselungsfehler, der im Februar 2014 Apples Betriebssysteme unsicher werden ließ. Der Fehler steckte ausgerechnet in der Funktion, die sicherstellen soll, dass die Schlüssel, die für gesicherte Verbindungen angefordert werden, definitiv von der korrekten Gegenseite stammen. Diese Prüfung entfiel durch den Fehler und jeder erdenkliche Schlüssel wurde einfach akzeptiert.

In der Praxis hieß das, dass sich Hacker, Geheimdienste oder Cyberkriminelle sehr einfach als beliebiges Unternehmen, beispielsweise die Online-Bank oder auch Facebook, ausgeben und sensible Daten mitlesen konnten. Die Verbindung war zwar verschlüsselt, jedoch merkten die Apple-Devices nicht, dass Schlüssel und Website nicht zueinander passten.

Apple reagierte mit einem Update, forderte Nutzer dazu auf, dieses sofort einzuspielen und in öffentlichen Netzen nicht mehr auf HTTPS-Verbindungen zu vertrauen oder gar Passwörter einzugeben, bis das Update eingespielt ist. So weit, so gut, allerdings nur für iOS-Nutzer. OS X-Anwender mussten länger auf ein Update warten. Wie lange der Fehler, den Adam Langley als Google-Mitarbeiter in seinem Blog beschrieb, bereits existierte, ist unklar.

Betroffen war Apples SSL-Quellcode: hier ermöglichte eine überflüssige Dopplung der goto fail-Zeile den Bug. Selbst Nutzer, die auf Apples Safari-Browser verzichteten, waren betroffen, da Dienste wie Apple Mail, iBooks, aber auch die Twitter-App Apples SSL-Implementierung „Secure Transport“ nutzten. Es dauerte, bis Mac-User mit einem Patch bedient wurden – und als es endlich soweit war, stellten sich diverse Fehler und Ungereimtheiten heraus. Apple stand stark in der Kritik: anstatt mit dem Patchen bis zum nächsten Großupdate zu warten, hätten es viele lieber gesehen, hätte der Konzern ein Notfall-Update herausgebracht.

Platz 7: Bug aus den 80ern spähte in 2015

Die Sicherheitslücke „Factoring attack on RSA-Export Keys“, besser bekannt als Freak, erlaubte es Angreifern, Internetverbindungen abzuhören und sensible Daten zu erbeuten. Die Schwachstelle fand ihren Ursprung in den 80er Jahren: US-Unternehmen war es per Gesetz untersagt, starke Verschlüsselungstechniken im Ausland zu veräußern. So entschloss man sich, eine abgeschwächte Export-Version zu schaffen. Die Schlüssel wurden auf 512 Bit gekürzt, sodass sie ziemlich leicht zu knacken waren. Eine gesetzliche Hintertür entstand, deren Auswüchse wir im Jahre 2015 kennenlernen sollten.

Und diese Auswüchse hatten es in sich: nicht nur Googles Standard-Android-Browser und Apples Safari waren betroffen, sondern auch sämtliche Windows-Versionen erlaubten es, Freak auszunutzen. Updates brachten nicht den gewünschten Erfolg, sondern legten Windows Update lahm und sorgten dafür, dass diverse HTTPS-Websites nicht mehr erreichbar waren. Alle Hintergründe dieser katastrophalen Sicherheitslücke lesen Sie bitte in unserem Beitrag „Freak: Sicherheitslücke zielt auch auf Windows-User ab“ nach.

Platz 6: Sony reagiert zögerlich auf SQL-Injection-Lücke

Schon in unserer Hacker-Serie war Sony fester Bestandteil. Wenig verwunderlich, dass die SQL-Injection-Lücke, die Zugriff auf die sensiblen Kundendaten im Playstation Network gestattete, zu unseren katastrophalsten Sicherheitslücken zählt. Der IT-Sicherheitsexperte Aria Akhavan entdeckte die Sicherheitslücke und informierte Sony. Der Konzern jedoch reagierte nicht, bis zwei Wochen später die Medien auf die Lücke aufmerksam wurden. Die Lücke war verheerend: über eine Funktion auf Sonys Support-Seite gelang es, durch manipulierte Parameter in der URL Anfragen an Sonys SQL-Datenbankserver zu senden. Potenzielle Angreifer erhielten die Ausgabe der Anfrage bequemer Weise direkt im Browser.

Dass es Sony mit seiner Sicherheitspolitik mehrfach in die SQLI Hall of Shame geschafft hat, erscheint wenig verwunderlich. Wohl am heftigsten war jedoch, dass sich Sony elegant ausschwieg und einfach nicht reagierte: weder Heise noch der Spiegel oder andere Magazine erhielten Auskunft – Anfragen blieben einfach wochenlang liegen, ebenso die Sicherheitslücke, bei der der Umfang des Zugriffs auf die Userdaten unbekannt war. Dies hätte einer Klärung bedurft, die jedoch seitens Sony ausblieb.

Die 10 katastrophalsten Sicherheitslücken: Plätze 5 – 1

Freuen Sie sich auf die Plätze 5 bis 1 der katastrophalsten Sicherheitslücken in der kommenden Woche! In der Zwischenzeit können Sie uns gerne mitteilen, welche Sicherheitslücke Sie erschüttert hat. Kommen Sie mit uns ins Gespräch: hier in den Kommentaren, auf Facebook, Google Plus oder Twitter!