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

81–90 of 500 posts

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

#81

Post by ibotty »

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!

No that patch series is from Lasse. He said himself that it's not urgent in any way and it won't be merged this merge window, but nobody (sane) is accusing Lasse of being the bad actor.

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

#82

Post by squigz »

jolmg wrote: post #79
mr_mitm wrote: post #73

Earlier quoted context omitted.

Note that port knocking is vulnerable to replay attacks. Single Packet Authentication is better, but requires a private key (can be your SSH key). https://www.cipherdyne.org/fwknop/

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!)

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

#83

Post by Joel_Mckay »

deknos wrote: post #55
Joel_Mckay wrote: post #51

Earlier quoted context omitted.

Port knocking with ssh over https using client certs. And port knocking is one of the few effective methods against the standard distributed brute forcing slow attacks. Note if you blanket-ban IN/RU/UK/CN/HK/TW/IR/MX/BZ/BA + tor/proxies lists, than 99.998% of your nuisance traffic issues disappear overnight. =)

can you give an example for an implementation of portnocking/ssh/over https and client certs?

In general, it is a standard shore-wall firewall rule in perl, and the standard ssh protocol wrapper mod.

These are very well documented tricks, and when combined with a standard port 22 and interleaved knock ports tripwire 5 day ban rules... are quite effective against scanners too.

I am currently on the clock, so can't write up a detailed tutorial right now.

Best regards, =)

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

#84

Post by mlyle »

herpderperator wrote: post #42
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…

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.

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

#85

Post by avidiax »

TheBlight wrote: post #60
TechDebtDevin wrote: post #39

Earlier quoted context omitted.

Likely a team of people at a three letter agency.

Everyone keeps saying this but it seems unlikely to me that they'd do this for a relatively short window of opportunity and leave their methods for all to see.

You are judging this by the outcome, as though it were pre-ordained, and also assuming that this is the only method this agency has.

It is much more likely that this backdoor would have gone unnoticed for months or years. The access this backdoor provides would be used only once per system, to install other APT (advanced persistent threats), probably layers of them. Use a typical software RAT or rootkit as the first layer. If that is discovered, fallback to the private keys you stole, or the social engineer the company directory you copied. If that fails, rely on the firmware rootkit that only runs if it's timer hasn't been reset in 6 months. Failing that, re-use this backdoor if it's still available.

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

#86

Post by miduil »

nindalf wrote: post #50
doakes wrote: post #25

Earlier quoted context omitted.

Are you saying POCs are pointless unless a script kiddie can use it?

The context of the conversation, which you seem to have missed, is that now that we have a POC, we need a way to check for vulnerable servers. The link being that a POC makes it easier for script kiddies to use it, meaning we're in a race against them. But we aren't, because only one group in the whole world can use this exploit.

> is that now that we have a POC, we need a way to check for vulnerable servers.

You misunderstand me, the "need to check for vulnerable servers" has nothing to do with the PoC in itself. You want to know whether you're vulnerable against this mysterious unknown attacker that went through the all the hoops for a sophisticated supply chain attack. I never said that we need a way to detect it because there is a POC out, at least I didn't meant to imply that either.

> script kiddies to use it, meaning we're in a race against them

This is something you and the other person were suddenly coming up with, never said this in first place.

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

#87

Post by declan_roberts »

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.

I agree that this is probably about persistence. Initially I thought the developer was playing the long-con to dump some crypto exchange and make off with literally a billion dollars or more.

But if that was the case they wouldn't bother with the key. It'd be a one-and-done situation. It would be a stop-the-world event.

Now it looks more like nation-state spycraft.

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

#88

Post by bewaretheirs »

MuffinFlavored wrote: post #78
tadfisher wrote: post #68

Earlier quoted context omitted.

When loading liblzma, it patches the ELF GOT (global offset table) with the address of the malicious code. In case it's loaded before libcrypto, it registers a symbol audit handler (a glibc-specific feature, IIUC) to get notified when libcrypto's symbols are resolved so it can defer patching the GOT.

> When loading liblzma, it patches the ELF GOT (global offset table) with the address of the malicious code. How was this part obfuscated/undetected?

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.

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

#89

Post by webmaven »

mlyle wrote: post #84
herpderperator wrote: post #42

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.

TIL another interesting browser feature. Thank you.

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

#90

Post by noman-land »

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…

Got any advice to easily set up port knocking?
Post reply on HN