Vom Umgang mit Sicherheitslücken

Inhaltsverzeichnis

Was macht man eigentlich, wenn man eine gravierende Sicherheitslücke in einem von vielen Menschen genutzten Programm oder Gerät entdeckt? Der ganzen Welt davon zu erzählen, scheint da im ersten Moment eine denkbar schlechte Idee. Schließlich warten Cyber-Kriminelle doch nur auf solche Gelegenheiten. Trotzdem ist das in bestimmten Situationen sehr sinnvoll.

Um die heute übliche Vorgehensweise beim Umgang mit Sicherheitslücken besser zu verstehen, lohnt ein kleiner Abstecher in die Geschichte der Security. Die Rede ist vom finsteren Mittelalter der Computerei, das bis in die 90er-Jahre reichte. Damals war IT-Security eine arkane Geheimwissenschaft, die nur erleuchtete Magier beherrschten. Die tauschten sich in weitgehend geschlossenen Communitys aus; öffentliche Informationen zum Thema gab es kaum.

Security damals im Wesentlichen ein unnötiger Kostenfaktor

Es war die Zeit, in der das Internet die Welt eroberte und Microsoft plötzlich entdeckte, dass man da eine überaus wichtige Entwicklung fast verschlafen hätte. In Windows 95 wurde TCP/IP eingebaut und plötzlich waren viele tausende Systeme vernetzt, die darauf eigentlich gar nicht richtig vorbereitet waren.

Microsoft und eigentlich fast alle Hersteller von Hard- und Software betrachteten Security damals im Wesentlichen als einen unnötigen Kostenfaktor und ansonsten hauptsächlich als ein Kommunikationsproblem. Natürlich gab es es auch damals Sicherheitslücken – doch darüber sprach man nicht. Wer versuchte, einen Hersteller auf ein Security-Problem seiner Produkte aufmerksam zu machen, musste mit heftigen Reaktionen rechnen. Einschüchterungsversuche durch Firmenanwälte bis hin zu Klagen mit nachfolgenden Gerichtsverfahren waren eher die Regel als die Ausnahme.

Security-Updates oder Patches gab es quasi nicht. Und wenn doch, dann vergammelten sie in irgendeiner möglichst verborgenen Ecke. Denn ein systematischer Weg, die Systeme zu aktualisieren, war nicht vorgesehen und öffentliche Hinweise auf Sicherheitslücken waren tabu – die könnte ja jemand ausnutzen. Das war jedenfalls die offizielle Begründung. Tatsächlich ging es jedoch vor allem darum, dass die Firmen das ganze Thema Security am liebsten totschweigen wollten.

Der erste Wurm

Die Folge waren weltweit vernetzte Systeme mit horrenden Sicherheitslücken, die teilweise trivial auszunutzen waren, wenn man nur wusste wie. Der erste Computer-Wurm im Internet beruhte auf einem Sicherheitsproblem, das bereits seit mehreren Jahren bekannt war.

Aufgrund eines fehlerhaften Passwort-Checks genügte es, dem Mail-Dienst Sendmail das Kommando wiz zu schicken, damit dieser antwortete

200 Please pass, oh mighty wizard

und dem Anfragenden volle Root-Rechte auf dem System verlieh. Das nutzte am 2. November 1988 der Morris-Wurm aus und infizierte innerhalb weniger Stunden über 6000 Systeme, was damals einen signifikanten Teil des gesamten Internet ausmachte. In der Folge wurden Sendmail-Sicherheitseinstellungen in diesem Punkt etwas verbessert. Doch ansonsten ging es weiter wie bisher.

Erst Anfang der 90er kam es zu einem wichtigen Umschwung und die Security-Community öffnete sich. Der treibende Gedanke dabei war: Sowohl Security-Konzepte als auch deren Schwächen müssen endlich offen diskutiert werden, damit Security besser wird. Len Rose, einer der Gründer der Mailing-Liste Full Disclosure, brachte die Dringlichkeit seines Anliegens auf den Punkt:

