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