Luis Rodríguez, CTO of Xygeni.io, joins host Robert Blumen for a discussion of the recently thwarted attempt to insert a backdoor in the SSH (Secure Shell) daemon. OpenSSH is a popular implementation of the protocol used in major Linux distributions for authentication over a network. Luis describes how a backdoor in a supporting library was recently discovered and removed before the package was published to stable releases of the Linux distros. The conversation explores the mechanism of the attack through modifying a function table in the runtime; how the attack was inserted during the build; how the attack was carefully staged in a series of modifications to the lz compression library; the nature of “Jia Tan,” the entity who committed the changes to the open source project; social engineering that the entity used to gain the trust of the open source community; what forensics indicates about the location of the entity; hypotheses about whether criminal or state actors backed the entity; how the attack was detected; implications for other open source projects; why traditional methods for detecting exploits would not have helped find this; and lessons learned by the community. Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes
Related Episodes
- SE Radio 606: Charlie Jones on Third-Party Software Supply Chain Risks
- SE Radio 541: Jordan Harband and Donald Fischer on Securing the Supply Chain
- SE Radio 587: M. Scott Ford on Managing Dependency Freshness
Other References
- Luis Rodríguez on the ssh backdoor XZ Backdoor: “That was a close one”
- FAQ by @thesamesam on the xz backdoor: xz-utils backdoor situation (CVE-2024-3094)
- Gynvael on the bash-stage obfuscation: xz/liblzma: Bash-stage Obfuscation Explained
- Xygeni | Secure your Software Development and Delivery | Xygeni Security home page
- Luis Rodríguez on the Ledger Attack : The Ledger Attack: draining hardware cryptowallets
- Luis Rodríguez on the 3CX supply chian attack: 3CX Supply Chain Attack: Lessons Learned
- Luis Rodríguez Berzosa LinkedIn profile: @luis-rodríguez-xygeni
Transcript
Transcript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.
Robert Blumen 00:00:19 For Software Engineering Radio. This is Robert Blumen. Today I’m joined by Luis Rodriguez. Luis is the CTO of Xygeni, where he focuses on supply chain security. Prior to Xygeni, he held management positions and consultant roles at Argento and other software companies. Luis, welcome to Software Engineering Radio.
Luis RodrÌguez 00:00:43 Hi, I appreciate the opportunity to talk in this podcast.
Robert Blumen 00:00:47 Would you like to say anything about your background that I didn’t mention?
Luis RodrÌguez 00:00:50 I have worked mainly in the application security space for some 15-20 years, more or less, mainly on the vendor side. I was interested in application security and cyber security in general. And I work in later projects in the static analysis for vulnerabilities for application security vulnerabilities. Also in the SCA space, detecting vulnerabilities on dependencies on third party dependencies. I felt a bit guilty on producing a lot of noise, a lot of vulnerabilities. And in fact, the new project, which is Xygeni, which I started as a co-founder intending to correct that problem to give a better approach to managing the vulnerabilities and also the malware because not only the passive security problems, but also the active ones, the issues that third party bad actors are injecting in the supply chain. This is, we are focused on that right now.
Robert Blumen 00:01:55 Supply chain security has been in the news a lot. We have covered it on Software Engineering Radio a few times. Episode 535 on Supply Chain Attacks, 541 on Securing Open-source Supply Chains and 606 on Third Party Supply Chain Risks. Today we will be talking about a celebrated, or maybe I should say, infamous supply chain attack on the SSH daemon through a package called XZ. This attack has been widely reported in the media, and I follow this to some extent, although I wouldn’t call myself a security researcher. I didn’t feel that the media really dived very deeply in depth into this, and hopefully we will be doing that today. I want to start out with, we will cover what has already been reported on us. Could you give a summary of the attack and then we’ll delve more into details.
Luis RodrÌguez 00:02:55 Sure. Basically, a malicious actor created a command execution backdoor in a popular Linux compression library, LCMA XZ for short, resulting in a backdoor in another popular remote access system, which is open SSH. This was an advanced server supply chain attack with obfuscation hiding this behavior from reviewers. It was detected on March 28th this year, just one month after it was injected, and it was quickly contained, so it did not enter stable distributions, which fortunately is a lucky thing. Because imagine if you have a back door open in more than 20 million potential open SSH servers hanging on the internet, you have a big problem.
Robert Blumen 00:03:50 What would the attacker have been able to do if this attack had been distributed?
Luis RodrÌguez 00:03:56 As I mentioned, there was something like more than 20 million open SSH servers hanging on the internet. That means that bad actor has access to arbitrary commands of the selective targets. He could wreak havoc in a lot of places. The problem was contained, but it could be much worse than it was at the end. This is the ending of the thing, but the problem is that it opened a lot of can of worms. What happened if this is not the unique backdoor popular system in hanging on the internet? This is the, which we’re taking into account right now.
Robert Blumen 00:04:36 Now have raised a point that there could be other similar attacks that have not been detected. I do want to come back to that question, but before we go there, I’d like you to describe how the attack was detected.
Luis RodrÌguez 00:04:52 Passwords developer named Andres Freund, who detected a bad performance issue with the SSH server he was testing. He detected that logging took half a second, more than usual. So he decided to investigate, to perform some internal research on that. First, he extracted from the turbo, from the distribution turbo for the open SSH. He tried to look something there, but he found nothing, nothing relevant. He then performed some performance testing with the open SSH service, and he found that there was a library, which was LCMA library, which was acting as a CPU hook. And he made some debugging, and he detected that the library was doing something strange, which was modifying the system library and modifying the table for functions and injecting a different function, which was the pre authentication function that the SSH uses for validation of the public key presented by the client.
Luis RodrÌguez 00:06:01 He decided to look more in depth in the LMCA carbo, and he found that there was something strange with the build script that destructive from the testing files, which was highly obfuscated and was included in the build system, in the final binary for the LCMA library. That means that probably that was some strange thing, a malware, he did not perform a reverse engineering. He asked for help for others. They found that there was something that tried to open a system call for running the commands passed by the attacker in the payload in the communication payload. So this was clearly a backdoor, not for authentication with SSH, but for remote code execution, allowing the attacker to run arbitrary commands using the commands they decide on the vulnerable system.
Luis RodrÌguez 00:07:09 And it was also an attack that it was not replyable, and it was gated. That means that only the owner of the private key, the right private key, could make the backdoor run, otherwise the system work it as normal. It jumped to the normal crypto and exchange. So it was a passive backdoor, and this made impossible for normal detection tools. Unless the backdoor is really executed, no tool could detect that. It was there, was something strange on that, but it was amazing how by accident, by a performance problem, this could be detected by a person. Which he declared, he was not a security analyst. So I think we were lucky on this.
Robert Blumen 00:08:00 I need to discuss also in a bit later in the interview, the element of luck that was involved, and is that a good way to detect things? Before we get to that, you raised a couple of points that I want to come back to. In my reading about this, and I only know a little bit about C and I’m not involved with these security issues at all. But what struck me as hard to understand is SSH is the application. It uses libraries, which is how every program worked. Compression is a library that it calls upon to do some step in its process. So my question was, how could a library that you call insert a backdoor that affects the behavior at a much higher level of the stack? I think where you begin to answer that is there is a table that points to functions somewhere in the process, and that there isn’t any restriction that prevents a library from going and changing how this table works. Now, did I understand that correctly and can you say more about that?
Luis RodrÌguez 00:09:14 That’s a very good question and complex to explain. Okay. Open SSH does not link with this library with live LCMA library. It uses an SLib or JLib library, but it is optional. It is not even linked with many, many open SSH distributions. So, in fact, this is an option that is normally not enabled and never works in normal open SSH installations. But in some distros, patches were added which enable SSHD to inform the system, the service manager in many Linux systems, which is System D when it has finished starting up, okay? System D is a common Linux system and leave System D uses the XZ library. Okay. So the malicious leave the LCMA library, installs an audit hook into the dynamic linker waiting for a function name. I have a small check here is RSA public-key.
Luis RodrÌguez 00:10:24 This is the name of the function that is used by SSH to perform the initial re-authentication logic. So the malware through the system, the dependency managed to change dynamically the link to this function. So it works with the backdoor. Instead of running through the normal function, it run through the backdoor. The backdoor checks, simply key used to authenticate is the right one from the attacker, and then develops the payload to the system call, which runs an arbitrary command in the system. SSHD the server, the open SSH server normally runs with high privileges typically as root. So if you can execute the command as root, you are a king. So this is the reason why they looked for open SSH instead of running in the user space in the compressed library. And it was a very interesting way of, without having a direct link from SSH to the library, you can, in the library, you can manage to affect the third- party service at work. So this is the key of the of the attack.
Robert Blumen 00:11:51 When I have read about this, it reminded me of there are other attacks on the process runtime, and there have been efforts over time to restrict things. I don’t recall the name of this, but there was an attack where a function would be written into an area of heap, and something like what we’ve been talking about was used to get the execution to point into that function. So there were changes made in the runtime layout where certain areas or data only, and you simply could not execute those areas. The process would fail in some other runtimes, like a Java, you can have quite a high degree of security over what pieces of code have access to what parts of the runtime. Now, I don’t know the equivalent amount about C and we’ll talk more about remediation later, but, so we’re right on this. I wanted to ask, has there been any discussion or is this fixable in such a way to say, we can’t allow a library to have access to those function pointers, or is that just how this runtime works and it’s not fixable?
Luis RodrÌguez 00:13:05 Absolutely, it’s fixable. The problem is that the attackers made some changes that allow for the library to be able to perform this change of the symbol table allowing to inject the backdoor in the upper SSHD daemon. And this was fixed, but the idea was to add some kind of performance improvements, allowing to change functions using indirect functions — or ifunc for short. And this was added before the actual malware were injected by the bad actors. They have a plan, they decided to first allow in the library to perform this dynamic change of the functions in the via System D. And after that, they inserted, when they were aware that nobody was looking, they inserted the actual malware.
Robert Blumen 00:14:04 I see. That means they first disabled security feature that would’ve prevented the attack for completely different reasons. So they said, but their true reason was to prepare the groundwork for step two, which was the attack. Very clever. I think now, since we’re talking about, this might be a good time to talk more about the attacker, which is some kind of entity and is still mysterious. What is known about the attacker?
Luis RodrÌguez 00:14:38 One thing is to have evidence of who could be after the attack and other way is at attribution. Attribution is quite difficult now, but they will think here is that all the changes were done on a public repository, which is a GitHub version, which has also a copy in the, in the Git, Linux system for Git a mirror, and we can see exactly which actions were done by the bad actors after a fact. So there were two commit authors, mainly one named Jia Tan. Jian Tan is a common Chinese name, but forget about thinking that Jia Tan is Chinese, probably. And there was also one Hans Jansen. These two guys, they are actually personas. They are actually fake accounts. Weíre working accordingly to perform some activity first. This is a social engineering attack mainly. Because this Jia Tan made the neutral or innocuous commits for more than two years, since November 2021.
Luis RodrÌguez 00:15:52 He gained confidence from the maintainer, the innocent person here. So he was promoted as maintainer during June, September 2022. Another committer, this Hans Jansen, then made two key commits not malicious per se, but preparing the field, as you mentioned, for with this ifunc support, which opened the kit for the attack. There was also another fake identity, sock puppets like one named Jigar Karmer, Denis Sans. They were using ephemeral email systems. They just made some and sent some emails to the maintainer, to the project maintainer, and to the distribution, mainly lists, asking for readiness or pushing for the malicious turbos to be included in the distributions. These pressure emails were done by different person from the ones who were performing the commits in the repository. Those identities are really fake using disposable ephemeral emails I mentioned for social engineering.
Luis RodrÌguez 00:17:07 And no red flag was opened by the actions by the bad actors, because they worked very candidly without trying to make too much noise. Committers were even thanked by the poor maintainer for their commits. In retrospect, some distro maintainers show concern on the pressure emails received by these fake accounts for including the versions in the stable release. Probably the best mechanism for avoiding the worst problem was the slowly pace in which linear distributions work. First, when a new change is done, it enters the unstable or experimental distributions, and only after a third review, it passes to the stable ones. So obviously, you can have an install, an unstable version, I have myself, in fact because I need to be on the edge of the last versions, one thing is to have a malware in a normal distribution, in an unstable distribution and a different thing, a devilish thing is to have the malware in a stable distribution, which is much worse.
Luis RodrÌguez 00:18:19 So no red flags happened, and these two guys Jia Tan and Hans Jansen made the changes. And again, there were three stages, the attack. First, the neutral stage where Jia Tan made some contributions to the project and gained confidence from the main maintainer. They asked the maintainer to be maintainers, backup maintainers, which is a normal thing when you have done woodwork on a project, you can offer yourself as a new maintainer. They deceived the original maintainer, and he approved some accesses for Jia Tan particularly. So he made them sign the releases, which were taken by the Linux distributions for adding the library to their distributions. So one month before the day the attack was found, he made the final step, which was the attack.
Luis RodrÌguez 00:19:29 He changed in the turbo, not in the source repository, but in the turbo. He made a small change in the build file in one of the build file. And with that change, he makes the, when the period was compiled from the sources, the final binary included the backdoor. This was the last step, the attack step, okay? All they have to do is just wait for different distributions to get the, that is entered to get the distribution installed on the end points. And then they could choose which end points to attack, because they had the private key needed to perform the back door to run the back door.
Robert Blumen 00:20:15 Tell me about the attacker. Was there any additional forensic work done trying to locate who the attacker might be, based on any information contained in the commit?
Luis RodrÌguez 00:20:28 Yeah, after the fact, it’s quite easy to see exactly which were the commits. There are many commits, but most of them in the first stage were neutral. Only the commits I mentioned — the change by that Jansen enabling the ifunc capability and the final attacks from Jia Tan where he uploaded the new releases, the new malicious releases — were the key points. Later, there were some bugs when they using a tool called back green, because of the way the backdoor was injected, there was that some tools were bending the process. So they managed to fix some of the bugs after the malware were distributed in some unstable Linux distributions. They were checked because they are number, but not a big number of malicious commits. And after the fact, it was found exactly which were the things that there were clearly trying to maybe avoid detection, fixing bug to avoid detection or performing additional preparation steps for the attack.
Robert Blumen 00:21:46 Things like time zone, IP addresses. Were there any clues even indicating where this attacker might have been located?
Luis RodrÌguez 00:21:56 We have evidence, but no unquestionable attribution. First that Jia Tan used a VPN for access all the time. He used Singaporean IP address. That does not mean that he’s in Singapore of course. Regarding the time zone used in the commits and the work patterns, we have some ideas. They used UTC +8, which is the Chinese time zone, obviously. His name is Chinese, so he tried to deceive, but in fact, in some commits, probably he forgot to change the time zone, and he was using UTC+2 or +3, which is due to the summertime change, corresponds to Eastern Europe and Israel. Also it doesn’t mean that the guy, these guys are in Europe or Eastern Europe, or Israel. But it’s a nice, interesting evidence, okay?
Luis RodrÌguez 00:22:59 And obviously the working pattern, they work from 9:00 AM to 6:00 PM in that UTC+2 time zone, which resembles normal working hours, not nightly working. So all of these, they didn’t work on holidays; hackers, the bad guys, the financial-motivated bad guys normally work on holidays. Work whenever they want, and they use an irregular pattern. They are not using the working hours pattern. Commits were done on the Chinese holidays which for me is a clear sign this guy is not Chinese, okay? But not on Christmas, and Christianity New Year. So all this evidence accumulates to think that we are probably thinking about a bad actor, not a financial-motivated actor, but probably a state-backed actor, which was operating on this time zone.
Luis RodrÌguez 00:24:08 I don’t know the latitude, I know the longitude, not the latitude, but probably Eastern Europe is a clear candidate, and the most robust evidence comes from the techniques and the pattern itself. Passions, planning two years, more than two years planning. This is not a financial-motivated bad actor, which quickly runs for more money. This is probably the other kind of bad actors and I think about APTs or state-backed bad actors. The target is also not financially motivated actors. They are trying to get, obviously they can use a backdoor in SSH, but probably this is more for spyware, for extracting information, sensitive information from certain systems. So I think that this makes the, all the evidence accumulates on the APT candidate.
Robert Blumen 00:25:10 Okay. The ability to access SSH would be only a step towards some other type of attack. So where do you see them going with this, if they were able to get it in place?
Luis RodrÌguez 00:25:25 Probably, I think they are trying to use a surgical backdoor. It’s not an attack. They injected, I mentioned 23 million openness, potential installations. Not all were affected because there was a need of different environmental conditions where need to meet for the attacker to be able to be executed. But they have a lot of servers where they could use the backdoor. And I think that probably the surgical attack to selective targets would be the reason behind the attack. Which ones? I don’t know, mainly Microsoft, who knows?
Robert Blumen 00:26:14 Now, SSH logs, whenever somebody authenticates, many security systems would monitor these logs looking for unusual authentications. If it had gone into the wild, could it have been detected through log analysis,
Luis RodrÌguez 00:26:31 Through logs? No way. Because the back door was not doing anything in the authentication phase. It was simply diverting the authentication and it was running the back door, which means that you will not find any failure authentication in the locks. You understand?
Robert Blumen 00:26:52 There is no, yes. Got it. Okay.
Luis RodrÌguez 00:26:53 No trace on the locks, so no wave. It could be detected but using a different approach.
Robert Blumen 00:27:01 Now, we’ve been talking a bit about how it was detected, how it could have been detected. Has there been any discussion in the community about is there a better way for the community to distinguish between real people and fake entities that are cutouts?
Luis RodrÌguez 00:27:20 You hit the nail, this is the common problem with open-source. In open-source, you can even be totally anonymous. If you make a good contribution to an open-source project, you are welcome. And there is no betting, there is no list in general, you can perform your activity from a VPN, hide your identity, totally using names and you are welcome. This is a problem with open-source obviously, and in the private sector this is not reasonable, but in open-source, that was the way of working up to now. And the change, this is almost impossible. So maybe we have to, for example, the problem here was a small change in the build, in the turbo, which was released for distributions to perform the compiling, so maybe this is the point where it could be detected, but this is also very difficult because as you know, the turbo has all the source code, but the compilation is quite complex, quite difficult. And it’s difficult to have an automated system to understand if there is a difference between the expected output of the compilation and the real one.
Luis RodrÌguez 00:28:40 The first C compiler can follow, it made some hints and on this, and how can I trust the C compiler? How can I trust the tools that make other tools? This is a complex problem, and it is an unsolved problem for now. Of course you can have two different compilations, one with one system and one with other, and you can compare if the results are the same. Which is in this dual compilation with different build systems. Probably you can catch a difference in between the two because for this backdoor to be enabled, you need a particular environment in the build. The problem is that compilation is not repeatable. And you can compile even with the same environment, the same source code, and get different non-binary compliant output. So it’s quite difficult to do this. This, for example, for the SolarWinds build system, they try to change this and do a one automatic build and one automatic build and compare the two outputs to check if there are any difference. So if someone can change source code in the build process, that could be detected. The problem is that it’s not easy because of their repeatability problem I mentioned.
Robert Blumen 00:30:07 What you’re talking about now is a way that it could have been detected. We talked a little earlier about a degree of luck in that someone who’s not a security specialist was doggedly determined to get to the bottom of this performance issue, and he knew enough to call in other experts when he saw something that shouldn’t be there. You also mentioned that my idea of checking logs does not work. What are some other ways this might have been detected, or in a more general principle, how could this type of thing be detected?
Luis RodrÌguez 00:30:48 First of all, after the fact detection is easy. Really, there are now Java rules for command line tools and a lot of tools for detecting. For example, there are some program capabilities analyzers. There is one from chainwork, you name being capped. There is also a tool named binary, which provide detection rules for this particular malware. The problem is that they cannot detect it before they are instructed to do so. They cannot detect preventively. There are also different kind of tools which are runtime monitoring tools, which baseline the behavior of the programs and libraries and report on deviations from the normal behavior they’ve learned. This might detect exploitation right after it runs. The problem with this backdoor is that unless there is a real backdoor attack, you don’t see any change in the normal behavior of the SSHD daemon.
Luis RodrÌguez 00:31:50 So this makes even for these tools quite difficult to do that. In fact, there was no known evidence of real attack using this backdoor because it was removed quite promptly from the releases. But even if this exploitation happens, these tools may detect that because they will see a system call, which was not before in the normal learned behavior, and they can’t report this as an unusual activity. So the problem with this is that you have to instrument the end systems. You don’t detect the problem at the source. You detect them at the end systems, you can detect it, and at the end systems. Obviously if the end systems report them to a threat modeling tool, which gathers information from multiple sites, they could detect. This is what happens for example with tools like the ones from CrowdStrike, another tool vendor. And they could detect that there is an ongoing attack using this SSHD.
Luis RodrÌguez 00:32:55 But this is after the malware enters the victims, the end victims, okay? So this is not also the perfect thing for detection, obviously detecting this, the bad commits in the source would be the best, but it’s quite difficult. Because you trust the contributors if they are find and it’s quite difficult if they use their magic, they can hide, for example, in this case, the backdoor was inserted in a test file. In a test compressed file because this is a compression library. So the binary containing the actual malware, the actual back door was in a test file and nobody opens a compressed test file to check if there is something strange there. It’s quite difficult to detect.
Robert Blumen 00:33:46 You’re not giving me a lot of confidence that it would’ve been rapidly detected. That raises a question that you raised earlier, and I promise to come back to this. Surely people must now be asking how many more similar, not necessarily attacks on SSH, but equally severe attacks that we don’t know about because we didn’t have some good luck of person noticing an anomaly and then unraveling the code changes, which led to that.
Luis RodrÌguez 00:34:18 There are more Jia Tans out there. Now this is for sure, which projects I don’t know. There are some projects under review, for example, only projects that are using ifunc are being under review because this was the vector, the bad actors used for this attack. But obviously they can use other techniques which are not known for now. And obviously it’s quite difficult to prevent malicious activity when it’s done by actors that take the patience in the qualification for the attack. So, I have not answered your question. I don’t know. In fact I don’t know if there are more Jia Tans out there working, making their magic on other popular point.
Robert Blumen 00:35:08 This next question we may have covered to some extent, but anything about lessons learned that we have not yet covered?
Luis RodrÌguez 00:35:17 Well, we talked about how hard it is to prevent these intentional back doors because they are done with by knowledge people, not street kiddies, which was known as a street kiddies when I they were young. Some authors pointed at System D, you know, the System D is the bridge between the two libraries, the SSH library, the SSH executable and the compression library that was attacked. This popular service manager opens a large attack surface, third-party services for backdoor. This is what bad actor used and System D has many eyeballs on it, but this in obscure library up the chain can poison all the water down downstream. This was a wake-up call for other projects that depends on System D to check exactly which kind of back doors could be inserted using this bridge library.
Luis RodrÌguez 00:36:18 The System D, for example, immediately after the attack was uncovered, there was a request on the XZ library for removing the ifunc support. And this was also a change in System D to avoid using libraries. For example, the promise that System D uses XZ library and is not related to the attack, but what is the reason for System D to use this library is nonsense. So they are skimming, eliminating all the spurious dependencies to keep and clean the main, an important element like System D. This is another learned lesson, okay? And probably the root cause with open-source security issues is probably the accessorís task. I mentioned that this is the way open-source projects was evolved in the past, but this is getting a deep review now because obviously, important projects need much more control on which person makes which changes.
Luis RodrÌguez 00:37:30 And this probably will change a bit. How open-source projects in the Linus ecosystem and other ecosystems are done in the open-source community. The problem is how maintainers get remunerated by their hard work if they are working as volunteers. There are some ideas on how to finance by the private sector, by the government, the open-source of efforts. And I think this could be another good thing and use also a different approach. I mentioned that probably the attack could be detected if there was a mechanism to detect problems in the build that lead to a different binary from the one produced by the pure sources.
Robert Blumen 00:38:17 You mentioned that the exploit was in a test file that was included in the final distribution artifact. That also sounds odd to me. If I am running a Linux system and I want to run SSHD, I should not need any of the test files in my distribution. First am I correct about this and is that another avenue of improvement?
Luis RodrÌguez 00:38:44 No, the problem is that in the tar ball, you have the source code in the test files because when you run, you run also the tests. When you make the build, you run the test to check that the system build is correct. So, obviously the test files need to be there in the source tar ball, which is compiled by the distributions. It’s difficult if you cannot get rid of the test files. And obviously if the test files are removed, probably the bad guys will find another place to put the malware. So it’s not the, I think it’s not the issue.
Robert Blumen 00:39:21 We’re getting close to end of time. Something I’d like your opinion on is, had this exploit been released in the wild, how would you rank it compared to some of the more well-known open-source attacks that have occurred in the last few years?
Luis RodrÌguez 00:39:36 Well, I think it is five, not 10. The CVSS score, when the CVAE was opened by Red Hat, it was given a 10. 10 is apocalyptic. In the past there was some 10s also, for example, like well-known Log4j issue received a 10. But the problem there is that it was completely open and there was a lot of, every single 2.X version of Log4j was vulnerable. So the problem was huge. Here, the problem was much more contained because it affected only a few distributions, not all the distributions. For example, open-source Debian, RC Linux, and Fedora from Red Hat. Not the small distributions, also Kali Linux. Kali Linux, which is used by pen testers is the distribution was choice for pen testers was affected. Interesting.
Luis RodrÌguez 00:40:43 But for example, Debian stable or Ubuntu or many other distributions, commercial ones and so on, were not affected. So I give five. The attack is serious because if it could, really get open access. The problem is that as this is a back door that makes no noise, it could, left the time between the introduction and the detection could range in the years. Perhaps the risk was high, was enormous, but it was contained quickly. So for me, it’s a five, not a 10. Thank God, and thanks to Andrew Freudian, we all free for him for years.
Robert Blumen 00:41:32 As we come to a close, were there any aspects of this issue that we have not covered that you’d like to highlight?
Luis RodrÌguez 00:41:40 I think we’ve covered a lot of things. From the detection, from the how the attackers work. They used a social engineering attack. This is the key idea because if introducing the malware, they need rights to perform changes and to release the distributions. So social engineering is the big deal for many attacks in the supply chain part of the equation. So I think this is interesting to understand how the attackers work, how they gain confidence, how they exploit the different, the combination of techniques they used is interesting because with this information we can prevent in the future similar attacks. I think this is the main benefit for this knowledge, for this attack.
Robert Blumen 00:42:31 I did forget to mention that much of this conversation was based on an article that you wrote on the Xygeni blog on the issue that will be linked in the show notes. Is there anywhere else you’d like people to find you on the internet?
Luis RodrÌguez 00:42:47 Well, I have a LinkedIn account. If you want, you can reach me by email. My email is [email protected].
Robert Blumen 00:42:59 It’s been a pleasure speaking with you. Thank you very much for speaking to Software Engineering Radio.
Luis RodrÌguez 00:43:04 Thank you very much Robert. The pleasure was mine.
Robert Blumen 00:43:08 For Software Engineering Radio, this is Robert Blumen. Thank you for listening.
[End of Audio]
