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

341–350 of 500 posts

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

#341

Post by acid__ »

acdha wrote: post #121
knoxa2511 wrote: post #28

Earlier quoted context omitted.

Sysdig released a blog on friday. "For runtime detection, one way to go about it is to watch for the loading of the malicious library by SSHD. These shared libraries often include the version in their filename." The blog has the actual rule content which I haven't seen from other security vendors https://sysdig.com/blog/cve-2024-3094-detecting-the-sshd-bac...

Thanks! That’s a little disappointing since I would have thought that the way it hooked those functions could’ve been caught by a generic heuristic but perhaps that’s more common than I thought.

My experience from working in the security space is that all the tech is pretty un-sexy (with very good sales pitches), and none of it will save you from a nation-state attacker.

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

#342

Post by pavon »

davikr wrote: post #74
faxmeyourcode wrote: post #43

Edit: I misunderstood what I was reading in the link below, my original comment is here for posterity. :) > From down in the same mail thread: it looks like the individual who committed the backdoor has made some recent contributions to the kernel as well... Ouch. https://www.openwall.com/lists/oss-security/2024/03/29/10 The OP is such great analysis, I love reading this kind of stuff!

Lasse Collin is not Jia Tan until proven otherwise.

No, he likely is not. But the patch series includes commits co-developed by Jia Tan, and lists Jia Tan as a maintainer of the kernel module.

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

#343

Post by neodymiumphish »

webmaven wrote: post #111
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.

Was the performance issue pure luck? Or was it a subtle bit of sabotage by someone inside the attacking group worried about the implications of the capability? If it had been successfully and secretly deployed, this is the sort of thing that could make your leaders much more comfortable with starting a "limited war". There are shades of "Setec Astronomy" here.

Considering how difficult it might be (and identifiable) to attempt direct exploitation of this without being sure your target is vulnerable, it’s plausible the performance issue allowed for an identifiable delay in attempts. This might be useful in determining whether to attempt the exploit, with an auto-skip if it received a response in less than N milliseconds.

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

#344

Post by mlyle »

toast0 wrote: post #268
mlyle wrote: 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.

Likely won't be enough if you're behind CGNAT and you get a different public IP on different connections.

Most decent CGNAT will give you the same source IP when you connect to the same dest IP repeatedly.

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

#346

Post by skykooler »

gitfan86 wrote: post #41
herpderperator wrote: post #22

> Note: successful exploitation does not generate any log entries. Does this mean, had this exploit gone unnoticed, the attacker could have executed arbitrary commands as root without even a single sshd log entry on the compromised host regarding the 'connection'?

Yeah, but then you would have ssh traffic without a matching login. Wonder if any anomaly detection would work on that

That would look the same as a random failed ssh login, which happens all the time. The connection isn't maintained past that point (unless the payload chooses to do so).

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

#347

Post by MOARDONGZPLZ »

VMG wrote: post #225
MOARDONGZPLZ wrote: post #72

Earlier quoted context omitted.

Shutting down 99.9% of speculation on how the vulnerability was found in the first place.

(1) obviously not (2) they could just say they found it during some routine dependency review or whatever

I mean, yes. I’ve read all the commentary I can get my hands on about this incident because it is fascinating and this is the first instance of some parallel construction theory of finding it I’ve seen.

Second, maybe a routine dependency review is how they _actually_ found it but they don’t want future people like this focusing too much on that otherwise they may try to mitigate, whereas now they may focus on something inane like a 0.5 second increase in sshd’s load time or whatever.

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

#348

Post by [deleted] »

haswell wrote: post #16
asveikau wrote: post #10

It's pretty interesting that they didn't just introduce an RCE that anyone can exploit, it requires the attacker's private key. It's ironically a very security conscious vulnerability.

I suspect the original rationale is about preserving the longevity of the backdoor. If you blow a hole wide open that anyone can enter, it’s going to be found and shut down quickly. If this hadn’t had the performance impact that brought it quickly to the surface, it’s possible that this would have lived quietly for a long time exactly because it’s not widely exploitable.

[deleted]

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

#349

Post by ufo »

TheBlight wrote: post #299
ufo wrote: post #205

Earlier quoted context omitted.

We were lucky that the backdoor called attention to itself, because it impacted the performance off ssh and introduced valgrind warnings.

Doesn't that further suggest non-state actor(s)?

I've heard that it was only detected because the developer that found it was using different compiler flags than the default. Under default settings, the backdoor was stealthier.

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

#350

Post by ufo »

belorn wrote: post #185
reaperman wrote: post #172

Earlier quoted context omitted.

Security-by-obscurity is dumb, yes. But in the context of supply-chain exploits in the theme of this xz backdoor, this statement is also myopic: > If you want more secret bits which users need to know in order to access your system, increase your password lengths, or cryptographic key sizes. If your sshd (or any other exposed service) is backdoored, then the "effective bits" of any cryptographic key size is reduced t…

Chaining multiple different login system can make sense. A more sensible solution over port knocking would be an alternative sshd implementation with a tunnel to the second sshd implementation. Naturally the first one should not run as root (similar to the port knocking daemon). That way it would not be in clear text, and the number of bits of security will be order of magnitude larger even with very simple password.…

Chaining login methods would not help if the outermost login method is backdoored with an RCE.
Post reply on HN