Undetectable Remote Arbitrary Code Execution Attacks through JavaScript and HTTP headers trickery

[Shamar]

Comunque trovo quei link molto confusi.

Mi dispiace, lo sono @lynX, ma purtroppo non è colpa mia.

Proprio Frederik Braun ha suggerito di continuare su Lobste.rs la conversazione dopo aver chiuso la segnalazione. (una delle tante evidenze che mi hanno mostrato come l’open source sia profondamente diverso dal software libero che è espressione della curiosità hacker).

Purtroppo su Lobste.rs entrambi i confronti sono stati censurati (e io sono stato bannato).

Braun ha iniziato il dialogo sul Lobste.rs in modo molto simpatico e gentile:

Okay, I’ll bite.

Purtroppo non ha risposto alle semplici domande di un hacker, evidenziando mala fede.

Anche rain1 inizialmente era piuttosto ostile nei confronti del mio bug report.

Tuttavia dopo la pubblicazione del primo exploit (molto grezzo per evitare che fosse immediatamente utilizzabile da chi non lo conoscesse ancora) in cui mostro come bypassare firewall e proxy per conoscere i servizi in esecuzione sulla macchina del visitatore di una qualsiasi pagina web, lui l’ha reso immediatamente usabile su un fiddler estendendolo alla mappatura di tutta la rete privata del visitatore. In altri termini ha pubblicato un attacco che permette di penetrare in una rete privata, mapparne e (attraverso un DNS rebinding) utilizzarne i servizi HTTP/HTTPS disponibili. Immagina, giusto per far capire agli altri la gravità del problema per i diritti civili, cosa si possa fare attraverso questi attacchi in una rete dove sono presenti IoT di vario genere, telecamere di sorveglianza, sistemi informativi aziendali, CMS cui l’utente è autenticato automaticamente etc… Grazie al comportamento omissivo di Mozilla&friends, le persone, le aziende e persino i governi non sono consapevoli che i loro costosissimi firewall servono a poco o nulla se navigano sul web con JavaScript e/o WebAssembly abilitati.

Entrambi gli attacchi sono stati verificati su reti configurate in modo molto professionale.

Quando su altri canali mi hanno informato che il Governo Russo stava usando l’attacco che avevo ideato per mostrare la gravità del problema (in realtà è stato il quarto o il quinto che mi è venuto in mente), l’ho segnalato a Mozilla e rain1. Putroppo a Mozilla, la sicurezza e la libertà dei cittadini russi non interessa. E secondo me, neanche di quelli italiani o europei.

Questo exploit è solo uno degli exploit possibili, altri molto semplici sono elencati nel bug report e qualunque programmatore competente (come spero siano in Mozilla Security) ne può ideare a bizzeffe.

Una intera classe di vulnerabilità

Il problema è molto semplice, nascosto in bella vista da decenni.

Un browser che esegua ciecamente il codice fornito da terze parti può accedere come minimo a:

1. gli IP associati al PC su cui gira il browser
2. la sua banda sulle diverse reti
3. la potenza di calcolo
4. la RAM
5. e può scrivere il disco (browser cache)

Più naturalmente qualsiasi vulnerabilità nel sandboxing del browser o nei layer sottostanti (ricordi Meltdown e Spectre?)

Questi attacchi possono essere serviti specificatamente ad uno o più visitatori appartenenti ad un gruppo identificabile (anche attraverso siti di terze parti se sei una CDN) customizzandoli come si fa con gli Ads e rimuovendo le tracce attraverso gli header HTTP di Cache-Control.

Per detectarli, pur nell’impossibilità di provarli se l’attaccante è in gamba, hai bisogno di uno dei tool di sicurezza che il Governo Russo cerca sulla tua macchina (proxy etc che loggino la comunicazione)

Come mitigarle

La cosa eticamente devastante per un hacker che crede nell’onestà intellettuale è stato il rifiuto di informare gli utenti del problema. Ma anche le mitigazioni proposte sono semplici da implementare in un browser. (perdonatemi copio dal testo inglese che ho scritto in precedenza, sto finendo il tempo)

Page Refresh though META tag and JavaScript are disabled by defaultBoth can be enabled on a per website basis,

• No script or CSS is requested with Cookies or other HTTP headers
• Each script and CSS is requested through a dedicated TCP connection
• SubResource Integrity is made mandatory (at least for JavaScript)
• For each URI, record the SRI of last downloaded contents and warn the user if a page propose a different SRI for that same URI
• Warn the user about scripts served with suspect HTTP headers

On browser exit, remove from the cache all resources downloaded by pages that have Meta Refresh and/or JavaScript enabled.

View Page Source should never fetch new versions of the page from the server (whatever the HTTP Headers provided with the page are)

Obviously all this leaves the door open for pages that:

• are visited only once
• are visited for the first time

thus I would also mark as “Not Secure” web pages visited for the first time that require JavaScript or WebAssembly.

Se hai ulteriori domande (che spero non annoino gli altri avventori di questo forum) sono felice di risponderti.

[Shamar]

Nota veloce: ovviamente Tor browser, nella sua configurazione di default, non è vulnerabile, che io sappia, allo specifico attacco che io e rain1 abbiamo descritto come mero esempio.

Questo perché indirizza tutto il traffico via Tor, impedendo (sempre di default) l’accesso alla rete locale.

Tuttavia, l’esecuzione di JavaScript (e se non erro anche di WebAssembly) è abilitata per configurazione predefinita su tutti i siti, nonostante la presenza di NoScript.

Tor browser, gentilmente, informa l’utente che massimizza la finestra che è più saggio mantenerla nelle dimensioni in cui è stata aperta perché ovviamente le dimensioni dello schermo possono essere usate per identificare e tracciare l’utente.

Quello che Tor browser non dice è che le dimensioni della finestra saranno comunque disponibili a qualunque sito internet proprio via JavaScript.

In pratica diverse tecniche di fingerprinting si basano proprio su JavaScript e sono semplicemente altri esempi di questa vasta classe di attacchi.