„Wir glauben nicht an Security durch Unverständlichkeit (security by obscurity). Und soweit wir wissen, ist vollständige Offenlegung (full disclosure) der einzige Weg, sicherzustellen, dass nicht nur Insider, sondern jedermann Zugang zu den überlebenswichtigen Informationen hat.“

Bugtraq und Full Disclosure

Dazu tauschte sich die Security-Community über die moderierte Mailing-Liste Bugtraq und im offenen Full Disclosure aus. Dort nahm man kein Blatt mehr vor den Mund: So gab es alle Infos zu konkreten Sicherheitslücken – und zwar sofort. Häufig inklusive voll funktionsfähiger Demos und unabhängig von der Verfügbarkeit von Updates. Oft sogar ohne dass der Hersteller zuvor benachrichtigt wurde.

Es war die wilde Zeit der Zero Days – kurz 0days, gesprochen o-days – die zum Status-Objekt der Szene wurden. Wer etwas auf sich hielt, hatte ein gut gefülltes Reservoir an privaten 0days und ließ seine Fans großzügig daran teilhaben. Allein auf Bugtraq und Full Disclosure wurden hunderte solcher 0days veröffentlicht. Lücken im Internet Explorer, über die man Windows-Rechner kapern konnte, wurden da teilweise im Wochentakt offengelegt.

Das Erstaunliche daran: Full Disclosure funktionierte tatsächlich. Immer mehr Leute interessierten sich für das Thema. Durch die öffentlich verfügbaren Informationen fanden sie einen schnellen Einstieg. Und die Qualität des öffentlich verfügbaren Security-Know-hows nahm ebenfalls zu.

Eines der berühmtesten Beispiele dafür ist der Artikel „Smashing the Stack for Fun and Profit“. Darin erklärte der Bugtraq-Moderator mit den Handle Aleph One erstmals en détail einer großen Öffentlichkeit, wie man einen Puffer-Überlauf ausnutzen kann, um beliebigen, eigenen Code in ein System einzuschleusen und auszuführen. Nicht nur abstrakt und theoretisch, sondern ganz konkret mit Code und Beispielen.

Das Standardwerk zum professionellen Ausnutzen eines Pufferüberlaufs auf dem Stack erschien im Hackermagazin Phrack.

Solche Pufferüberläufe waren eine Seuche. Gefühlt jedes zweite Programm wies diese Schwachstellen auf – und fast immer konnte man sie ausnutzen, um mit einem passenden Exploit das System zu übernehmen, auf dem es ausgeführt wurde. In der Folge gab es hunderte Demo-Exploits für verschiedenste Programme, die mit Aleph Ones Stack-Smashing-Rezepten zusammengebraut waren.

Doch letztlich war diese Veröffentlichung und die folgende Katharsis wohl notwendig dafür, dass diese Kategorie von Sicherheitslücken auf modernen PCs heute keine große Rolle mehr spielt. Dies wurde nur erreicht durch eine bis dahin nie gesehene Anstrengung der Hersteller von Hard- und Software.

Blaster erschüttert die Welt

Die öffentliche Diskussion über Sicherheitslücken hatte nämlich durchaus auch die befürchteten negativen Konsequenzen in Form von Katastrophen in bis dahin unerreichtem Ausmaß. So fand die schillernde Hackergruppe Last Stage of Delirium (man beachte die Initialen!) 2003 eine Lücke im RPC-Dienst von Windows, die sich übers Netz ausnutzen ließ. Millionen von PCs waren anfällig.

Zwar veröffentlichte Microsoft am 16. Juli 2003 das Microsoft Security Bulletin MS03-026 „Critical Buffer Overrun In RPC Interface Could Allow Code Execution“ und stellte Sicherheits-Updates für Windows NT 4.0, XP, 2000 und Server 2003 bereit. Doch die installierte nur ein kleiner Teil der Windows-Nutzer. Parallel bastelte die Security-Comunity gemeinsam in Full Disclosure an immer besseren Exploits.

