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

The xz sshd backdoor rabbithole goes quite a bit deeper

twitter.com

Post reply on HN
Print view View original

141–150 of 310 posts

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#141

Post by cookiengineer »

akira2501 wrote: post #114
rdtsc wrote: post #32

Earlier quoted context omitted.

I can believe it’s because it was a team behind the account. Someone developed the feature and another more careless or less experienced one integrated it. Another one possibly managing sock puppets and interacting in comments and PRs.

I wonder what the web admin control panel for the "fake human" looks like, or if it even rises to that level of sophistication yet.

It's called AIMS (Advanced Impact Media Solutions) and is used by several state-level actors these days, both pro- and contra-NATO.

Well, at least that one is the most sophisticated one on the market (as of now) and Team Jorge is probably making shitloads of money with it while not giving a damn about who uses their software in the end.

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#142

Post by bilekas »

ckcheng wrote: post #126
bilekas wrote: post #43

Earlier quoted context omitted.

Yes, I understand.. It's just not a surprise.

It was surprising because previously we had: 'XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."' [0]. [0]: https://news.ycombinator.com/item?id=39877267 (811 comments)

Did you understand the XZ backdoor before the rest of us ?

We will figure it out. With all of our stubborn ways, we can document it. Clap

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#143

Post by INTPenis »

atomicnumber3 wrote: post #4

The sophistication here is really interesting. And it all got caught because of a fairly obvious perf regression. It reminds of a quote I heard in one of those "real crime" shows: "There's a million ways to get caught for murder, and if you can think of half of them, you're a genius."

Given enough time and local testing they could have gotten away with it.

I'm positive their deadline changed due to @teknoraver's patch in libsystemd.

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#144

Post by asveikau »

EvanAnderson wrote: post #58
bilekas wrote: post #50

Earlier quoted context omitted.

No full dissemination of the backdoor itself has been done yet, as for the anti-debug, sure you can avoid things like that with flags. But this was done at compile level so its a bit more tricky. > I'd have to assume since there's anti-debug functionality that the code is also obfuscated. Not really, as above it was done at build time.. So you have already set your home up. It's shown the problems with package manage…

So ifunc is a link-time thing and not a runtime thing, then? (My background, when it comes to linking, is DOS and Windows.)

It's runtime, but I think dynamic linker. The Windows equivalent would be if a library patched some code at dllmain. Actually the Detours library in the Windows world is similar. But it's for performance; the idea is you would patch some function references based on the CPU revision to get faster code specific to your CPU.

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#145

Post by bartimus »

ufmace wrote: post #14

The weird thing about this one is how it seems super professional in some ways, and rather amateur in others. Professional in the sense of spending a long time building up an identity that seemed trustworthy enough to be made maintainer of an important package, of probably involving multiple people in social manipulation attacks, of not leaking the true identity and source of the attack, and the sophistication and ob…

What's also surprising is how quickly the community seems to be giving someone the benefit of the doubt. A compromised maintainer would probably exactly introduce a fake member joining the project to make certain commits. They might have a contact providing the sophisticated backdoor that they need to (amateurishly) implement.

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#146

Post by tw04 »

dralley wrote: post #134
tw04 wrote: post #95

Earlier quoted context omitted.

The fact that the guys developing the code weren't also simultaneously running valgrind and watching performance isn't hard to believe. They were targeting servers and appliances, how many servers and appliances do you know of that are running valgrind in their default image? Sure, in hindsight that's a "duh, why didn't we think of that" - but also it's not very hard at all to see why they didn't think of that. They…

In theory they should probably be testing against the CI pipelines of Debian and Fedora / CentOS, as that's the moat their backdoor has to cross.

They put code in to, in theory, avoid running in a development environment.

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#147

Post by beeboobaa3 »

hinkley wrote: post #130
lyu07282 wrote: post #41

Earlier quoted context omitted.

One measure might be that we never really found that many backdoors. Over time there is quite a large accumulation of hackers looking at the most mundane technical details. This may be confirmed by regular vulnerabilities that are found in sometimes many decades old software, since vulnerabilities are much harder to find than backdoors. For example shellshock was 30 year old code, PwnKit 12 and log4j was ~10 ish. So…

I’m not convinced that if I found a bug that I’d notice all the security implications of fixing it. Occasionally yes, but I wonder how many people have closed back doors just by fixing robustness issues and not appreciated how big of a bug they found.

Sure, but this xz backdoor is far, far more involved than that.

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#148

Post by gitaarik »

pflenker wrote: post #120
ufmace wrote: post #14

The weird thing about this one is how it seems super professional in some ways, and rather amateur in others. Professional in the sense of spending a long time building up an identity that seemed trustworthy enough to be made maintainer of an important package, of probably involving multiple people in social manipulation attacks, of not leaking the true identity and source of the attack, and the sophistication and ob…

We could be faced with a form of Survivorship Bias here[0]. I find that thought rather chilling. [0] https://en.wikipedia.org/wiki/Survivorship_bias

Which would mean that we have all kinds of active backdoors in our systems without us knowing it.

But wouldn't they be detected at some point by someone? Or would they be silently removed again after some time so the attackers are not revealed?

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#149

Post by glibg10b »

sureglymop wrote: post #96

Does anyone have a good explanation or introduction into the performance testing that was done to find this? And how to get started? Actually measuring performance always seemed to be a very hard task and I'd like to be able to do similar testing as the person which found this backdoor.

https://www.openwall.com/lists/oss-security/2024/03/29/4

  > == Observing Impact on openssh server ==
  > 
  > With the backdoored liblzma installed, logins via ssh become a lot slower.
  > 
  > time ssh nonexistant@...alhost
  > 
  > before:
  > nonexistant@...alhost: Permission denied (publickey).
  > 
  > before:
  > real 0m0.299s
  > user 0m0.202s
  > sys 0m0.006s
  > 
  > after:
  > nonexistant@...alhost: Permission denied (publickey).
  > 
  > real 0m0.807s
  > user 0m0.202s
  > sys 0m0.006s

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#150

Post by renk »

ufmace wrote: post #14

The weird thing about this one is how it seems super professional in some ways, and rather amateur in others. Professional in the sense of spending a long time building up an identity that seemed trustworthy enough to be made maintainer of an important package, of probably involving multiple people in social manipulation attacks, of not leaking the true identity and source of the attack, and the sophistication and ob…

That performance regression could also be a way to identify compromised systems.
Post reply on HN