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

201–210 of 500 posts

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

#201

Post by gowld »

declan_roberts wrote: post #77

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.

This goes back to WWII. USA solves problems with manufacturing and money. Europeans relatively lack both, so they solve problems with their brains.

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

#202

Post by gowld »

wolverine876 wrote: post #110

Have the heads of the targeted projects - including xz (Lasse Collin?), OpenSSH (Theo?), and Linux (Linus) - commented on it? I'm especially interested in how such exploits can be prevented in the future.

OpenSSH and Linux were not targeted/affected.

xz and the Debian distribtion of OpenSSH were targeted.

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

#203

Post by gowld »

gghffguhvc wrote: post #97
kstrauser wrote: post #62

Earlier quoted context omitted.

Yes. This would surely be prosecutable under the CFAA. Honestly, if I were involved in this, I'd hope that it was, say, the FBI that caught me. I think that'd be the best chance of staying out of the Guantanamo Bay Hilton, laws be damned.

Even with the MIT disclaimer and the author not being the distributor or have any relationship with the distributor. Publishing vulnerable open source software to GitHub with a disclaimer that says it isn’t fit for any purpose seems like a bit of an oversight of using MIT license in distros to me.

A software license has never been a protection against malicious criminal activity. They'd have to prove that the "feature" had a legitimate non-nefarious purpose, or was accidental, neither of which apply here.

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

#204

Post by takeda »

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.

If you think of it as a state sponsored attack it makes a lot of sense to have a "secure" vulnerability in system that your own citizens might use.

It looks like the whole contribution to xz was an effort to just inject that backdoor. For example the author created the whole test framework where he could hide the malicious payload.

Before he started work on xz, he made contribution to libarchive in BSD which created a vulnerability.

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

#205

Post by ufo »

TheBlight wrote: post #176
avidiax wrote: post #85

Earlier quoted context omitted.

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…

It was found in a few weeks so why is it more likely it wouldn't have been noticed for months/years with more people running the backdoored version of the code?

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

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

#206

Post by deepbreath »

ulrikrasmussen wrote: post #94
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/

What if the knocking sequence was derived from a TOTP secret?

Don't have to do anything too complicated. Here's the knocker code in a short Bash script, produced by GPT4:

~ % gpt4 'write a very short bash script that takes the number stored in ~/.ssh/knock_seq, increments it by 1 and saves it to the file. It then takes the new number and concatenates it with the value stored in the file ~/.ssh/secret. It pipes the resulting string to sha1sum, spitting out binary. It then takes both the resulting sha1sum and the number used and pipes their concatenation to "nc -u $host $(cat ~/.ssh/knocking_port)". be brief'

  knock_seq=$(cat ~/.ssh/knock_seq)
  let knock_seq++
  echo $knock_seq > ~/.ssh/knock_seq
  concat_seq_secret=$(echo -n "${knock_seq}$(cat ~/.ssh/secret)")
  sha1_output=$(echo -n $concat_seq_secret | sha1sum -b | awk '{print $1}')
  final_output="${sha1_output}${knock_seq}"
  host=localhost
  knocking_port=$(cat ~/.ssh/knocking_port)
  echo -n $final_output | nc -u $host $knocking_port

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

#207

Post by mikeocool »

teddyh wrote: post #177
VWWHFSfQ wrote: post #170

Earlier quoted context omitted.

Port knocking is definitely dumb, but "increase your password lengths, or cryptographic key sizes" does nothing if your ssh binary is compromised and anyone can send a magic packet to let themselves in. Strict firewalls, VPNs, and defense-in-depth is really the only answer here. Of course, those things all go out the window too if your TCP stack itself is also compromised. Better to just air-gap.

Many people argue that a VPN+SSH is a reasonable solution, since it uses two separate implementations, where both are unlikely to be compromised at the same time. I would argue that the more reasonable option would be to split the SSH project in two; both of which validates the credentials of an incoming connection. This would be the same as a VPN+SSH but would not convolute the network topography, and would eliminat…

Best practice would have your internet exposed daemon (vpn or ssh) running a fairly locked down box that doesn’t also have your valuable “stuff” (whatever that is) on it.

So if someone cracks that box, their access is limited, and they still need to make a lateral move to access actual data.

In the case of this backdoor, if you have SSH exposed to the internet on a locked down jump box, AND use it as your internal mechanism for accessing your valuable boxes, you are owned, since the attacker can access your jump box and then immediately use the same vulnerability to move to an internal box.

In the case of a hypothetical VPN daemon vulnerability, they can use that to crack your jump box, but then still need another vulnerability to move beyond that. Not great, but a lot better than being fully owned.

You could certainly also accomplish a similar topology with two different SSH implementations.

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

#208

Post by hybridtupel »

gowld wrote: post #201
declan_roberts wrote: post #77

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.

This goes back to WWII. USA solves problems with manufacturing and money. Europeans relatively lack both, so they solve problems with their brains.

Israel is not in Europe

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

#209

Post by belthesar »

MuffinFlavored wrote: post #182
acdha wrote: post #147

Earlier quoted context omitted.

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

> build-to-host.m4 I wasn't aware that the rogue maintainer was able to commit himself without any PR review (or he snuck it through PR review) rogue steps in the build process as well that went unnoticed so that he could bundle decompressed `xz` streams from test data, that also patched output .so files well enough to add hooking code to them. How many "process failures" are described in that process that exist in e…

That's kind of the rub here.

> volunteer That's the majority of OSS. Only a handful of the projects we use today as a part of the core set of systems in the OSS world actually have corporate sponsorship by virtue of maintainers/contributors on the payroll. > unknown The actor built up a positive reputation by assisting with maintaining the repo at a time when the lead dev was unable to take an active role. In this sense, although we did not have some kind of full chain of authentication that "Jia Tan" was a real human that existed, that's about as good as it gets, and there's plenty of real world examples of espionage in both the open and closed source software world that can tell us that identity verification may not have prevented anything. > untrusted The actor gained trust. The barrier to gaining trust may have been low due to the mental health of the lead maintainer, but trust was earned and received. The lead maintainer communicated to distros that they should be added.

That's the rub here. It's _really easy_ to say this is a process problem. It's not. This was a social engineering attack first and foremost before anything else. It unlocked the way forward for the threat actor to take many actions unilaterally.

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

#210

Post by allanbreyes »

btown wrote: post #163
declan_roberts wrote: post #87

Earlier quoted context omitted.

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.

It's worth also noting that the spycraft involved a coordinated harassment campaign of the original maintainer, with multiple writing styles, to accelerate a transition of maintainership to the attacker: https://www.mail-archive.com/xz-devel@tukaani.org/msg00566.h... https://www.mail-archive.com/xz-devel@tukaani.org/msg00568.h... https://www.mail-archive.com/xz-devel@tukaani.org/msg00569.h... While this doesn't prove…

Ugh, that this psyops sockpuppetry may have started or contributed to the maintainer's mental health issues seems like the most depressing part of all this. Maintaining OSS is hard enough.
Post reply on HN