Earlier quoted context omitted.
Well this very reply you made is very much like something I would see on Reddit.
The door is that way, kind sir.
[flagged]
Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
451–460 of 500 posts
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#452[deleted]
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#453Do we know who's the attacker?
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.
Interesting to look through the "starred" repos of that account ... seems like a hit list: https://github.com/JiaT75?tab=stars
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#454Earlier 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…
pretty unhealthy attitude to live by tbh. almost better being burned by a malicious payload once every 10 years than live in perpetual fear of being constantly scammed
[dead]
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#455Earlier quoted context omitted.
> Port Knocking doesn't add any security benefit in the sense that there are known non avoidable security risk aka your transmit your password(knocking) in clear text over the network. This take is bordering on not even wrong territory. The point of port knocking isn't to increase entropy of your password or authentication keys per se, it is to control who can send packets to your SSH daemon, either to limit the nois…
>This take is bordering on not even wrong territory. The point of port knocking isn't to increase entropy of your password or authentication keys per se, it is to control who can send packets to your SSH daemon, either to limit the noise in your logs or to mitigate an RCE in the SSH daemon. The vast majority of potential attackers in the real world are off-path and aren't going to be in a position to observe someone'…
> If you read my full sentence in the context it stands, I argue that authorizing access to your openssh instance is done by sending an authentication code in cleartext.
I did read your full post. Your claim that port knocking adds no security benefit is just simply incorrect. Even if you take for granted the scenario of an attacker who can recover the port knock sequence, there is still the benefit of shielding the SSH daemon from other attackers who cannot do so. Which is…a “security benefit.”
Describing the port knocking sequence as an extension of someone’s authentication key is where this goes off into not even wrong territory. A dynamically controlled firewall rule (port knocking) is not fungible with bits from an authentication token for the reasons I’ve already outlined - the benefit is limiting network access to the daemon at all.
> Yes a vpn that has no known reliably attack vector is definitely better than a protocol with a known working attack vector
You talk about recovering someone’s port knocking sequence as if that is trivial to do or in any way reliable. It is, in fact, neither of those things. An attacker would have to either:
1) sniff network traffic in front of the server
2) sniff network traffic in front of the client
3) compromise the server
4) compromise the client
5) brute force the port knocking sequence without getting locked out.
Most attackers are going to be in a position to try brute forcing — that’s it.
Meanwhile, you may not have noticed, but commercial VPNs have suffered a steady stream of high-impact CVEs for the last few years.
Wireguard is certainly better in this regard than any commercial VPN I know of, but it does have challenges with regard to key distribution/device enrollment, and thus from a practical standpoint limits access to pre-enrolled endpoints, which is a limitation someone using port knocking does not have.
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#456Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#457Earlier quoted context omitted.
> It’s got me suspicious of build-time dependency we have in an open source tool, where the dependency goes out of its way to prefer xz and we even discovered that it installs xz on the host machine if it isn’t already installed — as a convenience. Kinda weird because it didn’t do that for any other dependencies. Have you considered reaching out to the maintainers of that project and (politely) asking them to explain…
> Have you considered reaching out to the maintainers of that project and (politely) asking them to explain? That's kind of a catch-22, right? They'd explain with a seemingly good answer if they did it for actual reasons. They'll still explain with a seemingly good answer if they did it for nefarious reasons. I don't have a good answer to this except to monitor this dependency and its changes.
I'm not sure it's a catch-22, there are many possibilities and subsequent outcomes. I would just want to satiate my curiosity.
You assume they'll have a good reason, but they may not. They could be a malicious actor but also suck at it, and you might spook them into reconsidering. Or they may be fully innocent and just suck at packaging and distributing software and you might help them learn something.
If they do have a good reason, it should stand on its own merits when presented. Anyone could be up to no good and they might be plotting the end of the world, but they also might coincidentally and not relatedly happen to like xz-utils a lot.
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#458Earlier quoted context omitted.
> I'm very down on connecting directly through SSH without network access. The xz situation has validated this opinion. Did it? At the point an attacker has remote code execution, couldn't they just as easily pivot into an outgoing connection to some command and control server? I don't see how some intermediary access point would have alleviated this problem. If the call is coming from inside the house, the gig is al…
> 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.
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#459Earlier quoted context omitted.
This is not that concept. That concept is no one but us can technically complete the exploit. Technical feasibility in that you need a supercomputer to do it, not protecting a backdoor with the normal cia triad
That doesn't seem correct: If they determine the vulnerability is only exploitable by the NSA for reasons such as computational resources, budget, or skill set, they label it as NOBUS and will not move to patch it, but rather leave it open to exploit against current or future targets. If (!) the NSA regards ssh keys as secure, then from that article it sounds like the NOBUS thing would fit.
Is it legal and possible for the NSA to socially attack someone with mental health issues this way?
I'd like to rule-out some state actors by the mere heartbreaking act of socially engineering and targeting a person in pain.
Not even considering the original maintainer may be a US citizen (idk).
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#460Earlier quoted context omitted.
I'm not claiming the attempt didn't succeed. I'm claiming that the attempt didn't occur, and that distributing the backdoor more widely would only have created the preconditions for an attempt. We don't know who the intended target was, or what the intended payload was. Yes, subsection (b) of the CFAA covers attempts at acts described in subsection (a) of the CFAA. Which specific act under subsection (a) do you claim…
All of them? It's a backdoor into Linux to gain unauthorized access to computers that even specifically only works for that attackers specific private key. We have trial by jury where I guess you could argue that this carefully crafted backdoor was just some sort weird accident, but we also have prosecutors to make the obvious counterargument and investigate what these folks were going for. Though frankly they're pro…
> All of them?
> literally all of part a
It's not (1) or (2) as no exfiltration has occurred. It's not (3) as a government system has not been targeted. It's not (4) as "the thing obtained consists only of the use of the computer". It's not (5) as no system has been targeted or damaged (based on the statutory definition of 'damage'). It's not (6) as we have no evidence of the attacker sharing their Ed448 private key. It's not (7) as there has been no act of extortion.
> did someone just trip and fall on their keyboard over a period of months to accidentally carry out sophisticated social engineering to write a carefully hidden backdoor into a package targeted at hijacking widely used operating systems?
I'm not arguing that it was a weird accident. I'm arguing that this clearly malicious act does not, based solely on the information we have today, constitute a violation of the CFAA.