Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

devever.net

Post reply on HN
Print view View original

31–40 of 150 posts

Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

#31

Post by jeroenhd »

the8472 wrote: post #12
liquidk wrote: post #8

The provider has access to the host, they can just inspect the job from the outside and you won’t be able to tell

secure boot + virtualized memory encryption is supposed to prevent that, you'll have to trust intel/amd though.

Secure boot on a cloud machine is pretty useless, there's nothing stopping the hypervisor from injecting code into the running machine. Theoretically virtual machine memory is encrypted, but you'll just have to trust the hypervisor's word for it. You can try to verify the boot chain all the way to the hardware keys, but if the hypervisor just replaces your `JNE` with a `NOP` you'll have a hard time automating your protections.

I suppose you can transfer the keys out of the machine over the network (and hope the hypervisor doesn't replace the socket buffers just before transmission) and verify them off site, but guest machines will always be just that: guests on a host that has all the power.

Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

#32

Post by lallysingh »

the8472 wrote: post #12
liquidk wrote: post #8

The provider has access to the host, they can just inspect the job from the outside and you won’t be able to tell

secure boot + virtualized memory encryption is supposed to prevent that, you'll have to trust intel/amd though.

Those are best for compliance to security requirements/ standards. They're not for security against state level actors.

Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

#33

Post by skissane »

mjevans wrote: post #9
LeoPanthera wrote: post #6

Earlier quoted context omitted.

I would suggest that if you are the police, you can break into a datacenter with a flash of a badge. I can't imagine many would attempt to stop you.

I would hope they at least: * Require a copy of the badge number, and verify that this officer is assigned and expected to be at this business right now. * Require them to sign into and out of the site. * Annotate which systems / compromises are in place. - That all of the above MIGHT be sealed under a court order; I would hope any such order has an automatic 'sunset' date, and possibly renewal upon review by a diffe…

A business can request visiting law enforcement to do all those things, and hopefully law enforcement complies. However, if they refuse to comply, realistically you just have to let them in anyway. Document their non-compliance and provide it to your lawyers, who can decide what action to take (lodge a formal complaint to the law enforcement agency, apply to a judge for an injunction to compel their compliance, etc)

Well, that’s true in countries like Germany or the US. I suspect in somewhere like Russia or China, formal complaints are unlikely to achieve anything except invite government retaliation.

Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

#34

Post by jacquesm »

LeoPanthera wrote: post #4

The summary of the attack from https://notes.valdikss.org.ru/jabber.ru-mitm/ is very interesting: * 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…

> Both Hetzner and Linode network appear to be reconfigured specifically for this kind of attack for the XMPP service IP addresses

This suggests a compromise of Hetzner and Linode network management.

Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

#35

Post by [deleted] »

mike_d wrote: post #16

Great callout: > Don't use Cloudflare or similar services. See my article here for an explanation on why. If you use a service like this, you're basically already MitMing yourself. I wish more people would realize that when arguing on the internet about CAA, DNSSEC, NSA, etc. that none of it really matters. We willingly allow a government aligned entity to unwrap 20% of all TLS connections on the internet and peak in…

[deleted]

Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

#36

Post by jacquesm »

whalesalad wrote: post #3
abigail95 wrote: post #2

> What would a perfect attacker do? If you had physical access to the computer, some sort of bus interception to exfiltrate data from the machine.

extremely difficult to get physical access in a datacenter

All the people working in the datacenter have that level of physical access.

Unless they are very closely supervised they can do a lot of damage without anybody being the wiser until they get caught. I've been in (nominally very secure) DCs on behalf of customers and I've seen:

- unlocked racks

- doors open

- temporary network cables and keyboards, monitors and mice attached to running systems

- systems logged in left unattended

- floor panels raised up and left open unattended exposing cabling

- meet-me rooms with interfaces exposed (gear in racks without doors)

DC personnel tends to trust each other, and they probably shouldn't. But it's hard to be part of a closely knit crew for a long time without getting into a 'get stuff done' mode where protocol and rules are there in principle but less so in practice because it is seen as an efficiency penalty. It's another instance of the 'normalization of deviation' phenomenon.

Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

#37

Post by comex »

jeroenhd wrote: post #31
the8472 wrote: post #12

Earlier quoted context omitted.

secure boot + virtualized memory encryption is supposed to prevent that, you'll have to trust intel/amd though.

Secure boot on a cloud machine is pretty useless, there's nothing stopping the hypervisor from injecting code into the running machine. Theoretically virtual machine memory is encrypted, but you'll just have to trust the hypervisor's word for it. You can try to verify the boot chain all the way to the hardware keys, but if the hypervisor just replaces your `JNE` with a `NOP` you'll have a hard time automating your pr…

That is not the case for the latest CPU extensions for encrypted VMs, AMD SEV-SNP and Intel TDX, which are designed to allow remote attestation based on a key hidden in the CPU that the hypervisor does not get access to.

The hypervisor only ever sees the VM’s memory in encrypted form, and it’s integrity-checked by the CPU to prevent replay attacks.

Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

#38

Post by jacquesm »

LeoPanthera wrote: post #6
whalesalad wrote: post #3

Earlier quoted context omitted.

extremely difficult to get physical access in a datacenter

I would suggest that if you are the police, you can break into a datacenter with a flash of a badge. I can't imagine many would attempt to stop you.

I highly doubt it is that simple for LE to enter a DC without a warrant signed by a judge, but insiders have all of that access and plants in DCs can and do happen.

I was present when Dutch LE seized a bunch of servers on behalf of an FBI liaison officer in NL and everything went 'by the book', there is no way an LE officer without a signed order from a judge would have been granted access.

Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

#39

Post by simpaticoder »

LeoPanthera wrote: post #4

The summary of the attack from https://notes.valdikss.org.ru/jabber.ru-mitm/ is very interesting: * 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…

>The attacker managed to issue multiple SSL/TLS certificates via Let’s Encrypt

This implies that the attacker was able to validate domain ownership of jabber.ru and xmpp.ru by either a) being able to respond to the ACME protocol on domain(s) hosted http OR b) being able to write to a DNS TXT file for the domain(s). This implies that the victim already lost control of their process server and/or their nameserver.

Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

#40

Post by tetromino_ »

simpaticoder wrote: post #39
LeoPanthera wrote: post #4

The summary of the attack from https://notes.valdikss.org.ru/jabber.ru-mitm/ is very interesting: * 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…

>The attacker managed to issue multiple SSL/TLS certificates via Let’s Encrypt This implies that the attacker was able to validate domain ownership of jabber.ru and xmpp.ru by either a) being able to respond to the ACME protocol on domain(s) hosted http OR b) being able to write to a DNS TXT file for the domain(s). This implies that the victim already lost control of their process server and/or their nameserver.

No. Most probably it merely implies someone upstream of them (presumably their hosting provider under compulsion from German law enforcement) intercepted and spoofed their unencrypted, unauthenticated ACME HTTP traffic.

Same can happen to you.

Post reply on HN