On the hunt for popping up kernel drives.

Dave Bittner: 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 the threats and vulnerabilities, solving some of the hard problems and protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. [ Music ]

Dana Behling: As part of this research, we were looking at new and novel ways that you could leverage vulnerable drivers or drivers in general in an attack sequence.

Dave Bittner: Our guest today is Dana Behling, a researcher from VMware Carbon Black's Threat Analysis Unit. The research we're discussing today is titled, "Hunting Vulnerable Kernel Drivers." [ Music ]

Dana Behling: Well, bring your own horrible attacks are becoming a more common on the threat landscape in general. One of the most important reasons that VMware and Carbon Black are interested in them is that drivers are commonly used to turn off security processes, and being a security process ourselves, we don't want that to happen, right? So, as part of this research we were looking at new and novel ways that you could leverage vulnerable drivers or drivers in general in an attack sequence.

Dave Bittner: Well, let's dig into the research together here. Can you give us an overview exactly what are we looking at here today?

Dana Behling: So, the research was initially conducted by my colleague, Takahiro Haruyama and he was looking at a method to automate the process of searching for vulnerable drivers. When he initially created his framework for looking for the vulnerable drivers, we found such a huge number of vulnerable drivers. We ended up, or he ended up having to scale it back a bit. So, what we did was we looked for only vulnerable drivers that could access very specific kernel resources, so a specific function call within the kernel driver framework. And what his research demonstrated was that the function call for rewriting firmware; firmware is the software that resided on the actual hardware chips themselves. The reason that it's so important to protect firmware from rewriting is that, well first of all, most people don't pay attention to it. Once they purchase a hardware device, whatever firmware is on it is that what's going to be on it for the, you know, until the device is discarded. But secondly, and even if you reinstall your operating system, that firmware will stay there, right? So, if an actor is able to rewrite that software that's on the hardware itself, there is a very, very small chance that it will get upgraded to, you know, a patched version just because people aren't paying attention to it and secondly, it will allow the attack or whatever the purpose is for rewriting the hardware, to live on until that device is discarded.

Dave Bittner: Well, let's go through the research together here. What was the process by which you all hunted these down?

Dana Behling: So, one of the most troublesome things about vulnerable drivers is that by necessity, the kernel is divided into two different sections; there is the kernel mode and the user mode, okay, in an operating system. The kernel mode is where all of the protected processes happen, and the user mode is like the public area. I consider it sort of like -- like a bank, right? There's the public area and then there's the private area. The private area is the kernel mode; the public area is the user mode. Because hardware, the users need to make changes in the kernel mode. There is these things called I/O control commands, I-O-C-T-L, which allows a user to send a command from the user mode, the unprotected spot of the operating system, into that very protected spot, and by making those commands, you can affect the kernel resources and negate all the things that Windows or Microsoft has put into place to protect the kernel itself. Takahiro's research showed that you could make calls directly to a function called "MMIO space" which allows you to write memory directly to addresses in the real address space, because it allows you to map from the real addresses to the virtual addresses, which basically is like saying, rather than giving someone your home address like 123 Elm Street, you're giving them the GPS coordinates and so they can write directly to that place. [ Music ]

Dave Bittner: We'll be right back. [ Music ] And so, is this a case where there is a legitimate and needed functionality that is out there unprotected and that's what allows it to potentially be used for bad things?

Dana Behling: Sure. Well, I'm thinking that the reason that the original authors left that in there is so that way they would have the ability to upgrade the firmware themselves. But in this case, because it's left open to the world, anyone is allowed to "upgrade" the firmware, right, with whatever they want or not at all and just make the hardware completely unusable which was also demonstrated.

Dave Bittner: What is your sense for the degree to which this is a problem out there? How widespread this could be?

Dana Behling: So, the "bring your own" vulnerable driver attacks is extremely widespread. I think there has been less research into the area of firmware rewriting, which was one of the great and novel things that Takahiro was able to demonstrate, but in a larger sense, the "bring your own" vulnerable driver attack negates all of the patch guard and virtualization base security that Microsoft has implemented to allow any actor to access the protected resources in the kernel that are normally like thought of as being protected and all you really need is admin access to do it which there are numerous tools available, you know, even on GitHub to elevate a person's access to admin in order to enumerate all of these protected resources in the kernel that would normally not be accessible in a -- by a normal user.

Dave Bittner: Oh, you anticipated my next question which was, you know, with what degree of access do you have -- do you need to have? So, admin will get you in there with no problem?

Dana Behling: That's right. So, you can -- once you install the driver, in many cases for the vulnerable drivers, almost all of its resources are available to you. Microsoft does recommend that the driver author's themselves implement access, protected resources, and add an additional layer of security, but from what I've seen in drivers that's very rare.

Dave Bittner: Is this a case of kind of out of sight out of mind where there, I don't know, almost a security by obscurity thing where they're banking on the fact that not many people have firmware top of mind?

Dana Behling: I think that could be part of it. I think another part of it is is that, as a culture and industry we think of drivers as these very complex things that are not understandable by the normal person, but in reality, a driver is just another type of software just like in the user's space. It uses different libraries and it has some different rules that it has to abide by, but in reality, it's just software and it's -- it has all the same vulnerabilities plus additional vulnerabilities that other software has and that we're all very familiar with.

Dave Bittner: What are your recommendations then for folks who may be concerned about this? What sort of things can they put in place to protect themselves?

Dana Behling: There is a website LOLDrivers.IO and so that LOL stands for living off the land drivers. That provides a list of all of the drivers with known vulnerabilities. You can put those on a protected list, and if you have any of those drivers in your environment, the first thing that I would do is look to see if there is an updated version of that driver, and just like with all other software, you want to be running the most up-to-date version of your drivers so that way you aren't, you know, at risk of that vulnerable driver being used even without admin rights in your environment. Another thing you can do is have security products in place that are watching for drivers, new drivers being loaded. In most corporate environments, drivers should not be being installed on a regular basis. So, if you do see drivers being installed, that's a very good clue that a "bring your own" vulnerable driver attack is, you know, about to happen or has already happened. [ Music ]

Dave Bittner: Our thanks to Dana Behling from Carbon Black for joining us. The research is titled, "Hunting Vulnerable Kernel Drivers." We'll have a link in the Show Notes. [ Music ] The CyberWire "Research Saturday" podcast is a production of N2K Networks. N2K's Strategic Workforce Intelligence optimizes the value of your biggest investment, your people. We make you smarter about your team, while making your team smarter. Learn more at n2k.com. This episode was produced by Liz Irvin. Our mixer is Elliott Peltzman. Our executive producers are Jennifer Eiben and Brandon Karpf. Our executive editor is Peter Kilpe and I am Dave Bittner. Thanks for listening. We'll see you back here next time. [ Music ]