September 2018 - nexa - server-nexa.polito.it

Re: [nexa] Come bypassare firewall e proxy aziendali (e di PA, banche.. etc)

by Giacomo Tesio

La tua è una opinione diffusa fra i giuristi. Il 13 settembre 2018 17:54, Marco Ciurcina <ciurcina(a)studiolegale.it> ha scritto: > Ma il software è software e non ha intenzioni etiche. Al contrario! La Tecnologia è il proseguimento della Politica con altri mezzi! Il Software Libero orienta l'attività politica costituita dalla programmazione verso un sistema etico e politico che deriva da un valore cardine: la Curiosità. La libertà del software è un valore fondamentale, ma comunque strumentale alla curiosità, al bisogno dell'hacker di scoprire, di provare, di esplorare. Un altro valore fondamentale, ma derivato dalla Curiosità è l'onestà intellettuale: l'importante è comprendere la realtà, imparare... non avere ragione. L'Open Source, sin dalla sua definizione si oppone a questi valori che cerca di marginalizzare (con grande succcesso). > Il software libero è il software disponibile secondo una licenza che > soddisfa i requisiti della definizione di software libero. > > L'espressione open source definisce le licenze che soddisfano l'open source > definition. > > Nella sostanza, i due insiemi (licenze di software libero e licenze open > source) sono quasi coincidenti. Questa è una opinione molto diffusa fra i giuristi. Ho discusso con Carlo Piana estensivamente in passato su questo punto. Se proiettati sul piano legale, avete ragione: sono indistinguibili. Ma non possiamo limitarci a questa dimensione. Come puoi vedere da questa storia, la distanza è enorme. Sul piano culturale, politico, sociale... e non pensare che tutte queste differenze non si esprimano sul codice! Ora, l'Open Source non è cattivo, ma è solo uno strumento di marketing. Uno strumento utilissimo! Ottimo software. Ma è "neutro", come dicevi tu. Solo che il Software Libero invece non è neutro! E mentre il Software Libero viene deriso per i propri valori, l'Open Source se ne appropria come strumento di marketing mentre li svuota di significato. Giacomo

Sept. 13, 2018

Re: [nexa] Come bypassare firewall e proxy aziendali (e di PA, banche.. etc)

by Marco Ciurcina

In data giovedì 13 settembre 2018 10:58:08 CEST, hai scritto: > Con tutto il rispetto Marco, devo contraddirti: Firefox è evidentemente > Open Source, non Software Libero. Dal menù "Aiuto", voce "Informazioni su Firefox", link "Informazioni sulla licenza" della versione di Firefox che ho sul mio PC leggo: "All of the *source code* to this product is available under licenses which are both free[1] and open source[2]." Secondo me intendono "free software and open source": infatti la parola "free" è linkata a http://www.gnu.org/philosophy/free-sw.html. Non ho motivo di dubitare che le licenze secondo le quali è disponibile Forefox rispettano la definizione di software libero. Quindi penso di non sbagliare se scrivo che Firefox è software libero. > > Il software libero è un'espressione della cultura hacker, un atto creativo > di curiosità. > Come tale l'onestà intellettuale è un prerequisito fondamentale del > software libero. > > Firefox è Open Source, una cosa molto diversa: > https://twitter.com/giacomotesio/status/1035553204552040448 mm.. Se capisco il tuo punto, intendi dire che gli sviluppatori di Firefox e Chrome sono "Opensursari" e non hanno un chiaro standing etico. Mi pare condivisibile. Ma il software è software e non ha intenzioni etiche. Come scrivevo questa mattina, Firefox ci dice: "I'm not bad. I'm just drawn that way.". :-) Il software libero è il software disponibile secondo una licenza che soddisfa i requisiti della definizione di software libero. L'espressione open source definisce le licenze che soddisfano l'open source definition. Nella sostanza, i due insiemi (licenze di software libero e licenze open source) sono quasi coincidenti. Personalmente, preferisco usare l'espressione software libero per riferirmi al software che è software libero / open source perché l'espressione software libero richiama implicitamente i valori di libertà e comunità (che trovo importanti). L'espressione open source, invece, è nata proprio per omettere questo richiamo ai valori (che i fondatori della Open Source Initiative ritenevano d'intralcio nella diffusione in ambito "industriale"). m.c. -------- [1] http://www.gnu.org/philosophy/free-sw.html [2] http://www.opensource.org/docs/definition.php

Sept. 13, 2018

Re: [nexa] Come bypassare firewall e proxy aziendali (e di PA, banche.. etc)

by Giacomo Tesio

Il giorno 13 settembre 2018 17:12, Alberto Cammozzo <ac+nexa(a)zeromx.net> ha scritto: > > Osservazione a margine: la lista Nexa sta diventando sempre più tecnica! Io direi piuttosto che questa lista crea un dialogo costruttivo fra persone con competenze tecniche diverse: diritto, informatica, economia, sociologia... Da dialoghi come questi, secondo me, dovrebbero emergere le sintesi Politiche anche in Parlamento. L'idea della Politica come professione, come competenza a se stante, secondo me è profondamente contraria ai valori democratici espressi dalla Costituzione della Repubblica Italiana agli articoli 1, 56, 58 e 67. Altrimenti, con un paio di concorsi pubblici potremmo risparmiarci campagne elettorali ed elezioni! > Nel merito: > > On 13/09/2018 10:56, Stefano Quintarelli wrote: > > cosa dovrebbe consentire javascript ? > Sorprende (o meglio, ahimè, non sorprende più, fa solo rabbia) che si > commettano sempre gli stessi errori: gli script nei file microsoft word, > nei PDF, perfino Postscript nelle stampanti: > <https://www.securityweek.com/printer-vulnerabilities-expose-organizations-a…>. Hai ragione, non impariamo mai. Per questo secondo me dobbiamo partire dalle elementari. Per creare una generazione di hacker capaci di non ripetere (e di difendersi/difenderci da) i nostri errori. > Javascript nei browser non dovrebbe poter mandare richieste HTTP con > contenuto arbitrario a destinazioni arbitrarie. Punto. Ci libereremmo di > un bel po' di botnet. Se può aggiungere HTML al DOM della pagina, può far partire richieste HTTP. > Se però, come richiede molto ragionevolmente Giacomo, dovessimo > espressamente autorizzare gli script che usano "liberamente" la rete, > rischieremmo lo stesso effetto dei privacy cookies: dovresti farlo così > spesso che alla fine autorizzeremmo senza guardare, aprendo la strada a > attacchi più gravi di script che accedono a telecamera, microfono, dati, > ecc... Per la verità la mia proposta è un po' più articolata, ma non propone una tale precisione nei permessi. Poter semplicemente abilitare JS per sito web (e dunque averlo disabilitato di default) ridurrebbe del 95% l'ammontare di JavaScript in transito sul web. La stragrande maggioranza delle pagine web che usa JS non ne ha veramente bisogno. > Oppure cambia l'architettura: il browser costruisce una macchina > virtuale per ogni pagina e parla con un indirizzo alla volta, o al > limite solo con quelli autorizzati in un campo dell'header HTTP ad hoc, > o con quelli indicati da un meccanismo analogo a SPF per la mail. Preferirei avere il controllo su cosa eseguire sui miei device. In generale. > Ma se mi chiedi di scommettere, direi che la soluzione proposta sarà un > sistema centralizzato di certificazione e firma degli script, stile app. > Così "per la tua sicurezza" ti verrà chiesto di autorizzare solo gli > script "non certificati sicuri" (come avviene per i certificati SSL) che > non vengono da uno dei soliti repository. > Sempre perché si commettono sempre gli stessi errori. Beh.. ma ci sarà qualcuno al mondo capace di dire "No" a questa gente! > Potresti anche inconsapevolmente contribuire a un repository > "distribuito" di materiale che qualcun'altro non vuole tenere in casa: > <https://github.com/seantmalone/HiveMind> Quinto attacco che mi è venuto in mente. :-) > Oppure un dispettoso potrebbe lasciarti del materiale di cui faresti > fatica a giustificare il possesso in caso di sequestro. Primo attacco che mi è venuto in mente. Il secondo è stato: metto materiale illegale (lista dei pagamenti del pizzo, pedopornografia, progetti rubati alla concorrenza) nella cache del browser, così se mi sequestrano il PC, la sola esistenza di questi attacchi mi fornisce una giustificazione plausibile. > > e se uno non vuole consentirlo ? > > su firefox basta usare plugin come noscript e/o umatrix > > tra l'altro consiglio di farlo a tutti e collegarsi poi ad una pagina > > di youtube (ad esempio) > > Mi associo caldamente alla raccomandazione. > Umatrix è formidabile. Non discuto la qualità di questi tool. Qui trovate istruzioni precise su come rendere Firefox un browser decente dal punto di vista di sicurezza: http://sciops.net/information/browser_setup/firefox Ma anche quelle istruzioni, non possono niente contro questi attacchi. La sicurezza non deve essere OPT-IN. Giacomo

