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

231–240 of 310 posts

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

#231

Post by afiori »

_8j50 wrote: post #164
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/c…

For bytedance/TikTok the question is not really "should the US ban this company" but rather "should the government be able to ban any companies it wants (and also make it illegal for VPNs to allow US users to access relevant services/websites) without having to provide any substantial evidence?

Which is a very different question in practice

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

#232

Post by zellyn »

amoss wrote: post #166
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.

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.

Since it happened, I've said that the “Year of Snowden” turned “It's theoretically possible to backdoor the firmware of a hard drive” (for example), into “Somewhere in the NSA, there's a Kanban board with post-its for each major manufacturer of hard drives, and three of them are already in the 'done' column.”

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

#233

Post by alcover »

sofrimiento wrote: post #187
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.

I would be interested in semantic analysis of the communication from the involved online personas, similar to what was done for Satoshi, to point to a cultural direction. Would also be interesting to see if there were semantic style differences over time pointing to different people acting as the personas. Since it would be quite a lot of code that has been committed as well, would also be interesting to see if code…

I fully agree. Stylometry is surprinsingly accurate (as proven on this very forum corpus) and would be quite involved to hide from.

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

#234

Post by evilduck »

amoss wrote: post #166
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.

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.

https://cybercoe.army.mil/CDID/ and yeah some use agile practices.

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

#235

Post by yonatan8070 »

compsciphd wrote: post #201
Adverblessly wrote: post #190

Earlier quoted context omitted.

> but also Israel (IST) I had the same thought myself initially, but the analysis suggests a work-week that includes Fri, which precludes Israel (where the work week is Sun-Thu and not Mon-Fri), as well as celebrating Christmas and New Year's which are not official holidays in Israel. It isn't uncommon for younger people to take a day off for New Year's since it is an excuse to party, or for Jews with eastern Europea…

and I believe someone pointed out that there were commits on yom kippur? that is a day basically no one works. The skies are closed, the roads are empty and everyone is bicycling on all the available streets, including highways.

Israel isn't home only for Jewish people who don't work on Yom Kippur, there are significant populations of both Muslims and Chirstians

I don't think that you can rule out any country based on email and commit timestamps, the attacker could have been further east and had a late work day, or further east with an early work day

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

#236

Post by heyoni »

jwilk wrote: post #154
heyoni wrote: post #52

Earlier quoted context omitted.

I thought performance was actually fine? It only dragged when using valgrind, hence the rhetoric that it took some really unlikely circumstances for it to be detected that quickly.

No, it wasn't fine. From the advisory ( https://news.ycombinator.com/item?id=39865810 ): > With the backdoored liblzma installed, logins via ssh become a lot slower.

Yea you're right. 500ms vs 10ms on an older server. Was thrown off by this statement and thought only the perf/valgrind/gdb attachments were what really brought it to surface.

> Initially starting sshd outside of systemd did not show the slowdown, despite the backdoor briefly getting invoked. This appears to be part of some countermeasures to make analysis harder.

Performance was much worse but not enough to actually nudge the author into digging into it until the random ssh logins started piling up:

https://twitter.com/AndresFreundTec/status/17741907437768663...

https://nitter.poast.org/AndresFreundTec/status/177419074377...

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

#237

Post by olejorgenb »

jwilk wrote: post #154
heyoni wrote: post #52

Earlier quoted context omitted.

I thought performance was actually fine? It only dragged when using valgrind, hence the rhetoric that it took some really unlikely circumstances for it to be detected that quickly.

No, it wasn't fine. From the advisory ( https://news.ycombinator.com/item?id=39865810 ): > With the backdoored liblzma installed, logins via ssh become a lot slower.

2-3x slower 0m0.299s -> 0m0.807s [1]

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

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

#238

Post by rightbyte »

XorNot wrote: post #158
asveikau wrote: post #125

Earlier quoted context omitted.

I don't think we should assume a state actor. We don't know. It's kind of similar to stuxnet but attacking Linux distros is so broad and has such a huge risk of being exposed, as it was within a few weeks of deployment. A good nation state attack would put more effort into not being caught. But we don't know. So maybe I'm wrong.

Assuming a state-actor is a cope though. It's looking at the problem and saying "well we were fighting god himself, so really what could we have done?" Whereas given the number of identities and time involved, the thing we really see is "it took what, 2-3 or burner email accounts and a few dozen hours over 2 years to almost hack the world?" The entire exploit was within the scope of capability of one guy . Telling ou…

Ye it is a really good scapegoat. You get cover from war mongerers in a "don't blame the victim" way too.

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

#239

Post by olejorgenb »

rzwitserloot wrote: post #224
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…

I find this the most plausible explanation by far: * The highly professional outfit simply did not see teknoraver's commit to remove liblzma as standard dependency of systemd build scripts coming. * The race was on between their compromised code and that commit. They had to win it, with as large a window as possible. * This caused the amateuristic aspects: Haste. * The performance regression is __not__ big. It's luck…

They could also have regrouped and found another way to do the exploit, given the relative ease of updating the payload (though it's probably a limited number of times you could change the test blobs without causing suspicion?). But I agree this explanation is plausible.

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

#240

Post by d-z-m »

justusthane wrote: post #102
jpalawaga wrote: post #65

it's a rather good thing that this was found before it made it out broadly. Not just for obvious reason of not wanting an unknown party to have RCE on your infrastructure. I think as people keep digging they will eventually formulate a payload which will allow the backdoor to be used by anyone. As bad as it is for a single party to have access, it's much worse for any (every?) party to have access.

Isn’t that more or less impossible since the payload is a private RSA key?

From my understanding, the command payload is not an RSA private key. It is an SSH certificate's public key field, a section of which contains the signed command to be executed.
Post reply on HN