Der Umgang mit Sicherheitsforschern – ein Thema für sich

Reaktion 1: Belohnung für die Forscher, gemeinsame Entwicklung einer Lösung

Viele Entwickler, besonders große Unternehmen im Cloud- und Security-Umfeld, loben sogenannte „Bug Bounties“ aus (was mit “Kopfgeld auf Bugs ausloben” zu übersetzen wäre). Das bedeutet: Findet jemand eine Sicherheitslücke in der Software des Unternehmens, gibt es unter bestimmten Bedingungen eine Belohnung.

Wichtig dabei sind unter anderem die Kritikalität der Lücke, die Reproduzierbarkeit bzw. der Proof-of-Concept-Code des Entdeckers und die Art der Veröffentlichung der Sicherheitslücke:

• Die Schwere der Lücke lässt sich nach dem Common Vulnerability Scoring System (CVSS) sehr gut einschätzen. Die Skala geht von 0 (keine Lücke) bis hin zu 10 (jeder kann die Lücke mit minimalem Aufwand auf IP-Ebene ausnutzen, um das System zu übernehmen). Klar: Wer eine 10 findet, bekommt eine höhere Belohnung als jemand, der eine 1 findet.
• Die Reproduzierbarkeit spielt bei der Einstufung einer Meldung ebenfalls eine wichtige Rolle und fließt mit in den CVSS-Score ein. Je einfacher und zuverlässiger eine Sicherheitslücke ausgenutzt werden kann, desto höher fällt die Belohnung aus. Der Umkehrschluss: Einfach nur behaupten „Da ist eine Lücke!“ bringt ohne den Beweis gar nichts!
• Ebenfalls wichtig: Die Sicherheitslücke sollte natürlich dem Unternehmen gemeldet, erst nach breiter Verfügbarkeit eines Patches veröffentlicht und nicht im Darknet verkauft werden. Letzteres kann zwar finanziell attraktiv sein, ist jedoch nicht im Sinne gewissenhafter Sicherheitsforscher!

Diese Art, auf die Meldung von Sicherheitslücken zu reagieren, ist natürlich der Gold-Standard. Die Motivation für Sicherheitsforscher und auch Enthusiasten ist in diesem Bereich sehr hoch, mit dem Unternehmen zusammenzuarbeiten und die Sicherheitslücke nicht auf anderen Kanälen publik zu machen. Ebenso können der Finder der Lücke und der/die Entwickler der betroffenen Software oft sehr schnell und umfassend die Ursache finden und gemeinsam beheben.

Reaktion 2: Dankbarkeit, gemeinsame Entwicklung einer Lösung

Wenn die finanziellen Reserven eines Unternehmens nicht für ein Bug-Bounty-Programm reichen, ist meistens immerhin noch ein „Danke, lieber Finder!“ üblich. Hier kann es ebenfalls zu einer gemeinsamen Lösung des Problems kommen. Selbst wenn ein „Danke“ im Vergleich zu einer Belohnung mickrig erscheinen mag, so kann es häufig schon eine gute Motivation sein. Wenn beim nächsten Release zudem noch der Finder der Lücke erwähnt wird, so kann sich dieser auf Dauer auch einen Namen machen. Viele Sicherheitsforscher sind obendrein bei spezialisierten Firmen angestellt und finanziell nicht davon abhängig, eine Belohnung zu erhalten.

Und bei vielen Enthusiasten, die in ihrer Freizeit nach Sicherheitslücken in interessanter Software suchen, ist eher der Wunsch ursächlich, etwas zu lernen und bei einer weitverbreiteten Anwendung die vielen Nutzer vor möglichem Schaden zu bewahren.

Allerdings reagieren manche Entwickler auch sehr empfindlich:

Reaktion 3: Keine Reaktion

Es gibt immer wieder Berichte, in denen davon die Rede ist, dass Sicherheitsforscher auf verschiedenste Art und Weise versucht haben, eine Sicherheitslücke an ein Unternehmen zu melden. Die tragische Betonung liegt dabei auf „versucht“, da in manchen Fällen eine Reaktion komplett ausbleibt.

Das kann viele Ursachen haben, und nicht immer ist es Vorsatz, dass auf die Meldung nicht reagiert wird.

Manchmal kommt die Meldung bei Personen im Unternehmen an, die damit nichts anfangen können, z.B. weiß nicht jeder Support-Mitarbeiter, was unter der Meldung „in Modul XY ist ein Buffer Overflow an dieser und jener Stelle möglich“ zu verstehen ist!

Eine ausbleibende Reaktion stellt den Finder der Lücke vor eine schwierige Entscheidung: Wie lange versucht er oder sie, die Firma zu kontaktieren? Und: Macht man die Sicherheitslücke irgendwann publik? Gerade die Art und Weise, wie man eine Schwachstelle kommuniziert oder offenlegt, ist ein Thema, dass weiter unten noch einmal etwas ausführlicher betrachtet werden soll.

Die Finder könnten in diesem Fall nach Ausbleiben einer Reaktion seitens der Urheber der Software eine dritte, vertrauenswürdige Instanz informieren. In Deutschland kann das zum Beispiel das BSI sein.

Reaktion 4: Die Anzeige