Sept. 13, 2018

Re: [nexa] Come bypassare firewall e proxy aziendali (e di PA, banche.. etc)

by Alberto Cammozzo

Osservazione a margine: la lista Nexa sta diventando sempre più tecnica! Nel merito: On 13/09/2018 10:56, Stefano Quintarelli wrote: > cosa dovrebbe consentire javascript ? Sorprende (o meglio, ahimè, non sorprende più, fa solo rabbia) che si commettano sempre gli stessi errori: gli script nei file microsoft word, nei PDF, perfino Postscript nelle stampanti: <https://www.securityweek.com/printer-vulnerabilities-expose-organizations-a…>. Javascript nei browser non dovrebbe poter mandare richieste HTTP con contenuto arbitrario a destinazioni arbitrarie. Punto. Ci libereremmo di un bel po' di botnet. > puo' collegarsi a computer diversi da quello dell'utente ? certamente, > per comunicare con il server da cui proviene. > > può scaricare oggetti, diciamo immagini, da un computer con un > determinato indirizzo ? beh, tutte le pagine web sono composte cosi'. > (a partire dalla webmail) > > una alternativa potrebbe essere che consenta di comunicare solo con il > computer che lo ha servito. Speedtest, per esempio, non funzionerebbe. > (forse nemmeno neubot, e nemmeno quasi tutto il mercato pubblictario). Con l'attuale architettura non funzionerebbe quasi nulla: gli script raramente risiedono nel sito che li richiede e quindi quasi mai parlano col sito dal quale vengono. Se fossero autorizzati gli script solo del sito dal quale proviene la pagina principale escluderesti apis.google.com e miriadi di altri, sui quali risiedono quasi tutti gli script (e i font) usati in giro (favorendo ovviamente il tracking). Se però, come richiede molto ragionevolmente Giacomo, dovessimo espressamente autorizzare gli script che usano "liberamente" la rete, rischieremmo lo stesso effetto dei privacy cookies: dovresti farlo così spesso che alla fine autorizzeremmo senza guardare, aprendo la strada a attacchi più gravi di script che accedono a telecamera, microfono, dati, ecc... Oppure cambia l'architettura: il browser costruisce una macchina virtuale per ogni pagina e parla con un indirizzo alla volta, o al limite solo con quelli autorizzati in un campo dell'header HTTP ad hoc, o con quelli indicati da un meccanismo analogo a SPF per la mail. Ma se mi chiedi di scommettere, direi che la soluzione proposta sarà un sistema centralizzato di certificazione e firma degli script, stile app. Così "per la tua sicurezza" ti verrà chiesto di autorizzare solo gli script "non certificati sicuri" (come avviene per i certificati SSL) che non vengono da uno dei soliti repository. Sempre perché si commettono sempre gli stessi errori. > queste due cose che consente, possono essere usate da qualcuno per > acquisire informazioni ? ogni cosa fatta su un computer da remoto > consente di acquisire informazioni, dalla latenza di un collegamento > al fatto che il computer a cui si collega risponda o meno. (che e' > l'esempio sotto) Potresti anche inconsapevolmente contribuire a un repository "distribuito" di materiale che qualcun'altro non vuole tenere in casa: <https://github.com/seantmalone/HiveMind> Oppure un dispettoso potrebbe lasciarti del materiale di cui faresti fatica a giustificare il possesso in caso di sequestro. > e se uno non vuole consentirlo ? > su firefox basta usare plugin come noscript e/o umatrix > tra l'altro consiglio di farlo a tutti e collegarsi poi ad una pagina > di youtube (ad esempio) Mi associo caldamente alla raccomandazione. Umatrix è formidabile. Alberto > > On 13/09/2018 10:29, Marco Ciurcina wrote: >> "I'm not bad. I'm just drawn that way." >> (Jessica Rabbit in Who Censored Roger Rabbit?) >> >> Per fortuna Firefox è software libero: c'è la speranza che qualche >> sviluppatore faccia un fork. >> >> m.c. >> >> >> In data giovedì 13 settembre 2018 00:13:03 CEST, Giacomo Tesio ha >> scritto: >>> Salve, e' stato pubblicato un nuovo exploit del bug che ho recentemente >>> segnalato a Mozilla e Google. >>> >>> Basically any old webpage can perform local network host discovery >>> on you. >>> >>>> To implement this I made a webpage which attempts to load images from >>>> addresses 192.168.1.x. If you watch in the browser console it’ll show >>>> either net::ERR_CONNECTION_REFUSED for a host that’s up or >>>> net::ERR_ADDRESS_UNREACHABLE for a host that doesn’t exist. This is >>>> a CORS >>>> error which the javascript on the webpage is not allowed to >>>> differentiate >>>> by catching. But one error takes 3 ms to happen and the other takes 3 >>>> seconds! >>>> [...] >>>> A related thing a webpage in your browser might do is connect to >>>> localhost >>>> and control any unauthenticated local services. Taviso used this to >>>> great >>>> effect here https://github.com/spesmilo/electrum/issues/3374 >>> >>> https://rain-1.github.io/in-browser-localhostdiscovery >>> >>> E con questo siamo a 2 exploit che vanificano firewall e proxy >>> aziendali. >>> E io ne ho descritti altri nel bug report! >>> >>> E Mozilla tace. Io sono allibito. >>> >>> Ricordate "this is the Web functioning as desinged"! >>> >>> >>> Giacomo >> >> >> _______________________________________________ >> nexa mailing list >> nexa(a)server-nexa.polito.it >> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >> > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Sept. 13, 2018

Re: [nexa] Come bypassare firewall e proxy aziendali (e di PA, banche.. etc)

by Giacomo Tesio

