Bug Bounties: Kein Allheilmittel

10.05.2019
G DATA Blog

Bug Bounties sollen einen Anreiz für Forscher schaffen, Sicherheitslücken zu melden. Doch Bug Bounties sind nicht das Allheilmittel, als welches sie oftmals präsentiert werden. Die Möglichkeit, eine Lücke zu melden ist nicht alles – der Umgang mit diesen Meldungen ist das Entscheidende.

Wir haben ein Problem – und jetzt?

Begeben wir uns in ein fiktives Unternehmen, das Software herstellt und vertreibt. Im Support des Unternehmens ruft jemand an und behauptet, eine kritische Sicherheitslücke im Produkt des Herstellers gefunden zu haben. Kontaktdaten sind schnell aufgenommen sowie eine grobe Umschreibung des Problems. Doch an wen geht die Information jetzt? Ans Produktmanagement? Den Geschäftsführer? Den Chefentwickler? Und wenn diese Zuständigkeit geklärt ist, müssen die zuständigen Mitarbeiter den Aufwand für einen Fix abschätzen. Einen Releasetermin verschieben? Das steht außer Frage – die Anzeigen sind bereits gebucht und das Datum ist bereits kommuniziert. Erfordert die Lücke aber komplexe Änderungen in mehreren unterschiedlichen Komponenten der Software, während ein wichtiges Release ins Haus steht, ist guter Rat erst einmal teuer.

Interne Strukturen vs. externer Input

Grundsätzlich ist ein Bug-Bounty-Programm eine gute Idee. Es kann die Sicherheit und Robustheit einer Anwendung oder einer Plattform nachhaltig stärken. Wie in allen Bereichen, in denen es um Sicherheit geht, stellt sich jedoch unausweichlich die Frage nach einem entsprechenden Prozess. Die entscheidenden Fragen sind hier: Wie kann jemand von extern eventuelle Bugs oder Sicherheitslücken melden? Wer bekommt diese Meldungen und wie werden sie priorisiert? Wenn diese und andere Fragen nicht geklärt sind, dann hilft ein Bug Bounty-Programm nicht nur nicht weiter, sondern verursacht Verwirrung.

Viele Unternehmen sind dazu übergegangen, ein Bug-Bounty-Programm an einen externen Dienstleister (z.B. HackerOne) zu geben. Alle Berichte werden über diese Plattform gesammelt, sodass dieser Aufwand für die angeschlossenen Unternehmen entfällt. Damit wird jedoch nur ein Teilaspekt verlagert: Ein Unternehmen, das eine solche externe Plattform nutzt, muss die darüber gesammelten Reports immer noch verarbeiten. Es ist also nicht damit getan, einfach nur eine Seite auf der Homepage zu erstellen und eine Mailbox einzurichten.

„Stelle keine Frage, auf die Du die Antwort nicht hören willst“

Fehlen die darunterliegenden Prozesse und Zuständigkeiten, ist das Unternehmen organisatorisch einfach nicht bereit für ein Bug-Bounty-Programm. Mehr noch: es ist gängige Praxis, eine an einen Hersteller gemeldete Sicherheitslücke nach Verstreichen einer Frist von 90 Tagen öffentlich zu machen. Hat es ein Unternehmen bis zu diesem Zeitpunkt nicht geschafft, eine Lösung oder zumindest einen Workaround bereit zu stellen, ist es jedem möglich, der die Motivation und das Fachwissen hat, die Sicherheitslücke auszunutzen. Dass dies kaum im Sinne der betroffenen Unternehmen ist, versteht sich von selbst.

Chancen und Belohnungen

Ein Negativbeispiel aus der Vergangenheit ist leider Apple: Der iPhone – Hersteller hat eine Woche lang Versuche eines 14-Jährigen ignoriert, eine kritische Sicherheitslücke in Facetime auf iOS zu melden. Einem Interview zufolge hatte er „bis auf Rauchzeichen“ alle ihm zur Verfügung stehenden Kommunikationskanäle ausgeschöpft, allerdings ohne eine Reaktion zu erhalten. Der offizielle Weg im Fall von Apple war zu diesem Zeitpunkt, dass nur Inhaber eines kostenpflichtigen Entwicklerkontos Sicherheitslücken melden können. Ein Entwicklerkonto kostet jährlich 99 Dollar. Hat ein Forscher es nach Überwindung dieser Hürden geschafft, eine Sicherheitslücke zu melden, hat Apple in einigen Fällen auch schon versucht, die Sicherheitslücke mit einer Sperrfrist von 12 Monaten zu belegen, während der Melder sich verpflichtet, diese Lücke nicht anderweitig publik zu machen. Eine mehr als fragwürdige Praxis: 90 Tage sind hier die Regel. Außerdem werden Bug Bounties auch nur für bestimmte Teilbereiche von Apples Diensten gezahlt, wie etwa das Finden von Schwachstellen, die Zugang zum iCloud-Konto ermöglichen oder Jailbreaks auf iPhones möglich machen.

