Im September 2014 hat das Internet eine Weile lang verrückter gespielt, als es das im Normalfall tut: Ein bei Redaktionsschluss Unbekannter hat eine Flut von intimen Bildern von Stars an die Öffentlichkeit gestellt. So ziemlich das Einzige, das sich mit Gewissheit feststellen lässt, ist, dass es sich hierbei um eine schwerwiegende Verletzung der Privatsphäre der Betroffenen handelt. Es steht ausserdem fest, dass die Entdeckung der Lücke, die ausgenutzt wurde, dabei helfen kann, weitere Incidents zu vermeiden. Egal um welche Daten es sich handelt.

Bis jetzt ist das Wie des Incidents noch nicht geklärt. Theorien besagen, dass Apples iCloud in zumindest einigen der Fälle involviert war. Der Grund für die Vermutung: Es gibt eine Vulnerability, die unter Umständen für das Leck genutzt wurde.

Die frühere Vulnerability

Ein Blick in die Vergangenheit: Ein Security Researcher entdeckt, dass in einem Teil der FindMyiPhone API kein Lockout-Mechanismus vorhanden ist. Das öffnet Brute-Force-Attacken Tür und Tor. Im Normalfall ist es Pflicht, dass in Software, die in irgendeiner Form mit Authentifizierung zu tun hat, ein solcher Lockout-Mechanismus als Grundanforderung gilt. Der Mechanismus beugt Brute-Force-Angriffen vor, indem der Account zumindest temporär deaktiviert wird, was folgende Login-Versuche fruchtlos werden lässt. Ein solcher Lockout kann unter anderem ein Captcha oder eine andere mehr oder weniger effektive Lösung sein. Aber die API hat das nicht, was es einem Angreifer ermöglicht, eine grosse Zahl Passwörter auszuprobieren, bis er schliesslich das Richtige findet.

Da der Lockout im Normalfall auf Applikationsebene geregelt ist und Apples Server Sekunde für Sekunde mit unheimlich grossen Datenmengen operieren, ist es unwahrscheinlich, dass ein Brute-Force-Angriff irgendwo in Apples Monitoring auftauchen würde. Und auch wenn dem so sein sollte, wäre dem Vorfall wohl nicht die nötige Aufmerksamkeit beschieden. Der Vorfall würde wohl unter noch so ein kleiner Botnet DDoS Versuch abgehakt werden.

Nach der Entdeckung der Vulnerability hat Researcher Alexey Troshichev ein Proof-of-Concept auf GitHub veröffentlicht, in dem er die Schwere des Problems mit einem kleinen Programm, das er iBrute nennt, illustriert.

Es ist nicht wirklich relevant, ob es dieser Bug oder Troshichevs Code war, der für das Datenleck verantwortlich ist und die Privatsphäre von Berühmtheiten verletzt hat. Fakt ist: Es könnte sein. Und: Apple hätte das verhindern können. Die Lösung wäre simpel und Apple würde einem Trend folgen, der in jüngster Zeit immer mehr im Kommen ist: Bug Bounties.

Geld für Vulnerabilities

Eine Bug Bounty ist einfach erklärt: Eine Firma kann Leute dazu einladen, potentielle Sicherheitsprobleme zu melden und – sollten sich diese bewahrheiten – mit Geldbeträgen zu belohnen.

Apple ist eine der wenigen grossen Technologiefirmen, die kein Bug Bounty Programm haben. Sie laden zwar Researcher dazu ein, Vulnerabilities zu melden, aber eine Belohnung am Ende bleibt aus. Bis vor kurzem war es sogar so, dass Apple den Researchern kaum Anerkennung zollte. Daher ist es nur logisch, dass der Wille, Vulnerabilities mit Apple zu teilen, ziemlich klein ist.

Facebook auf der anderen Seite hat schon seit Jahren ein Bug Bounty Programm und die Erfahrungen beim weissen F auf blauem Grund sind komplett anders. Im Januar 2014 hat Facebook einem Researcher 33 500 US Dollar bezahlt. Dies, weil er eine kritische Vulnerability gemeldet hat, die Angreifer Daten auf dem Webserver hätten auslesen lassen. Im Jahr 2013 hat Facebook mehr als 1.5 Millionen US Dollar für Bug Bounties bezahlt. Das waren 14 763 Meldungen, wovon 687 mit Bounties belohnt wurden.