Fantastico. :-) Onestamente mi ero perso il BeEF project. Grazie davvero per il link. Spero che a Mozilla, Google, Microsoft e Apple non fosse sfuggito, però! Sarebbe persino peggio della mala fede! Forse per questo non hanno risposto quando ho chiesto (ripetutamente) se i loro utenti fossero vulnerabili a questi attacchi o meno. Comunque il problema che ho posto io dipende in larga parte dal protocollo HTTP: - dagli header HTTP che permettono di identificare l'obbiettivo (ma può bastare l'IP, o il keep alive... per questo dicevo che ogni JS, ogni CSS e ogni risorsa esterna dovrebbe essere veicolata da una nuova connessione TCP e non contenere headers!) - dalle direttive di cache control che permettono di rimuovere le prove Tutto questo, unito ad un linguaggio di programmazione Turing complete, con accesso alle risorse suddette ed eseguito ciecamente dall'utente rende la superficie di attacco larghissima e il rischio minimo. E pensa poi con WebAssembly! Io mi sono già trovato a debuggare binari senza disporre del sorgente o dei simboli di debug. Chi dice che non cambierà niente perché anche oggi si offusca il JS, no sa di cosa parla. Giacomo Il giorno 13 settembre 2018 14:03, Stefano Traverso < s.traverso(a)ermessecurity.com> ha scritto: > Ciao Giacomo, > Le cose sono a mio avviso anche piu’ preoccupanti. > I ragazzi di BeEF project (https://github.com/beefproject/beef/wiki/ > Introducing-BeEF) hanno dimostrato che con un po’ di JS si possono fare > cose ben piu’ turpi di network/port scan. In primis raccogliere > informazioni personali, ma si arriva anche a rubare credenziali e ottenere > reverse shell su SO/browser obsoleti con relativa facitlita’. > > Stefano > > — > Stefano Traverso, PhD > Chief Technical Officer @ Ermes Cyber Security > <https://www.ermessecurity.com> > Mail: s.traverso(a)ermessecurity.com > Skype: tigredcarta > > On 13 Sep 2018, at 12:13, Giacomo Tesio <giacomo(a)tesio.it> wrote: > > Scusa Stefano, mi rendo conto ora che forse non avevo capito il tuo dubbio. > > Una volta entrato nella tua rete privata (o VPN) attraverso JS, posso > trasferire informazioni sulla sua topologia all'esterno ed eseguire > attacchi su eventuali servizi presenti in essa. > > Sempre senza lasciare traccie. > > Posso anche attacchare terze parti. Senza lasciare tracce del mio attacco, > ma lasciando tracce che riconducono alla tua macchina. > > Pensa quanto può essere utile questo in ambito di spionaggio industriale. > > > Spero di essere stato più chiaro... > > > Giacomo > > > > Il giorno 13 settembre 2018 12:08, Giacomo Tesio <giacomo(a)tesio.it> ha > scritto: > >> Aggiungo: come hacker mi può anche stare bene che alla comunità di >> Chromium e Mozilla non interessi prevenire questi attacchi. >> Ognuno deve essere libero di investire il proprio tempo per perseguire la >> PROPRIA curiosità. >> >> Ma quello che non posso accettare è il tentativo (che a questo punto a me >> sembrerebbe evidente) di NON INFORMARE gli utenti. >> >> >> Giacomo >> >> >> Il giorno 13 settembre 2018 11:59, Giacomo Tesio <giacomo(a)tesio.it> ha >> scritto: >> >>> Il giorno 13 settembre 2018 10:56, Stefano Quintarelli < >>> stefano(a)quintarelli.it> ha scritto: >>> >>>> cosa dovrebbe consentire javascript ? >>>> >>> >>> Come ho scritto nel bug report, JavaScript dovrebbe (e potrebbe) essere >>> reso molto più sicuro attraverso piccole modifiche. >>> In sintesi >>> <https://medium.com/@giacomo_59737/i-compiled-a-detailed-bug-report-for-mozi…> >>> : >>> >>>> Anyway, to answer your question, the solution is simple, if it’s not >>>> easy. >>>> *The execution of Web software should be opt-in, not opt-out * >>>> (if you can opt-out, given how usable are the UI to disable JavaScript >>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c9>). >>>> >>>> Now, given the *severity of the issue*, as a first step I would >>>> release an *emergency fix that disable JavaScript* (and Meta Refresh) >>>> without looking at the user settings. >>>> >>>> Then I would deploy a mid term fix so that: >>>> >>>> - Page Refresh though META tag and JavaScript are disabled by >>>> default >>>> - Both can be enabled on a per website basis, but >>>> — No script or CSS is requested with Cookies or other HTTP headers >>>> — Each script and CSS is requested through a dedicated TCP >>>> connection >>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c12> >>>> — SubResource Integrity <https://www.w3.org/TR/SRI/> 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 >>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c13> >>>> (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” >>>> <https://www.blog.google/products/chrome/milestone-chrome-security-marking-h…> >>>> web pages visited for the first time that require JavaScript. >>>> >>>> >>> (scusa il cut&paste, ma sono un po' di corsa) >>> >>> >>> Il giorno 13 settembre 2018 10:56, Stefano Quintarelli < >>> stefano(a)quintarelli.it> ha scritto: >>> >>>> puo' collegarsi a computer diversi da quello dell'utente ? certamente, >>>> per comunicare con il server da cui proviene. >>>> >>>> può scaricare oggetti, diciamo immagini, da un computer con un >>>> determinato indirizzo ? beh, tutte le pagine web sono composte cosi'. (a >>>> partire dalla webmail) >>>> >>>> una alternativa potrebbe essere che consenta di comunicare solo con il >>>> computer che lo ha servito. Speedtest, per esempio, non funzionerebbe. >>>> (forse nemmeno neubot, e nemmeno quasi tutto il mercato pubblictario). >>>> >>>> queste due cose che consente, possono essere usate da qualcuno per >>>> acquisire informazioni ? >>>> >>> >>> No. >>> >>> Attraverso l'uso appropriato degli header HTTP (cache control etc), >>> qualsiasi JavaScript può sostituire se stesso sul disco rimuovendo le >>> tracce di un attacco. >>> Se il server (o la CDN) può identificare l'obbiettivo (non solo privati >>> cittadini, pensa ad un ospedale con un IP fisso, o ad un comune o un >>> ufficio di polizia, o un'azienda) può servire SOLO all'obbiettivo, SOLO una >>> volta, JavaScript malevolo e poi rimuoverlo alla fine dell'attacco. >>> Attraverso quel JavaScript può sfruttare diverse risorse della vittima >>> (cut&paste dal report) >>> >>> - their IP >>> - their bandwith >>> - their computing power >>> - their RAM >>> - their disk (through browser cache) >>> - potentially others resources (gained through access to system vulnerabilities, think about Spectre/Meltdown) >>> >>> e questo permette tutte una enorme varietà di attacchi la cui >>> realizzazione è veramente banale. >>> >>> In questi due exploit (il mio e quello di rain1) usiamo JavaScript ed un >>> banalissimo DNS rebinding per penetrare la rete privata della vittima. >>> >>> Ma sono solo due degli attacchi possibili: davvero qualunque >>> sviluppatore web con un minimo di competenza e fantasia ne può pensare a >>> bizzeffe. >>> E qualunque sito web (o CDN! chi controlla le CDN?) può veicolarli, >>> anche all'insaputa del creatore del sito stesso: basta controllare >>> l'hosting (il Cloud! chi controlla il Cloud?) >>> >>> E tutto questo vale ancora di più per WebAssembly: nemmeno con un proxy >>> che logga l'intero contenuto delle comunicazioni HTTP e HTTPS sarebbe >>> possibile osservare l'attacco (mentre con JS sarebbe possibile, avedo un >>> paio di persone che analizzano i log quotidianamente). >>> >>> >>> ogni cosa fatta su un computer da remoto consente di acquisire >>>> informazioni, dalla latenza di un collegamento al fatto che il computer a >>>> cui si collega risponda o meno. (che e' l'esempio sotto) >>>> >>> >>> Scusa, ma allora perché installiamo antivirus, firewall, certificati SSL >>> etc? >>> Se tanto non serve a niente! Risparmiamo soldi, tempo e preziosa >>> energia, non credi? >>> >>> >>> e se uno non vuole consentirlo ? >>>> su firefox basta usare plugin come noscript e/o umatrix >>>> >>> >>> No, contro questi attacchi questi plugin non possono nulla. >>> >>> Una volta che hai autorizzato un certo dominio, sei vulnerabile, perché >>> il server (o la CDN) può cambiare il codice DOPO aver ottenuto il tuo >>> permesso di esecuzione sulla tua macchina. >>> >>> >>> >>>> tra l'altro consiglio di farlo a tutti e collegarsi poi ad una pagina >>>> di youtube (ad esempio) >>>> >>> >>> Io ad oggi consiglio di usare due browser: >>> - un Firefox con JavaScript disabilitato da usare su tutti i siti che >>> funzionano >>> - un Chrome per tutti quelli che proprio non funzionano senza JS (e non >>> si può evitare di usare). >>> >>> Ma il suggerimento di installare NoScript o UMatrix (o di utilizzare due >>> browser) è intrinsecamente fallace. >>> >>> >>> La OPT-IN SECURITY non funziona: basta un dipendente distratto per >>> entrare nella rete di una banca con questi attacchi. >>> >>> Abilitare l'esecuzione di JavaScript sito per sito, invece, è >>> perfettamente usabile. Come lo è per le notifiche push di HTTP/2! >>> E come lo era per Flash o per le Applet Java. >>> >>> >>> Ai miei occhi, tutto questo indignarsi per una soluzione semplice e >>> ovvia come rendere JavaScript opt-in (e più sicuro) è prova di >>> straordinaria disonestà intellettuale da parte di sviluppatori, come quelli >>> di Mozilla, che si declamano campioni della privacy! >>> >>> >>> >>> Giacomo >>> >>> >>> >>> >>>> >>>> ciao, s. >>>> >>>> >>>> >>>> On 13/09/2018 10:29, Marco Ciurcina wrote: >>>> >>>>> "I'm not bad. I'm just drawn that way." >>>>> (Jessica Rabbit in Who Censored Roger Rabbit?) >>>>> >>>>> Per fortuna Firefox è software libero: c'è la speranza che qualche >>>>> sviluppatore faccia un fork. >>>>> >>>>> m.c. >>>>> >>>>> >>>>> In data giovedì 13 settembre 2018 00:13:03 CEST, Giacomo Tesio ha >>>>> scritto: >>>>> >>>>>> Salve, e' stato pubblicato un nuovo exploit del bug che ho >>>>>> recentemente >>>>>> segnalato a Mozilla e Google. >>>>>> >>>>>> Basically any old webpage can perform local network host discovery on >>>>>> you. >>>>>> >>>>>> To implement this I made a webpage which attempts to load images from >>>>>>> addresses 192.168.1.x. If you watch in the browser console it’ll show >>>>>>> either net::ERR_CONNECTION_REFUSED for a host that’s up or >>>>>>> net::ERR_ADDRESS_UNREACHABLE for a host that doesn’t exist. This is >>>>>>> a CORS >>>>>>> error which the javascript on the webpage is not allowed to >>>>>>> differentiate >>>>>>> by catching. But one error takes 3 ms to happen and the other takes 3 >>>>>>> seconds! >>>>>>> [...] >>>>>>> A related thing a webpage in your browser might do is connect to >>>>>>> localhost >>>>>>> and control any unauthenticated local services. Taviso used this to >>>>>>> great >>>>>>> effect here https://github.com/spesmilo/electrum/issues/3374 >>>>>>> >>>>>> >>>>>> https://rain-1.github.io/in-browser-localhostdiscovery >>>>>> >>>>>> E con questo siamo a 2 exploit che vanificano firewall e proxy >>>>>> aziendali. >>>>>> E io ne ho descritti altri nel bug report! >>>>>> >>>>>> E Mozilla tace. Io sono allibito. >>>>>> >>>>>> Ricordate "this is the Web functioning as desinged"! >>>>>> >>>>>> >>>>>> Giacomo >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> nexa mailing list >>>>> nexa(a)server-nexa.polito.it >>>>> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >>>>> >>>>> _______________________________________________ >>>> nexa mailing list >>>> nexa(a)server-nexa.polito.it >>>> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >>>> >>> >>> >> > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > > >

Sept. 13, 2018

Re: [nexa] Come bypassare firewall e proxy aziendali (e di PA, banche.. etc)

by Stefano Traverso

Ciao Giacomo, Le cose sono a mio avviso anche piu’ preoccupanti. I ragazzi di BeEF project (https://github.com/beefproject/beef/wiki/Introducing-BeEF) hanno dimostrato che con un po’ di JS si possono fare cose ben piu’ turpi di network/port scan. In primis raccogliere informazioni personali, ma si arriva anche a rubare credenziali e ottenere reverse shell su SO/browser obsoleti con relativa facitlita’. Stefano — Stefano Traverso, PhD Chief Technical Officer @ Ermes Cyber Security <https://www.ermessecurity.com/> Mail: s.traverso(a)ermessecurity.com Skype: tigredcarta > On 13 Sep 2018, at 12:13, Giacomo Tesio <giacomo(a)tesio.it> wrote: > > Scusa Stefano, mi rendo conto ora che forse non avevo capito il tuo dubbio. > > Una volta entrato nella tua rete privata (o VPN) attraverso JS, posso trasferire informazioni sulla sua topologia all'esterno ed eseguire attacchi su eventuali servizi presenti in essa. > > Sempre senza lasciare traccie. > > Posso anche attacchare terze parti. Senza lasciare tracce del mio attacco, ma lasciando tracce che riconducono alla tua macchina. > > Pensa quanto può essere utile questo in ambito di spionaggio industriale. > > > Spero di essere stato più chiaro... > > > Giacomo > > > > Il giorno 13 settembre 2018 12:08, Giacomo Tesio <giacomo(a)tesio.it <mailto:giacomo@tesio.it>> ha scritto: > Aggiungo: come hacker mi può anche stare bene che alla comunità di Chromium e Mozilla non interessi prevenire questi attacchi. > Ognuno deve essere libero di investire il proprio tempo per perseguire la PROPRIA curiosità. > > Ma quello che non posso accettare è il tentativo (che a questo punto a me sembrerebbe evidente) di NON INFORMARE gli utenti. > > > Giacomo > > > Il giorno 13 settembre 2018 11:59, Giacomo Tesio <giacomo(a)tesio.it <mailto:giacomo@tesio.it>> ha scritto: > Il giorno 13 settembre 2018 10:56, Stefano Quintarelli <stefano(a)quintarelli.it <mailto:stefano@quintarelli.it>> ha scritto: > cosa dovrebbe consentire javascript ? > > Come ho scritto nel bug report, JavaScript dovrebbe (e potrebbe) essere reso molto più sicuro attraverso piccole modifiche. > In sintesi <https://medium.com/@giacomo_59737/i-compiled-a-detailed-bug-report-for-mozi…>: > Anyway, to answer your question, the solution is simple, if it’s not easy. > The execution of Web software should be opt-in, not opt-out > (if you can opt-out, given how usable are the UI to disable JavaScript <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c9>). > > Now, given the severity of the issue, as a first step I would release an emergency fix that disable JavaScript (and Meta Refresh) without looking at the user settings. > > Then I would deploy a mid term fix so that: > > Page Refresh though META tag and JavaScript are disabled by default > Both can be enabled on a per website basis, but > — No script or CSS is requested with Cookies or other HTTP headers > — Each script and CSS is requested through a dedicated TCP connection <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c12> > — SubResource Integrity <https://www.w3.org/TR/SRI/> 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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c13> (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” <https://www.blog.google/products/chrome/milestone-chrome-security-marking-h…> web pages visited for the first time that require JavaScript. > > > > (scusa il cut&paste, ma sono un po' di corsa) > > > Il giorno 13 settembre 2018 10:56, Stefano Quintarelli <stefano(a)quintarelli.it <mailto:stefano@quintarelli.it>> ha scritto: > puo' collegarsi a computer diversi da quello dell'utente ? certamente, per comunicare con il server da cui proviene. > > può scaricare oggetti, diciamo immagini, da un computer con un determinato indirizzo ? beh, tutte le pagine web sono composte cosi'. (a partire dalla webmail) > > una alternativa potrebbe essere che consenta di comunicare solo con il computer che lo ha servito. Speedtest, per esempio, non funzionerebbe. (forse nemmeno neubot, e nemmeno quasi tutto il mercato pubblictario). > > queste due cose che consente, possono essere usate da qualcuno per acquisire informazioni ? > > No. > > Attraverso l'uso appropriato degli header HTTP (cache control etc), qualsiasi JavaScript può sostituire se stesso sul disco rimuovendo le tracce di un attacco. > Se il server (o la CDN) può identificare l'obbiettivo (non solo privati cittadini, pensa ad un ospedale con un IP fisso, o ad un comune o un ufficio di polizia, o un'azienda) può servire SOLO all'obbiettivo, SOLO una volta, JavaScript malevolo e poi rimuoverlo alla fine dell'attacco. > Attraverso quel JavaScript può sfruttare diverse risorse della vittima (cut&paste dal report) > - their IP > - their bandwith > - their computing power > - their RAM > - their disk (through browser cache) > - potentially others resources (gained through access to system vulnerabilities, think about Spectre/Meltdown) > e questo permette tutte una enorme varietà di attacchi la cui realizzazione è veramente banale. > > In questi due exploit (il mio e quello di rain1) usiamo JavaScript ed un banalissimo DNS rebinding per penetrare la rete privata della vittima. > > Ma sono solo due degli attacchi possibili: davvero qualunque sviluppatore web con un minimo di competenza e fantasia ne può pensare a bizzeffe. > E qualunque sito web (o CDN! chi controlla le CDN?) può veicolarli, anche all'insaputa del creatore del sito stesso: basta controllare l'hosting (il Cloud! chi controlla il Cloud?) > > E tutto questo vale ancora di più per WebAssembly: nemmeno con un proxy che logga l'intero contenuto delle comunicazioni HTTP e HTTPS sarebbe possibile osservare l'attacco (mentre con JS sarebbe possibile, avedo un paio di persone che analizzano i log quotidianamente). > > > ogni cosa fatta su un computer da remoto consente di acquisire informazioni, dalla latenza di un collegamento al fatto che il computer a cui si collega risponda o meno. (che e' l'esempio sotto) > > Scusa, ma allora perché installiamo antivirus, firewall, certificati SSL etc? > Se tanto non serve a niente! Risparmiamo soldi, tempo e preziosa energia, non credi? > > > e se uno non vuole consentirlo ? > su firefox basta usare plugin come noscript e/o umatrix > > No, contro questi attacchi questi plugin non possono nulla. > > Una volta che hai autorizzato un certo dominio, sei vulnerabile, perché il server (o la CDN) può cambiare il codice DOPO aver ottenuto il tuo permesso di esecuzione sulla tua macchina. > > > tra l'altro consiglio di farlo a tutti e collegarsi poi ad una pagina di youtube (ad esempio) > > Io ad oggi consiglio di usare due browser: > - un Firefox con JavaScript disabilitato da usare su tutti i siti che funzionano > - un Chrome per tutti quelli che proprio non funzionano senza JS (e non si può evitare di usare). > > Ma il suggerimento di installare NoScript o UMatrix (o di utilizzare due browser) è intrinsecamente fallace. > > > La OPT-IN SECURITY non funziona: basta un dipendente distratto per entrare nella rete di una banca con questi attacchi. > > Abilitare l'esecuzione di JavaScript sito per sito, invece, è perfettamente usabile. Come lo è per le notifiche push di HTTP/2! > E come lo era per Flash o per le Applet Java. > > > Ai miei occhi, tutto questo indignarsi per una soluzione semplice e ovvia come rendere JavaScript opt-in (e più sicuro) è prova di straordinaria disonestà intellettuale da parte di sviluppatori, come quelli di Mozilla, che si declamano campioni della privacy! > > > > Giacomo > > > > > ciao, s. > > > > On 13/09/2018 10:29, Marco Ciurcina wrote: > "I'm not bad. I'm just drawn that way." > (Jessica Rabbit in Who Censored Roger Rabbit?) > > Per fortuna Firefox è software libero: c'è la speranza che qualche > sviluppatore faccia un fork. > > m.c. > > > In data giovedì 13 settembre 2018 00:13:03 CEST, Giacomo Tesio ha scritto: > Salve, e' stato pubblicato un nuovo exploit del bug che ho recentemente > segnalato a Mozilla e Google. > > Basically any old webpage can perform local network host discovery on you. > > To implement this I made a webpage which attempts to load images from > addresses 192.168.1.x. If you watch in the browser console it’ll show > either net::ERR_CONNECTION_REFUSED for a host that’s up or > net::ERR_ADDRESS_UNREACHABLE for a host that doesn’t exist. This is a CORS > error which the javascript on the webpage is not allowed to differentiate > by catching. But one error takes 3 ms to happen and the other takes 3 > seconds! > [...] > A related thing a webpage in your browser might do is connect to localhost > and control any unauthenticated local services. Taviso used this to great > effect here https://github.com/spesmilo/electrum/issues/3374 <https://github.com/spesmilo/electrum/issues/3374> > > https://rain-1.github.io/in-browser-localhostdiscovery <https://rain-1.github.io/in-browser-localhostdiscovery> > > E con questo siamo a 2 exploit che vanificano firewall e proxy aziendali. > E io ne ho descritti altri nel bug report! > > E Mozilla tace. Io sono allibito. > > Ricordate "this is the Web functioning as desinged"! > > > Giacomo > > > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa <https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa> > > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa <https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa> > > > > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Sept. 13, 2018

Re: [nexa] Come bypassare firewall e proxy aziendali (e di PA, banche.. etc)

by Giacomo Tesio

Scusa Stefano, mi rendo conto ora che forse non avevo capito il tuo dubbio. Una volta entrato nella tua rete privata (o VPN) attraverso JS, posso trasferire informazioni sulla sua topologia all'esterno ed eseguire attacchi su eventuali servizi presenti in essa. Sempre senza lasciare traccie. Posso anche attacchare terze parti. Senza lasciare tracce del mio attacco, ma lasciando tracce che riconducono alla tua macchina. Pensa quanto può essere utile questo in ambito di spionaggio industriale. Spero di essere stato più chiaro... Giacomo Il giorno 13 settembre 2018 12:08, Giacomo Tesio <giacomo(a)tesio.it> ha scritto: > Aggiungo: come hacker mi può anche stare bene che alla comunità di > Chromium e Mozilla non interessi prevenire questi attacchi. > Ognuno deve essere libero di investire il proprio tempo per perseguire la > PROPRIA curiosità. > > Ma quello che non posso accettare è il tentativo (che a questo punto a me > sembrerebbe evidente) di NON INFORMARE gli utenti. > > > Giacomo > > > Il giorno 13 settembre 2018 11:59, Giacomo Tesio <giacomo(a)tesio.it> ha > scritto: > >> Il giorno 13 settembre 2018 10:56, Stefano Quintarelli < >> stefano(a)quintarelli.it> ha scritto: >> >>> cosa dovrebbe consentire javascript ? >>> >> >> Come ho scritto nel bug report, JavaScript dovrebbe (e potrebbe) essere >> reso molto più sicuro attraverso piccole modifiche. >> In sintesi >> <https://medium.com/@giacomo_59737/i-compiled-a-detailed-bug-report-for-mozi…> >> : >> >>> Anyway, to answer your question, the solution is simple, if it’s not >>> easy. >>> *The execution of Web software should be opt-in, not opt-out * >>> (if you can opt-out, given how usable are the UI to disable JavaScript >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c9>). >>> >>> Now, given the *severity of the issue*, as a first step I would release >>> an *emergency fix that disable JavaScript* (and Meta Refresh) without >>> looking at the user settings. >>> >>> Then I would deploy a mid term fix so that: >>> >>> - Page Refresh though META tag and JavaScript are disabled by default >>> - Both can be enabled on a per website basis, but >>> — No script or CSS is requested with Cookies or other HTTP headers >>> — Each script and CSS is requested through a dedicated TCP connection >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c12> >>> — SubResource Integrity <https://www.w3.org/TR/SRI/> 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 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c13> (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” >>> <https://www.blog.google/products/chrome/milestone-chrome-security-marking-h…> >>> web pages visited for the first time that require JavaScript. >>> >>> >> (scusa il cut&paste, ma sono un po' di corsa) >> >> >> Il giorno 13 settembre 2018 10:56, Stefano Quintarelli < >> stefano(a)quintarelli.it> ha scritto: >> >>> puo' collegarsi a computer diversi da quello dell'utente ? certamente, >>> per comunicare con il server da cui proviene. >>> >>> può scaricare oggetti, diciamo immagini, da un computer con un >>> determinato indirizzo ? beh, tutte le pagine web sono composte cosi'. (a >>> partire dalla webmail) >>> >>> una alternativa potrebbe essere che consenta di comunicare solo con il >>> computer che lo ha servito. Speedtest, per esempio, non funzionerebbe. >>> (forse nemmeno neubot, e nemmeno quasi tutto il mercato pubblictario). >>> >>> queste due cose che consente, possono essere usate da qualcuno per >>> acquisire informazioni ? >>> >> >> No. >> >> Attraverso l'uso appropriato degli header HTTP (cache control etc), >> qualsiasi JavaScript può sostituire se stesso sul disco rimuovendo le >> tracce di un attacco. >> Se il server (o la CDN) può identificare l'obbiettivo (non solo privati >> cittadini, pensa ad un ospedale con un IP fisso, o ad un comune o un >> ufficio di polizia, o un'azienda) può servire SOLO all'obbiettivo, SOLO una >> volta, JavaScript malevolo e poi rimuoverlo alla fine dell'attacco. >> Attraverso quel JavaScript può sfruttare diverse risorse della vittima >> (cut&paste dal report) >> >> - their IP >> - their bandwith >> - their computing power >> - their RAM >> - their disk (through browser cache) >> - potentially others resources (gained through access to system vulnerabilities, think about Spectre/Meltdown) >> >> e questo permette tutte una enorme varietà di attacchi la cui >> realizzazione è veramente banale. >> >> In questi due exploit (il mio e quello di rain1) usiamo JavaScript ed un >> banalissimo DNS rebinding per penetrare la rete privata della vittima. >> >> Ma sono solo due degli attacchi possibili: davvero qualunque sviluppatore >> web con un minimo di competenza e fantasia ne può pensare a bizzeffe. >> E qualunque sito web (o CDN! chi controlla le CDN?) può veicolarli, anche >> all'insaputa del creatore del sito stesso: basta controllare l'hosting (il >> Cloud! chi controlla il Cloud?) >> >> E tutto questo vale ancora di più per WebAssembly: nemmeno con un proxy >> che logga l'intero contenuto delle comunicazioni HTTP e HTTPS sarebbe >> possibile osservare l'attacco (mentre con JS sarebbe possibile, avedo un >> paio di persone che analizzano i log quotidianamente). >> >> >> ogni cosa fatta su un computer da remoto consente di acquisire >>> informazioni, dalla latenza di un collegamento al fatto che il computer a >>> cui si collega risponda o meno. (che e' l'esempio sotto) >>> >> >> Scusa, ma allora perché installiamo antivirus, firewall, certificati SSL >> etc? >> Se tanto non serve a niente! Risparmiamo soldi, tempo e preziosa energia, >> non credi? >> >> >> e se uno non vuole consentirlo ? >>> su firefox basta usare plugin come noscript e/o umatrix >>> >> >> No, contro questi attacchi questi plugin non possono nulla. >> >> Una volta che hai autorizzato un certo dominio, sei vulnerabile, perché >> il server (o la CDN) può cambiare il codice DOPO aver ottenuto il tuo >> permesso di esecuzione sulla tua macchina. >> >> >> >>> tra l'altro consiglio di farlo a tutti e collegarsi poi ad una pagina di >>> youtube (ad esempio) >>> >> >> Io ad oggi consiglio di usare due browser: >> - un Firefox con JavaScript disabilitato da usare su tutti i siti che >> funzionano >> - un Chrome per tutti quelli che proprio non funzionano senza JS (e non >> si può evitare di usare). >> >> Ma il suggerimento di installare NoScript o UMatrix (o di utilizzare due >> browser) è intrinsecamente fallace. >> >> >> La OPT-IN SECURITY non funziona: basta un dipendente distratto per >> entrare nella rete di una banca con questi attacchi. >> >> Abilitare l'esecuzione di JavaScript sito per sito, invece, è >> perfettamente usabile. Come lo è per le notifiche push di HTTP/2! >> E come lo era per Flash o per le Applet Java. >> >> >> Ai miei occhi, tutto questo indignarsi per una soluzione semplice e ovvia >> come rendere JavaScript opt-in (e più sicuro) è prova di straordinaria >> disonestà intellettuale da parte di sviluppatori, come quelli di Mozilla, >> che si declamano campioni della privacy! >> >> >> >> Giacomo >> >> >> >> >>> >>> ciao, s. >>> >>> >>> >>> On 13/09/2018 10:29, Marco Ciurcina wrote: >>> >>>> "I'm not bad. I'm just drawn that way." >>>> (Jessica Rabbit in Who Censored Roger Rabbit?) >>>> >>>> Per fortuna Firefox è software libero: c'è la speranza che qualche >>>> sviluppatore faccia un fork. >>>> >>>> m.c. >>>> >>>> >>>> In data giovedì 13 settembre 2018 00:13:03 CEST, Giacomo Tesio ha >>>> scritto: >>>> >>>>> Salve, e' stato pubblicato un nuovo exploit del bug che ho recentemente >>>>> segnalato a Mozilla e Google. >>>>> >>>>> Basically any old webpage can perform local network host discovery on >>>>> you. >>>>> >>>>> To implement this I made a webpage which attempts to load images from >>>>>> addresses 192.168.1.x. If you watch in the browser console it’ll show >>>>>> either net::ERR_CONNECTION_REFUSED for a host that’s up or >>>>>> net::ERR_ADDRESS_UNREACHABLE for a host that doesn’t exist. This is a >>>>>> CORS >>>>>> error which the javascript on the webpage is not allowed to >>>>>> differentiate >>>>>> by catching. But one error takes 3 ms to happen and the other takes 3 >>>>>> seconds! >>>>>> [...] >>>>>> A related thing a webpage in your browser might do is connect to >>>>>> localhost >>>>>> and control any unauthenticated local services. Taviso used this to >>>>>> great >>>>>> effect here https://github.com/spesmilo/electrum/issues/3374 >>>>>> >>>>> >>>>> https://rain-1.github.io/in-browser-localhostdiscovery >>>>> >>>>> E con questo siamo a 2 exploit che vanificano firewall e proxy >>>>> aziendali. >>>>> E io ne ho descritti altri nel bug report! >>>>> >>>>> E Mozilla tace. Io sono allibito. >>>>> >>>>> Ricordate "this is the Web functioning as desinged"! >>>>> >>>>> >>>>> Giacomo >>>>> >>>> >>>> >>>> _______________________________________________ >>>> nexa mailing list >>>> nexa(a)server-nexa.polito.it >>>> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >>>> >>>> _______________________________________________ >>> nexa mailing list >>> nexa(a)server-nexa.polito.it >>> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >>> >> >> >

