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

481–490 of 500 posts

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

#481

Post by teddyh »

mikeocool wrote: post #207
teddyh wrote: post #177

Earlier quoted context omitted.

Many people argue that a VPN+SSH is a reasonable solution, since it uses two separate implementations, where both are unlikely to be compromised at the same time. I would argue that the more reasonable option would be to split the SSH project in two; both of which validates the credentials of an incoming connection. This would be the same as a VPN+SSH but would not convolute the network topography, and would eliminat…

Best practice would have your internet exposed daemon (vpn or ssh) running a fairly locked down box that doesn’t also have your valuable “stuff” (whatever that is) on it. So if someone cracks that box, their access is limited, and they still need to make a lateral move to access actual data. In the case of this backdoor, if you have SSH exposed to the internet on a locked down jump box, AND use it as your internal me…

Sure, but that violates the end-to-end principle.

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

#482

Post by teddyh »

PhilipRoman wrote: post #198
teddyh wrote: post #192

Earlier quoted context omitted.

That would be possible, yes, but it’s not the current situation. And since we can choose how we proceed, I would prefer my proposal, i.e. that the SSH daemon be split into two separate projects, one daemon handling the initial connection, locked-down like you describe, then handing off the authenticated connection to the second, “inner”, SSH daemon, which also does the authentication , using the same credentials as s…

Huh, I briefly looked at the documentation for UsePrivilegeSeparation option and it looks very similar to what you're describing. Interesting why it didn't prevent this attack.

Note that UsePrivilegeSeparation is no longer an option; it is mandatory since OpenSSH 7.5, released seven years ago.

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

#483

Post by NarcissistDev »

saagarjha wrote: post #470
NarcissistDev wrote: post #430

Earlier quoted context omitted.

There’s a severe and dangerous lack of paranoia in this dev space. If I was letting someone maintain my codebase, I would 1 Billion percent be reviewing everything… if there was a binary added, I’d be building it myself and comparing the checksums. Trust absolutely no-one. If you can give a close friend or a loved one a loan of money and it is so easy for them to never pay you back, it should be a reminder that devs…

What's the point of having someone maintain your codebase if you have to do even more work than if you just did everything yourself?

[dead]

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

#484

Post by GabeIsko »

delusional wrote: post #458
deepbreath wrote: post #196

Earlier quoted context omitted.

> At the point an attacker has remote code execution The attacker doesn't have remote code execution in the xz case unless they can speak to your port 22. Port knocking prevents them from doing so, provided they don't know how to knock.

Assuming they have injected code into the sshd executable, couldn't that code just do the exploit without a connection? What I'm saying is that the structure of this payload is the way it is because sshd is accessible. Had it not been accessible, the payload just wouldn't have required an external connection.

I mean, this is the twisting logic. xy hack put's a backdoor in sshd. You need to access sshd port to go through the back door and get RCE. Hacker could have put something even more nefarious that could phone home somewhere. We would like to think that would have been a little easier to spot, but who knows.

To me, that is what makes this hack so noteworthy. Hacker got access, and then kept playing the long game. Very spooky. And yes, someone capable of this probably has a plan for gaining network access if they had a target in mind. Even with best security practice, this rabbit hole goes pretty deep.

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

#485

Post by McBun »

croemer wrote: post #433
jeroenhd wrote: post #337

Earlier quoted context omitted.

It's rather trivial to fake git commits. Basing this stuff on email times (especially replies to emails sent that same day) would be more relevant. However. if this operation was pulled off with the precision and opsec that it seems to have been, I wouldn't be too surprised if whatever group is behind this attack would've sent over + funded a developer somewhere in a time zone of their choice. No doubt any nation sta…

I'm basing this on Github's activity archive as queried through Clickhouse - which is much harder to fake than git commits: https://play.clickhouse.com/play?user=play#U0VMRUNUCiAgY3JlY... See the writeup here: https://til.simonwillison.net/clickhouse/github-explorer

Thank you for this tool.

That activity look 100% to be from a paid employee to me. He works in the morning and does git maintenance in the afternoon like clockwork... Between 12 and 18... It might also have been multiple employee.

He didn't work on Christmas or new year eve which is extremely telling...

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

#486

Post by infamouscow »

gowld wrote: post #203
gghffguhvc wrote: post #97

Earlier quoted context omitted.