[lynX]

In altri termini ha pubblicato un attacco che permette di penetrare in una rete privata, mapparne e (attraverso un DNS rebinding) utilizzarne i servizi HTTP/HTTPS disponibili.

Uhm, fammi capire… se una pagina web va a pigliare http://10.11.12.13 e ci trova l’intranet della ditta, poi può trasferire il contenuto al webserver dal quale proviene? Io avevo capito che può solo rilevare l’esistenza di un sito.

Immagina, giusto per far capire agli altri la gravità del problema per i diritti civili, cosa si possa fare attraverso questi attacchi in una rete dove sono presenti IoT di vario genere, telecamere di sorveglianza, sistemi informativi aziendali, CMS cui l’utente è autenticato automaticamente etc…

No, non capisco. Il javascript sarebbe in grado di estrarre immagini da una webcam IoT ed exfiltrarli?

Questi attacchi possono essere serviti specificatamente ad uno o più visitatori appartenenti ad un gruppo identificabile (anche attraverso siti di terze parti se sei una CDN) customizzandoli come si fa con gli Ads e rimuovendo le tracce attraverso gli header HTTP di Cache-Control.

Si, questa parte mi è chiara.

è stato il rifiuto di informare gli utenti del problema.

Se io sto ancora a fare domande ho seri dubbi che Frederik e colleghi abbiano capito in pieno il problema.

Le mitigazioni appaiono draconiane ed irrealistiche per coloro che non vogliono credere che l’architettura web/js è profondamente borked.

[Shamar]

Uhm, fammi capire… se una pagina web va a pigliare http://10.11.12.13 e ci trova l’intranet della ditta, poi può trasferire il contenuto al webserver dal quale proviene? Io avevo capito che può solo rilevare l’esistenza di un sito.

Potenzialmente sì. Dipende naturalmente dal contenuto in questione, dal fatto che sia accessibile al browser senza autenticazione (o con una autenticazione basata sull’IP) e dalla disponibilità di un DNS rebinding che permetta di aggirare le same origin policy.

Il javascript sarebbe in grado di estrarre immagini da una webcam IoT ed exfiltrarli?

Non ci ho mai provato, ma se le immagini sono servite via HTTP/HTTPS su un IP liberamente accessibile, perché no? Considerato il pessimo livello di sicurezza dell’IoT l’attaccante potrebbe anche usare il browser come ponte per modificarne la configurazione. O spegnerla. O muoverla. O causare un denial of service in altro modo. Ti ricordo che dei buontemponi nel 2018 hanno bucato il browser del media center di una Tesla per guidarla da remoto (qui i paper rilevanti: 1 e 2). (voglio dire, che ficata! altro che Super Mario Kart, ci potevi giocare a GTA in 3D su strada! )

L’attacco deve ovviamente essere personalizzato per la vittima. E per il browser in esecuzione. Ma gli attacchi sono innumerevoli. Giusto per citare cose note e stranote, conosci certamente BeFF.

Se io sto ancora a fare domande ho seri dubbi che Frederik e colleghi abbiano capito in pieno il problema.

Non ti offendere @lynX, ma spero che Frederik Braun che lavora in Mozilla Security ne capisca più di me e di te messi insieme. E poi ha capito benissimo. Infatti non ha risposto ad una semplicissima domanda:

Are the attacks described in the bug report possible in Firefox, or not? Are Firefox’s users world wide vulnerable to them?

Se riesci a strappargli una risposta pubblica tu… Io ho fallito.

Aspetto la risposta in merito di @calamarim.

Le mitigazioni appaiono draconiane ed irrealistiche

Ti prego @lynX, so che non le ritieni tali, ma veramente: tocchi un tasto che mi manda in Berserk.

Anzitutto non sono irrealistiche. Se ci mettono più di un mese ad implementarle tutte in Mozilla, abbiamo un problema più grave (come in effetti abbiamo… ma uno diverso).

Inoltre non sono draconiane. Google Chrome (!!!) ti permette di rendere l’esecuzione di JavaScript opt-in per sito web. In due click lo riabiliti se ti serve. E potrebbe essere uno solo. E poi voglio dire, te lo ricordi Flash? te le ricordi le applet Java? Qualcuno si strappava le vesti perché non venivano eseguite automaticamente dal browser dell’utente a sua insaputa?

E comunque, anche se le mitigazioni fossero davvero “draconiane e irrealistiche”, come questo giustifica la scelta di NON INFORMARE GLI UTENTI DEI RISCHI CHE CORRONO?

Perché credi che il Governo Russo si stia creando un db dei russi che potrebbero detectare questo tipo di attacchi? Anzitutto il servitore di Putin in questione si chiederà “perché questo Shamar russo prende questo tipo di precauzioni? Ma certo: deve avere qualcosa da nascondere!”. E perché costruire un db delle persone vulnerabili ad una certa classe di attacchi, se non intendi usarli?

[lynX]

Non ci ho mai provato, ma se le immagini sono servite via HTTP/HTTPS su un IP liberamente accessibile, perché no?

Ah cavolo, ai miei tempi XMLHttpRequest era un catorcio che funzionava solo se il server sputava sintassi XML… ma in questo modo almeno era impossibile farci cose senza che il lato server sia d’accordo. Vedo che le nuove API l’hanno reso un falla grossa come una capanna. A questo punto proporrei come misura di mitigazione che l’impiego di XMLHttpRequest per accedere a contenuti atipici richieda un permesso esplicito dell’utente, tipo come con la telecamera.

Non mi parlare di IoT. Secondo me tutta una generazione di hardware odierna sarà da rottamare perché prima che l’IoT funzioni a base di qualcosa tipo GNUnet è tutta una follia che cammina a mo di zombie.

L’attacco deve ovviamente essere personalizzato per la vittima. E per il browser in esecuzione.

Non si potrebbe fare un attacco con proxy AI? Tipo il browser prova a caricare http://10.0.0.1, manda il risultato al server, quello consulta l’AI e decide in quale modo continuare l’attacco.

