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 <dami...@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>.

Attachment: signature.asc
Description: PGP signature

_______________________________________________
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Reply via email to