Google: Hersteller machen es Hackern zu leicht

Inhaltsverzeichnis

Im Dezember 2018 entdeckten Forscher von Google eine Gruppe von Hackern, die ihr Augenmerk auf den Internet Explorer von Microsoft gerichtet hatten. Obwohl der Konzern mittlerweile voll auf die Neuentwicklung Edge setzt, bleibt der IE auf Abermillionen wenn nicht gar Milliarden Computern aktiv. Die Hacker suchten (und fanden) zuvor unbekannte Fehler, also Zero-day-Schwachstellen. Exploits machten die Runde. Microsoft veröffentlichte Patches und besserte die Fehler aus – jedenfalls gewissermaßen. Im September 2019 wurde entdeckt, wie eine vergleichbare Schwachstelle von derselben Hacker-Gruppe erneut ausgenutzt wurde.

Weitere Entdeckungen folgten im November 2019, Januar 2020, und im April 2020 – am Ende wurden mindestens fünf Zero-Day-Schwachstellen im IE ausgebeutet, alle aus derselben Fehlergruppe und in kurzer Zeitabfolge. Microsoft veröffentlichte vielfache Sicherheitsupdates: Bei manchen gelang es nicht, die eigentliche vulnerable Stelle, die angegriffen wurde, zu reparieren. Doch andere Patches setzten nur geringfügige Änderungen um, die den Hackern letztlich kaum mehr abverlangten, als ein oder zwei Zeilen im Code zu ändern, um den Exploit fortzusetzen.

Diese Geschichte ist bezeichnend für ein sehr viel größeres Problem in der Cybersecurity. Davon geht auch Maddie Stone aus, Sicherheitsforscherin bei Google. Es sei viel zu einfach für Hacker, einmal vorhandene Zero-Days auf neue Arten auszubeuten, denn Firmen würden schlichtweg keinen guten Job machen, ihre Fehler und Schlupflöcher kontinuierlich zu beheben. Die Forschung von Stone, die Teil des Google-Sicherheitsteams Project Zero ist, hebt mehrere praktische Beispiele hervor, darunter auch Probleme, die Google selbst mit seinem beliebten Chrome Browser hatte.

Tiefhängende Früchte

"Was wir gesehen haben, zieht sich so durch die gesamte Industrie: Unvollständige Patches machen es Angreifern sehr einfach, Nutzer mit Zero-Days anzugreifen", sagte Stone Anfang Februar bei der Sicherheitskonferenz Enigma. "Wir setzen dabei nicht voraus, dass Angreifer neue Fehlerklassen entwickeln oder neue Formen des Missbrauchs. Sie müssen sich keinen Code anschauen, der vorher nie erforscht wurde. Wir erlauben ihnen die Wiedernutzung verschiedener Schwachstellen, von denen wir vorab schon wussten."

Project Zero_blank arbeitet innerhalb von Google als einzigartiges und manchmal auch intern durchaus kontroverses Team, das sich komplett der Jagd auf diese enigmatischen Zero-Day-Fehler verschrieben hat. Diese Bugs sind von Hackern aller Art begehrt und werden heute höher geschätzt als je zuvor – nicht unbedingt, weil sie schwerer zu entwickeln sind, sondern weil sie in einer Welt der globalen Vernetzung nochmals mächtiger sind.

In seinem sechsjährigen Bestehen hat das Team von Google mehr als 150 bedeutende Zero-Day-Bugs aufgespürt und publiziert. 2020 dokumentierten Stone und ihre Kollegen 24 Zero-Days, die ausgenutzt wurden – ein Viertel davon ähnelten den zuvor entdeckten Schwachstellen stark. Drei von ihnen waren nur dürftig geflickt, was bedeutet, dass es nur ein paar Ausbesserungen am Hacker-Code bedurfte, damit er weiter funktionieren würde. Viele dieser Attacken, so Stone, involvieren grundlegende Fehler, es seien "tiefhängende Früchte". Anders gesagt: Es ist verführerisch einfach, zuzupacken. Für Hacker sei das "nicht schwer", sagt Stone. "Sobald sie nur einen dieser Fehler verstehen, können Sie einfach ein paar Zeilen ändern und weiterhin mit funktionierenden Zero-Days arbeiten."

Gleiches Problem eine Zeile weiter

Warum also werden die Bugs nicht ausreichend repariert? Die meisten Mitarbeiter der Sicherheitsteams in Software-Firmen haben nur wenig Zeit und Ressourcen, erklärt Stone – und wenn ihre Prioritäten und Anreize nicht richtig sind, überprüfen sie nur, ob sie die spezifische Schwachstelle vor ihren Augen repariert haben. So wird das größere Problem an der Wurzel vieler Schwachstellen übergangen.

