it-swarm.com.de

Google IAP gibt ein kurzes Kauftoken zur Überprüfung zurück

Ich habe serverseitige Verifizierungs-Google IAP-Kauftoken implementiert. Meine mobile App sendet mir dieses Token, wie es von Google abgerufen wird. 

Ein normales Token sieht aus wie

minodojglppganfbiedlabed.AO-J1OyNtpooSraUdtKlZ_9gYs0o20ZF_0ryTNACmvaaaG5EwPX0hPruUdGbE3XejoXYCYzJA2xjjAxrDLFhmu9WC4fvTDNL-RDXCWjlHKpzLOigxCr1QhScXR8uXtX8R94iV6MmMHqD

aber manchmal bekomme ich so ein kurzes token

korpimulxmslxissnschtkdb

Wenn ich dieses Token über die Google Play Developer API verifiziere: https://www.googleapis.com/androidpublisher/v2/applications/packageName/purchases/subscriptions/subscriptionId/tokens/token , bekomme ich ein kurzes Token 404 Fehler. 

Wo ist das Problem? Ist es möglich, dass dieses kurze Token echte Transaktionen darstellt?

29
cermakjn

Ich habe die gleichen ungültigen Token in unserer App erhalten, ohne den Grund für eine Weile zu kennen. Die Token sind in verschiedenen Formaten erhältlich, darunter 24 alphanumerische Zeichen (z. B. glvnqnpjqslcagyimgxeuybk), 15 Ziffern (z. B. 781871156762279, siehe diese Frage ) und sogar Token mit der richtigen Länge, die ein etwas anderes Format als die gültigen haben (z. B. xdavcuvdnniwwrhwemleqjdz.rSQozm...siehe diese Frage ).

Dies sind die Fehlermeldungen, die ich von der In-App-Abrechnungs-API für diese verschiedenen Token zu der einen oder anderen Zeit erhalten habe:

  • "code": 404, "message": "The purchase token was not found."
  • "code": 400, "message": "Invalid Value"
  • "code": 400, "message": "Your request is invalid for this subscription purchase."

Die Antwort von Marc Greenstock gab mir eine Idee, um zu versuchen, das Problem zu reproduzieren.

Betrügerische Einkäufe tätigen

Ich habe zwei Apps getestet, die behaupten, In-App-Käufe zu hacken: Freedom und Lucky Patcher , auf einem gerooteten Gerät. Ersteres hat nicht funktioniert: Obwohl festgestellt wurde, dass unsere App Einkäufe tätigen kann, wurde mir beim Versuch, eine Fälschung zu erstellen, mitgeteilt, dass "die Einkäufe dieser App nicht gefälscht werden können". Letzteres funktionierte jedoch nach einigem Hin und Her und erzeugte genau wie in der Frage einen kurzen Kauf-Token. Als ich versuchte, das Token über die In-App-Abrechnungs-API zu verifizieren, erhielt ich dieselbe exakte Meldung "Ungültiges Token" wie zuvor.

Ich habe auch damit begonnen, den Root-Status von Geräten zu protokollieren, die ungültige Token generieren, und zwar mit diese Methode . Dies ist zwar kein Beweis für irgendetwas, aber die Tatsache, dass fast alle ungültigen Token von gerooteten Geräten stammten, ließ mich verdächtigen, dass sie schlecht gespielt haben.

Der Angriff

Ich glaube, der Angriff funktioniert wie folgt. Wer mehr darüber weiß, meldet sich bitte!

  • Der Benutzer installiert eine der Hacking-Apps, die angeblich kostenlose In-App-Käufe auf einem gerooteten Gerät tätigen
  • Die Hacking-App patcht entweder den legitimen In-App-Abrechnungsdienst auf dem Gerät oder emuliert ihn
  • Während eines Kaufvorgangs fängt die Hacking-App das Kauf Intent ab, das für den legitimen Service bestimmt ist
  • Die Hacking-App verarbeitet die Kaufanfrage und generiert eine Antwort auf die gleiche Weise wie der legitime Service, aber die Kaufanfrage erreicht niemals die Google-Server
  • Eine App, die sich auf die lokale Token-Validierung stützt, fordert Käufe beim In-App-Abrechnungsservice an. Diese Anfrage wird auch von der Hacking-App abgefangen, die behauptet, dass der Kauf gültig ist
  • Eine App, die sich auf die Server Token-Validierung stützt, sendet das Kauf-Token an einen Server, der die In-App-Abrechnungs-API aufruft, die dies noch nie getan hat das Token gesehen und gibt daher eine "ungültige Token" -Antwort zurück

Minderung

  • Apps, die sich ausschließlich auf den In-App-Abrechnungsdienst verlassen, sind anfällig ! Die Kaufbestätigungsanfragen und werden von derselben betrügerischen App abgefangen. Es gibt keine Verteidigung.
  • Apps, die auf einem Server-Backend basieren, sollten das Kauf-Token an das Backend senden, um es über die Publisher-API zu überprüfen. Diese Apps dürfen den Benutzer nicht mit dem Kauf belasten , bis das Back-End dies überprüft und ein positives Ergebnis an die App zurückgibt. Das Backend sollte wahrscheinlich den Sicherheitsempfehlungen für die In-App-Abrechnung folgen. Diese Apps sind wahrscheinlich sicherer vor betrügerischen Einkäufen, obwohl sie viele ungültige Einkäufe generieren.
  • Ich glaube nicht, dass es sicher ist, sich auf die Länge oder das Format des Tokens, die Bestellnummer oder andere Daten zu verlassen, um die Gültigkeit des Kaufs zu bestimmen. Diese Token sind wahrscheinlich nur fehlerhaft, weil sie ein vorheriges Format emuliert haben. Vermutlich werden die Autoren der Hacking-App irgendwann eine Version veröffentlichen, um jedes von Google gewünschte Format zu emulieren. Die einzige sichere Möglichkeit besteht darin, den Kauf über die In-App-Abrechnungs-API auf einem Gerät zu überprüfen, das Sie steuern, d. H. ein Server.
40
savanto

Hast du das am Ende gelöst?

Der einzige Grund, den ich vorschlagen kann, ist, dass das Token von einem In-App Purchase Cracker generiert wurde, z.

Ich bin daran interessiert zu sehen, ob Sie einen kurzen Wert für Testkäufe erhalten haben, die Sie selbst gemacht haben.

Ein weiterer Hinweis, dass das Token falsch ist, ist das Format der orderId, die Sie nach dem Kauf in der App erhalten.

Wenn es nicht dem in Verwalten der In-App-Fakturierung docs angegebenen Format entspricht, ist dies höchstwahrscheinlich ein betrügerischer Kauf.

3
Marc Greenstock

Ich habe eine teilweise Minderung gefunden, die bei einigen falschen IAP-Providern funktioniert: Überprüfen Sie die digitale Signatur manuell. Was auch immer der IAP-Simulator tut, er hat keine Kopie des privaten RSA-Schlüssels von Google. Ich habe meine eigene Signaturprüfung gerollt und fängt zumindest einige dieser gefälschten Transaktionen ein.

Der Prüfcode ist ein Gist.

0
Seva Alekseyev