Okay, we're streaming.
Everyone, welcome back to, I guess, the very first talk of...
Okay, we're streaming.
...speakers. This is the How to Hack Windows Machines with Printing Protocols.
I forgot the most important part of that, right? Evil Printer.
How to Hack Windows Machines with Printing Protocols.
Would you guys mind introducing yourselves, since I've already said that it's really late where y'all are at?
Okay, so we are speakers from Beijing, China.
And we work at Tencent Security Chef Lab.
And this is the main speaker, or the author of the presentation, Jim Hongbo.
He is the senior researcher on this project.
And I'm the co-author of the presentation, slash translator for this talk, slash voice cast for the talk, actually.
For anyone who maybe didn't get a chance to finish watching the talk, or just got overwhelmed with how many there are already,
would you be willing to just kind of give us a brief overview of what all your talk, your presentation, entails?
So basically we are showcasing a vulnerability we've discovered in Windows Printing Protocol.
And this vulnerability can basically pose locally privileged escalation.
So maybe from sandbox apps to normal user.
And also escalate from normal user to system root on Linux.
System on Linux.
And basically we can also do it remotely as remote code execution.
Maybe you can affect other users who are connecting to the printer.
And when the user connects to that printer, it automatically gets code executed on their machine.
First question we had come in is, why would a sandbox app, like a browser, even need access to the printer server?
Well, browser, as you can see, is a very complex app.
When you use the browser, you actually have many different needs for different users.
Many of the users would like to print documents that they are using a, for example, PDF reader in the browser.
And you may want to print that PDF document.
And that's when the browser needs to talk to a printer through the Windows Printing Protocol.
And that opens up a channel from the sandbox app or the browser to the privileged service, the Windows Printing Service, the Print Spooler.
So that's why this vulnerability can affect a sandbox app like browsers.
Is this throughout all of the Windows Suite that's out there?
Are there certain versions that are susceptible that others aren't?
Well, we did test through Windows 10 to legacy Windows 7.
Theoretically, it does affect even older versions like Windows 2000.
But we haven't tested that yet.
The Windows Spooler service, which is a very patient or legacy service, exists in more than 25 years.
So that really does affect a lot of versions in between.
Is this still research that you guys are planning on going further down? Is this going to pivot into something else?
Well, we've been doing this research on Windows Privileged Escalation for many years now.
So we did research other parts of the Windows operating system, and this is one of our latest findings, actually.
By the way, we did discover another Privileged Escalation vulnerability just after finishing the talk.
Are you ready to talk about it here?
Not really, because Microsoft decided it will postpone the fix to December.
Maybe next year.
I think they're teasing us, guys, like, hey, if you want us back next year, we've got more to drop on y'all.
Yeah, actually, we did write a lot about how to find similar bugs, or similar kinds of logical bugs.
We did a submission this year, but unfortunately...
Maybe next year.
How to do logical bug finding generically.
Maybe I'll just put you guys on the spot a little bit.
Will you give us a little bit of teaser, a 1,000-mile overview of how you would go about finding interesting bugs like this?
Not your full talk, but...
Well, I can basically summarize into a few things.
First thing is you have to have in-depth knowledge about operating system kernels.
So sometimes even more in-depth than the person who is actually writing the operating system components.
So basically more knowledge than the average Microsoft employee, or average Microsoft engineers.
That's how deep you are going to get to actually find the interesting bugs in Windows operating system.
And second is, I think, the tooling is very important.
So you have to have your own tooling for the research that you want to make.
We really recommend you guys check out James' awesome OLU.net.
It's an awesome tool.
But don't just use the tool. Write your own.
You can write the tool. It depends on the other people's tools.
But try to write your own, because writing that tool, you get more knowledge about the kernel stuff, how it works,
and how they decide certain things.
The engineer view of the operating system is very important.
I always end up with audio issues. Sorry about that.
We had a question come in. Have you noticed any easy access for printer memory?
They went on to say, I know that the DoD has been trying to crack down on this for decades.
What do you mean by printer memory? The memory on the actual physical printer?
I think they have a bit of a follow-up for you there, so hopefully he'll get back to us.
In the meantime, though, you've said that you've kind of been investigating all this in privileged escalation for a while.
What got you guys into this track?
What got you excited about digging in to the point where you're writing your own tools for all of this?
Well, as I said, the tooling is very important because it not only lets you know the internals of the operating system,
how it works and why it works, or why they are designed this way.
Also, it will get you further than other people's generic tools don't get.
That's why we are recommending everybody to have their own tools instead of using the generic ones.
And the curiosity in the internals is very important for finding logical bugs.
That's why we started doing logical privileged escalation instead of memory corruptions.
Everybody is working on that.
But logical bugs are quite fun, actually, to find it and to talk about it.
It was definitely a really interesting talk to listen to because I think it's something that can affect everyone, right?
Not just companies, but writing your own home.
Those are always... I don't even know the right word for it. Unsettling? Would that be the correct term?
I'm waiting on Hakai to get back to us on the rest of his questions.
Hakai, can you get that in? I'm not ignoring it.
While we're waiting, I did have a question.
When you were talking about the previous CVE fix where they just simply put a warning up to install the bad driver,
or before they installed drivers, it didn't seem like there was anything other than just telling the user that there's a risk to installing a driver writ large.
There was nothing that said whether a driver could be good or bad.
Was that your take of it? It seems kind of like a punt on Microsoft's part.
Well, because they have certain bars for servicing, or should I say certain bars for vulnerability,
what they are considering vulnerability and what they are not considering vulnerability.
So the most important bar for the vulnerability consideration is user interaction.
If you have more than one user interaction, that doesn't seem to be a vulnerability by their view.
So they put up a warning dialogue and they think maybe it's good enough.
That's how it works.
Yeah, but it's not like they're signed where I can trust these drivers and I can't trust those drivers, right?
Well, actually the newer protocol is basically invented for checking the signatures of the drivers.
So that's the implementation of that protocol, the source of the vulnerability.
So that's quite ironic.
Just clarifying for me on that answer.
So the patches that have come out, are they only affecting Windows printing or are those patches also affecting other services and components?
Well, the patch is for the cabinet instruction part of the system.
So the one thing about the cabinet API in Windows is that when you are calling that API, you're actually handing over a few callback functions to that API.
Basically, the API calls you back when it's extracting the files.
And so the vulnerability is actually not inside the cabinet API but the callback that Windows printing is handling to the API.
So the patch actually did fix that vulnerability and whether or not there's other vulnerabilities regarding the cabinet API
is basically depends on the user of the API itself.
The API seems secure to me.
Seems like famous last words at a conference like this, right?
Somebody out there is going challenge accepted.
I'm sorry, I think I cut you off in the middle of the question earlier there.
I was going to ask about the... I mean, fundamentally, this is a path transversal bug you found.
But I think you answered it earlier in that the architecture itself seems to have some flaws and the way it trusts things.
And if I had to guess, I'd say that your undisclosed vulnerability you found is probably along the same lines.
Do you think just the actual architecture of that driver handshake is flawed?
Well, I would like to say that the design problem is basically you shouldn't have put that service at such a privileged level.
The printer driver is actually not a device driver traditionally.
A traditional device driver is actually a bunch of DL files, dynamic link files.
That's loaded by the driver, by these prints for the process.
So the fundamental problem is you shouldn't have that much of a privilege by design.
And basically, I think Microsoft may be considering, you know, after all these vulnerabilities recently,
they may be considering a redesign or re-architect the entire printing stack.
Maybe that's why we are pushing the patch to some direction.
Kind of off-topic, but you made me wonder, you know, if they're rethinking the design of this,
have you done any investigation on how this would impact or is implemented on other operating systems like Linux or Mac OS?
Printing is really a legacy thing.
All operating system kinds of implement is in their place.
We did the research on a few operating systems, but not all.
We did find a few issues.
So basically, yeah, that's all I've got to say.
So I think what we're getting is if you want the real meat and bones about this,
you're going to have to keep inviting us back to different dot-coms.
I didn't say that.
No, it sounds like there's definitely a lot more to the research that you guys are doing.
I'm a little scared right now, though, being a Linux user.
Into the research that you guys are doing, what's your next big project?
What is the next thing after this talk is out of the way that you guys are going to delve into?
Operating system has a lot of attacks of this.
Printing is a very small fraction of it.
We did have different kinds of research on, for example, the ALPC,
which is a pretty advanced inter-process communication channel on Windows.
We also have COM, which is another IPC channel, a legacy channel on Windows.
And we did find a lot of bugs regarding those two channels.
Basically, we started research from the browser aspect.
So that's how to get out of the browser sandbox.
We started research from there.
And we gradually became more generic, doing research in other parts of the system.
So we did a lot of normal-to-system privilege escalations, basically.
So that's expanding our research throughout the parts of the system.
Obviously, there is a lot more to be researched here.
And I know earlier you said the key point is you have to be curious.
You can't rely on other people's tools.
You have to be willing to write your own.
And you need to know the fundamentals better even than the developers do.
But if somebody out there is going like,
OK, you know what, I'm really interested in this.
This is something that I want to get into.
What resources, recommendations would you give them as a starting point?
You know, you guys started in the browser, but you already had that fundamental knowledge.
Where could they get started?
Well, the starting point can be anywhere you like to.
But the curiosity part is the most important thing.
You have to have a curiosity in how things work.
How they work internally.
And just play with the tool and get used to it.
And just looking at other parts of the system.
Just look away.
You have to have in-depth research than average engineers.
The engineers basically have different types of requirements.
They basically want to complete a certain feature in a certain time frame.
Within a certain budget.
But security research is different.
They do have the requirement of getting deeper than others.
Other competitors.
The more deep you get, the more bugs you can find.
That's a great way to just sum up what a security researcher does right there.
We're kind of coming to the end of our time together.
And I was wondering, is there anything that maybe didn't make it into y'all's talk?
Or anything that you wish you would have focused more around that you're hoping to let people know about now?
Well, we actually did two submissions, as I said earlier.
And that part that didn't make it into this talk was, how do I find these similar bugs?
Generically.
Even with automation.
Like, without even intervention.
That's the thing I want to talk about.
Maybe next time.
Or other places.
But that's a really fun thing to talk about.
If people have more questions or anything they'd like to get a hold of you with about, what's the best way for them to reach out to you?
You can add us as friends on Discord or maybe Twitter.
Twitter accounts are on the slides.
You can DM us any questions or thoughts.
You can DM us and we are glad to answer.
That sounds great.
Well, I don't see any more questions coming in.
And we're kind of already towards the end of time anyway.
So thank you guys for coming and sharing your talk with us.
And scaring us about all the other things you haven't released yet.
That would be great.
Y'all have a great night.
Thank you.