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

301–310 of 500 posts

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

#301

Post by jhugo »

pxx wrote: post #221
takeda wrote: post #204

Earlier quoted context omitted.

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…

The libarchive diff didn't create any vulnerability. The fprintf calls were consistent with others in the same repository.

It did, actually: the filename can contain terminal control characters, which thanks to the change from safe_fprintf to fprintf, were printed without escaping, which allows the creator of the archive being extracted to control the terminal of the user extracting the archive.

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

#302

Post by eklitzke »

xvector wrote: post #286
pphysch wrote: post #96

Earlier quoted context omitted.

Given the sophistication of this attack it would indeed be downright negligent to presume that it's the attackers' legal name and that they have zero OPSEC.

He used ProtonMail. I wonder if ProtonMail can pull IP logs for this guy and share them.

It might be worth looking into, but:

1) Probably by design protonmail doesn't keep these kinds of logs around for very long

2) Hacking groups pretty much always proxy their connection through multiple layers of machines they've rooted, making it very difficult or impossible to actually trace back to the original IP

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

#303

Post by asveikau »

yread wrote: post #254
btown wrote: post #163

Earlier quoted context omitted.

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…

Maybe they weren't all sockpuppets. Here Jigar Kumar was nitpicking Jia Tan's changes: https://www.mail-archive.com/xz-devel@tukaani.org/msg00556.h... That was not necessary to gain trust. Writing style is different, too. Later when Jia gained commit access he reminds him to merge it.

This looks like a very phony "debate".

I think the most convincing case made about the sock puppets is around account creation dates, and also people disappearing after they get what they need. Like Jigar disappearing after Jia becomes maintainer. Or the guy "misoeater19" who creates his debian bug tracker account to say that his work is totally blocked on needing xz 5.6.1 to be in debian unstable.

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

#304

Post by bobby_the_whale »

bewaretheirs wrote: post #88
MuffinFlavored wrote: post #78

Earlier quoted context omitted.

> When loading liblzma, it patches the ELF GOT (global offset table) with the address of the malicious code. How was this part obfuscated/undetected?

it was part of the binary malware payload hidden in a binary blob of "test data". In a compression/decompression test suite, a subtly broken allegedly compressed binary blob is not out of place. This suggests we need to audit information flow during builds - the shipping production binary package should be reproduceably buildable without reading test data or test code.

[dead]

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

#305

Post by kbenson »

juitpykyk wrote: post #295
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.

You're talking as if securing a backdoor with public cryptography is some unimaginable feat of technology. It's literally a couple hours work.

I don't think they were using complexity as the reason for that assumption, but instead goals. Adding security doesn't require a nation state's level of resources, but it is a more attractive feature for a nation state that wants to preserve it over time and prevent adversaries from making use of it.

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

#306

Post by jhugo »

loeg wrote: post #266
thenewwazoo wrote: post #259

Earlier quoted context omitted.

This is a NOBUS attack - Nobody But Us. By tying it to a particular key owned by the attacker, no other party can trigger the exploit.

I don't think this is responsive to my comment.

I think it is? They were not trying to hide the content, but rather to ensure that nobody else could encrypt valid payloads.

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

#307

Post by neodymiumphish »

kbenson wrote: post #305
juitpykyk wrote: post #295

Earlier quoted context omitted.

You're talking as if securing a backdoor with public cryptography is some unimaginable feat of technology. It's literally a couple hours work.

I don't think they were using complexity as the reason for that assumption, but instead goals. Adding security doesn't require a nation state's level of resources, but it is a more attractive feature for a nation state that wants to preserve it over time and prevent adversaries from making use of it.

And on the contrary, creating a vulnerability that’s not identifiable to a limited attack group provides for a bit more deniability and anonymity. It’s hard to say which is more favorable by a nation-state actor.

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

#308

Post by fubar9463 »

fubar9463 wrote: post #272
jmb99 wrote: post #216

Earlier quoted context omitted.

Any log that root on that box has write access to. It’s theoretically possible to have an anomaly detection service running on a vulnerable machine dumping all of its’ data to an append-only service on some other non-compromised box. In that case, (in this ideal world) the attacker would not be able to disable the detection service before it had logged the anomalous traffic, and wouldn’t be able to purge those logs s…

You would be sending logs to a log collector (a SIEM) in security terms, and then you could join your firewall logs against your SSH auth logs. This kind of anomaly detection is possible. Not sure how common it is. I doubt it is common.

In any case the ROI for correlating SSH logs against network traffic is potentially error prone and may be more noisy than useful (can you differentiate in logs between SSH logins from a private IP and a public one?).

An EDR tool would be much better to look for an attacker’s next steps. But if you’re trying to catch a nation state they probably already have a plan for hiding their tracks.

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

#309

Post by juitpykyk »

jmb99 wrote: post #216
FergusArgyll wrote: post #128

Earlier quoted context omitted.

Interesting... Though you can edit whatever log file you want

Any log that root on that box has write access to. It’s theoretically possible to have an anomaly detection service running on a vulnerable machine dumping all of its’ data to an append-only service on some other non-compromised box. In that case, (in this ideal world) the attacker would not be able to disable the detection service before it had logged the anomalous traffic, and wouldn’t be able to purge those logs s…

You can do it on a single machine if you use the TPM to create log hashes which can't be rolled back.

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

#310

Post by acid__ »

AlexCoventry wrote: post #130
wolverine876 wrote: post #104

Earlier quoted context omitted.

> The USA seems to have an affinity for hardware interdiction as opposed to software backdoors. What are some examples?

https://en.wikipedia.org/wiki/Tailored_Access_Operations

Be sure to check out the mentioned catalog. [1]

The NSA's capabilities back in 2008 were pretty astonishing: "RAGEMASTER" A $30 device that taps a VGA cable and transmits the contents of your screen to the NSA van sitting outside! Crazy stuff. Makes you wonder what they've built in the last 15 years.

[1] https://en.wikipedia.org/wiki/ANT_catalog

Post reply on HN