Bei einem autorisierten Test einer großen Mobilitäts-App auf dem eigenen iPhone zeigten sich zwei Schwächen, die einzeln überschaubar sind und zusammen eine Kette ergeben. Die App prüft nicht streng, mit wem sie spricht, und der Anmeldetoken hängt an keinem Gerät. Wer den Datenverkehr einmal mitliest, kann den Token danach von jedem Rechner aus weiterverwenden, bis er abläuft. Was das praktisch bedeutet, wie ernst es wirklich ist und wie man so einen Fund meldet.
Es geht um eine verbreitete App für Fahrten und Lieferungen, auf dem Handy von vielen Menschen und mit Zugriff auf Standort, Adressen und Kontodaten. Bei einem autorisierten Test der iOS-App, ausschließlich mit dem eigenen Konto auf dem eigenen Gerät, habe ich mir zwei Dinge angesehen: wie die App mit ihrem Server spricht und wie sie die Anmeldung absichert. Zwei Beobachtungen kamen dabei heraus. Jede für sich ist nicht dramatisch, zusammen ergeben sie eine Kette.
Erstens: Die App schaut nicht genau hin, mit wem sie spricht
Eine App redet über eine verschlüsselte Verbindung mit ihrem Server. Standardmäßig vertraut sie dabei allen Zertifikaten, die das Betriebssystem für vertrauenswürdig hält. Sorgfältig gebaute Apps gehen einen Schritt weiter und akzeptieren nur das eine, ihnen bekannte Zertifikat ihres Servers. Dieses festnageln nennt man Certificate Pinning.
Diese App macht das nicht. Mit einem selbst ausgestellten Zertifikat, das auf dem Gerät als vertrauenswürdig markiert ist, und einem ganz normalen Abfang-Proxy, wie man ihn für App-Tests einsetzt, wird der komplette Verkehr im Klartext lesbar. Kein Jailbreak, kein Eingriff in die App, kein verändertes Programm. Keine Fehlermeldung, kein Verbindungsabbruch, kein Hinweis in der App. Für sich genommen ist das eine niedrig eingestufte Schwäche. Sie öffnet aber die Tür für das Zweite.
Dazu gehört die ehrliche Einordnung: Das setzt voraus, dass jemand auf dem Gerät des Opfers ein eigenes Zertifikat installieren und als vertrauenswürdig markieren kann oder den Netzverkehr auf andere Weise abfängt. Das ist kein Angriff aus der Ferne per Klick, sondern verlangt Zugriff auf das Gerät oder das Netz.
Zweitens: Der Anmeldetoken hängt an nichts
Nach der Anmeldung bekommt die App einen Token, der jede weitere Anfrage autorisiert, rund eine Stunde lang gültig. Dieser Token ist an kein Gerät gebunden. Es gibt keine Geräteprüfung, keine Signatur pro Anfrage, keinen Abgleich von Netzadresse oder Gerätetyp, und im kurzen Test keine erkennbare Ratenbegrenzung. Die Kennungen, die die App sonst mitschickt, also Gerät, Sitzung und Nutzerkennung, werden nur auf ihr Vorhandensein geprüft, nicht auf ihre Echtheit. Man kann sie frei erfinden, und der Server antwortet trotzdem.
Die Folge: Ein einmal mitgelesener Token funktioniert von jedem beliebigen Rechner aus, in jedem Netz, ohne die App und ohne das Originalgerät, bis er abläuft.
Auch hier die ehrliche Grenze, die wichtig ist, damit niemand die Sache größer macht, als sie ist: Man bekommt damit die Daten des Kontos, zu dem der Token gehört, nicht die eines fremden Nutzers. Das ist kein Zugriff auf beliebige Fremdkonten. Das eigentliche Problem ist, dass ein gestohlener Token vollständig übertragbar ist und der Server den Kontextwechsel, also anderes Netz, anderes Gerät, fehlende app-typische Merkmale, nicht als verdächtig erkennt.
Die Kette
Zusammengesetzt ergibt das einen nachvollziehbaren Ablauf. Wer den Netzverkehr abfängt, liest wegen der fehlenden Zertifikatsprüfung den Token mit. Wegen der fehlenden Gerätebindung kann er ihn danach von überall weiterverwenden, ohne dass Opfer oder Betreiber etwas bemerken, bis der Token abläuft. Das ist kein Weltuntergang, es ist aber genau die Art von Schwäche, die man schließt, bevor sie jemand ausnutzt.
Was dagegen hilft
- Zertifikate festnageln. Die App sollte nur ihr eigenes Server-Zertifikat akzeptieren, mit einer Strategie für den geplanten Wechsel. Dann scheitert das Mitlesen.
- Den Token ans Gerät binden. Eine Geräte-Attestierung oder eine Signatur pro Anfrage, die an einen auf dem Gerät gebundenen Schlüssel geknüpft ist, macht einen abgezogenen Token woanders wertlos.
- Mitgeschickte Kennungen serverseitig gegen den Token prüfen, nicht nur auf Vorhandensein. Erfundene Werte müssen auffallen.
- Ratenbegrenzung pro Token und Konto auf den sensiblen Abfragen.
- Auffälligkeiten erkennen, etwa einen plötzlichen Wechsel von Netz und Gerätetyp oder fehlende erwartete Merkmale, und im Zweifel eine erneute Anmeldung verlangen.
Zwei Randnotizen noch, keine klassischen Lücken, aber erwähnenswert: Standort und Kennungen reisen teils als Teil der Adresse mit statt im Nachrichtenkörper, was das Risiko erhöht, dass sie im Klartext in Server-Protokollen landen. Und beim Start lädt die App eine ganze Reihe von Tracking-Diensten, ein Datenschutzthema für sich.
Melden, nicht posten
Hier gilt dasselbe wie bei jedem Fund in fremder Software. Solange der Anbieter nicht nachbessern konnte, ist das kein Blogthema mit Anleitung. Der Fund ging deshalb vertraulich über das Bug-Bounty-Programm des Anbieters, den dafür vorgesehenen Weg. Getestet wurde ausschließlich das eigene Konto, kein fremdes Konto, keine fremden Daten. Dieser Artikel nennt den Anbieter und die App nicht und verzichtet bewusst auf den mitgelesenen Token, auf Geräte- und Sitzungskennungen, auf die internen Serveradressen und auf jede Schritt-für-Schritt-Anleitung. Es geht um das Prinzip, nicht um eine Vorlage.
Was man mitnehmen kann
Für alle, die eigene Apps mit einem Server dahinter bauen:
- Pinning ist kein Luxus. Ohne festgenagelte Zertifikate liegt der gesamte Verkehr offen, sobald jemand ein eigenes Zertifikat auf dem Gerät unterbringt.
- Ein Bearer-Token ohne Gerätebindung ist ein Generalschlüssel auf Zeit. Wer ihn hat, ist das Konto, egal von wo. Binde ihn an das Gerät, das ihn bekommen hat.
- Kennungen prüfen, nicht nur verlangen. Felder, die der Client mitschickt, dürfen nicht nur vorhanden sein, sie müssen zum Token passen.
- Ehrlich einordnen schützt die eigene Glaubwürdigkeit. Ein portabler Token ist ein echtes Problem, aber kein Zugriff auf fremde Konten. Wer übertreibt, verliert den Triager und den Leser.
- Gefunden heißt nicht gepostet. Erst vertraulich über den richtigen Kanal melden, dem Anbieter Zeit geben, dann reden.
Weiterlesen: Wenn der Angreifer ein LLM ist · Punkte ohne Wissen: eine Lernplattform im Test · Reihenweise gemeldet: eine Runde Open-Source-Reviews