conosci certamente BeEF.

No, dato che sono inattivo in campo pentesting non conosco le ultime cosuccie, ma vedo che ci sta l’estrazione dell’IP usando WebRTC della quale avevo parlato. Quello che questa implementazione BeEF non mostra: ci puoi elencare tutte le interfaccie ethernet, perciò se il computer che stai exploitando è connesso a reti interne private, ora puoi scoprirne gli IP range. Happy scanning!

E comunque, anche se le mitigazioni fossero davvero “draconiane e irrealistiche”, come questo giustifica la scelta di NON INFORMARE GLI UTENTI DEI RISCHI CHE CORRONO?

Fai una bella cosa. Fai un PoC veramente calzante, ed invece di pubblicarlo mandalo al CCC per dare un talk al prossimo congresso.

[Shamar]

Non si potrebbe fare un attacco con proxy AI? Tipo il browser prova a caricare http://10.0.0.1, manda il risultato al server, quello consulta l’AI e decide in quale modo continuare l’attacco.

Naturalmente è possibile, ma le AI di solito vengono usate per gestire automaticamente grandi quantità.

Ora, è importante chiarire 2 cose:

1. questi attacchi sono pericolosi perché possono essere personalizzati, veicolati da terze parti inconsapevoli (se ad esempio l’attaccante è una CDN)
2. la plausible deniability si ottiene solo se tutti gli utenti che non appartengono al gruppo sotto attacco ricevono script innocui

Se Google scansionasse TUTTE le reti sistematicamente, è probabile che prima o poi qualcuno se ne accorgerebbe. Se invece lo fa, un po’ per volta attraverso i browser di diversi dipendenti, per una sola azienda italiana alla volta, al sistemista che dovesse sospettare qualcosa riderebbero tutti in faccia (o peggio, come è successo a me).

Vi è poi una terza questione che secondo me è importante (ed lo è particolarmente per Pirati come noi): è ridicolo pensare che Giacomo Tesio sia stato il primo ad ideare questi attacchi. Questo ha svariate conseguenze.

La più ovvia è che questi attacchi vengono usati da anni e non sono mai stati osservati. Un po’ meno ovvio è che, in un certo senso, è la scoperta dell’acqua calda: eseguire automaticamente codice personalizzato sotto il controllo di sconosciuti che rispondono a sistemi legali e politici diversi è estremamente pericoloso. Bella scoperta!

Fai un PoC veramente calzante, ed invece di pubblicarlo mandalo al CCC per dare un talk al prossimo congresso.

E perché dovrei fare marketing per ottenere che una classe di vulnerabilità di questa portata planetaria venga mitigata? Per ottenere visibilità? Non è il mio mestiere.

Molti mi hanno suggerito di preparare un PoC, un sito web, e lanciare una campagna come fu fatto per Heartbleed e Meltdown, ma io lo trovo triste e patetico.

Mi rifiuto di giocare a questo gioco.

Aderire significherebbe avvallare questa totale ed assoluta mancanza di onestà intellettuale nel IT.

Il bug report e il PoC che sono stati pubblicati devono essere sufficienti ad un professionista di sicurezza dei browser per mollare tutto quello che sta facendo ed iniziare a mitigare il problema.

Perché la più grave vulnerabilità qui è la fiducia che le persone hanno nei confronti di Mozilla e dell’open source in generale.

[lynX]

Naturalmente è possibile, ma le AI di solito vengono usate per gestire automaticamente grandi quantità.

Infatti sto teorizzando qualcosa tipo FOXACID o HACIENDA a livello browser.

è ridicolo pensare che Giacomo Tesio sia stato il primo ad ideare questi attacchi.

Si. Giusto fare i conti da quando questi attacchi sono tecnicamente realizzabili, cioè quando è stata introdotta questa XHR2… se per caso è correlabile col “DoS” degli addon per Firefox che di colpo hanno smesso di funzionare…

in un certo senso, è la scoperta dell’acqua calda

Il concetto di sandbox risale ai tardi anni ottanta circa… la novità è ogni volta quando si inventano un modo per aprire una falla di sicurezza enorme e non dire nulla a nessuno. Per questo generalizzare non serve, significherebbe eliminare tutta l’economia “app” e tutti i Javascript. Abbiamo a che fare con una falla specifica e c’è da domandarsi chi è stato talmente genio ad introdurla.

Aderire significherebbe avvallare questa totale ed assoluta mancanza di onestà intellettuale nel IT.

I’m afraid in IT ci sta una sacco di mancanza di onestà intellettuale.

Perché la più grave vulnerabilità qui è la fiducia che le persone hanno nei confronti di Mozilla e dell’open source in generale.

E per questo è una questione di politica e marketing, non di onestà che in quel ambiente tanto non c’è. La priorità è il guadagno, anche se ne soffre il genere umano intero.

[Shamar]

se per caso è correlabile col “DoS” degli addon per Firefox che di colpo hanno smesso di funzionare…

No, quella è stata una enorme “sciocchezza” tecnico manageriale.

La cosa inquietante è ciò che ha rivelato ai più attenti (e che francamente io non sapevo): about:studies è abilitato di default su Firefox! In pratica, da Mozilla non hanno bisogno di questi attacchi, possono prendere il controllo remoto del tuo browser e fargli fare quello che desiderano.

Potevano chiamarla backdoor, ma studies fa più figo!

E per questo è una questione di politica

E’ una questione altamente politica in effetti.

Ogni giorno che passa Mozilla e Chromium sono più colpevoli (ed in realtà anche WHATWG, Microsoft, Safari etc… che ho informato tutti in un modo o nell’altro).

Ogni giorno che passa.

E sono passati 10 mesi.

E’ una questione Politica in effetti.

Conosci mica un partito politico che potrebbe affrontare e persino risolvere il problema?

I’m afraid in IT ci sta una sacco di mancanza di onestà intellettuale.

Per questo servono Pirati che insegnino a tutti a programmare!

[lynX]

