Domanda:
Come proteggere un'app mobile dai suoi utenti?
Noureddine
2020-06-08 17:03:56 UTC
view on stackexchange narkive permalink

Ho creato un'applicazione mobile che monitora l'attività dell'accelerometro e in base a questa premia l'utente se viene osservato uno schema specifico. Come posso proteggere l'applicazione contro l'utente stesso che potrebbe tentare di hackerare l'applicazione per segnalare lo schema che sto cercando per ottenere la ricompensa?

Un'altra cosa è che la ricompensa viene data al vincitore alla fine della competizione presso un'agenzia fisica. È possibile che l'agente prima di ricevere il premio controlli se l'utente ha manipolato l'app o meno, ad esempio osservando o confrontando qualcosa nel dispositivo?

https://www.aliexpress.com/wholesale?SearchText=phone+swing
@Coxy Qual è lo scopo di questi dispositivi?
@NumLock un utilizzo è per testare le app di fitness tracker, l'oscillazione del telefono fa sì che il telefono conti i passaggi.È molto utile per sviluppatori e team di controllo qualità testare i loro prodotti con un certo numero di passaggi senza camminare.
Sei sicuro che sia un problema per te?Quando l'utente tradisce se stesso, è colpa sua.Vedo solo un problema quando ricompensi l'utente in un modo che è costoso per te.Perché quando l'utente raggiunge un determinato obiettivo di fitness senza camminare effettivamente, sa che il risultato non è un vero risultato ma solo un inganno.
@allo Sei sicuro che l'utente stia imbrogliando solo se stesso?Ho visto pedometri emessi da società o assicurazioni sanitarie per verificare che un soggetto sia "sano" con incentivi reali per un numero elevato di passi.
Le risposte sembrano non menzionare la possibilità che qualcuno possa costruire un dispositivo per spostare fisicamente il telefono nello schema desiderato.Sarebbe quasi impossibile proteggersi, avrei pensato.
Scrivi la tua candidatura con Malbolge.https://esolangs.org/wiki/malbolge (risposta non seria)
Sette risposte:
ThoriumBR
2020-06-08 18:18:01 UTC
view on stackexchange narkive permalink

Non puoi.

Non appena l'utente ha il dispositivo mobile e la tua applicazione, nulla gli impedisce di decompilare la tua applicazione, capire come funziona & quali dati invia e replicarli. Possono persino imbrogliare usando un congegno che fa ruotare il telefono e fa credere alla tua applicazione che sia un essere umano a usarlo.

Non hanno nemmeno bisogno di decompilare la tua applicazione; devono solo mettere un proxy per intercettare le richieste e capire il protocollo.

Dai commenti:

Se controlli l'hardware, puoi proteggere l'app:

Non proprio. I controlli Apple dal processore all'interfaccia utente dell'iPhone e i jailbreak sono una cosa. Anche se ne controllano ogni aspetto, un giorno qualcuno esegue il jailbreak e il root dell'iPhone e carica la tua app su di esso.

Trasparenza del certificato, blocco delle chiavi

Non utile se il dispositivo è rootato. Il checksum, la firma digitale e la verifica dell'integrità funzionano solo se il sistema operativo non è compromesso. Se l'utente possiede il sistema operativo e il dispositivo, può disabilitare i controlli del sistema operativo, può modificare il binario dell'app e cambiare le istruzioni verificando la firma o il checksum.

Macchina virtuale, offuscamento del codice

Rendono molto più difficile analizzare il codice, ma il codice deve essere eseguito dal processore. Se un disassemblatore non può essere d'aiuto, lo farà un debugger. L'utente può inserire punti di interruzione su parti chiave del codice e col tempo raggiungerà la funzione che controlla il certificato, o il checksum, o qualsiasi controllo di convalida in atto, e può modificare tutto ciò che vuole.

Quindi è inutile provare?

No. Devi soppesare costi e benefici. Solo non contare sulle difese per essere imbattibili, perché ogni difesa può essere battuta. Puoi solo renderlo così difficile che l'attaccante smetta di mettere molte risorse contro la tua app e di ricevere un piccolo vantaggio.

