Warum wir neugierige Sicherheitsforscher unterstützen statt bestrafen sollten

Die jüngsten Berichte über den jugendlichen Sicherheitsforscher Bill Demirkapi, der schwerwiegende Schwachstellen in der von seiner Schule genutzten Software aufdeckte, weckten bei mir durchaus Erinnerungen. Ich erinnere mich, wie ich als neugieriges Kind unter die Motorhaube von Software geschaut habe, um zu sehen, wie alles funktioniert – und, was noch wichtiger ist, ob ich es kaputt machen konnte. Seit Jahrzehnten streben Softwareentwickler nach kontinuierlicher Verbesserung und Absicherung ihrer Produkte, und die Sicherheits-Community spielt (auch wenn sie manchmal etwas frech in ihrer Herangehensweise ist) eine wichtige Rolle dabei, Fehler und potenzielle Katastrophen zu entdecken, hoffentlich bevor es ein Bösewicht tut.

Das Problem hierbei ist jedoch, dass er als Reaktion auf seine Entdeckungen von der Schule suspendiert wurde. Und das geschah erst, nachdem er alle Möglichkeiten ausgeschöpft hatte, das Unternehmen (Follett Corporation) privat zu kontaktieren, und sich schließlich für einen eher öffentlichen Weg entschied, um auf sich und seine Fähigkeit, in ihr System einzudringen, aufmerksam zu machen. Seine wiederholten Versuche, die Follett Corporation ethisch korrekt zu warnen, blieben unbeantwortet, während die Software anfällig blieb und Berge von Schülerdaten relativ leicht zugänglich waren, da ein Großteil davon unverschlüsselt war.

Er suchte auch nach Fehlern in der Software eines anderen Unternehmens: Blackboard. Während die Daten von Blackboard zumindest verschlüsselt waren, hätten potenzielle Angreifer darauf zugreifen und Millionen weiterer Datensätze entwenden können. Sowohl diese Software als auch das Produkt von Follett wurden an seiner Schule eingesetzt.

Das Narrativ vom „bösen Hacker“ ist problematisch.

Demirkapi präsentierte seine Ergebnisse auf der diesjährigen DEF CON, wobei die schelmischeren Details seiner Aktionen vom Publikum mit Applaus bedacht wurden. Zu Recht – obwohl er anfangs in Ungnade gefallen war und viele Hürden überwinden musste, damit seine Entdeckungen anerkannt wurden, war die Follett Corporation Berichten zufolge dankbar für seine Bemühungen und handelte nach seinem Rat, wodurch ihre Software letztlich sicherer wurde und die Krise, eine weitere Statistik für Datenpannen zu werden, abgewendet werden konnte. Er wird nach seinem Highschool-Abschluss auch das Rochester Institute of Technology besuchen, es ist also klar, dass er auf dem besten Weg ist, ein gefragter Sicherheitsspezialist zu werden.

Als jemand, der selbst im Sicherheitsbereich tätig ist, fällt es mir schwer, nicht zu kritisieren, wie mit dieser Situation umgegangen wurde. Auch wenn in diesem Fall alles gut ausgegangen ist, wurde er anfangs wie ein nerviger Skript-Kiddie behandelt, der seine Nase in Dinge steckt, die ihn nichts angehen. Eine Google-Suche zu dem Vorfall liefert Artikel, die ihn als „Hacker“ bezeichnen (was ihn in den Augen von Laien in vielerlei Hinsicht zum Bösewicht macht), obwohl sein Ansatz (und der vieler anderer) genau das ist, was unsere Daten sicher hält.

Wir brauchen neugierige, kluge und sicherheitsorientierte Menschen, die unter die Motorhaube schauen, und das muss viel häufiger geschehen. Allein bis Juli wurden dieses Jahr über vier Milliarden Datensätze bei böswilligen Datenpannen offengelegt. Dank der Sicherheitslücke bei der Mode- und Lifestyle-Marke Poshmark im August könnten weitere fünfzig Millionen hinzukommen.

