It'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.
For real, it's almost like a state-sponsored exploit. It's crafted and executed incredibly well, the performance issue feels like pure luck it got found.
Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
21–30 of 500 posts
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#22Does this mean, had this exploit gone unnoticed, the attacker could have executed arbitrary commands as root without even a single sshd log entry on the compromised host regarding the 'connection'?
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#23It'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.
For real, it's almost like a state-sponsored exploit. It's crafted and executed incredibly well, the performance issue feels like pure luck it got found.
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#24It'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.
Am I reading it correctly that the payload signature includes the target SSH host key? So you can't just spray it around to servers, it's fairly computationally expensive to send it to a host.
It's practically a good backdoor then, crypto graphically protected and safe against "re-play" attacks.
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#25Earlier quoted context omitted.
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
#26Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#27Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#28Has 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.
The blog has the actual rule content which I haven't seen from other security vendors
https://sysdig.com/blog/cve-2024-3094-detecting-the-sshd-bac...
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#29Have we seen exploitation in the wild yet?
Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor
#30https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01
These don't have any obvious connection to SSH, so maybe it did things even if there was no connection. This could be important to people who ran the code but never exposed their SSH server to the Internet, which some people seem to be assuming was safe.