Skip to main content

Fascinating and sophisticated MiTM ('man in the middle') at Hetzner (DE) and Linode, targeting Russia's largest XMPP/Jabber (civilian) chat service. The authors of the article make a reasonably compelling case that "this is lawful interception Hetzner and Linode were forced to setup."

https://notes.valdikss.org.ru/jabber.ru-mitm/

Excellent mitigation walkthrough here:

https://www.devever.net/~hl/xmpp-incident

Sure gets me thinking.

#infosec #sysadmin #forensics

Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service —

notes.valdikss.org.ru
#infosec #sysadmin #forensics
in reply to Julian Oliver

modulux
modulux
• •

Regarding the LB, someone was wondering whether the FBI could circumvent SSL connections, and we have an answer: German police can.

Unfortunately I can't find the post asking that question, otherwise I'd reply directly to it.

in reply to modulux

Julian Oliver
Julian Oliver
• •
@modulux Yes they can. CAA and DNSSEC the best mitigating options.
@modulux
in reply to Julian Oliver

old sysops
old sysops
• •
@modulux this is just moving the attack vector to a ca provider.
If you have a legal power to compel a hosting compagny, you have it for a ca one.
But yes, dnssec and caa are in the critical path.
@modulux
in reply to old sysops

Julian Oliver
Julian Oliver
• •
A lesson in here, nonetheless. As the datacenter owns the route, they can do the LE ACME challenge at the hop facing the customer server, for which DNS resolves, set up a proxy and transparently decrypt traffic, effectively hijacking each STARTTLS connection on initiation. It's like a datacenter implementation of Moxie's 'ssl stripping' back in the day, and so the CA itself doesn't need to be poisoned.
in reply to Julian Oliver

modulux
modulux
• •
In my opinion this calls for some mitigations. For example, sending an email to the account on record after a renewal. Other possibilities include keeping some kind of shared secret for renewals (as opposed to first issuance) using the email as recovery mechanism.
in reply to modulux

Julian Oliver
Julian Oliver
• •
I agree that LE could improve here, no reason a 2FA-alike mechanism can't be employed de facto, triggered when `certbot` is invoked. In the interests of avoiding mitigation redundancy this however would perhaps best be optional, as domains that have DNSSEC and CAA configured would not require it.
in reply to Julian Oliver

modulux
modulux
• •

I am not too familiar with CAA, but would this have helped in the first place? My understanding is CAA only says "such and such CA can authorise this domain." So if they were using LE before LE would be on the record and the attack would go through. Or am I missing something?

@oldsysops

@old sysops
in reply to modulux

Julian Oliver
Julian Oliver
• •

In fact yes it can help in the case of LE, as you can define a record like so:

yourdomain.org CAA 128 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/<le-account-number>

However if the attacker has prior-knowledge your LE account number, then you only have DNSSEC.

in reply to Julian Oliver

modulux
modulux
• •
Thanks, I think that's an extension of CAA from what I was reading at least. That's something for sure.
in reply to Julian Oliver

Refurio Anachro
Refurio Anachro
• •

If your hoster is attacking you, they can just pick your cert's private keys off your box and use that. Neither CAA nor DNSSec will help.

@JulianOliver @modulux @oldsysops

@old sysops @Julian Oliver @modulux
in reply to Refurio Anachro

modulux
modulux
• •
Harder to do without you noticing, no? At least if it's a dedi. if it's a VPS then yeah, you're screwed.
⇧