fondamentalmente hai ragione.ma in un approccio pratico potresti fare alcune cose per aumentare la difficoltà connessa con l'app.
puoi rendere sempre più difficile, ma non puoi proteggere nessuna app dall'hacking.Pokemon Go è un buon esempio: utilizzava i sensori del telefono, aveva un'azienda con molta esperienza e denaro e l'app è stata comunque hackerata.
Ho iniziato dicendo che hai ragione.E tu sei.Ma c'è ancora valore nel renderlo più difficile anche se impossibile non è un'opzione.
Corretta!Ma non appena la ricompensa per la rottura del sistema è maggiore del costo, verrà interrotta.A volte sarà rotto "solo per divertimento", ecco perché cercare di proteggere un sistema lato client per lo più non funzionerà.
Anche abbastanza vero.L'impatto su un'azienda è piuttosto variabile, anche se con la quantità di protezione in atto.Da nessuna protezione a incredibilmente difficile è un ampio spettro di potenziale perdita di entrate (e quindi la motivazione a implementare la sicurezza).
Non è possibile intercettare il traffico di un'app se segue i principi di sicurezza di base, come la trasparenza del certificato, tra gli altri.
@CONvid19 Se è in esecuzione su hardware che controlli, puoi farlo, non importa quanto sia efficace nel rispetto dei principi di sicurezza.
@ThoriumBR: Bene, puoi, _se controlli l'hardware_.Prendi Apple Inc, che può effettivamente controllare ciò che le persone eseguono sugli iPhone tramite la firma del codice.Tuttavia, richiede hardware dedicato e molta pianificazione e può ancora essere interrotto.
@JosephSible-ReinstateMonica Anche Apple non può controllare tutto in ogni momento e i jailbreak sono qui per dimostrarlo.Sony ha fatto un buon lavoro con la PS3 e ha impiegato circa 4 anni per essere sconfitta, ma è stata anche sconfitta.
@CONvid19 Niente impedisce all'utente di cambiare un "JNZ" in "JZ" sul codice e procede quando il certificato non corrisponde.O modificando il file binario e bloccando il proprio certificato.O "NOP" l'intera funzione di controllo.La sicurezza lato client fallirà sempre se si dà abbastanza tempo e motivazione.
@ThoriumBR Intendevo "controllo" come in "possesso fisico di".
@JosephSible-ReinstateMonica in questo caso, è possibile.Ma nel caso di OP, non sarebbe molto utile se l'utente non avesse il dispositivo che registrerà i propri movimenti ...
@ThoriumBR Giusto, questo è il punto.Sono d'accordo con la tua risposta.
Immagino che la domanda sia: quando viene hackerato una volta, è aperto a tutti tramite la condivisione delle informazioni o ogni utente dovrebbe hackerarlo da solo?In quest'ultimo caso immagino valga la pena renderlo più difficile, mentre nel primo caso potrebbe non esserlo?
@bob ha violato una volta, ha violato per sempre fino a quando non rilasci una nuova versione che tappi il buco, o cambi il protocollo o qualsiasi altra contromisura.È difficile mantenere i segreti ora.
@ThoriumBR quindi sì, in questo caso sembra che non valga la pena cercare di prevenire.
MechMK1
2020-06-08 18:40:27 UTC
view on stackexchange narkive permalink

Anche se generalmente sono d'accordo con la risposta di ThoriumBR, ci sono alcune cose che puoi fare.

Ad esempio, puoi analizzare il comportamento dell'utente per discrepanze, come:

  1. Dati ovviamente riprodotti

    Ad esempio, un utente potrebbe agire nel modo desiderato, quindi acquisire ha inviato i dati e riprodurli nuovamente in un secondo momento. Questo può essere determinato abbastanza facilmente, dato che i dati del sensore rumorosi sembrano essere gli stessi, cosa che non accadrebbe mai in un caso d'uso reale.

  2. Ovviamente falsi Dati

    Ad esempio, un utente potrebbe segnalare falsi dati del sensore. Questi dati probabilmente non sarebbero abbastanza casuali. Ad esempio, invece di riportare una posizione di 48,7849165 ° N; 27,4159014 ° W , il punto dati falsificato potrebbe essere 48,78 ° N; 27,42 ° W .

  3. Pattern simili a macchine

    Ad esempio, un utente potrebbe scrivere un programma che invia automaticamente rumorosi e "corretti -looking "dati sempre alla stessa ora del giorno. Questo sembra sospetto, in quanto fondamentalmente nessun utente sarebbe così preciso.