Und am 11. August 2003 war es dann so weit: Der Blaster-Wurm raste innerhalb weniger Stunden rund um die Welt und infizierte über die RPC-Lücke in wenigen Tagen weit über eine Million PCs. Ein gewisser „ju“ forderte damals übrigens auf heise online in seinem Kommentar „Lehren aus ‚Einmal Wurm mit Ansagen’“ bessere Update-Funktionen für Windows.

Doch wir hatten noch einmal Glück im Unglück. Denn der Blaster-Wurm hatte keine echte Schadfunktion. Den eingebauten Denial-of-Service-Angriff auf die Windows-Update-Server ließ Microsoft weitgehend ins Leere laufen. Das Schlimmste, was die meisten Windows-Nutzer von Blaster mitbekamen, war, dass ihr Rechner schon Minuten nach dem Aufbau einer Internet-Verbindung abstürzte, was auf einen Fehler im Wurm zurückzuführen war. Eingebettet im Code des Blaster-Wurms fand sich eine Botschaft an den damaligen Microsoft-Chef:

billy gates why do you make this
possible? Stop making money and
fix your software!!

Und man mag es kaum glauben, aber diese Botschaft fand tatsächlich ein offenes Ohr. Denn genau dieser Bill Gates hatte erst kurz zuvor eine Erleuchtung, an der er mit einer E-Mail alle Microsoft-Mitarbeiter teilhaben ließ. Ihre zentrale Botschaft war: „Trustworthy Computing is the highest priority for all the work we are doing“ – Security sollte plötzlich die Grundlage für alles sein.

Damals zweifelten viele Security-Experten wie auch der Autor dieses Artikels, ob das nicht nur ein weiterer PR-Schachzug war. Doch die weitere Geschichte zeigte: Es war Gates voller Ernst. Er krempelte seinen Multi-Milliarden-Dollar-Konzern auf allen Ebenen sehr gründlich um.

Der Wandel

Damit keine Missverständisse aufkommen: Das war keine plötzlich entdeckte Liebe für das Thema Security, sondern eine unternehmerische Entscheidung, die den drohenden Niedergang des Windows-Imperiums abwenden sollte. Denn dessen Sicherheitsprobleme und deren Konsequenzen hatten unterdessen ein Ausmaß angenommen, dass man sie unter keinen noch so großen Teppich mehr kehren konnte. Endanwender, Firmen und sogar ganze Staaten drohten, sich von Microsoft abzuwenden.

Und Microsoft war dabei keineswegs allein. Die komplette IT-Branche geriet unter Beschuss und orientierte sich in den 2000er-Jahren in Sachen Security neu: Hersteller begriffen, dass sie Security tatsächlich brauchten. Es gab vermehrt Security-Updates, die auch tatsächlich beim betroffenen System ankamen. Software wurde plötzlich im Rahmen eines Security Development Lifecycles (SDL) geplant, entwickelt und bis zum geplanten End-of-Life weiter gepflegt.

Im Zuge dieser Umorientierung suchte man auch die aktive Zusammenarbeit mit der Security-Szene. Plötzlich waren die früheren Outlaws gesuchte Experten, von denen es schon bald nicht mehr genug gab. Der Autor erinnert sich noch an einen Besuch auf dem Microsoft-Campus in Redmond (dessen Kosten Microsoft übrigens übernahm), bei dem man ihm fast schon stolz zwei Microsoft-Mitarbeiter als Gründungsmitglieder der Hackergruppe LSD vorstellte. Statt im Untergrund 0days zu erforschen, halfen sie jetzt dem Windows-Kernel-Team, die Sicherheit konzeptionell zu verbessern.

Aber bitte verantwortungsbewusst

Eher notgedrungen akzeptierte man auch das Veröffentlichen von konkreten Informationen zu Sicherheitsproblemen als wichtigen Bestandteil dieses Prozesses. Aber natürlich nicht mehr so ungezügelt wie in den wilden Full-Disclosure-Zeiten, sondern am besten nach den eigenen Spielregeln. Der erste Anlauf dafür war Microsofts Konzept einer „Responsible Disclosure“, die einen verantwortungsbewussten Umgang mit diesen sensiblen Informationen einforderte.