Potrei iniziare a ragionare su quale campagna a sorpresa si potrebbe fare per rendere nota questa falla… ma se lo faccio in forum non sarebbe più una sorpresa.

[Shamar]

@lynX sono 10 mesi che cerco di spargere la voce… (con qualche risultato fra i miei fan russi, si direbbe)

Pensi davvero che se ne parliamo qui Mozilla prenda precauzioni?

[ale]

Non so se ho capito bene, ma a me sembra un network scanner progettato con javascript. Se é cosí, l’exploit non c’é, javascript é un linguaggio di programmazione, é normale che abbia funzionalitá di rete, anzi, questa caratteristica é cercata e voluta dai suoi progettisti. Si puó fare anche in java o python e molti software che funzionano all’interno dei browser sono progettati per usare queste funzionalitá, quindi non c’é bug. Perché il bug é un errore, in questo caso invece stiamo parlando di una funzionalitá cercata.

Probabilmente la problematica va indirizzata in modo diverso. Cioé é un problema di sicurezza nelle reti che per qualche motivo devono rimanere private.

Non sono esperto di browser, ma immagino debbano esistere delle chiavi dentro Firefox che permettono di definire i permessi di un software javascript. Se non esistessero, non é una issue che si deve sollevare, ma una richiesta di nuova funzionalitá per poter controllare i permessi di rete del software. Anche se queste cose si possono comunque affrontare a livello di firewall.

[lynX]

Se é cosí, l’exploit non c’é

Vabbeh dai… non esageriamo.

[Shamar]

No @ale purtroppo questa è una risposta frequente di fronte ad un problema architetturale di sicurezza, ma è semplicemente sbagliata.

Il fatto che un software implementi perfettamente delle specifiche, non garantisce la sicurezza degli utenti se tali specifiche sono fallate. Questo è tanto più vero per i browser WHATWG, che determinano i cosiddetti Living Standards attraverso l’implementazione: lo so che è paradossale, ma le specifiche del Web seguono l’implementazione più influente politicamente all’interno del WHATWG, e non solo di fatto, ma proprio by design,

Oggi le implementazioni più influenti sono Firefox e Chrome, ma Firefox perde terreno ogni giorno che passa, perché la sua influenza dipende dalla sua credibilità, e da qualche anno sta facendo un errore strategico dopo l’altro, tanto che iniziano a diventare evidenti persino ai suoi sostenitori.

Come ho fatto notare ai vertici di Mozilla, affrontare apertamente e tempestivamente questa classe di vulnerabilità avrebbe potuto cambiare rapidamente lo status quo, rivelando al mondo la profonda insicurezza (personale, aziendale e geopolitica) degli strumenti cui si affida al di là dell’ipocrisia e della retorica del Web.

Ma ti prego, non definire un bug architetturale di queste dimensioni “feature”.

Una backdoor installata e razionalizzata da miliardi di persone nel mondo è una feature solo se sei una potenza militare che distribuisce la stragrande maggioranza dei contenuti web.

Il problema non è JavaScript. (e questo, detto da me che lo conosco più di quanto lo odio, dovrebbe seminare il panico nei cuori! )

Il problema è la combinazione di alcune caratteristiche fondamentali del web odierno:

• l’esecuzione automatica di programmi personalizzabili sotto il controllo di terze parti (sia JS o WASM è irrilevante)
• la distribuzione geografica di queste terze parti (hosting, cloud, cdn etc…): chi controlla il JS / WASM in esecuzione sulla tua macchina risponde a sistemi giuridici diversi dal tuo, che sia la Russia, l’Iran (in un recente attacco basato su lets encrypt), gli USA, la Cina (ricorderai certamente il DDoS a github di qualche anno fa) o chiunque altro.
• la profilazione capillare degli individui, dei gruppi e delle loro relazioni
• la pervasività della sorveglianza che permette di correlare una identità ottenuta legittimamente su un sito con le informazioni non autenticate (@calamarim giustamente osservava che i dati non aggregati non sono mai anonimi)
• l’adozione indiscriminata di HTTPS che impedisce il caching intermedio dei contenuti (a meno di MitM istituzionalizzati e razionalizzati come Cloudflare) che costringe il browser a ricontattare sempre e comunque il server autoritativo di ogni singolo contenuto
• il cache control HTTP che, sebbene abbia perso gran parte della sua utilità con la diffusione del HTTPS (l’unica cache che controlla è quella del browser in esecuzione, se visiti la stessa pagina HTTPS con due browser diversi sulla stessa macchina verrà scaricata comunque due volte dal server in autoritativo per essa e nessuno dei proxy intermedi potrà cacharla per ridurre il traffico o proteggere la tua privacy), permette di nascondere e rimuovere le prove di un avvenuto attacco

Oggi è ancora possibile detectare (con qualche difficoltà e con strumenti e competenze specialistiche) questi attacchi, ma la diffusione di DoH, HTTP/3 e soprattutto WebAssembly renderà anche questo proibitivo anche per gli esperti.

E comunque non puoi provare di aver subito un attacco del genere nemmeno se lo individui, perché trattandosi di dati, potresti averli fabbricati tu stesso. E per contro uno strozzino potrebbe salvare la contabilità illegale nella cache del browser e fingersi vittima di un attacco, con buona pace dell’informatica forense.

Tutto questo non è una feature checché ne divano gli standard (che i browser vendor hanno scritto dopo averli implementati).

Peraltro, anche formalmente, nessun passaggio degli standard WHATWG stabilisce che JavaScript debba essere abilitato di default. Dunque richiedere l’autorizzazione all’utente per l’esecuzione non violerebbe alcuno standard (tant’è che Chrome può essere facilmente configurato in questo modo). E visto che i Living Standard seguono le implementazioni, implementare queste mitigazioni in un browser maggiore è il primo passo per ridurre la vulnerabilità architetturale che il WHATWG ha creato.

