Live data from Hacker News

Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

devever.net

81–90 of 150 posts

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

#81
post #49

A quick warning on hetzner. I needed a personal bare metal machine so signed up. I was travelling and on an IP in a distant land so their sign up asked for secondary verification via PayPal. All passed and now it’s should get a server? Nope - next day their support emailed telling me they would not approve my account without… no word of a lie here… either 1: a fax of my passport info page or 2: a scan and email conta…

https://gdpr.eu/email-encryption/

On email: "While encryption is not required, it is up to every organization to develop a rationale for developing the most appropriate data security practices."

You should probably apologise for being wrong.

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

#82

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…

XMPP supports channel binding, which is not mentioned in this post but would have prevented this attack. Unfortunately jabber.ru is running server software from 2016, and that old version doesn't support it. Pinning is problematic these days, because certificates are short-lived and renewed frequently. Users would be constantly asked to accept new certificates on a monthly basis, and they wouldn't think twice about c…

Pinnig is based on the keypair, not the cert. You can renew and not break pinning, right?

Also you can phase in a new cert with pinning.

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

#83
post #79

Earlier quoted context omitted.

Cloudflare exists out of necessity for the most part. The alternatives to shield from large scale DDoS are all US American too.

Which lets be honest isn't a problem that 99% of the sites using Cloudflare need to solve. Nobody is going to waste energy and time to attack your blog with your vacation photos. The huge wave of DDoS extortion attacks that happened 3-4 years ago was mostly enabled by "booter" services that themselves hid from law enforcement behind Cloudflare. Here is an example: https://therecord.media/feds-seize-ddos-booter-sites-…

Beat me to it. More often than not, every time I run into the run-of-the-mill booter or other super blatantly illegal things, at least some portion of the infrastructure is behind CloudFlare.

I don't have enough fingers and toes to count the number of abuse reports I've personally filed that seemingly go nowhere.

OVH at least takes down the booters and other proper malicious stuff. However, copyright infringement reports go ignored to the point to where I stopped bothering--not that I had any right to care when I torrented loads, but it was a little annoying that ~$10 software, with no DRM, regional discounts, and a dozen ways to pay still ended up pirated to the point to where it wasn't worth selling

(fun story: I still have email records from when a pretty beloved multi-billion dollar tech company launched their ROG-clone sub-brand and pirated our XenForo plugins to use on their site instead of ponying up $10 -- maybe one day I'll have to ask them for a laptop).

CloudFlare, on the other hand, at best, just passed on whatever I send in, and whoever their actual providers were never cared either, so nothing gets done. It can feel like rackeetering; sign-up for protection from the people attacking you ...whom we also protect and refuse to take down.

That said, I think 99% of small sites, personal blogs, etc, really don't need any of the services offered; the most useful offering for most people is literally probably DNS.

Game servers and gaming-related communities, or at the least the ones I am most attracted to, are just about the only thing I think requires DDoS mitigation regardless of size. Our little Garry's Mod TTT server with a max player limit of like ~24 people would get attacked a couple of times a week at least.

And good lord, the RuneScape community is another breed of toxic. The way I learned to program was by reverse engineering the game, and we'd work on private servers that were essentially from-scratch MMORPG servers that just emulated the RuneScape mechanics and protocol.

One aspect of the game, though, is PvP -- when you kill another player in the wilderness, unlike in a lot of other MMOs, you get most, if not all, of their items they have on them.

I could perhaps understand DDoSing another player during combat in order to steal their gear. But what made me stunned beyond belief was that when I hosted a "spawn PKing" server (e.g., PvP-only, but you don't have to work for your gear; everything is free - it's just for fun), they'd literally lure each other into TeamSpeak to grab IP addresses and DDoS each other for.... nothing :)

(and so you can imagine also just how often we'd get hit with massive attacks ourselves)

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

#84
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…

The Hetzner server used here was a dedicated, physical server.

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

#85
post #18

I looked into CAA but the current dns provider doesn't support those records. Is there a reason it had to be a new type not a more common TXT record?

See RFC5507: "Why Adding a New Resource Record Type Is the Preferred Solution"

DNS providers should support a wide range of RR types, and domain owners should vote with their NS records.

See https://github.com/StackExchange/dnscontrol/blob/master/docu... for a list of DNS providers that support CAA.

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

#86
post #76

Earlier quoted context omitted.

> This suggests a compromise of Hetzner and Linode network management. No it doesn't. It suggests that they both complied with a request from law enforcement.

So… compromised.

Compromised means they got hacked, which would translate to all servers in Linode and Hetzner being unsafe for all customers.

Since this affected only one client and it's more likely than not a lawful intercept, it's not a compromise.

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

#87
post #82

Earlier quoted context omitted.

XMPP supports channel binding, which is not mentioned in this post but would have prevented this attack. Unfortunately jabber.ru is running server software from 2016, and that old version doesn't support it. Pinning is problematic these days, because certificates are short-lived and renewed frequently. Users would be constantly asked to accept new certificates on a monthly basis, and they wouldn't think twice about c…

Pinnig is based on the keypair, not the cert. You can renew and not break pinning, right? Also you can phase in a new cert with pinning.

Yes, you can pin the public key instead, which is generally more helpful. But most ACME clients (including the "official" certbot) default to rotating the key too. That can be disabled, but it's a problematic default for this use case which means clients can't just enable pinning.

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

#88

Earlier quoted context omitted.

Easier to conceal the attack. The MiTM attacker can pass through a command stream without STARTTLS. If they intercepted 5223 they would have to do their own client-side TLS handshake with the attacked server, which would look really obvious to anybody doing TLS fingerprinting on the server: all of a sudden, 100% of their clients have the exact same TLS fingerprint. Stop outsourcing your PKI to ICANN, folks. Domains a…

They were doing their own TLS handshake - that's how the attack was discovered (the attacker presented a different certicate, which eventually expired, presumably due to negligence). They were decrypting and re-encrypting.

Read it again:

> they would have to do their own client-side TLS handshake

By intercepting the STARTTLS port the attacker can merely decrypt -- rather than, as you wrote, decrypting and re-encrypting.

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

#89

Earlier quoted context omitted.

They were doing their own TLS handshake - that's how the attack was discovered (the attacker presented a different certicate, which eventually expired, presumably due to negligence). They were decrypting and re-encrypting.

Read it again: > they would have to do their own client-side TLS handshake By intercepting the STARTTLS port the attacker can merely decrypt -- rather than, as you wrote, decrypting and re-encrypting .

This is not what the attackers did however. From the original article (not this one):

> Traffic dump on port 5222, the connection is hijacked on application level (L7), the server receives replaced ClientHello message from the client.

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

#90

Earlier quoted context omitted.

How would you do certificate pinning if you don't control the clients? My understanding is that certificate pinning is only possible if you control the clients, in which case you can embed which certificates are allowed directly in the client and bypass the whole web PKI. In a situation with general-purpose clients connecting, how would they know which certificates are meant to be allowed? That's what the web PKI is…

Isn't this what those "key hash pictures" in WhatsApp/Signal are solving? XMPP clients could implement such a mechanism, and if any certificate/domain along the path changes, the users in a conversation would be notified.

These are usually to validate the keys used in end-to-end encryption. Both parties must confirm that they see the same details, which confirms that the same keys are being used on both ends.
Post reply on HN