Andere Forscher bestätigen, dass es sich um ein landläufiges Problem handelt. "Im schlimmsten Fall war es so, dass ein paar von mir entdeckte Zero-Days ein Problem hatten, das vom Anbieter behoben wurde – und buchstäblich in der nächsten Codezeile befand sich noch immer genau dieselbe Art von Sicherheitslücke und es wurde sich nicht die Mühe gemacht, sie zu reparieren", sagt John Simpson, Forscher bei der Cybersecurity-Firma Trend Micro. "Wir können alle so lang quatschen bis wir blau im Gesicht werden, aber wenn Unternehmen nicht die richtige Struktur haben, um mehr zu tun als einfach nur einen gemeldeten Bug zu reparieren, dann kommt es zu einer solchen Patch-Qualität."

Damit sich das ändert, wird es Zeit und Geld brauchen: Entwicklern müssten länger dafür eingeräumt werden, neue Sicherheitslücken zu untersuchen, den Ursprung dafür zu suchen und Fehler tiefgehender zu beheben, die oft unter spezifischen Anfälligkeiten liegen. Sie könnten auch eine Variantenanalyse durchführen, meint Stone: Also denselben Fehler an verschiedenen Orten auffinden oder verschiedene Schwachstellen im selben Code-Block.

Ein Türsteher für iMessage

Manche versuchen sich bereits an anderen Ansätzen. Apple hat es beispielsweise geschafft, einige der schwerwiegendsten Sicherheitsrisiken des iPhones zu beheben, indem Lücken auf tiefer Ebene beseitigt wurden. Eine andere Project-Zero-Forscherin bei Google, Natalie Silvanovich, machte im Jahr 2019 Schlagzeilen, als sie auf kritische "Zero-Click-Zero-Day"-Fehler in Apples iMessage aufmerksam machte.

Diese Fehler ermöglichten es einem Angreifer, das gesamte Telefon einer Person zu übernehmen und zwar ohne dass das Opfer dafür irgendetwas tun musste. Es brauchte also nicht mal den Klick auf einen Link, damit das iPhone von Hackern kontrolliert werden konnte. (Im Dezember 2020 entdeckten weitere Untersuchungen eine Hacking-Kampagne gegen Journalisten, die ebenso von Zero-Click-Zero-Day-Angriffen bei iMessage betroffen waren.)

Anstatt die spezifischen Schwachstellen nur oberflächlich zu polieren, ging das Unternemen in die Tiefen bei iMessage, um grundlegende Probleme anzugehen, die von Hackern ausgenutzt wurden: Code wird besser isoliert. Apple hat sich zwar nie speziell über diese Änderungen geäußert, doch Samuel Groß vom Project Zero konnte nach seinen Analysen ableiten, was bei iOS und iMessage tatsächlich geschehen war. Die App ist jetzt mit einer Funktion namens "BlastDoor" vom Rest des Geräts besser getrennt. Die neue Entwicklersprache Swift erschwere Hackern zudem den Zugriff auf den von iMessage verwendeten Speicherbereich.

"Investieren, investieren, investieren"

Auch die Architektur von iOS wurde von Apple geändert, sodass es schwieriger geworden ist, Zugang auf den freigegebenen Cache des Telefons zu bekommen – genau das ist nämlich bei den bekanntesten iPhone-Hacks der letzten Jahre geschehen. Somit hat Apple es verhindern können, dass Hacker immer wieder in kürzester Zeit sogenannte Brute-Force-Angriffe ausführen. Neue Drosselungsfunktionen verlängern Exploits-Varianten – was möglicherweise einmal Minuten gedauert hat, braucht jetzt Stunden oder Tage. Für Hacker wird der Angriff weniger attraktiv.

"Es ist großartig zu sehen, dass Apple die Ressourcen für dieses Ausmaß an Umgestaltungen zur Hand nimmt, um die Nutzersicherheit zu erhöhen", schreibt Groß. "Diese Änderungen heben auch den Wert offensiver Sicherheitsarbeit hervor: Nicht nur wurden einzelne Fehler repariert, sondern es wurden auch strukturelle Verbesserungen erreicht, die auf Erkenntnisse aus der Exploit-Entwicklungsarbeit zurückzuführen sind." Böswillige Angreifer werden immer größere Schwierigkeiten bekommen, wenn Tech-Firmen sich stärker miteinander vernetzen. Das bedeutet auch, dass es für Technologieunternehmen wichtiger denn je wird, in bedeutende Probleme der Cybersicherheit, die ganze Gruppen von Schwachstellen und Exploits verursachen, zu investieren und daraus eine Priorität zu machen.

"Ein Ratschlag für die Unternehmensführung lautet: Investieren, investieren, investieren", erklärt Stone. "Den Entwicklern muss Zeit gegeben werden, um die Hauptursachen für Schwachstellen zu finden – und passende Patches zu entwickeln." Sie brauchten den Spielraum für Analysen von Varianten von Lücken. Und diese Arbeit sollte ausreichend belohnt werden.

(bsc)