October 2023 - nexa - server-nexa.polito.it

Re: [nexa] Un caso di "intercettazione telematica", in Europa (Hetzner, Germania) [CDT:L0]

by 380°

Buongiorno Mario, Mario Sabatino <mario(a)liste.cloud> writes: > Non sono un informatico ma un po' di esperienza pratica su XMPP me la > sono fatta, usando un server familiare da me installato e gestito da > quasi due anni complimenti... sei informatico quanto basta :-D > (tutti possono farlo, fatelo anche voi, ne vale la pena). bello l'invito! [...] > Infatti su XMPP - da quando lo uso - vanno in chiaro solo le > conversazioni nei MUC (multi user chat/ stanze) pubblici che essendo > tali, per definizione, rendono la cifratura semplicemente uno spreco di > risorse computazionali. Hai fatto benissimo a evidenziare la e2e encryption (l'autore dell'articolo evidenzia questa cosa, l'ho riportata per completezza, vedi sotto la citazione del mio messaggio). Aggiungo che spesso ci può essere bisogno di riservatezza anche nelle MUC: non uso XMPP da un sacco, non ricordo se è possibile avere MUC e2e con OMEMO... ma questo è un dettaglio. Inoltre, non è quello che è successo in questo attacco MiTM TLS, in caso di compromissione del server è possibile montare un attacco MiTM anche se viene usata la e2e encryption (OMEMO o il vecchio OTR) [1] (chiamiamolo MiTM OMEMO), il c.d. "threat model" è descritto bene qui nel link [2]. Molti utenti pensano che sia sufficiente utilizzare uno strumento senza voler nemmeno sapere di striscio come funziona - tipo "uso Signal e sono in una botte di ferro" - mentre: --8<---------------cut here---------------start------------->8--- The only protection against (e2e, n.d.r.) man-in-the-middle attacks is to verify the fingerprints out of band over a secure channel that the hypothetical attacker does not control. Think phone call, a personal website or even better meeting each other in person. --8<---------------cut here---------------end--------------->8--- (da [1]) Dico questo per ricordare, ancora una volta, che a un "attore" con sufficienti risorse e con adeguati poteri di persuasione /quasi/ nulla è impossibile quando *il server* è _fisicamente accessibile_ (non parliamo nemmeno dei server virtuali, che sono /virtualmente/ accessibili :-D), a /quasi/ ogni livello dello stack di rete ISO/OSI. Lo dico in altri termini: Internet è un ambiente *altamente* compromesso. Punto. [...] > Ecco che, fatta questa per molti di voi inutile premessa, la minaccia > rappresentata dall'attacco a jabber.ru appare ai miei occhi molto > limitata. Relativamente limitata, perché sebbene gli attaccanti non abbiano potuto leggere i messaggi crittografati 2e2, hanno potuto: [...] >> [...] the attacker have been able to execute any action as if it is >> executed from the authorized account, without knowing the account >> password. This means that the attacker could download account's >> roster, lifetime unencrypted server-side message history, send new >> messages or alter them in real time. anche solo il roster sono un sacco di metadati >> End-to-end encrypted communications, such as OMEMO, OTR or PGP, are >> protected from the interception only if both parties have validated >> the encryption keys. The users are asked to check their accounts for >> new unauthorized OMEMO and PGP keys in their PEP storage, and change >> passwords. Ricordo ancora che in una situazione nella quale 2 (o più) partecipanti che usano e2e senza (saper) verificare la loro "fingerprint" *out of band*, anche con un "semplice" MiTM TLS è possibile impersonare chiunque, da parte dell'attaccante, in particolare con un minimo di social engineering. [...] Saluti, 380° [1] https://web.archive.org/web/20231025060130/https://crypto.stackexchange.com… [2] https://web.archive.org/web/20231025060825/https://crypto.stackexchange.com… -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.

Oct. 25, 2023

Re: [nexa] Gramellini ha dimenticato un "solo"

by Massimo Maggiore

Purtroppo devo dissentire La carica simbolica negativa di questa nomina di Amato (peraltro mi chiedo se sia un tuttologo) è devastante. Peraltro l'alternativa non sarebbe stata tra un ragazzino e un 85enne Diciamo che non avere alternative in Italia - senza concedere non ve ne siano - sarebbe avvilente come minimo Inviato dal mio Galaxy -------- Messaggio originale -------- Da: Marco Fioretti <mfioretti(a)nexaima.net> Data: 25/10/23 07:36 (GMT+01:00) A: Nexa <nexa(a)server-nexa.polito.it> Oggetto: [nexa] Gramellini ha dimenticato un "solo" visti i danni causati PROPRIO dall'aver abbandonato certi sviluppi interamente in mano a ragazzini (relativamente, chiaro) ignoranti di tutto tranne che di coding, lo aggiungo io in maiuscolo: "La rivoluzione digitale non può essere pienamente compresa né tantomeno disciplinata SOLO da chi è cresciuto con i telefoni a disco rotante e spesso ha problemi anche soltanto con le app (il riferimento è dolorosamente autobiografico)." Post completo qui: https://www.corriere.it/caffe-gramellini/23_ottobre_25/digital-amato-1b867e… Marco

Oct. 25, 2023

Gramellini ha dimenticato un "solo"

by Marco Fioretti

visti i danni causati PROPRIO dall'aver abbandonato certi sviluppi interamente in mano a ragazzini (relativamente, chiaro) ignoranti di tutto tranne che di coding, lo aggiungo io in maiuscolo: "La rivoluzione digitale non può essere pienamente compresa né tantomeno disciplinata SOLO da chi è cresciuto con i telefoni a disco rotante e spesso ha problemi anche soltanto con le app (il riferimento è dolorosamente autobiografico)." Post completo qui: https://www.corriere.it/caffe-gramellini/23_ottobre_25/digital-amato-1b867e… (https://www.corriere.it/caffe-gramellini/23_ottobre_25/digital-amato-1b867e…) Marco

Oct. 25, 2023

Managing AI Risks in an Era of Rapid Progress

by don Luca Peyron

Documento interessante, buona lettura dl https://managing-ai-risks.com/ _________________________ don Luca Peyron Pastorale Universitaria - Apostolato Digitale Arcidiocesi di Torino www.universitari.to.it via XX settembre 83, Torino tel. 011 5156239

Oct. 24, 2023

Re: [nexa] Un caso di "intercettazione telematica", in Europa (Hetzner, Germania) [CDT:L0]

by Mario Sabatino

Non sono un informatico ma un po' di esperienza pratica su XMPP me la sono fatta, usando un server familiare da me installato e gestito da quasi due anni (tutti possono farlo, fatelo anche voi, ne vale la pena). Osservo un dato che viene sino ad ora trascurato nelle discussioni, ovvero che in XMPP - non proprio da oggi - tutte le chat possono essere cifrate con e2ee usando OMEMO oppure PGP (meglio la prima perchè con PGP abbiamo sempre incontrato parecchi problemi nello scambio delle chiavi). Quindi solo le comunicazioni in chiaro (eccezione alla regola) sarebbero esposte alla minaccia di un eventuale attacco. Infatti su XMPP - da quando lo uso - vanno in chiaro solo le conversazioni nei MUC (multi user chat/ stanze) pubblici che essendo tali, per definizione, rendono la cifratura semplicemente uno spreco di risorse computazionali. Su XMPP normalmente fai una chat a due in chiaro se usi dispositivi e versioni di software non aggiornati, se qualcosa non funziona nello scambio delle chiavi (quindi incidenti di percorso) oppure se hai deciso di farlo. La cifratura e2e è proprio automatica; nella maggior parte dei casi per uscire non cifrato dal tuo dispositivo devi fare un vero e proprio opt out (esattamente il contrario di quello che avviene ad es. su Telegram). :-) Ecco che, fatta questa per molti di voi inutile premessa, la minaccia rappresentata dall'attacco a jabber.ru appare ai miei occhi molto limitata. Mi sembra anche a questo punto lecito pensare che tanta scienza impiegata per eseguire l'attacco sia quasi un altro spreco di risorse, a meno che gli obiettivi non fossero altri (e con le mie scarse conoscenze non so neanche immaginare quali). Buona sera a tutte e tutti Mario Sabatino Il giorno mar, 24/10/2023 alle 18.12 +0200, 380° ha scritto: > Buongiorno Damiano, > > grazie mille per la segnalazione! > > Giusto per ribadire per l'ennesima volta il concetto: tutto questo > non è > affatto nuovo e tantomeno "strano"; Internet è così: fa schifo, > compreso TLS. > > Giusto per ribadire che avere un server in hosting in un datacentre è > sicuro *al massimo* così, come descritto nell'articolo... e non > comincio > neanche di striscio a raccontare cosa è possibile fare avendo accesso > _fisico_ a una macchina. > > Se pensate che io esageri, è solo perché non avete analizzato > abbastanza > lo stato delle cose :-(. > > Trattandosi questa di una mailing list di studio di Internet, *nulla* > di > quello che è accaduto nell'attacco MiTM in oggetto può essere > _percepito_ come troppo tecnico :-) > > Un attacco MiTM è descritto qui > https://it.wikipedia.org/wiki/Attacco_man_in_the_middle > > --8<---------------cut here---------------start------------->8--- > > un attacco informatico in cui qualcuno segretamente ritrasmette o > altera > la comunicazione tra due parti che credono di comunicare > direttamente > tra di loro > > --8<---------------cut here---------------end--------------->8--- > > e deve essere chiaro che viene usato molto, ma molto più spesso di > quanto gli stessi "addetti ai lavori" riescano a immaginare nei loro > peggiori incubi, su *tutto* lo spettro del layer di rete ISO/OSI. > > Leggenda vuole che la Germania, nella desolazione europea, fosse tra > le > nazioni più "garantiste" da questo punto di vista... ma viviamo in > tempi... > > Forse si salverà solo la neutrale Svizzera?!? > > Damiano Verzulli <damiano(a)verzulli.it> writes: > > [...] > > Per la cronaca, l'articolo dice che i provider sono Hetzner e Linode > e > che l'attacco è stato eseguito in datacentre tedeschi. Precisamente, > le > macchine sotto attacco sono state: 1 server dedicato Hetzner, 2 VPS > Linode. > > > e poi "aggiungere" un livello di gestione lato TLS (ossia, > > mettendosi > > in mezzo fra i client sparsi su Internet, ed il server che era li > > in > > casa) facendo in modo che entrambi (client e server) parlassero > > TLS, > > senza rendersi conto che lui, pero', era nel mezzo (a guardare e > > potenzialmente alterare il relativo traffico). > > Per espandere un pochino: da quello che emerge NON si è trattato di > una > intrusione nelle 3 macchine in oggetto ma "solo" di un attacco MiTM > che, > grazie al "magheggiamento" con le connessioni di rete e coi > certificati > X.505, ha consentito di intercettare **in chiaro** connessioni > crittografate via TLS tra i client (il software usato dagli utenti > per > comunicare) e il server di chat XMPP (aka Jabber) > > [...] > > > Che io sappia, è la prima volta che vedo "documentato" uno schema > > del > > genere. > > Forse non un caso così specifico (attacco MiTM a un server XMPP), ma > ormai ci sono innumerevoli casi documentati (mi si perdoni > l'approssimazione, non ho dati sotto mano). > > Possiamo soprassedere sui "magheggiamenti" lato rete (cioè "rubare" > la > connessione internet ad un'altra macchina) perché sono sì molto > tecnici > ma davvero molto, ma molto banali: progettarli e metetrli in pratica > per > un tecnico di rete è davvero di una banalità disarmante. > > Ciò su cui non *dobbiamo* soprassedere è l'insicurezza > dell'infrastruttura dei "certificati TLS/SSL", detta PKI (Public Key > Infrastructure), documentata ormai da almeno 23 anni: > https://en.wikipedia.org/wiki/X.509#Security > > Tipo l'affare DigiNotar del 2011 > (https://en.wikipedia.org/wiki/DigiNotar) > > ...e anche questo dipende sostanzialmente dal fatto che la X.509 PKI > è > stata progettata coi piedi, come spiega brillantemente Peter Gutmann > (University of Auckland) > > https://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf > «Everything you Never Wanted to Know about PKI but were Forced to > Find > Out» > > --8<---------------cut here---------------start------------->8--- > > To understand the X.509 PKI, it’s necessary to understand the history > behind it > > Why does X.509 do otherwise straightforward things in such a weird > way? > > [The] standards have been written by little green monsters from outer > space in order to confuse normal human beings and prepare them for > the > big invasion — comp.std.internat > > • Someone tried to explain public-key-based authentication to > aliens. Their universal translators were broken and they had to > gesture > a lot > > • They were created by the e-commerce division of the Ministry of > Silly > Walks > > --8<---------------cut here---------------end--------------->8--- > > > I dettagli, sono qui: > > > > https://notes.valdikss.org.ru/jabber.ru-mitm/ > > --8<---------------cut here---------------start------------->8--- > > The attacker has issued several new TLS certificates using Let’s > Encrypt > service which were used to hijack encrypted STARTTLS connections on > port > 5222 using transparent MiTM proxy. The attack was discovered due to > expiration of one of the MiTM certificates, which haven’t been > reissued. > There are no indications of the server breach or spoofing attacks on > the > network segment, quite the contrary: the traffic redirection has been > configured on the hosting provider network. The wiretapping may have > lasted for up to 6 months overall (90 days confirmed). We believe > this > is lawful interception Hetzner and Linode were forced to setup. > > [...] But nothing stood out. We noticed the only uncommon record in > the > kernel log on Hetzner dedicated machine, it lost the physical network > link for 19 seconds on 18 July 2023: > > [Tue Jul 18 12:58:29 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC > Link is Down > [Tue Jul 18 12:58:48 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC > Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX > > [...] In other words, the encrypted connection interception of the > same > kind happens both on Hetzner dedicated and Linode VPS machines. > > [...] It became clear that the affected Linode VM have uncommon > network > setup compared to regular Linode instances, possibly have been > isolated > into separate VLAN. > > [...] After checking crt.sh certificate transparency database, rogue > certificates have been discovered which were not issued by any of > jabber.ru servers. > > There are two genuine certificates used in XMPP service: the one > issued > for xmpp.ru, *.xmpp.ru and the other one is for jabber.ru, > *.jabber.ru. > > [...] 18 July 2023 issuing time is about the same when Hetzner server > has lost network link for several seconds. > > [...] Summary and finale > > * The attacker managed to issue multiple SSL/TLS certificates via > Let’s > Encrypt for jabber.ru and xmpp.ru domains since 18 Apr 2023 > > * The Man-in-the-Middle attack for jabber.ru/xmpp.ru client XMPP > traffic > decryption confirmed to be in place since at least 21 July 2023 for > up > to 19 Oct 2023, possibly (not confirmed) since 18 Apr 2023, affected > 100% of the connections to XMPP STARTTLS port 5222 (not 5223) > > * The attacker failed to reissue TLS certificate and MiTM proxy > started > to serve expired certificate on port 5222 for jabber.ru domain > (Hetzner) > > * The MiTM attack stopped shortly after we begun our investigation > and > network tests on 18 Oct 2023, along with tickets to Hetzner and > Linode > support team, however passive wiretapping (additional routing hop) > is > still in place at least on a single Linode server > > * Neither servers appear to be hacked > > * Both Hetzner and Linode network appear to be reconfigured > specifically > for this kind of attack for the XMPP service IP addresses > > [...] the attacker have been able to execute any action as if it is > executed from the authorized account, without knowing the account > password. This means that the attacker could download account's > roster, > lifetime unencrypted server-side message history, send new messages > or > alter them in real time. > > End-to-end encrypted communications, such as OMEMO, OTR or PGP, are > protected from the interception only if both parties have validated > the > encryption keys. The users are asked to check their accounts for new > unauthorized OMEMO and PGP keys in their PEP storage, and change > passwords. > > We tend to assume this is lawful interception Hetzner and Linode were > forced to setup based on German police request. Another possible, > although much more unlikely scenario is an intrusion on the internal > networks of both Hetzner and Linode targeting specifically jabber.ru > — > much harder to believe but not entirely impossible. > > As of 20 Oct 2023, we’re still waiting for the adequate reply from > Hetzner and Linode to our inquiries. > > > --8<---------------cut here---------------end--------------->8--- > > > Ne è nato un piccolo thread (ancora piu' tecnico) sulla community > > ITNOG > > [1] dove provavo a riflettere su come "detectare" tali situazioni > > e, ove > > necessario, "impedirle". > > Ogni attacco MiTM ha le sue tecniche di individuazione e mitigazione, > l'articolo ne elenca alcuni speficifi per i certificati, altri per > XMPP > (paragrafo «Could you prevent or monitor this kind of attack?») > > Ovviamente c'è anche un thread su Hacker News: > https://news.ycombinator.com/item?id=37961166 > > [...] > > > [1] https://t.me/IT_NOG/99331/115800 > > [...] > > Saluti, 380° > > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Oct. 24, 2023