Naturalmente, non puoi vedere questi esempi come un elenco esaustivo. Sono qui solo per servire come esempi del tipo di modelli che puoi rilevare. Addestrare il tuo sistema a rilevare le anomalie è molto più difficile nella pratica e sarà probabilmente più difficile da implementare che convivere con il fatto che alcune persone imbrogliano.

Poiché la domanda è stata modificata dopo la pubblicazione della risposta: è possibile eseguire un'analisi più approfondita del set di dati dei vincitori per vedere se si verificano irregolarità. In questo modo, dovresti solo eseguire analisi sui set di dati che realmente contano per te come azienda.

Come Falco ha menzionato nei commenti, aggiungendo una dichiarazione di non responsabilità come "I tuoi invii verranno analizzati per prevenire frodi "potrebbe impedire ad alcune persone di inviare invii falsi.

Come potresti rilevare gli attacchi di replay senza registrare, salvare e cercare i dati grezzi?Sembra abbastanza poco pratico.
@jpaugh è esattamente quello che facciamo per la nostra app: sono solo molti dati, non è esattamente poco pratico e una volta ottenuto un modello per l'aspetto "reale" dei dati, è possibile individuare i dati "falsi" basati sul modello e scartarne altrii dati di supporto.
@jpaugh È difficile e richiederà il salvataggio di molti dati.Inoltre, non voglio fingere che l'analisi delle anomalie sia la base di tutto, dal momento che richiede un sacco di dati e analisi e molto probabilmente sarà una cosa troppo grande per la maggior parte delle piccole aziende che cercano di farlorilascia una o due app.
Puoi vedere i pro ei rischi di rilevare e agire su queste discrepanze nei giochi, dove la frode e il rilevamento e la prevenzione non sono rari.Ci sono alcune tabelle dei punteggi più alti con punteggi chiaramente impossibili (ad es. Finire un livello in 0,0001 secondi) e ci sono alcuni casi in cui alcuni giocatori sono banditi solo per giocare normalmente.
Penso che sottovaluti i problemi della vita reale con hardware diverso.Dati "troppo esatti"?Non sai cosa potrebbe fare il firmware del telefono su un telefono che non hai mai usato.Non è nemmeno così stupido effettuare il denoising dei dati sulla posizione inesatti, perché perché le app dovrebbero fare affidamento sul quinto posto dopo la virgola, quando la lettura del sensore è accurata solo per due punti?
L'OP ha un caso speciale, in cui c'è solo uno (o pochi) vincitori e saranno fisicamente presenti e potrebbero essere citati in giudizio per barare.- Se registri i dati sul dispositivo e li carichi periodicamente sul cloud, devi solo controllare la correttezza dei dati, una volta che una persona dichiara di essere un vincitore e firma il modulo "Prometto di non aver barato e sedovevo all'azienda $ 1000 di risarcimento danni "quando riscuoti il loro prezzo e poi controlla i suoi dati.- La maggior parte delle persone non proverà a imbrogliare, se c'è un rischio reale di essere scoperti dopo il fatto.
@Falco Tutte queste informazioni sono state aggiunte dopo che questa risposta è stata scritta
@MechMK1 Penso che questa risposta potrebbe essere migliorata, aggiungendo un piccolo paragrafo alla fine.Dal momento che la soluzione proposta sembra ideale per la situazione dei PO, poiché l'analisi non deve essere eseguita su tutti i dati, ma solo sui set di dati dei vincitori - e anche solo divulgare le informazioni "i tuoi dati saranno analizzati per prevenire la frode" dovrebbe vietarela maggior parte degli imbroglioni
DennisFrett
2020-06-09 11:55:50 UTC
view on stackexchange narkive permalink

Pur essendo d'accordo con le altre risposte, trovo che ci siano alcune cose pragmatiche che vengono trascurate.

