Ammetto di non aver mai approfondito in maniera adeguata la sicurezza delle applicazioni Mobile sul blog, sia per poco interesse da parte mio, sia per mancanza di tempo, ma ho deciso di scrivere una mini guida abbastanza approfondita in modo che chiunque possa iniziare a capirne il funzionamento, la metodologia e chissà, magari appassionarsi all’argomento.
Per chi non avesse nessun’infarinatura, consiglio Come Funziona un’applicazione Android e Introduzione alla sicurezza di un’applicazione Android, anche se ne potete trovare altri nella categoria Mobile.
Nel seguente articolo utilizzerò un telefono rootato, con al suo interno Xposed con i moduli:
- Inspeckage
- SSLUnpinning
- Rootcloack
L’applicazione in oggetto sarà InsecureBankv2.
NB: se non avete un secondo telefono per fare i test, non fatelo sul vostro principale, in quando il root, se non utilizzato con criterio, riduce di molto la sicurezza del dispositivo e rischia di essere vulnerabile a particolari attacchi. Se volete potete crearne uno virtuale, seguendo questa guida o direttamente quella di Android.
Setup dell’ambiente
Per prima cosa, dobbiamo configurare il telefono in modo tale che possa dialogare con la nostra Kali. Io, utilizzando una macchina virtuale, l’ho connessa in modalità Bridged in modo tale che esponga l’indirizzo IP direttamente sulla rete Wifi.
Dopo aver aperto Burp, imposto il proxy sull’indirizzo IP della rete
Sul telefono, basterà andare in Impostazioni -> Wifi, tener premuto sul Wifi a cui siamo connessi (dipende dalla versione che avete) e cliccare su Modifica. All’interno del menu, impostate il proxy Manuale, inserendo l’indirizzo IP di Burp
Una volta impostato, basterà importare il certificato di Burp seguendo questa guida di PortSwigger.
Per installare l’applicazione utilizzerò per comodità adb, quindi dopo aver collegato il telefono con il suo cavo alla macchina virtuale, e digitato
Avremo la nostra applicazione installata. Avviate sulla Kali AndroServer (il server dell’applicazione) con il comando
python app.py
E voilà, avremo il nostro ambiente pronto per essere testato!
Analisi statica
L’analisi statica, come si evince dal nome, è la fase in cui si analizza il file apk, sia manualmente, sia con tool automatici, al fine di poter trovare vulnerabilità o misconfigurazioni.
Per prima caso andremo ad analizzare il file con MobSF, il quale permette di farsi un’idea iniziale e iniziare a comprendere l’applicazione.
Le informazioni che possiamo ottenere sono:
- l’analisi del manifesto (AndroidManifest.xml) dove sono esplicitamente segnalate le attività che il file esegue
Che possiamo anche trovare in basso
- L’analisi del codice, che in questo caso non è disponibile
- L’analisi del file
- Le stringhe trovate, come ad esempio
Con applicazioni vere solitamente trova molte informazioni e permette di farsi un’idea generale. In questo caso, oltre alle attività, non ha trovato nulla di rilevante.
Altri tool per effettuare analisi automatiche sono:
- https://github.com/vincentcox/StaCoAn
- https://github.com/SUPERAndroidAnalyzer/super
- https://github.com/1N3/ReverseAPK
- https://github.com/linkedin/qark
Per capire cosa succede dietro le quinte nell’analisi automatica, passiamo a quella manuale.
Decompilazione APK
Tramite apktool decompilo l’app in modo da averla in una comoda cartella. Il comando utilizzato è
apktool d InsecureBankv2.apk
AndroidManifest.xml contiene la maggior parte dei dettagli di configurazione, incluso il nome del pacchetto, i componenti dell’app, le impostazioni di sicurezza e i permessi. È quello che MobSF analizza e stampa le configurazioni insicure.
Per quanto riguarda le stringhe invece le prende dal file /res/strings.xml
Questo ci fa capire quando sia utile in certi casi fare sempre un passaggio con MobSF, in quanto ci permette di evitare un’analisi manuale (in certi casi).
Ma cosa significa quelli is_admin? Proviamo a capirlo andando a modificarlo e ricompilare l’app.
Compilazione APK
Modifico la stringa inserendo yes
Ricompilo l’applicazione con il comando
apktool b InsecureBankv2
Dove InsecureBankv2 è la cartella contenente tutti i file precedentemente estratti
Con i comandi
keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore InsecureBankv2.apk alias_name
Andiamo a firmarla nuovamente, altrimenti non potrà essere installata
La installiamo di nuovo con adb
Ed ecco che abbiamo l’applicazione con un nuovo bottone, probabilmente disponibile solo per gli admin
Cliccando dice che è ancora Work In Progress, ma è stato un ottimo esercizio per analizzare, decompilare e ricompilare un file apk.
Analisi statica del codice
Per poter leggere il codice java di un’applicazione è necessario utilizzare il tool jadx-gui, il quale decompilerà l’app in maniera automatica e ci permetterà di leggere e capire tutte le funzioni dell’app. In certi casi il codice è ofuscato e jadx fallisce, ma in questo caso è chiaramente leggibile.
Una volta aperto possiamo sia analizzare file per file il codice alla ricerca di funzioni particolari, sia cercare stringhe come “password”, “token” e similari, in modo da vedere se è rimasta qualche credenziale hardcodata all’interno del file.
In questo caso abbiamo trovato la chiave AES utilizzata per cifrare.
Andando invece a frugare tra le varie funzioni, troviamo una particolare condizione durante il Login
Il quale dice che se viene inserito il nome utente devadmin, la password viene ignorata.
Bingo! Siamo dentro l’app senza conoscerne le credenziali.
È possibile bypassare il login anche tramite il modulo app.activity.start di Drozer, come ho spiegato in questa guida.
Un altro tool per l’analisi statica molto comodo è Andromeda.
Bypass dei controlli root
Come potete vedere dallo screenshot l’app segnala che il dispositivo non è rootato, anche se in realtà lo è. Potrei spiegare come bypassare il root ma in realtà il 90% delle volte basta avere un modulo come RootCloak o MagiskHide. Nel caso in cui non funzioni, potrebbe essere necessario usare Frida, che inserirò in una prossima guida probabilmente. Se volete approfondire, questo è un ottimo articolo.
Analisi Dinamica
Nella fase di analisi dinamica andremo ad analizzare il comportamento dell’app, cosa salva all’interno del device, quali chiamate fa al server di riferimento, e via discorrendo.
Analisi all’interno del dispositivo
Una volta installata ed aver fatto qualche operazione, i file che utilizza l’app potrebbero trovarsi sia nella memoria esterna (che è una bad practice, perchè potrebbero essere letti e modificati da qualsiasi altra app) sia nella memoria interna, nel path /data/data/nomepacchetto.
Nella cartella databases solitamente si trova il database utilizzato dall’app per salvare le informazioni, mentre in shared_prefs alcune coppie chiavi:valori, utilizzate per il login o token di sessione.
Controlliamo il database per vedere se ci sono informazioni sensibili al suo interno. Per vederlo direttamente sul nostro pc facciamo una copia in una cartella accessibile dall’esterno
cp mydb /storage/emulated/0/Download/
e lo copiamo sulla nostra kali
adb pull /storage/emulated/0/Download/mydb ./mydb
Ora con un software come SQLIte viewer possiamo tranquillamente analizzarlo
Ed ecco altre credenziali hardcodate, con le quali possiamo autenticarci all’applicativo.
Per quanto riguarda la cartella shared_prefs, vediamo che ci potrebbe essere qualche informazione sensibile
Nel nostro caso abbiamo sia il server e la porta utilizzata per connettersi al server, sia delle credenziali che sembrano encodate o cifrate.
Per quanto riguarda lo username, è encodato in base64 e lo abbiamo ricavato. Ma la password sembra cifrata, magari in AES con la chiave trovata prima?
Per scoprirlo, basta tornare sul codice Java, utilizzarne le funzioni che ci servono (in questo caso per pura comodità, in quanto il codice è perfettamente leggibile e possiamo copiarlo, con qualche modifica, per averne una copia funzionante)
Beh, vuota perché siamo autenticati con devadmin che non ha password.
Per capire se funziona, mi loggo nell’app con le credenziali presenti nel database, danesh/Dinesh@123$ .
Ed ecco che abbiamo decifrato delle credenziali grazie all’analisi statica effettuata precedentemente.
Logging
È importante che non vengano loggate informazioni sensibili durante l’utilizzo dell’app. Per verificare ciò, basta aprire logcat greppando solo il nome del pacchetto in analisi, con il comando
adb logcat | grep "$ (adb shell ps | grep | awk '{print $ 2}')"
Come possiamo vedere, in questo caso vengono loggate tutte le informazioni, come password in chiaro o i trasferimenti effettuati.
Debugging con JDWP
Se nel Manifest è attivo il debugging possiamo utilizzarlo per analizzare le funzioni passo passo e potenzialmente bypassare certi controlli. Per debuggare è necessario:
- Aprire l’applicazione da analizzare (e chiudere tutte le altre per semplicità)
- Comando adb jdwp e prendere nota dell’ID stampato (nel mio caso 16432)
- Digitare a db forward tcp:7777 jdwp:16432
- Ed infine jdb -attach localhost:7777 ed ecco che possiamo iniziare a debuggare
Per un approfondimento su questo rimando ad un ottimo articolo di FSecure (descrivere questo processo richiederebbe un altro articolo).
External Storage
Come anticipato, salvare file sulla memoria esterna non è consigliato, in quanto questi file potranno essere poi utilizzati da chiunque, poiché non sono protetti come nel caso dei dati salvati nella memoria interna.
Durante il logging e il contemporaneo utilizzo dell’app vediamo come essa cerchi di aprire un file che si trova nella memoria esterna
Ma nella GUI appare che il file non esiste. Proviamo a crearne uno, inserendo un javascript
Ed ecco che il nostro Javascript è stato eseguito. Ciò significa che l’app è vulnerabile ad un attacco Cross Site Scripting da parte da altre app, in quando tutti possono accedere a quel percorso e modificarne i file.
Per un’analisi dinamica omnicomprensiva io ho sempre utilizzato Inspeckage, il quale permette di “attaccarsi” all’app ed analizzare tutte le chiamare, le funzioni e
Come potete vedere, tante delle informazioni che abbiamo ricavato in maniera manuale, Inspeckage le trova durante l’utilizzo dell’app, in modo che siano già tutte in un’unica interfaccia.
Conclusioni
Ho volutamente evitato la parte di analisi delle API, in quanto sconfinano nella parte delle vulnerabilità Web, ma non dimentichiamoci che oltre a tutto ciò che abbiamo visto nell’articolo, rimane il testing di tutte le chiamate verso il server
che potrebbero essere vulnerabili ai classici attacchi di SQLInjection, XSS, IDOR e via discorrendo.
Come abbiamo visto l’analisi di un’applicazione Android comprende diverse parti, diverse metodologie ed è decisamente più complessa di una normale applicazione web. L’apk utilizzato come esempio ha altre vulnerabilità che ho deciso di non introdurre, ma se volete potete trovare altri esempi a questo indirizzo.
Dopo aver scritto questo articolo ho scoperto l’esistenza di un’altra applicazione vulnerabile, che vi consiglio se volete fare altra pratica.
Risorse utili
- https://appsecwiki.com/#/mobilesecurity
- https://manifestsecurity.com/android-application-security/
- https://github.com/OWASP/owasp-mstg/tree/master/Document
- https://www.evilsocket.net/2017/04/27/Android-Applications-Reversing-101/
- https://conference.hitb.org/hitbsecconf2018ams/materials/D1T1%20-%20Federico%20Dotta%20and%20Piergiovanni%20Cipolloni%20-%20Brida%20When%20Burp%20Suite%20Meets%20Frida.pdf
- https://mobile-security.gitbook.io/mobile-security-testing-guide/
- https://god.owasp.de/archive/2018/slides/2018-god-holguera.pdf
Hits: 295
L’articolo Penetration Test di un’Applicazione Mobile – Android proviene da HackTips.
Introduzione
L’internet of things è ormai una realtà. Sul mercato si possono trovare centinaia di dispositivi intelligenti diversi, e le nostre case sono piene di elettrodomestici e sensori intelligenti.
Gli smartphone hanno fatto da apripista in questa rivoluzione delle connessioni, e tuttora mantengono la maggior parte di share del mercato per quanto riguarda i dispositivi elettronici. In questo contesto, da diversi anni, Android si è affermato come il sistema operativo più utilizzato al mondo con quasi il 39% del mercato [1], che supera addirittura il 70% se si considera solo l’ambiente mobile. Di conseguenza, Android risulta essere il sistema operativo più minacciato da malware.
I nostri smartphone sono assistenti di tantissime attività quotidiane, dal leggere le mail, navigare sul web e parlare con altre persone, fino al monitorare i nostri allenamenti, il traffico sulle strade che percorriamo e gli acquisti della spesa. La quantità di informazioni e dati che passano tramite i nostri smartphone è una risorsa di grande valore, ambita dalle grandi aziende informatiche, dai governi ma anche dai criminali.
La maggior parte di antimalware attuali fanno uso di tecniche ‘signature-based’ per il rilevamento di minacce, ossia comparano l’applicazione in analisi con un database di minacce conosciute. Chiaramente, questo tipo di approccio risulta inefficace nel rilevare nuove minacce non presenti nei database. Inoltre, gli sviluppatori di malware fanno largo uso di tecniche di offuscamento del codice per modificare parzialmente il malware mantenendo intatta la sua azione malevola ma rendendolo “nuovo” e quindi non rilevato dagli antimalware [2]. Per mantenere alto il livello di sicurezza dei dispositivi mobili c’è un continuo bisogno di sviluppo di tecniche di rilevamento di applicazioni malevole sempre più’ efficaci ed efficienti.
In questo contesto, gli scrittori di malware stanno sviluppando attacchi sempre più complessi per evadere i sistemi di rilevamento del malware, uno di questi recentemente apparso è il cosiddetto colluding attack (attacco tramite collusione): l’azione dannosa è suddivisa in più applicazioni che comunicano tra loro quando l’utente esegue una determinata azione o al verificarsi di uno specifico evento all’interno del sistema. In questo modo gli attuali antimalware, che analizzano un’applicazione alla volta, non sono in grado di identificare il payload dannoso in quanto suddiviso tra diverse applicazioni. Pertanto, negli attacchi tramite collusione, un payload dannoso viene suddiviso in parti più piccole e distribuito in più applicazioni. In questo tipo di attacco le applicazioni non destano sospetti per gli antimalware, perché richiedono i permessi minimi necessari per eseguire l’azione dannosa. Ad esempio, quando due applicazioni implementano questo tipo di attacco, la prima applicazione potrebbe avere il permesso di leggere dati sensibili e trasmetterli alla seconda applicazione, che col permesso di connessione ad una rete li trasmette al mondo esterno. In questo modo la prima non richiede il permesso per utilizzare la connessione Internet, ma solo il permesso per leggere i dati, eludendo così i controlli, poiché reputata innocua; dall’altra parte la seconda applicazione richiedendo solo il permesso di connessione ad Internet, non risulta essere sospetta se non può accedere direttamente a informazioni di tipo sensibile. A tal proposito si può affermare che se analizzate singolarmente, le applicazioni sono considerate benigne poiché non esiste un percorso diretto dai dati sensibili alla loro trasmissione.
Metodologia
Partendo dalla problematica dell’attacco tramite collusione in ambiente mobile, abbiamo sviluppato una metodologia basata sull’utilizzo di tecniche di model checking e su una nuova funzione euristica, il cui scopo è quello di ridurre il numero di applicazioni analizzate. La funzione è stata definita sulla base della Logica Temporale Mu-Calculus e del model checking [3].
Figura 1. Schema del metodo proposto
La metodologia lavora sulle risorse condivise di tipo stringa, andando a sfruttare le SharedPreferences di Android, usate per salvare i settaggi delle impostazioni nelle applicazioni. Il nostro metodo, mostrato in Figura 1, prevede in input un insieme di applicazioni, che viene ridotto grazie ad una prima euristica, ottenendo così un sottoinsieme di candidati all’analisi. La prima euristica inoltre divide le applicazioni in base al diverso utilizzo delle shared resource, infatti in figura possiamo notare uno split tra le applicazioni che verificano la proprietà di GET (se leggono i dati) e quelle che verificano le proprietà di PUT (se scrivono dati). La seconda euristica entra in azione dopo la verifica della proprietà di PUT, visto che le applicazioni di questo tipo sono quelle che permettono una modifica attiva; e serve a ridurre ulteriormente lo spazio di ricerca tra le applicazioni colludenti andando ad analizzare l’esecuzione del flusso e quindi il tipo di informazione che viene inviata, per fare ciò si utilizza FlowDroid. Dopo ciò, con il model checker CWB-NC si verifica se tra le applicazioni è presente una proprietà di collusione che soddisfa la formula in mu-calculus [4].
Conclusioni
In conclusione, possiamo dire che l’attacco tramite collusione è una minaccia emergente in ambiente mobile che si basa sulla comunicazione tra due o più applicazioni. Per mitigare gli effetti dannosi di questa nuova minaccia in ambiente Android, proponiamo l’utilizzo di un metodo basato sul model checking. Il metodo proposto ottiene una accuracy pari a 0.99 nella valutazione di applicazioni che effettuano diversi tipi di attacchi tramite collusione, applicazioni malevole che non effettuano collusione ed applicazioni considerate legittime.
Referenze
[1] Statcounter Global Stats website. “Operating System Market Share Worldwide.” URL: https://gs.statcounter.com/os-market-share ACCESSED: 02/12/20 [2] Canfora, Gerardo, et al. “Obfuscation techniques against signature-based detection: a case study.” 2015 Mobile Systems Technologies Workshop (MST). IEEE, 2015. [3] Iadarola, Giacomo, et al. “Call Graph and Model Checking for Fine-Grained Android Malicious Behaviour Detection.” Applied Sciences 10.22 (2020): 7975 [4] Casolare, Rosangela, et al. “Malicious Collusion Detection in Mobile Environment by means of Model Checking.” 2020 International Joint Conference on Neural Networks (IJCNN). IEEE, 2020
Articolo a cura di Giacomo Iadarola, Rosangela Casolare, Fabio Martinelli, Francesco Mercaldo, Antonella Santone
L’articolo Metodi Formali per la rilevazione di collusioni in ambiente Android proviene da ICT Security Magazine.
Una nuova campagna di Phishing ai danni degli utenti INPS, similare alla precedente del 6 Aprile 2020, è stata rilevata nelle scorse ore dal nostro centro di ricerca e analisi delle campagne di Phishing.
L’attività fraudolenta viene svolta attraverso un dominio web creato Ad Hoc con similitudini, nel nome, a quello ufficiale dell’istituto nazionale della previdenza sociale con l’intento di far scaricare un malware agli utenti interessati a ricevere l’indennità Covid-19 stanziata dallo stato Italiano.
Il malware veicolato è destinato esclusivamente agli utenti Android, in formato .apk, ed è della famiglia Android Banker ovvero in grado di estrarre dallo smartphone della vittima informazioni bancarie o di carte di credito.
Invitiamo pertanto gli utenti a prestare massima attenzione e di installare applicazioni esclusivamente tramite gli app store ufficiali.
Di seguito alcuni screenshot del sito web malevolo.
IoC:
- inps-it[.]top
- acrobatreader.apk
- MD5: 3e48bb31ab93ddf136a1212d49566de2
- SHA1: 4fd90de7e8709390cf9c3e51bac0964323cdca9f
- SHA256: 8790d9ffb67ce0d2e48b71aa152bbf4ae12fba0cc9fa7a57473c233117743e01
Siamo lieti di annunciare un nuovo servizio per aiutare chi non ha molte conoscenze informatiche o chi sospetta di avere programmi spia o malware nel suo telefono e desidera mettere in sicurezza un dispositivo android o controllare le impostazioni di privacy dei suoi account social.
1) Pacchetto SICUREZZA ANDROID con Assistenza da Remoto
Il pacchetto Sicurezza Android Completa tramite Assistenza da Remoto vi permette di controllare il vostro telefono in modo approfondito e di migliorare le condizioni di sicurezza e funzionamento del vostro dispositivo. Per approfondire [ click qui ]
2) Pacchetto SICUREZZA ANDROID e SICUREZZA FACEBOOK da remoto
In aggiunta al pacchetto Sicurezza Android con assistenza da remoto, sopra presentato, procederemo con la messa in sicurezza del profilo facebook del cliente ( tramite un blocco totale per il massimo livello di privacy ed accesso ai dati del profilo consentito solo ai propri amici ) e la verifica degli ultimi accessi al suo account facebook. Per approfondire [ click qui ]
3) Pacchetto MESSA IN SICUREZZA PROFILI SOCIAL da remoto
Il pacchetto messa in sicurezza profili social da remoto prevede il nostro intervento per ottenere il massimo livello di sicurezza per il vostro account Facebook, Instagram, Twitter, Linkedin, Pinterest. Per approfondire [ click qui ]
4) Pacchetto MESSA IN SICUREZZA FACEBOOK da remoto
Procederemo con la messa in sicurezza del profilo facebook del cliente ( tramite un blocco totale per il massimo livello di privacy ed accesso ai dati del profilo consentito solo ai propri amici ) e la verifica degli ultimi accessi al suo account facebook. Per approfondire [ click qui ]
Informatica in Azienda diretta dal Dott. Emanuel Celano
L’articolo SERVIZIO DA REMOTO : richiedi la massima SICUREZZA per il tuo telefono ANDROID e per i tuoi account SOCIAL proviene da .
Premessa – Chi è NOYB
NOYB – Centro europeo per i diritti digitali (www.noyb.eu), è un’organizzazione senza scopo di lucro con sede a Vienna, in Austria, fondata nel 2017.
Co-fondatore di NOYB è l’avvocato austriaco Max Schrems, attivista per la privacy diventato noto nel 2013 per avere avviato campagne contro Facebook Ireland per violazioni delle leggi europee sulla privacy; nello specifico, Schrems contestava alla sede europea del social in blu come il livello di protezione dei dati dei cittadini europei nell’ambito del trasferimento verso il quartier generale di Menlo Park non potesse essere considerato sufficiente a garantire un’adeguata tutela della vita privata da intromissioni generalizzate e indiscriminate, in particolare alla luce delle rivelazioni di Edward Snowden sull’esistenza dei programmi di sorveglianza di massa PRISM e Upstream.
L’AAID oggetto del reclamo promosso da NOYB
Oggetto del reclamo promosso da NOYB è l’attivazione su tutti i sistemi Android, da parte di “Big G” (ovvero Google LLC e la sua sede europea Google Ireland Limited), dell’AAID – Android Advertising ID, che consiste in una stringa di caratteri alfanumerici il cui scopo è quello di rendere esattamente identificabile il device dell’utente, al fine di utilizzarlo come tracciatore delle abitudini di quest’ultimo e, così, di permetterne il riconoscimento univoco nel c.d. eco-sistema di advertising a favore di sviluppatori di App, e di un indefinito numero di terze parti.
Come riportato nell’esempio citato nel reclamo, “…se il reclamante utilizza un’app e mostra un particolare interesse per un evento, tale preferenza è associata al suo AAID e viene utilizzata per pubblicare annunci pertinenti su un’altra app o anche su pagine Web non correlate”.
In sostanza, allorquando attiviamo per la prima volta un sistema Android (cellulare o tablet, per esempio) e attiviamo i servizi offerti da Google, viene generato un codice identificativo univoco (c.d. “unique identifier”) che, senza richiedere uno specifico consenso all’utente, viene generalmente condiviso mediante tracker incorporati nelle App (come ad es. gli SDK), per consentire alle terze parti destinatarie di tracciare e profilare gli utenti attraverso applicazioni e servizi.
Questo codice viene, poi, trasmesso e condiviso all’interno di tutto l’ecosistema pubblicitario tra una miriade di soggetti e terze parti, che spesso generano anch’essi identificativi di tracciamento persistenti; questo sistema permette così ai soggetti operanti nel circuito pubblicitario di raccogliere molti dati dell’utente da un alto numero di fonti diverse, per poi ricondurli ad un minimo comun denominatore (l’AAID appunto).
L’oggetto del reclamo di NOYB verte proprio sul sistema di attivazione e funzionamento dell’AAID: si tratterebbe, infatti, di una forma di tracciamento non autorizzata dall’utente e senza alcuna valida base giuridica, sulla quale gli utenti, una volta attivato il cellulare o il tablet, non hanno alcun controllo e contro cui possono fare ben poco, con grave violazione dei principi e delle norme previste dal Regolamento generale per la protezione dei dati personali (UE) 2016/679, posto che – come affermato da Google medesima – non è possibile la cancellazione dell’AAID generato di default dal sistema attivato, ma solo la generazione di un codice ex novo in sostituzione dell’originale, funzione che pare in ogni caso inefficace per limitare le capacità di tracciamento; infatti, se è vero che l’AAID rigenerato viene sincronizzato con altri identificativi dell’utente, le terze parti destinatarie possono semplicemente aggiungere il nuovo codice al precedente, e riprendere in tal modo la profilazione dell’utente aggregando i nuovi dati con quelli precedentemente acquisiti.
Il reclamo di NOYB avanti l’Autorità di Controllo austriaca
La tesi di NOYB parte della convinzione che l’AAID, per un verso, sia da considerare dato personale (ex art. 4, par. 1, del GDPR) che viene continuamente recuperato, utilizzato, collegato e condiviso tra Google e le terze parti, al fine di (1) tracciare le azioni degli utenti, (2) elaborare le preferenze di consumo e, infine, (3) fornire pubblicità pertinente su dispositivi Android, e, per altro verso, sia oggetto di trattamento secondo quanto previsto dall’art. 4, par. 2, del GDPR.
In sostanza, contesta NOYB, l’AAID non sarebbe nient’altro che un codice identificativo che “marchia” univocamente e “per sempre” l’utilizzatore (consumatore) del sistema Android, senza che vi sia stata una scelta consapevole e volontaria dell’utente al momento dell’attivazione del sistema e, inoltre, senza che sia addirittura prevista una possibilità di opt-out, cioè di cancellazione dell’AAID, o quantomeno di dissociazione definitiva dal dispositivo utilizzato, e quindi dall’identità dell’utilizzatore – impedendo, così, il c.d. single-out (cfr. WP 29, Opinion 16/2011, Opinion 2/2013 e Opinion 5/2014).
E ancora, NOYB ha altresì fatto oggetto di reclamo il fatto che Google, al momento dell’attivazione della contestata stringa ID, non abbia fornito al reclamante, che ne aveva assoluto diritto, informazioni specifiche, complete e aggiornate sul trattamento effettuato dall’AAID, sui destinatari, sulle fonti, sulla base giuridica utilizzata o sul periodo di conservazione, facendo riferimento e genericamente richiamando le proprie politiche sulla privacy.
Le contestazioni di NOYB
NOYB, a mezzo del proprio reclamo, ha contestato:
- la violazione dell’art. 6, par. 1, del GDPR, in quanto, pur nell’impossibilità di stabilire una valida base giuridica sottostante al trattamento condotto a mezzo AAID, in ogni caso il trattamento sarebbe illecito, se è vero che (a) nel caso in cui la base giuridica ipotizzata fosse il consenso ex art. 6, par. 1, lett. a), questo non sarebbe stato informato, specifico, fornito liberamente, e quindi non sarebbe in ogni caso valido (a tacere dell’assenza di qualsiasi funzione effettiva di opt-in); (b) nel caso in cui la base giuridica fosse, invece, il legittimo interesse ex art. 6, par 1, lett. f), sarebbe ancor qui invalida posto che l’interesse di Google e delle terze parti per il tracciamento delle abitudini di acquisto dell’interessato non sarebbe, comunque, prevalente sugli interessi o i diritti e le libertà del medesimo;
- la violazione degli articoli 7, par. 3, e 21 del GDPR, posto che, indipendentemente dalla base giuridica adottata, l’AAID, avendo il reclamante correttamente esercitato i propri diritti, avrebbe dovuto essere “cancellato” definitivamente da parte di Google, il quale, però, lungi dall’aver provveduto a disattivarlo, ha rigettato la richiesta, asserendo, in modo apodittico e generico, di non avere i mezzi tecnici “per verificare l’identità delle persone interessate da un Advertising ID” e, quindi, di non essere in grado di adottare le misure specifiche di disattivazione richieste.
L’alternativa proposta da Google
Vista i motivi di asserita incapacità tecnica dichiarata dal motore di ricerca di far fronte alle richieste avanzate dall’utente/reclamante, Google ha proposto a quest’ultimo una soluzione alternativa, ovvero, resettare l’originario AAID, con la conseguente riassegnazione di un nuovo codice identificativo.
Sulla base dei rapporti contrattuali in corso tra Google e terze parti, sostiene “Big G”, non sarebbe infatti più possibile utilizzare il vecchio codice, ma – al netto del paradosso per cui parrebbe che per ottenere l’interruzione del trattamento illecito l’unica opzione sarebbe di acconsentirne uno nuovo con le stesse modalità – è stato in ogni caso dimostrato da recenti studi ed analisi (cfr. report Out of Control del Norwegian Consumer Council) come l’Advertising Id – che a tutti gli effetti è da considerarsi dato personale al pari degli altri codici identificativi infornatici – possa essere “…condiviso e, se necessario, collegato a vecchi valori tramite innumerevoli altri identificatori come indirizzi Ip, codici Imei e coordinate GPS, username di social media, indirizzi email o numero di telefono, di fatto permettendo un tracciamento persistente degli utenti Android”.
Sembra – così conclude NOYB – che il fatto stesso che sia Google a dover richiedere alle terze parti di interrompere il tracciamento dell’AAID originario, sia la prova stessa che la soluzione proposta da Google di fatto non consenta di interrompere il tracciamento continuo dell’AAID dell’utente, e che, quindi, Google abbia creato un sistema che strutturalmente non consente la disattivazione del tracciamento delle abitudini dell’interessato.
Le richieste conclusive di NOYB
NOYB, in conclusione, ha richiesto all’Autorità di Controllo austriaca di avviare un’indagine su quanto oggetto del reclamo promosso e di ordinare a Google: (1) di eliminare definitivamente l’AAID, interrompendo, quindi il trattamento dei dati associati ad esso, e (2) di consentire al reclamante il diritto di accesso ai dati richiesti oggetto del trattamento, applicando a Google, in forza degli artt. 58, par. 2, e 83, par. 4, lett. a) del GDPR, una sanzione effettiva, proporzionata e dissuasiva per tutte le violazioni contestate.
Articolo a cura di Jacopo Giunta e Matteo Chiavassa
L’articolo NOYB vs. Google LLC/Google Ireland Limited: il reclamo sul funzionamento dell’AAID – Android Advertising ID proviene da ICT Security Magazine.