attacco Protection per iOS acquisti in-app

Question

iOS di Apple in-app sistema di acquisto è stato attaccato in passato da persone che hanno ingannato le app a dare loro contenuti gratuitamente. Da allora hanno migliorato i sistemi coinvolti per cercare di limitare questo tipo di cose.

Ho letto attraverso i documenti di riferimento StoreKit disponibili da Apple e ho un'idea generale del flusso di lavoro e le verifiche che devono essere fatte, e così via. Tuttavia, potrebbero esserci problemi di sicurezza di cui non sono a conoscenza.

Qualcuno può fornire un elenco completo di furto-attacchi che può essere tentata contro i meccanismi di acquisto in-app, come gli sviluppatori potrebbe consentire erroneamente questi attacchi, e quali sono le migliori pratiche per la prevenzione di loro?

Answer 1

Questi sono gli attacchi che sono a conoscenza di, passato e presente:

falso App Store

resa famosa dal programmatore russo Alexey Borodin, questo attacco ha effetto solo le applicazioni che verificano le ricevute di acquisto direttamente con l'App Store. Modificando le impostazioni DNS del dispositivo e installando certificati di sicurezza falsificati, le richieste di verifica vengono inviate a un server App Store falso, che restituisce automaticamente che l'acquisto è valido. Le app ignare accetteranno queste chiamate di verifica e consegneranno il contenuto all'utente.

Commento

Dopo questo exploit è stato reso noto nel mese di luglio del 2012, Apple ha emesso la documentazione aggiornata e di consulenza per gli sviluppatori per garantire questo tipo di attacco non avrebbe continuato a verificarsi. Borodin è stato citato in vari articoli sul web affermando che il "gioco è finito" basato sulle API aggiornate di Apple e sulle linee guida sulle best practice.

Prevenzione

Apple ha un intero documento dedicato a questa scappatoia here. (EDIT:. Link è giù, Wayback se vuoi ... anche se il documento coperto iOS 5.1 e versioni precedenti) Il più grande punto che portano fino sta avendo la vostra applicazione inviare la ricevuta a un server esterno che si possiede, e poi dover il tuo server verifica la ricevuta con Apple. Tuttavia, se si invia la ricevuta direttamente dall'app all'App Store, si consigliano i seguenti controlli:

• Verificare che il certificato SSL utilizzato per connettersi al server App Store sia un certificato EV.
• Verificare che le informazioni restituite dalla convalida corrispondano alle informazioni nell'oggetto SKPayment.
• Verificare che la ricevuta abbia una firma valida.
• Verificare che le nuove transazioni abbiano un ID transazione univoco.

falso verifica server

Se la vostra applicazione invia le ricevute delle transazioni al server, che poi li inoltra ad App Store, una possibilità è per l'attaccante di falsificare il server di verifica. Con qualche metodo (alterando la tabella DNS, cambiando l'URL, ecc.) La ricevuta viene inviata ad una posizione alternativa e viene restituita una "verifica riuscita".In questo modo la ricevuta non raggiunge mai il tuo server e non hai mai la possibilità di controllarlo con l'App Store.

Commento

quanto pare ci sono una varietà di applicazioni nel negozio Cydia che servono per l'esecuzione in background, monitorare il traffico ricezione, e destinarli a questo scopo. Fonte: Hussulinux Blog

Prevenzione

Se si esprime immediatamente il contenuto non appena ricevuta è verificato, non v'è alcun modo conosciuto per evitare che questo tipo di attacco. Tuttavia, prendi questo scenario: hai un sistema di account utente gestito sul tuo server. Se lo scopo dell'acquisto in-app è di notificare al tuo server che un particolare account utente ha acquistato un articolo e l'app lo scarica dal tuo server, sei immune all'attacco. Il reindirizzamento della ricevuta a un altro server non compire nulla per l'utente malintenzionato, poiché il server non contrassegnerà mai l'account utente come proprietario di un articolo, in quanto non vede mai la ricevuta.

ricevute false

