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

161–170 of 310 posts

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

#161

Post by bdd8f1df777b »

rav wrote: post #109
sho_hn wrote: post #88

Earlier quoted context omitted.

This refers to the fact that systemd was planning to drop the dependency on liblzma (the conpression library installed by xz), and instead dlopen it at runtime when needed. Not for security reasons, but to avoid pulling the libs into initramfs images. The backdoor relies on sshd being patched to depend on libsystemd to call sd_notify(), which several distros had done. OpenSSH has since merged a new patch upstream tha…

> The backdoor relies on sshd being patched to depend on libsystemd to call sd_notify I remember when we added sd_notify support to our services at work, I was wondering why one would pull in libsystemd as a dependency for this. I mean, there's a pure-Python library [1] that basically boils down to: import os, socket def notify(state=b"READY=1"): sock = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM) addr = os.geten…

> With proper error handling, that's about 50 lines of C code.

Writing proper error handling in C is a very tedious and error prone task. So it doesn't surprise me that people would rather call another library instead.

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

#162

Post by cesarb »

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.

From what I understand, it wasn't even the performance testing itself that caught the backdoor. The developer wanted to have the machine as quiescent as possible (so that nothing else running on it would interfere) before starting the performance tests, but sshd was using much more CPU than expected (and this could be observed with simple tools like "top"). My guess is that the usual "backscatter" of password guessing ssh login attempts from all over the Internet normally uses very little CPU time in sshd before being rejected, but the backdoor made each login attempt use a significant amount of CPU time to check whether it was an encrypted request from the attacker (and this particular machine had its sshd open to the Internet because it was a cloud machine being accessed via ssh through the open Internet).

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

#163

Post by almostnormal »

sjs382 wrote: post #64
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…

> Over time there is quite a large accumulation of hackers looking at the most mundane technical details. Are there though? Even if true, there are probably enough places with very few eyes on them.

Maybe something could be built to put more eyeballs on things.

A kind of online-tool that collects the sources to build some relevant distributions, a web front-end to show a random piece of code (filtered by language, probability to show inreasing by less-recently/frequently/qualified viewed) to a volunteering visitor to review. The reviewer leaves a self assesment about their own skills (feed back into selection probability) and any potential findings. Tool-staff double-checks findings (so that the tool does not create too much noise) and forwards to the original authors (bugs) or elsewhere (backdoors).

A bit like wikipedias show random page.

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

#164

Post by _8j50 »

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…

This tracks with other nation state sponsored attack patterns. I've had that same reaction before. Most APTs are like this but some Chinese,US and Russian APTs are so well funded, every aspect of their attacks is impressive.

Many hackers who work for nation states also have side gigs as crimeware/ransomgang members or actual pentesting jobs.

Reminds me of apt3/boyusec:

https://www.bleepingcomputer.com/news/security/chinese-gover...

It still boggles my mind that americans are against banning companies like huawei and bytedance. The MSS and PLA don't mess around.

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

#165

Post by zvmaz »

Jasper_ wrote: post #132
orbital-decay wrote: post #119

Earlier quoted context omitted.

You probably have too high expectations when you hear the "state-sponsored" part. Every large organization will inevitably end up like any other. They also have bureaucracy, deadlines, production cycle, poor communication between teams, the recent iOS "maybe-a-backdoor" story also shows that they don't always care about burning the vulnerabilities because they amassed a huge pile of them.

Eh. Take a look at other state-sponsored attackers. We know they have 0-days for iOS, we know they've been used, but even Apple doesn't know what they are since they are so good at hiding their tracks. I don't think a state-sponsored attack would upload their payload to the git repo and tarball for all to stare at after it's been found out, which only took about a month. NSO Group built a turing-complete VM out of a…

> Uploading a payload to the world wide web and calling it bad-3-corrupt_lzma2.xz is clownshoes by comparison.

While the world is trying to understand the backdoor, you sir decided that it's "clowshoes". I can only blindly defer to your expertise... "Clownshoes, amateur, hacker ring, ransomeware group." Done.

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

#166

Post by amoss »

orbital-decay wrote: post #119
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…

You probably have too high expectations when you hear the "state-sponsored" part. Every large organization will inevitably end up like any other. They also have bureaucracy, deadlines, production cycle, poor communication between teams, the recent iOS "maybe-a-backdoor" story also shows that they don't always care about burning the vulnerabilities because they amassed a huge pile of them.

Welp. Ok, well now my newest worst nightmare is a jira board with tickets for "Iran" and "North Korea" stuck in the wrong column and late-night meetings with "product" about features.

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

#167

Post by alecco »

noman-land wrote: post #77

I haven't been following this story super closely but I find it extremely odd that I've heard zero discussion about the perpetrator of this hack.

> However, I believe that he is actually from somewhere in the UTC+02 (winter)/UTC+03 (DST) timezone, which includes Eastern Europe (EET), but also Israel (IST)

https://rheaeve.substack.com/p/xz-backdoor-times-damned-time...

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

#168

Post by renk »

Rygian wrote: post #157
renk wrote: post #150

Earlier quoted context omitted.

That performance regression could also be a way to identify compromised systems.

If all systems are compromised you don't need to identify anymore.

Well, for now the payload delivery relies on things like x86, glibc.. still enough.

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

#169

Post by graemep »

atomicnumber3 wrote: post #94
anamax wrote: post #23

Earlier quoted context omitted.

> "There's a million ways to get caught for murder, and if you can think of half of them, you're a genius." Does "think of half" apply to the folks trying to solve murders?

Nah, it applies to the person trying to get away with the murder. People will do really, really intricate jobs of trying to cover up, then slip up because like, they leave a receipt in their car that accidentally breaks their alibi.

A clever murderer will disguise the murder as an accident, suicide or natural death. It will not even show in the stats as unsolved.

I got the idea from fiction (specifically Dorothy Sayers), but the number of murders Harold Shipman committed before anyone even noticed makes it plausible that people with relevant expertise (doctors, pharmacists, cops, etc.) could easily get away with murder. If Shipman had stopped after the first 100 or so he would have.

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

#170

Post by [deleted] »

ThePowerOfFuet wrote: post #159
orbital-decay wrote: post #136

Earlier quoted context omitted.

That's why I mentioned the recent story. [0] [1] "Apple doesn't know" when the chain uses an internal backdoor in Apple hardware is a... stretch. And the chain gives the strong vibes of corporate-style development, with all its redundancy and mismatch between two parts. It's not alchemy, really. [0] https://securelist.com/operation-triangulation-the-last-hard... [1] https://news.ycombinator.com/item?id=38783112 - HN…

Re the secret knock in the Apple silicon, a friend of mine once said "that's how you lose the NOBUS on a backdoor", and I think they were absolutely right. The one thing which most leads me to believe this was an intentional backdoor? The S-boxes.

[deleted]
Post reply on HN