Was ist ein “Bug-Bounty-Program”?
Ein Bug-Bounty-Programm ist eine öffentliche Einladung eines Unternehmens an Sicherheitsforscher: Sucht gezielt nach Schwachstellen in unseren Systemen, meldet sie uns verantwortungsvoll - statt sie auszunutzen oder zu veröffentlichen - und wir zahlen euch dafür eine Belohnung. Die Höhe richtet sich meist nach der Schwere des Fundes (Severity). Vorher legt das Unternehmen fest, was getestet werden darf (Scope) und was tabu ist (Out-of-Scope), oft vermittelt über Plattformen wie HackerOne oder Bugcrowd.
Eine Analogie aus der echten Welt
Ist es nicht seltsam? In der digitalen Welt kann man Geld dafür bekommen, sich in die Sicht eines Angreifers zu versetzen und den Angriff auf die digitale Infrastruktur eines Unternehmens zu simulieren.
Und in der analogen Welt? Dort stelle ich mir das folgendermaßen vor (am Beispiel eines Hotels).
Szenario
- Ein Hotelbesitzer hat einen öffentlichen Aushang, der dazu aufruft, Sicherheitsprobleme zu suchen, zu finden und zu melden mit der Aussicht auf eine Belohnung. Er legt fest, dass der Garten “out-of-scope” ist. Fokus soll auf das Gebäude gelegt werden.
- Ich sehe diesen Aushang und mache einen Plan.
- Ich buche mir ein Zimmer und reise an. Ich gehe gleich zur Rezeption. “Bar oder mit Karte” werde ich gefragt… Bar natürlich! Ich zücke die falschen 50€-Scheine aus meinem Geldbeutel und überreiche sie. Als man mir schon das Wechselgeld geben möchte, weise ich die Person darauf hin, dass es Falschgeld ist und zücke meine Bank-Karte. Von der sichtlich verwirrten Person erhalte ich die Scheine zurück, zahle mit Karte und erhalte die Schlüssel-Karte für Zimmer 16.
Notizen:
Schweregrad: Hoch
Angriffskomplexität: niedrig, da Falschgeld leicht zu beschaffen ist und an der Rezeption kein Prüfmittel (UV-Lampe, Prüfstift, Wasserzeichen-Kontrolle) eingesetzt wurde;
Auswirkung: Verletzung der Integrität des Zahlungsprozesses, unmittelbarer finanzieller Schaden, der sich bei wiederholter Anwendung beliebig skalieren lässt.- 30 Minuten später… Ich bin in meinem Zimmer angekommen und frage mich permanent, wie wohl ein Angreifer handeln würde. Wenig später stehe ich mit einem Feuerzeug und einem Feuerlöscher vor den Gardinen. Ich will keinen Schaden anrichten und schaue nur, ob sie theoretisch brennbar sind. Ja, sind sie. Ich notiere im Detail, wie ich es gemacht habe und dass so etwas ausgebessert gehört. Ein Angreifer hätte mit den leicht entflammbaren Gardinen potenziell das gesamte Gebäude abfackeln können… Ein Klassiker: Das letzte Hotel hatte daran auch nicht gedacht.
Notizen:
Schweregrad: Kritisch
Angriffskomplexität: niedrig, da Feuerzeug frei erhältlich;
Auswirkung: Verletzung der Verfügbarkeit und Integrität.- Es ist Abend geworden und ich habe den Room-Service noch nicht ausprobiert. Ich nutze das Telefon und bestelle das Tagesmenü auf Zimmer 19. Was wird passieren? Leider scheint die Rezeption die Nummer des anrufenden Zimmers (16) angezeigt zu bekommen. Das Essen wird auf mein Zimmer geliefert und wohl auch auf meine Rechnung gesetzt werden. Schade.
Notizen:
Impersonation anderer Besucher gegenüber dem Room-Service leider nicht so einfach möglich. TODO: Wie andere Nummer vortäuschen?- Nächster Tag morgens… Ich checke aus. Aber wer sagt, dass ein Angreifer vorgegebenen Checkout-Prozessen folgen muss? Die Person an der Rezeption ist gerade abgelenkt durch andere Checkouts. Gilt das schon als Denial-of-Service? Besonders auffallen tut es nicht, dass ich gerade mit meinem Koffer das Hotel verlassen habe. Einer so abgelenkten Rezeption wird es sicherlich auch nicht auffallen, wenn ich nächste Woche nochmal komme, um auszuprobieren, ob meine nicht zurückgegebene Schlüssel-Karte widerrufen wurde, oder ich nach wie vor damit mein Zimmer betreten kann… Die Rechnung für die Mahlzeit gestern könnte wohl per Post kommen. Aber wer sagt, dass ich bei der Buchung des Zimmers eine korrekte Adresse angab?
Notizen:
Fehlende Session-Invalidierung?- Ich fahre nach Hause und verfasse meinen Report und bin gespannt, wie hoch die Auszahlung wird. Nicht zu optimistisch sein! Das letzte Hotel hatte 2 meiner gemeldeten Probleme als Duplikate geschlossen…
Pläne für die Zukunft:
Notizen:
- Nach dem Melden & ausreichender Zeit zur Behebung Regressionstests ausführen
- (Social engineering) Erhalte ich durch Tricks einen Schlüssel für ein fremdes Zimmer?
- (Race Condition) Gleichzeitig Stornierung und Check-In?
- (Business Logic Flaw) Minibar: Wird der Verbrauch nur stichprobenartig kontrolliert? Fällt es auf, wenn ich Flaschen austausche, statt sie zu entnehmen? Fällt es auf, wenn ich nur einen Schluck des Inhalts entnehme?
- (Broken Access Control / IDOR) Frühstücksbuffet: Reicht die Nennung einer fremden Zimmernummer, oder wird tatsächlich abgeglichen, wer wo wohnt?
- (Privilege Escalation) Personaltüren und Notausgänge: Lassen sich Bereiche betreten, die eigentlich nur dem Personal vorbehalten sind?Schluss
Ok, ich gebe zu: Ich hätte in meinem Szenario mehrfach Gesetze gebrochen und der Scope und die Restriktionen hätten mir das meiste davon wahrscheinlich verboten…
Aber in der digitalen Welt muss ein System interessanterweise gegen alle erdenklichen Angriffsvektoren abgesichert sein, während es in der echten Welt viel lockerer gesehen wird. Auf der Website eines Hotels kann ich nur eine limitierte, bewusst ausgewählte Menge an Aktionen ausführen und eine ungeplante Ausweitung dieser Aktionen zum Schaden des Unternehmens würde i.d.R. schnell behoben werden. Ich bin im Normalfall physisch also gar nicht in der Lage, es sei denn, ich finde einen Fehler im System. In der echten Welt hingegen kann ich in das Hotel hereinspazieren und dafür sorgen, dass es niederbrennt. In beiden Fällen würden Gesetze gebrochen. Letzteres wäre aber wahrscheinlich schwerer, unerkannt/anonym zu bewerkstelligen und wäre schwerer, komplett zu verhindern. Möglicherweise sind das die entscheidenden Unterschiede…