Verifica dell'integrità delle applicazioni Android dal lato server

15

Ho delle applicazioni Android (Mobile banking) che si collegano al mio server e fanno transazioni online (via Internet / USSD / SMS), voglio assicurarmi che quei client non siano manomessi e siano quelli originali distribuiti da me.

Ricorda che non tutti i miei clienti scaricano l'applicazione tramite google play, alcuni utilizzano mercati di terze parti o scaricano l'apk da altrove.

C'è un modo per convalidare l'integrità dell'applicazione (usando un checksum o una firma) sul lato server per assicurarmi che non sia manomessa. (Ad esempio, un trojan non viene impiantato nell'applicazione e quindi ridistribuito)

Per le soluzioni suggerite:

  • Possono essere implementati su tutti e 3 i canali di comunicazione (SMS / USSD / Internet) o le soluzioni sono proprietarie di uno / alcuni canali?

(Sto cercando esattamente la tecnica a cui è stato fatto riferimento in questa pagina: link ):

Chase's servers don't check the integrity of their Android app when it connects to their servers. It is therefore easy to modify the app, adding trojan code that does malicious things. An attacker who can trick people into using the trojaned app can exploit them.

This vulnerability does not affect people who are using the genuine app from the Google Play Store. It would only harm people who are tricked into installing a modified app from a Web site, email, etc.

    
posta Silverfox 31.01.2016 - 18:49
fonte

4 risposte

29

Utilizza Android SafetyNet . È così che Android Pay si convalida da solo.

Il flusso di base è:

  • Il tuo server genera un nonce che invia all'app client.
  • L'app invia una richiesta di verifica con il nonce tramite Google Play Services.
  • SafetyNet verifica che il dispositivo locale non sia modificato e abbia passato il CTS .
  • Una risposta firmata da Google ("attestazione") viene restituita alla tua app con un risultato pass / fail e informazioni sull'APK della tua app (certificato di hash e sigining).
  • La tua app invia l'attestato al tuo server.
  • Il tuo server convalida la firma nonce e APK, quindi invia l'attestato a un server di Google per la verifica. Google controlla la firma di attestazione e ti dice se è autentica.

Se questo passa, puoi essere abbastanza sicuro che l'utente sta eseguendo una versione originale della tua app su un sistema non modificato. L'app dovrebbe ricevere un attestato all'avvio e inviarlo al tuo server con ogni richiesta di transazione.

Nota, tuttavia, ciò significa:

  • Gli utenti che hanno effettuato il root del proprio telefono non supereranno questi controlli
  • Gli utenti che hanno installato ROM / firmware / sistema operativo personalizzati o di terze parti (es. Cyanogen) non supereranno questi controlli
  • Gli utenti che non hanno accesso ai servizi di Google Play (ad esempio dispositivi Amazon, persone in Cina) non passeranno questi controlli

... e quindi non sarà in grado di utilizzare la tua app. La tua azienda deve prendere una decisione commerciale in merito all'eventuale accettabilità di tali restrizioni (e dei relativi utenti sconvolti).

Infine, renditi conto che questa non è una soluzione completamente ermetica . Con l'accesso root e forse Xposed, è possibile modificare la libreria SafetyNet per mentire sui server di Google, dicendo loro le risposte "giuste" per ottenere un risultato di verifica che Google firma. In realtà, SafetyNet sposta semplicemente i pali degli obiettivi e rende più difficile per gli attori malintenzionati. Poiché questi controlli devono essere eseguiti su un dispositivo fuori dal tuo controllo, è davvero impossibile progettare un sistema completamente sicuro.

Leggi un'eccellente analisi di come funzionano gli interni di SafetyNet qui.

    
risposta data 01.02.2016 - 02:38
fonte
20

Questo è impossibile. Chiunque abbia il file APK intero può decompilarlo e creare un clone dannoso che si comporta esattamente nello stesso modo verso il server.

    
risposta data 31.01.2016 - 19:28
fonte
2

Arrivo un po 'in ritardo alla festa, ma penso di poter aggiungere alcune utili informazioni.

Is there a way I can validate the integrity of the application (using a checksum or a signature) on the server side to make sure its not tampered with. (e.g a trojan is not implanted in the application and then redistributed)

Per garantire la massima sicurezza tra la tua app e il server API, dovresti utilizzare un servizio di attestazione dell'integrità delle app mobili insieme alla soluzione SafetyNet, il servizio OAUTH2. Importante è anche l'uso del blocco del certificato per proteggere il canale di comunicazione tra il server API e l'app per dispositivi mobili come descritto in questa serie di articoli sulle tecniche di API per dispositivi mobili.

