New vulnerabilities in PC sound cards.

Dave Bittner: [00:00:03] Hello everyone, and welcome to the CyberWire's Research Saturday, presented by Juniper Networks. 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.

Dave Bittner: [00:00:25] And now a word from our sponsor, Juniper Networks. Organizations are constantly evolving and increasingly turning to multicloud to transform IT. Juniper's connected security gives organizations the ability to safeguard users, applications, and infrastructure by extending security to all points of connection across the network, helping defend you against advanced threats. Juniper's connected security is also open, so you can build on the security solutions and infrastructure you already have. Secure your entire business, from your endpoints to your edge, and every cloud in between, with Juniper's connected security. Come see Juniper at RSA 2020 in booth 6161 to see why NSS Labs says Juniper is back in security. And we thank Juniper for making it possible to bring you Research Saturday.

Dave Bittner: [00:01:19] Thanks also to our sponsor, Enveil, whose revolutionary ZeroReveal solution closes the last gap in data security: protecting data in use. It's the industry's first and only scalable commercial solution enabling data to remain encrypted throughout the entire processing lifecycle. Imagine being able to analyze, search, and perform calculations on sensitive data, all without ever decrypting anything – all without the risks of theft or inadvertent exposure. What was once only theoretical is now possible with Enveil. Learn more at enveil.com.

Itzik Kotler: [00:01:58] 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.

Dave Bittner: [00:02:11] That's Itzik Kotler. He's co-founder and CTO at SafeBreach. The research we're discussing today is titled, "Realtek HD Audio Driver Package - DLL Preloading and Potential Abuses."

Itzik Kotler: [00:02:24] And interestingly enough, in today's software, there is sort of a trust that happens, that in the network side does no longer exist. So, when you have a file, the mere fact of the filename exists in the 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 man-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 are sending back just by the fact that they are in our line.

Itzik Kotler: [00:03:02] 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.

Dave Bittner: [00:03:22] Hmm. 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?

Itzik Kotler: [00:03:36] Correct. It's actually 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 have a mixture of an OEM. In this particular vulnerability, we have actually found it to be vulnerable everywhere you have the Realtek HD Audio hardware, Windows will deploy their driver that up until now had this particular vulnerability in it.

Dave Bittner: [00:04:11] Well, walk us through – what is the actual vulnerability?

Itzik Kotler: [00:04:14] 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 into the workstation.

Itzik Kotler: [00:04:42] Now, as part of the adversary's next move is obviously they want to achieve persistence, right? They want to get ahold 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. 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 defense evasion can be implemented as smoothly as possible. 

Itzik Kotler: [00:05:15] 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.

Dave Bittner: [00:05:43] Hmm. Well, how does it work? How do they achieve what they're after here?

Itzik Kotler: [00:05:46] So, essentially, the HD – the package that comes with the driver for the hardware obviously has its own, you know, normal execution times, right? You want, when your computer boots up, you want the audio system to be initialized so you can use it later on within the different applications. So, they have their own service and drivers which take care of loading their own component.

Itzik Kotler: [00:06:12] Looking at what's particularly interesting here in this particular vulnerability is that Realtek – and we have discovered that again, as we went through the process of disclosing 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 they 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 suffixes "ENU" and "LOC" – for the different languages that they could load in the runtime to cater to the user.

Itzik Kotler: [00:07:13] So, you can imagine every language will have a DLL, that within that DLL there's different strings, there's different resources 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 love 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.

Itzik Kotler: [00:07:39] 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 resources only – they treated them as code. So, essentially, if you were able to write into a specific directory a file that has this suffix in it, then you eventually would've managed to get your code run by Realtek as a result of their discovering the different locale options that they have. And this is exactly goes back into the persistence idea, where the adversary understanding the software is installed, and 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 Realtek to get executed on the machine.

Dave Bittner: [00:08:38] Now, they're using quite an old version of Visual Studio, yes?

Itzik Kotler: [00:08:43] Yes, I believe that the version that they're using is from 2005. 

Dave Bittner: [00:08:49] 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.