Besonders hohe Wellen, gerade in einschlägigen Medien, schlagen Anzeigen gegen Personen, die Sicherheitslücken gefunden haben. In den letzten Monaten sind häufiger Fälle aufgetreten, die hier nicht genau benannt werden sollen.

In diesem Kontext liegt leider häufig ein falsches Verständnis für das Verhalten von Sicherheitsforschern vor. Bei manchen Unternehmen führt das Bekanntwerden einer Sicherheitslücke zu einer reflexartigen Annahme, dass der Finder der Lücke diese schon ausgenutzt hat, um sich zu bereichern oder dem Unternehmen zu schaden. Es ist auch nicht immer ein Verständnis dafür da, was die Sicherheitslücke genau bedeutet. Doch hier spielt die Art und Weise der Veröffentlichung ebenfalls eine Rolle:

Bei einer freundlichen Benachrichtigung, dass eine Sicherheitslücke existiert, evtl. sogar mit Hinweisen zur Behebung, ist eine Anzeige nicht immer nachvollziehbar. Hier kommen entweder Missverständnisse bei der Kommunikation oder das o.g. falsche Verständnis als Ursachen infrage.

Wird die Sicherheitslücke ohne Benachrichtigung des jeweiligen Unternehmens veröffentlicht, kann der Schaden für das Unternehmen erheblich sein. Dahinter muss man andere Ursachen vermuten.
Offenlegung von Schwachstellen

Wir sehen in allen Reaktionen, dass die Art und Weise, in der die jeweilige Sicherheitslücke gemeldet wird, einen enormen Einfluss sowohl auf die Reaktion an sich als auch auf weitere Handlungen hat. Doch welche Möglichkeiten zur Veröffentlichung existieren? Hier folgen zwei häufige vorkommende Beispiele:

• Sofortige Veröffentlichung ohne Benachrichtigung des Entwicklers:
  Diese Art und Weise der Veröffentlichung ist für den Entwickler der betroffenen Software natürlich der absolute GAU (größter anzunehmender Unfall). In dem Moment, in dem der Entwickler von der Sicherheitslücke erfährt, wissen es auch alle anderen, inkl. bösartiger Hacker, Skript-Kiddies und der eigenen Kunden. Das heißt, für das Schließen der Lücke bleibt extrem wenig Zeit, und selbst bei einem schnellen Fix können schon viele Kunden betroffen sein und der Ruf des Entwicklers erheblichen Schaden genommen haben. Dass der Entwickler in einer solchen Situation nicht besonders gut auf den Finder der Lücke zu sprechen ist, versteht sich von selbst.
• Meldung an den Entwickler mit einer Frist für die Reaktion, nach deren Ablauf die Sicherheitslücke veröffentlicht wird:
  Mit diesem Vorgehen erhält der Entwickler eine Gelegenheit, mit dem Finder der Lücke Kontakt aufzunehmen und ggf. gemeinsam eine Lösung zu entwickeln. Das ist grundsätzlich nicht die schlechteste Idee, wenn die Frist realistisch gesetzt ist. In der Weihnachtszeit eine Frist von einem oder zwei Tagen zu setzen, wäre vielleicht sehr kurzfristig! In diesem Fall würde man in die vorherige Art der Veröffentlichung hineinrutschen und somit evtl. schlechte Stimmung beim Entwickler erzeugen. In vielen Fällen bestätigen die Unternehmen hier die Lücke und bitten um eine gewisse Zeit für die interne Analyse, sodass die breite Veröffentlichung der Lücke erst nach der Verfügbarkeit eines Patches oder eines Workarounds stattfindet. Hierein muss einfließen, wie einfach die Lücke zu entdecken war, wie schlimm sie ist und wie viel Zeit der Entwickler gerne hätte.

Natürlich kann es noch weitere Abstufungen geben. Ist es mir als Finder einer Sicherheitslücke überhaupt wert, viel Aufwand in die Meldung und die weitere Kommunikation mit dem Entwickler zu stecken? Möchte ich riskieren, dass der Entwickler rechtliche Schritte in Erwägung zieht? Gerade die letzte Frage führt häufiger dazu, dass Sicherheitsforscher bestimmte Entwickler oder Unternehmen in ihren Untersuchungen nicht betrachten, weil diese für ihre sehr engagierte Rechtsabteilung bekannt sind. Das Endergebnis ist leider unsichere Software und im Falle eines groß angelegten Angriffs eine große Zahl von Betroffenen.

Fazit

Es gibt viele – mehr oder weniger gute und sozialverträgliche – Möglichkeiten, einerseits Sicherheitslücken an Entwickler zu melden, andererseits als solcher auf die Meldungen zu reagieren. Es ist sicherlich hilfreich, einer freundlichen Meldung auch freundlich zu begegnen. In vielen Fällen kann der Finder einer Sicherheitslücke bei der Behebung ebenfalls helfen. Das ist für den Entwickler auf verschiedenen Ebenen vorteilhaft: Es werden Lücken gefunden und Lösungen mit verringertem Personalaufwand entwickelt. Im optimalen Fall kann man dem Finder der Lücke eine (kleine) Belohnung zukommen lassen. Wenn der Finder sich sozial und kooperativ verhält, sollte zumindest ein „Danke!“ möglich sein. Der Finder der Lücke erfährt eine Wertschätzung für seine Arbeit und kann im besten Fall noch etwas daran verdienen, dass er oder sie helfen wollte und konnte.