Re: [nexa] Un caso di "intercettazione telematica", in Europa (Hetzner, Germania) [CDT:L0]

by Stefano Quintarelli

On 24/10/23 18:12, 380° wrote: > We tend to assume this is lawful interception Hetzner and Linode were > forced to setup based on German police request. Another possible, > although much more unlikely scenario is an intrusion on the internal > networks of both Hetzner and Linode targeting specifically jabber.ru — > much harder to believe but not entirely impossible. > > As of 20 Oct 2023, we’re still waiting for the adequate reply from > Hetzner and Linode to our inquiries. questo e' un punto importante. devono dare risposte ASAP rischiano l'abbandono di clienti. (io per primo) ciao, s.

Oct. 24, 2023

Re: [nexa] Un caso di "intercettazione telematica", in Europa (Hetzner, Germania) [CDT:L0]

by 380°

Buongiorno Damiano, grazie mille per la segnalazione! Giusto per ribadire per l'ennesima volta il concetto: tutto questo non è affatto nuovo e tantomeno "strano"; Internet è così: fa schifo, compreso TLS. Giusto per ribadire che avere un server in hosting in un datacentre è sicuro *al massimo* così, come descritto nell'articolo... e non comincio neanche di striscio a raccontare cosa è possibile fare avendo accesso _fisico_ a una macchina. Se pensate che io esageri, è solo perché non avete analizzato abbastanza lo stato delle cose :-(. Trattandosi questa di una mailing list di studio di Internet, *nulla* di quello che è accaduto nell'attacco MiTM in oggetto può essere _percepito_ come troppo tecnico :-) Un attacco MiTM è descritto qui https://it.wikipedia.org/wiki/Attacco_man_in_the_middle --8<---------------cut here---------------start------------->8--- un attacco informatico in cui qualcuno segretamente ritrasmette o altera la comunicazione tra due parti che credono di comunicare direttamente tra di loro --8<---------------cut here---------------end--------------->8--- e deve essere chiaro che viene usato molto, ma molto più spesso di quanto gli stessi "addetti ai lavori" riescano a immaginare nei loro peggiori incubi, su *tutto* lo spettro del layer di rete ISO/OSI. Leggenda vuole che la Germania, nella desolazione europea, fosse tra le nazioni più "garantiste" da questo punto di vista... ma viviamo in tempi... Forse si salverà solo la neutrale Svizzera?!? Damiano Verzulli <damiano(a)verzulli.it> writes: [...] Per la cronaca, l'articolo dice che i provider sono Hetzner e Linode e che l'attacco è stato eseguito in datacentre tedeschi. Precisamente, le macchine sotto attacco sono state: 1 server dedicato Hetzner, 2 VPS Linode. > e poi "aggiungere" un livello di gestione lato TLS (ossia, mettendosi > in mezzo fra i client sparsi su Internet, ed il server che era li in > casa) facendo in modo che entrambi (client e server) parlassero TLS, > senza rendersi conto che lui, pero', era nel mezzo (a guardare e > potenzialmente alterare il relativo traffico). Per espandere un pochino: da quello che emerge NON si è trattato di una intrusione nelle 3 macchine in oggetto ma "solo" di un attacco MiTM che, grazie al "magheggiamento" con le connessioni di rete e coi certificati X.505, ha consentito di intercettare **in chiaro** connessioni crittografate via TLS tra i client (il software usato dagli utenti per comunicare) e il server di chat XMPP (aka Jabber) [...] > Che io sappia, è la prima volta che vedo "documentato" uno schema del > genere. Forse non un caso così specifico (attacco MiTM a un server XMPP), ma ormai ci sono innumerevoli casi documentati (mi si perdoni l'approssimazione, non ho dati sotto mano). Possiamo soprassedere sui "magheggiamenti" lato rete (cioè "rubare" la connessione internet ad un'altra macchina) perché sono sì molto tecnici ma davvero molto, ma molto banali: progettarli e metetrli in pratica per un tecnico di rete è davvero di una banalità disarmante. Ciò su cui non *dobbiamo* soprassedere è l'insicurezza dell'infrastruttura dei "certificati TLS/SSL", detta PKI (Public Key Infrastructure), documentata ormai da almeno 23 anni: https://en.wikipedia.org/wiki/X.509#Security Tipo l'affare DigiNotar del 2011 (https://en.wikipedia.org/wiki/DigiNotar) ...e anche questo dipende sostanzialmente dal fatto che la X.509 PKI è stata progettata coi piedi, come spiega brillantemente Peter Gutmann (University of Auckland) https://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf «Everything you Never Wanted to Know about PKI but were Forced to Find Out» --8<---------------cut here---------------start------------->8--- To understand the X.509 PKI, it’s necessary to understand the history behind it Why does X.509 do otherwise straightforward things in such a weird way? [The] standards have been written by little green monsters from outer space in order to confuse normal human beings and prepare them for the big invasion — comp.std.internat • Someone tried to explain public-key-based authentication to aliens. Their universal translators were broken and they had to gesture a lot • They were created by the e-commerce division of the Ministry of Silly Walks --8<---------------cut here---------------end--------------->8--- > I dettagli, sono qui: > > https://notes.valdikss.org.ru/jabber.ru-mitm/ --8<---------------cut here---------------start------------->8--- The attacker has issued several new TLS certificates using Let’s Encrypt service which were used to hijack encrypted STARTTLS connections on port 5222 using transparent MiTM proxy. The attack was discovered due to expiration of one of the MiTM certificates, which haven’t been reissued. There are no indications of the server breach or spoofing attacks on the network segment, quite the contrary: the traffic redirection has been configured on the hosting provider network. The wiretapping may have lasted for up to 6 months overall (90 days confirmed). We believe this is lawful interception Hetzner and Linode were forced to setup. [...] But nothing stood out. We noticed the only uncommon record in the kernel log on Hetzner dedicated machine, it lost the physical network link for 19 seconds on 18 July 2023: [Tue Jul 18 12:58:29 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Down [Tue Jul 18 12:58:48 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX [...] In other words, the encrypted connection interception of the same kind happens both on Hetzner dedicated and Linode VPS machines. [...] It became clear that the affected Linode VM have uncommon network setup compared to regular Linode instances, possibly have been isolated into separate VLAN. [...] After checking crt.sh certificate transparency database, rogue certificates have been discovered which were not issued by any of jabber.ru servers. There are two genuine certificates used in XMPP service: the one issued for xmpp.ru, *.xmpp.ru and the other one is for jabber.ru, *.jabber.ru. [...] 18 July 2023 issuing time is about the same when Hetzner server has lost network link for several seconds. [...] Summary and finale * The attacker managed to issue multiple SSL/TLS certificates via Let’s Encrypt for jabber.ru and xmpp.ru domains since 18 Apr 2023 * The Man-in-the-Middle attack for jabber.ru/xmpp.ru client XMPP traffic decryption confirmed to be in place since at least 21 July 2023 for up to 19 Oct 2023, possibly (not confirmed) since 18 Apr 2023, affected 100% of the connections to XMPP STARTTLS port 5222 (not 5223) * The attacker failed to reissue TLS certificate and MiTM proxy started to serve expired certificate on port 5222 for jabber.ru domain (Hetzner) * The MiTM attack stopped shortly after we begun our investigation and network tests on 18 Oct 2023, along with tickets to Hetzner and Linode support team, however passive wiretapping (additional routing hop) is still in place at least on a single Linode server * Neither servers appear to be hacked * Both Hetzner and Linode network appear to be reconfigured specifically for this kind of attack for the XMPP service IP addresses [...] the attacker have been able to execute any action as if it is executed from the authorized account, without knowing the account password. This means that the attacker could download account's roster, lifetime unencrypted server-side message history, send new messages or alter them in real time. End-to-end encrypted communications, such as OMEMO, OTR or PGP, are protected from the interception only if both parties have validated the encryption keys. The users are asked to check their accounts for new unauthorized OMEMO and PGP keys in their PEP storage, and change passwords. We tend to assume this is lawful interception Hetzner and Linode were forced to setup based on German police request. Another possible, although much more unlikely scenario is an intrusion on the internal networks of both Hetzner and Linode targeting specifically jabber.ru — much harder to believe but not entirely impossible. As of 20 Oct 2023, we’re still waiting for the adequate reply from Hetzner and Linode to our inquiries. --8<---------------cut here---------------end--------------->8--- > Ne è nato un piccolo thread (ancora piu' tecnico) sulla community ITNOG > [1] dove provavo a riflettere su come "detectare" tali situazioni e, ove > necessario, "impedirle". Ogni attacco MiTM ha le sue tecniche di individuazione e mitigazione, l'articolo ne elenca alcuni speficifi per i certificati, altri per XMPP (paragrafo «Could you prevent or monitor this kind of attack?») Ovviamente c'è anche un thread su Hacker News: https://news.ycombinator.com/item?id=37961166 [...] > [1] https://t.me/IT_NOG/99331/115800 [...] Saluti, 380° -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.

Oct. 24, 2023

Un caso di "intercettazione telematica", in Europa (Hetzner, Germania)

by Damiano Verzulli

Segnalo un articolo un po' tecnico che descrive uno scenario nel quale il traffico XMPP (un protocollo utilizzato per servizi a-la "chat" sincrona), seppur protetto da crittografia (TLS), è stato oggetto di intercettazione, verosimilmente da parte delle autorita' tedesche. In particolare, il provider tedesco che offriva l'infrastruttura "cloud" con la quale veniva gestito il relativo "server" (parliamo di "jabber.ru" e di "xmpp.ru"), si è adoperato per "riorganizzare" il collegamento Internet del server in esame (isolandolo dal resto dell'infrastruttura e lasciandolo connesso, in disparte dal resto) e poi "aggiungere" un livello di gestione lato TLS (ossia, mettendosi in mezzo fra i client sparsi su Internet, ed il server che era li in casa) facendo in modo che entrambi (client e server) parlassero TLS, senza rendersi conto che lui, pero', era nel mezzo (a guardare e potenzialmente alterare il relativo traffico). E' interessante osservare che il tutto è emerso alla luce del sole, solo a causa di una "distrazione" di un qualche tecnico... che si è "dimenticato" di rinnovare un certificato TLS ( che quindi è scaduto, portanto i client a.. innervosirsi... e cosi' innescando l'analisi tecnica degli admin). Che io sappia, è la prima volta che vedo "documentato" uno schema del genere. I dettagli, sono qui: https://notes.valdikss.org.ru/jabber.ru-mitm/ Ne è nato un piccolo thread (ancora piu' tecnico) sulla community ITNOG [1] dove provavo a riflettere su come "detectare" tali situazioni e, ove necessario, "impedirle". Saluti, DV [1] https://t.me/IT_NOG/99331/115800 -- Damiano Verzulli e-mail: damiano(a)verzulli.it --- possible?ok:while(!possible){open_mindedness++} --- "...I realized that free software would not generate the kind of income that was needed. Maybe in USA or Europe, you may be able to get a well paying job as a free software developer, but not here [in Africa]..." -- Guido Sohne - 1973-2008 http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html

