[00:34.240 --> 00:36.200]  Okay, we're streaming.
[00:37.780 --> 00:41.620]  Everyone, welcome back to, I guess, the very first talk of...
[00:41.620 --> 00:43.020]  Okay, we're streaming.
[00:45.610 --> 00:52.370]  ...speakers. This is the How to Hack Windows Machines with Printing Protocols.
[00:52.370 --> 00:54.910]  I forgot the most important part of that, right? Evil Printer.
[00:54.950 --> 00:57.830]  How to Hack Windows Machines with Printing Protocols.
[00:57.830 --> 01:02.610]  Would you guys mind introducing yourselves, since I've already said that it's really late where y'all are at?
[01:02.610 --> 01:07.530]  Okay, so we are speakers from Beijing, China.
[01:07.530 --> 01:10.830]  And we work at Tencent Security Chef Lab.
[01:11.170 --> 01:17.910]  And this is the main speaker, or the author of the presentation, Jim Hongbo.
[01:18.990 --> 01:21.770]  He is the senior researcher on this project.
[01:21.770 --> 01:31.330]  And I'm the co-author of the presentation, slash translator for this talk, slash voice cast for the talk, actually.
[01:32.710 --> 01:38.370]  For anyone who maybe didn't get a chance to finish watching the talk, or just got overwhelmed with how many there are already,
[01:38.370 --> 01:44.170]  would you be willing to just kind of give us a brief overview of what all your talk, your presentation, entails?
[01:45.150 --> 01:53.110]  So basically we are showcasing a vulnerability we've discovered in Windows Printing Protocol.
[01:53.110 --> 02:00.910]  And this vulnerability can basically pose locally privileged escalation.
[02:00.910 --> 02:05.130]  So maybe from sandbox apps to normal user.
[02:05.170 --> 02:12.930]  And also escalate from normal user to system root on Linux.
[02:12.990 --> 02:14.710]  System on Linux.
[02:15.570 --> 02:20.830]  And basically we can also do it remotely as remote code execution.
[02:21.550 --> 02:27.170]  Maybe you can affect other users who are connecting to the printer.
[02:27.170 --> 02:35.030]  And when the user connects to that printer, it automatically gets code executed on their machine.
[02:36.950 --> 02:44.430]  First question we had come in is, why would a sandbox app, like a browser, even need access to the printer server?
[02:46.070 --> 02:49.850]  Well, browser, as you can see, is a very complex app.
[02:49.850 --> 02:56.630]  When you use the browser, you actually have many different needs for different users.
[02:57.210 --> 03:07.690]  Many of the users would like to print documents that they are using a, for example, PDF reader in the browser.
[03:07.750 --> 03:10.850]  And you may want to print that PDF document.
[03:11.290 --> 03:18.810]  And that's when the browser needs to talk to a printer through the Windows Printing Protocol.
[03:20.470 --> 03:34.470]  And that opens up a channel from the sandbox app or the browser to the privileged service, the Windows Printing Service, the Print Spooler.
[03:34.470 --> 03:41.730]  So that's why this vulnerability can affect a sandbox app like browsers.
[03:42.030 --> 03:45.930]  Is this throughout all of the Windows Suite that's out there?
[03:45.930 --> 03:49.850]  Are there certain versions that are susceptible that others aren't?
[03:50.110 --> 03:57.310]  Well, we did test through Windows 10 to legacy Windows 7.
[03:57.570 --> 04:02.950]  Theoretically, it does affect even older versions like Windows 2000.
[04:04.090 --> 04:06.790]  But we haven't tested that yet.
[04:06.790 --> 04:18.790]  The Windows Spooler service, which is a very patient or legacy service, exists in more than 25 years.
[04:18.790 --> 04:23.570]  So that really does affect a lot of versions in between.
[04:24.970 --> 04:30.650]  Is this still research that you guys are planning on going further down? Is this going to pivot into something else?
[04:31.410 --> 04:40.230]  Well, we've been doing this research on Windows Privileged Escalation for many years now.
[04:40.230 --> 04:50.910]  So we did research other parts of the Windows operating system, and this is one of our latest findings, actually.
[04:51.910 --> 05:02.130]  By the way, we did discover another Privileged Escalation vulnerability just after finishing the talk.
[05:02.130 --> 05:05.350]  Are you ready to talk about it here?
[05:05.350 --> 05:13.990]  Not really, because Microsoft decided it will postpone the fix to December.
[05:14.830 --> 05:16.890]  Maybe next year.
[05:16.890 --> 05:23.290]  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.
[05:23.810 --> 05:32.870]  Yeah, actually, we did write a lot about how to find similar bugs, or similar kinds of logical bugs.
[05:33.650 --> 05:37.830]  We did a submission this year, but unfortunately...
[05:38.570 --> 05:40.370]  Maybe next year.
[05:40.570 --> 05:44.870]  How to do logical bug finding generically.
[05:44.870 --> 05:47.250]  Maybe I'll just put you guys on the spot a little bit.
[05:47.250 --> 05:54.150]  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?
[05:54.150 --> 05:56.750]  Not your full talk, but...
[05:56.750 --> 06:05.150]  Well, I can basically summarize into a few things.
[06:05.390 --> 06:11.090]  First thing is you have to have in-depth knowledge about operating system kernels.
[06:11.090 --> 06:19.190]  So sometimes even more in-depth than the person who is actually writing the operating system components.
[06:19.190 --> 06:27.350]  So basically more knowledge than the average Microsoft employee, or average Microsoft engineers.
[06:27.690 --> 06:35.430]  That's how deep you are going to get to actually find the interesting bugs in Windows operating system.
[06:35.430 --> 06:41.750]  And second is, I think, the tooling is very important.
[06:41.750 --> 06:50.850]  So you have to have your own tooling for the research that you want to make.
[06:51.610 --> 07:00.730]  We really recommend you guys check out James' awesome OLU.net.
[07:00.730 --> 07:02.430]  It's an awesome tool.
[07:02.430 --> 07:07.870]  But don't just use the tool. Write your own.
[07:08.290 --> 07:14.750]  You can write the tool. It depends on the other people's tools.
[07:14.750 --> 07:23.590]  But try to write your own, because writing that tool, you get more knowledge about the kernel stuff, how it works,
[07:23.590 --> 07:29.670]  and how they decide certain things.
[07:29.670 --> 07:34.910]  The engineer view of the operating system is very important.
[07:40.180 --> 07:42.400]  I always end up with audio issues. Sorry about that.
[07:42.400 --> 07:48.240]  We had a question come in. Have you noticed any easy access for printer memory?
[07:48.460 --> 07:53.780]  They went on to say, I know that the DoD has been trying to crack down on this for decades.
[07:55.940 --> 08:01.240]  What do you mean by printer memory? The memory on the actual physical printer?
[08:03.020 --> 08:09.580]  I think they have a bit of a follow-up for you there, so hopefully he'll get back to us.
[08:09.580 --> 08:15.920]  In the meantime, though, you've said that you've kind of been investigating all this in privileged escalation for a while.
[08:15.920 --> 08:17.620]  What got you guys into this track?
[08:17.620 --> 08:22.840]  What got you excited about digging in to the point where you're writing your own tools for all of this?
[08:23.660 --> 08:35.160]  Well, as I said, the tooling is very important because it not only lets you know the internals of the operating system,
[08:35.160 --> 08:40.760]  how it works and why it works, or why they are designed this way.
[08:40.760 --> 08:49.960]  Also, it will get you further than other people's generic tools don't get.
[08:50.960 --> 08:59.260]  That's why we are recommending everybody to have their own tools instead of using the generic ones.
[09:01.120 --> 09:12.360]  And the curiosity in the internals is very important for finding logical bugs.
[09:12.780 --> 09:19.720]  That's why we started doing logical privileged escalation instead of memory corruptions.
[09:19.720 --> 09:21.780]  Everybody is working on that.
[09:22.860 --> 09:30.000]  But logical bugs are quite fun, actually, to find it and to talk about it.
[09:31.820 --> 09:37.980]  It was definitely a really interesting talk to listen to because I think it's something that can affect everyone, right?
[09:37.980 --> 09:40.600]  Not just companies, but writing your own home.
[09:40.980 --> 09:46.940]  Those are always... I don't even know the right word for it. Unsettling? Would that be the correct term?
[09:46.940 --> 09:52.960]  I'm waiting on Hakai to get back to us on the rest of his questions.
[09:53.700 --> 09:56.400]  Hakai, can you get that in? I'm not ignoring it.
[09:57.820 --> 10:01.080]  While we're waiting, I did have a question.
[10:01.080 --> 10:12.920]  When you were talking about the previous CVE fix where they just simply put a warning up to install the bad driver,
[10:12.920 --> 10:25.120]  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.
[10:25.120 --> 10:29.020]  There was nothing that said whether a driver could be good or bad.
[10:29.020 --> 10:36.280]  Was that your take of it? It seems kind of like a punt on Microsoft's part.
[10:37.260 --> 10:45.720]  Well, because they have certain bars for servicing, or should I say certain bars for vulnerability,
[10:45.720 --> 10:50.480]  what they are considering vulnerability and what they are not considering vulnerability.
[10:50.900 --> 10:59.760]  So the most important bar for the vulnerability consideration is user interaction.
[10:59.760 --> 11:07.960]  If you have more than one user interaction, that doesn't seem to be a vulnerability by their view.
[11:08.500 --> 11:13.980]  So they put up a warning dialogue and they think maybe it's good enough.
[11:15.220 --> 11:17.580]  That's how it works.
[11:18.240 --> 11:26.880]  Yeah, but it's not like they're signed where I can trust these drivers and I can't trust those drivers, right?
[11:26.880 --> 11:37.260]  Well, actually the newer protocol is basically invented for checking the signatures of the drivers.
[11:37.540 --> 11:45.100]  So that's the implementation of that protocol, the source of the vulnerability.
[11:45.520 --> 11:48.980]  So that's quite ironic.
[11:53.740 --> 11:58.140]  Just clarifying for me on that answer.
[11:58.140 --> 12:06.600]  So the patches that have come out, are they only affecting Windows printing or are those patches also affecting other services and components?
[12:07.680 --> 12:13.800]  Well, the patch is for the cabinet instruction part of the system.
[12:14.200 --> 12:27.380]  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.
[12:27.380 --> 12:33.680]  Basically, the API calls you back when it's extracting the files.
[12:34.560 --> 12:44.580]  And so the vulnerability is actually not inside the cabinet API but the callback that Windows printing is handling to the API.
[12:45.280 --> 12:55.640]  So the patch actually did fix that vulnerability and whether or not there's other vulnerabilities regarding the cabinet API
[12:55.640 --> 13:01.140]  is basically depends on the user of the API itself.
[13:01.240 --> 13:04.940]  The API seems secure to me.
[13:08.620 --> 13:12.000]  Seems like famous last words at a conference like this, right?
[13:12.420 --> 13:14.640]  Somebody out there is going challenge accepted.
[13:16.660 --> 13:20.980]  I'm sorry, I think I cut you off in the middle of the question earlier there.
[13:23.510 --> 13:29.930]  I was going to ask about the... I mean, fundamentally, this is a path transversal bug you found.
[13:29.930 --> 13:41.130]  But I think you answered it earlier in that the architecture itself seems to have some flaws and the way it trusts things.
[13:41.170 --> 13:49.050]  And if I had to guess, I'd say that your undisclosed vulnerability you found is probably along the same lines.
[13:49.050 --> 13:56.910]  Do you think just the actual architecture of that driver handshake is flawed?
[13:59.420 --> 14:09.720]  Well, I would like to say that the design problem is basically you shouldn't have put that service at such a privileged level.
[14:10.560 --> 14:15.640]  The printer driver is actually not a device driver traditionally.
[14:15.640 --> 14:21.060]  A traditional device driver is actually a bunch of DL files, dynamic link files.
[14:21.580 --> 14:27.640]  That's loaded by the driver, by these prints for the process.
[14:27.740 --> 14:34.740]  So the fundamental problem is you shouldn't have that much of a privilege by design.
[14:37.480 --> 14:44.120]  And basically, I think Microsoft may be considering, you know, after all these vulnerabilities recently,
[14:44.120 --> 14:49.720]  they may be considering a redesign or re-architect the entire printing stack.
[14:50.480 --> 14:54.880]  Maybe that's why we are pushing the patch to some direction.
[14:57.880 --> 15:02.580]  Kind of off-topic, but you made me wonder, you know, if they're rethinking the design of this,
[15:02.580 --> 15:10.520]  have you done any investigation on how this would impact or is implemented on other operating systems like Linux or Mac OS?
[15:12.680 --> 15:15.940]  Printing is really a legacy thing.
[15:15.940 --> 15:20.640]  All operating system kinds of implement is in their place.
[15:20.640 --> 15:26.440]  We did the research on a few operating systems, but not all.
[15:29.410 --> 15:32.220]  We did find a few issues.
[15:42.940 --> 15:46.840]  So basically, yeah, that's all I've got to say.
[15:47.820 --> 15:51.120]  So I think what we're getting is if you want the real meat and bones about this,
[15:51.120 --> 15:54.140]  you're going to have to keep inviting us back to different dot-coms.
[15:54.980 --> 15:56.380]  I didn't say that.
[15:57.400 --> 16:02.200]  No, it sounds like there's definitely a lot more to the research that you guys are doing.
[16:02.200 --> 16:04.940]  I'm a little scared right now, though, being a Linux user.
[16:05.420 --> 16:10.020]  Into the research that you guys are doing, what's your next big project?
[16:10.020 --> 16:14.060]  What is the next thing after this talk is out of the way that you guys are going to delve into?
[16:16.300 --> 16:19.640]  Operating system has a lot of attacks of this.
[16:20.820 --> 16:23.440]  Printing is a very small fraction of it.
[16:23.440 --> 16:31.600]  We did have different kinds of research on, for example, the ALPC,
[16:31.600 --> 16:38.580]  which is a pretty advanced inter-process communication channel on Windows.
[16:39.020 --> 16:47.200]  We also have COM, which is another IPC channel, a legacy channel on Windows.
[16:47.380 --> 16:53.060]  And we did find a lot of bugs regarding those two channels.
[16:55.380 --> 17:06.000]  Basically, we started research from the browser aspect.
[17:06.000 --> 17:10.940]  So that's how to get out of the browser sandbox.
[17:10.940 --> 17:13.160]  We started research from there.
[17:13.160 --> 17:21.180]  And we gradually became more generic, doing research in other parts of the system.
[17:22.100 --> 17:29.520]  So we did a lot of normal-to-system privilege escalations, basically.
[17:29.900 --> 17:34.880]  So that's expanding our research throughout the parts of the system.
[17:37.180 --> 17:40.480]  Obviously, there is a lot more to be researched here.
[17:40.480 --> 17:43.900]  And I know earlier you said the key point is you have to be curious.
[17:43.900 --> 17:46.960]  You can't rely on other people's tools.
[17:46.960 --> 17:48.180]  You have to be willing to write your own.
[17:48.180 --> 17:52.500]  And you need to know the fundamentals better even than the developers do.
[17:52.600 --> 17:54.280]  But if somebody out there is going like,
[17:54.280 --> 17:56.180]  OK, you know what, I'm really interested in this.
[17:56.180 --> 17:57.980]  This is something that I want to get into.
[17:57.980 --> 18:02.660]  What resources, recommendations would you give them as a starting point?
[18:02.660 --> 18:05.920]  You know, you guys started in the browser, but you already had that fundamental knowledge.
[18:05.920 --> 18:07.440]  Where could they get started?
[18:08.680 --> 18:13.760]  Well, the starting point can be anywhere you like to.
[18:13.760 --> 18:16.940]  But the curiosity part is the most important thing.
[18:16.940 --> 18:21.220]  You have to have a curiosity in how things work.
[18:21.220 --> 18:25.080]  How they work internally.
[18:25.280 --> 18:31.820]  And just play with the tool and get used to it.
[18:31.820 --> 18:37.840]  And just looking at other parts of the system.
[18:37.840 --> 18:39.400]  Just look away.
[18:39.640 --> 18:45.660]  You have to have in-depth research than average engineers.
[18:45.660 --> 18:55.260]  The engineers basically have different types of requirements.
[18:55.260 --> 19:01.060]  They basically want to complete a certain feature in a certain time frame.
[19:01.360 --> 19:03.000]  Within a certain budget.
[19:03.000 --> 19:04.940]  But security research is different.
[19:06.340 --> 19:11.140]  They do have the requirement of getting deeper than others.
[19:11.140 --> 19:12.760]  Other competitors.
[19:14.720 --> 19:18.380]  The more deep you get, the more bugs you can find.
[19:21.320 --> 19:25.420]  That's a great way to just sum up what a security researcher does right there.
[19:26.300 --> 19:29.080]  We're kind of coming to the end of our time together.
[19:29.080 --> 19:32.560]  And I was wondering, is there anything that maybe didn't make it into y'all's talk?
[19:32.560 --> 19:37.440]  Or anything that you wish you would have focused more around that you're hoping to let people know about now?
[19:38.600 --> 19:44.480]  Well, we actually did two submissions, as I said earlier.
[19:44.480 --> 19:52.740]  And that part that didn't make it into this talk was, how do I find these similar bugs?
[19:52.740 --> 19:53.800]  Generically.
[19:55.440 --> 19:57.060]  Even with automation.
[19:57.060 --> 20:01.920]  Like, without even intervention.
[20:01.920 --> 20:05.240]  That's the thing I want to talk about.
[20:05.560 --> 20:06.880]  Maybe next time.
[20:06.880 --> 20:09.480]  Or other places.
[20:11.380 --> 20:15.540]  But that's a really fun thing to talk about.
[20:16.440 --> 20:23.140]  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?
[20:23.140 --> 20:28.160]  You can add us as friends on Discord or maybe Twitter.
[20:28.160 --> 20:32.160]  Twitter accounts are on the slides.
[20:33.280 --> 20:39.000]  You can DM us any questions or thoughts.
[20:39.260 --> 20:43.760]  You can DM us and we are glad to answer.
[20:44.160 --> 20:45.440]  That sounds great.
[20:45.440 --> 20:47.800]  Well, I don't see any more questions coming in.
[20:47.800 --> 20:49.560]  And we're kind of already towards the end of time anyway.
[20:49.560 --> 20:52.440]  So thank you guys for coming and sharing your talk with us.
[20:52.440 --> 20:55.220]  And scaring us about all the other things you haven't released yet.
[20:55.220 --> 20:56.200]  That would be great.
[20:57.740 --> 20:59.020]  Y'all have a great night.
[20:59.020 --> 21:03.360]  Thank you.