Divulgazione completa: lavoro per un'azienda che costruisce software di offuscamento / protezione per applicazioni mobili.

Non è possibile una protezione completa e indistruttibile per un'app in esecuzione su un dispositivo controllato da un utente malintenzionato. Tuttavia, esiste un software che mira ad alzare il livello e rende meno / non utile per una persona effettuare un attacco.

In genere queste soluzioni coprono due aspetti

Statico protezione

Questo di solito include una serie di tecniche di offuscamento che mirano a rendere difficile per un utente malintenzionato che vuole analizzare un'applicazione mobile esaminando i binari utilizzando strumenti come IDA Pro, Ghidra e Hopper.

Le tecniche qui sono l'offuscamento del flusso di controllo, l'offuscamento semantico (classe, metodo, ... nomi), l'offuscamento aritmetico, la crittografia delle stringhe, la crittografia delle classi, ...

Questi lo rendono molto difficile "sbirciare" all'interno di un binario e capire cosa sta succedendo, ma non offrire molta protezione quando un utente malintenzionato guarda l'applicazione mentre è in esecuzione sul dispositivo stesso.

Protezione dinamica

Si tratta di tecniche di protezione che mirano a proteggere un'applicazione dall'analisi o dalla modifica durante l'esecuzione sul dispositivo. Gli strumenti popolari qui sono debugger (lldb, gdb, ...) e framework di hooking (Frida, Cydia Substrate, ...).

Qui le tecniche cercheranno di bloccare / rilevare l'uso di questi strumenti, rilevare ambienti di esecuzione manomessi (dispositivo jailbroken / rooted, emulatori), modifiche apportate all'applicazione e molto altro.

Conclusione

Sebbene sia della massima importanza garantire che la tua applicazione sia stata creata utilizzando pratiche di sicurezza ben definite (il software di offuscamento / protezione non ti aiuterà qui!), esistono strumenti che possono funzionare come un gruppo di shell attorno alla tua applicazione che insieme rendono molto più difficile, e si spera non utile, violare la tua applicazione.

