The xz package was backdoored, and the payload appears to be targeting SSH on x86_64 Fedora and Debian.
What you need to know:
- The backdoored version did not make it into any stable distros
- It was caught about a month after it was introduced
- It did make it into some bleeding edge distros (e.g. Debian's unstable branch: sid)
- It only affected the binary releases, so if you build from source, you were safe from this one
- It was only caught because the backdoor caused some tests to take a half second longer, someone noticed this and decided to investigate why
Get the technical details directly from the person who discovered it: https://www.openwall.com/lists/oss-security/2024/03/29/4
Some updates on the payload:
- it's not an authentication bypass, it's remote code execution (RCE)
- the code to be executed is provided in the public key (very clever!)
- it requires the attacker's private key to exploit
- even of an attack were captured, it could not be replayed on another machine
For more details, see my source: https://bsky.app/profile/did:plc:x2nsupeeo52oznrmplwapppl/post/3kowjkx2njy2b
As I said before, there are a lot of lessons for payload authors here.
- Don't include the real payload (stage 2) in everyone infected, only in those who are exploited. Infection (stage 1) should just enable delivery.
- Always encrypt and sign your payloads, both for confidentiallity and to make sure others can't use your backdoor.
- Make sure captured payloads can not be replayed against everyone
- Don't phone home
- Make sure your stack is aligned!
- Stash your stage 1 in files that evade scrutiny (a unit test case file was good, but now that's been burned and people will be looking closer at those, at least for a while)
- If you do put a payload in a unit test, be sure to write a test that uses said file, and add some chaff so it's not immediately obvious that it's an obfuscated shell script
For any defenders out there who want some unsolicited advice about #exploit #detection. I got you. 😄
You might want to use auditd to log all invocations of the fork() and clone() syscalls. All successful calls to system() will result in one of these being called.
If you only monitor calls system() (which is a libc function), it's possible for a payload to just invoke the syscalls directly and you will miss new processes spawning.
The documentation for auditd is decent, but using it effectively does require a bit of knowledge about the #kernel and specifically #syscalls.
In addition to looking for processes, you can also look for files being opened, read, written, and tons of other things of interest.
None of this will stop any attacks, but it can help you know when you've been pwned and do some #forensics after the fact. Of course, to be of any practical value, you'll also need to detect the anomolous behavior via the log messages and ship an alert to another machine as quickly as possible.
The fastest way to do this is usually to ship the logs directly to a syslog server (or two) and do the analysis there.
As you may have guessed by now, I've personally done this. On some machines, it's extremely expensive (in terms of CPU & I/O) because a lot of these so-called cloud native apps want to do SO MANY SYSCALLS! Oh mein Gott! It's complete madness. Those systems take a lot of resources and a lot of work to deal with. If they are mission critical, that sucks.
But if compromising those services only gets the attacker a launchpad, and doesn't compromise anything that is really critical, you can sometimes cheat by lowering the amount of syscall monitoring on that box and focus on #network traffic from/to there.
Hopefully that critical machine doesn't need to talk to tons of arbitrary servers or if it does that is confined to one, untrusted network interface. If not, again, that sucks. Try to split some things up if you can. If not, you'll be in for a lot of work to do a reasonable job at exploit detection.
Remember: When formulating your detection routines don't ask the question of "how could I detect this payload?" Ask the question "How can I detect all payloads?"
You probably won't get to "all" payloads, but that framing helps avoid the problem of keying in on #exploit / #payload specific things that are trivial for the attacker to change. Detecting when the web server tries to access some file outside of the ones it normally messes with, on the other hand... that's harder to bypass (unless your web server can access /dev/sda or something similar, but if that's the case, you have bigger problems!).
I have plenty of suggestions for also thwarting the #attacks too, but this post has gotten long enough. As a teaser: a lot of the protection revolves around locking down permissions and limiting the syscalls that users or processes have access to. Maybe I'll post about that in the future.
#security #infosec #cybersecurity #cyber #cybersec #hacking #BlueTeam 💪
