 It is March 30th of 2024 and yes, your SSH might have a backdoor, but don't worry, the sky's not falling. There's some really smart people that are jumping on top of this. I just wanted to put a video out to talk about the problem because I've seen a few people ask me and I've posted on LinkedIn. So I wanted to post here, but I want to note that this is a point in time of March 30th, 2024 at about 1pm Eastern Standard Time. And this is still a developing story, but let's talk about how this bug was found and what they're doing about it and whether or not you're affected. And essentially, unless you're running a bleeding edge version of Red Hat or Debian, you're probably not affected, but that doesn't mean all distributions don't pull from bleeding edge. And we'll talk about that in a moment. So let's jump over to you how this bug was found. I think that's really important. Now everything I talk about will be linked down below and we'll start here with Andre who found this. I accidentally found a security issue while benchmarking postgres changes. If you run Debian testing unstable or some other bleeding edge distribution, I strongly recommend you upgrade ASAP. And essentially, he was running some micro benchmarks. And what's wild is he found essentially a small hiccup when doing these, this small hiccup didn't set well with him. And it led him to start pulling apart more and more why the build process wasn't right. And if we go to the actual post they have, after observing the symptoms around Libs ZMA, part of the XC package on Debian SID installations over the last weeks, logins with that stage taking a lot of CPU time and of all grind errors, I figured out the answer. The upstream XC repository and the XC Tarballs have been backdoor. I first thought this was the compromise of Debian's package, but it turns out to be upstream. And they break down some of the details. And what's interesting is it's a very specific that it only does this in certain build situations, specifically targeting targeting x86 CPU, right here is the conditions included for x86 64 Linux. So it won't even compile and pull this back door in consistently, it only does it on certain situations, such as these conditions being met. And that is really concerning. There's a lot of detail that goes into the obfuscation of this backdoor. It's actually the code and an obfuscated part of the code that when it's built, if conditions are met, it pulls in more code to create the back door. Now NIST has assigned the CVE 2024 3094, there's all the details as I said, this will be linked below. Red Hat actually has assigned us a base score 10.0 absolutely critical. And by the way, this is not something you're going to find in your Red Hat, your standard rel production systems, as it was noted before, even with Red Hat, this is only in the bleeding edge version of the distribution, as far as we know, as of the recording of this video. But at least know some of you that are watching this video may be using Kali Linux and they did tweet this out. The XC package starting from version 5.6.0 to 5.6.1 was found to contain a backdoor. The impact this vulnerability affected Kali between March 26 to March 29. If you updated your Kali installation on or after March 26 is crucial apply the latest updates today. So yes, it does affect certain bleeding edge distributions that are quite popular Kali is going to be among them. We're not going to know all the bleeding edge ones, but this is kind of have to be on a case by case basis. These companies are going to have to let us know and some of these projects are going to have to let us know if they're pulling from that latest one. So this is going to be on a case by case basis, but most of the concern is if you're running something that's bleeding edge. Now the last thing I want to leave you with is this right here is a GitHub post with a FAQ on the XC utilities backdoor. A lot of good background in here. It talks about the two project maintainers on there. One of the project maintainers has already updated his site, both of the project maintainers have been suspended until it can be sorted out. We don't know if one of the project maintainers actually injected this or their account was compromised and the injection happened. So we are not here to blame anyone. As a matter of fact, I really like the fact that it's right here. We do not speculate on the people behind the project in this document. This is not a productive use of our time law enforcement will be able to handle identifying those responsible. As of right now, we do not know exactly what the payload was going to be. That is at least not something I was able to figure out. The GitHub repository has been completely shut down for now. But of course, I know people over at Microsoft are pouring through this and going through along with other security researchers that have access to a lot of this data to try to figure out exactly what was going on. There's a lot of obfuscation going on so that this would hide not just the way it would only build in certain situations, but how they implemented it was a little bit challenging to see and easily find. Hence the reason some coincidences of the pauses that were occurring being the trigger to start looking further and really happen to take this apart because it really wasn't obvious for people just looking at the code. But one of the last things I want to comment in here is this is open source in action. If this was going on in a closed source world, we wouldn't see it. We wouldn't have this level of commit and investigation that you have that is completely transparent in the open source world. Supply chain tax are just becoming more and more the norm. We're going to keep seeing them. But the fact that we can unravel all of this, the fact that we have so many if I despite the fact that Microsoft took it down, there are plenty of copies out there of all the GitHub history. We understand the build history, how long this was affected for and how companies are easily able to such as Kali Linux say that yes, these are the dates that were affected by for that particular library with that particular problem. This is one of the reasons I'm still such an open source advocate for these things, because when this happens in the closed source world, we have a much harder time finding out anything about it who actually did it or well, any of the details or that it even happened with the open source world, it takes a ton of obfuscation. And even then with all the efforts that were going into this, it was still found out it's still being unraveled, it's still being taken apart. And we're getting better all the time at scrutinizing all the code that goes into build our open source products. But I'll leave all those links down there. And as I said, this is a developing thing, but I don't want people to panic if you're not running something that is absolutely bleeding edge, you should be fine. Just go ahead and update if you are running Kali or something like that. And because we don't know the payload, I'm not exactly sure if there's a way to indicate whether or not you were compromised, but I will say that because this was in SSH, this is one more good argument not to publicly expose SSH. I generally locked down my SSH or keep it behind a VPN or filter it by only certain control IPs that I may log into. Those are still great practices. And if you have those practices in place, you have a whole lot less to worry about. Thanks.