{"id":2847,"date":"2016-01-19T13:39:51","date_gmt":"2016-01-19T12:39:51","guid":{"rendered":"https:\/\/www.psw-group.de\/blog\/?p=2847"},"modified":"2026-01-16T10:20:00","modified_gmt":"2026-01-16T09:20:00","slug":"die-10-katastrophalsten-sicherheitsluecken-teil-1","status":"publish","type":"post","link":"https:\/\/www.psw-group.de\/blog\/die-10-katastrophalsten-sicherheitsluecken-teil-1\/","title":{"rendered":"Die 10 katastrophalsten Sicherheitsl\u00fccken \u2013 Teil 1"},"content":{"rendered":"

Unser Blogjahr startete mit den 10 interessantesten Hackerangriffen<\/a>. Aufgrund der positiven Resonanz stellen wir Ihnen diese und kommende Woche die 10 katastrophalsten Sicherheitsl\u00fccken vor.<\/p>\n

Platz 10: Google ver\u00f6ffentlicht geheime Whois-Daten<\/h3>\n

Das Unternehmen Cisco wurde im M\u00e4rz 2015 auf ein Leck im Google Apps-Service aufmerksam, durch das \u00fcber 280.000 eigentlich als geheim geltende Adressen verschiedener Domaininhaber \u00f6ffentlich einsehbar waren. In Zusammenarbeit mit dem Registrar eNom<\/a> bietet Google Apps die M\u00f6glichkeit, .com-Domains registrieren zu k\u00f6nnen, ohne Daten in der Whois-Abfrage zu hinterlassen. Eine offenbar beliebte Funktion, denn weit \u00fcber 90 % aller registrierten Domaininhaber setzen auf diese Privatsph\u00e4re-Schutzoption. Schon Mitte 2013 tauchte jedoch ein Bug auf, der Anfang 2015 f\u00fcr die Offenlegung von mehr als 280.000 geheimen Whois-Daten sorgte.<\/p>\n

Die sogenannte „Whois Privacy Protection“ bewirkt, dass Anschrift, Name, E-Mail-Adresse sowie Telefonnummer eines Domaininhabers online f\u00fcr jedermann zug\u00e4nglich ist. Dies soll vorrangig vor Identit\u00e4tsdiebstahl bewahren. Jedoch bewirkte ein Softwarefehler in Google Apps das Gegenteil, wie Cisco seinerzeit auf seinem Blog mitteilte<\/a>. Beim allj\u00e4hrlichen Verl\u00e4ngern 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\u00e4chlichen Nutzerdaten.<\/p>\n

Google hat sich f\u00fcr die Panne entschuldigt und den Fehler auf Ciscos Kontakt hin behoben. Die Daten der Nutzer waren jedoch weiterhin einsehbar, da verschiedene Dienste, etwa Domaintools<\/a>, die Whois-Eintr\u00e4ge zahlloser Dom\u00e4nen regelm\u00e4\u00dfig archivieren.<\/p>\n

Platz 9: Twitters Sicherheitsl\u00fccke wurde aktiv ausgenutzt<\/h3>\n

Der Micro-Blogging-Dienst Twitter hatte im Jahre 2009 ein ernstes Problem<\/a>: eine Cross-Site-Scripting-L\u00fccke wurde aktiv ausgenutzt, um einen Wurm zu platzieren, der sich selbstst\u00e4ndig auf Twitter verbreitete. Erste Wurm-Codes tauchten auf und eine Demo erlaubte einen Test: dabei \u00f6ffnete sich ein Popup mit Datenschnipseln des Cookies. Farbfl\u00e4chen tauchten in Tweets auf, die zum Beispiel automatisierte Retweets ausl\u00f6sten. Das Deaktivieren von JavaScript sch\u00fctzte vor dem Angriff.<\/p>\n

Twitter schaltete die Timeline \u00f6ffentlicher 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<\/a>.<\/p>\n

Platz 8: fataler Verschl\u00fcsselungsfehler in iOS und OS X<\/h3>\n

Er ging als „goto fail“ in die Sicherheitsgeschichte ein: der fatale Verschl\u00fcsselungsfehler, der im Februar 2014 Apples Betriebssysteme unsicher werden lie\u00df. Der Fehler steckte ausgerechnet in der Funktion, die sicherstellen soll, dass die Schl\u00fcssel, die f\u00fcr gesicherte Verbindungen angefordert werden, definitiv von der korrekten Gegenseite stammen. Diese Pr\u00fcfung entfiel durch den Fehler und jeder erdenkliche Schl\u00fcssel wurde einfach akzeptiert.<\/p>\n

In der Praxis hie\u00df 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\u00fcsselt, jedoch merkten die Apple-Devices nicht, dass Schl\u00fcssel und Website nicht zueinander passten.<\/p>\n

Apple reagierte mit einem Update<\/a>, forderte Nutzer dazu auf, dieses sofort einzuspielen und in \u00f6ffentlichen Netzen nicht mehr auf HTTPS-Verbindungen zu vertrauen oder gar Passw\u00f6rter einzugeben, bis das Update eingespielt ist. So weit, so gut, allerdings nur f\u00fcr iOS-Nutzer. OS X-Anwender mussten l\u00e4nger auf ein Update warten<\/a>. Wie lange der Fehler, den Adam Langley als Google-Mitarbeiter in seinem Blog beschrieb<\/a>, bereits existierte, ist unklar.<\/p>\n

Betroffen war Apples SSL-Quellcode: hier erm\u00f6glichte eine \u00fcberfl\u00fcssige 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 \u2013 und als es endlich soweit war, stellten sich diverse Fehler und Ungereimtheiten<\/a> heraus. Apple stand stark in der Kritik: anstatt mit dem Patchen bis zum n\u00e4chsten Gro\u00dfupdate zu warten, h\u00e4tten es viele lieber gesehen, h\u00e4tte der Konzern ein Notfall-Update herausgebracht.<\/p>\n

Platz 7: Bug aus den 80ern sp\u00e4hte in 2015<\/h3>\n

Die Sicherheitsl\u00fccke „Factoring attack on RSA-Export Keys“, besser bekannt als Freak, erlaubte es Angreifern, Internetverbindungen abzuh\u00f6ren und sensible Daten zu erbeuten. Die Schwachstelle fand ihren Ursprung in den 80er Jahren: US-Unternehmen war es per Gesetz untersagt, starke Verschl\u00fcsselungstechniken im Ausland zu ver\u00e4u\u00dfern. So entschloss man sich, eine abgeschw\u00e4chte Export-Version zu schaffen. Die Schl\u00fcssel wurden auf 512 Bit gek\u00fcrzt, sodass sie ziemlich leicht zu knacken waren. Eine gesetzliche Hintert\u00fcr entstand, deren Ausw\u00fcchse wir im Jahre 2015 kennenlernen sollten.<\/p>\n

Und diese Ausw\u00fcchse hatten es in sich: nicht nur Googles Standard-Android-Browser und Apples Safari waren betroffen, sondern auch s\u00e4mtliche Windows-Versionen erlaubten es, Freak auszunutzen. Updates brachten nicht den gew\u00fcnschten Erfolg, sondern legten Windows Update lahm und sorgten daf\u00fcr, dass diverse HTTPS-Websites nicht mehr erreichbar waren. Alle Hintergr\u00fcnde dieser katastrophalen Sicherheitsl\u00fccke lesen Sie bitte in unserem Beitrag „Freak: Sicherheitsl\u00fccke zielt auch auf Windows-User ab“<\/a> nach.<\/p>\n

Platz 6: Sony reagiert z\u00f6gerlich auf SQL-Injection-L\u00fccke<\/h3>\n

Schon in unserer Hacker-Serie war Sony fester Bestandteil. Wenig verwunderlich, dass die SQL-Injection-L\u00fccke, die Zugriff auf die sensiblen Kundendaten im Playstation Network gestattete, zu unseren katastrophalsten Sicherheitsl\u00fccken z\u00e4hlt. Der IT-Sicherheitsexperte Aria Akhavan entdeckte die Sicherheitsl\u00fccke und informierte Sony. Der Konzern jedoch reagierte nicht, bis zwei Wochen sp\u00e4ter die Medien auf die L\u00fccke aufmerksam wurden. Die L\u00fccke war verheerend: \u00fcber 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.<\/p>\n

Dass es Sony mit seiner Sicherheitspolitik mehrfach in die SQLI Hall of Shame<\/a> geschafft hat, erscheint wenig verwunderlich. Wohl am heftigsten war jedoch, dass sich Sony elegant ausschwieg<\/a>\u00a0und einfach nicht reagierte: weder Heise noch der Spiegel oder andere Magazine erhielten Auskunft \u2013 Anfragen blieben einfach wochenlang liegen, ebenso die Sicherheitsl\u00fccke, bei der der Umfang des Zugriffs auf die Userdaten unbekannt war. Dies h\u00e4tte einer Kl\u00e4rung bedurft, die jedoch seitens Sony ausblieb.<\/p>\n

Die 10 katastrophalsten Sicherheitsl\u00fccken: Pl\u00e4tze 5 \u2013 1<\/h3>\n

Freuen Sie sich auf die Pl\u00e4tze 5 bis 1 der katastrophalsten Sicherheitsl\u00fccken in der kommenden Woche! In der Zwischenzeit k\u00f6nnen Sie uns gerne mitteilen, welche Sicherheitsl\u00fccke Sie ersch\u00fcttert hat. Kommen Sie mit uns ins Gespr\u00e4ch: hier in den Kommentaren, auf Facebook<\/a>, Google Plus<\/a> oder Twitter<\/a>!<\/p>\n