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

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

github.com

Post reply on HN
Print view View original

141–150 of 500 posts

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

#141

Post by rdtsc »

AlexCoventry wrote: post #109
TacticalCoder wrote: post #75

Earlier quoted context omitted.

> 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?

I've heard it many times in the form of "security through obscurity, lol! you obviously, don't know what you're doing".

Yeah, it's a "straw man" pretending the person they are addressing was just planning on running telnet with port knocking.

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

#142

Post by [deleted] »

MuffinFlavored wrote: post #98
bewaretheirs wrote: post #88

Earlier quoted context omitted.

it was part of the binary malware payload hidden in a binary blob of "test data". In a compression/decompression test suite, a subtly broken allegedly compressed binary blob is not out of place. This suggests we need to audit information flow during builds - the shipping production binary package should be reproduceably buildable without reading test data or test code.

How/why did the test data get bundled into the final library output?

[deleted]

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

#143

Post by Attummm »

Terr_ wrote: post #70
dec0dedab0de wrote: post #36

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".

While 'security through obscurity' shouldn't be your only defense, it still plays a crucial role within 'defense in depth' strategies.

In the past, sensitive networks relied heavily on obscurity alone. Just dialing the right phone number could grant access to highly sensitive networks. However, there's a cautionary tale of a security researcher who took the phrase 'don't do security through obscurity' to heart and dared hackers, leading to disastrous consequences.

Obscurity, when used appropriately, complements broader security measures. Take SSH, for example. Most bots target its default port. Simply changing that port removes the easy targets, forcing attackers to use more sophisticated methods, which in turn, leaves your logs with more concerning activity.

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

#144

Post by tredre3 »

bpfrh wrote: post #137
TacticalCoder wrote: post #75

Earlier quoted context omitted.

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

>It seems that we now have a clear proof that it's actually helping versus certain type of attacks (including source-code supply chain attacks). So would have a vpn or using a bastion host with a custom non standard ssh implementation... At some point you have to make the choice to not implement a security measure and I would argue that should stop at vpn+standard software for secure access. If you are a bigger compa…

    You also add another program with potential vulnerabilities, and as port knocking is not as popular as e.g. sshd, wireguard, maybe it gets less scrutiny and it leads to a supply chain attack?
That other program is just a stateful firewall, aka the Linux Kernel itself. If you can't trust your kernel then nothing you do matters.

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

#145

Post by anarazel »

est31 wrote: post #59
stingraycharles wrote: post #38

Earlier quoted context omitted.

I like the theory that actually, it wasn’t luck but was picked up on by detection tools of a large entity (Google / Microsoft / NSA / whatever), and they’re just presenting the story like this to keep their detection methods a secret. It’s what I would do.

I doubt that if Google detected it with some internal tool, they'd reach out to Microsoft to hide their contribution. It was reported by an MS engineer who happens to be involved in another OSS project. MS is doing business with the US intelligence community, for example there is the Skype story: First, rumors that NSA offers a lot of money for people who can break Skype's E2E encryption, then MS buys Skype, then MS…

> It was reported by an MS engineer who happens to be involved in another OSS project.

I view it as being OSS or postgresql dev that happens to work at microsoft. I've been doing the former for much longer (starting somewhere between 2005 and 2008, depending on how you count) than the latter (2019-12).

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

#146

Post by codedokode »

zoeysmithe wrote: post #114
dec0dedab0de wrote: post #36

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…

Port knocking is bit like a lazy person's VPN. You might as well get off your butt and install a vpn solution and use ssh via vpn. The time and effort is almost the same nowadays anyway. The chances of both vpn and ssh being exploited like this must be zero. Worse, most corporate, public wifi, etc networks block all sorts of ports. So at home sure you can open random ports but near everywhere else its just 80 and 443…

> nor can you audit every line of code all the time

You can if you distribute this job among volunteers or hire people to do that. There are millions of developers around the world capable to do this. But reality is that nobody wants to contribute time or pay for free software.

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

#147

Post by acdha »

MuffinFlavored wrote: post #98
bewaretheirs wrote: post #88

Earlier quoted context omitted.

it was part of the binary malware payload hidden in a binary blob of "test data". In a compression/decompression test suite, a subtly broken allegedly compressed binary blob is not out of place. This suggests we need to audit information flow during builds - the shipping production binary package should be reproduceably buildable without reading test data or test code.

How/why did the test data get bundled into the final library output?

That’s what the compromised build stage did. It’s really interesting to read if you want to see the details of how a sophisticated attacker works:

https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...

https://gynvael.coldwind.pl/?lang=en&id=782

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

#148

Post by bpfrh »

tredre3 wrote: post #144
bpfrh wrote: post #137

Earlier quoted context omitted.

>It seems that we now have a clear proof that it's actually helping versus certain type of attacks (including source-code supply chain attacks). So would have a vpn or using a bastion host with a custom non standard ssh implementation... At some point you have to make the choice to not implement a security measure and I would argue that should stop at vpn+standard software for secure access. If you are a bigger compa…

You also add another program with potential vulnerabilities, and as port knocking is not as popular as e.g. sshd, wireguard, maybe it gets less scrutiny and it leads to a supply chain attack? That other program is just a stateful firewall, aka the Linux Kernel itself. If you can't trust your kernel then nothing you do matters.

That other programm is knockd, which needs to listen to all traffic and look for the specified packets.

Granted, that program is really small and could be easily audited, but that same time could have been spent on trying apparmor/seclinux + a good vpn and 2fa

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

#149

Post by blablabla123 »

timmytokyo wrote: post #132
Alifatisk wrote: post #18

Earlier quoted context omitted.

For real, it's almost like a state-sponsored exploit. It's crafted and executed incredibly well, the performance issue feels like pure luck it got found.

I'm not sure why everyone is 100% sure this was a state-sponsored security breach. I agree that it's more likely than not state-sponsored, but I can imagine all sorts of other groups who would have an interest in something like this, organized crime in particular. Imagine how many banks or crypto wallets they could break into with a RCE this pervasive.

Especially considering this introduced a 500ms waiting time. But surely this was quite a risky time investment, 2 years. How likely is it that this was the only attempt if this was done by a group? (And maybe there were failed attempts after trying to take over maintenance of other packages?) Maybe really a very well-funded cybercrime group that can afford such moonshot endeavours or a state group that doesn't completely know yet what it's doing or isn't that well equipped (anymore?). I'm definitely curious about analysis of attribution

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

#150

Post by ametrau »

squigz wrote: post #82
jolmg wrote: post #79

Earlier quoted context omitted.

Not if you set it up such that each knocking sequence can only be used once. Port knocking is a flexible concept.

I wonder if one could combine port knocking and TOTP in some way, so the sequence is determined by the TOTP? (Security is not my thing; don't judge me!)

Yeah you could but wouldn’t it defeat the purpose of being basically a secret knock before you can give the password? The password should be the ssh password.
Post reply on HN