Der wichtigste Punkt einer solchen Responsible Discloure war, dass man den Hersteller als ersten über Sicherheitsprobleme informiert. Diesem sollte man dann ausreichend Zeit einräumen, ein Security-Update zu erstellen. Erst wenn dieses verfügbar ist, veröffentlichen Hersteller und Finder konkrete Informationen zu diesem Problem. Nur wenn ein Hersteller innerhalb eines bestimmten Zeitraums nicht angemessen reagiert, darf der Entdecker mit seinen Informationen auch einseitig an die Öffentlichkeit gehen. Die Fristen variieren dabei von einigen Wochen bis zu mehreren Monaten.

Die Security-Szene beäugte „Responsible Disclosure“ von Anfang an eher skeptisch. Die unausgesprochene Botschaft war: „Wer sich nicht an unsere Spielregeln hält, handelt verantwortungslos.“ Und diesen Schuh wollte man sich nicht ausgerechnet von einem Konzern anziehen lassen, der über viele Jahre bei der Security ganz ohne Gewissensbisse maßlos geschlampt hatte.

Von "Responsible Disclosure" zu "Coordinated Disclosure"

Überhaupt ging es bei Responsible Disclosure sehr viel um die Pflichten der Hacker und eher wenig um die der Hersteller. Das spiegelte sich dann auch in der konkreten Praxis wider, in der Hersteller Responsible Disclosure immer wieder benutzten, um Sicherheitslücken herunterzuspielen oder auszusitzen.

Ein typisches Spiel, das auch der Autor mehrfach miterlebt hat, war, von dem Entdecker einer Lücke einen voll funktionsfähigen Exploit zu verlangen, bevor man den Fund als relevantes Sicherheitsproblem akzeptierte. Ein solcher Exploit erforderte oft Tage oder sogar Wochen zusätzlicher Arbeit. Andererseits verbat man sich ein einfaches Veröffentlichen des Sachverhalts als „unverantwortlich“.

Mittlerweile hat sich unter anderem deshalb eine andere Policy durchgesetzt: Bei der sogenannten „Coordinated Disclosure“ steht die partnerschaftliche Zusammenarbeit von Entdecker und Hersteller im Vordergrund. Diese orientiert sich an drei zentralen Zielen:

1. Schaden zu minimieren,
2. die Lücke zu beseitigen,
3. andere am Erkenntnisgewinn teilhaben zu lassen.

Unter anderem das Bundesamt für Sicherheit in der Informationstechnik (BSI) und die europäische Sicherheitsbehörde ENISA empfehlen Coordinated Disclosure als Vorgehensweise zum Umgang mit Sicherheitslücken.

Das liebe Geld

Der Elefant im Raum war das Thema Geld. Die Übergabe der Informationen, die erforderliche Arbeit zum Nachweis der Relevanz des Problems – all das hatte selbstredend unentgeltlich zu erfolgen. Doch damit wollten sich einige Hacker nicht mehr abfinden. 2009 starteten Alex Sotirov, Dino Dai Zovi und Charlie Miller ihre Kampagne „No more free bugs“. Die Zeit, in der Softwarehersteller von der kostenlosen Arbeit der Security-Comunity profitierten, sei vorbei, argumentierten die drei Rockstars der Security-Szene. Hersteller sollten ihre Arbeit gefälligst entlohnen.

Tatsächlich entwickelte sich ein Markt, auf dem Sicherheitslücken beziehungsweise die Informationen, wie man sie ausnutzen kann, einen ganz realen Wert darstellten. Da waren zunächst die Bug-Broker wie die Zero Day Initiative (ZDI), die Zero-Day-Lücken aufkaufen. Für voll funktionsfähige, exklusive Exploits in populären Programmen zahlen sie dem Entdecker bis zu 100.000 US-Dollar.

