CyberWire Daily - New vulnerabilities in PC sound cards. [Research Saturday]

Episode Date: February 22, 2020

SafeBreach Labs discovered a new vulnerability in the Realtek HD Audio Driver Package, which is deployed on PCs containing Realtek sound cards.  On this week's Research Saturday, our conversation with Itzik Kotler, who is Co-Founder and CTO at SafeBreach.  The research can be found here:  Realtek HD Audio Driver Package - DLL Preloading and Potential Abuses Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. data products platform comes in. With Domo, you can channel AI and data into innovative uses that deliver measurable impact. Secure AI agents connect, prepare, and automate your data workflows, helping you gain insights, receive alerts, and act with ease through guided apps tailored to your role. Data is hard. Domo is easy. Learn more at ai.domo.com. That's ai.domo.com. Hello, everyone, and welcome to the CyberWire's Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down threats and vulnerabilities and solving some of the hard problems of

protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. And now, a message from our sponsor, Zscaler, the leader in cloud security. Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security.

Zscaler Zero Trust Plus AI stops attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network, continuously verifying every request based on identity and context, simplifying security management with AI-powered automation, and detecting threats using AI to analyze over 500 billion daily transactions. Hackers can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI.

Learn more at zscaler.com slash security. Over the past year, we actually looked at different stacks of the software to basically understand, you know, what has been perhaps missed or which things have not been yet drilled into. That's Itzik Kotler. He's co-founder and CTO at SafeBreach. The research we're discussing today is titled RealTech HD Audio Driver Package, DLL Preloading and Potential Abuses. And interestingly enough, in today's software, there is sort of a trust that happens that in the network side is no longer exist. So when you have a file, the mere fact of the file name or existing in a specific directory creates a trust that it's indeed the right file with the right functionality. While when you're looking at the networking element, things such as men in the middle, we all go through our ISPs every day to get to the internet. However, we don't trust every packet or data that they're sending back just by the fact that they are in our line. So re-examining the software stack, we've basically got reintroduced

to a problem that we are looking at, which is the DLL preloading, DLL search order hijacking. And looking at that horizontally, we have found that problem in multiple companies, and Realtek is one of those. Well, let's dig in here and explore what you're laying out here. First of all, this Realtek HD Audio Driver Package, this goes along with some audio cards that they manufacture? Correct. It's actually a very interesting, out of the many different vendors that we've examined, this vendor actually got their driver being pushed by Microsoft Update.

So essentially, there is certain vulnerabilities that we have found in companies that has a mixture of an OEM. In this particular vulnerability, we have actually found it to be vulnerable. Everywhere you have the real tech HD audio hardware, Windows will deploy their driver that up until now had this particular vulnerability in it. Well, walk us through what is the actual vulnerability. Excellent.

In order to kind of set the scenery to everybody understands the benefit and the interjection point, so we're looking at an adversary. An adversary first needs to infiltrate into a machine, or in some cases it could be an inside threat they may already have access. But this is not a vulnerability that goes to the exploitation part. So the assumption here right now is that some exploitation took place, the adversary got in into the exploitation part. So the assumption here right now is that some exploitation took place, the adversary got in into the workstation. Now, as part of the adversary next move

is obviously they want to achieve persistence, right? They want to get a hold of the computer in order to pivot from it in the future, or maybe that computer in the future will contain some interesting information on its own. And in order to do so, you know, there's different techniques, different remote access tools, RATs and backdoors. Now, we're looking into how can this mechanism of persistency and deface evasion can be implemented as smoothly as possible. Here, the DLL preloading vulnerability comes in place.

Essentially, instead of the adversary to go ahead and basically create a hook that will drive the software to basically load every time the computer reboots, we're basically piggybacking on the Realtek HD audio package to do it for us. And this is essentially the vulnerability that we have found in this overall software. Well, how does it work? How do they achieve what they're after here? So essentially, the HD package that comes with the driver for the hardware obviously has its own normal execution times, right?

When your computer boots up, you want the audio system to be initialized so you can use it later on within the different application. So they have their own service and drivers which take care of loading their own component. Looking at what's particularly interested here in this particular vulnerability is that Realtek, and we have discovered that again as we went through the process of disclosuring it with them, have used a very old version of the Microsoft Visual Studio. In that particular version that they have used, what we end