Il ruolo di un servizio di attestazione dell'integrità delle app mobili è quello di garantire in fase di esecuzione che l'app non sia stata manomessa o non sia in esecuzione in un dispositivo rooted utilizzando un SDK integrato nell'app e un servizio in esecuzione nel cloud.

In caso di attestazione riuscita dell'App Integrity, un token JWT viene emesso e firmato con un segreto che solo il server API della tua app e il servizio di attestazione dell'integrità delle app mobili nel cloud sono a conoscenza.

In caso di errore su Attestity Integrity App, il JWT è firmato con un segreto che il server API non conosce.

Ora l'app deve inviare con ogni API la chiamata del token JWT nelle intestazioni della richiesta. Ciò consentirà al server API di servire solo le richieste quando può verificare la firma nel token JWT e rifiutarle quando fallisce la verifica.

Una volta che il segreto utilizzato dal servizio di attestazione dell'integrità delle app mobili non è noto dall'app, non è possibile eseguirne il reverse engineering in fase di runtime anche quando l'app viene manomessa, eseguita in un dispositivo rooted o comunicante tramite una connessione che è il bersaglio di un Uomo nel Medio Attacco. Questo è dove questo tipo di servizio brilla in relazione alla soluzione SafetyNet.

Puoi trovare questo servizio in Approov che ha SDK per diverse piattaforme, incluso Android. L'integrazione richiede anche un piccolo controllo nel codice del server API per verificare il token JWT al fine di proteggersi dall'uso fraudolento.

Keep in mind that not all of my customers download the application via google play, some of them use 3rd party markets or download the apk from elsewhere.

Con l'uso di un servizio di attestato sull'integrità dell'API mobile come Approov non importa da dove era l'App installato.

I have android applications (Mobile banking) that connect to my server and do online transactions (via Internet/USSD/SMS), I want to make sure those clients are not tampered with and are the original ones distributed by me.

e

For suggested solutions:

Can they be implemented over all 3 communication channels (SMS/USSD/Internet) or are the solutions proprietary to one/some channels?

Quindi, supponendo che la tua App comunichi direttamente con i servizi di terze parti, ti suggerisco di delegare tale responsabilità al server API, che impedirà utilizzo non autorizzato dei servizi di terze parti a tuo nome, una volta che serve solo ora autentiche richieste dall'app mobile che ha superato le sfide di integrità.

SafetyNet

The SafetyNet Attestation API helps you assess the security and compatibility of the Android environments in which your apps run. You can use this API to analyze devices that have installed your app.

OAUTH2

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.

Blocco dei certificati

Pinning is the process of associating a host with their expected X509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host. If more than one certificate or public key is acceptable, then the program holds a pinset (taking from Jon Larimer and Kenny Root Google I/O talk). In this case, the advertised identity must match one of the elements in the pinset.

Token JWT

Token Based Authentication

JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.

Dichiarazione di non responsabilità: lavoro a Approov.

    
risposta data 25.09.2018 - 15:09
fonte
0

Questo problema è qualcosa che i giochi per dispositivi mobili devono affrontare per motivi di reddito, e da quello che posso dire, si occupano di questo aggiornando costantemente l'app, richiedendo all'utente di scaricare e installare una nuova patch ogni volta prima di iniziare il gioco. di solito questa è una piccola quantità. Queste patch aggiungono anche nuovi contenuti al gioco. Le patch gestiscono anche l'aggiornamento, quindi se un'app viene modificata, la patch fallisce.

Quindi in teoria (non sono sicuro di quanto sia accurato), in pratica scrivi un'app all'interno di un'app. L'app interna è l'app che fa il lifting. L'app esterna, ogni volta che viene avviata, scarica una patch / convalida dell'integrità, che prima verifica che le app non siano state manomesse (di solito attraverso un checksum), quindi patch l'app interna, se necessario. È simile a un bootstrap.

Come accennato da Marstato, questo non è ancora perfetto. Ad esempio, un utente malintenzionato può reindirizzare le richieste al proprio server e installare le patch personalizzate in questo modo. Un modo possibile per fare questa convalida dell'integrità prima di ogni transazione, ma sarebbe piuttosto lento.

    
risposta data 31.01.2016 - 23:35
fonte

Leggi altre domande sui tag