Per questo ho aperto un bug report a Mozilla (per altro su suggerimento di Marco Ciurcina che in una mail aveva osservato che affinché la mia scoperta avesse rilevanza legale, i vendor dovevano essere informati pubblicamente della questione).

Perché fixare Firefiox fosse il primo passo per migliorare il Web. Un onere ed un onore che Mozilla ha buttato al vento. Lo farà anche il Partito Pirata? Non lo so…

Ma per me la questione è e rimane semplice. Se le persone che usano correttamente un mio programma possono essere attaccate attraverso di esso, non c’è specifica o strategia di marketing che tenga: si molla tutto e si chiude la falla nel modo più rapido possibile informando tutti del problema.

[ale]

No @ale purtroppo questa è una risposta frequente di fronte ad un problema architetturale di sicurezza, ma è semplicemente sbagliata.

Non credo sia un problema architetturale.

le specifiche del Web seguono l’implementazione più influente politicamente all’interno del WHATWG, e non solo di fatto, ma proprio by design,

E’ vero, é un classico di molti standard industriale, anzi, credo che la Netscape fu la prima a imporre i propri standard, tralaltro se la memoria non m’inganna furono loro a inventare JavaScript.

Ma ti prego, non definire un bug architetturale di queste dimensioni “feature”.

Non é propriamente una feature, é proprio una caratteristica insita nel linguaggio. Se un linguaggio prevede delle primitive per utilizzare le reti ti ritroverai per forza di cosa a poter aprire connessioni di rete.

Il problema non è JavaScript.

Concordo, si puó scrivere lo stesso codice con qualunque helper.

Il problema è la combinazione di alcune caratteristiche fondamentali del web odierno:

Non puoi contestare l’architettura del web attraverso il bug tracking, se vuoi contestare le scelte architetturali ti devi rivolgere direttamente a chi scrive gli standard. Ammesso che la tua voce abbia peso, perché come hai detto ci sono ben altri calibri in gioco.

l’esecuzione automatica di programmi personalizzabili sotto il controllo di terze parti (sia JS o WASM è irrilevante)

E’ configurabile nel browser, se vuoi puoi contestare le impostazioni di default, ma sono impostazioni di sicurezza modificabili.

Non commento i punti che hai messo, perché nessuno di questi é un elemento tecnico che va a favore o a sfavore del bug. Esecuzione automatica, distribuzione geografica, profilazione, https, sono tutti elementi dei quali possiamo parlare, ma non hanno niente a che vedere con la capacitá di un software di creare delle connessioni in una rete locale.

Tutto questo non è una feature checché ne divano gli standard (che i browser vendor hanno scritto dopo averli implementati).

Il mio punto non sono gli standard. La questione, secondo me, é che javascript é un linguaggio di programmazione completo, anche molto potente aggiungerei, quindi é normale che se scrivo del software con questo linguaggio gli posso far fare tutte le cose che voglio, per esempio si potrebbe scrivere un clone di nmap. Quindi il primo punto é che mi sembra giusto che javascript sia in grado di fare questa cosa.

Ora i browser creano un ambiente, nel quale si possono lanciare programmi (dico programmi per sottolineare che possono raggiungere rispettabilissimi livelli di complessitá), e in questo ambiente abbiamo il primo livello di sicurezza. Se il software é scritto bene, la sicurezza é una questione di impostazioni, per esempio, potrei creare una blacklist dove vieto al browser di accedere a tutti gli indirizzi di rete locale.

Il fatto se farlo o meno come default é una scelta (criticabile o meno) del produttore. Ma se fossi cosí restrittivo, non potrei piú vedere siti internet sulla rete locale.

Quindi quello che si potrebbe chiedere a Mozilla é di rendere piú dettagliata (non so se esiste, magari esiste) la possibilitá di filtrare gli accessi eseguiti da un software all’interno del browser. Ovviamente finché ragioniamo a livello applicazione.

Cmq, la scommessa secondo me non dovrebbe essere disabilitare javascript, ma farlo girare in modo sicuro, dove per sicuro intendo nel modo che ci si aspetterebbe.

[Shamar]

Non sono esperto di browser

@ale la maggioranza delle persone che frequentano questo forum non dispongono delle conoscenze necessarie a valutare la nostra rispettiva competenza in materia di sviluppo Web ed architettura dei sistemi distribuiti.

Io sono felicissimo di rispondere alle tue domande ma ti pregherei, per rispetto e tutela dei pirati meno esperti, di non fare affermazioni che, basate su una lettura approssimativa di questo thread e su una conoscenza superficiale della materia, potrebbero confonderli.

Lo dico anche nel tuo interesse professionale, perché scrivi su un forum pubblico affermazioni che rimarranno visibili a lungo. Per il momento sia Frederik Braun (Mozilla Security) sia Asa Dotzler (Mozilla… di tutto un po?) si sono ben guardati dal contraddirmi nel merito o anche solo di rispondere alle mie semplici domande, nonostante io abbia fornito a Mozilla (e ad altri) molte occasioni su diversi canali. Alla fine solo gli hacker rispondono alle domande (link a Twitter).

Ti suggerisco dunque di rileggere il tutto attentamente, provare gli exploit, comprendere la questione da una prospettiva tecnica, legale e geopolitica prima di minimizzarla in pubblico.

La questione, secondo me, é che javascript é un linguaggio di programmazione completo, anche molto potente aggiungerei, quindi é normale che se scrivo del software con questo linguaggio gli posso far fare tutte le cose che voglio, per esempio si potrebbe scrivere un clone di nmap.

a me sembra un network scanner progettato con javascript.

No, è (anche) un sistema per bypassare firewall e proxy attraverso il browser di un utente che visiti una qualsiasi pagina web anche di terze parti ignare (se controlli una CDN ad esempio). Una volta entrato nella rete della vittima è solo questione di fantasia: il network scanning è solo la quarta o quinta cosa che mi è venuta in mente.

Se é cosí, l’exploit non c’é

ROTFL ! ! !

Puoi provare a spiegarlo al Governo Russo? Magari li convinci a smettere di usarlo!

