Italian Reverse engineering, sicurezza connessioni, ridurre rischio

[calsdn]

Sappiamo che il file apk può essere 'decompilato' e quindi tutto ciò che usiamo, inserito nel codice, come username e password per collegarsi a qualunque cosa sulla rete può venire carpito e potrebbe essere usato in modo improprio per non dire altro. L'offuscamento rende solo più difficile il processo di reverse e quindi non risolve il problema.

Che strategie avete adottato per ridurre il rischio o annullarlo?
Ad esempio una connessione Rdc, http, Ftp, Pop3, Smtp?
Come avete eventualmente alzato la sicurezza lato server per le vs app?

Una password che il cliente digita all'ingresso della app, usata poi per decifrare un file contenente info di accesso ai servizi esterni necessari all'app, può essere una strada percorribile? non ridurrebbe l'appeal o la user experience nell'uso dell'app?
Avete risolto in modo diverso?

 

[valentino s]

Spostare tutto lato server, se non ti fidi dell'app.

Io penso di sviluppare qualcosa nei prossimi tempi che gestisca lato server tutto, ma scarichi sulla app una password specifica per il singolo device (con i problemi di avere piu' device quindi), generata automaticamente dal server e memorizzata sul telefono per accedere direttamente. Password che si va ad aggiornare ogni tot da sola, in modo da non usare mai le credenziali dell'utente per i successivi login.

Per il resto ssl sul sito.

La password temporanea sul device puo' essere crittografata ,credo, non ho provato ma non vedo controindicazioni

v.

 

[LucaMs]

Il problema principale è che in qualunque modo tu autentichi il tuo utente sul server, alla fine il tuo server concederà dei permessi all'app per fare qualcosa anche in locale.

Intendo dire che se dal server l'app riceve l'ok, avrai del codice tipo:

If ServerMiHaDatoOk Then
    FaccioQuesto
Else
    msg("non autorizzato","")
End If

Un hacker bypassa quell'istruzione If e tutto lo studio sull'autenticazione è servito a niente.

 

[LordZenzo]

se il problema e` per un app bancaria dove bisogna essere assolutamente certi dell'identità` del utente basta inviare un sms con un codice verso un telefono indicato in fase di iscrizione, il codice viene inserito a mano e siamo sicuri che non c'e` frode, almeno questo fanno alcune banche e penso che loro il problema lo abbiano studiato affondo
se invece serve per un giochino stupido e pure gratis, allora non serve affatto nulla
per le vie di mezzo, scrivete codice confusionario e pieno di GoTo cosi all'hacher viene una crisi di nervi e lascia stare

 

[udg]

Aggiungo un'accortezza ulteriore agli ottimi spunti qui presenti.
Per le app destinate ad un cliente "di peso" , abbiamo implementato un sistema di autenticazione a due livelli. L'app contiene il riferimento (IP o dominio) di un server che svolge il ruolo che definiamo dispatcher (in pratica un routing) e in fase di login invia in https una terna: utente, password (md5/sh256) e codice azienda (potrebbe essere un qualunque altro dato).
Il dispatcher grazie alla terna svolge due compiti: ricava da una sua tabella il riferimento al server che ospita i dati di quell'azienda e su quel server verifica correttezza credenziali e validità (es. utente sospeso, scaduto, etc). Al termine ritorna all'app un codice di errore e se questo è zero anche il riferimento al server corretto.
Da quel momento l'app invia al server corretto (il cui riferimento è presente solo in una var globale e non viene mai salvato in locale) una serie di comandi sulla falsariga di quanto fa RDC/RDC2, quindi qualcosa tipo <comando, parametri> ed attende in risposta un pacchetto del tipo <codice errore, payload di risposta> dove il secondo elemento varia in funzione del comando inviato.

A cosa serve questo livello extra? In primo luogo diviene possibile spostare il DB relativo ad un'azienda su un diverso server in ogni momento senza modificare le app mobile già distribuite ed inoltre concorre a consentire una distribuzione del carico tra più server (aziende 1..20 sul server1, aziende 21-50 sul server2, etc).
In più, disassemblando l'apk si troverebbe solo il riferimento al dispatcher e non al server destinatario dei comandi per una determinata azienda.

Direi che i punti deboli in chiave sicurezza alla fine sono: apk, dati locali, trasmissione dati mentre il server lo consideriamo generalmente sicuro (se il sistemista sa dove mettere le mani e aggiorna regolarmente sistema e librerie varie).

Per una soluzione più completa del problema "sicurezza" esiste una guida a pagamento di Informatix di cui molti si sono detti soddisfatti. Personalemnte non ho ancora avuto modo di acquistarla quindi mi limito a riportare il riscontro generale di cui ho letto.

udg

 

[LucaMs]

scrivete codice confusionario e pieno di GoTo cosi all'hacher viene una crisi di nervi

e pure a noi programmatori, però

 

[LucaMs]

Il sistema architettato da @udg è sicuramente utile per quanto riguarda il suo primo scopo, ovvero distribuire su vari server i dati delle aziende, ma riguardo alla sicurezza non mi pare molto sicuro.

In più, disassemblando l'apk si troverebbe solo il riferimento al dispatcher e non al server destinatario dei comandi per una determinata azienda.

Potrebbe cmq hackerare l'app ed inviare (non gli interessa sapere dove e quale sia il server) qualunque comando falso.

e in fase di login invia in https una terna: utente, password (md5/sh256) e codice azienda

Sniffer.

 

[LucaMs]

Secondo me c'è una sola conclusione: se esistesse un metodo sicuro (e non può esistere, trattandosi di telematica-informatica), Trump non sarebbe stato eletto.

 

[udg]

Potrebbe cmq hackerare l'app ed inviare (non gli interessa sapere dove e quale sia il server) qualunque comando falso.

No. Lo scopo dei due server è proprio questo. Disassemblata l'app ottieni l'indirizzo del dispatcher e quindi di un server che non è deputato a ricevere comandi diversi dalla sola fase di autenticazione. Quello che potresti fare è inviare infinite triple finchè non scopri una combinazione valida e quindi essere in grado, da quel momento, di impersonare uno specifico utente di una specifica azienda (o comunque riferito a ciò che significhi il terzo parametro).

Es.
dispatcher attivo su 171.2.34.12
terna valida-> user: uno; password: due; azienda: tre
risposta del dispatcher: 154.33.12.12

Da questo momento per interagire con il DB dell'azienda "tre" invio comandi e richieste a 154.33.12.12, indirizzo che non potevi ricavare disassemblando l'apk.

Sniffer.

Lo scopo della terna non è rendere più sicura l'autenticazione. Come dicevo uno dei punti deboli è la trasmissione dei dati e l'utilizzo del protocollo https aiuta in questo senso, ma nulla impedisce di adottare altre misure, dalla crittazione all'invio frammentato dei dati.

In genere non può esistere una sicurezza assoluta, ma rendere poco conveniente cercare di aggirare le protezioni si può fare. Al di là dello sfizio, credo che nessuno di noi passerebbe giornate e nottate (avendone le piene competenze) per aggirare sistemi di sicurezza a protezione di un software venduto a $1 per una base di 100/1000 utilizzatori.. senza contare l'aspetto legale della questione!

 

[calsdn]

No. Lo scopo dei due server è proprio questo. Disassemblata l'app ottieni l'indirizzo del dispatcher e quindi di un server che non è deputato a ricevere comandi diversi dalla sola fase di autenticazione. Quello che potresti fare è inviare infinite triple finchè non scopri una combinazione valida e quindi essere in grado, da quel momento, di impersonare uno specifico utente di una specifica azienda (o comunque riferito a ciò che significhi il terzo parametro).

... snip

Da questo momento per interagire con il DB dell'azienda "tre" invio comandi e richieste a 154.33.12.12, indirizzo che non potevi ricavare disassemblando l'apk.

Lo scopo della terna non è rendere più sicura l'autenticazione. Come dicevo uno dei punti deboli è la trasmissione dei dati e l'utilizzo del protocollo https aiuta in questo senso, ma nulla impedisce di adottare altre misure, dalla crittazione all'invio frammentato dei dati.

... snip

Avevo già a suo tempo implementato una soluzione del genere in ambiente Windows proprio per dividere i carichi dei server remoti, ma solo per questo.
Non pensavo allora alla sicurezza ...

Nell'ottica di ridurre il rischio di accessi a host 'critici' mi pare veramente una buona strada.
Certo se poi implementiamo https e cifratura mi pare che il rischio 'compromissione' sia ancora di più ridotto.

Grazie Udg (buona annata il 64 )

 

[Star-Dust]

No. Lo scopo dei due server è proprio questo. Disassemblata l'app ottieni l'indirizzo del dispatcher e quindi di un server che non è deputato a ricevere comandi diversi dalla sola fase di autenticazione. Quello che potresti fare è inviare infinite triple finchè non scopri una combinazione valida e quindi essere in grado, da quel momento, di impersonare uno specifico utente di una specifica azienda (o comunque riferito a ciò che significhi il terzo parametro).

Es.
dispatcher attivo su 171.2.34.12
terna valida-> user: uno; password: due; azienda: tre
risposta del dispatcher: 154.33.12.12

Da questo momento per interagire con il DB dell'azienda "tre" invio comandi e richieste a 154.33.12.12, indirizzo che non potevi ricavare disassemblando l'apk.


Lo scopo della terna non è rendere più sicura l'autenticazione. Come dicevo uno dei punti deboli è la trasmissione dei dati e l'utilizzo del protocollo https aiuta in questo senso, ma nulla impedisce di adottare altre misure, dalla crittazione all'invio frammentato dei dati.

In genere non può esistere una sicurezza assoluta, ma rendere poco conveniente cercare di aggirare le protezioni si può fare. Al di là dello sfizio, credo che nessuno di noi passerebbe giornate e nottate (avendone le piene competenze) per aggirare sistemi di sicurezza a protezione di un software venduto a $1 per una base di 100/1000 utilizzatori.. senza contare l'aspetto legale della questione!

UN sistema simile lo adottò anni orsono Microsoft Messenger (buonanima) con un autenticazione al server principale che tu chiami dispatcher. Il dispatcher ti inviava un codice che univi a username e password e inviavi in MD5. lui ti restituiva un indirizzo IP di uno dei loro server. Il dispatcher mandava al server a cui dovevi connetterti il tuo indirizzo IP e il codice. Se non ricordo male connettendoti a quell'indirizzo dovevi reinviare il codice iniziale, perché il secondo server verificava il tuo IP e il codice che ti avevano inviato.

Non so se migliorava la sicurezza , certo é che il secondo server non ti dava accesso a un bel niente se non avevi un IP validato e il codice.


All'epoca trovavi molte guide che ti spiegavano il protocollo e come crearti un Client Alternativo e in effetti si trovavano molti di questi Client (Trillian in prima fila). QUalcuno lo trovavi realizzato in VB6 con tanto di codice sorgente. E vi posso garantire che funzionavano e ritoccando il codice riuscivi .....

(il '73 é stata un annata migliore)

 

[calsdn]

All'epoca trovavi molte guide che ti spiegavano il protocollo e come crearti un Client Alternativo e in effetti si trovavano molti di questi Client (Trillian in prima fila). QUalcuno lo trovavi realizzato in VB6 con tanto di codice sorgente. E vi posso garantire che funzionavano e ritoccando il codice riuscivi .....

ok, ma chi utilizzava client alternativi aveva comunque le corrette credenziali per accedere al sistema.
Poi forse qualcuno si divertiva anche ...

(il '73 é stata un annata migliore)

tsk tsk tsk ... senza offesa

 

[LucaMs]

Da questo momento per interagire con il DB dell'azienda "tre" invio comandi e richieste a 154.33.12.12, indirizzo che non potevi ricavare disassemblando l'apk.

e mica mi serve conoscere l'indirizzo, trovo il punto dell'app in cui inviare i comandi e li invio. Il punto è che se questi comandi sono solo un nome procedura e parametri, perché il codice eseguibile sta sul server, al massimo posso creare danni per divertimento, non per ottenere qualcosa. Ma ad esempio per un'azienda concorrente questo è già sufficiente.

 

[udg]

e mica mi serve conoscere l'indirizzo

è questo l'aspetto che non riesco a cogliere. Guarda qui di seguito un pezzo di codice di esempio

Log("sync avviato")
SyncOk = False
'richiesta tabella unm aggiornata
Dim Parameters As Map             
Parameters.Initialize
Dim buffer() As Byte
buffer=DBData.PrepareCommand(Parameters,25)   
Dim pJob As HttpJob
pJob.Initialize("unm", Me)
pJob.PostBytes(Main.hurl&"/abc2",buffer)

Main.hurl corrisponde al server 154.33.12.12 restituito dal dispatcher. Se non lo conosci, come fai ad inviare "ad capocchiam" il comando 25 giusto per dare fastidio?

udg

 

[LucaMs]

Se non lo conosci, come fai ad inviare "ad capocchiam" il comando 25 giusto per dare fastidio?

Così, no? Uso Main.hurl

pJob.PostBytes(Main.hurl&"/abc2",buffer)

 

[udg]

Main.hurl viene valorizzato solo se la fase iniziale di autenticazione ha esito positivo. Questo vuol dire che hai bisogno di una terna valida e di esguire la prima parte di codice. A quel punto, nella risposta del dispatcher, hai il riferimento al secondo server da registrare nel Main.hurl e utilizzare nel seguito.
Per questo dicevo che il solo disassemblare l'apk non serviva a nulla.

 

[Star-Dust]

Basta sniffare una connessione di un client e vedi con quali server si connette

 

[udg]

Vero. Anche se in quel caso rischi di inviare comandi errati e quindi non eseguiti. Come dicevo il terzo valore della terna non è detto sia un codice azienda. Potrebbe identificare un'app in modo che un unico oggetto lato server sia in grado di servire più app completamente diverse tra loro.
Edit: come dire che il comando 25 significa una cosa per l'app1 ed una completamente diversa per l'app2

Ad ogni modo, la questione era semplicemente quella di sottolineare che nell'apk non si trovava direttamente il riferimento al server che esegue i comandi ma si introduce un livello extra per obbligare ad un maggior sbattimento il "pirata".
Pensiamo al caso di un pirata che abbia copia del sw (magari preso dal GPlayer) ma non conosca un possibile cliente che lo utilizzi e quindi non sappia quale rete cercare di "bucare" per poter sniffare del traffico. A quel punto, l'accorgimento sarebbe utile perchè il pirata non saprebbe cosa farsene del codice, mentre se trovasse nel codice il riferimento al vero server avrebbe subito la possibilità di fare danni.

udg

 

[calsdn]

Riprendo il thread per aggiungere un ulteriore livello di 'sicurezza' ovvero accertare che il client sia il tuo apk e niente altro.

Stavo pensando a come il 'server dispatcher' possa capire che il client apk che si mette in contatto sia quello giusto ovvero il mio.
Per impedire di fatto a qualsiasi altra app a connettersi ai service remoti.

Credo che qualsiasi cosa possa ricevere il server dal client (di suo) non dia garanzia.
La copia username e password garantisce solo le credenziali di chi le ha ricevute (la persona) non che l'apk è il tuo. Possono essere carpite.
Altre cose che si inseriscono nell'apk, per quanto le si nascondino, un buon hacker le può trovare e le può usare nella sua app per smarronarti i service remoti.

Stavo pensando ad uno script che il server invia al client e che lo esegua e calcoli la firma (hash) del client e invii poi al server il risultato il quale lo confronta con le firma depositata del tuo apk se ok allora è il tuo app che sta eseguendo il collegamento.

E' una complicazione inutile o avrebbe un senso?
Avete altre idee o perseguito altre strade?

 

[Star-Dust]

Se parliamo di client alternativi secondo me è davvero difficile distinguerli. Perché ogni tipo di identificazione che può richiedere il server il client può sempre falsificarla.

Tornando a MSN Messenger, aveva un sistema che cercava di identificare il client ma non è mai stato sufficiente.

Alcuni che usano il browser come client, verificano il s.o. e la versione, quale browser usano e la versione, da li identificano qual è il dispositivo che si collega, ma tristemente anche questo potrebbe essere falsificato.

Non saprei... Però molti programmi che scansionano la rete riescono a identificare i dispositivi connessi, sfruttando un qualche servizio (vedi https://play.google.com/store/apps/details?id=com.overlook.android.fing o il grande ZANTI https://www.zimperium.com/zanti-mobile-penetration-testing) .... Credo che potresti capire in questo modo almeno il s.o. se non anche il dispositivo.