un utente malintenzionato può falsificare il processo di acquisto e quindi inviare una ricevuta forgiato al server di verifica. A differenza dell'attacco precedente, la posizione in uscita della ricevuta non viene modificata, ma viene sostituita con un impostore. Questa ricevuta spoofata è, infatti, una ricevuta valida da una precedente transazione di App Store e l'App Store la verificherà come tale. Mediante la falsificazione del processo di acquisto e l'invio di una ricevuta falsificata sul server, il contenuto non viene mai effettivamente pagato.

Commento

quanto pare ci sono una varietà di Cydia applicazioni che fanno questo genere di cose. Puoi individuare ricevute false perché il loro product_id è completamente diverso da qualsiasi cosa tu usi nella tua app. Apparentemente l'id falsificato più famoso è com.zeptolab.ctrbonus.superpower1. Fonte: Hussulinux Blog.

Prevenzione

Nel link dove ho trovato questo attacco, il blogger ha raccomandato che si apre la confezione la ricevuta al vostro server di verifica (base64_decode) e verificate la product_id prima di inviare la ricevuta per l'App Store. Tuttavia, in this article, Apple consiglia di inviare prima la ricevuta all'App Store, quindi leggere le informazioni restituite per accertarsi che la ricevuta sia valida.

(Inoltre, correggimi se sbaglio, ma la tecnica consigliata da Apple potrebbe anche essere utilizzata per prevenire questo tipo di attacco anche se non hai un server di verifica. Se la tua app invia la ricevuta direttamente all'App Store, potrebbe esaminare il contenuto della risposta JSON per assicurarsi che sia valido. Ma questo va contro Apple consigliate le migliori pratiche di utilizzo di un server di verifica esterna, quindi non sarebbe favorevole esso.)

In chiusura

Questi sono gli attacchi di cui sono a conoscenza, sentitevi liberi di correggermi se ho torto su un punto qualsiasi o di proporre ulteriori attacchi e correzioni.

Come nota, c'è questo sito web: http://www.in-appstore.com/ che dichiara di consentire gli acquisti in-app gratuitamente, sia su iOS 5 sia con un dispositivo iOS 6 jailbroken, ed è attivo dal 5 luglio 2013.Anche se non sono sicuro al 100% su come lo stanno facendo, sembra implicare il reindirizzamento DNS e certificati di sicurezza falsi, il che implicherebbe l'App Store falso o il Fake Verification Server, il che implicherebbe anche che ci siano ancora app là fuori che sono non protetto contro questi attacchi.

Risorse

• Apple iOS in-app purchase hacking
• My Experiences With Verifying In-App Purchase Receipts
• How to detect "IAP Crackers"?

EDIT:

Ulteriori

Sembra che una o due persone siano passate da qui e hanno trovato utile questo post e sono contento.

Ci sono altre informazioni che si possono avere su questo argomento, sia in altri post, libri, o, se si sta facendo, raschiando il ventre di internet. Ecco solo un paio di siti Web e post e così via che voglio esaminare, ma non ho ancora avuto una possibilità. Aggiungerò più collegamenti più tardi quando trovo interessanti curiosità.

http://www.se7ensins.com/forums/threads/tut-how-to-hack-ios-games-and-apps.701845/ http://www.iapphacks.com/

Un paio di take away immediati: non conservare i dati del lettore in modo semplice plist a meno che non si vuole che possano essere modificati da qualche adolescente. Le persone non devono hackerare il tuo sistema IAP se possono semplicemente darsi oro o qualcosa di simile modificando i file sul disco. Forse crittografando questi file, potresti scoraggiare un certo segmento di aggressori.

In base al collegamento di se7ensins, sembra che un utente malintenzionato possa fare a meno del proprio file binario e pasticciarlo per ottenere gli stessi fini della modifica di un file plist o anche di più, ma ciò richiederà un livello di abilità leggermente superiore . Forse l'impostazione del rilevamento del jailbreak sarebbe sufficiente a scoraggiare la maggior parte delle persone che farebbero ricorso a questo.

Ancora una volta, questa sezione è principalmente speculazione, ma può aiutare qualcuno. In realtà, il livello di protezione dipende dalla misura in cui uno sviluppatore è disposto a passare (con il minimo vantaggio in termini di sicurezza e crittografia) per proteggere la propria bottom line.