javascript é un linguaggio di programmazione, é normale che abbia funzionalitá di rete, anzi, questa caratteristica é cercata e voluta dai suoi progettisti.

Programmo in JavaScript professionalmente da 20 anni, credo di sapere cos’è.

Il problema non è il linguaggio di programmazione in sé (che ti assicuro ha dei problemi devastanti! da sbattere forte la testa contro il muro gridando disperatamente “perché? perché?”) né l’ecosistema (da dove comincio?). Tutto ciò che ho descritto è applicabile esattamente nello stesso modo a WebAssembly.

Il problema è l’esecuzione automatica di programmi personalizzabili sotto il controllo di terze parti… bla bla bla… le cose che ho già scritto.

Non commento i punti che hai messo, perché nessuno di questi é un elemento tecnico che va a favore o a sfavore del bug. Esecuzione automatica, distribuzione geografica, profilazione, https, sono tutti elementi dei quali possiamo parlare, ma non hanno niente a che vedere con la capacitá di un software di creare delle connessioni in una rete locale.

Ecco appunto, forse è meglio che le rileggi con calma ed attenzione.

Se poi qualcosa non è chiaro, sarò veramente felice di rispondere alle tue domande.

Sul tuo passaggio riguardo l’uso del browser come piattaforma di sviluppo di applicazioni distribuite potremmo discutere a lungo. Sarebbe una chiacchierata piacevole: potremmo per esempio confrontarlo con architetture distribuite differenti, come .NET nella visione originale di Bill Gates, oppure con Java, oppure ancora con Plan 9 from Bell Labs oppure ancora con CORBA etc…

Tuttavia ci porterebbe fuori tema ed annoierebbe tutti gli altri.

la scommessa secondo me non dovrebbe essere disabilitare javascript, ma farlo girare in modo sicuro, dove per sicuro intendo nel modo che ci si aspetterebbe.

Su questa scommessa Microsoft, Apple, Google e Mozilla e molti altri stanno spendendo miliardi da anni. E perdono sempre.

O forse no?

[ale]

Lo dico anche nel tuo interesse professionale, perché scrivi su un forum pubblico affermazioni che rimarranno visibili a lungo.

Non é un problema, ho le spalle abbastanza grosse. Ho scritto che non sono esperto di browser, ma so leggere un semplice codice in avascript e ho esperienza di programmazione in diversi linguaggi.

Per il momento sia Frederik Braun (Mozilla Security) sia Asa Dotzler (Mozilla… di tutto un po?) si sono ben guardati dal contraddirmi nel merito o anche solo di rispondere alle mie semplici domande, nonostante io abbia fornito a Mozilla (e ad altri) molte occasioni su diversi canali.

Ti dovresti chiedere perché…

No, è (anche) un sistema per bypassare firewall e proxy attraverso il browser di un utente che visiti una qualsiasi pagina web anche di terze parti ignare (se controlli una CDN ad esempio). Una volta entrato nella rete della vittima è solo questione di fantasia: il network scanning è solo la quarta o quinta cosa che mi è venuta in mente.

Non é un buco, il software ha i permessi per fare quelle cose. Molti software che girano nei browser utilizzano quelle caratteristiche per fare chiamate REST e forniscono i loro servizi basandosi proprio su quelle caratteristiche. E’ una cosa, che nel campo della programmazione é risaputa e documentata.

Se poi qualcosa non è chiaro, sarò veramente felice di rispondere alle tue domande.

Ho l’impressione che tu l’abbia giá fatto. Ma i tuoi argomenti sono politici, non tecnici.

Sul tuo passaggio riguardo l’uso del browser come piattaforma di sviluppo di applicazioni distribuite potremmo discutere a lungo. Sarebbe una chiacchierata piacevole: potremmo per esempio confrontarlo con architetture distribuite differenti, come .NET nella visione originale di Bill Gates, oppure con Java, oppure ancora con Plan 9 from Bell Labs oppure ancora con CORBA etc…

Mi sembra di capire che suggerisci che esistono modi migliori di fare la stessa cosa. Se é questo che stai cercando di dire concordo perfettamente.

Su questa scommessa Microsoft, Apple, Google e Mozilla e molti altri stanno spendendo miliardi da anni.E perdono sempre.

Be, mi sono capitati davanti frontend basati su nodejs che interrogavano api su backend python che non erano niente male.

[Shamar]

Ti dovresti chiedere perché…

Mi sono interrogato sulla questione a lungo, in effetti.

Considera che quando tutti usavano IE6 io installavo personalmente Firefox 0.8 a colleghi, amici e parenti. E ho continuato a farlo a lungo, anche quando ormai il vento era cambiato e Chrome stava diventando il nuovo IE6. Non perché avessi compreso la strategia di Google (mi vergogno ad ammetterlo ma 10/15 anni fa credevo anche io alla favoletta del Google benefattore dell’umanità): semplicemente ritenevo Mozilla più bisognosa di supporto (nonché Firefox tecnicamente superiore grazie a XUL).

Nel tempo la mia fiducia in Mozilla è scesa, ma quella nei confronti di Google è crollata. Tuttavia, anche solo per mere ragioni di marketing e brand, ero ancora abbastanza fiducioso che Mozilla avrebbe affrontato il problema di petto. Dal loro punto di vista poteva essere l’occasione ideale per sbaragliare i concorrenti sui loro cavalli di battaglia, privacy e sicurezza, mostrando di essere disposti a rischiare tutto per proteggere i propri utenti.

Non l’hanno fatto. Hanno condannato s’è stessi.

Sono mesi che mi chiedo il perché. Qual’è la tua ipotesi?

i tuoi argomenti sono politici, non tecnici

