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

281–290 of 500 posts

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

#281

Post by Aloisius »

rhaps0dy wrote: post #183
bpfrh wrote: post #148

Earlier quoted context omitted.

That other programm is knockd, which needs to listen to all traffic and look for the specified packets. Granted, that program is really small and could be easily audited, but that same time could have been spent on trying apparmor/seclinux + a good vpn and 2fa

I much prefer the approach I read about in https://github.com/moxie0/knockknock (use a safe language, trust basically only the program you write and the language), to a random port daemon written in C which pulls libpcap to sniff everything. To some extent knockknock also trusts the Python interpreter which is not ideal (but maybe OK)

In Linux, simple knocking (fixed sequences of ports) can be done entirely in the kernel with nftables rules. Probably could even have different knock ports based on day of the week or hour or source IP.

https://wiki.nftables.org/wiki-nftables/index.php/Port_knock...

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

#282

Post by kevincox »

loeg wrote: post #134

> The ciphertext is encrypted with chacha20 using the first 32 bytes of the ED448 public key as a symmetric key. As a result, we can decrypt any exploit attempt using the following key: Isn't this wild? Shouldn't the ciphertext be encrypted with an ephemeral symmetric key signed by the privkey? I guess anyone with the public key can still read any payload, so what's the point?

Encrypting the payload will allow you to get by more scanners and in general make the traffic harder to notice. Since the publicly available server code needs to be able to decrypt the payload there is no way to make it completely secure, so this seems like a good tradeoff that prevents passive naive monitoring from triggering while not being more complicated than necessary.

The only real improvement that I can see being made would be adding perfect forward secrecy so that a logged session couldn't be decrypted after the fact. But that would likely add a lot of complexity (I think you need bidirectional communication?)

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

#283

Post by dannyw »

jcranmer wrote: post #230
gghffguhvc wrote: post #48

Is there anything actually illegal here? Like is it a plausible “business” model for talented and morally compromised developers to do this and then sell the private key to state actors without actually breaking in themselves or allowing anyone else to break in. Edit: MIT license provides a pretty broad disclaimer to say it isn’t fit for any purpose implied or otherwise.

There are things you can't contractually wave away, especially in form contracts that the other side has no ability to negotiate (which is what software licenses amount to). One of those things is going to be fraud: if the maintainer is intentionally installing backdoors into their software and not telling the user, there's going to be some fraud-like statute that they'll be liable for.

That said, if you’re doing this for your jurisdiction’s security agency, you’ll certainly be protected.

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

#284

Post by pama »

gghffguhvc wrote: post #48

Is there anything actually illegal here? Like is it a plausible “business” model for talented and morally compromised developers to do this and then sell the private key to state actors without actually breaking in themselves or allowing anyone else to break in. Edit: MIT license provides a pretty broad disclaimer to say it isn’t fit for any purpose implied or otherwise.

You are talking about the greatest exposed hack of the computer supply chain so far by a big margin. Laws can be made retroactively for this type of thing. It has implications that are beyond the legal system, as the threat level is way beyond what is typically required as a sniff test for justifying military actions. This was not an RCE based on identifying negligent code; this was a carefully designed trap that could reverse the power dynamics during military conflict.

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

#285

Post by misswaterfairy »

rst wrote: post #3
miduil wrote: post #2

Super impressed how quickly the community and in particular amlweems were able to implement and document a POC. If the cryptographic or payload loading functionality has no further vulnerabilities, this would have been also at least not introducing a security flaw to all the other attackers until the key is broken or something. Edit: I think what's next for anyone is to figure out a way to probe for vulnerable deploy…

Well, it's a POC against a re-keyed version of the exploit; a POC against the original version would require the attacker's private key, which is undisclosed.

Could the provided honeypot print out keys used in successful and unsuccessful attempts?

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

#286

Post by xvector »

pphysch wrote: post #96
toasteros wrote: post #58

Earlier quoted context omitted.

The name that keeps coming up is Jia Tan ( https://github.com/JiaT75/ ) but we have no way of knowing if this is a real name, pseudonym, or even a collective of people.

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.

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

#287

Post by wolverine876 »

pama wrote: post #278
gowld wrote: post #202

Earlier quoted context omitted.

OpenSSH and Linux were not targeted/affected. xz and the Debian distribtion of OpenSSH were targeted.

The core source of the vulnerability (symbol lookup order allowing a dependency to preempt a function) might theoretically be fixed at the Linux+OpenSSH level.

It's in their ecosystem; they should be concerned about other similar attacks and about addressing the fears of many users, developers, etc.

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

#288

Post by greyface- »

pama wrote: post #284
gghffguhvc wrote: post #48

Is there anything actually illegal here? Like is it a plausible “business” model for talented and morally compromised developers to do this and then sell the private key to state actors without actually breaking in themselves or allowing anyone else to break in. Edit: MIT license provides a pretty broad disclaimer to say it isn’t fit for any purpose implied or otherwise.

You are talking about the greatest exposed hack of the computer supply chain so far by a big margin. Laws can be made retroactively for this type of thing. It has implications that are beyond the legal system, as the threat level is way beyond what is typically required as a sniff test for justifying military actions. This was not an RCE based on identifying negligent code; this was a carefully designed trap that cou…

> Laws can be made retroactively

Not in the United States. https://constitution.congress.gov/browse/article-1/section-9...

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

#289

Post by formerly_proven »

fpgaminer wrote: post #253
declan_roberts wrote: post #77

One thing I notice about state-level espionage and backdoors. The USA seems to have an affinity for hardware interdiction as opposed to software backdoors. Hardware backdoors make sense since much of it passes through the USA. Other countries such as Israel are playing the long-con with very well engineered, multi-year software backdoors. A much harder game to play.

My completely unexpert opinion, informed by listening to all the episodes of Darknet Diaries, agrees with this. US intelligence likes to just bully/bribe/blackmail the supply chain. They've got crypto chops, but I don't recall any terribly sophisticated implants like this one (except Stuxnet, which was likely Israel's work funded/assisted by the US). NK isn't terribly sophisticated, and their goal is money, so that d…

> Russia is all over the place in terms of targets/sophistication/etc ... but this feels a bit beyond anything I recall them accomplishing at a state level.

https://en.wikipedia.org/wiki/Triton_(malware) (https://www.justice.gov/opa/pr/four-russian-government-emplo...)

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

#290

Post by est31 »

anarazel wrote: post #145
est31 wrote: post #59

Earlier quoted context omitted.

I doubt that if Google detected it with some internal tool, they'd reach out to Microsoft to hide their contribution. It was reported by an MS engineer who happens to be involved in another OSS project. MS is doing business with the US intelligence community, for example there is the Skype story: First, rumors that NSA offers a lot of money for people who can break Skype's E2E encryption, then MS buys Skype, then MS…

> It was reported by an MS engineer who happens to be involved in another OSS project. I view it as being OSS or postgresql dev that happens to work at microsoft. I've been doing the former for much longer (starting somewhere between 2005 and 2008, depending on how you count) than the latter (2019-12).

Thanks for the explanation. Also thanks for catching this and protecting us all; I think in the end it's way more believable that you indeed found it on your own, above was just brainless blathering into the ether =). Lastly, thanks for your Postgres contributions.
Post reply on HN