- [Jake] Hello, DEF CON. Welcome to my talk, Bring Your Own Print Driver Vulnerability.
00:07 - In this talk, I’ll discuss how a standard, low-privileged user can install print drivers of their choosing, by design, on Windows systems.
00:16 - And I’ll show how a local attacker can escalate to SYSTEM using a handful of different print drivers.
00:22 - Now, I want to say upfront that I won’t be talking about PrintNightmare.
00:26 - PrintNightmare, at this point, is supposed to be a patched vulnerability, whereas what I’m going to talk about in this presentation is likely a built-in feature that will be difficult to patch.
00:38 - I also had to record this shortly after PrintNightmare was released, so even if I wanted to incorporate it, there really just wasn’t enough time.
00:49 - Now, this talk is roughly broken down into four parts.
00:53 - To start, I’ll discuss some research that influenced this talk.
00:57 - Then, we’ll explore how a standard user can install a print driver.
01:02 - Next, we’ll discuss actual exploitation, and I’ll introduce a tool I wrote.
01:08 - Finally, I’ll touch on detecting this sort of attack in the wild, and mitigations that may prevent it.
01:15 - I’ll also give a quick rundown of the vulnerability disclosure timelines associated with this talk.
01:24 - Now, in my opinion, slides are just an educational tool.
01:28 - While it’s all well and good for me to present them, it’s also important for the viewer to read them at their own pace, click links, read background material, and try out code snippets.
01:39 - There are also exploits associated with this talk, and because of all that, the code and slides are available at the following GitHub repository.
01:49 - The name of the repo will make a little bit more sense, later on in the talk.
01:57 - Finally, before we get too far into it, I’d like to introduce myself.
02:02 - My name is Jake Baines, and I’m a vulnerability researcher.
02:06 - I like to use the handle Albino Lobster, which is why you’ll see this little lobster almost everywhere I’m active online.
02:13 - My most well-known work is probably my micro-tech work, although it isn’t well-known at all, but I have had the good fortune to be able to present at a few conferences, including DEF CON 27.
02:26 - I’m currently employed by Tregos. However, all the work I’m discussing today was done while I was employed by Dark Wolf Solutions in fall 2020.
02:37 - Dark Wolf very kindly gave me permission to share this work, for which I am truly grateful.
02:42 - So thank you very much to them. Now, there are some researchers that cut their own path and break new ground, but I’m just not one of those people.
02:55 - To learn the printer subsystem and arrive at the conclusions I did, I had to stand on the shoulders of many more talented researchers that came before me.
03:04 - I think it’s important, and useful, to understand the work that influenced my final outcome.
03:10 - So, let’s quickly discuss some previous printer vulnerabilities.
03:19 - The first issue I want to familiarize you with is CVE-2019-19363.
03:28 - This is a vulnerability in a third-party print driver.
03:31 - The driver was developed by Ricoh, and it allows for privilege escalation to SYSTEM by overriding a DLL.
03:39 - Pentagrid handled the disclosure and published a nice proof of concept, while Shelby Pace of Rapid7 developed the Metasploit module.
03:48 - It’s a good vulnerability, but the driver has to be installed on the system in order to exploit it.
03:54 - So it is sort of limited in that capacity. This is a good one to remember for later in the talk, as we will reference it again.
04:05 - Of course, there is CVE-2020-1048, which is better known as PrintDemon.
04:11 - Now, it got a lengthy and a bit of a meandering writeup on the Windows Internals blog.
04:17 - But if you spend some time with it, that blog provides really good exposure to some of the important WIN API function calls associated with printers.
04:26 - The vulnerability itself allows a local attacker to print to arbitrary files as SYSTEM, after restarting the spooler, resulting in privilege escalation.
04:36 - The image here is actually from the VoidSec blog that talks about the vulnerability.
04:42 - And what you see is the UI rejecting the attack due to insufficient permissions.
04:47 - However, a similar call, via the WIN API, was allowed, resulting in the vulnerability.
04:58 - And of course, there was the patch bypass for PrintDemon.
05:01 - A variety of people were actually credited with this CVE.
05:05 - But VoidSec did the best writeup, in my opinion.
05:09 - This is a really simple attack, where after the file permission checks have been done, the attacker just swaps the file port with a junction.
05:16 - And then they just execute the normal PrintDemon attack.
05:21 - It’s really just that easy. I like Rapid7’s AttackerKB, because it’s an easy way to get other attackers’ thoughts on vulnerabilities.
05:31 - As you can see, CVE-2020-1337, still just a local privilege escalation, is rated as very high.
05:42 - Finally, CVE-2020-1300 or Evil Printer, was presented at DEF CON 28 last year.
05:50 - Again, this is a local privilege escalation using the printer subsystem, but this time, with the CAB file delivered by remote printer.
05:59 - ZDI wrote up some technical details about the CAB file, but other than Steven Seely’s Sweet November, I haven’t seen anyone publish a full exploit for this one.
06:10 - Now, I loved the DEF CON 28 presentation, and it served as a jumping off point for my own research.
06:21 - And because Evil Printer was so important to me and my thought process, I want to spend a few minutes just walking through the attack in its entirety.
06:35 - The attack setup requires two things: a standard user account on a Windows machine, and an Evil Printer to serve up a malicious CAB file.
06:45 - The standard user simply uses the Add Printer interface to connect to the Evil Printer, which triggers the CAB download and unpackaging.
06:56 - The CAB file contains a file path with a directory traversal that gets unpacked anywhere on the system the attacker would like, essentially allowing the attacker to plant a DLL or overwrite an executable to escalate to SYSTEM.
07:14 - As Steven Seely’s Tweet suggested, generation of a malicious CAB is actually quite easy.
07:21 - Here, I generate a CAB file containing a file called ualapi. dll, that, due to the path traversal, will get right into the SYSTEM32 directory.
07:32 - Of course, ualapi. dll is a known missing DLL that an attacker can plant in order to escalate to SYSTEM on reboot.
07:45 - And of course, if you’re interested in recreating the CAB yourself, here’s the source of the DLL I generated.
07:52 - Anyone familiar with Pentagrid’s Ricoh exploit will know I basically stole the snippet from them.
07:58 - But either way, if you go to the linked repository, you’ll find a project file that will compile the DLL.
08:06 - Obviously, this is nothing special or exciting.
08:10 - I just want to point out that this DLL executes whoami and writes the output to c:\output. txt.
08:18 - We will refer back to this throughout the talk.
08:24 - The more complicated part of the Evil Printer attack is setting up the Evil Printer.
08:30 - And as I’ve suggested, this method is lifted entirely from last year’s DEF CON presentation.
08:36 - Now, for whatever reason, CutePDF Writer has implemented delivery of a CAB file to remote clients via Package Point and Print.
08:46 - So we can rely on the CutePDF Writer to do all of our heavy lifting.
08:51 - If you prepare a Windows box in your control with the steps in this slide, then you’ll be ready to serve up malicious CAB files.
09:03 - The next step is the actual exploitation. As a standard, low-privileged user, using the Add Printer UI, connect to the Evil Printer you just configured.
09:18 - When the attacker connects to the printer, the CAB file is downloaded and unpackaged, which means our malicious DLL gets dropped into SYSTEM32.
09:28 - We also see this popup regarding installation of a driver, which requires administrator approval.
09:36 - However, at this point, our attack has already been successful.
09:40 - So we can just hit Cancel. After rebooting the system, the ualapi. dll we dropped in SYSTEM32 is loaded into a system process and executed.
09:55 - As you see, the result. txt created by the DLL contains the result of whoami, which, when the DLL was executed, was SYSTEM.
10:06 - A successful privilege escalation, and a really great attack, in my opinion.
10:11 - It’s only complicated by the requirement of an Evil Printer, but in most attack scenarios, that shouldn’t be a dealbreaker.
10:23 - Like I said, there wasn’t a public exploit for this, at least that I was aware of, so I’ve published my own.
10:30 - It’s wrapped up into a tool that we’ll talk about later.
10:33 - So I won’t explain the silly name or how to use the exploit.
10:37 - We’ll get there later. Just know a public exploit exists now, and it’s in the repository I mentioned earlier.
10:47 - So, last fall, after this had been patched, I was exploring this attack surface, and I was thinking about this Install Driver prompt.
10:57 - I was interested if driver installation always required administrative rights, or if I could bypass that somehow.
11:08 - So I decided to spend some time learning how a standard, low-privileged user can install a print driver on their system.
11:19 - But first we need to pick a driver that we would actually want to install.
11:24 - As an attacker, I’d love to install this vulnerable Ricoh driver that we talked about earlier.
11:31 - As a reminder, the vulnerability in this driver is a race condition to overwriting a DLL during the AddPrinter call.
11:40 - If timed correctly, a standard user can escalate to SYSTEM.
11:47 - Now, one of the requirements to AddPrinter is, of course, the driver name the new printer will be using, which is all well and good when the driver is available, like in this screenshot.
12:01 - The AddPrinter call would be successful on this target.
12:09 - But when the driver isn’t present, AddPrinter will obviously fail.
12:14 - So it should be fairly obvious why I’m interested in finding ways to install the driver without needing administrator privileges.
12:22 - If I can trick the system into loading the driver somehow, then I can install the driver as a standard, low-privileged user, and exploit the driver’s vulnerability: an attack that I’d like to call Bring Your Own Print Driver Vulnerability.
12:42 - So how can a standard user try to install the vulnerable print driver? There actually is a surprising amount of legitimate options.
12:51 - I listed a bunch here, and we’re going to quickly look at what happens when they’re invoked by a standard user.
13:01 - First of all, thank you to Pentagrid for leaving links to the Ricoh installer in their blog.
13:08 - That did prove very helpful to me. The Ricoh installer for the vulnerable driver isn’t so much an installer, but just right-clicking on an INF file to invoke the INF installer, which just so happens to require administrative rights, so that’s not really all that useful for the standard user.
13:32 - Pointing the printer user interface at the INF file yields similar results.
13:37 - So that’s another no-go for the standard user.
13:43 - PowerShell fails with a very ugly and sort of useless error message.
13:48 - However, looking up the command in MS documentation, we find this useful tidbit: “The INF file should exist in the driver store. ” Well, what is that? Well, just hold on.
14:01 - We’ll circle back to that. Invoking printui. dll yields the exact same result as just using the UI, kind of what you’d expect.
14:15 - So yet another failure for the standard user.
14:20 - And yet again, another failure when trying to use prndrvr. vbs.
14:31 - And while there are too many MS API functions for printers, Print Daemon specifically uses InstallPrinterDriverFromPackage, because a standard user could invoke it, if, as highlighted here, a driver is in the driver store.
14:51 - So, it seems like getting the print driver into the driver store would be really useful.
14:58 - How do we go about doing that? Well, let’s talk about it.
15:06 - In this section, we’ll finally see how to get the Ricoh driver onto the system as a standard user.
15:19 - A good place to start is, what is the driver store? The answer is that it’s a trusted location on the system, where signed and verified driver packages are stored.
15:31 - Adding a driver to the driver store is referred to as staging, likely so it isn’t confused with installation.
15:40 - Staging a driver in the driver store is not the same as installing it.
15:50 - Only administrators can stage drivers. Probably the best tool for enumerating, adding, and removing drivers is the Plug ‘n’ Play util tool.
16:01 - In this screenshot, the administrator adds the vulnerable Ricoh driver to the driver store.
16:09 - And once the vulnerable Ricoh driver is in the driver store, a standard, low-privileged user can install it while adding a new printer.
16:18 - Now, obviously, this talk is about a standard, low-privileged user adding a driver to the driver store, and not an administrator, like in the previous slide.
16:29 - But I want to highlight how owning the driver store is all we need to be able to then exploit the Ricoh driver.
16:39 - So, finally coming full circle, we sought to discover if a low-privileged user can introduce arbitrary drivers to the system.
16:49 - We tested multiple methods of installing the vulnerable Ricoh driver, and we checked out how the driver store works.
16:59 - Is there any way to stage a print driver as a standard, low-privileged user? And the answer, of course, is yes.
17:12 - A standard, low-privileged user can stage drivers into the driver store by connecting to a printer that uses Package Point and Print, just like Evil Printer.
17:23 - The package of a CAB file, if signed, will be staged in the driver store.
17:33 - So an attacker that controls an Evil Printer and a standard Windows account can stage drivers of their choosing.
17:42 - A client need only invoke the GetPrinter driver MS API function.
17:51 - The printer responds with the driver, and the system verifies the driver’s integrity before finally dropping it into the driver store.
18:01 - It’s really just that easy. So let’s try it ourselves.
18:05 - We need to create a CAB file for our vulnerable Ricoh driver.
18:13 - As we talked about earlier, the Ricoh installer just sort of left us this exploded directory.
18:21 - Well, we can roll all that up into a CAB file using makecab.
18:29 - Obviously, the CAB file we generate isn’t signed.
18:34 - But fortunately for us, Windows doesn’t care about that.
18:38 - When unpackaging the CAB, the system will hunt out the security catalog that I’ve highlighted.
18:47 - The Security Catalog itself is signed by Microsoft Windows hardware compatibility publisher.
18:55 - And the catalog contains hashes of each file that the driver needs.
19:00 - Now, if you have sharp eyes, you might ask, “Does it matter if the ‘valid to’ date has expired?” And the answer is, no.
19:08 - The system doesn’t care at all about that. So we’ve created a Ricoh CAB that is cryptographically acceptable to the Windows printer subsystem.
19:22 - Now, we just need to configure the Evil Printer just as we did earlier in the talk.
19:28 - I’ll leave that as an exercise for home, since it’s the exact same setup we discussed before, and I’ll share a tool in a bit that automates all of that.
19:43 - Now, once the Evil Printer is all set up, we can connect to it as a standard, low-privileged user, via the Add Printer UI.
19:52 - If successful, we should see a new entry in the driver store.
20:00 - Here, we’ve established our connection to the Evil Printer, and I’ve highlighted our Ricoh driver staged in the driver store.
20:08 - The only downside here is that we’ve triggered Windows Update.
20:12 - Later, we’ll discuss how to avoid triggering the update and really, the UI altogether.
20:21 - We can now see that our Ricoh driver is staged via the Print UI.
20:25 - So a low-privileged user can now use it to add a printer, and most importantly, exploit it to achieve SYSTEM.
20:35 - Now, that’s the whole thing: using a remote printer to stage drivers, and exploiting the staged driver.
20:43 - Literally, Bring Your Own Print Driver Vulnerability.
20:52 - Is this a vulnerability in Windows? Uh, yes.
20:55 - I think so. As I just said, we clearly crossed a security boundary by adding a driver into the driver store.
21:04 - And the result of crossing that security boundary is that we’re able to escalate to SYSTEM.
21:15 - But is this actually a vulnerability in Windows? Uh, no.
21:21 - It’s a feature that’s working as designed. This is exactly how printers are supposed to work.
21:28 - The system is supposed to automatically download and stage the package so that the user can add a new printer.
21:35 - And, as we all know, features aren’t vulnerabilities.
21:40 - We can dislike the feature, and believe it’s flawed, but at the end of the day, a feature really just isn’t a vulnerability.
21:51 - But really, is this a vulnerability in Windows? Uh, I’d say, honestly, I’m not sure.
21:59 - And I’m not sure I really care all that much.
22:02 - But I think both arguments are true. At the end of the day, I can escalate to SYSTEM.
22:07 - You can call it a bug. You can call it a feature.
22:10 - The result is the same, either way: escalation to SYSTEM.
22:21 - Is this useful? Of course this is useful.
22:24 - As long as you can establish a remote connection to an Evil Printer in your control, you can escalate to SYSTEM.
22:33 - What’s more is that I’m not sure it’s a patchable issue.
22:38 - It’s working as designed, and it works for Windows versions back to at least Windows 7.
22:44 - Maybe Vista. I actually didn’t get a chance to try.
22:48 - What’s more, though, is it makes old or unlikely to be seen in the wild print drivers, like Ricoh, really valuable, since now we can just pop them on the box at will and exploit them.
23:07 - So that’s the entire concept. A standard user can add a print driver of their choosing and exploit it to obtain SYSTEM privileges.
23:18 - But of course, no one wants to do that manually.
23:22 - So I’ve developed a tool that automates the process.
23:26 - The tool is called Concealed Position. So here’s an early screenshot of the GitHub repo and a link.
23:34 - As of August 7th, this should be open to everyone.
23:41 - Now, Concealed Position is developed in C++ and has three major components.
23:48 - The first is the server, for configuring the Evil Printer.
23:53 - The second is the client, for staging the driver and executing the privilege escalation.
23:59 - And finally, the DLL that gets executed with SYSTEM privileges.
24:08 - Concealed Position currently has four exploits you can choose from.
24:12 - SlashingDamage and PoisonDamage are the two we’ve already spoken about.
24:16 - That’s CVE-2020-1300, and PoisonDamage is the Ricoh driver.
24:24 - But it also has two more vulnerable drivers that I found, and while recording this, I’m still in the middle of disclosing to the vendors, which we will talk about at the end of this talk.
24:39 - The first one is AcidDamage, which is a vulnerability in Lexmark’s universal print driver.
24:45 - And the second is RadiantDamage, which is a vulnerability in Canon’s TR150 print driver.
24:52 - Concealed Position can also be executed in a local-only mode, when the drivers already exist in the driver store.
25:03 - Now, here’s a sample screenshot of the server.
25:06 - And as you can see, it’s simple to invoke. You just select the exploit you want to use.
25:16 - And the client is similar, except you need to either specify local exploitation, or provide the Evil Printer address and the name of the Evil Printer you’re going to connect to.
25:34 - And here’s the tool after executing an attack using AcidDamage.
25:38 - Again, we see the DLL used just echoes whoami to the result. txt file you see pictured here.
25:52 - In one of the previous slides, we saw that connecting to the Evil Printer using the Add Printer UI triggered Windows Update, which is obviously a no-go during a real attack.
26:05 - By using the WIN API calls listed in the slide, the client is able to avoid Windows Update and the UI altogether.
26:13 - In the first stage, which is the connection to the remote printer, the attacker utilizes GetPrinterDriver.
26:21 - In the second phase, the driver is installed from the driver store using InstallPrinterDriverFromPackage.
26:29 - Exploitation typically then occurs during the AddPrinter call.
26:37 - Now, there’s a lot of love for PowerShell out there, and I think it’s the obvious tool for a lot of people.
26:43 - So some might wonder why I didn’t develop Concealed Position in PowerShell.
26:48 - Well, first of all, I just happen to love C++, and it’s really sort of the language that I think in first.
26:55 - But I think it’s also good to know, if you do want to use PowerShell, the AddPrinter using ConnectionName will stage the driver into the driver store.
27:07 - But it also triggers Windows Update as well.
27:10 - But if you like PowerShell, that’s probably easy enough to work around.
27:14 - If you want to develop your own tool, you should definitely pursue that.
27:23 - All right. So we’ve talked about the attack.
27:25 - And I’ve showed off my tools. So let’s talk about the new driver vulnerabilities that I found.
27:35 - The first one is AcidDamage, and like I said earlier, it’s an issue with Lexmark’s universal print driver, affecting versions 2. 15. 1. 0 and below.
27:47 - This has been assigned CVE-2021-35449. The issue is that during AddPrinter, a world writable file is parsed for DLLs.
27:59 - An attacker can just insert a path traversal to a DLL under their control, resulting in escalation to SYSTEM.
28:09 - Very, very simple. Now, obviously, the exploit has an implementation in Concealed Position.
28:21 - But I’ve also developed a Metasploit module for this as well.
28:25 - Now, the module doesn’t use an Evil Printer.
28:27 - It’s just a local-only attack. However, one of the challenges of recording this so far in the past, like I said, I’m recording this in mid-July.
28:37 - It’s July 13th. So the challenge here is that I can’t really show an open pull request until August 7th.
28:45 - So I can’t link it here. But trust me, when the morning of August 7th rolls around, I will open that pull request.
28:56 - Now, remember, to use this attack with the Evil Printer, we need to generate a CAB file.
29:03 - Now, we can cheat and just download version 2. 10. 0. 5 from the Windows Update Catalog.
29:11 - So that works fine. So why not? The CAB file downloaded from Windows Catalog is also signed by Microsoft.
29:23 - So that’s kind of a neat thing we can’t recreate, just by using makecab.
29:33 - But if you want to use the latest version, we can do that, too.
29:38 - First, we just have to grab the Lexmark installer, and it will dump the required files off of C:\Lexmark.
29:48 - We can use the same technique as before, using dir to generate our files list.
29:54 - Except makecab doesn’t respect directories unless you tell it to, so you have to modify the files. txt file to let makecab know that the driver needs the directory structure to be respected.
30:07 - But that’s really it. Pass the modified files. txt to makecab, and we have a CAB file to use with Concealed Position.
30:16 - Again, our generated CAB file isn’t signed, but it contains a valid Security Catalog.
30:27 - The next vulnerable driver, RadiantDamage, is an issue I discovered in the driver for Canon’s PIXMA TR150 mobile wireless printer.
30:38 - The TR150 driver 3. 71. 2. 10 and below is affected.
30:44 - And again, this is a local privilege escalation during the AddPrinter process.
30:53 - This issue has not been assigned a CVE yet, at time of recording.
30:58 - So I guess we’ll discuss that in a bit. Similar to the Ricoh vulnerability, this is a race condition to overwrite a DLL in ProgramData.
31:11 - If you can time it correctly, the overwritten DLL will get picked up by printIsolationHost and executed as SYSTEM.
31:19 - Again, very simple. I found that this is a bit difficult to time, a little bit harder than AcidDamage is.
31:29 - But it usually takes no more than a couple of minutes to finally hit.
31:37 - Again, we need a CAB file to work with Concealed Position server.
31:41 - And again, you can actually download the TR150 driver from the Update Catalog.
31:48 - So we can simply download it, and we have a signed, well-formed, most current version of a totally exploitable driver to use.
32:02 - Now, of course, it might be useful to know how to generate our own still.
32:07 - The Canon installer will download the following files into a directory in AppData.
32:12 - Note the flat file structure. Because of the flat file structure, it’s trivial to package up using makecab.
32:23 - We just do exactly what we did for the Ricoh CAB, and just like that, we generated our own correctly-formed TR150 CAB.
32:36 - Again, you can find the implementation of RadiantDamage at the following link.
32:41 - And again, there is a Metasploit module. I just couldn’t include the link because I recorded so far in the past.
32:54 - So that’s all for the exploitation sections.
32:57 - And I hope you found it interesting. But I now want to touch on detection and mitigation, for those of us that have to defend against this sort of thing in the real world.
33:08 - Now, my full-time job is not defending. So these are best effort.
33:15 - Forgive me if I have overlooked anything obvious.
33:24 - So the first detection is from the event log.
33:27 - Event ID 600 is great for catching CVE-2020-1300, or what I call SlashingDamage, or what is known as the original Evil Printer.
33:40 - This is the path traversal presented at last year’s DEF CON.
33:44 - And you can even see in the description that it mentions that the failure can occur due to a bad or missing signature, which is exactly what the original Evil Printer serves up.
34:02 - Event 215 catches all the other issues, at least as I’ve coded them up.
34:08 - Here, you can see the exploitation caused the print driver to fail to install correctly during the AddPrinter process.
34:21 - You can also investigate the setupapi. dev file and see windows/inf.
34:28 - Now, this could quite tedious, as it’s very verbose and quite long.
34:33 - But it’s actually great documentation for any driver that has been introduced to the system, or even a driver that has been attempted to be introduced to the system.
34:48 - And of course, you can detect the attack over the wire, as long as SMB encryption isn’t enabled.
34:56 - The challenge here, of course, is that this attack uses totally legitimate behavior.
35:02 - Although, depending on your environment and where the Evil Printer is located, this might be a good way to detect the attack.
35:09 - For instance, it’s probably a bad thing if one of your systems is reaching out to a printer over the internet.
35:24 - I’ve also embedded a unique string into Concealed Position’s client.
35:28 - I chose the client, because that’s typically the victim system.
35:33 - So if we’re using YARA, or any other signature-based system, you should be able to identify use of cp_client, based on this string.
35:42 - Naturally, smart attackers are going to review the code I’ve written and remove this line.
35:50 - But there are a lot of dumb attackers out there, too.
35:52 - So hopefully if this ever does get used in the wild, this will help stop that.
36:03 - Now, one of the challenges with mitigations is I doubt this will ever see any real patch.
36:12 - You know, installing a printer is meant to use these mechanisms.
36:18 - So I think the best you can do is just ensure that the affected drivers aren’t on your systems already, and then enable the Package Point and Print - Approved Servers in GPO.
36:31 - Now, of course, that will make it very difficult for your end users to add printers.
36:37 - That’s sort of the entire issue, isn’t it? Printers can’t be trusted.
36:46 - And finally, I’d like to discuss the disclosures of the vulnerabilities, and suggest some future work.
36:58 - So after getting my DEF CON acceptance and talking to Dark Wolf, I sent similar disclosures to Lexmark, Canon, and Microsoft.
37:07 - All were provided descriptions and exploit code, all very similar disclosures, really.
37:13 - And they were all informed of the August 7th disclosure date.
37:22 - Excuse me. Lexmark was awesome. And this is exactly how you want disclosure to go.
37:28 - They acknowledged receipt immediately. I sent the disclosure on a Friday, because I’m a monster, and they confirmed the issue on a Monday.
37:37 - And it only took a little more than a week to send me a beta patch, which is really impressive.
37:44 - You can see at the end here that Lexmark intends to release a patch shortly after I record this talk, so by the end of the week of July 12th.
37:54 - And Lexmark has been a great communicator, overall.
37:59 - They even went as far as wishing me good luck on my DEF CON talk, which I never actually told them about.
38:05 - So I thought that was pretty clever. So a shoutout to Braden, if you’re listening.
38:11 - Now, the only real problem with this disclosure is it took MITRE two weeks to assign a CVE, which is really frustrating from a researcher’s point of view, if they can’t move faster than that.
38:23 - They literally have two jobs: assigning and publishing CVEs that other people write.
38:28 - You know, how hard is that? Otherwise, great disclosure.
38:34 - Lexmark is awesome. So Canon and Lexmark were sent very similar content, to the point that I accidentally left the word Lexmark in a spot in my Canon disclosure.
38:51 - And disclosure with Canon started off very well.
38:53 - They asked clarifying questions on the affected component, but then nothing.
39:00 - By July 9th, they had the vulnerability for three weeks and they hadn’t confirmed the issue.
39:06 - They haven’t denied the issue. They didn’t indicate if they tried the PoC, or if they’d even looked at the PoC, even though I keep asking.
39:16 - Now, they did release a security patch on July 4th.
39:19 - But after looking at it, it doesn’t affect the vulnerability I reported.
39:26 - And they, for some reason, didn’t mention it to me until eight days later.
39:31 - But basically, I’m not sure where the confusion lies with Canon, that they aren’t giving me any type of feedback so that I can help them, and I think at some point I’ll probably have to loop in CERT/CC so that this gets a CVE hopefully by August 7th.
39:53 - The Microsoft disclosure has been reasonable.
39:56 - As you can see from the timeline, there was a fair amount of back and forth about recreating the issue.
40:03 - But eventually, I guess the proof of concept video got there, which probably just means my written instructions weren’t very good.
40:12 - Now, while they did acknowledge the issue on July 12th, I actually don’t expect any type of CVE here or security bulletin.
40:20 - But really, I just wanted Microsoft to be aware that this is a thing they designed into their system, and that I’m going to talk about it on August 7th.
40:29 - So, mission accomplished. But I honestly am not sure how they can address this, without breaking normal printer workflows.
40:43 - You know, I think it is very funny how these three different disclosures were all very similar content, but they all had very differing results.
40:54 - So one turned out good. One turned out bad.
40:57 - (Jake laughs) And one spent a lot of time, and can’t reproduce.
41:06 - So, last slide. Future work. Like I said, any print driver that is compatible with the driver store is fair game, new or old.
41:14 - Really, very old is even up for grabs here.
41:18 - So there are many drivers that could be analyzed and added to Concealed Position.
41:24 - There’s also nothing special about CutePDF.
41:27 - It’s only there because I couldn’t get Samba to do what I wanted, and didn’t have the time to write my own implementation of delivering a Package Point and Print CAB file.
41:39 - Now, hopefully in the future, I or someone else will code that up, so that others can use an Evil Printer as they choose.
41:49 - Once that is done, this attack would be great paired with a USB attack.
41:56 - And finally, Concealed Position could use polishing.
42:00 - Like most exploits, it was written only to prove that the attack was possible.
42:06 - So it’s a little messy at the moment, and some of the mechanisms around dropping DLL and customizing payloads could be extended.
42:16 - Otherwise, that’s it. Thank you all so much for listening.
42:21 - Thank you very much to Dark Wolf for letting me share.
42:23 - And thank you again, DEF CON, for both the support and allowing me to present.
42:30 - Again, thank you all. .