 A backdoor was recently discovered in XZUtils, a lossless compression tool that's widely used across systems on the internet because of its excellent compression ratios. A lot of package managers use it for compressing files and even kernel.org uses XZ for compressing the Linux kernel itself. Now the backdoor was first noticed by a Postgres developer working at Microsoft who was troubleshooting SSH issues on a Debian Linux system. The problem that this guy noticed was that SSH logins were taking too long, they were using too many CPU cycles, and it was generating errors with a memory debugging tool that he was using. And through careful analysis, he discovered that the problem was with recent updates that had been made to XZUtils and that those recent updates were in fact a malicious backdoor. This is his post about his findings on Openwall. Now this guy is not a security researcher, but this is still a pretty good write-up about the backdoor. Not to mention that this backdoor would have been one of the worst ones in a while in terms of how many systems it affected because the malware that he discovered wasn't just in Debian's XZ package as he initially thought, but the backdoor was actually in the upstream XZ repository. So if it didn't get discovered, it could have made its way downstream into all kinds of different Linux distributions that pretty much run the entire internet. And because this is open source software, the backdoor had to be hidden really, really well so that people wouldn't find it because you got to think there's lots of people looking over the source code and especially new commits that are being made to it. At least we hope that's what's going on. So a key portion of this backdoor was not in the upstream code or in build to host used by XZ and Git. Instead, it was hidden in binary files within the test folder. And funny enough, the first part of the backdoor was actually encrypted with the XZ library. How about that? We're going to use the library that we're backdooring to encrypt our very own backdoor. But this is probably just done to make it harder to analyze and discover the malware. So when you decompress this XZ file and you pipe it into bash, you get this code with the i function that calls head a whole bunch of times. So here the next stage of the backdoor is being loaded as a data stream, but it's actually being loaded as chunks. So if we take a look at the first head command here, 1024 bytes of data is being loaded, but then it's being redirected to dev null, which effectively means just throw away that 1024 bytes of data. And then if you notice the next head command has 2048 bytes of data that are being loaded, but there's no dev null. So that data is actually going to end up being kept as part of the backdoor's code. And then we see this process is repeated again and again where a chunk is thrown away and then a chunk is loaded, chunk is thrown away, chunk is loaded until we get to the very end here where the last 724 bytes are loaded. And I think these amounts vary depending on which version of the backdoor you're using, because there's a couple versions that were created. And then we can also see the tr command here, which was also used in the initial stage for byte substitution. So after these chunks are reassembled, rearranged, decompressed, and then piped into bin sh, we get the next stage of the backdoor, which is in this attachment injected dot txt. So this is the script that would be run at the end of building xz. And it's only going to run under a few conditions that are checked in here. Some of these conditions are checking to see if the target is running x86 64 Linux checking to see if they are building their packages with GCC and also checking to see if the package is being built as part of a Debian or RPM package build. So it appears that this backdoor is specifically trying to target Debian or Red Hat based systems, which is still really bad because those are some of the more common Linux distributions out there, especially in enterprise use. But on the upside, Arch, Gentoo, and other similar distros that are not based on Red Hat or Debian don't appear to be affected by this backdoor, which means we have once again been vindicated for our distro OCD. But anyway, if the conditions on the target system are right, then this lib LZMA LA CRC 64 fast binary object gets injected into the build process, and then your system is backdoor. Now, because the payload is a binary object, it has to be reverse engineered to really seem how this backdoor works. And the author here tells us, you know, he's not a security researcher or reverse engineer, he's not going to do all of that. But he does give us some surface level things that he was able to observe about the backdoor version of XZ. So, of course, the slower SSH logins were a symptom that, you know, initially clued him in that something was wrong. And it appears to be slow because the backdoor installs an audit hook into the dynamic linker to resolve symbols and libraries that were not yet loaded. So the hook gets called for numerous symbols, and it appears to wait for RSA public decrypt PLT to get resolved. And when it does, it changes its value to point to its own code. And when that backdoor is called, it runs the lib crypto library, presumably, to verify a key. And this is where research is still ongoing. But the leading theory is that the author of this backdoor puts in their key, and then it passes a payload to system, giving them remote code execution system level remote code execution. In fact, now it's even scarier than this backdoor itself, was the way that it actually made its way into this open source code. This was a hacking operation that was years in the making, and it seems to involve multiple people working together to infiltrate this repository. It starts in April of 2022 with GiaTan submitting their first patch to XZ via a mailing list. And a little over a week later, this new user, Jigar Kumar, appears in the thread, and he's talking about the commit that Gia made, but at the end, you can see he's saying that your efforts are good, but based on the slow release schedule, it will unfortunately be years until the community actually gets this quality of life feature. So here, he's throwing a little bit of shade at the maintainer of XZ, saying that, you know, this software has a slow release schedule, so it's going to be a while until anyone can actually benefit from this amazing code that Gia supposedly committed. And we can see more of this if we go to Jigar's next message, where he says that patches spend years on this mailing list, 5.2.0 release was seven years ago. There is no reason to think that anything is coming soon. And if we see the next message again, he's saying over one month and no closer to being merged, no surprise. He's just constantly throwing shade at the maintainer here. And then there's one last comment from Jigar asking Gia if they can commit it themselves. Because at this point, Gia had actually made some other commits to the XZ repo. And there was also pressure coming from an account named Dennis ENS around the same time. And just like Jigar, there's no activity on this account outside of the XZ repo. The beginning of 2023 is when Gia Tan appears to have made their first commit to XZ. Then in March of 2023, another commit is made where the primary contact email was changed from the original maintainer Lossy Collin to Gia Tans. Then there's this account, Hans Jans and Hans Jansen, who has very little activity besides a pull request to XZ in June of 2023. And then later they're pushing to have a compromise version of XZ to be included in Debian's repos. And this is just what's been discovered so far, but this clearly shows that an organized threat actor has spent years on this to get control of a package that's being widely used to try and backdoor Linux systems. The current recommendations to patch this bug are to update your system if you're on XZ version 5.6.0 or 5.6.1 or you can downgrade to a version prior to these if a patched version is not available for your repo yet. And even if you're not on a Red Hat or a Debian based system, you should definitely take action because like I said, the reverse engineering has not been completed yet. And these threat actors were messing with the XZ repo for years as you can see, so there could be other bugs that have not yet been discovered. But big thanks to Andreas Freend, I'm sure I'm messing his name up, but thanks anyway man, because you found one of the more scarier advanced persistent threats that I think I've ever seen in open source software before it actually got installed on a lot of systems and caused total chaos. If you enjoyed this video, please like and share it to hack the algorithm and check out my online store based.win where you can get awesome merch like the come and find it breathable cotton shirt or the little daemon hoodie or accessories for your phone or computer. 10% discount for all items at checkout when paying in Monero XMR. Have a great rest of your day.