Dann melden sie die Lücken beim Hersteller, damit dieser einen Patch entwickeln und bereitstellen kann. Erst danach wird die Lücke veröffentlicht – entweder durch den Broker oder den Finder. Das Geschäftsmodell der Bug-Broker beruht darauf, dass die Mutterfirma – bei ZDI also früher HP, jetzt Trend Micro – Security-Software oder -Hardware verkauft, die auf quasi magische Weise auch vor Zero-Day-Lücken schützen kann.

Das Problem dabei war, dass die Bug-Broker kein wirkliches Interesse daran hatten, dass die Lücken tatsächlich geschlossen wurden. Im Gegenteil: Je länger sich der Hersteller mit dem Fixen einer kritischen Lücke Zeit ließ, desto länger war der Zeitraum, in dem der einzige Schutz das Kaufen der Security-Produkte war. So räumte ZDI etwa Microsoft schon auch einmal über zwei Jahre ein, um eine kritische Lücke in einer Office-Komponente zu schließen.

Horrende Schwarzmarkt-Preise

Parallel dazu gab und gibt es immer noch einen blühenden Schwarzmarkt für Sicherheitslücken. Firmen wie Exodus Intelligence, Revuln, Vupen und Zerodium kaufen Bugs auf, um daraus voll funktionsfähige Cyberwaffen zu bauen. Die verkaufen sie dann an Geheimdienste, Militärs und Polizei weiter. Wenn etwa das BKA seinen Staatstrojaner übers Netz auf dem Laptop eines Terrorverdächtigen platzieren wollte, würde es die dafür notwendigen Exploits ziemlich sicher dort einkaufen.

Zerodium zahlt Preise von über einer Million US-Dollar für einen iOS-Jailbreak oder für Exploits in Tor-Browser/Tails. Da gehen dann natürlich keine Infos an den Hersteller – die würden die wertvolle Ware schließlich nur kaputt machen, indem sie die Sicherheitslücke beseitigen. Und das wäre nicht im Sinne von Zerodium und dessen Kunden. Letztere müssen sich sogar vertraglich verpflichten, die eingekauften oder gemieteten Tools nicht an Dritte und somit insbesondere nicht an den Hersteller der betroffenen Software weiterzugeben.

Doch auch an den Softwareherstellern ging „No more free bugs“ nicht ungehört vorbei. Immer mehr Firmen bieten selbst Belohnungen für das Melden von Sicherheitslücken. Google, Mozilla, Facebook, Paypal und mittlerweile sogar Microsoft, das sich lange gesträubt hatte, bieten eigene Bug-Bounty-Programme, in denen sie Prämien für das Melden von Sicherheitslücken anbieten.

Viele Firmen nutzen für ihre Bug-Bounty-Programme auch Plattformen wie Bugcrowd und Hackerone. Die verstehen sich als Vermittler zwischen Firmen und Hackern, die Spaß daran haben, Sicherheitslücken aufzudecken, aber gerne damit auch Geld verdienen möchten. Den Hackern versprechen sie Unterstützung bei der Disclosure und insbesondere, dass sie weiterhin ihren Spaß haben können, ohne negative Reaktionen der Hersteller befürchten zu müssen.

Den Firmen helfen die Plattformbetreiber dabei, eigene Disclosure-Policies und Bug-Bounty-Programme aufzusetzen. Und sie werben damit, dass man mit ihrer Hilfe die „Crowd“ sogar für gezielte Sicherheitstests nutzen könne. Denn die früher oft geschmähten und gefürchteten Hacker sind heute respektierte Fachkräfte, nach denen viele Firmen verzweifelt suchen. Und nach wie vor spielt Disclosure – also das Offenlegen von Sicherheitslücken – eine zentrale Rolle.

---

heise Security als Vermittler

In Fällen von öffentlichem Interesse bietet heise Security an, als Vermittler bei der Kommunikation mit Herstellern aufzutreten. Wir haben dabei im Laufe der Jahre einiges an Erfahrung gesammelt und viele Ansprechpartner, die uns in diesem Kontext bereits kennen.

Der scheinbare Umweg über Heise hat für den Entdecker einer Schwachstelle den Vorteil, dass er auf Wunsch zunächst anonym bleiben kann und erst später entscheidet, ob er in diesem Kontext persönlich in Erscheinung treten will. Wir haben die Möglichkeit, unsere Informanten auch dauerhaft anonym zu halten.