Potresti anche creare una macchina virtuale all'interno dell'app, per eseguire operazioni critiche lì, che offre una certa protezione contro gli attacchi statici e dinamici.
Trovo triste che la sicurezza per oscurità debba essere una cosa così importante ... Non che non sia utile.Vorrei solo che ci fosse una soluzione più ... * robusta * per impedire all'utente di fare qualsiasi cosa con il tuo codice. Immagino che avrei dovuto essere un ingegnere civile piuttosto che uno software.I passanti non sono molto propensi a strappare un ponte solo per evitare di dover pagare il pedaggio :-(
@Mathieu VIALES, ci sono alcuni cambiamenti in corso di implementazione anche su questo fronte.Puoi dare un'occhiata a Intel SGX, ARM TrustZone, che sono implementazioni hardware.Conosco anche idee accademiche basate su hypervisor che cercano di fornire una sicurezza significativa sui dispositivi infettati da malware.Ovviamente non è una soluzione completa contro un dispositivo controllato da un utente malintenzionato, ma offre alcune garanzie extra.
@DennisFrett Sembra piuttosto interessante!Mi assicurerò di cercare SGX e zona di fiducia.Sembra abbastanza promettente. per quanto riguarda i dispositivi controllore attaccante, immagino che non ci sarà mai una soluzione effettiva fintanto che il codice in qualsiasi forma è sempre presente sui dispositivi dell'attaccante: - /
Nitpick, ma: come si passa dal "dispositivo dell'utente finale" a "controllato da un utente malintenzionato"?Sia l'audit di un pezzo di software che la risoluzione dei problemi / sandbox sono pratiche legittime, anche se spesso noiose.Nel mio libro, interferire con applicazioni non correlate sulla macchina dell'utente ti renderebbe l'attaccante.
Non sono d'accordo con l'idea che tutto questo lavoro per un piccolo guadagno sia una cosa negativa.Dover installare software closed source a livello di kernel per assicurarti di non imbrogliare in un videogioco è idiota.Preferisco avere a che fare con gli imbroglioni piuttosto che con il software dannoso.
@MathieuVIALES anche il bridge non è di proprietà dei passanti, il telefono lo è.Quindi sono soprattutto le loro cose che si stanno temperando - e sebbene ci siano alcuni argomenti per i contratti che determinano come un software può essere utilizzato (ad esempio, non per hackerare un'altra macchina senza il consenso del proprietario, ecc.) Molti modelli di business / aziende ci provano troppo duramenteper controllare come il loro software viene utilizzato sui dispositivi di altre persone.Sarebbe ridicolo se qualcuno cercasse di assicurarsi che non puoi usare un cacciavite a taglio per viti philipps.
@MathieuVIALES C'è un'area grigia nel mezzo?Certo, ma l'allegoria del ponte viene da un punto di vista estremo, potrebbe essere il tuo codice ma è il loro dispositivo e hanno concesso in licenza il tuo codice in cima, quindi nel mio libro possiedono circa tre quarti del dire cosa fare con la combinazione ditutti e due.
8vtwo
2020-06-09 01:35:40 UTC
view on stackexchange narkive permalink

È in qualche modo possibile.

Invia semplicemente i dati registrati a un server remoto che esegue il controllo del pattern. Assicurati che ci sia un ritardo tra l'osservazione di uno schema corretto e la ricompensa. Sarà molto difficile capire esattamente quale modello viene abbinato.

Se lo combini con l'euristica che rileva l'attività riprodotta e bandisce i trasgressori, ci sono buone probabilità che tu possa sostenere questo tipo di modello.

Ciò presuppone che l'utente non possa sapere nulla del pattern, ad es.quale attività dovrebbe causarlo e poche possibilità di approssimarlo.Quando si lavora con i dati del sensore della vita reale, è probabile che una leggera modifica casuale dei dati registrati abbia buone probabilità di rientrare nei parametri accettabili del modello.
Possono sapere qual è * parte * del modello, ma non tutto.Ad esempio, se lo schema è semplicemente lanciare il telefono in aria: inviando l'intero flusso di dati da remoto puoi anche controllare i dati prima e dopo l'evento noto.Come il "wind up" e il "catch".Quindi puoi controllare per assicurarti che tutte queste cose corrispondano in modo appropriato e siano uniche ogni volta.
Ciò non mi impedisce, ad esempio, di registrare dieci lanci, di aspettare per quanto a lungo la risposta, distorcendo leggermente l'intero set di dati, sminuzzandolo tra i lanci e poi rimandandolo indietro in ordine casuale.Dopotutto, le letture dell'accelerometro non sono un rumore bianco casuale.Qualunque modello ti aspetti è vincolato dalla fisica dell'attività che desideri rilevare e dalla precisione delle misurazioni.E non puoi nemmeno inserire facilmente nella lista nera gli utenti perché otterrai letture non corrispondenti tutto il tempo.
Penso che tu stia sottovalutando la difficoltà di distorcere * accuratamente * l'intero set di dati e riprodurre un set di dati completamente nuovo che corrisponde correttamente al comportamento di un utente normale.L'utilizzo della corrispondenza di modelli lato server offre un'enorme quantità di dati che è possibile analizzare.Tutto ciò che accade dall'apertura dell'app al pattern di destinazione può essere esaminato.Gli algoritmi di apprendimento automatico sono molto bravi a distinguere tra modelli reali unici e quelli che presentano qualsiasi tipo di anomalia.I punti in cui "tagli" i lanci apparirebbero sospetti se la transizione non fosse fluida.
@RutherRendommeleigh a sostegno di questa risposta, vedere le tecniche utilizzate da Uber per prevenire lo spoofing GPS qui https://eng.uber.com/advanced-technologies-detecting-preventing-fraud-uber/ È una soluzione comunemente adottata nel settore.Ovviamente non è infallibile.
@goncalopp Direi che i tipi e la quantità di dati che Uber raccoglie, così come le risorse che possono lanciare al problema, sono probabilmente fuori portata per lo scenario di OP.Se * richiedono * dati di posizione costanti e l'app è abbastanza complessa da produrre modelli di utilizzo distinti, abbastanza equo.D'altra parte, perdi utenti che non acconsentono alla sorveglianza 24 ore su 24, 7 giorni su 7.
goncalopp
2020-06-10 11:57:24 UTC
view on stackexchange narkive permalink

Più frequentemente negli ultimi anni, la soluzione sicura suggerita a questo problema si chiama attestazione remota.

In breve, questo significa eseguire le parti critiche per la sicurezza della tua applicazione in un'area separata della CPU che ne garantisce l'integrità (tramite key escrow sull'hardware) e consente a un server remoto di confermarlo.

Per quanto ne so, non c'è modo pratico e infallibile per farlo per un'app mobile sviluppata in modo indipendente a partire dal 2020. Ma esistono già API per verificare che il sistema non sia stato manomesso e poiché sempre più telefoni includono TPM / TEE, penso che sia ragionevole aspettarsi che sia generalmente disponibile nel prossimo futuro. È attualmente utilizzato in Google Pay, ad esempio.

Avvertenze importanti:

  • Ciò impedisce l'esecuzione dell'applicazione sui telefoni controllati (" posseduto "?) dall'utente finale (es: telefoni rooted / jailbroken). Può essere considerato una forma di DRM ed è controverso (vedere la relativa controversia sull'avvio sicuro sui PC)
  • Dovrai estendere il tuo TCB per includere i produttori di CPU e il fornitore di sistemi operativi.

Le persone hanno un'ampia varietà di opinioni su questi avvertimenti, i due estremi sono "irrilevanti nella pratica" per " rendere la tecnologia peggiore che inutile ".

Questo è copiato dalla mia risposta qui

Non importa dove viene eseguito il software: riceve comunque i dati da qualche parte.Imposta un falso sensore di movimento / contapassi e il tuo programma elaborerà e invierà dati falsi in modo molto sicuro.
Eric Johnson
2020-06-10 22:25:47 UTC
view on stackexchange narkive permalink

Altri hanno risposto riguardo alle protezioni software, ma un attacco può verificarsi anche a livello hardware.

Ad esempio, se un telefono ha un accelerometro IC che si trova sul PCBA, la maggior parte di questi sensori trasmetterebbe su un bus SPI o I2C standard con i dati grezzi e nessun tipo di crittografia. Potrebbe essere possibile per un utente malintenzionato rimuovere il sensore esistente e inviare dati falsi sul bus dati. Sarebbe impossibile per il software del telefono rilevare qualsiasi modifica alla modalità operativa normale poiché non è stata apportata alcuna modifica al software. Pertanto sarebbe impossibile prevenire un aggressore motivato.

Ora potrebbero esistere alcune attenuazioni come rilevare se il dispositivo è stato inserito o utilizzare un sensore che crittografa la comunicazione / autentica l'IC come autentico, ma dato che un telefono cellulare è un prodotto di base (almeno per Android) sarebbe possibile trovare un telefono che non lo ha fatto.

Daniël van den Berg
2020-06-11 11:44:12 UTC
view on stackexchange narkive permalink

Oltre a tutte le altre risposte menzionate, un modo "semplice" per proteggersi dall'hacking è semplicemente non avere la logica all'interno della tua app.

Nell'app, vuoi solo fare due cose.

  1. Leggere i dati
  2. Visualizzare i dati

Nel momento in cui provi a elaborare i dati sul dispositivo, sei condannato e l'app verrà compromessa. Invece, invia tutti i dati grezzi a un server (ovviamente questo comporta i suoi rischi per la sicurezza, ma quelli sono più facili da mitigare). Su questo server puoi eseguire tutta l'elaborazione dei dati in modo sicuro, poiché è sotto il tuo controllo.

Un altro vantaggio di questo approccio è che rende molto più facile rilevare gli utenti maligni. Hai detto che questa app deve essere utilizzata per una competizione. Sul tuo server potrai, al termine della competizione, semplicemente confrontare i dati di movimento con i dati di altri utenti. Se tutti gli utenti mostrano uno schema con diciamo 8 ore di sonno e un utente mostra uno schema che richiederebbe loro di essere svegli 24 ore su 24, 7 giorni su 7, sai che è falso. Ma su questo aspetto MechMK1 ha già dato un'ottima risposta, solo che ora puoi combinare anche più utenti.



ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...