up finding out that they had also enabled localization, which makes sense. It's been an international company. There could be multiple languages that users want to cater. That multiple languages support is actually embedded in a framework called MFC, which is something that Microsoft is actually bundling and pushing. Particularly in that old version of MFC, they're looking for specific files and the blog contains the specific names of the file with the CIFICS, ANU and LOC for the different languages that they could load in runtime to cater to the user.

So you can imagine every language will have a DLL that within that DLL there's different strings, there's different resource to how you should communicate with that user. So if you imagine the favorite dialog boxes, the wizard, the next, next, next buttons that we all have to click through, the language in those dialogues needs to come from somewhere and then when you want to support multiple languages, those will be break down into different DLLs. However, what we end up finding out due to the old version, that in those days when this Visual Studio compiler came out, they were treating those DLLs, although they're resource only, they treated them as a code. So essentially, if you were able to write into a specific directory a file that has

this CFIS in it, then you eventually would have managed to get your code run by Realtek as a result of their discovering the different locale options that they have. And this exactly goes back into the persistence idea where the adversary, understanding the software is installed, instead of trying to register its own service or its own routine to be invoked, uses this specific DLL, writes itself in this specific location, and gets under the umbrella of real tech to get executed on the machine. Now, they're using quite an old version of Visual Studio, yes?

Yes. I believe that the version that they're using is from 2005. Which is interesting in itself. I mean, obviously, I suppose they have their reasons, but I guess it's certainly something that would raise eyebrows. Yes, yes. And unfortunately, you know, this is not the first time that, you know, we in an industry, you know, observing, you know, different vendors and competitions and, sorry, companies, different vendors and companies that, you know, they have a sellable product and they keep pushing the product. And then security might not always have the first priority. And while one can argue that changing your working environment,

Visual Studio may not be a security-only reason, there is also security attached to it because legacy products contain legacy logic that, as we've witnessed here over the years, no longer exists. When we have tried to reproduce it in a Visual Studio 2017, that was no longer the case. So as you can imagine, this is a case where if you don't use the legacy compiler, if you switch to a modern one, just by the sheer fact that you switch, you no longer have the underlying issue. I see. So this could be a situation where they were using the old compiler because in their view,

if it's not broke, don't fix it. Everything seems to work. We've used this for a long time. Let's not spend any time or energy on that. Let's continue using it the way that we always have. And as you point out, that could lead to some security issues. Correct. And that was indeed the case. I do have to, you know, in favor of being honest here and looking at the problem, you know, holistically. So yes, the usage of the outdated software and the fact that those satellite DLLs were treated as an executable was a major contributor to the fact that we have managed to exploit this vulnerability and managed to show how this is consistent with this kind of

post-exploitation techniques. There is also the matter of the fact that they have not used digital signature to validate the code. And again, going back into our initial discussion, in the network arena, trust has been, by the fact of how things work, by the fact that you always kind of go through someone's pipe to some degree to get into the outside world, trust such as TLS, digital certificates, encryption, world, trust such as TLS, certificates, encryption, has rapidly involved to accommodate all these conditions. In a sense, those tools,

those encryption and cryptography capabilities are also existing in the endpoint. However, one needs to choose to use those APIs, one needs to choose to use this logic to validate that those are just not a file in this directory, but it's indeed a signed file by the vendor that expects those files to be signed in a specific way, that's not just randomly loading DLLs, but also verifying their origin. And I think this is the overall issue here, contributing to the fact that they have used an outdated software.

Yeah, it's interesting to me. I mean, it strikes me that something like an audio driver could be generally considered to be benign. It's sort of out of sight, out of mind. It just operates behind the scenes here. Probably not something that attracts a lot of scrutiny. Exactly. something that attracts a lot of scrutiny. Exactly.

And I think just because of the reason that you just mentioned, it could be almost a perfect hideout for an adversary. So the researcher that has conducted this research, as well as the previous one, Pelle Gadar, is named in the blog post. In some of those elements, although not in particular in this one, we've also kind of tried to look at the bigger picture. And the bigger picture is that this service, this software, has a parallel driver loaded into the kernel.

