Live data from Hacker News

Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

github.com

101–110 of 500 posts

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#101
post #46
post #26

Earlier quoted context omitted.

Or...falling back on less noticed contingency plans...

My pet theory is that this was just one project they have been running for years. They are likely doing many more at same time. Slowly inserting parts in various projects and getting their contributors inside the projects.

That seems like a safe bet. If you are planning a multi year operation, it would be silly to do it all under a single account. Best to minimize the blast radius if any single exploit gets discovered.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#102
post #70

Stuff like this is why I like port knocking, and limiting access to specific client IPs/networks when possible. 20 years ago, I was working at an ISP/Telco and one of our vendors had a permanent admin account hardcoded on their gear, you couldn't change the password and it didn't log access, or show up as an active user session. Always limit traffic to just what is necessary, does the entire internet really need to b…

My gut-feel is that it rides near the line between "defense in depth" versus "security through obscurity".

The reality is that security through obscurity works really well as a layer in an otherwise already good security model. You make sure to test it with some red teaming, and if they fail to get through, you give them all the details about your tricks so they can also test the actual security.

The "obscurity" part mostly serves to limit the noise of drive by and bot'd attacks, such that each attack attempt that you end up stopping and catching is a more serious signal, and more likely to be directed. It's about short circuiting much of the "chaff" in the signal such that you are less warning fatigued and more likely to seriously respond to incidents.

The obscurity is not meant to prevent targeted attacks.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#103

Stuff like this is why I like port knocking, and limiting access to specific client IPs/networks when possible. 20 years ago, I was working at an ISP/Telco and one of our vendors had a permanent admin account hardcoded on their gear, you couldn't change the password and it didn't log access, or show up as an active user session. Always limit traffic to just what is necessary, does the entire internet really need to b…

Going in through the main Internet connection might not be the only way in. Someone surfing on Wifi who visits the wrong website can also become a second way into your internal network.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#104

One thing I notice about state-level espionage and backdoors. The USA seems to have an affinity for hardware interdiction as opposed to software backdoors. Hardware backdoors make sense since much of it passes through the USA. Other countries such as Israel are playing the long-con with very well engineered, multi-year software backdoors. A much harder game to play.

> The USA seems to have an affinity for hardware interdiction as opposed to software backdoors.

What are some examples?

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#106
post #84

Earlier quoted context omitted.

> The thing about port knocking is that if you're on a host where you don't have the ability to port-knock, then you're not able to connect. You can type http://hostname:porttoknock in a browser. As long as you're not behind a super restrictive gateway that doesn't let you connect to arbitrary ports, you're golden.

I'm a bit of a noob about this. Can you explain what this means?

Port knocking involves sending a packet to certain ports on a host. It's overkill but typing http://host:port/ in your browser will, as part of trying to make a TCP connection, send a packet to that port.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#107
post #24

Earlier quoted context omitted.

Am I reading it correctly that the payload signature includes the target SSH host key? So you can't just spray it around to servers, it's fairly computationally expensive to send it to a host.

*host key fingerprint, but I assume what you've meant. It's practically a good backdoor then, crypto graphically protected and safe against "re-play" attacks.

Not quite. It still looks vulnerable: an attacker A without the private key impersonates a victim server V and reports their host key. A careless attacker B with the key tries to attack A, but an ends up recovering a valid payload targeting V.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#108
post #84

Earlier quoted context omitted.

The thing about port knocking is that if you're on a host where you don't have the ability to port-knock, then you're not able to connect. This can turn into a footgun: you're away from your usual device, something happens and you desperately need to connect, but now you can't because all the devices in your vicinity don't have the ability to perform $SECURITY_FEATURE_X so that you can connect, and you're screaming a…

> The thing about port knocking is that if you're on a host where you don't have the ability to port-knock, then you're not able to connect. You can type http://hostname:porttoknock in a browser. As long as you're not behind a super restrictive gateway that doesn't let you connect to arbitrary ports, you're golden.

I've actually been behind a firewall that blocked outgoing connections except on several well-known ports. Had to run my SSH server over the port usually used for HTTPS just to get it unblocked.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#109

Stuff like this is why I like port knocking, and limiting access to specific client IPs/networks when possible. 20 years ago, I was working at an ISP/Telco and one of our vendors had a permanent admin account hardcoded on their gear, you couldn't change the password and it didn't log access, or show up as an active user session. Always limit traffic to just what is necessary, does the entire internet really need to b…

> Stuff like this is why I like port knocking, and limiting access to specific client IPs/networks when possible. Indeed: I whitelist hosts/IP blocks allowed to SSH in. I don't use port-knocking but I never ever criticized those using port knocking. I do really wonder if people are still going to say that port knocking is pointless and security theatre: we now have a clear example where people who were using port-kno…

> say that port knocking is pointless and security theatre

Who was saying that?

Post reply on HN