Google hat ebenfalls ein Bug Bounty Programm, das im selben Zeitraum etwa zwei Millionen US Dollar ausbezahlt hat. Aktuell wird angenommen, dass etwa 350 Hersteller Bug Bounty Programme führen, in allen Ausrichtungen. Facebook zahlt mindestens 500 US Dollar, Twitter bleibt beim ikonischen (aber recht unattraktiven) Betrag von 140 Dollar, was genau der Maximallänge eines Tweets entspricht. Etsy, ein Marktplatz für Handgemachtes, bietet symbolische Belohnung in Form von öffentlicher Respektzollung und einen T-Shirt.

Das Konzept von Bug Bounties ist nicht neu: Als Netscape 2.0 im Jahre 1995 erschienen ist, boten die Entwickler Poloshirts und Tassen an, wenn ihnen Schwachstellen im damals enorm beliebten Browser gemeldet wurden.

Apple ist definitive einer der grossen Player auf dem Markt, die ein Bug Bounty Programm einführen und führen sollten. Dies bedeutet aber nicht, dass das zwingend jeder tun sollte. Katie Moussouris, die einst für Microsoft gearbeitet hat und dort das Bug Bounty Programm von Grund auf aufgebaut hat, hat an der RSA 2013 in einem Flash Talk darüber geredet. Im Talk riet sie Firmen, sicherzustellen, dass sie Vulnerabilities genau bewerten und richtig darauf reagieren können, bevor das Bug Bounty Programm öffentlich gemacht wird.

Sie hat wohl Recht: Nur nachdem alle Möglichkeiten einer Firma ausgeschöpft sind, mit Due Dilligence, damit sichergestellt werden kann, dass die eigene Infrastruktur sicher sind, kann ein Bug Bounty Programm seine volle Effektivität entfalten. Tausende Dollar für eine Cross-Site-Scripting-Schwachstelle zu zahlen, die ein unerfahrener Tester mit automatischem Scan erkennen kann, ist nicht unbedingt vernünftig.

Aber auch wenn eine Firma nicht bereit für ein solches Programm ist: Das Verständnis für den Vulnerability-Markt im Jahre 2014 ist aus vielerlei Gründen Pflicht. Bug Bounty Programme bieten Researchern einen einfachen Weg, mit Vulnerabilities umzugehen, ohne kriminalisiert oder bedroht zu werden. Es ist nicht selten, dass einem Researcher gleich nach Meldung einer Vulnerability mit rechtlichen Konsequenzen gedroht wird. Manchmal sogar in recht scharfem Ton. Daher ist es eine valide Alternative zum Verkauf der Vulnerability über einen Broker – womit sich definitiv mehr Geld verdienen lässt – mit dem stets moralische Bedenken einhergehen, die Vulnerabilities an Geheimdienste mit drei Buchstaben im Namen zu verkaufen, die auch noch viel mit Cybercrime zu tun haben.

In Anbetracht der Tatsache, dass diese Programme von Researchern weltweit genutzt werden, ist die Annahme, dass Apple eine Brute-Force-Attacke auf jeden registrierten iCloud-Account verhindern könnte, höchstwahrscheinlich valid. Sicher ist: Es würde sich für Apple lohnen, sich mit dem Konzept eines Bug Bounty Programmes auseinanderzusetzen. Hätte Apple ein solches Programm, dann wäre iBrute nie zum Problem vom heutigen Ausmass geworden. iBrute wäre als ein paar hundert Dollar weniger auf dem Bankkonto des Apfels in die Geschichte eingegangen.

Über den Autor

Stefan Friedli gehört zu den bekannten Gesichtern der Infosec Community. Als Referent an internationalen Konferenzen, Mitbegründer des Penetration Testing Execution Standard (PTES) und Vorstandsmitglied des Schweizer DEFCON Group Chapters trägt er aktiv zum Fortschritt des Segmentes bei.

Links

• http://www.forbes.com/sites/kashmirhill/2014/01/15/so-you-found-an-obamacare-website-is-hackable-now-what/
• http://www.theguardian.com/technology/2014/sep/01/naked-celebrity-hack-icloud-backup-jennifer-lawrence
• https://github.com/hackappcom/ibrute
• https://www.facebook.com/BugBounty/posts/778897822124446