Replay Attack ad Immuni/GAEN
Appena letto sugli issues di Immuni. In sostanza, trattando opportunamente le TEK di utenti positivi scaricabili dal server di Immuni è possibile rilanciare i relativi RPI da un device programmato ad hoc. Spostando all'indietro l'ora sui telefoni bersaglio (può essere fatto anche senza accesso fisico, utilizzando un Access Point modificato, come sottolinea chi ha ideato la cosa) questi riceveranno gli RPI fasulli e quindi, al successivo controllo, la notifica di esposizione. Mi sembra un problema molto serio. https://github.com/immuni-app/immuni-app-android/issues/278 rob
Il 19/10/20 11:55, Roberto Resoli ha scritto:
Appena letto sugli issues di Immuni.
In sostanza, trattando opportunamente le TEK di utenti positivi scaricabili dal server di Immuni è possibile rilanciare i relativi RPI da un device programmato ad hoc. Spostando all'indietro l'ora sui telefoni bersaglio (può essere fatto anche senza accesso fisico, utilizzando un Access Point modificato, come sottolinea chi ha ideato la cosa) questi riceveranno gli RPI fasulli e quindi, al successivo controllo, la notifica di esposizione.
Mi sembra un problema molto serio.
Vedo che l'autore è Vincenzo Iovino, ricercatore all'università di Salerno, che ha anche pubblicato al riguardo un articolo su agendadigitale.eu: https://www.agendadigitale.eu/sicurezza/privacy/replay-attack-contro-immuni-... rob
rob
Buongiorno Roberto e nexiane, grazie mille Roberto della segnalazione! Ho dato una rapida occhiata nei miei archivi e non mi pare che questa _specifica_ vulnerabilità sia stata segnalata prima in questa lista, anche se è il replay attack è chiaramente segnalato come possibile vulnerabilità in almeno un paio di paper girati qui sul tema. Roberto Resoli <roberto@resolutions.it> writes:
Il 19/10/20 11:55, Roberto Resoli ha scritto:
[...]
Vedo che l'autore è Vincenzo Iovino, ricercatore all'università di Salerno, che ha anche pubblicato al riguardo un articolo su agendadigitale.eu:
https://www.agendadigitale.eu/sicurezza/privacy/replay-attack-contro-immuni-...
In buona sostanza si tratta *solo*, e sottolineo _solo_, di una simulazione "casalinga" di un replay attack (auto inflitto o verso terzi fa poca differenza): complimenti a Iovino che ha sviluppato il proof-of-concept e lo ha attuato con strumenti alla portata di molti con le necessarie competenze. Il commento ufficiale di Immuni [1] dice che non ci possono far nulla perché si tratta di un problema di GAEN: comodo eh! :-D Da quanto leggiamo, qundi, è altamente probabile che tutte le applicazioni che usano GAEN sono vulnerabili a questo attacco: cosa si starà dicendo in Germania o altri paesi "interoperabili" di 'sta cosa?!? Tutto tace. In Svizzera a quanto pare la "Swiss cybersecurity agency" e la "Swiss public health authority" hanno dichiarato [2] che due attacchi evidenziati da una analisi dei soliti Serge Vaudenay e Martin Vuagnoux, tra cui il replay attack, sono improbabili. In *teoria*, ma è ovvio che nessuno lo vorrà mai fare, un attacco del genere è alla portata di chi può installare sufficienti beacon bluetooth e usare "fake base station" [3] per coprire aree pubbliche molto frequentate. Però è ovvio che nessuno lo vorrà mai fare, sarebbe assurdo no? Teorire paranoiche (?!?) a parte, la cosa interessante (triste?) è che i rompiscatole come Iovino et al. non si sono limitati a segnalare ma hanno fornito interessanti contributi per trovare le migliori soluzioni ai problemi riscontrati, ma *pare* siano stati inascoltati... o meglio: "non possiamo farci niente, rivolgetevi all'ufficio reclami"... alla faccia del software libero. Ora veniamo al nocciolo della questione: tutto questo era AMPIAMENTE noto [3] prima del 20 Maggio, giorno in cui Vittorio Bertola ha aperto la issue #58: https://github.com/immuni-app/immuni-documentation/issues/58 (issue tuttora in stato "open") Sostanzialmente la issue segnala questo paper: https://down.dsg.cs.tcd.ie/tact/replay.pdf «A Coronavirus Contact Tracing App Replay Attack with Estimated Amplification Factors» pubblicata il 19 Maggio 2020 da due ricercatori del Trinity College di Dublino. Se proprio avete lo stomaco, vi invito a dare un'occhiata al thread scaturito in quella issue, giusto per rendervi conto coi vostri occhi del tenore delle risposte ricevute. Se non avete lo stomaco e avete il coraggio di fidarvi di me, posso solo dirvi che al netto di trolleggiamenti vari quella issue conferma che il problema è "irricevibile" da Immuni perché SAREBBE risolvibile solo mettendo mano a GAEN. Inoltre in quella issue non mancano le solite critiche al fatto che un tipo di attacco del genere non gioverebbe a nessuno e quindi possiamo tranquillamente ignorarlo. Saluti, Giovanni. [...] [1] https://github.com/immuni-app/immuni-app-android/issues/278#issuecomment-699... [2] https://deepai.org/publication/swisscovid-a-critical-analysis-of-risk-assess... [3] sono illegali ma fattibili https://www.blackhat.com/docs/eu-15/materials/eu-15-Borgaonkar-LTE-And-IMSI-... chi non le sa fare le può acquistare già belle che fatte al costo di una decina di migliaia di EUR: https://yatebts.com/products/satsite/ -- Giovanni Biscuolo
Il 20/10/20 17:00, Giovanni Biscuolo ha scritto:
Buongiorno Roberto e nexiane,
grazie mille Roberto della segnalazione!
Prego, è stata veramente una scoperta casuale, mi sorprende che non se ne parli di più.
Ho dato una rapida occhiata nei miei archivi e non mi pare che questa _specifica_ vulnerabilità sia stata segnalata prima in questa lista, anche se è il replay attack è chiaramente segnalato come possibile vulnerabilità in almeno un paio di paper girati qui sul tema.
Si, pare anche a me (ho controllato prima di inviare).
Roberto Resoli <roberto@resolutions.it> writes:
Il 19/10/20 11:55, Roberto Resoli ha scritto:
[...]
Vedo che l'autore è Vincenzo Iovino, ricercatore all'università di Salerno, che ha anche pubblicato al riguardo un articolo su agendadigitale.eu:
https://www.agendadigitale.eu/sicurezza/privacy/replay-attack-contro-immuni-...
In buona sostanza si tratta *solo*, e sottolineo _solo_, di una simulazione "casalinga" di un replay attack (auto inflitto o verso terzi fa poca differenza): complimenti a Iovino che ha sviluppato il proof-of-concept e lo ha attuato con strumenti alla portata di molti con le necessarie competenze.
Sì, la cosa è abbastanza semplice da essere veramente attuabile in contesti reali.
Il commento ufficiale di Immuni [1] dice che non ci possono far nulla perché si tratta di un problema di GAEN: comodo eh! :-D
Da quanto leggiamo, qundi, è altamente probabile che tutte le applicazioni che usano GAEN sono vulnerabili a questo attacco: cosa si starà dicendo in Germania o altri paesi "interoperabili" di 'sta cosa?!? Tutto tace.
L'attacco è stato riprodotto anche nel contesto dell'app svizzera SwissCovid, come annunciato nello stesso issue di immuni molto probabilmente da Martin Vuagnoux che menzioni poco oltre. https://github.com/immuni-app/immuni-app-android/issues/278#issuecomment-699...
In Svizzera a quanto pare la "Swiss cybersecurity agency" e la "Swiss public health authority" hanno dichiarato [2] che due attacchi evidenziati da una analisi dei soliti Serge Vaudenay e Martin Vuagnoux, tra cui il replay attack, sono improbabili.
Grazie del puntatore. Mi pare che in [2] corrisponda a "2.2 False positive attacks". L'autore di [2] è il matematico Paul-Olivier Dehaye, che cita anche le valutazioni ([7] nel testo) del National Cyber Security Centre: "It is difficult to estimate the likelihood that someone really tries to poison the whole system by large-scale replay attacks or to try to put individuals wrongly into quarantine by a targeted re-play attack against some persons. As notified individuals are now eligible by law to free testing, targeted attacks would only be effective for a short time (until the results of the tests are known). Large-scale replay attacks would generate a high number of tests and thus be easy to detect. In case the worst case, the app could then be disabled. The damage would be limited to development costs of the app, and a lost opportunity. The alternative would be not do offer a proximity tracing app at all – even an app using a centralized approach would be vulnerable to replay attacks to a certain, though lower, degree. In the end, this is a question that cannot be answered on a technical level alone. While such an attack is possible, it is associated with high costs for the attackers. As such, we believe that the benefit of the app is higher than the potential risk of such an attack." le risposte di Dehaye, a mio parere assai condivisibili: " We dispute several assertions in this quote. We agree that it is difficult to estimate the likelihood that someone really tries to poison the system. However a starting point would be to assess the technical difficulty of doing so. By showing an example here (under specific constraints), we hope to move this discussion forward a bit. While the example shown here might appear very random and small scale, our quantitative discussion at the end will show that relatively small actors could actually be impactful. State-level adversaries would definitely have the possibility to acquire the technical capacity to create havoc. We do not think the worst case would necessarily be so clear. An attacker with this type of leverage over the system will not necessarily use it right away and overtly. Instead, in certain disinformation attacks, the attacker would work at changing the perception of the system by different actors, thereby polarizing people around it. We have specific scenarios in mind of how to achieve this, but this is not the focus of the present report. We contend that the cost of technically performing the attack could be negligible to some actors, and we show this with an example of a mobile app SDK that already harvests Bluetooth beacon data from millions of users and sends it to central servers. " Rispetto a questo scenario, inoltre, l'attacco prospettato da Iovino non necessita "harvests Bluetooth beacon data from millions of users", perchè, se capisco bene, gli RPI vengono rigenerati in base alle TEK dei positivi normalmente pubblicati dai server dell'infrastruttura. Questo semplifica di molto l'infrastruttura necessaria a portare l'attacco. L'attacco è ipotizzato anche in un Issue del "GAEN Internals": https://github.com/google/exposure-notifications-internals/issues/19 menzionato anche da Iovino, e a cui ha risposto confermando la fattibilità: https://github.com/google/exposure-notifications-internals/issues/19#issueco...
In *teoria*, ma è ovvio che nessuno lo vorrà mai fare, un attacco del genere è alla portata di chi può installare sufficienti beacon bluetooth e usare "fake base station" [3] per coprire aree pubbliche molto frequentate. Però è ovvio che nessuno lo vorrà mai fare, sarebbe assurdo no?
Se ti riferisci allo scenario svizzero, come detto questo non sembra necessario.
Teorire paranoiche (?!?) a parte, la cosa interessante (triste?) è che i rompiscatole come Iovino et al. non si sono limitati a segnalare ma hanno fornito interessanti contributi per trovare le migliori soluzioni ai problemi riscontrati, ma *pare* siano stati inascoltati... o meglio: "non possiamo farci niente, rivolgetevi all'ufficio reclami"... alla faccia del software libero.
Citando sempre Iovino: https://github.com/immuni-app/immuni-app-android/issues/278#issuecomment-700... "5. Beyond proposing to look at alternative solutions, I actually do have a likely solution to withstand replay attacks that works with GAEN and would just require a change at the app level. Unfortunately, the Immuni's ecosystem is not (contrarily to what you write in your FAQ) open source and is not even testable, so I cannot perform tests to confirm whether my solution may really work. If I had the possibility of debugging, this would help. Being your process IMHO completely non-transparent until now, having you based the app on a system that is not publicly debuggable, and for other reasons, I prefer to not disclose my solution here. But I am open and you may contact me privately."
Ora veniamo al nocciolo della questione: tutto questo era AMPIAMENTE noto [3] prima del 20 Maggio, giorno in cui Vittorio Bertola ha aperto la issue #58: https://github.com/immuni-app/immuni-documentation/issues/58 (issue tuttora in stato "open")
Che necessita comunque dell'infrastruttura per raccogliere gli RPI. Nel caso di Iovino gli RPI vengono semplicemente rigenerati a posteriori (cosa tra l'altro alla base del meccanismo di GAEN che effettua il controllo rispetto agli RPI raccolti dal telefono). Quello che dici in [3] è sacrosanto: "chi non le sa fare le può acquistare già belle che fatte" e i costi sono assai più bassi. Non chiudere questa vulnerabilità mi sembra veramente irresponsabile.
Sostanzialmente la issue segnala questo paper: https://down.dsg.cs.tcd.ie/tact/replay.pdf «A Coronavirus Contact Tracing App Replay Attack with Estimated Amplification Factors» pubblicata il 19 Maggio 2020 da due ricercatori del Trinity College di Dublino.
Se proprio avete lo stomaco, vi invito a dare un'occhiata al thread scaturito in quella issue, giusto per rendervi conto coi vostri occhi del tenore delle risposte ricevute.
Se non avete lo stomaco e avete il coraggio di fidarvi di me, posso solo dirvi che al netto di trolleggiamenti vari quella issue conferma che il problema è "irricevibile" da Immuni perché SAREBBE risolvibile solo mettendo mano a GAEN.
Inoltre in quella issue non mancano le solite critiche al fatto che un tipo di attacco del genere non gioverebbe a nessuno e quindi possiamo tranquillamente ignorarlo.
Saluti, Giovanni.
[...]
[1] https://github.com/immuni-app/immuni-app-android/issues/278#issuecomment-699...
[2] https://deepai.org/publication/swisscovid-a-critical-analysis-of-risk-assess...
[3] sono illegali ma fattibili https://www.blackhat.com/docs/eu-15/materials/eu-15-Borgaonkar-LTE-And-IMSI-... chi non le sa fare le può acquistare già belle che fatte al costo di una decina di migliaia di EUR: https://yatebts.com/products/satsite/
Caro Roberto, solo un paio di commenti "a caldo", Roberto Resoli <roberto@resolutions.it> writes:
Il 20/10/20 17:00, Giovanni Biscuolo ha scritto: [...]
Roberto Resoli <roberto@resolutions.it> writes: [...]
Sì, la cosa è abbastanza semplice da essere veramente attuabile in contesti reali.
I contesti sono molteplici, dall'auto "attacco" per ottenere priorità sui tamponi fino all'inquinamento generalizzato delle segnalazioni di contatto, passando per l'attacco a un ristretto gruppo (o singolo). Queste prospettive sembrano sempre da paranoici complottisti fino a quando non si studia cosa è già stato fatto; per dire, quello che ha rivelato Snowden prima delle rivelazioni sembrava da paranoici. Per essere chiari: *non* sto prospettando scenari da DataGate in questo contesto, ma il rischio di qualcosa di serio c'è. [...]
Grazie del puntatore. Mi pare che in [2] corrisponda a "2.2 False positive attacks".
Sì, dove il 2.1 corrisponde ad un attacco di re-identificazione della persona che ha installato la app. [...]
Large-scale replay attacks would generate a high number of tests and thus be easy to detect. In case the worst case, the app could then be disabled.
Sì certo, tutto sta in quanto tempo si riesce ad accorgersi (gli attaccanti mica sono scemi e potrebbero adottare tecniche di poisoning lento) e quanti danni sono stati provocati nel frattempo. Su queste cose mi piacerebbe che venisse svolta e _pubblicata_ una adeguata analisi dei rischi: le chiacchiere stanno a zero.
The damage would be limited to development costs of the app, and a lost opportunity.
Ecco fatto: analisi dei rischi in due righe, zac! [...]
In the end, this is a question that cannot be answered on a technical level alone.
Balle. Punto.
While such an attack is possible, it is associated with high costs for the attackers.
Falso, _tutti_ gli esperti nel settore lo sanno *e* sanno anche che per un attaccante con sufficienti motivazioni e risorse il costo non è un problema (DataGate docet).
As such, we believe that the benefit of the app is higher than the potential risk of such an attack."
Il rischio è sempre potenziale ma l'analisi dei rischi dovrebbe evidenziare quali sono i possibili danni (in questo caso sistemici) che un simile attacco potrebbe comportare. Per quello che leggo questa cosa non mi pare sia stata fatta, spero vivamente di sbagliarmi e che un simile documento sia semplicemente segreto e ben custodito in qualche cassetto che conta.
le risposte di Dehaye, a mio parere assai condivisibili:
[...]
our quantitative discussion at the end will show that relatively small actors could actually be impactful.
Se l'analisi dei rischi fosse a disposizione per essere studiata non ci sarebbe bisogno di simili discussioni "campate per aria".
State-level adversaries would definitely have the possibility to acquire the technical capacity to create havoc.
Non sono solo "state-level", la tecnologia è ampiamente alla portata di molti criminali (non tutti mossi da motivazioni economiche). [...]
Rispetto a questo scenario, inoltre, l'attacco prospettato da Iovino non necessita "harvests Bluetooth beacon data from millions of users",
Sì, credo si riferisse all'attacco di re-identificazione [...]
L'attacco è ipotizzato anche in un Issue del "GAEN Internals":
https://github.com/google/exposure-notifications-internals/issues/19
menzionato anche da Iovino, e a cui ha risposto confermando la fattibilità:
https://github.com/google/exposure-notifications-internals/issues/19#issueco...
Good catch: non ci sono segni che la issue sia stata considerata nè che si stia lavorando per risolverla.
In *teoria*, ma è ovvio che nessuno lo vorrà mai fare, un attacco del genere è alla portata di chi può installare sufficienti beacon bluetooth e usare "fake base station" [3] per coprire aree pubbliche molto frequentate. Però è ovvio che nessuno lo vorrà mai fare, sarebbe assurdo no?
Se ti riferisci allo scenario svizzero, come detto questo non sembra necessario.
Hai ragione, forse ho fatto un po' di confusione: devo ristudiami bene il vettore di attacco. [...]
Citando sempre Iovino: https://github.com/immuni-app/immuni-app-android/issues/278#issuecomment-700...
"5. Beyond proposing to look at alternative solutions, I actually do have a likely solution to withstand replay attacks that works with GAEN and would just require a change at the app level. Unfortunately, the Immuni's ecosystem is not (contrarily to what you write in your FAQ) open source and is not even testable, so I cannot perform tests to confirm whether my solution may really work. If I had the possibility of debugging, this would help.
Bingo! Per i "normali utenti" è difficile percepire una app come "ecosistema" ma per gli sviluppatori non dovrebbe esserlo: fanno parte della app *tutte* le dipendenze dirette E indirette che servono a produrre il binario: se una di queste non è disponibile NESSUNO è in grado di fare test e debugging indipendenti e quindi di poter effettuare verifiche su eventuali problemi dell'ecosistema.
Being your process IMHO completely non-transparent until now, having you based the app on a system that is not publicly debuggable, and for other reasons, I prefer to not disclose my solution here. But I am open and you may contact me privately."
Questa non la capisco, ma pazienza. [...]
Non chiudere questa vulnerabilità mi sembra veramente irresponsabile.
Il vero problema è che *pare* che Immuni e le altre app basate su GAEN sono letteralmente ostaggio di un vendor lock-in: 1. il vendor vuole risolvere la vulnerabilità? 2. gli sviluppatori che usano GAEN vogliono risolvere la vulterabilità? 3. se 2 è vero e 1 no, gli sviluppatori sono in grado di sostituire la libreria difettosa con una meno difettosa? Davvero per cose così delicate una nazione deve sottostare ai criteri di sviluppo e manutenzioone del software dettati da un paio di mutinazionali? [...] Saluti, Giovanni. -- Giovanni Biscuolo
Il 21/10/20 10:00, Giovanni Biscuolo ha scritto:
Caro Roberto,
solo un paio di commenti "a caldo",
Roberto Resoli <roberto@resolutions.it> writes:
Il 20/10/20 17:00, Giovanni Biscuolo ha scritto: [...]
Roberto Resoli <roberto@resolutions.it> writes: [...] ... [...]
Rispetto a questo scenario, inoltre, l'attacco prospettato da Iovino non necessita "harvests Bluetooth beacon data from millions of users",
Sì, credo si riferisse all'attacco di re-identificazione
Non credo; entrambi gli attacchi 2.1 e 2.2 nel paper di Dehaye (re-identificazione e replay) prevedono la raccolta massiva di RPI. La verifica di fattibilità fatta da Iovino è fatta rigenerando gli RPI e modificando l'ora del telefono principalmente per non commettere reati (come giustamente sottolinei, la raccolta massiva sul campo di RPI è illegale). Lo chiarisce direttamente in questo tweet: https://twitter.com/vincenzoiovino/status/1312742967799615488?s=20 "Last but not least, questi replay Attack con macchina del tempo si ricorda sono usati per simulare un attacco reale senza fare cose ilelgali. L'attaccante reale piazza uno sniffer all'aeroporto dove ogni giorno numero infetti>1" Ciò non toglie che l'attacco "targeted" con modifica dell'ora del telefono sia comunque possibile, anche senza accesso fisico al dispositivo: https://github.com/google/exposure-notifications-internals/issues/19#issueco... "I did the attack outside the house of a "victim" (who was informed of the fact but a real attacker would not inform him). I just needed to know the password of the wifi and guess by several attempts the IP of his phone. The attack was successful. Similarly, you can do the attack in any place (bar, restaurant, bus stations, etc.) where people stay for 15 minutes and they are connected to a wifi to which you can also connect. So it is very doable. Users can notice it but is only for 15 minutes. Via another trick that we did not disclose yet, you can shorten the time to much less than 15 minutes." rob
participants (2)
-
Giovanni Biscuolo -
Roberto Resoli