Now, again, we have not looked to understand the relationship and what kind of trust relationship could be made between those elements. relationship could be made between those elements. But as you mentioned, the sound driver, but being a legitimate driver loaded into the kernel, one can even exploit this delegate relationship to even make even far-fetched and more bigger impacts on that computer. Just by the sheer fact that the driver may blindly trust any calls or requests that are made by the software, there is even a bigger play here to escalate even further than just having a persistent mechanism, but also roaming into the kernel land and make even more subversion into the machine security at large. I see. Now, was there any evidence that anyone was taking advantage of this vulnerability? Not that we know of. Every now and then we do try to, again, use our sources to look around and understand whether this is something that already existed or how can we try to trace it.

But to the best of our knowledge, no one has used this technique. And we're very much grateful and happy that Realtec took the steps to mitigate it, but to the best of our knowledge, no one has used this technique. And we're very much grateful and happy that RealTech took the steps to mitigate it. So even now, if somebody reads this blog post, it's only applicable to the legacy driver. The new driver already contains the fix. And I think it also raises a good point about this knowledge can be used to progress companies, whether it's security vendors to be aware of such techniques by adversary, as well as the vendors themselves to upgrade their level of security. So all in all, I say it's a win-win. Yeah, I think it's also worth noting that as part of the blog post that you all put up here,

that you have a timeline of the communications between your organization and Realtek. And it really reads like a back and forth sort of a collaborative process where everyone in good faith was trying to get this resolved. Yes, yes, it is. And this is something that, you know, we as a company and us as a researcher are very much committed into, you committed into this responsible disclosure process. I'm not saying that there is not times that you need to kind of break things out and venture on your own to get the vendor attention. Luckily, again, we did manage to get the vendor attention.

It took some time to explain the vulnerability. It took some time to read the response and trying to use their arguments because, as we mentioned earlier, the software works. We're not talking about a situation where the user is complaining. We're talking about a situation where the

user could benefit from a higher level of security. And where does this security come in place and how will it be tangible it's not always very clear to all the vendors and so going back and forth trying to explain the scenario trying to explain the different technicalities we're very happy that real tech understood that and basically proceeded to fixing it and again as you can see the result is documented in the timeline but nonetheless there is a cv issued and more importantly there is a patch that has been fixing it. And again, as you can see, the result is documented in the timeline. But nonetheless,

there is a CV issued. And more importantly, there is a patch that has been circulated. So we put an end to the problem. What are the broader high-level lessons to be learned here in terms of people who are working, developing things like this within their organizations, sending them out into the real world? What sorts of things should they be aware of that this issue demonstrates? I think it's a very good question. I think this issue demonstrates, again, a little bit of the old ways where assumptions about artifacts, whether it's paths, file names, or even to some degree, some special signatures or keywords were used to identify, locate and trusted in order to perform actions. And again, we can all look back and understand that, you know, back in the day, from a computational perspective or even from a threat landscape perspective,

those things could may have a picture or come across as an overkill. But I think these days, you know, especially when you're looking at a very popular company that has a huge distribution mechanism, that has a huge footprint, that could exist in many different laptops and computers. And the side effect that, you know,

this little nuance can now give an adversary a legitimate mechanism to load the malicious code and potentially abuse their driver to perform kernel subversions to other processes is very, very far. And so, you know, again, going back into the basics, going back into the security hygiene, we're looking here at how should you treat artifacts when you try to load them.

If you know that it's your own software, you should definitely sign. You should be able to authenticate and validate your own code signatures. If you're looking to work with third parties that develop for you. There are schemes and rotation mechanisms when you can share digital certifications and encryptions. So there are ways to solve this issue, much like it was solved in the network world. But what it takes is people to care, people to think about that as a problem.

And hopefully, again, going back into Peleg's extensive research in 2019 that resulted in, if I'm not mistaking, a little bit over 20 different CVEs for many different big vendors in the market. I really hope this will move the needle going forward. That's Itzig Kotler from SafeBreach. Thank you. security solution trusted by businesses worldwide. ThreatLocker is a full suite of solutions designed to give you total control, stopping unauthorized applications, securing sensitive data, and ensuring your organization runs smoothly and securely.

Visit ThreatLocker.com today to see how a default-deny approach can keep your company safe and compliant. CyberWire team is Elliot Peltzman, Puru Prakash, Stefan Vaziri, Kelsey Bond, Tim Nodar, Joe Kerrigan, Carol Terrio, Ben Yellen, Nick Valecki, Gina Johnson, Bennett Moe, Chris Russell, John Petrick, Jennifer Iben, Rick Howard, Peter Kilpie, and I'm Dave Bittner. Thanks for listening. Thank you.