I’m genuinely disturbed that a person who was a core developer could just go rogue.
From what I’ve been reading, it sounds like they were malicious from the very beginning. The work to integrate the malware goes back to 2021. https://boehs.org/node/everything-i-know-about-the-xz-backdoor
It’s an extremely sophisticated attack that was hidden very well, and was only accidentally discovered by someone who noticed that rejected SSH connections (eg invalid key or password) were using more CPU power and taking 0.5s longer than they should have. https://mastodon.social/@AndresFreundTec/112180406142695845
From that post, commits set to UTC+0800 and activity between UTC 12-17 indicate that the programmer wasn’t operating from California but from another country starting with C. The name is also another hint.
That could be part of their plan though… Make people think they’re from China when in reality they’re a state-sponsored actor from a different country. Hard to tell at this point. The scary thing is they got very close to sneaking this malware in undetected.
A lot of critical projects are only maintained by one person who may end up burning out, so I’m surprised we haven’t seen more attacks like this. Gain the trust of the maintainer (maybe fix some bugs, reply to some mailing-list posts, etc), take over maintenance, and slowly add some malware one small piece at a time, interspersed with enough legit commits that you become one of the top contributors (and thus people start implicitly trusting you).
Edit: Based on this analysis, they may have been based in a European timezone and just changed their timezone to UTC+8 before committing to Git to make it look like they were in China: https://rheaeve.substack.com/p/xz-backdoor-times-damned-times-and. Their commits were usually between 9 am and 6 pm Eastern European Time, and there are a few commits where the timezone was set to UTC+2 instead of UTC+8.
According to this post, the person involved exposed a different name at one point.
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
Cheong is not a Pingyin name. It uses Romanization instead. Assuming that this isn’t a false trail (unlikely, why would you expose a fake name once instead of using it all the time?) that cuts out China (Mainland) and Singapore which use the Pingyin system. Or somebody has a time machine and grabbed this guy before 1956.
Likely sources of the name would be a country/Chinese administrative zone that uses Chinese and Romanization. Which gives us Taiwan, Macau, or Hong Kong, all of which are in GMT+8. Note that two of these are technically under PRC control.
Realistically I feel this is just a rogue attacker instead of a nation state. The probability of China 1. Hiring someone from these specific regions 2. Exposing a non-pinying full name once on purpose is extremely low. Why bother with this when you have plenty of graduates from Tsinghua in Beijing? Especially after so many people desperate for jobs after COVID.
In case you’re not trolling:
I’m kinda hoping it was just that a state sponsored attacker showed up on their door and said “include this snippet or else…” otherwise it’s terrifying thinking of someone planning some long con like this
We are all relying on the honesty of a few overworked volunteers…
could this be a nation-state attack? since jiat75 spent multiple years developing a fake persona and it seems like a lot of effort was put into this
I’m on Void, and I had the malicious version installed. Updating the system downgraded xz to 5.4.6, so it seems they are on it. I’ll be watching discussions to decide if my system might still be compromised.
What is the name of the software that is affected??
xz is the compromised package, but it in turn compromises ssh authentication
In turn it compromises ssh authentication allows remote code execution via system(); if the connecting SSH certificate contains the backdoor key. No user account required. Nothing logged anywhere you’d expect. Full root code execution.
There is also a killswitch hard-coded into it, so it doesn’t affect machines of whatever state actor developed it.
It’s pretty clear this is a state actor, targeting a dependency of one of the most widely used system control software on Linux systems. There are likely tens or hundreds of other actors doing the exact same thing. This one was detected purely by chance, as it wasn’t even in the code for ssh.
If people ever wonder how cyber warfare could potentially cause a massive blackout and communications system interruption - this is how.
Hard to tell from first glance but my guess would be this is fallout from the ongoing xz drama. Here: https://www.openwall.com/lists/oss-security/2024/03/29/4
some people in my mastodon feed are suggesting that the backdoor might have connected out to malicious infrastructure or substituted its own SSH host keys, but I can’t find any clear confirmation. More info as the investigation progresses.
I guess at this point if you’re on Fedora 40 or rawhide clear / regen your host keys, even after xz version rollback
or substituted its own SSH host keys,
why would the backdoor do that? It would immediately expose itself because every ssh client on the planet warns about changed host keys when connecting.
Perhaps it was a poorly worded way of suggesting that invalidating host keys would invalidate all client keys it could potentially generate? Either way it’s a lot of speculation.
Resetting the keys and SSH config on any potentially compromised host is probably not a terrible idea
Nuke from orbit might be an overreaction, if you need that machine perhaps disable ssh or turn the machine off until later next week when the postmortems happen. If you need that trusted machine now, then yes fresh install
Honestly doing a fresh install is a good test of your recovery abilities. You should always have a way to restore critical content in an emergency