Selbstverständlich diskutieren wir auch eventuelle rechtliche Konsequenzen mit den Meldern von Sicherheitslücken. Und schließlich bekommen bei vielen Herstellern Dinge oftmals noch eine etwas höhere Dringlichkeit, wenn sie von Heise angesprochen werden.

Für uns steht das Vermeiden von Schaden für Dritte im Vordergrund. Dazu pflegen wir eine Vorgehensweise der Coordinated Disclosure, die dem Hersteller einen angemessenen Zeitraum zur Beseitigung von Sicherheitslücken einräumt. Im Normalfall berichten wir – in enger Abstimmung mit dem Melder – erst nachdem der Hersteller Updates ausgerollt hat, die die Gefahr bannen.

Als Anlaufstelle kann der Redakteur des Vertrauens, die Mailadresse der heise-Security-Redaktion (red@heisec.de) oder ganz anonym der Online-Briefkasten des heise-Investigativ-Teams dienen.

---

Mehr Infos

Disclosure für Hersteller

Wer Dienste anbietet oder Soft-/Hardware entwickelt, muss davon ausgehen, dass seine Produkte Sicherheitslücken aufweisen. Und früher oder später werden auch Externe welche darin entdecken. Machen Sie es Ihnen so leicht wie möglich, diese bei Ihnen zu melden. Letztlich profitieren Sie davon, dass Ihr Produkt danach sicherer ist. Die wichtigsten Tipps dazu in Form einer Checkliste:

Planen

Bereiten Sie sich auf den Eingang von Berichten zu Sicherheitsproblemen vor. Legen Sie Regeln fest, wie Sie damit umgehen wollen. Das Modell der Coordinated Disclosure beschreibt den Stand der Technik. Legen Sie fest, wer für die Betreuung und Kommunikation zuständig ist und wie das Ganze in etwa ablaufen soll. Auch ein realistischer zeitlicher Rahmen, innerhalb dem man Sicherheitsprobleme fixen will, sollte zumindest intern schon mal diskutiert worden sein.

Meldestelle einrichten

Machen Sie das Melden so leicht wie möglich. Bieten Sie klare Anlaufstellen, um Sicherheitsprobleme zu melden. Eine E-Mail-Adresse wie "security@firma.de" und eine Web-Seite wie "https://www.firma.de/security" mit einem Formular zur Kontaktaufnahme haben sich bewährt. Machen Sie deutlich, dass Sie das Melden von Sicherheitslücken begrüßen und aktiv unterstützen. Am besten stellen Sie dort auch bereits Ihre Policy für den Umgang mit Sicherheitslücken vor, damit der Melder sich ein Bild machen kann, auf was er sich einlässt.

Kommunikation

Gute Kommunikation mit dem Entdecker ist das A & O für Coordinated Disclosure. Seien Sie möglichst offen und lassen Sie keinen Frust aufkommen. Bestätigen Sie den Eingang der Meldung zu einer Schwachstelle möglichst zeitnah und geben Sie dem Melder dann regelmäßig Feedback über Fortschritte und angepeilte Termine. Vermeiden Sie alles, was als Drohung wahrgenommen werden könnte.

Bug Bounties

sind oft der Einstieg in die Überlegungen rund um Disclosure. Dabei sind sie eigentlich der letzte Punkt auf der To-do-Liste, nachdem die oben aufgeführten abgearbeitet sind. Überlegen Sie, ob Sie Prämien auf das Melden von Schwachstellen ausschreiben wollen und können. Auch wenn eine finanzielle Honorierung der erbrachten Leistung (noch) nicht möglich ist, kann man über ein nacktes „Danke“ hinausgehen. Die meisten Melder von Sicherheitslücken freuen sich über jedes Zeichen der Anerkennung – sei es ein T-Shirt, eine Tasse oder das Angebot einer Spende in seinem Namen.

Dieser Artikel stammt aus c't 21/2019. (ju)