Sept. 13, 2018

Re: [nexa] Come bypassare firewall e proxy aziendali (e di PA, banche.. etc)

by Giacomo Tesio

Aggiungo: come hacker mi può anche stare bene che alla comunità di Chromium e Mozilla non interessi prevenire questi attacchi. Ognuno deve essere libero di investire il proprio tempo per perseguire la PROPRIA curiosità. Ma quello che non posso accettare è il tentativo (che a questo punto a me sembrerebbe evidente) di NON INFORMARE gli utenti. Giacomo Il giorno 13 settembre 2018 11:59, Giacomo Tesio <giacomo(a)tesio.it> ha scritto: > Il giorno 13 settembre 2018 10:56, Stefano Quintarelli < > stefano(a)quintarelli.it> ha scritto: > >> cosa dovrebbe consentire javascript ? >> > > Come ho scritto nel bug report, JavaScript dovrebbe (e potrebbe) essere > reso molto più sicuro attraverso piccole modifiche. > In sintesi > <https://medium.com/@giacomo_59737/i-compiled-a-detailed-bug-report-for-mozi…> > : > >> Anyway, to answer your question, the solution is simple, if it’s not easy. >> *The execution of Web software should be opt-in, not opt-out * >> (if you can opt-out, given how usable are the UI to disable JavaScript >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c9>). >> >> Now, given the *severity of the issue*, as a first step I would release >> an *emergency fix that disable JavaScript* (and Meta Refresh) without >> looking at the user settings. >> >> Then I would deploy a mid term fix so that: >> >> - Page Refresh though META tag and JavaScript are disabled by default >> - Both can be enabled on a per website basis, but >> — No script or CSS is requested with Cookies or other HTTP headers >> — Each script and CSS is requested through a dedicated TCP connection >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c12> >> — SubResource Integrity <https://www.w3.org/TR/SRI/> 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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c13> >> (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” >> <https://www.blog.google/products/chrome/milestone-chrome-security-marking-h…> >> web pages visited for the first time that require JavaScript. >> >> > (scusa il cut&paste, ma sono un po' di corsa) > > > Il giorno 13 settembre 2018 10:56, Stefano Quintarelli < > stefano(a)quintarelli.it> ha scritto: > >> puo' collegarsi a computer diversi da quello dell'utente ? certamente, >> per comunicare con il server da cui proviene. >> >> può scaricare oggetti, diciamo immagini, da un computer con un >> determinato indirizzo ? beh, tutte le pagine web sono composte cosi'. (a >> partire dalla webmail) >> >> una alternativa potrebbe essere che consenta di comunicare solo con il >> computer che lo ha servito. Speedtest, per esempio, non funzionerebbe. >> (forse nemmeno neubot, e nemmeno quasi tutto il mercato pubblictario). >> >> queste due cose che consente, possono essere usate da qualcuno per >> acquisire informazioni ? >> > > No. > > Attraverso l'uso appropriato degli header HTTP (cache control etc), > qualsiasi JavaScript può sostituire se stesso sul disco rimuovendo le > tracce di un attacco. > Se il server (o la CDN) può identificare l'obbiettivo (non solo privati > cittadini, pensa ad un ospedale con un IP fisso, o ad un comune o un > ufficio di polizia, o un'azienda) può servire SOLO all'obbiettivo, SOLO una > volta, JavaScript malevolo e poi rimuoverlo alla fine dell'attacco. > Attraverso quel JavaScript può sfruttare diverse risorse della vittima > (cut&paste dal report) > > - their IP > - their bandwith > - their computing power > - their RAM > - their disk (through browser cache) > - potentially others resources (gained through access to system vulnerabilities, think about Spectre/Meltdown) > > e questo permette tutte una enorme varietà di attacchi la cui > realizzazione è veramente banale. > > In questi due exploit (il mio e quello di rain1) usiamo JavaScript ed un > banalissimo DNS rebinding per penetrare la rete privata della vittima. > > Ma sono solo due degli attacchi possibili: davvero qualunque sviluppatore > web con un minimo di competenza e fantasia ne può pensare a bizzeffe. > E qualunque sito web (o CDN! chi controlla le CDN?) può veicolarli, anche > all'insaputa del creatore del sito stesso: basta controllare l'hosting (il > Cloud! chi controlla il Cloud?) > > E tutto questo vale ancora di più per WebAssembly: nemmeno con un proxy > che logga l'intero contenuto delle comunicazioni HTTP e HTTPS sarebbe > possibile osservare l'attacco (mentre con JS sarebbe possibile, avedo un > paio di persone che analizzano i log quotidianamente). > > > ogni cosa fatta su un computer da remoto consente di acquisire >> informazioni, dalla latenza di un collegamento al fatto che il computer a >> cui si collega risponda o meno. (che e' l'esempio sotto) >> > > Scusa, ma allora perché installiamo antivirus, firewall, certificati SSL > etc? > Se tanto non serve a niente! Risparmiamo soldi, tempo e preziosa energia, > non credi? > > > e se uno non vuole consentirlo ? >> su firefox basta usare plugin come noscript e/o umatrix >> > > No, contro questi attacchi questi plugin non possono nulla. > > Una volta che hai autorizzato un certo dominio, sei vulnerabile, perché il > server (o la CDN) può cambiare il codice DOPO aver ottenuto il tuo permesso > di esecuzione sulla tua macchina. > > > >> tra l'altro consiglio di farlo a tutti e collegarsi poi ad una pagina di >> youtube (ad esempio) >> > > Io ad oggi consiglio di usare due browser: > - un Firefox con JavaScript disabilitato da usare su tutti i siti che > funzionano > - un Chrome per tutti quelli che proprio non funzionano senza JS (e non si > può evitare di usare). > > Ma il suggerimento di installare NoScript o UMatrix (o di utilizzare due > browser) è intrinsecamente fallace. > > > La OPT-IN SECURITY non funziona: basta un dipendente distratto per entrare > nella rete di una banca con questi attacchi. > > Abilitare l'esecuzione di JavaScript sito per sito, invece, è > perfettamente usabile. Come lo è per le notifiche push di HTTP/2! > E come lo era per Flash o per le Applet Java. > > > Ai miei occhi, tutto questo indignarsi per una soluzione semplice e ovvia > come rendere JavaScript opt-in (e più sicuro) è prova di straordinaria > disonestà intellettuale da parte di sviluppatori, come quelli di Mozilla, > che si declamano campioni della privacy! > > > > Giacomo > > > > >> >> ciao, s. >> >> >> >> On 13/09/2018 10:29, Marco Ciurcina wrote: >> >>> "I'm not bad. I'm just drawn that way." >>> (Jessica Rabbit in Who Censored Roger Rabbit?) >>> >>> Per fortuna Firefox è software libero: c'è la speranza che qualche >>> sviluppatore faccia un fork. >>> >>> m.c. >>> >>> >>> In data giovedì 13 settembre 2018 00:13:03 CEST, Giacomo Tesio ha >>> scritto: >>> >>>> Salve, e' stato pubblicato un nuovo exploit del bug che ho recentemente >>>> segnalato a Mozilla e Google. >>>> >>>> Basically any old webpage can perform local network host discovery on >>>> you. >>>> >>>> To implement this I made a webpage which attempts to load images from >>>>> addresses 192.168.1.x. If you watch in the browser console it’ll show >>>>> either net::ERR_CONNECTION_REFUSED for a host that’s up or >>>>> net::ERR_ADDRESS_UNREACHABLE for a host that doesn’t exist. This is a >>>>> CORS >>>>> error which the javascript on the webpage is not allowed to >>>>> differentiate >>>>> by catching. But one error takes 3 ms to happen and the other takes 3 >>>>> seconds! >>>>> [...] >>>>> A related thing a webpage in your browser might do is connect to >>>>> localhost >>>>> and control any unauthenticated local services. Taviso used this to >>>>> great >>>>> effect here https://github.com/spesmilo/electrum/issues/3374 >>>>> >>>> >>>> https://rain-1.github.io/in-browser-localhostdiscovery >>>> >>>> E con questo siamo a 2 exploit che vanificano firewall e proxy >>>> aziendali. >>>> E io ne ho descritti altri nel bug report! >>>> >>>> E Mozilla tace. Io sono allibito. >>>> >>>> Ricordate "this is the Web functioning as desinged"! >>>> >>>> >>>> Giacomo >>>> >>> >>> >>> _______________________________________________ >>> nexa mailing list >>> nexa(a)server-nexa.polito.it >>> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >>> >>> _______________________________________________ >> nexa mailing list >> nexa(a)server-nexa.polito.it >> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >> > >

