How did the exploit do this at runtime?
I know the chain was:
opensshd -> systemd for notifications -> xz included as transient dependency
How did liblzma.so.5.6.1 hook/patch all the way back to openssh_RSA_verify when it was loaded into memory?
61–70 of 500 posts
How did the exploit do this at runtime?
I know the chain was:
opensshd -> systemd for notifications -> xz included as transient dependency
How did liblzma.so.5.6.1 hook/patch all the way back to openssh_RSA_verify when it was loaded into memory?
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.
Honestly, if I were involved in this, I'd hope that it was, say, the FBI that caught me. I think that'd be the best chance of staying out of the Guantanamo Bay Hilton, laws be damned.
Earlier quoted context omitted.
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.
Do we have a detailed technical analysis of the code? I read a few analysis but they all seem preliminary. It is very useful to learn from the code.
Earlier quoted context omitted.
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.
I like the theory that actually, it wasn’t luck but was picked up on by detection tools of a large entity (Google / Microsoft / NSA / whatever), and they’re just presenting the story like this to keep their detection methods a secret. It’s what I would do.
Stuff like this is why I like port knocking, and limiting access to specific client IPs/networks when possible. 20 years ago, I was working at an ISP/Telco and one of our vendors had a permanent admin account hardcoded on their gear, you couldn't change the password and it didn't log access, or show up as an active user session. Always limit traffic to just what is necessary, does the entire internet really need to b…
There's a lot of solutions now where the host has an agent that reaches out instead of allowing incoming connections which can be useful (assuming you trust that proxy service/software).
One place I worked, we ran our jumphost on GCP with Identity Aware Proxy and on AWS with SSM sessions so had to authenticate to the cloud provider API and the hosts weren't directly listening for connections from the internet. Similar setup to ZeroTier/TailScale+SSH
Instead of needing the honeypot openssh.patch at compile-time https://github.com/amlweems/xzbot/blob/main/openssh.patch How did the exploit do this at runtime? I know the chain was: opensshd -> systemd for notifications -> xz included as transient dependency How did liblzma.so.5.6.1 hook/patch all the way back to openssh_RSA_verify when it was loaded into memory?
Instead of needing the honeypot openssh.patch at compile-time https://github.com/amlweems/xzbot/blob/main/openssh.patch How did the exploit do this at runtime? I know the chain was: opensshd -> systemd for notifications -> xz included as transient dependency How did liblzma.so.5.6.1 hook/patch all the way back to openssh_RSA_verify when it was loaded into memory?
Instead of needing the honeypot openssh.patch at compile-time https://github.com/amlweems/xzbot/blob/main/openssh.patch How did the exploit do this at runtime? I know the chain was: opensshd -> systemd for notifications -> xz included as transient dependency How did liblzma.so.5.6.1 hook/patch all the way back to openssh_RSA_verify when it was loaded into memory?
Stuff like this is why I like port knocking, and limiting access to specific client IPs/networks when possible. 20 years ago, I was working at an ISP/Telco and one of our vendors had a permanent admin account hardcoded on their gear, you couldn't change the password and it didn't log access, or show up as an active user session. Always limit traffic to just what is necessary, does the entire internet really need to b…
The thing about port knocking is that if you're on a host where you don't have the ability to port-knock, then you're not able to connect. This can turn into a footgun: you're away from your usual device, something happens and you desperately need to connect, but now you can't because all the devices in your vicinity don't have the ability to perform $SECURITY_FEATURE_X so that you can connect, and you're screaming a…
Then you attach a device that can have port knocking to that unsupported host. Also, I remember it was called port punching not knocking.
Stuff like this is why I like port knocking, and limiting access to specific client IPs/networks when possible. 20 years ago, I was working at an ISP/Telco and one of our vendors had a permanent admin account hardcoded on their gear, you couldn't change the password and it didn't log access, or show up as an active user session. Always limit traffic to just what is necessary, does the entire internet really need to b…