Wir machen dieselben Fehler, und was noch besorgniserregender ist: Es handelt sich oft um einfache Schwachstellen, bei denen man sich nur an den Kopf fassen kann und die uns immer wieder zu Fall bringen.

Cross-Site Scripting und SQL-Injection sind nicht verschwunden.

Wie von WIRED berichtet, enthielten die Community Engagement-Software von Blackboard und das Student Information System von Follett laut Demirkapi gängige Sicherheitslücken wie Cross-Site Scripting (XSS) und SQL-Injection – beides Themen, die Sicherheitsspezialisten schon seit den 1990er Jahren Kopfzerbrechen bereiten. Wir ertragen ihre Existenz schon sehr lange, und genau wie Hypercolor-T-Shirts und Disketten sollten sie längst der Vergangenheit angehören.

Aber das tun sie nicht, und es ist offensichtlich, dass nicht genügend Entwickler ein ausreichendes Sicherheitsbewusstsein zeigen, um deren Einzug in ihren Code zu verhindern. Scan-Tools und manuelle Code-Reviews können nur begrenzt helfen, und es gibt weitaus komplexere Sicherheitsprobleme als XSS und SQL-Injection, bei denen diese teuren und zeitaufwendigen Maßnahmen besser eingesetzt wären.

Menschen wie Bill Demirkapi sollten Entwickler dazu inspirieren, einen höheren Standard bei der Programmierung zu setzen; mit gerade einmal 17 Jahren drang er in zwei stark frequentierte Systeme ein, und zwar über Angriffsvektoren, die hätten erkannt und korrigiert werden müssen, noch bevor der Code überhaupt eingecheckt wurde.

Gamification: Der Schlüssel zum Engagement?

Ich habe viel darüber geschrieben, warum Entwickler sich kaum für Sicherheit interessieren. Die kurze Antwort lautet: Weder auf organisatorischer noch auf bildungspolitischer Ebene wird genug getan, um sicherheitsbewusste Entwickler zu fördern. Wenn Unternehmen sich die Zeit nehmen, eine Sicherheitskultur aufzubauen, die Engagement belohnt und anerkennt – einschließlich Schulungen, die die Sprache der Entwickler sprechen und sie motivieren, am Ball zu bleiben –, dann beginnen diese lästigen Schwachstellen-Relikte aus der Software, die wir nutzen, zu verschwinden.

Demirkapi hat offensichtlich ein außerschulisches Interesse an Sicherheit und hat sich die Zeit genommen, zu lernen, wie man Malware zurückentwickelt, Fehler erkennt und – nun ja – Dinge kaputt macht, die von außen betrachtet nicht kaputt aussehen. In einem Gespräch mit VICE (und über seine DEF CON-Folien) machte er jedoch eine interessante Aussage zu seiner Selbstbildung... er hat sie gamifiziert:

„Mit dem Ziel, etwas in der Software meiner Schule zu finden, war es eine unterhaltsame, ‚gamifizierte‘ Art, mir eine beachtliche Menge an Penetration Testing beizubringen. Obwohl ich meine Recherche mit der Absicht begann, mehr zu lernen, fand ich am Ende heraus, dass die Dinge viel schlimmer waren, als ich erwartet hatte“, sagte er.

Auch wenn nicht jeder Entwickler sich auf Sicherheit spezialisieren möchte, sollte jeder Entwickler die Möglichkeit erhalten, sicherheitsbewusst zu werden. Die Grundlagen sollten innerhalb eines Unternehmens fast wie ein „Führerschein für das Programmieren“ dienen, insbesondere für diejenigen, die Zugriff auf große Mengen unserer sensiblen Daten haben. Wenn die einfachsten Sicherheitslücken von jedem Entwickler behoben werden können, bevor sie überhaupt geschrieben werden, sind wir gegenüber denjenigen, die Chaos stiften wollen, weitaus besser aufgestellt.

Neugierig auf gamifiziertes Training? Schauen Sie sich unsere Serie „Coders Conquer Security“ zu XSS und SQL-Injection an.