41–50 of 500 posts
> Note: successful exploitation does not generate any log entries. Does 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'?
Wonder if any anomaly detection would work on that
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…
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 at yourself for adding so much security at the expense of convenience.
This could happen as easily as restricting logins to SSH keys only, and not being able to use your SSH key on whatever host you have available at the time, wishing you'd have enabled password authentication.
> From down in the same mail thread: it looks like the individual who committed the backdoor has made some recent contributions to the kernel as well... Ouch.
https://www.openwall.com/lists/oss-security/2024/03/29/10
The OP is such great analysis, I love reading this kind of stuff!
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…
Earlier quoted context omitted.
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.
> It doesn't matter. To understand the exact behavior and extend of the backdoor, this does matter. An end to end proof of how it works is exactly what was needed. > A way to check if servers are vulnerable is probably by querying the package manager Yes, this has been know since the initial report + later discovering what exact strings are present for the payload. https://github.com/Neo23x0/signature-base/blob/maste…
Yeah but these servers and appliances aren't running Debian unstable are they? I'd understand if it affected LTS versions of distros, but these were people living on the bleeding edge anyway. Folks managing such servers are going to be fine running `apt-get update`.
We got lucky with this one, tbh.
Earlier quoted context omitted.
Must be punching the air right now
Or...falling back on less noticed contingency plans...
Earlier quoted context omitted.
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…
https://github.com/CERN-CERT/pam_2fa
Edit: MIT license provides a pretty broad disclaimer to say it isn’t fit for any purpose implied or otherwise.
Do we know if this exploit only did something if a SSH connection was made? There's a list of strings from it on Github that includes "DISPLAY" and "WAYLAND_DISPLAY": https://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…
Earlier quoted context omitted.
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.
Are you saying POCs are pointless unless a script kiddie can use it?