Oct. 24, 2023

Trasparenza dell’algoritmo, la Cassazione: sì al rating reputazionale, se in linea con la privacy

by don Luca Peyron

Buona lettura dl https://www.cybersecurity360.it/legal/privacy-dati-personali/trasparenza-de… _________________________ don Luca Peyron Pastorale Universitaria - Apostolato Digitale Arcidiocesi di Torino www.universitari.to.it via XX settembre 83, Torino tel. 011 5156239

Oct. 24, 2023

MEMENTO | 108° Nexa Lunch Seminar | 25 ottobre 2023, ore 13.00

by Valeria Bergantino

Gentilissime, gentilissimi, Vi ricordiamo che *mercoledì 25 ottobre*, dalle ore 13.00 alle ore 14.00, si terrà il *108° Nexa Lunch Seminar* con un incontro dal titolo: /*"Analisi e report di trasferimenti di dati personali verso domini extra-EEA"*/. Ospite dell'incontro: *Lorenzo Laudadio* (Politecnico di Torino). _L'incontro si terrà IN PRESENZA e ONLINE._ _SEDE FISICA_ dell'incontro: Centro Nexa su Internet e Società, Politecnico di Torino, Via Boggio 65/a, Torino (1° piano). Per accedere alla sala si raccomanda di suonare al citofono *Portineria* e di seguire le indicazioni lungo il percorso. QUI <https://nexa.polito.it/contatti> maggiori informazioni su come raggiungerci. _STANZA VIRTUALE _dell'incontro: https://didattica.polito.it/VClass/NexaEvent Per maggiori dettagli è possibile consultare la pagina web dell'evento: https://nexa.polito.it/lunch-108 Cordiali saluti, -- Valeria Bergantino Communication Officer Nexa Center for Internet & Society Politecnico di Torino - DAUIN Via Pier Carlo Boggio, 65/A - 10138 Torino web: https://nexa.polito.it/ mail: valeria.bergantino(a)polito.it <mailto:valeria.bergantino@polito.it> tel: 3473443585

Oct. 23, 2023