Itzik Kotler: [00:08:57] Yes. Yes. And unfortunately, you know, this is not the first time that, you know, we in the industry, you know, observing, you know, different vendors and competitions – sorry, companies – different vendors and companies, that, you know, they have a sellable product and they keep pushing the product, and then security may not always have the first priority. And while, you know, 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 in – when we have tried to reproduce that 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.

Dave Bittner: [00:09:59] 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.

Itzik Kotler: [00:10:21] Correct. And that was indeed the case. I do have to, you know, in favor of being honest here in 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, you know, we have managed to exploit this vulnerability and managed to show how this is consistent with, you know, with this kind of post-exploitation techniques.

Itzik Kotler: [00:10:52] There is also the matter of, you know, the fact that they have not used digital signature to validate the code. And again, you know, 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, trust certificates, encryption has rapidly evolved to accommodate, you know, 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.

Dave Bittner: [00:12:00] You know, 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.

Itzik Kotler: [00:12:16] 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, Peleg Hadar – his name 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, does this service, this software, have 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. But as you mentioned, the sound driver, being a legitimate driver loaded into the kernel, one can even exploit this delicate relationship to 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 persistence mechanism, but also roaming into the kernel end and make even more subversion into the machine security at large.

Dave Bittner: [00:13:34] I see. Now, was there any evidence that anyone was taking advantage of this vulnerability?

Itzik Kotler: [00:13:40] Not not that we know of. You know, every now and then we do try to, again, use our sources to look around, understand, you know, whether this is something that already existed or, you know, 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 Realtek 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.

Itzik Kotler: [00:14:11] And I think it also raises a good point, you know, 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'd say it's a win-win.

Dave Bittner: [00:14:32] 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.

Itzik Kotler: [00:14:50] 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 know, this responsible disclosure process. I'm not saying that there is not times that you need to kind of, you know, break things out and venture on your own to get the vendor's attention. Luckily, again, we did manage to get the vendor's attention. It took some time to explain, you know, the vulnerability. It took some time to read their response and trying to kind of use their, you know, 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.

Itzik Kotler: [00:15:42] And so, going back and forth, trying to explain the scenario, trying to explain the different technicalities, we're very happy that Realtek understood that and basically proceeding to fixing it. And again, as you can see, the result is documented in the timeline. But nonetheless, there is a CVE issued, and more importantly, there is a patch that has been circulated. So, we put an end to the problem.

Dave Bittner: [00:16:07] 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?

Itzik Kotler: [00:16:23] I think it's a very good question. I think this issue demonstrates, again, a little bit of the old ways where assumptions about, you know, artifacts – whether it's paths, filenames, you know, 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 – come across as an overkill.

Itzik Kotler: [00:17:01] 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.

Itzik Kotler: [00:17:32] 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 where you can share the initial certifications and encryptions.

Itzik Kotler: [00:18:03] 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 mistaken – a little bit over twenty different CVEs for many different big vendors in the market, I really hope this will move the needle going forward.

Dave Bittner: [00:18:30] That's Itzik Kotler from SafeBreach.

Dave Bittner: [00:18:37] Thanks to Juniper Networks for sponsoring our show. You can learn more at juniper.net/security, or connect with them on Twitter or Facebook.

Dave Bittner: [00:18:45] And thanks to Enveil for their sponsorship. You can find out how they're closing the last gap in data security at enveil.com. 

Dave Bittner: [00:18:53] Funding for this CyberWire podcast is made possible by RSA Conference, where the world talks security. Through global events and year-round content, RSAC connects you to cybersecurity leaders and cutting-edge ideas for a safer, more secure future. Learn more at rsaconference.com.

Dave Bittner: [00:19:14] The CyberWire Research Saturday is proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technologies. Our amazing CyberWire team is Elliott Peltzman, Puru Prakash, Stefan Vaziri, Kelsea Bond, Tim Nodar, Joe Carrigan, Carole Theriault, Ben Yelin, Nick Veliky, Bennett Moe, Chris Russell, John Petrik, Jennifer Eiben, Peter Kilpe, and I'm Dave Bittner. Thanks for listening.