Even with the MIT disclaimer and the author not being the distributor or have any relationship with the distributor. Publishing vulnerable open source software to GitHub with a disclaimer that says it isn’t fit for any purpose seems like a bit of an oversight of using MIT license in distros to me.

A software license has never been a protection against malicious criminal activity. They'd have to prove that the "feature" had a legitimate non-nefarious purpose, or was accidental, neither of which apply here.

In the US, you are innocent until proven guilty.

In the US, you are innocent until proven guilty.

In the US, you are innocent until proven guilty.

Apologies for having to be obnoxious about it, but it deserves repeating.

If you take a approach of presumed guilty where the accused have to prove their innocence: you have a problem. You'd have a very difficult time proving your innocence after being accused of a crime. Anyone can accuse you of a murder that happened at 2am, and your alibi of being asleep won't cut it. Remember, in this bizarro world, it's presumed you are already guilty. You need to convince the prosector and jury you didn't commit the crime. Even if you had 4K night vision video of you sleeping in your bed, it probably won't persuade anyone because the prosecutor will say you pre-recorded the video to deceive a jury, and since you're presumed guilty, it makes sense for you to manufacture evidence in your defense.

This is why guilty until proven innocent is genuinely stupid.

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

#487

Post by int_19h »

greyface- wrote: post #288
pama wrote: post #284

Earlier quoted context omitted.

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...

Ex post facto criminal liability is prohibited either constitutionally or by strong custom in most jurisdictions, and this is generally considered a fundamental part of having rule of law and due process. This is also spelled out in UDHR, ECHR, and several other similar documents.

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

#488

Post by int_19h »

McBun wrote: post #485
croemer wrote: post #433

Earlier quoted context omitted.

I'm basing this on Github's activity archive as queried through Clickhouse - which is much harder to fake than git commits: https://play.clickhouse.com/play?user=play#U0VMRUNUCiAgY3JlY... See the writeup here: https://til.simonwillison.net/clickhouse/github-explorer

Thank you for this tool. That activity look 100% to be from a paid employee to me. He works in the morning and does git maintenance in the afternoon like clockwork... Between 12 and 18... It might also have been multiple employee. He didn't work on Christmas or new year eve which is extremely telling...

The last commit in December is on the 21st, so I'm not sure how much can be read into it.

But note that he comes back next year on the 5th, then disappears for 6th and 7th, and comes back at 8th. 7th is the old-style Eastern Orthodox Christmas, as celebrated in e.g. Russia, Serbia, and Georgia, and 6th is therefore the Christmas Eve. Although in Russia official holidays are the entire week from January, 1 to January, 8 inclusive... still, for this kind of work I wouldn't expect them to stick to the letter of the law there.

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

#489

Post by int_19h »

beefnugs wrote: post #191
pixl97 wrote: post #32

Earlier quoted context omitted.

So who's started scanning open source lib test cases for more stuff like this?

Like everything else in this world, its utterly and completely unfixably broken: There is no way you can have complex huge dependencies properly. The best most paranoid thing is to have multiple networking layers hoping they have to exploit multiple things at once, and whitelist only networking for exactly what you are expecting to happen. (which is completely incompatible with the idea of ssl, we would need a new ty…

You can have complex huge dependencies, provided that they can be audited properly. Which means that, for starters, they need to be broken into smaller chunks for which the behavior can be fully specified. They need to be written in languages that are, inasmuch as it is possible, formally verifiable against the spec, even at considerable expense of performance. And where that is not possible, the languages still need to be the kind where any behavior that is not straightforward sticks out like a sore thumb.

Then once you do all that, of course, you have one particular version that has been audited and can be used as a dependency. Which means that "ship early, ship often" and "move fast and break things" are completely off the table.

In short, it means doing more or less the exact opposite of the trends in the industry for the past 50 years or so. Starting with rewriting everything that we already have.

And it will be insanely expensive, of course, because the sheer amount of man-hours needed on all this are massive. Nor can you get away with cheap disposable labor for most of it, since writing specs and formal proofs and doing audits all requires a very skilled labor force.

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

#490

Post by int_19h »

noobermin wrote: post #27
Alifatisk wrote: post #20

Earlier quoted context omitted.

Must be punching the air right now

Or, they must be strapped into a chair having teeth being pulled out by whoever directed them.

Why would they be? You don't get far with this kind of approach to valuable skilled human resources.
Post reply on HN