Spiegami, per favore: gli header di cache control che permettono di rimuovere le prove non sono un argomento tecnico? La connessione TLS che impedisce il caching intermedio di qualsiasi risorsa servita via HTTPS, non è un argomento tecnico? La diffusione di CDN che servono script JavaScript per una infinità di siti internet ricevendo una varietà di informazioni attraverso cui identificare le potenziali vittime, non è un argomento tecnico? Tutti i vari MitM nel tragitto fra l’utente e la sorgente autoritativa del contenuto (di nuovo, CDN ma anche hosting provider e cloud) e che potrebbero modificarlo in transito, non sono un argomento tecnico? L’intera infrastruttura centralizzata del Web (dal DNS all’HTTP) che favorisce economie di scala centralizzanti (e dunque tracciatura e profilazione), non è un argomento tecnico? Il riuso di connessioni TCP, l’assenza di content addressing, la non obbligatorietà di SRI… sono argomenti tecnici o no?

La Tecnologia è Politica, @ale.

Mi sembra di capire che suggerisci che esistono modi migliori di fare la stessa cosa. Se é questo che stai cercando di dire concordo perfettamente

Sì beh è come dire che ci sono modi migliori di sturare un lavandino rispetto alle bombe a mano.

Certo che ci sono metodi migliori. Uno lo sto cercando personalmente.

Ma qui c’è una falla architetturale enorme in un’infrastruttura fondamentale del nostro tempo. Per quanto vogliamo nascondere la testa sotto la sabbia?

[ale]

Nel tempo la mia fiducia in Mozilla è scesa, ma quella nei confronti di Google è crollata.Tuttavia, anche solo per mere ragioni di marketing e brand, ero ancora abbastanza fiducioso che Mozilla avrebbe affrontato il problema di petto. Dal loro punto di vista poteva essere l’occasione ideale per sbaragliare i concorrenti sui loro cavalli di battaglia, privacy e sicurezza, mostrando di essere disposti a rischiare tutto per proteggere i propri utenti.

Non l’hanno fatto.Hanno condannato s’è stessi.

Sono mesi che mi chiedo il perché.Qual’è la tua ipotesi?

Non sono sicuro di avere capito la domanda. Non hanno fatto cosa? Correggere il bug che hai notificato nei loro browser? Perché dal loro punto di vista non é un bug… E’ una caratteristica insita nel software. Infatti quella che tu chiami mitigazione, corrisponde in realtá a tornare a Internet 1.0, che dal loro punto di vista é inaccettabile. Inoltre esistono giá dei plugin che permettono di bloccare i javascript remoti, e di default i browser sono impostati per bloccare javascript maligni. Gli strumenti per bloccare attacchi di questo tipo esistono anche senza rivedere l’architettura di Internet.

Peró voglio far notare un problema piú subdolo: Supponiamo che Firefox e Google, che sono in teoria le piú sensibili al problema, decidessero di disattivare di default tutti i javascript, o di rivedere i permessi di javascript all’interno del browser creando una “camicia di forza” che permette al javascript solamente di accedere al proprio sito internet. Cosa succederebbe? Che molti javascript benigni smetterebbero di funzionare. Nell’immaginario dell’utente comune significherebbe che questi browser sono difficili da usare e browser rivali potrebbero farsi strada togliendo quote di mercato a firefox e google. Ne consegue, che anche loro sono prigionieri della situazione, l’unico modo sarebbe un accordo tra tutti i produttori e comunque la soluzione non dovrebbe diminuire le funzionalitá odierne, altrimenti si potrebbe sempre fare avanti qualche rivale che ruba quote di mercato.

Paradossalmente questo scenario renderebbe Internet meno sicura.

Spiegami, per favore: gli header di cache control che permettono di rimuovere le prove non sono un argomento tecnico?

Lo sono, ma in questo caso non c’entrano niente.

La connessione TLS che impedisce il caching intermedio di qualsiasi risorsa servita via HTTPS, non è un argomento tecnico?

Lo é, ma in questo caso non c’entra niente. A parte il fatto che le connessioni criptate hanno reso internet piú sicura.

La diffusione di CDN che servono script JavaScript per una infinità di siti internet ricevendo una varietà di informazioni attraverso cui identificare le potenziali vittime, non è un argomento tecnico?

Lo é, ma ancora una volta, non c’entra niente con l’argomento di cui stiamo parlando.

Tutti i vari MitM nel tragitto fra l’utente e la sorgente autoritativa del contenuto (di nuovo, CDN ma anche hosting provider e cloud) e che potrebbero modificarlo in transito, non sono un argomento tecnico?

A meno di bug, questo tipo di attacco (Man in the Middle) credo che ormai sia abbastanza raro, in caso di connessione criptata é molto difficile da mettere in piedi. Ma comunque anche quest’argomentazione é OT, perché non c’entra niente col bug che proponi.

L’intera infrastruttura centralizzata del Web (dal DNS all’HTTP) che favorisce economie di scala centralizzanti (e dunque tracciatura e profilazione), non è un argomento tecnico?

E’ il progetto originario, il web é sempre stato centralizzato. E’ vero che a cavallo tra gli anni 90 e 2000 c’é stato un movimento che favoriva le connessioni p2p, ma il progetto principale di Internet é questo. Che questo convenga alle grosse multinazionali e che le cose siano andate diversamente da come ci si aspettava é vero, ma questo é ancora un altro argomento.

Il riuso di connessioni TCP, l’assenza di content addressing, la non obbligatorietà di SRI… sono argomenti tecnici o no?

Si lo sono, immagino che prima o poi arriveremo all’obbligatorietá delle SRI (Subresource Integrity), come si é fatto per l’HTTPS, ma per arrivarci credo ci debba essere uno storico di exploit che si risolvono in questo modo. Again, siamo fuori tema.

In generale, l’informatica non procede secondo il modello “a cascata”, dove si prevede tutto a monte e poi tutto procede correttamente, ma é un continuo work-in-progress dove si parte da un progetto e questo viene corretto e rimodulato strada facendo.

Non avrai mai un’Internet perfetta, ci saranno sempre problemi che vengono risolti e ogni soluzione genererá nuovi problemi e nuovi attacchi. Che ci siano grandi interessi in gioco é vero, ma credo che presumere che ci sia malizia in ogni cosa sia un approccio sbagliato che puó dare soddisfazione nel corto raggio, ma che alla lunga porta fuori strada.

