Seit einigen Tagen ist es innerhalb der iOS-Entwicklergemeinde als auch unter den iPhone/iPad Nutzern ein großes Thema. Ein Hacker aus Russland stellte bei Youtube ein Video bereit, auf dem man sehen konnte, wie ein InApp-Kauf gefälscht werden konnte. Kurze Zeit später stellte er auch alles notwendige bereit um selber „kostenlose” InApp-Käufe tätigen zu können.

Zwischenzeitlich wurde das Video allerdings entfernt und der für den „Hack” benötigte DNS-Server wurde zwischenzeitlich gesperrt. Der aktuelle Stand sieht nun so aus, dass der vorgestellte Weg nicht mehr direkt funktioniert. Allerdings hat der Hacker bereits eine neue funktionierende Anleitung für den heutigen Abend angekündigt.

Vorab ein paar generelle Dinge zu solchen Hacks. Ich werde sicherlich hier die Anleitung nicht verlinken. Es sollte auch jedem klar sein, dass man sich mit dem „faken” eines InApp-Kaufs abseits der legalen Wege bewegt und dies unter umständen später teuer zu stehen kommt.

Abseits der rechtlichen Probleme möchte ich dennoch auf ein paar Punkte hinweisen, die auf vielen Nachrichtenseiten nicht direkt bzw. nur unvollständig erwähnt wurden.

Zuerst ein Punkt, der eigentlich jedem klar sein sollte. Der vom Hacker betriebene „InApp-Kauf”-Server, welcher die Antwort (=Reciept bzw. Kaufbeleg) für die jeweilige App generiert, erhält neben der Gerätekennung auch die eingegebenen Zugangsdaten. Die Zugangsdaten werden zwar über eine verschlüsselte Verbindung übertragen, aber da der Hacker als „Man-In-The-Middle” die komplette Kommunikation auf sein eigenen Server umlenkt baut iOS die verschlüsselte Verbindung mit dem „falschen” Server auf. Dies wird allerdings erst wiederum durch das installieren eines gefälschten Zertifikats überhaupt möglich.

Auch wenn jetzt der Hacker natürlich beteuert, dass beliebige Zugangsdaten eingegeben werden können, so dürfte es dennoch genügend Leute geben, die ihre echten AppleId-Zugangsdaten eingegeben haben. Man kann den Leuten nur dringend empfehlen das Passwort schnellstmöglich zu ändern. Dies gilt für alle Seiten, auf der man das gleiche Passwort verwendet hat. Bleibt natürlich noch die Gerätekennung und mit dieser kann theoretisch jedes iPhone/iPad erkannt werden kann. Hier kann man nur hoffen, dass wirklich nichts aufgezeichnet wurde. Für Apps aus dem iTunes Store ist übrigens der Zugriff auf genau diese Kennung zukünftig nicht mehr möglich.

Ein weiterer Punkt  ist, dass das Problem bereits seit Ende 2011 bekannt ist und der „Hacker” im Endeffekt das ganze nur als fertige Lösung präsentierte die auch ohne Jailbreake funktionierte. Natürlich handelt es sich dabei auch um eine „Leistung”. Mir stellt sich aber die Frage: hätte er eine solche weitreichende Anleitung unbedingt bereitstellen müssen? Jedenfalls ist die Sache alles andere als neu …

Bereits im letzten Jahr hat Apple im Zusammenhang mit den InApp-Käufen seine Entwickler darauf hingewiesen, dass man das Receipt bzw. den Kaufbeleg unbedingt vor dem freischalten von Inhalten prüfen sollte. Zitat von der Apple Developer-Homepage:

The code provided in these steps is best used for the built-in product model. If your application uses a server to deliver content, you are responsible for designing and implementing the protocols used to communicate between your application and your server. Your server should also verify receipts before delivering products to your application.

Es existiert auch eine Anleitung die das prüfen des Kaufbelegs erklärt. In der Anleitung geht man auch davon aus, dass die Prüfung über ein eigenen Server erfolgt. Selbst innerhalb des geschlossenen Entwickler-Forums ist dies bereits seit längerem ein regelmäßiges Thema.

Auch wenn die Prüfung für ein Entwickler einen Extra-Aufwand bedeutet, so sollte spätestens jetzt eigentlich jedem klar sein, dass die Prüfung mittlerweile notwendig ist. Durch eine solche Prüfung, besonders wenn sie über den eigenen Server ausgeführt wird, kann man als Entwickler relativ beruhigt vor gefälschten Kaufbelegen sein. Ein Angreifer müsste dann auch die Verbindung zu dem für das jeweilige App zuständige Webservice abfangen und dies bedeutet eine individuelle Anpassung für die jeweilige App. Um das ganze noch etwas zu erschweren, kann der Webservice über eine https-Verbindung mit einem gültigen Zertifikat betrieben werden.

Die Liste mit Apps, die durch den nun bekanntgewordenen Weg angegriffen werden kann dürfte mit Sicherheit in Zukunft immer weiter abnehmen. Ich kann mir nicht vorstellen, dass von den betroffenen Publisher viele lange zuschauen werden.