Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
1–10 of 500 posts
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#2Super 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 deployments (which seems non-trivial) and also perhaps possibly ?upstreaming? a way to monitor if someone actively probes ssh servers with the hardcoded key.
Kudos!
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#3Super 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.
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#4All these efforts are appreciated, but I don't think the attacker is going to leak their payload after the disclosure and remediation of the vuln.
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#5Super 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.
It's a POC nevertheless, it's a complete implementation of the RCE minus obviously the private key.
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#6Has anyone tried the PoC against one of the anomalous process behavior tools? (Carbon Black, AWS GuardDuty, SysDig, etc.) I’m curious how likely it is that someone would have noticed relatively quickly had this rolled forward and this seems like a perfect test case for that product category.
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#7Earlier quoted context omitted.
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.
It's a POC nevertheless, it's a complete implementation of the RCE minus obviously the private key.
It doesn't matter. The people with the private key already knew all of this because they implemented it. The script kiddies without the private key can't do anything without it. A POC doesn't help them in any way.
A way to check if servers are vulnerable is probably by querying the package manager for the installed version of xz. Not very sophisticated, but it'll work.
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#8Super 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…
Probing for vulnerable deployments over the network (without the attacker's private key) seems impossible, not non-trivial.
The best one could do is more micro-benchmarking, but for an arbitrary Internet host you aren't going to know whether it's slow because it's vulnerable, or because it's far away, or because the computer's slow in general -- you don't have access to how long connection attempts to that host took historically. (And of course, there are also routing fluctuations.)
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#9Have we seen exploitation in the wild yet?
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#10It's pretty interesting that they didn't just introduce an RCE that anyone can exploit, it requires the attacker's private key. It's ironically a very security conscious vulnerability.