and later it will turn out that the AI solution was actually two clickworkers in a trenchcoat

xzbot from Anthony Weems enables to patch the corrupted liblzma to change the private key used to compare it to the signed ssh certificate, so adding this to your instructions might enable me to demonstrate sshing into the VM :)

Fun :)

Btw, instead of installing individual vulnerable debs as those kali instructions I linked to earlier suggest, you could also point debootstrap at the snapshot service so that you get a complete system with everything as it would've been in late March and then run that in a VM... or in a container. You can find various instructions for creating containers and VMs using debootstrap (eg, this one which tells you how to run a container with systemd-nspawn; but you could also do it with podman or docker or lxc). When the instructions tell you to run debootstrap, you just want to specify a snapshot URL like https://snapshot.debian.org/archive/debian/20240325T212344Z/ in place of the usual Debian repository url (typically https://deb.debian.org/debian/).

A daily ISO of Debian testing or Ubuntu 24.04 (noble) beta from prior to the first week of April would be easiest, but those aren't archived anywhere that I know of. It didn't make it in to any stable releases of any Debian-based distros.

But even when you have a vulnerable system running sshd in a vulnerable configuration, you can't fully demo the backdoor because it requires the attacker to authenticate with their private key (which has not been revealed).

But, if you just want to run it and observe the sshd slowness that caused the backdoor to be discovered, here are instructions for installing the vulnerable liblzma deb from snapshot.debian.org.

https://mullvad.net/en/blog/evaluating-the-impact-of-tunnelvision

Sounds like it requires that your DHCP server is hostile, which is actually a very small (though nonzero, yes) number of the attack scenarios that VPNs are designed for

In most situations, any host on the LAN can become a DHCP server.

“there are no ways to prevent such attacks except when the user’s VPN runs on Linux or Android” is a very funny way of saying “in practice applies only to Windows and iOS”.

No. There are certainly ways of mitigating it, but afaict no Linux distros have done so yet.

The vast majority of LANs do not do anything to prevent rogue DHCP servers.

Just to be clear, a "DHCP server" is a piece of software which can run anywhere (including a phone). Eg, if your friend's phone has some malware and you let them use the wifi at your house, someone could be automatically doing this attack against your laptop while they're there.

VPNs have several purposes but the big two are hiding your traffic from attackers on the local area network and concealing your location from sites that you visit.

If you're using a VPN on wifi at a cafe and anyone else at the cafe can run a rogue DHCP server (eg, with an app on their phone) and route all of your traffic through them instead of through the VPN, I think most VPN users would say the purpose of the VPN has been defeated.

because i thought the situation described by the post was tragicomic (as was somewhat expressed by the line from it quoted in the post title)

You can use Wireshark to see the packets and their IP addresses.

https://www.wireshark.org/download.html

https://www.wireshark.org/docs/

A word of warning though: finding out about all the network traffic that modern software sends can be deleterious to mental health 😬

I do have wireguard on my server as well, I guess it’s similar to what tailscale does?

Tailscale uses wireguard but adds a coordination server to manage peers and facilitate NAT traversal (directly when possible, and via a intermediary server when it isn't).

If your NAT gateway isn't rewriting source port numbers it is sometimes possible to make wireguard punch through NAT on its own if both peers configure endpoints for eachother and turn on keepalives.

Do you know if Yggdrasil does something similar and if we exchange data directly when playing over Yggdrasil virtual IPv6 network?

From this FAQ it sounds like yggdrasil does not attempt to do any kind of NAT traversal so two hosts can only be peers if at least one of them has an open port. I don't know much about yggdrasil but from this FAQ answer it sounds like it runs over TCP (so using TCP applications means two layers of TCP) which is not going to be conducive to a good gaming experience.

Samy Kamkar's amazing pwnat tool might be of interest to you.

I have a device without public IP, AFAIK behind NAT, and a server. If I use bore to open a port through my server and host a game, and my friends connect to me via IP, will we have big ping (as in, do packets travel to the server first, then to me) or low ping (as in, do packets travel straight to me)?

No, you will have "big ping". bore (and everything on that page i linked) is strictly for tunneling which means all packets are going through the tunnel server.

Instead of tunneling, you can try various forms of hole punching for NAT traversal which, depending on the NAT implementation, will work sometimes to have a direct connection between users. You can use something like tailscale (and if you want to run your own server, headscale) which will try its best to punch a hole for a p2p connection and will only fall back to relaying through a server if absolutely necessary.

See https://github.com/anderspitman/awesome-tunneling for a list of many similar things. A few of them automatically setup letsencrypt certs for unique subdomains so you can have end-to-end HTTPS.