BTS #58 - UEFI Vulnerabilities and Hardware Risks
In this episode, the hosts discuss various cybersecurity topics, focusing on hardware vulnerabilities, UEFI attack vectors, and the implications of new regulations on device security. They explore the evolution of Mirai variants targeting IoT devices and the challenges of securing firmware. The conversation highlights the need for improved security measures and the complexities of managing vulnerabilities in a rapidly changing technological landscape.
Subscribe
Transcript
Paul Asadoorian (00:01.637) Oh, knock on wood, I haven’t gotten the error. Usually it’s like, oh, there was an error. And I’m like, okay, well, like what was the error? And it’s like, I don’t know, there was just an error. It’s kind of like when I was doing OS2 Warp administration and be like, there’s an error and it’s this code 2701. I’m like, okay, what’s error code 2701? It’s like, oh, an error has occurred. Please contact your systems administrator. I’m like, but I am the systems administrator. That’s not helpful. Vlad is here, yay.
What’s up Vlad?
Vlad Babkin (00:35.439) Hello.
Chase Snyder (00:36.76) Just in time to party.
Paul Asadoorian (00:38.467) Just in time.
Chase Snyder (00:41.432) Just in time to party, which is what I call going live on LinkedIn.
Paul Asadoorian (00:45.317) on a podcast on LinkedIn, YouTube, Twitter. There’s an internal streaming link too. You should utilize that.
let’s see, where am I? there they are. Yay, got them.
Chase Snyder (01:07.406) watching some videos recently lectures where this guy has a like an electronic whiteboard and I was like that is cool I want that I would replace the stuff behind me with that so I could draw and you can out different colors and it’ll like save frames so you can like clear to a blank frame but then go back to what you had up there before it’s like oh this is an incredible tool but they are expensive turns out
Paul Asadoorian (01:13.998) Yeah.
Paul Asadoorian (01:23.224) Yeah.
Yeah.
Paul Asadoorian (01:35.429) I’d imagine rapid seven rapid seven used to do that. I don’t know if it was a digital whiteboard, but they called it whiteboard Wednesdays and they would do a series. did a series of videos. I don’t know they still do it anymore. This was years ago and it was called whiteboard Wednesdays and it was random. I don’t know if it was random people or slack people from rapid seven. They would just whiteboard out stuff.
Chase Snyder (01:40.622) Mmm.
Chase Snyder (01:47.331) Yeah.
Chase Snyder (01:58.402) Yeah, we used to do something similar at Extra Hop with a light board, which is like a clear glass and you use these fluorescent whiteboard markers. And then you, don’t know if you have to blacklight it or what, but they show up super bright. So it’s like, you’re just hovering there in like dark space and then you write on it and it’s super bright. Very satisfying to do, but…
Paul Asadoorian (02:03.853) Yes.
Paul Asadoorian (02:10.883) Yes, you know it.
Paul Asadoorian (02:25.637) Mmm.
Chase Snyder (02:27.79) cleaning the glass afterwards, like you have to get it super clean because you know how stuff shows up in a black light, so it’s like any little lint on there just like…
Paul Asadoorian (02:31.661) Yeah, right.
Paul Asadoorian (02:41.411) Maybe we’ll get back to it. All right, but now we’re gonna do blow the surface everyone ready
All right, here we go.
This week, UEFI settings and burning down the house, old vulnerabilities, and a life devices static tundra, a new Mirai variant with a name that we’re just gonna rename for the sake of the show. Stay tuned below the surface, coming up next.
Paul Asadoorian (03:09.037) Welcome to Below the Surface. It’s episode number 58 being recorded on Wednesday, August 27th, 2025. Of course, your host, Paul Sidorian, joined by Mr. Chase Snyder. Chase, welcome.
Chase Snyder (03:20.888) Hey Paul, hey Vlad.
Paul Asadoorian (03:23.193) Vlad Bapkin’s here too. Vlad, welcome.
Vlad Babkin (03:26.053) Hello.
Paul Asadoorian (03:27.503) Thank you so much for joining me today. I’m looking forward to the topics we have. Before we dig into it, below the surface listeners can learn more about Eclipseum by visiting Eclipseum.com forward slash go. There you’ll find the ultimate guide to supply chain security, an on-demand webinar I presented called Unraveling Digital Supply Chain Threats and Risk, a paper on the relationship between ransomware and the supply chain, and a customer case study with DigitalOcean. If you’re interested in seeing the product in action, you can sign up for a demo, all that.
at Eclipseum.com forward slash go. I think we want to talk about CPUs and hardware melting down as a result of you EFI settings. If you are a customer of ASRock specifically, although this is not specifically an AMD problem, it also affects Intel historically. However, the Tom’s Hardware did a great job of covering this. They have three articles I’ll put in the show notes.
so you can follow along at home. basically what I surmise from reading all of this is that, and I’m not sure where the BIOS manufacturer comes in, and I’m not sure who, whether it was AMI, Insight, or Phoenix in this case. Are there other ones other than those three? Anyway, that’s a tangent for another time. because we talked about this with Brian Mullen on the show. So, know, Intel and AMD.
have their parameters like, if you’re gonna build a platform that includes our processor, like here’s the stuff. And then, know, AMI and Phoenix and Insider like, well, we can make a BIOS, UEFI BIOS for that. And like, here’s the stuff. And then it gets to an OEM, in this case, ASRock, right? Primarily motherboard manufacturer goes, okay, I’ll take all of that and I’ll design my system and the UEFI within those specifications and add on my…
customized stuff, as it were, inside of UEFI. What we believe is happening is that ASRock, and they’re not the only ones to have ever done this either, have deviated from the recommendations or made design decisions and implemented them in such a way that the hardware then runs out of spec based on the UEFI settings. Those of you that have done any PC building or gaming know that when you build a system, you…
Paul Asadoorian (05:51.119) typically go into UEFI when you first build it, you get that first power on, you do a happy dance, you go into UEFI after your happy dance, and you start setting some settings. Now those of you that remember overclocking and all that kind of stuff, that’s where you can tune the CPU clock frequencies, you can tune the memory and other parameters. Now hopefully, what we hope is that within those parameters that have been set by the OEM,
that you can’t step outside into a perimeter that would be dangerous to your system. I overclockers have experienced system crashes, because in my opinion, there should be, and I believe there are safeguards, not just the parameter, like not letting you set a high enough voltage to cause any kind of adverse effect, but also physical safeguards that don’t let components melt down. We talked about this in the context of printers several years ago.
There’s physical safeguards that prevent things from catching on fire. That’s why we have things like UL and the like. However, in this somewhat unique case, people experienced actual meltdowns of, I believe they’re CPUs and like melting in the CPU socket, which then, I mean, you got to throw it away and start over at that point. What’s your guys take on these hardware issues?
Vlad Babkin (07:14.469) it’s not new. Like if you look at older hardware that was very common. Like modern CPU mostly have a lot of safeguards against that, but go back quite a few generations and you will find CPUs which don’t. And moreover we have seen something similar researched very fairly recently, I believe like 2023.
Paul Asadoorian (07:22.052) Mmm.
Vlad Babkin (07:35.749) I believe it was called PM fault. So there were people who were actually doing overvolting of Xeon from BMCs as an exploit and they set its voltage to 2.7, which is normal voltage, which 1.3 just in case. That’s quite a few more volts than it is expecting and the CPU was being fried from that. this aside from being a…
Paul Asadoorian (07:47.844) Mm-hmm.
Paul Asadoorian (07:53.347) Yeah.
Vlad Babkin (08:03.749) Oh hey, customers are being dumb and reconfiguring UFI. It’s also an attack surface where customers might not even be dumb, but attackers might want to fry their hardware.
Paul Asadoorian (08:15.17) Yeah, that’s where my brain was going after I read these articles that I was like, wait, so that means that an attacker that can control UEFI could potentially cause adverse effects on the system in a physical sense. I’m just like, I wonder what other safeguards may exist for that. Or is it really just a UEFI NV RAM variable that gets read that says set the voltage to this, right? It has to be some kind of setting that’s saved somewhere, right?
Vlad Babkin (08:43.501) Yep, it’s probably a setting. I mean, if it is accessible by BMC and UFI alike, it must be a setting. And you can in fact over-vault your CPU because normally it’s locked behind quite a few places so that you don’t normally over-vault it, but you have access to all of that. Moreover, you have access to this from user-land in some cases. Like, yeah, it’s…
Paul Asadoorian (08:51.225) Mm-hmm.
Paul Asadoorian (09:00.461) Yeah.
Paul Asadoorian (09:06.672) Right, so some of these settings can be changed from user land to allow utilities, right? The motherboard manufacturer makes a utility that’s called a tweaker or even in some of the BIOS it’s AI tweaker or something like that that allows you to change those settings.
Vlad Babkin (09:11.543) Yeah, in this case, Yeah.
YAH!
Chase Snyder (09:23.52) If you said the phrase AI tweaker to me, that’s not the first thing I would think.
Paul Asadoorian (09:26.564) I know, right? I always thought that was a strange way of presenting it, sorry, go ahead, Vlad.
Vlad Babkin (09:30.521) Yeah, AI tweaker is ASUS stuff. In this case, there’s also stuff like Intel XTU, like Extreme Tweaking Utility. I have no idea what it’s called for AMD, just in case. But they probably have something equivalent. And in this case, those utilities do have access to added voltages as well. Again, on certain motherboards under certain conditions. So it does go through UEFI probably as well, or maybe something like… What are those tables called?
Paul Asadoorian (09:41.837) Yeah, yeah.
Vlad Babkin (10:00.495) There’s some BIOS stuff
Paul Asadoorian (10:01.124) ACPI tables?
Vlad Babkin (10:03.861) yeah like they probably access some calls on the motherboard itself instead of doing it directly so
Paul Asadoorian (10:11.138) Yeah, it’s interesting where the safeguards exist and how they can be bypassed. I don’t think we have a blanket thing that says anyone in control of UEFI can potentially fry hardware or can fry hardware. I gotta imagine there’s safeguards. I don’t know. I guess when you’re initializing the hardware, all bets are off. It’s gotta rely on a setting that lives somewhere controlled by something. They can always be bypassed.
Vlad Babkin (10:39.714) Yeah, like CPU can’t really do anything because like imagine that you connected it to stuff and motherboard is just suddenly reconfigured to supply it a lot of volts. So CPU cannot really protect itself in this case.
Paul Asadoorian (10:54.262) Yeah, can’t, can’t, it has to accept whatever voltage, the components have to accept whatever voltage is coming from the motherboard is what you’re saying, Vlad. Yeah. Right.
Vlad Babkin (11:02.166) It’s like physically, yeah, they cannot disconnect magically. So in this case, if motherboard allows to override this with EFI access, it might be an attacked vector nobody really thought about yet, and it might even be applicable everywhere.
Paul Asadoorian (11:16.322) Yeah. Well, that’s my fear is that, you know, obviously we’ve covered in the history of our company and the history of cybersecurity, there’s a lot of attacks against UEFI. We cover new ones all the time. And, you know, an attacker that can live in UEFI can bypass any other controls or protections that you might get when you go into your bio screen and you’re presented with those options.
I feel like that software could say, hey, you can’t set the voltage outside of this range. However, an attacker that has access to UEFI is not constrained by that interface that the user would see to log into their BIOS. The attacker can set settings conceivably to whatever they want. Depending on how deep into UEFI, right, there’s different levels of attacks, right?
Chase Snyder (12:06.2) Here’s, okay, has there, I’m trying to think of like a real world attack that’s happened where a physical consequence was like the goal or a fundamental part of it and Stuxnet is the one that I can ever come up with. Not that there wouldn’t be another one, but.
Paul Asadoorian (12:22.5) Stuxnet’s a good one. Yeah, was it WannaCry? Not Petya. It was not Petya. But not Petya, the Russian threat actors turned the lights off in the control room in conjunction with a cyber attack. That’s the other example that I don’t know why that always sticks out in my mind is like doing things in the physical world in conjunction with the cyber.
Chase Snyder (12:29.581) Yeah.
Vlad Babkin (12:29.636) Not Peter.
Vlad Babkin (12:40.622) Yeah,
Chase Snyder (12:40.77) Okay.
Vlad Babkin (12:45.504) NotPetya was a massive show in Ukraine where a lot of systems just died because of this. So it was a destruction malware that was masqueraded as crypto extortion stuff. Yeah, and it pretty much killed a lot of banks and whatnot outside of everything else. So there was quite a few physical consequences. In this case though, it was not really targeting hardware destruction. It was targeting more… Yeah, it was trying to wipe the data.
Chase Snyder (12:47.17) Yeah.
Paul Asadoorian (12:52.9) Mm-hmm.
Paul Asadoorian (12:58.916) of ransomware. Yeah, yep.
Paul Asadoorian (13:10.882) It was just wiping the discs, right?
Vlad Babkin (13:15.918) So to be honest, what we haven’t seen for sure is people trying to attack the user from those attacks. We have seen people try to destroy hardware, try to destroy software and data, but I don’t think we ever saw attacks against users. Not sure if it is even possible, but…
Chase Snyder (13:16.215) Yeah.
Chase Snyder (13:34.35) I mean, when you say users, when you say they’ve been attacks where they tried to destroy hardware, that’s more what I’m talking about. I don’t mean like trying to cause harm to the end user. I mean, trying to make the hardware unusable as part of the attack chain. And there’s all this discussion, like geopolitically, there’s this unclear line of at what point a cyber attack becomes an act of war or the sort of boundary between a cyber and a kinetic.
Vlad Babkin (13:42.446) Mm-hmm.
Yeah.
Chase Snyder (14:03.042) like what sort of cyber attack would warrant a kinetic response. And I don’t know, my sense is that on one hand, this is an interesting case and it would open up the possibility of hardware destruction to a way bigger audience, because it’s easier to pwn UEFI and do this than it is to build a custom Stuxnet type thing. But on the other hand, I’m like, it seems like…
Most attackers would not use this in the course of normal events for their, it wouldn’t fit their desired outcome very well.
Vlad Babkin (14:39.224) Yeah.
Paul Asadoorian (14:39.48) Yeah, I think though it would, Vlad to your point, like would the user succumb to any harm? It would think the computer shuts down before like the flames start shooting out of your computer, right? Like maybe it can’t protect itself from the voltage, but all the safeguards on the system, your system just ends up shutting down at some point before like a blazing fire can engulf your PC, right?
Vlad Babkin (14:54.466) I mean…
Vlad Babkin (15:01.763) I mean…
Vlad Babkin (15:05.22) Yeah, you can try to put PC on fire, there is also, at the very least, is a power brick, or whatever you call it in the PC, power supply unit, which can be exploded if properly exploited. If you can get access to its firmware, it can be very fun. Then there is also attacks against certain health conditions, which might occur, like make a lot of blinking lights come out from computer monitor.
Paul Asadoorian (15:14.595) Yeah.
Paul Asadoorian (15:21.271) Yeah, yup.
Right.
Vlad Babkin (15:33.816) Might not be very fun for some people. But other than that, I don’t really see any other avenues right now. Hopefully nobody takes those as ideas, just in case.
Paul Asadoorian (15:34.061) Right, right, right.
Paul Asadoorian (15:42.476) Yeah, exactly. Hopefully threat actors aren’t looking to physically destroy systems.
Vlad Babkin (15:48.728) Yeah, threat actors for the most part are interested in earning money. Physical destruction very rarely earns money.
Paul Asadoorian (15:52.995) Yeah, or stealing intellectual property, lurking. Yeah, it’s usually not like the norm to physically destroy systems. And there have been instances of that, of course, but it’s usually not the end result the attacker is looking for because they can profit more and achieve their goals better if the computer and the network is up and running, right?
Vlad Babkin (15:58.798) Mm-hmm.
Vlad Babkin (16:06.446) Yeah. Yeah.
Yeah
Vlad Babkin (16:20.226) Yeah, there is also like, you know…
So attackers normally want money. So to earn money you have to either extort the user or harvest their personal information or harvest something the user owns. So most of the time attacker wants to be unseen as long as possible.
Chase Snyder (16:42.702) It can be done as like a diversion. I don’t know. This is all very speculative.
Vlad Babkin (16:45.292) Yeah, and to the point of, by the way, kinetic response. How do you attribute the attack reliably enough to actually warrant one? Like, okay, let’s say I want to make it look like Chinese guys attacked US. I would find a proxy in China and do my nefarious stuff directly from that. Right? And now… Yeah, and then, if I would be incredibly evil…
Paul Asadoorian (16:46.039) It could be, yes.
Paul Asadoorian (16:55.288) That’s the problem.
Chase Snyder (16:55.64) Sure.
Chase Snyder (17:07.746) Yeah, of course. Attribution, whole other rabbit hole.
Paul Asadoorian (17:10.84) Yep, still hard.
Vlad Babkin (17:15.298) I would probably try to break into some institution, then proxies through something else, and then get to US, so that if you trace it back just to the institution, you would think, it’s China. While in reality, it might be somebody else. So there is a lot of possibilities for nefariously trying to flag somebody else for your attack.
So, like there is all other rabbit hole of just picking the right target to shoot.
Paul Asadoorian (17:38.17) Yeah, and right. Well, it’s interesting we talk about attribution and it gets us to static Tundra, which was disclosed by Cisco Talos threat advisory about a week ago and static Tundra is attributed to Russian state sponsored cyber espionage group linked to the FSB Center 16 unit, which just sounds really fancy to say out loud actually.
The group has been observed exploiting the seven-year-old vulnerability CVE-2018-071, which is part of Cisco’s smart install feature that believe listens on a particular port, which I don’t have handy, but that is a remote code execution that when I did a little digging,
Two years ago, someone posted an exploit on GitHub for it. So again, like not recent, it didn’t come out when I believe a proof of concept was published closer to when the advisory came out in 2018. I found one that was published about two years ago. I did not test it, by the way. So that link ends up in the show notes. Just when you, if you click that link and run that code, like you’re on your own, don’t come to me. If that code does anything it should not do, or you’re not anticipating.
Chase Snyder (19:00.866) You
Chase Snyder (19:04.748) blanket disclaimer.
Paul Asadoorian (19:06.149) Yeah, make sure you read the exploit and understand it. And totally that’s a great use case for an LLM. Like, hey, here’s an exploit. Can you just go through that and like tell me all about it and tell me is there anything I should be concerned about? LLMs do a decent job of that. Although if the LLM hallucinates and goes, no, that’s not malicious. also you’ve also got to understand when you’re running exploits, if you don’t understand them, it could be a bad day.
Vlad Babkin (19:23.704) No. It’s… That’s not even the worst case scenario. Attacker might actually make an evil exploit which exploits you and put instructions for your LLM not to notice inside of it. So if you just use LLM to analyze it, it might be incredibly funny. So my recommendation is to turn the exploit on your own instead of relying on LLM.
Paul Asadoorian (19:36.549) Mm-hmm.
Yes, exactly, that’s great. Right.
Well, it’s kind of like a, yeah, yeah, yeah. No, completely agree. I mean, we see lots of malware that has anti-sandboxing features, know, sandbox detection and anti-forensics built into it as well. And you’re totally right. You can’t rely solely on an LM for that. So there is an exploit for it. It is remote. Again, I haven’t tested it. So that was the initial.
they believe the initial vector was that exploit, then the persistence was the 2015 sinful knock. Now, there’s a couple of interesting things about sinful knock. One, it works from what I could tell by reading about it is that it replaces Cisco iOS’s image, the actual firmware image running on the device. Now, I haven’t dug in
I didn’t dig into this part of it, but when I was researching it, I was like, how did they get around the signature validation? I know there’s most Cisco devices from previous research I’ve done indicate that there is some type of signature validation. Now there have been vulnerabilities that have allowed attackers to bypass signature validation on Cisco devices. So I don’t know if that’s in play. I don’t know how that works. I don’t know why these devices aren’t.
Paul Asadoorian (21:07.908) doing a validation on the firmware going, hey, that’s not a valid image because it contains a backdoor. It’s basically a port knocking backdoor. What was the one for Juniper that was a port knocking backdoor? I can’t remember the name of it. I meant to put it in the show notes. But there was one that they found on Juniper routers and then you trace it back to like a 1999 frac article that was a backdoor that also does port knocking. I can’t remember the name, but we covered it on the show.
Chase Snyder (21:36.95) tiny shell? Was it the tiny shell thing? Yeah.
Vlad Babkin (21:37.284) Amen.
Paul Asadoorian (21:37.987) Yeah, well there was Tiny Shell, but what was the one before Tiny Shell? It was before Tiny Shell. It was right before Tiny Shell. I think we built a detection for it, in fact. I think we built a generic detection for it to detect it on multiple platforms because it’s very portable code. It’s basically just Linux code. Yeah, it was Jmagic, thank you. It was a Jmagic backdoor. Very similar to that. In reading about Sinful Knock, Jmagic.
Chase Snyder (21:43.022) yeah.
Chase Snyder (21:54.552) J magic, J magic. Yeah.
Paul Asadoorian (22:03.522) very similar in terms of port knocking, right? Sending packets and then the malware is looking inside those packets for certain things and that’s how it’s doing the remote access. And so basically if you port knock, it gives you a telnet access to the device with a specific password. Now I thought, I did think that that was black hat research. That was not presented at black hat. When I researched this for the show, I did not find sinful knock being presented at black hat.
And I created a lot of LLMs and Google and it was not it was a before Mandiant was bought by Google It was fire eyes Mandiant, right? Because they were fire eyes. So fire eye Mandiant discovered the back door likely one of Mandiant’s Incident response investigations. It was like hey, look at that. Here’s a back door And so that’s interesting so the put the exploit code was never public but now that makes sense
Because it wasn’t a researcher that published it. Threat actors had this back door. The threat actors actually developed this back door. It was discovered by Mandiant. Okay, I answered my own questions in my head. So that makes sense. So that’s why you were not going to find it. So it was probably traded around amongst threat actors and apparently still in play today. Now the other interesting thing about Static Tundra
is it was being observed as targeting organizations in telecommunications, higher education, and manufacturing sectors. I think that in respects to telecommunications and higher education, they’re more likely to have a larger set of infrastructure of Cisco routers that are more likely to be exposed to the internet succumbing to these attacks. Manufacturing is kind of interesting, but when you think I worked in higher education, we had a lot of Cisco routers.
for all of our network infrastructure, so, and telecommunications as well, right? And some of these are Cisco iOS XE, right, which is very large kind of ISP provider level gear. So it’s not, I think that their targeting is partly because that’s where these devices happen to be, not so much that they were targeting telecommunications companies, unless they were, and that’s the logical point in which they were gonna attack.
Chase Snyder (24:29.272) likelihood of those those types of organizations having the end-of-life stuff too like the you know higher education particularly I would guess is not doing a really aggressive refresh cycle on their stuff you know they’re making it last for as long as possible I know manufacturing frequently does tries to make things last as long as possible more in the operational technology industrial control systems because you don’t want to pause the production line to replace gear but I would guess that
Paul Asadoorian (24:33.827) Mm-hmm.
Paul Asadoorian (24:41.859) Mm-hmm.
Paul Asadoorian (24:52.068) Yeah.
Chase Snyder (24:58.222) a similar heuristic would apply in manufacturing where it’s like they don’t want to replace the gear, it’s costly to do, and it might turn off the manufacturing line, which is the money printer. So any downtime is unacceptable in those scenarios.
Paul Asadoorian (25:13.081) Well, mean, downtime is hard in telecommunications and higher education too. I mean, I live that in higher education. You know, I’ve talked about it in my years of podcasting, right? But, you I was part of the network security team, worked very closely with the actual network team that was deploying and maintaining all of the network gear across a 500 acre campus. And it’s, you know, you can’t just willy nilly upgrade things. I mean, a lot of times,
Chase Snyder (25:16.248) Sure.
Paul Asadoorian (25:43.107) we were pinned, so I’ll give you an example. We sometimes were pinned on a particular version of Cisco software on a particular device that we may have had thousands of because the previous version introduced a bug. The version we’re on fixed that bug, but the next version introduced another potential bug, right? So we’re like, okay, we have to stay on this version because of all those features and bugs. So.
And then the act of upgrading it, the second thing is the act of upgrading it causes downtime. And then once you upgrade it, then if there’s a problem, then you’re troubleshooting it. And I lived that. I was there when that would happen. Because I would get called in. It’s kind of fun. I would get called in. Is this a cyber attack? And I’m like, wait, no, wait, what did you do? Did you upgrade that device? Like that device is acting funny. Like, Paul, what’s your packet captures telling you? Like, this looks like it’s just a networking, like some kind of bug.
versus a cyber, and sometimes it was a cyber attack, don’t get me wrong. So that was, it was hard to upgrade those devices is the point of that story.
Vlad Babkin (26:53.869) Yup, SS-PL
Paul Asadoorian (26:54.179) And therefore as an attacker, right? That’s what you want to go after. you’ve got this gear. It’s older. It’s vulnerable. End of life. Maybe you’re not getting newer updates. It’s hanging out.
Vlad Babkin (26:57.805) Mm-hmm.
Vlad Babkin (27:05.159) signature validation don’t glorify it too much. If signature validation happens not during boot time but during upgrade time, which is what’s normal, then if you get some code execution and you implant some files, the signature validation is not going to be able to catch them. It gets even worse because if you think about it, what do you validate the signature with? There must be some…
Paul Asadoorian (27:22.213) Wow, right.
Paul Asadoorian (27:28.773) I would think it’s the boot. So I feel like we’re in class now and Vlad’s the instructor and I’m the student and I’m like, ooh, ooh, ooh, me. I think that the bootloader should validate the firmware, right? Isn’t that how it works in a lot of other systems? It’s how it works.
Vlad Babkin (27:39.915) Yeah, but what if attacker… Yeah, but if attacker actually has root access to the device already, he can replace the bootloader. And pretty much kills validation there, and it’s just a… …brave hole, like from there. So the only path to have it is to have some place which cannot be patched ever by software, which does the root of trust checks. But then should you find a vulnerability in that place…
Paul Asadoorian (28:03.724) Mm-hmm.
Vlad Babkin (28:08.481) that hardware is permanently hacked. Like, it’s not gonna get patched ever. So there are downsides to… Yup.
Paul Asadoorian (28:12.921) Well, that happens, right? That’s usually the first stage bootloader that loads, that’s on a ROM that loads the second stage bootloader that loads the kernel and the firmware.
Vlad Babkin (28:20.568) Yep. Yep. So you either have to do the full root of trust where you cannot patch a certain part of it ever, or if you can patch anything, attacker is going to be able to patch anything as well if he gets cold execution.
Paul Asadoorian (28:28.376) Mm-hmm.
Paul Asadoorian (28:38.957) super interesting.
Vlad Babkin (28:39.363) So… So that’s that’s…
Chase Snyder (28:40.814) Paul, speaking of applying voltage, is that cigar lighter intentionally styled to look like a jumper cable clamp?
Paul Asadoorian (28:48.301) I know, it does, it’s very fancy. It looks very fancy, I know. It doesn’t have firmware on it, unfortunately, but yeah, it looks very fancy. That’s right.
Chase Snyder (28:49.806) Ha
Vlad Babkin (28:55.235) No, I cannot hack Paul’s cigar lighter, I’m sad.
Chase Snyder (28:55.276) Hmm, that’s coming. You know, it’s coming.
Paul Asadoorian (29:01.797) That’s right, it’s analog only right now. I’m not saying there aren’t lighters with firmware on them, but yeah. So I thought that was really interesting research in uncover. But it’s interesting that attackers are going after, I had a blog post that’s coming out talking about end-of-life devices and why they’re just great places. They’re just great for attackers, right? And that’s what we’re seeing here, so.
Yeah, need to test that exploit. In a similar, this campaign, next campaign is very similar. It’s actually very concerning to me and I think speaks to a trend. mean, put the self-serving to Eclipseum aside for a moment, right? So this is an area obviously we pay a lot of attention to, but attackers going after network devices, IoT devices, for all the reasons we’ve mentioned before, we see a new Mirai variant.
that has a very, we’ll call it an insulting name that I don’t really want to say on the show. But the link in the show notes does a Fortinet actual, it’s Fortinet Threat Research Labs, published a blog post on it. And I believe they’re the ones to analyze and to discover and analyze it. This particular Mirai variant targets Draytech routers and
Vlad Babkin (30:02.111) Hahaha
Paul Asadoorian (30:24.993) Raisecom routers, I want to say there’s a TP-Link device in there as well as some Cisco ISE, but Cisco ISE is software, right? That’s their, isn’t that their agent or something like that? Cisco ISE is, it’s like their agent. There was a vulnerability in that recently, but it’s software. It’s not an actual services engine. Yeah. It’s more like software. Yeah.
Chase Snyder (30:45.666) Yeah. Stands for identity service services engine. Yeah. So it’s like their NAC policy enforcement. Yeah.
Paul Asadoorian (30:55.013) So, sorry, it’s called FortiGuard Labs, I should say. FortiGuard Labs did a great job writing this up. This particular malware is really advanced. Like a lot of the malware I look at, in terms of the features that, I don’t know if the code is necessarily advanced, but in terms of the features the malware was implementing, very interesting in terms of how the malware selected the architecture, so it has multi-architectural support.
which think they derived from Mariah anyhow. So based on the target that they compromised, the initial loader will pull down code specific to that platform. It looks like a lot of the initial, should back up a step, the initial access vectors look like unauthenticated remote command injections in the web interface on these devices. So I can show you like a screenshot there.
And if you look very closely at that code, you’re like, that’s just a basic command injection, which makes sense, right? You’ve got end-of-life devices with remote unauthenticated command injection. That combination, if you have that, you’re likely already compromised. it’s, attackers have figured this out and they’re like, this is a great place for us to hide and do all kinds of stuff. And for all the reasons that, you know, lack visibility.
is one reason that attackers are going after this. find it, the TP-Link Archer one, just by looking at the get request, forward slash CGI dash bin forward slash Lucy, tells me that that’s based on Openwork. Because Openwork’s web management interface years ago was ported to Lua, and I believe they called it Lucy. So I would venture to guess that that is a command injection for OpenWRT.
So that’s the initial vector. And then of course, you know, they have code that’s specific to all the different processor architectures and vendors. It’s been to multiple countries. Yeah, everything from MIPS to ARM to PowerPC to Intel. And it did a lot of evasion. It looked like it was injecting or monitoring itself.
Paul Asadoorian (33:22.405) It was, it loaded 47 command strings into memory and scans all the slash proc PID command line entries. If a match is found, the malware immediately terminates the associated processes. Does that mean if I’m trying to do forensics on the box and I run one of these commands, the malware just kills my command? That wouldn’t surprise me. I mean, not that’s necessarily new for malware. Something I haven’t quite seen on malware that’s targeting a device that typically doesn’t have remote access.
Maybe as SSH I’m not sure, some of these models might, but usually they don’t even allow you to have a command line on it. Usually I have to work hard to get a command line on it, because there’s no mouse and keyboard and monitor on these devices.
Paul Asadoorian (34:07.397) That functionality is something I see more in malware for Linux is targeting an actual server or desktop. So I thought that was interesting. Then it’s got sandbox evasion. So it tries to tell if it’s running in a sandbox, kills itself, heartbeat monitors, like all kinds of stuff to make sure it’s running. DNS server uses public DNS servers to do the DNS lookups for its C2 infrastructure so they can keep changing them.
It looks at all the outgoing ports and picks one from a list of pretty common ports that it tries to communicate on and sets up a back door. This user of various commands, in fact, to the host. There’s something about the, looks inside the packets. It was UPX packed, but they changed the header. So you couldn’t easily tell that it was UPX packed, although that was kind of interesting. A lot of this stuff’s probably common.
in a lot of malware, but in terms of malware I’ve seen on these type of devices, I thought it was pretty sophisticated. don’t know, Chase, Vlad, if you want to weigh in on that, but I thought it was pretty interesting.
Vlad Babkin (35:17.891) Yeah, Mirai is one of the first botnets, I think, that ever was so successfully exploited in IoT holes. If this is a variant of that, that’s pretty darn cool, especially if they improved on it. not just, hey, let’s a couple new CWs there, but actually improve it, that’s an achievement, let’s put it this way.
Chase Snyder (35:43.382) You mentioned, the sort of surprising difficulty of getting command line on something like this, as opposed to something that’s running Linux. But something we’ve talked about recently is the proliferation of IoT stuff and peripherals that are actually running Linux under the hood. Is that potentially the case for some of these things? you know.
that it’s just a Linux, it’s a IoT container around a Linux version.
Paul Asadoorian (36:07.769) Well, I-
Paul Asadoorian (36:16.153) Yeah, I think there’s a couple of different classes of like Linux devices, maybe three. Well, so you’ve got like the small appliances. So when they talk about Draytech, Draytech is more of like a sometimes I feel like they make DSL modems, which would sit in front of like your traditional wifi based router. And a lot of the DSL modems, and quite frankly, a lot of models of just regular wireless routers, I’ll call them, they don’t have
facilities by default that allow you to the user to gain a remote shell. So they don’t build in SSH or Telnet to the device. Then there’s some that do and that varies. It could be you have to go in and enable it or it’s enabled by default and you can SSH or Telnet or remote into that particular device. Then there’s ones like the larger Cisco gear that have like Linux under the covers.
but there’s like a Cisco iOS layer above that. And we saw attacks, we covered on the show, right? Where attackers were going from the Cisco kind of management layer and jumping into the Linux that runs underneath it. So it’s not always the case that remote login for a command shell is on your device.
Chase Snyder (37:39.224) Fair.
Paul Asadoorian (37:39.309) So hence the malware that they build, right? Rather than in the previous attack, we talked about static tundra. They were using a lot of SNMP to do the configuration of that device. In this case for IOT devices, they’re uploading malware and using the malware to create their own C2 to send and receive commands from it.
Paul Asadoorian (38:03.245) So more going after devices. Like when do we get to secure these devices so we don’t have this problem or is this just gonna continue until security improves?
Vlad Babkin (38:15.619) That’s best part.
Chase Snyder (38:21.742) This is a…
Paul Asadoorian (38:21.86) Right.
Vlad Babkin (38:22.923) like the problem
Chase Snyder (38:25.944) Go ahead, bud.
Vlad Babkin (38:27.268) This is a cat and mouse problem. You’re not gonna have more secure devices until just about every vendor on the planet agrees to make every device more secure, which is not happening. It just isn’t. Vendors don’t prioritize that, especially for lower-end devices. And a lot of admins, go ahead, chase.
Paul Asadoorian (38:38.98) Right.
Chase Snyder (38:48.216) Yes.
No, no, you go ahead. Finish your thought.
Vlad Babkin (38:53.005) Yeah, a lot of admins, even in bigger networks, for some like end-point device, some like end-user device, they might actually just buy, hey, why the hell do we need this price switch? I’ll just buy this cheap one and let’s install that, that’s gonna serve the exact same purpose for this specific part of my network. And suddenly you have a low-end device which doesn’t really have a good security, even if your vendor for your primary network actually committed to
Chase Snyder (39:22.798) I’m wondering how the new EU Cyber Resilience Act is gonna impact this at all. This is a curveball topic. It’s not something we have in the notes, but the EU has put out this new regulation that is heavily focused on manufacturers having to do due diligence around their supply chain for, they use the phrase digital elements and all integrated components and.
There’s tons of language in there about manufacturers having to verify that there are no known vulnerabilities in the components that they’re incorporating into their devices that they sell and getting an SBOM for all that stuff. And if they discover a vulnerability, even in free open source stuff or in a component from an upstream supplier, they have to notify the supplier and they have to provide a fix. There’s all this and it’s this EU law that’s
sort of gradually coming into effect. It entered force in December of 2024, but I think it won’t be fully enforced until like 2027. But it kind of is what you were just saying, Vlad, that like, yeah, the vendors are not gonna prioritize doing the security and the buyers are gonna buy the cheap one and the secure ones are probably inherently more expensive. And a bunch of that is gonna cause these vendors to be…
Paul Asadoorian (40:42.372) Yeah.
Vlad Babkin (40:44.077) So.
Chase Snyder (40:49.076) in violation of this law, and even though it’s an EU law, my guess is that like with GDPR, organizations that are trying to sell in the EU or, you know, at all working globally are going to be affected by it.
Vlad Babkin (41:05.443) So the problem here is even your base Linux image, even if you update all of the packages for it to the latest versions available for this base Linux image, it’s going to have 30 to 40 CVEs. So even if it is a small Linux like Alpine Linux, in a normal image there’s going to be a couple hundred CVEs. So the problem is this, vendors are just not going to be able to maintain that. Like right now, software vendors like us, we face a problem with this regulation where
Paul Asadoorian (41:13.133) Mm-hmm.
Chase Snyder (41:16.162) Mm-hmm.
Paul Asadoorian (41:19.781) Mm-hmm.
Vlad Babkin (41:35.341) we just have to go ghost hunting. We have a couple of hundred CVs which we have to deal with in our base image and we either have to pay a lot of money for an external vendor to provide us a base image, that’s basically what we are doing, for moving all of those from our base image which gives us literally nothing, as per security-wise. Let’s be honest, here most of those CVs are not even exploitable or relevant. If you’re not gonna do disk partitioning, vulnerability in some partitioning utilities is just…
not going to be relevant, albeit that’s one of those CVs that stays after full package update, right? So it’s going to be a lot of noise for the vendors. And even after vendors supply all of this, they’re going to find the new CV within weeks in every single device. because like open source software analyzed a lot. So somebody is going to find the vulnerability and suddenly the vendor has to go rush and patch it in every device. So
Paul Asadoorian (42:09.9) Mm-hmm.
Vlad Babkin (42:33.911) This puts too much pressure on vendors to fix vulnerabilities which are not even relevant. Right?
Chase Snyder (42:38.882) Yeah.
Paul Asadoorian (42:40.239) Yeah, think attacking it from the vulnerability problem is where people gravitate towards, but Vlad, I’m with you. It’s not going to help us even in the long run. It’s just not going to help us because no matter how many vulnerabilities we can squeeze out of the firmware that we’re delivering, you still have to harden it. And like you said, there’s going to be new vulnerabilities that arise or there’s going to be misconfigurations. So the real answer is how do we harden
Vlad Babkin (42:57.699) Mm-hmm.
Vlad Babkin (43:05.773) Yeah.
Paul Asadoorian (43:09.251) this firmware so that it is more resilient to attacks. mean, right now, like most devices, everything runs as root. So, you know, just one small vulnerability and everyone has root. And even if you don’t do that, there’s privilege escalation in all the binaries in those 50 or 100 CVEs that are living on the system, usually.
Vlad Babkin (43:12.547) Yes, yes, yes.
Vlad Babkin (43:20.095) And, yeah.
Vlad Babkin (43:26.741) I will make this image even scarier. How many vulnerabilities out of those that are in the headliners are in open source software? I will tell you an estimate. None. Like, okay, sometimes we find vulnerability in open SSL itself and it affects basically everything. Sure, but most vulnerabilities which are render specific, like which are, okay, we have code execution in the five devices. They’re not because of the five devices having some vulnerable components.
Paul Asadoorian (43:42.853) Sure.
Vlad Babkin (43:55.011) They are because of an F5 device having a code execution vulnerability. And 95 % of IIT vulnerabilities that are relevant are that. And EU regulation does not even touch them. So they don’t enforce any secure development lifecycle on the vendors. They don’t enforce vendors to actually pass SAS tools, which would catch a lot of those, by the way, because that would be an insurmountable task. If you think that a couple hundred vulnerabilities is bad,
Paul Asadoorian (43:59.375) in the web interface usually.
Vlad Babkin (44:24.729) Try to run a SAS tool on a project which never had that run and you’ll have a couple thousand of findings, probably tens of thousands of findings. Most of them are just noise. And digging through them is painful for anybody. Like they would have to literally stop the world and stop each vendor for a couple of years to just dig through all of that. And even then, even after you fix all of those, there is a, as you said, everything is running its route. Exploit one thing, exploit everything.
privilege circulation on device level.
Paul Asadoorian (44:57.358) One of my friends, Sam Bowne, said this on my Paul’s Security Weekly podcast. And he said, what if we were to treat firmware like the app stores and similar things where every piece of code that runs on this device is signed? So when you deliver firmware, everything’s signed and you can only run the software that’s contained inside that firmware. So we’ve hardened the firmware so that I, as an attacker, if I upload something new, well, it’s not signed, can’t run it.
how you do that and how you get around that could be a whole series of podcasts. But one of the problems with that, based on what you’re saying, Vlad, is that if there’s a command execution, I can still run what’s on the system. I don’t have to upload anything new. I can basically break out of the web interface and run a command. Now, could you put safeguards in to try and prevent that? Certainly. But then, again, back to your cat and mouse game comment, Vlad, then it’s like, well, how do I get around that?
Vlad Babkin (45:42.968) Yup. Yup.
Paul Asadoorian (45:56.369) but it would raise the bar. Right now, but right now the bar is extremely low. So raising the bar is like not hard, because the bar is like way down here somewhere.
Chase Snyder (46:04.012) The bar is low.
Vlad Babkin (46:04.053) So, bowl.
Yeah, Paul, if you want to make command execution not relevant, you have to ban every single scripting language on the device. You have to ban bash, have to ban Python, you have to ban Lua, you have to ban every single scripting language ever and not allow them to run at all. Like you cannot supply a shell on it because there is not supposed to be a shell. Because like, yes,
Paul Asadoorian (46:32.486) or you have to do some kind of zero trust thing, that doesn’t really run on, I mean, running on small devices is challenging. mean…
Vlad Babkin (46:38.916) As soon as you have assigned Python interpreter, attacker can just put a data file with his Python scripts and do whatever the hell he wants. This is by the way the case with
Paul Asadoorian (46:47.258) Right. I mean, I’ve seen solutions that can lock down a Python application in the context of zero trust, but implementing that inside of firmware, have not seen unless someone was, please correct me if I’m wrong. If that exists, please tell me. But yeah, hardening this firmware is, it’s hard, right? It’s hard. But certainly we can make some improvements, but.
Vlad Babkin (47:00.761) Yeah.
Vlad Babkin (47:05.122) Yeah, you need a special…
It’s like, what you’re proposing to run on the signed code is, what I would formulate is that A, there isn’t supposed to be anything executable in configuration partitions, and B, all of the partitions with executables are supposed to be signed and checked during boot time for the signature to be valid. And even then you’re still vulnerable to certain types of attacks. Like, yeah, it will be an incredible hardening step, but…
attacker getting code execution and being able to execute code, like maybe he cannot upload his own Go binary, but he can still execute bash, Python, whatnot, it’s not gonna be fixed. And that’s, again, the most common use case. Like we don’t see malware which is trying to spread, like, or sorry, we don’t see vulnerabilities which are somehow locked or forcing attacker to spread the binary. Most of the time it’s just a scripting language.
Paul Asadoorian (48:04.089) Yeah, I mean, it’s a perfect storm. In my article, I talk about how we have very low visibility into these environments, right? Defenders are not looking for compromised routers and network device equipment. It’s very hard to gain a deep level of of visibility into what’s happening on these devices because they are small, they’re locked down, they run firmware. And also, I think to compound the problem, it runs on
dozens of different platforms, right? Every firmware is all slightly different, even at a macro level, you’ve got MIPS, you’ve got ARM, and all the different flavors, so it makes it really hard to come up with defensive solutions that can be ubiquitous across all of those different computing environments. Also, we still have the problem, even if we say you have to deliver a secure device, we’re not going to buy it, it’s not going to be consumed.
Vlad Babkin (48:34.947) Mm-hmm. Yeah.
Paul Asadoorian (49:00.141) unless it’s air quotes secure and there’s no vulnerabilities on it today. But, and even if you keep up with that for the lifespan of the device, eventually that device is going to reach end of life. And unless we make a law that says, Hey, once your device reaches end of life, you have to take it off the network. Like no one’s going to do that. No one’s going to do that. I mean, you still have people out there running windows XP and you know, for reasons, right? And so that’s hard.
Vlad Babkin (49:11.735) Yup. Yup.
Vlad Babkin (49:20.035) Yup. Yup.
Vlad Babkin (49:25.411) We still have people who run ancient routers from Asus, which are end of life probably twice already with Thrice. Even then, and even if you do all of that, there is still configuration on the malware, like sync-marrys.net, which never even compromised firmware. It was just a configuration file. And a lot of devices actually allow incredibly complex configuration files, like sync-cisco.tcl language. Like, it’s a whole script.
Paul Asadoorian (49:52.313) Yeah, yeah, yeah. I’ve seen that before. Yeah, yeah, yeah. Right. It’s a whole scripting language they support. Yep.
Vlad Babkin (49:55.189) It’s like… That scripting language is incredibly complex. we have a whole… Again, not to shove our product upfront, but still, just a use case, we have a script which can collect information enough for us to check device integrity to a degree. Like, that’s a lot to ask from a device configuration interface, yet Cisco allows it. So unless you also force vendors to make their devices less usable as well, by not allowing very rich scripting,
Paul Asadoorian (49:59.974) Mm.
Paul Asadoorian (50:22.201) Yeah.
Vlad Babkin (50:24.612) you’re still gonna be, the attacker is still gonna be able to run a whole lot of code on it. Even if you…
Paul Asadoorian (50:30.113) Is a great point though. If we add the more capabilities we add, even if they’re too hardened and help defend the device, that increases the attack surface. Yeah, that’s a great point.
Chase Snyder (50:42.648) That is.
Vlad Babkin (50:46.519) Consider that some devices weren’t allowed to run Docker containers. Modern Microtex do that. You can build or run any Docker container you want on it. And that’s on a user device. It’s not even an enterprise one. And it’s not a security vulnerability. It’s more like we need capability.
Paul Asadoorian (50:49.957) You’re right.
Paul Asadoorian (50:56.611) Wow. Well, because that’s, yeah, well, because that’s Moore’s law, right? These devices have increased exponentially in their compute capabilities, but also the internet got a lot faster, which also means attackers can easily scan the internet and go find these devices. I was just saying before, in an interview that I did earlier today, that it’s kind of like attackers are doing continuous monitoring.
Vlad Babkin (51:07.16) Yes.
Exactly.
Paul Asadoorian (51:26.361) but not for defense, but for evil. So they’re continuously monitoring the internet, discovering devices that are both vulnerable and end of life. And they can do that at an amazing scale. think last time I interviewed H.D. Moore not that long ago, he said the internet can be scanned in matter of hours. I mean, that’s probably even a generous estimate depending on how you’re scanning and what you’re scanning from. Right, how big of a system do you have to scan? How much bandwidth do you have?
are all factors in how quickly you can scan the entire internet for any given things. And attackers are doing that. what’s allowing them to, the ironic thing, it’s like it’s full circle. Attackers are compromising the devices that are exposed on the internet, that are the low hanging, I hate the expression, they’re essentially low hanging fruit, building a botnet, then using that to scan the internet for other things, like RDP and whatnot, and just continuously scanning from those.
which is a great vantage point for them because they’re on the internet, they’re more compute powerful than ever before, and they’re coming from residential IP addresses. So if you’ve got a bot and have even 2,000 residential IP addresses and you’re cycling through them, that’s a brilliant way to scan the internet without getting taken down or caught.
Vlad Babkin (52:35.618) and
Vlad Babkin (52:39.875) And they can actually jump down into the said residential network because if this device is vulnerable, it’s very unlikely that this is only device vulnerable.
Paul Asadoorian (52:46.575) Mm-hmm.
Paul Asadoorian (52:51.813) I talked about that in like 2010, I actually showed how you could do research to figure out if you’re targeting a specific, you target a country, figure out who’s the ISP for that country. You go to the message boards and forums and you see what model routers are being distributed to those folks. And then you look for vulnerabilities in that router. And like you said, Vlad, it’s probably common across the way they’ve deployed it to all of their customers. Now you can basically compromise a huge subsection of a country.
and control the routers. And that’s pretty much what attackers are doing today, know, 15 years later.
Vlad Babkin (53:27.885) Yep, compromising a small ISP with homogeneous infrastructure with one CVE exploit is also doable sometimes.
Paul Asadoorian (53:33.891) Yeah, right.
Chase Snyder (53:36.824) thing you said about adding, as you add more features and capabilities, you also add attack surface, I feel happens at multiple sort of zoom levels, like in an individual device, the more featureful it is, the more compute that it has the more attack surface, but also organizationally, bringing in new products, even security products, it’s like, how much you know, the number of firewalls and VPNs and like things that are ostensibly for security that we see
Paul Asadoorian (53:45.528) Yeah.
Chase Snyder (54:06.636) being targeted and exploited as the initial access vector or as the or as a persistence mechanism or jumping off point for lateral movement or whatever. It’s like when you bring in a new product, even a security product like a firewall, you’re adding new attack surface and you might be bringing in more risk than you’re taking out depending on the product. So if you think about it, like sort of systems thinking flows of like
Paul Asadoorian (54:29.357) Right, right, right.
Chase Snyder (54:36.832) risk you bring in versus risk that you mitigate. If you look at every single product through that lens, companies are bringing in so much new technology and it’s increasing the attack surface and increasing the risk level probably at a greater rate than it is mitigating or reducing the risk.
Paul Asadoorian (54:57.571) Yeah, so like what you’re saying is if we create a new startup and we come out with the latest and greatest AI defensive software technology to protect firmware based devices and we’re able to deploy that to these devices, we’re also increasing the attack surface. Sure, we can gain visibility, but it’s somewhat of a trade off if our latest and greatest AI firmware, I don’t know, we could come up with a funny name for it, right?
to load this piece of code on all your firmware and it’s the magic bullet that helps defend it all, someone could, if there was a vulnerability in that, that’s another attack vector for threat actors.
Chase Snyder (55:34.274) That’s making me think about how the kernel level anti-cheats have started to conflict with each other. Another story that is not on the docket, but…
Paul Asadoorian (55:38.893) Yes. And move right, right. Yeah.
Vlad Babkin (55:42.305) Yep. Yeah, with this Eclipse we are trying to actually protect our product from that on multiple levels so that like even if the product is compromised let’s have at least one more layer of defense to not let attackers get to customer infrastructure. So we have all of that. But question is just how many vendors, even security-focused ones, are actually doing that? Definitely not all of them. Again, I’m not gonna call any single vendor out.
Paul Asadoorian (55:55.875) Mm-hmm.
Right. Yeah.
Vlad Babkin (56:10.979) But let’s just say that a whole bunch of vulnerabilities indicate that my statement is probably correct. That by far not every security vendor is focusing on
Paul Asadoorian (56:16.133) Mm.
Paul Asadoorian (56:20.677) Chase, you want to talk about Control Vault? Probably the last thing we’re able to cover on the show. We’re having so much fun.
Chase Snyder (56:24.196) yeah, we’re gonna.
Yeah, good good docket. I know we’re short on time. Should we do it or should we save that for the next one?
Paul Asadoorian (56:33.029) No, well, I think we should do it. Unless you have like a deep analysis of it, right? It’s, well, it’s actually sneak preview. In Paul’s queue of things I have to write about, the next piece I’m going to be working on is examples of where attackers can live outside the operating system. But I don’t want to pitch that as like, we shouldn’t secure the operating system or that even we as Eclipseum, we definitely help with operating system security too.
We just happen to have a heavy focus on the, like, before the operating system or outside the operating system components, which in my piece I talk about as the dusty corners, like a whole story narrative about that. And when you look at a system and you look at attacker behavior, right, they’re always trying to get around where the heaviest defenses are. And I feel like today the heaviest defenses are in the operating system. You’ve got advanced EDR for whatever that’s worth.
And also, I mean, back to our previous conversation, every week, we see, I see at least, you know, two or three articles that talk about how to bypass EDR. Now, whether those are new or not, sometimes that’s true, sometimes it’s not. Sometimes it’s a variation on a theme. Sometimes it’s a very small subset where that would work. But EDR bypasses are, they come out every week, right? And they’re constantly improving. And so, but also EDR is improving. So like, where do attackers go to hide? Well, they go to things like UEFI.
They go to things like other components, like your graphics card firmware. go to, last year we talked about the option ROM talk. They go to other components such as Dell ControlView or Mickey and Jesse’s research on BadCam, right? That’s living outside the operating system. Control Vault is the, I call it a daughter board, for lack of a better term, that sort of acts…
similar to a TPM in doing some enforcement of security controls for the system and that lives in a separate board. But what Cisco Talos researchers, they actually presented at Blacca, actually it’s Philippe who I’ve interviewed in years past before he went to Cisco Talos, is a firmware security researcher, awesome guy, amazing researcher. What Philippe figured out was that in this Dell control vault,
Paul Asadoorian (58:57.399) it’s firmware based and through a vulnerability, he could leverage that vulnerability to also control and upload his own firmware to it. Now, Philippe didn’t go into details, much in the same way Mickey and Jesse did. Like, Mickey and Jesse went to details. Here’s how you get malicious firmware on this device. It was kind of just like a note in their article. I haven’t watched the full Black Hat talk, but so you can control the firmware as an attacker.
on Control Vault. Conceivably, you could live inside of Control Vault, which means, as we’ve talked about with BadCam, that you can control the operating act independent of the operating system. So full system wipe doesn’t matter. I’m living in this little component. And once you put a new operating system on there, maybe I’ve got some kind of timer that checks in and goes, hey, there’s a new OS. I haven’t infected yet. Let me go infect that. Now you still have to get around operating system controls to infect it.
but as a persistence mechanism, it’s absolutely amazing. And maybe over 500 Dell laptops, right?
Chase Snyder (59:59.468) And the widespreadness of control vault, it’s in, I mean, yeah, hundreds of models, you know, that are, are widespreadly used in government enterprises. You know, it’s like the, organizations that are vulnerable to this or, know, potentially have this in their, in their system is a, a massive, massive group of targets.
Paul Asadoorian (01:00:21.411) Yeah, for sure. It was one of my favorite research pieces that came out as a result of Black Hat. I mean, I have to give, I was, I almost can’t count Bad Kam because I was too close to it. And I love Mickey and Jesse and what we do here. So, you know, there’s that, but they were in my mind, very similar, right? Also, think Kazuki’s talk about creating malware that lives in UEFI was a step forward in this progression towards
Chase Snyder (01:00:33.454) You
Paul Asadoorian (01:00:51.247) How do attackers live outside the operating system on a system? Because there’s so many benefits to that. Much like IoT and network devices we talked about, there’s nothing in there that is doing real detection and prevention of malicious code. There might be things that maybe sign the firmware, do validation, encrypt the firmware. There’s other features that are present in a lot of firmware-based devices.
Chase Snyder (01:00:55.436) Yeah. Yeah.
Paul Asadoorian (01:01:19.993) But for the most part, once you’re on that device, you can do whatever you want as an attacker. Doesn’t matter what the operating system does. In that case, it doesn’t matter what the bootloader does either. You’re before that as well. So it’s pretty awesome. Well, once you get BMC, I included BMC in that too. Because if you can live inside a BMC, you’re living outside the OS.
Chase Snyder (01:01:41.336) Yeah, big theme, big theme emerging.
Paul Asadoorian (01:01:45.405) Yes. And you know, it is in the research stages in a lot of these fronts today. But as we saw, thank you, Vlad, your discovery of CVE 2024 50. What is it? 54. 585. I almost had it. had it. 085 54085 was the one that we talked about heavily on the show.
Chase Snyder (01:02:01.358) 5487 54085 54085
Vlad Babkin (01:02:02.947) I don’t remember the number, I don’t understand what CV you’re referring to.
Paul Asadoorian (01:02:13.765) remote command execution of a BMC device ended up on the Sysicab. And so attackers were like, that’s awesome. I’ll use that. this to me is Pandora’s box. I think that everyone’s gonna wanna live outside of the operating system. But again, I’m biased, so.
Vlad Babkin (01:02:23.424) Yeah
Paul Asadoorian (01:02:35.704) Awesome.
Vlad Babkin (01:02:35.927) Maybe it’s Pandora Box, but I wouldn’t call that vulnerability technically interesting, in my opinion. Like, yeah, it’s only interesting because of the place where it is, not because of…
Paul Asadoorian (01:02:46.149) Agreed, right? If that was in some software that was used by, you know, 50 companies or whatever, it would be just another vulnerability that we see in WordPress and all these weird applications that end up on, you know, end up getting CVEs for a software application that hardly anyone uses. It would have just been under the radar. The fact that it was in a BMC that was so widely deployed is what makes it interesting. I think you’re right. I don’t want to take away from your research because I think it was an awesome discovery. When you showed me that this is the X-Blade and how it works, was like, well, it’s actually kind of, that’s really not hard to do.
Vlad Babkin (01:03:23.584) I have been claiming that that exploit is not really that hard. I pretty much explained it to you and you agree immediately. So this is what I’m saying, it’s not technically hard.
Paul Asadoorian (01:03:26.789) Yeah.Yeah, yeah.
Paul Asadoorian (01:03:33.453) Right. We don’t take away from the work it took to find that and validate the claim because that’s where the work is.
Vlad Babkin (01:03:38.979) Oh yeah, was a whole bunch of work to… For the initial research in 2023 and in 2022, there was a whole bunch of work to even get far enough to be able to research that.
Paul Asadoorian (01:03:45.477) Yeah.
Paul Asadoorian (01:03:51.342) Right, right. Well, awesome. Well, Vlad and Chase, thank you so much for appearing on this episode of Below the Surface. Thanks everyone for listening and watching. We’ll see you next time.
