NEWS

iOS App Store

In-App-Diebstahl - was dahinter steckt (Update)

Portrait des Authors


In-App-Diebstahl - was dahinter steckt (Update)
11

Werbung

In den vergangenen 3-4 Tagen dominierte eine Nachricht die Apple-Welt: Ein russischer Hacker namens Alexey V. Borodin hat eine Möglichkeit gefunden, In-App-Käufe aus dem iOS App Store ohne Bezahlung zu tätigen und das ohne Jailbreak. Wieder einmal stürzten sich die Medien auf diese Meldung und extrahierten daraus die erneute Security-Apokalypse bei Apple. Die Rede war von "Man in the Middle"-Attacken und Passwörtern in Klartext, die Hintergründe kannte und kennt aber kaum jemand, auch wenn die Begriffe richtig sein mögen. Zeit das Thema einmal von vorne aufzuarbeiten:

Erstmals tauchten am Mittwoch vergangene Wochen erste Meldungen zu diesem Hack auf. Die Methode von Alexey V. Borodin nutzt gefälschte Sicherheits-Zertifikate und einen modifizierten DNS-Server. Die installierten Apps glauben daraufhin direkt mit dem App Store zu kommunizieren, sprechen allerdings nur mit dem vom Hacker betriebenen Server. Dies ist eine klassische "Man in the Middle"-Attacke. Der vom Hacker betriebene Server stellt gefälschte "Receipts" aus, die eigentlich dazu genutzt werden, um den In-App-Kauf gegenüber dem Entwickler zu verifizieren. Laut Borodin sind diese "Receipts" sehr einfach zu fälschen, da keinerlei Nutzerdaten enthalten sind und diese nicht in irgendeiner Weise gerätegebunden erstellt werden.

Um den Hack vollständig zu verstehen, muss zunächst einmal verstanden werden, wie In-App-Käufe funktionieren. Wenn ein Nutzer einen In-App-Kauf tätigt, schickt Apple ein paar Daten, das "Receipt". Die App kontaktiert daraufhin direkt die Apple-Server, um das "Receipt" zu validieren. Apple bietet den Entwicklern zwei Möglichkeiten der Validierung. Diese kann auf dem iOS-Gerät erfolgen oder aber auf einem eigenen Server, der vom App-Anbieter betrieben wird. Momentan kann der Hack nur "Receipts" erstellen, die auf dem iOS-Gerät validiert werden. Borodin will in einer nächsten Phase aber auch den Validierungs-Prozess auf den App-eigenen Servern täuschen können.

in-app-kaeufe

Apples Verantwortung

Apple bietet momentan nur in Teilen eine für Entwickler sichere Methode für In-App-Käufe. Ein Großteil der Entwickler dürfte aber auf die Validierung auf dem iOS-Gerät zurückgreifen, da diese deutlich einfacher zu implementieren ist. Das die Methode der Validierung auf dem iOS-Gerät nicht sicher ist, darf sicherlich Apple angekreidet werden. Einfach auf die zweite Methode zu verweisen, entbindet Apple nicht von seiner Verantwortung.

Ein zweiter Punkt ist die Übertragung der Apple-ID und des Passworts im Klartext. Borodin gibt an, dass er beide Datensätze auslesen kann, sobald jemand seinen Hack anwendet. Dies geschieht allerdings nur, da das iOS-Gerät über das gefälschte Sicherheitszertifikat glaubt, mit einem sicheren Apple-Server zu sprechen. Auch hier lässt sich aber sicherlich ein Großteil der Verantwortung Apple zuschreiben. Es spricht schließlich nichts dagegen Daten, auch bei einer verschlüsselten Verbindung, verschlüsselt zu übertragen.

Apple-Sprecher gegenüber The Loop:

The security of the App Store is incredibly important to us and the developer community. We take reports of fraudulent activity very seriously and we are investigating.

Sicherheitslücke stopfen

Die Sicherheitslücke zu schließen dürfte Apple nicht sonderlich schwer fallen, wird aber etwas Zeit in Anspruch nehmen. Ein iOS-Update, das die Methode der Validierung der "Receipts" verbessert, reicht aus. Dazu müssen dann aber auch alle Nutzer das Update ausführen. Wer weiterhin auf der alten iOS-Version verbleibt, kann über den Hack kostenlos In-App-Käufe tätigen. Entwickler können auf die sicherere Validierung über einen eigenen Web-Server wechseln, was allerdings zusätzlichen Arbeitsaufwand und Kosten nach sich zieht. Ein Update der App ist an dieser Stelle Pflicht. Nutzer, die weiterhin die alte Version der App nutzen, können auch weiterhin vom Hack Gebrauch machen.

Moralische Verantwortung

Der Validierungsprozess für In-App-Käufe bei Apple weist große Lücken auf. Bislang konnten Entwickler bei ähnlichen Versuchen über Methoden, die über einen Jailbreak zugänglich wurden, mit eigenen Maßnahmen gegensteuern. Beim aktuellen Hack ist dies nur durch die eigenhändige Validierung auf den eigenen Servern möglich.

Software-Piraterie ist und bleibt ein Thema - auch auf mobilen Geräten. Viele Entwickler entscheiden sich noch immer gegen die Entwicklung einer Android-App, da ihnen der Anteil der "geraubten" Installation noch immer einfach zu hoch ist. Bislang konnte Apple dieses Thema weitestgehend vernachlässigen.

Jedem Nutzer dieses Hacks muss auch klar sein, welche Daten er dem Hacker preis gibt. Da die Apple-ID und das Passwort übertragen werden, hat dieser auch vollen Zugriff auf das iTunes-Konto, mitsamt der hinterlegten Zahlungsinformationen. Wer sich später über einen gehackten und leergeräumten iTunes-Account beschwert, darf nicht allzu viel Mitleid erwarten. Aus offensichtlichen Gründen verzichten wir auch auf die Verlinkung zu Anleitungen, die diesen Hack möglich machen.

Sicherlich kann man sich über die Vor- und Nachteile des Freemium-Modells, Spiele kostenlos anbieten und dann über In-App-Käufe refinanzieren, unterhalten. Dem Nutzer wird aber immer eine Wahl gelassen: nicht kaufen! Eine Argumentation man sähe ja nicht ein dafür Geld zu zahlen, kann nicht akzeptiert werden.

Update:

Im Rahmen der gegebenen Möglichkeiten versucht Apple derzeit gegen den Hack vorzugehen. Zum einen bittet Apple Google darum die Videos mit Anleitungen von Youtube zu entfernen, was auch teilweise schon geschehen ist. Weiterhin blockt Apple inzwischen die IP-Adressen der bekannten Server und hat die Anbieter um die Abschaltung der selbigen gebeten.

Borodin hingegen will Server außerhalb Russlands anmieten, um die Methode weiter anbieten zu können. Damit umginge er auch die IP-Sperren. Inzwischen warnen auch Sicherheitsexperten vor der Nutzung des Hacks, da nicht nur der Datenverkehr für den App Store mitgeschrieben werden könnte, sondern auch sämtliche andere sichere Verbindungen offenliegen könnten.

Quellen und weitere Links KOMMENTARE (11)