Sept. 13, 2018

Re: [nexa] Come bypassare firewall e proxy aziendali (e di PA, banche.. etc)

by Giacomo Tesio

Il giorno 13 settembre 2018 10:56, Stefano Quintarelli < stefano(a)quintarelli.it> ha scritto: > cosa dovrebbe consentire javascript ? > Come ho scritto nel bug report, JavaScript dovrebbe (e potrebbe) essere reso molto più sicuro attraverso piccole modifiche. In sintesi <https://medium.com/@giacomo_59737/i-compiled-a-detailed-bug-report-for-mozi…> : > Anyway, to answer your question, the solution is simple, if it’s not easy. > *The execution of Web software should be opt-in, not opt-out * > (if you can opt-out, given how usable are the UI to disable JavaScript > <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c9>). > > Now, given the *severity of the issue*, as a first step I would release > an *emergency fix that disable JavaScript* (and Meta Refresh) without > looking at the user settings. > > Then I would deploy a mid term fix so that: > > - Page Refresh though META tag and JavaScript are disabled by default > - Both can be enabled on a per website basis, but > — No script or CSS is requested with Cookies or other HTTP headers > — Each script and CSS is requested through a dedicated TCP connection > <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c12> > — SubResource Integrity <https://www.w3.org/TR/SRI/> 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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c13> > (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” > <https://www.blog.google/products/chrome/milestone-chrome-security-marking-h…> > web pages visited for the first time that require JavaScript. > > (scusa il cut&paste, ma sono un po' di corsa) Il giorno 13 settembre 2018 10:56, Stefano Quintarelli < stefano(a)quintarelli.it> ha scritto: > puo' collegarsi a computer diversi da quello dell'utente ? certamente, per > comunicare con il server da cui proviene. > > può scaricare oggetti, diciamo immagini, da un computer con un determinato > indirizzo ? beh, tutte le pagine web sono composte cosi'. (a partire dalla > webmail) > > una alternativa potrebbe essere che consenta di comunicare solo con il > computer che lo ha servito. Speedtest, per esempio, non funzionerebbe. > (forse nemmeno neubot, e nemmeno quasi tutto il mercato pubblictario). > > queste due cose che consente, possono essere usate da qualcuno per > acquisire informazioni ? > No. Attraverso l'uso appropriato degli header HTTP (cache control etc), qualsiasi JavaScript può sostituire se stesso sul disco rimuovendo le tracce di un attacco. Se il server (o la CDN) può identificare l'obbiettivo (non solo privati cittadini, pensa ad un ospedale con un IP fisso, o ad un comune o un ufficio di polizia, o un'azienda) può servire SOLO all'obbiettivo, SOLO una volta, JavaScript malevolo e poi rimuoverlo alla fine dell'attacco. Attraverso quel JavaScript può sfruttare diverse risorse della vittima (cut&paste dal report) - their IP - their bandwith - their computing power - their RAM - their disk (through browser cache) - potentially others resources (gained through access to system vulnerabilities, think about Spectre/Meltdown) e questo permette tutte una enorme varietà di attacchi la cui realizzazione è veramente banale. In questi due exploit (il mio e quello di rain1) usiamo JavaScript ed un banalissimo DNS rebinding per penetrare la rete privata della vittima. Ma sono solo due degli attacchi possibili: davvero qualunque sviluppatore web con un minimo di competenza e fantasia ne può pensare a bizzeffe. E qualunque sito web (o CDN! chi controlla le CDN?) può veicolarli, anche all'insaputa del creatore del sito stesso: basta controllare l'hosting (il Cloud! chi controlla il Cloud?) E tutto questo vale ancora di più per WebAssembly: nemmeno con un proxy che logga l'intero contenuto delle comunicazioni HTTP e HTTPS sarebbe possibile osservare l'attacco (mentre con JS sarebbe possibile, avedo un paio di persone che analizzano i log quotidianamente). ogni cosa fatta su un computer da remoto consente di acquisire > informazioni, dalla latenza di un collegamento al fatto che il computer a > cui si collega risponda o meno. (che e' l'esempio sotto) > Scusa, ma allora perché installiamo antivirus, firewall, certificati SSL etc? Se tanto non serve a niente! Risparmiamo soldi, tempo e preziosa energia, non credi? e se uno non vuole consentirlo ? > su firefox basta usare plugin come noscript e/o umatrix > No, contro questi attacchi questi plugin non possono nulla. Una volta che hai autorizzato un certo dominio, sei vulnerabile, perché il server (o la CDN) può cambiare il codice DOPO aver ottenuto il tuo permesso di esecuzione sulla tua macchina. > tra l'altro consiglio di farlo a tutti e collegarsi poi ad una pagina di > youtube (ad esempio) > Io ad oggi consiglio di usare due browser: - un Firefox con JavaScript disabilitato da usare su tutti i siti che funzionano - un Chrome per tutti quelli che proprio non funzionano senza JS (e non si può evitare di usare). Ma il suggerimento di installare NoScript o UMatrix (o di utilizzare due browser) è intrinsecamente fallace. La OPT-IN SECURITY non funziona: basta un dipendente distratto per entrare nella rete di una banca con questi attacchi. Abilitare l'esecuzione di JavaScript sito per sito, invece, è perfettamente usabile. Come lo è per le notifiche push di HTTP/2! E come lo era per Flash o per le Applet Java. Ai miei occhi, tutto questo indignarsi per una soluzione semplice e ovvia come rendere JavaScript opt-in (e più sicuro) è prova di straordinaria disonestà intellettuale da parte di sviluppatori, come quelli di Mozilla, che si declamano campioni della privacy! Giacomo > > ciao, s. > > > > On 13/09/2018 10:29, Marco Ciurcina wrote: > >> "I'm not bad. I'm just drawn that way." >> (Jessica Rabbit in Who Censored Roger Rabbit?) >> >> Per fortuna Firefox è software libero: c'è la speranza che qualche >> sviluppatore faccia un fork. >> >> m.c. >> >> >> In data giovedì 13 settembre 2018 00:13:03 CEST, Giacomo Tesio ha scritto: >> >>> Salve, e' stato pubblicato un nuovo exploit del bug che ho recentemente >>> segnalato a Mozilla e Google. >>> >>> Basically any old webpage can perform local network host discovery on >>> you. >>> >>> To implement this I made a webpage which attempts to load images from >>>> addresses 192.168.1.x. If you watch in the browser console it’ll show >>>> either net::ERR_CONNECTION_REFUSED for a host that’s up or >>>> net::ERR_ADDRESS_UNREACHABLE for a host that doesn’t exist. This is a >>>> CORS >>>> error which the javascript on the webpage is not allowed to >>>> differentiate >>>> by catching. But one error takes 3 ms to happen and the other takes 3 >>>> seconds! >>>> [...] >>>> A related thing a webpage in your browser might do is connect to >>>> localhost >>>> and control any unauthenticated local services. Taviso used this to >>>> great >>>> effect here https://github.com/spesmilo/electrum/issues/3374 >>>> >>> >>> https://rain-1.github.io/in-browser-localhostdiscovery >>> >>> E con questo siamo a 2 exploit che vanificano firewall e proxy aziendali. >>> E io ne ho descritti altri nel bug report! >>> >>> E Mozilla tace. Io sono allibito. >>> >>> Ricordate "this is the Web functioning as desinged"! >>> >>> >>> Giacomo >>> >> >> >> _______________________________________________ >> nexa mailing list >> nexa(a)server-nexa.polito.it >> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >> >> _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >

Sept. 13, 2018

Caso Snowden, la decisione della Corte Europea dei Diritti dell'Uomo

by Guido Noto La Diega

In allegato la decisione della ECtHR nel caso Snowden o Big Brother Watch v UK. A sorpresa, si fa per dire, il Regno Unito ha violato il diritto alla privacy nelle sue attività di spionaggio

Sept. 13, 2018