So funktioniert die Lücke in In-App-Käufen

Der russische Hacker Alexey Borodin hat eigene Server mit einem In-App-Kauf-Dienst online gestellt. Die Nutzer mussten nur die bereit gestellten Zertifikate herunterladen und auf dem iPhone installieren und schon war der Weg zu dem Gratis-Store offen. Apple hatte auf die Sicherheitslücke erstaunlich schnell reagiert und nach ein paar Tagen ein Tool für Entwickler und ein Update für iOS 6 veröffentlicht. Der iPhone-Hersteller behauptet, dass die Lücke ab iOS 6 nachhaltig geschlossen werde.

Der Hacker hat sich vor wenigen Tagen wieder zu Wort gemeldet und eine Schritt-für-Schritt-Anleitung für den Hack mitsamt des Codes für den Server veröffentlicht. Die Information ist mittlerweile harmlos, da der Hack nicht mehr funktioniert, bietet aber ein paar interessante Einsichten in die Kommunikation zwischen den Apple-Servern, denen der Entwickler und dem iPhone.

Für einen In-App-Kauf, kommuniziert ein iPhone mehrmals mit Apples Servern. Mittels einer Anfrage an den Extra-Server von iTunes (buy.itunes.apple.com) leitet das iPhone Angaben der App wie App-ID, Versionsnummer, Hersteller und die GUID/UUID des iPhone (Globally Unique Identifier oder Universally Unique Identifier) weiter. Als Antwort kommt die bekannte Kaufbestätigung „Wollen Sie die App X für Y Euro kaufen?“ Was auf dem iPhone-Bildschirm als eine Frage mit zwei Knöpfen aussieht, hat in einer aufgeschlüsselten Form deutlich mehr Parameter. So etwa die eindeutige iTunes Adam ID – eine acht- oder neun-stellige Identifikationsnummer für alle Apps in iTunes – sowie Preis, Versionsnummer, Hersteller und dergleichen. Borodin berichtet, dass bei seinen Tests die meisten Apps die iTunes ID ignorieren konnten. Sprich, die Kaufbestätigungsanfrage von iTunes enthält fast die gleichen Informationen, die das iPhone bereits an den Server verschickt hat. Die neuen Angaben wie die Adam ID werden einfach nicht beachtet.

Der nächste Schritt beim Kauf: der Nutzer schickt die Bestätigung an iTunes, indem er auf den Knopf „Kaufen“ tippt. Bei jedem App-Download bittet der App Store um eine Autorisierung. Bei dieser Autorisierung wurden nach Borodins Angaben vertrauliche Daten wie Apple ID und Passwort vom iPhone in einer unverschlüsselten Plist-Datei verschickt. Theoretisch öffnet sich hier eine weitere Sicherheitslücke: Da die Datenübertragung zwischen dem iPhone und dem App Store meist drahtlos arbeitet, ist es zu einem gegebenen Zeitpunkt für Verbrecher ziemlich einfach, an die sensiblen Zugangsdaten zu kommen.

Schwachstelle Validierungszertifikat

In den nächsten Schritten prüft der App Store den Kauf und ob die App auf dem iPhone angekommen ist. Dafür verschickt er eine digitale Kaufbestätigung mit allgemeinen Angaben zur App sowie extra Informationen zum Kaufdatum, der Transaktionsnummer und einem Validierungszertifikat für den Kauf. Bei dem Validierungszertifikat hat Borodin die entscheidende Schwachstelle gefunden, die er für den Hack nutzte. In der früheren Version lieferte der App Store das ganze File-Bundle, also das Zertifikat zusammen mit dem Schlüssel dazu. Das Layout des Zertifikats sieht folgendermaßen aus:

RECEIPTVERSION | SIGNATURE | CERTIFICATE SIZE | CERTIFICATE
    1 byte                          128                      4 bytes                  …

Bei den üblichen Verschlüsselungen wie zum Beispiel bei Mails schickt der Absender die elektronischen Briefe mit seinem ausgestellten Zertifikat. Der Empfänger hat dafür einen privaten Schlüssel für die Entschlüsselung. Passen das Zertifikat und der Schlüssel zusammen, bekommt der Empfänger die Daten in einer lesbaren Form. Dabei besteht für die Verbrecher kaum die Möglichkeit, die Daten ohne den gültigen Schlüssel zu dekodieren, selbst wenn es ihnen gelungen ist, an die Rohdaten heranzukommen.

Diesen logischen Fehler von Apple hat Borodin ausgenutzt: Die DNS-Einstellungen für das iPhone, die er zur Verfügung gestellt hatte, leitete das iPhone nicht zum App Store sondern zu einem andern Server um. Der Proxy-Server stellte für den App Store die gefälschten Zertifikate mit der gleichen Struktur wie bei einem Original-Zertifikat aus. Da die Schlüssel auf dem iPhone auch vom Hacker kamen, passte logischerweise das Zertifikat und der Schlüssel zusammen, der App Store betrachtete den Kauf als valide.

Der Hacker gibt auch Empfehlungen, wie App-Entwickler solche Einbrüche in der Zukunft vermeiden können. Zum einen liefert Apple den so genannten Verification Controller – eine zusätzliche Zeile im Kaufbestätigungs-Code. Zusätzlich dazu empfiehlt Borodin die Verifizierung aller Angaben in der Kaufbestätigung samt der iTunes ID. Die Apps, deren Kauf zusätzlich auf den externen Entwickler-Server mit eigenen Zertifikaten und Schlüssel geprüft wurden, waren von dem Hack nicht betroffen. Dies ist ebenfalls ein wirksamer Schutz gegen solche Einbrüche.

Alle Code-Beispiele finden Sie hier.

Den Code für In-App-Proxy gibt es auf Github .