- [Jake] Hello, DEF CON.
Welcome to my talk,
Bring Your Own Print Driver Vulnerability.
In this talk, I'll discuss how a standard,
low-privileged user can install print drivers
of their choosing, by design,
on Windows systems.
And I'll show how a local attacker
can escalate to SYSTEM
using a handful of different print drivers.
Now, I want to say upfront
that I won't be talking about PrintNightmare.
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.
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.
Now, this talk is roughly broken down into four parts.
To start, I'll discuss some research
that influenced this talk.
Then, we'll explore how a standard user
can install a print driver.
Next, we'll discuss actual exploitation,
and I'll introduce a tool I wrote.
Finally, I'll touch on detecting
this sort of attack in the wild,
and mitigations that may prevent it.
I'll also give a quick rundown
of the vulnerability disclosure timelines
associated with this talk.
Now, in my opinion, slides are just an educational tool.
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.
There are also exploits associated with this talk,
and because of all that,
the code and slides are available
at the following GitHub repository.
The name of the repo will make a little bit more sense,
later on in the talk.
Finally, before we get too far into it,
I'd like to introduce myself.
My name is Jake Baines,
and I'm a vulnerability researcher.
I like to use the handle Albino Lobster,
which is why you'll see this little lobster
almost everywhere I'm active online.
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.
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.
Dark Wolf very kindly gave me permission to share this work,
for which I am truly grateful.
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.
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.
I think it's important, and useful,
to understand the work that influenced my final outcome.
So, let's quickly discuss
some previous printer vulnerabilities.
The first issue I want to familiarize you with is
CVE-2019-19363.
This is a vulnerability in a third-party print driver.
The driver was developed by Ricoh,
and it allows for privilege escalation to SYSTEM
by overriding a DLL.
Pentagrid handled the disclosure
and published a nice proof of concept,
while Shelby Pace of Rapid7 developed the Metasploit module.
It's a good vulnerability,
but the driver has to be installed on the system
in order to exploit it.
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.
Of course, there is CVE-2020-1048,
which is better known as PrintDemon.
Now, it got a lengthy and a bit of a meandering writeup
on the Windows Internals blog.
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.
The vulnerability itself allows a local attacker
to print to arbitrary files as SYSTEM,
after restarting the spooler,
resulting in privilege escalation.
The image here is actually from the VoidSec blog
that talks about the vulnerability.
And what you see is the UI rejecting the attack
due to insufficient permissions.
However, a similar call, via the WIN API,
was allowed, resulting in the vulnerability.
And of course, there was the patch bypass for PrintDemon.
A variety of people were actually credited with this CVE.
But VoidSec did the best writeup, in my opinion.
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.
And then they just execute the normal PrintDemon attack.
It's really just that easy.
I like Rapid7's AttackerKB,
because it's an easy way
to get other attackers' thoughts on vulnerabilities.
As you can see, CVE-2020-1337,
still just a local privilege escalation,
is rated as very high.
Finally, CVE-2020-1300 or Evil Printer,
was presented at DEF CON 28 last year.
Again, this is a local privilege escalation
using the printer subsystem,
but this time,
with the CAB file delivered by remote printer.
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.
Now, I loved the DEF CON 28 presentation,
and it served as a jumping off point for my own research.
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.
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.
The standard user simply uses the Add Printer interface
to connect to the Evil Printer,
which triggers the CAB download and unpackaging.
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.
As Steven Seely's Tweet suggested,
generation of a malicious CAB is actually quite easy.
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.
Of course, ualapi.dll is a known missing DLL
that an attacker can plant
in order to escalate to SYSTEM on reboot.
And of course,
if you're interested in recreating the CAB yourself,
here's the source of the DLL I generated.
Anyone familiar with Pentagrid's Ricoh exploit
will know I basically stole the snippet from them.
But either way, if you go to the linked repository,
you'll find a project file that will compile the DLL.
Obviously, this is nothing special or exciting.
I just want to point out that this DLL
executes whoami and writes the output to c:\\output.txt.
We will refer back to this throughout the talk.
The more complicated part of the Evil Printer attack
is setting up the Evil Printer.
And as I've suggested,
this method is lifted entirely
from last year's DEF CON presentation.
Now, for whatever reason,
CutePDF Writer has implemented delivery of a CAB file
to remote clients via Package Point and Print.
So we can rely on the CutePDF Writer
to do all of our heavy lifting.
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.
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.
When the attacker connects to the printer,
the CAB file is downloaded and unpackaged,
which means our malicious DLL gets dropped into SYSTEM32.
We also see this popup regarding installation of a driver,
which requires administrator approval.
However, at this point,
our attack has already been successful.
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.
As you see,
the result.txt created by the DLL
contains the result of whoami,
which, when the DLL was executed,
was SYSTEM.
A successful privilege escalation,
and a really great attack, in my opinion.
It's only complicated by the requirement of an Evil Printer,
but in most attack scenarios,
that shouldn't be a dealbreaker.
Like I said,
there wasn't a public exploit for this,
at least that I was aware of,
so I've published my own.
It's wrapped up into a tool that we'll talk about later.
So I won't explain the silly name
or how to use the exploit.
We'll get there later.
Just know a public exploit exists now,
and it's in the repository I mentioned earlier.
So, last fall, after this had been patched,
I was exploring this attack surface,
and I was thinking about this Install Driver prompt.
I was interested if driver installation
always required administrative rights,
or if I could bypass that somehow.
So I decided to spend some time
learning how a standard, low-privileged user
can install a print driver on their system.
But first we need to pick a driver
that we would actually want to install.
As an attacker,
I'd love to install this vulnerable Ricoh driver
that we talked about earlier.
As a reminder,
the vulnerability in this driver is a race condition
to overwriting a DLL during the AddPrinter call.
If timed correctly,
a standard user can escalate to SYSTEM.
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.
The AddPrinter call would be successful on this target.
But when the driver isn't present,
AddPrinter will obviously fail.
So it should be fairly obvious
why I'm interested in finding ways
to install the driver
without needing administrator privileges.
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.
So how can a standard user
try to install the vulnerable print driver?
There actually is a surprising amount of legitimate options.
I listed a bunch here,
and we're going to quickly look at what happens
when they're invoked by a standard user.
First of all,
thank you to Pentagrid
for leaving links to the Ricoh installer in their blog.
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.
Pointing the printer user interface at the INF file
yields similar results.
So that's another no-go for the standard user.
PowerShell fails
with a very ugly and sort of useless error message.
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.
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.
So yet another failure for the standard user.
And yet again,
another failure when trying to use prndrvr.vbs.
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.
So, it seems like getting the print driver
into the driver store would be really useful.
How do we go about doing that?
Well, let's talk about it.
In this section,
we'll finally see how to get the Ricoh driver
onto the system as a standard user.
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.
Adding a driver to the driver store
is referred to as staging,
likely so it isn't confused with installation.
Staging a driver in the driver store
is not the same as installing it.
Only administrators can stage drivers.
Probably the best tool
for enumerating, adding, and removing drivers
is the Plug 'n' Play util tool.
In this screenshot,
the administrator adds the vulnerable Ricoh driver
to the driver store.
And once the vulnerable Ricoh driver is in the driver store,
a standard, low-privileged user can install it
while adding a new printer.
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.
But I want to highlight how owning the driver store
is all we need to be able to then exploit the Ricoh driver.
So, finally coming full circle,
we sought to discover if a low-privileged user
can introduce arbitrary drivers to the system.
We tested multiple methods
of installing the vulnerable Ricoh driver,
and we checked out how the driver store works.
Is there any way to stage a print driver
as a standard, low-privileged user?
And the answer, of course, is yes.
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.
The package of a CAB file, if signed,
will be staged in the driver store.
So an attacker that controls an Evil Printer
and a standard Windows account
can stage drivers of their choosing.
A client need only invoke
the GetPrinter driver MS API function.
The printer responds with the driver,
and the system verifies the driver's integrity
before finally dropping it into the driver store.
It's really just that easy.
So let's try it ourselves.
We need to create a CAB file
for our vulnerable Ricoh driver.
As we talked about earlier,
the Ricoh installer just sort of left us
this exploded directory.
Well, we can roll all that up into a CAB file
using makecab.
Obviously, the CAB file we generate isn't signed.
But fortunately for us,
Windows doesn't care about that.
When unpackaging the CAB,
the system will hunt out the security catalog
that I've highlighted.
The Security Catalog itself is signed by
Microsoft Windows hardware compatibility publisher.
And the catalog contains
hashes of each file that the driver needs.
Now, if you have sharp eyes, you might ask,
"Does it matter if the 'valid to' date has expired?"
And the answer is, no.
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.
Now, we just need to configure the Evil Printer
just as we did earlier in the talk.
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.
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.
If successful,
we should see a new entry in the driver store.
Here, we've established our connection to the Evil Printer,
and I've highlighted our Ricoh driver
staged in the driver store.
The only downside here
is that we've triggered Windows Update.
Later, we'll discuss how to avoid triggering the update
and really, the UI altogether.
We can now see that our Ricoh driver is staged
via the Print UI.
So a low-privileged user can now use it to add a printer,
and most importantly,
exploit it to achieve SYSTEM.
Now, that's the whole thing:
using a remote printer to stage drivers,
and exploiting the staged driver.
Literally, Bring Your Own Print Driver Vulnerability.
Is this a vulnerability in Windows?
Uh, yes.
I think so.
As I just said,
we clearly crossed a security boundary
by adding a driver into the driver store.
And the result of crossing that security boundary
is that we're able to escalate to SYSTEM.
But is this actually a vulnerability in Windows?
Uh, no.
It's a feature that's working as designed.
This is exactly how printers are supposed to work.
The system is supposed to automatically download
and stage the package
so that the user can add a new printer.
And, as we all know,
features aren't vulnerabilities.
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.
But really, is this a vulnerability in Windows?
Uh, I'd say, honestly, I'm not sure.
And I'm not sure I really care all that much.
But I think both arguments are true.
At the end of the day,
I can escalate to SYSTEM.
You can call it a bug.
You can call it a feature.
The result is the same, either way:
escalation to SYSTEM.
Is this useful?
Of course this is useful.
As long as you can establish a remote connection
to an Evil Printer in your control,
you can escalate to SYSTEM.
What's more is that I'm not sure it's a patchable issue.
It's working as designed,
and it works for Windows versions
back to at least Windows 7.
Maybe Vista.
I actually didn't get a chance to try.
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.
So that's the entire concept.
A standard user can add a print driver of their choosing
and exploit it to obtain SYSTEM privileges.
But of course, no one wants to do that manually.
So I've developed a tool that automates the process.
The tool is called Concealed Position.
So here's an early screenshot of the GitHub repo and a link.
As of August 7th, this should be open to everyone.
Now, Concealed Position is developed in C++
and has three major components.
The first is the server,
for configuring the Evil Printer.
The second is the client,
for staging the driver
and executing the privilege escalation.
And finally,
the DLL that gets executed with SYSTEM privileges.
Concealed Position currently has four exploits
you can choose from.
SlashingDamage and PoisonDamage
are the two we've already spoken about.
That's CVE-2020-1300, and PoisonDamage is the Ricoh driver.
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.
The first one is AcidDamage,
which is a vulnerability
in Lexmark's universal print driver.
And the second is RadiantDamage,
which is a vulnerability in Canon's TR150 print driver.
Concealed Position can also be executed
in a local-only mode,
when the drivers already exist in the driver store.
Now, here's a sample screenshot of the server.
And as you can see, it's simple to invoke.
You just select the exploit you want to use.
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.
And here's the tool after executing an attack
using AcidDamage.
Again, we see the DLL used
just echoes whoami to the result.txt file
you see pictured here.
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.
By using the WIN API calls listed in the slide,
the client is able to avoid Windows Update
and the UI altogether.
In the first stage,
which is the connection to the remote printer,
the attacker utilizes GetPrinterDriver.
In the second phase,
the driver is installed from the driver store using
InstallPrinterDriverFromPackage.
Exploitation typically then occurs
during the AddPrinter call.
Now, there's a lot of love for PowerShell out there,
and I think it's the obvious tool for a lot of people.
So some might wonder why I didn't develop
Concealed Position in PowerShell.
Well, first of all,
I just happen to love C++,
and it's really sort of the language that I think in first.
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.
But it also triggers Windows Update as well.
But if you like PowerShell,
that's probably easy enough to work around.
If you want to develop your own tool,
you should definitely pursue that.
All right.
So we've talked about the attack.
And I've showed off my tools.
So let's talk about
the new driver vulnerabilities that I found.
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.
This has been assigned CVE-2021-35449.
The issue is that during AddPrinter,
a world writable file is parsed for DLLs.
An attacker can just insert a path traversal
to a DLL under their control,
resulting in escalation to SYSTEM.
Very, very simple.
Now, obviously,
the exploit has an implementation in Concealed Position.
But I've also developed a Metasploit module
for this as well.
Now, the module doesn't use an Evil Printer.
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.
It's July 13th.
So the challenge here is that I can't really show
an open pull request until August 7th.
So I can't link it here.
But trust me,
when the morning of August 7th rolls around,
I will open that pull request.
Now, remember, to use this attack with the Evil Printer,
we need to generate a CAB file.
Now, we can cheat and just download version 2.10.0.5
from the Windows Update Catalog.
So that works fine.
So why not?
The CAB file downloaded from Windows Catalog
is also signed by Microsoft.
So that's kind of a neat thing we can't recreate,
just by using makecab.
But if you want to use the latest version,
we can do that, too.
First, we just have to grab the Lexmark installer,
and it will dump the required files off of C:\Lexmark.
We can use the same technique as before,
using dir to generate our files list.
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.
But that's really it.
Pass the modified files.txt to makecab,
and we have a CAB file to use with Concealed Position.
Again, our generated CAB file isn't signed,
but it contains a valid Security Catalog.
The next vulnerable driver, RadiantDamage,
is an issue I discovered in the driver
for Canon's PIXMA TR150 mobile wireless printer.
The TR150 driver 3.71.2.10 and below is affected.
And again, this is a local privilege escalation
during the AddPrinter process.
This issue has not been assigned a CVE yet,
at time of recording.
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.
If you can time it correctly,
the overwritten DLL will get picked up by printIsolationHost
and executed as SYSTEM.
Again, very simple.
I found that this is a bit difficult to time,
a little bit harder than AcidDamage is.
But it usually takes no more than a couple of minutes
to finally hit.
Again, we need a CAB file
to work with Concealed Position server.
And again, you can actually download the TR150 driver
from the Update Catalog.
So we can simply download it,
and we have a signed, well-formed, most current version
of a totally exploitable driver to use.
Now, of course, it might be useful to know
how to generate our own still.
The Canon installer will download the following files
into a directory in AppData.
Note the flat file structure.
Because of the flat file structure,
it's trivial to package up using makecab.
We just do exactly what we did for the Ricoh CAB,
and just like that,
we generated our own correctly-formed TR150 CAB.
Again, you can find the implementation of RadiantDamage
at the following link.
And again, there is a Metasploit module.
I just couldn't include the link
because I recorded so far in the past.
So that's all for the exploitation sections.
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.
Now, my full-time job is not defending.
So these are best effort.
Forgive me if I have overlooked anything obvious.
So the first detection is from the event log.
Event ID 600 is great for catching CVE-2020-1300,
or what I call SlashingDamage,
or what is known as the original Evil Printer.
This is the path traversal
presented at last year's DEF CON.
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.
Event 215 catches all the other issues,
at least as I've coded them up.
Here, you can see the exploitation caused the print driver
to fail to install correctly during the AddPrinter process.
You can also investigate the setupapi.dev file
and see windows/inf.
Now, this could quite tedious,
as it's very verbose and quite long.
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.
And of course,
you can detect the attack over the wire,
as long as SMB encryption isn't enabled.
The challenge here, of course,
is that this attack uses totally legitimate behavior.
Although, depending on your environment
and where the Evil Printer is located,
this might be a good way to detect the attack.
For instance, it's probably a bad thing
if one of your systems is reaching out to a printer
over the internet.
I've also embedded a unique string
into Concealed Position's client.
I chose the client,
because that's typically the victim system.
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.
Naturally, smart attackers
are going to review the code I've written
and remove this line.
But there are a lot of dumb attackers out there, too.
So hopefully if this ever does get used in the wild,
this will help stop that.
Now, one of the challenges with mitigations
is I doubt this will ever see any real patch.
You know, installing a printer
is meant to use these mechanisms.
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.
Now, of course, that will make it very difficult
for your end users to add printers.
That's sort of the entire issue, isn't it?
Printers can't be trusted.
And finally,
I'd like to discuss the disclosures of the vulnerabilities,
and suggest some future work.
So after getting my DEF CON acceptance
and talking to Dark Wolf,
I sent similar disclosures to Lexmark, Canon, and Microsoft.
All were provided descriptions and exploit code,
all very similar disclosures, really.
And they were all informed
of the August 7th disclosure date.
Excuse me.
Lexmark was awesome.
And this is exactly how you want disclosure to go.
They acknowledged receipt immediately.
I sent the disclosure on a Friday,
because I'm a monster,
and they confirmed the issue on a Monday.
And it only took a little more than a week
to send me a beta patch,
which is really impressive.
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.
And Lexmark has been a great communicator, overall.
They even went as far as
wishing me good luck on my DEF CON talk,
which I never actually told them about.
So I thought that was pretty clever.
So a shoutout to Braden, if you're listening.
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.
They literally have two jobs:
assigning and publishing CVEs that other people write.
You know, how hard is that?
Otherwise, great disclosure.
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.
And disclosure with Canon started off very well.
They asked clarifying questions on the affected component,
but then nothing.
By July 9th, they had the vulnerability for three weeks
and they hadn't confirmed the issue.
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.
Now, they did release a security patch on July 4th.
But after looking at it,
it doesn't affect the vulnerability I reported.
And they, for some reason,
didn't mention it to me until eight days later.
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.
The Microsoft disclosure has been reasonable.
As you can see from the timeline,
there was a fair amount of back and forth
about recreating the issue.
But eventually,
I guess the proof of concept video got there,
which probably just means
my written instructions weren't very good.
Now, while they did acknowledge the issue on July 12th,
I actually don't expect any type of CVE here
or security bulletin.
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.
So, mission accomplished.
But I honestly am not sure how they can address this,
without breaking normal printer workflows.
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.
So one turned out good.
One turned out bad.
(Jake laughs)
And one spent a lot of time, and can't reproduce.
So, last slide.
Future work.
Like I said, any print driver that is compatible
with the driver store is fair game, new or old.
Really, very old is even up for grabs here.
So there are many drivers that could be analyzed
and added to Concealed Position.
There's also nothing special about CutePDF.
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.
Now, hopefully in the future,
I or someone else will code that up,
so that others can use an Evil Printer as they choose.
Once that is done,
this attack would be great paired with a USB attack.
And finally,
Concealed Position could use polishing.
Like most exploits,
it was written only to prove that the attack was possible.
So it's a little messy at the moment,
and some of the mechanisms around dropping DLL
and customizing payloads could be extended.
Otherwise, that's it.
Thank you all so much for listening.
Thank you very much to Dark Wolf for letting me share.
And thank you again, DEF CON,
for both the support and allowing me to present.
Again, thank you all.