[Shamar]

[quote=“Shamar, post:18, topic:2899”] Spiegami, per favore: gli header di cache control che permettono di rimuovere le prove non sono un argomento tecnico?[/quote]

Lo sono, ma in questo caso non c’entrano niente.

@ale cosa sai dell’interpretazione del protocollo HTTP da parte dei browser? Sai con quale facilità questi header possono essere usati per nascondere un’attacco?

Sei proprio sicuro che non centrino?

La diffusione di CDN che servono script JavaScript per una infinità di siti internet ricevendo una varietà di informazioni attraverso cui identificare le potenziali vittime, non è un argomento tecnico? Tutti i vari MitM nel tragitto fra l’utente e la sorgente autoritativa del contenuto (di nuovo, CDN ma anche hosting provider e cloud) e che potrebbero modificarlo in transito, non sono un argomento tecnico?

A meno di bug, questo tipo di attacco (Man in the Middle) credo che ormai sia abbastanza raro, in caso di connessione criptata é molto difficile da mettere in piedi. Ma comunque anche quest’argomentazione é OT, perché non c’entra niente col bug che proponi.

@ale sai come funziona una CDN come Cloudflare?

Se sì, ci vuoi illuminare su come distribuisca contenuti su domini di terze parti via HTTPS?

Sei proprio sicuro che sia Off-Topic?

L’intera infrastruttura centralizzata del Web (dal DNS all’HTTP) che favorisce economie di scala centralizzanti (e dunque tracciatura e profilazione), non è un argomento tecnico?

ma questo é ancora un altro argomento.

@ale hai capito che sto parlando della centralizzazione prodotta da cloud e CDN?

Hai chiaro come funziona? Sono MitM applicati su scala planetaria con il consenso dei siti Web ma all’insaputa dei visitatori.

Se ti autentichi su un sito proxato da Cloudflare, lui può associare la tua identità a tutti i contenuti che serve per tutti gli altri siti internet. E ti può attaccare attraverso un sito internet del tutto ignaro, modificando le comunicazioni in transito.

Sei proprio sicuro sicuro sicuro che sia un’altro argomento?

Non avrai mai un’Internet perfetta

Hai mai visto un sistema perfetto? Hai letto What is Informatics?: sai benissimo che non credo nella perfezione. Cos’è questo, benaltrismo InfoSec?

Qui abbiamo una falla di sicurezza colossale installata sui PC di miliardi di persone. Perché pensi che il Governo Russo stia usando gli attacchi di cui tu neghi l’esistenza?

Prendo atto che a te va bene così.

Per curiosità, che software sviluppi? Posso leggere le loro EULA e/o SLA? Perché per me, se la libertà e la sicurezza degli utenti del mio software è messa in pericolo dal software stesso, io li informo immediatamente, poi mollo tutto e correggo il problema. Tu no.

[lynX]

E comunque non puoi provare di aver subito un attacco del genere nemmeno se lo individui, perché trattandosi di dati, potresti averli fabbricati tu stesso.

Problema fondamentale di tutta la giurisprudenza digitale e del GDPR… perciò applico l’evidenziatore.

Oggi è ancora possibile detectare (con qualche difficoltà e con strumenti e competenze specialistiche) questi attacchi, ma la diffusione di DoH, HTTP/3 e soprattutto WebAssembly renderà anche questo proibitivo anche per gli esperti.

E considerando che è compito della NSA creare sotterfugi di questo tipo e grazie a Snowden sappiamo che questo compito lo ha sempre adempito, non è adeguato pensare che tutto ciò sia solo un caso — che sia solo paranoia. Sarebbe illogico ed incoerente pensare che non sia in corso una cyber warfare.

Non puoi contestare l’architettura del web attraverso il bug tracking, se vuoi contestare le scelte architetturali ti devi rivolgere direttamente a chi scrive gli standard.

Questo implicherebbe che in ambito tecnologico siamo altrettanto fritti come in ambiti politici quali la globalizzazione, l’ineguaglianza, il surriscaldamento climatico. Tutte cose alle quali non basta più un bug report ma per le quali i poteri in gioco fanno in genere come gli pare… Non so se avete mai partecipato ad un IETF meeting. Io si. Inutile contare sull’IETF. Mentre la W3C è molto peggio.

per esempio, potrei creare una blacklist dove vieto al browser di accedere a tutti gli indirizzi di rete locale. Il fatto se farlo o meno come default é una scelta (criticabile o meno) del produttore. Ma se fossi cosí restrittivo, non potrei piú vedere siti internet sulla rete locale.

Non è quello lo scopo degli elenchi di interfacce di rete. Servono a realizzare servizi P2P sul web come le videochiamate WebRTC. Cosa del resto scema dato che WebRTC non è riuscita a democratizzare Skype come ci fu promesso, ma ha semplicemente piazzato le ditte predominanti del web al centro del universo anche per la telefonia (dato che solo loro hanno il necessario grafo sociale).

A parte il fatto che le connessioni criptate hanno reso internet piú sicura.

Eccetto se i contenuti sono banali ed il vero scopo è il tracciamento. O nel caso esposto da Shamar, l’oscuramento di attacchi individuali e/o di massa che grazie a Snowden sappiamo avvengono quotidianamente ed ovunque. Non citavo a caso appunto FOXACID e HACIENDA.

Lo sono, ma in questo caso non c’entrano niente.

Eddai, non dire così che mi viene freddo ai piedi.

credo che presumere che ci sia malizia in ogni cosa sia un approccio sbagliato

Certo se non credi a Snowden, allora puoi pensare così. Se non vuoi credere al eccellente lavoro di investigazione di Nafeez Ahmed che ci spiega come il pentagono nel 1995 decise di assicurarsi il controllo totale sulle tecnologie. Tutte. Specialmente l’Internet. L’esistenza della cyber warfare è indiscussa ed è iniziata nel 1995, e certamente include da sempre anche i browser web.