Zumindest im Fall des Facetime-Bugs, der medial hohe Wellen geschlagen hat, zeigte Apple sich im Nachhinein doch noch einsichtig.

Gezielt suchen - aber geschickt

Wer einen zusätzlichen Anreiz schaffen möchte, kann eine Belohnung für das Finden von Sicherheitslücken aussetzen. Zahlreiche Unternehmen tun dies bereits – die Auszahlungen bewegen sich zwischen einigen hundert bis zu über 100.000 Dollar. Microsoft, Facebook oder Google tun dies schon seit Jahren und legen hier besonderes Augenmerk auf einzelne Teilbereiche seiner Produkte und Dienstleistungen.

Einfach nur die Belohnungen zu erhöhen, um mehr Sicherheitslücken zu finden, ist jedoch nicht zielführend. Würden für jede Sicherheitslücke gleich hunderttausende Euro ausgelobt, könnten Entwickler auf die Idee kommen, absichtlich Sicherheitslücken einzubauen und gleichzeitig einen befreundeten Sicherheitsforscher bitten, diese zu „entdecken“, damit sich beide die Bug Bounty teilen können.

Damit tangiert die Problematik noch ein weiteres Feld: zahlt ein Unternehmen Außenstehenden mehr Geld als den eigenen Entwicklern, ist das der Motivation der Mitarbeiter nicht gerade zuträglich.

Bug Bounty: Für wen und für was?

Bug Bounties gibt es sowohl für das Finden von Sicherheitslücken in einer Software oder für das Aufspüren von Schwachstellen in Online-Plattformen. Wer also weder eigene Software vertreibt noch Dienste über eine eigene Web-Plattform anbietet, ist mit einem Penetrationstest besser beraten. Bei diesem simuliert ein darauf spezialisierter Dienstleister (wie die G DATA Advanced Analytics) einen Angriff auf bestimmte Komponenten und am Ende erhält das Unternehmen eine Übersicht der Faktoren, die einen erfolgreichen Angriff ermöglicht haben. Daraus kann der Betrieb dann die erforderlichen Sicherheitsmaßnahmen ableiten. Zu bedenken ist dabei allerdings, dass die Ergebnisse solcher Tests nur bedingt auf „echte“ Angriffe übertragen werden können, da Penetrationstests immer in einem genau definierten Rahmen („Scope“) und nach festgelegten Regeln durchgeführt werden.

Motivation

Dennoch müssen wir auch über Geld sprechen. Wenn das Melden von Sicherheitslücken allein von der Höhe der gezahlten Bug Bounties abhinge, dann wäre es oftmals zumindest finanziell lohnenswerter, Sicherheitslücken an spezialisierte Händler wie etwa Zerodium zu verkaufen. Und es gibt auch Experten, die keine moralischen Bedenken haben, wenn von ihnen entdeckte Sicherheitslücken von Kriminellen oder Geheimdiensten gegen andere eingesetzt werden. Ein gewisses Maß an Idealismus bringen viele Sicherheitsforscher mit – und den meisten kommt es auch nicht darauf an, von ihren Bug Bounties leben zu können und damit reich zu werden, denn das ist in den meisten Fällen nicht möglich. Einem Bericht von Hacker One zur Folge verdienen nur 12 von 100 auf der Plattform aktiven Forschern mindestens 20.000 Dollar im Jahr durch Bug Bounties. Mit anderen Worten: 88 Prozent der Forscher verdienen weniger als 20.000 Dollar im Jahr durch das Aufspüren von Sicherheitslücken. Leben kann man davon also nicht wirklich. Und selbst von den wenigen, die mindestens 20.000 USD verdienen, schaffen es nur drei Prozent über die Hürde von 100.000 Dollar im Jahr. Es gibt also vielleicht eine Handvoll Forscher weltweit, die theoretisch ausschließlich vom Aufspüren von Sicherheitslücken leben könnten.

Aber: Ein Polizist oder Sanitäter ergreift seinen Beruf auch nicht, um damit reich zu werden. Insgesamt 20 Prozent der befragten Hacker gaben entweder an, dass sie hacken, um „Gutes zu tun“ oder „um andere zu schützen“. Für viele ist auch einfach die Neugier der stärkste Motivator und das Bestreben, Neues zu lernen.

Ein finanzieller Anreiz ist dennoch hilfreich – denn wenn ein Forscher die fünfzehnte Sicherheitslücke beim gleichen Anbieter meldet und als Belohnung „nur“ ein T-Shirt erhält, sorgt das für Frust und das Gefühl, nicht ernstgenommen zu werden.

 

Bildnachweis:
"Bug Icon 198" von Edward Boatman, verwendet unter der Creative Commons-BY 3.0

Tim Berghoff
Security Evangelist