WEBVTT 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:46.310 ...speakers. 00:46.870 --> 00:52.370 This is the How to Hack Windows Machines with Printing Protocols. 00:52.370 --> 00:53.850 I forgot the most important part of that, right? 00:53.850 --> 00:54.910 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:44.170 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? 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:28.270 Is this still research that you guys are planning on going further down? 04:28.270 --> 04:30.650 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:06.370 But don't just use the tool. 07:06.370 --> 07:07.870 Write your own. 07:08.290 --> 07:11.350 You can write the tool. 07:11.350 --> 07:14.750 It depends on the other people's tools. 07:14.750 --> 07:29.670 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. 07:29.670 --> 07:34.910 The engineer view of the operating system is very important. 07:40.180 --> 07:41.480 I always end up with audio issues. 07:41.480 --> 07:42.400 Sorry about that. 07:42.400 --> 07:43.920 We had a question come in. 07:44.140 --> 07:48.240 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 --> 07:58.440 What do you mean by printer memory? 07:58.440 --> 08:01.240 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:40.760 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. 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:44.140 Those are always... I don't even know the right word for it. 09:44.140 --> 09:44.920 Unsettling? 09:44.920 --> 09:46.940 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:54.940 Hakai, can you get that in? 09:54.940 --> 09:56.400 I'm not ignoring it. 09:57.820 --> 10:01.080 While we're waiting, I did have a question. 10:01.080 --> 10:25.120 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. 10:25.120 --> 10:29.020 There was nothing that said whether a driver could be good or bad. 10:29.020 --> 10:32.440 Was that your take of it? 10:32.540 --> 10:36.280 It seems kind of like a punt on Microsoft's part. 10:37.260 --> 10:50.480 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. 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 --> 13:01.140 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. 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:49.720 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. 14:50.480 --> 14:54.880 Maybe that's why we are pushing the patch to some direction. 14:57.880 --> 15:10.520 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? 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:54.140 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. 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:38.580 We did have different kinds of research on, for example, the ALPC, 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:56.180 But if somebody out there is going like, 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.