WEBVTT 00:28.000 --> 00:31.440 All right, looks like we're live. 00:31.700 --> 00:35.600 So, thank you all for joining us this morning. 00:35.600 --> 00:47.960 I have Palig Hadar and Tomer Barr, who are going to be here to be talking about their research into the Stuxnet printing vulnerabilities that they found. 00:47.960 --> 00:51.260 They're still around after, you know, 10 years later. 00:51.340 --> 00:55.300 But to start things off, we have two first-time speakers. 00:55.480 --> 00:59.680 And as our tradition in DEF CON, we shot the noobs. 00:59.680 --> 01:03.980 And so, I'd like to invite you all to join me in a shot, folks. 01:04.220 --> 01:05.840 Here's to your talk. 01:08.000 --> 01:08.860 Thank you. 01:08.880 --> 01:09.660 Cheers. 01:12.260 --> 01:13.700 All right, great. 01:13.940 --> 01:17.300 So, we actually have a first question on the line. 01:17.560 --> 01:24.860 It said, can you please explain more about the fuzzing process when finding corruption in the SHD files? 01:26.760 --> 01:28.020 Yeah, sure. 01:28.520 --> 01:36.840 So, actually, it was pretty interesting because we didn't want to use some, I don't know, already existing tool. 01:36.840 --> 01:39.120 We wanted to do something on our own. 01:39.440 --> 01:52.200 So, after we understood the SHD processing and all of this stuff, we just wanted to do the most naive thing. 01:52.200 --> 01:56.300 We just written our own Python script, which takes already 01:59.340 --> 02:01.880 existing SHD file, which works. 02:01.880 --> 02:06.660 And we just mutated it one by one, one byte at a time. 02:06.660 --> 02:10.080 And we used zero to FF on each byte. 02:10.080 --> 02:16.180 And we didn't do anything that was, you know, dependent by each byte. 02:16.180 --> 02:19.840 We just did it each byte at a time. 02:20.900 --> 02:26.420 Afterwards, we just dropped all the SHD files and we wanted to make sure it's working. 02:26.420 --> 02:33.780 And we understood that there's a kind of a limit in the service that it won't process more than 256 files at a time. 02:33.780 --> 02:37.180 So, we just modified the spoiler service. 02:37.180 --> 02:41.600 We just patched it and we replaced the check with knobs, of course. 02:41.720 --> 02:47.480 And then we just kicked around a kind of a spoiler, which was modified and it just worked. 02:47.940 --> 02:49.120 And then it took 20 minutes. 02:49.120 --> 02:51.960 It processed all of the SHD files and it crashed. 02:52.280 --> 02:53.560 So, it was pretty cool. 02:54.940 --> 03:00.940 We don't intend to release the Python script, but maybe we will. 03:00.940 --> 03:02.500 We need to discuss it. 03:03.600 --> 03:04.520 Very cool. 03:04.520 --> 03:18.640 Yeah, I was pretty impressed with the ability or what you guys did in walking through the entire, for lack of a better term, kill chain of the Stuxnet. 03:19.540 --> 03:30.340 I mean, how much of studying that original code do you think influenced your discovery of these remaining vulnerabilities? 03:31.100 --> 03:33.660 Yeah, I think it was pretty much. 03:33.660 --> 03:40.660 Because when we started to look at it, we thought that, okay, it's 10 years after Stuxnet. 03:40.740 --> 03:45.100 A lot of very strong researchers already research it. 03:45.100 --> 03:49.120 What are the chances that we will find anything new? 03:49.120 --> 03:52.180 But we came with a lot of motivation. 03:52.280 --> 04:01.160 And after seeing that the first patch was not fully patched and can be re-exploited and the second patch and the third patch. 04:01.160 --> 04:06.580 So, we understood that we are onto something and started the research. 04:06.580 --> 04:11.820 And after 20 minutes of fuzzing, you get your first crash and it's not usual. 04:11.860 --> 04:18.000 And that gave us hope that we'll find more. 04:18.000 --> 04:19.600 And yeah, it's happened. 04:23.480 --> 04:24.100 Great. 04:24.100 --> 04:26.420 We have another question from the audience. 04:26.420 --> 04:29.260 It said, was the SHD crash exploitable? 04:30.500 --> 04:32.280 Actually, good question. 04:32.400 --> 04:35.760 From what we've seen, it wasn't exploitable. 04:35.760 --> 04:42.560 It was only one byte which was controllable and it was pretty odd. 04:42.560 --> 04:45.280 I mean, we're pretty sure it wasn't exploitable. 04:45.280 --> 04:50.700 But we really invite everyone to try and maybe to understand whether it's exploitable or not. 04:50.700 --> 04:56.180 And if it's exploitable, tweet about it and you can mention me. 04:56.660 --> 05:02.000 It will be very interesting because, as we mentioned, Microsoft didn't fix it. 05:02.000 --> 05:07.640 So, it might be more interesting and maybe if you'll find something, you can report it to Microsoft as well. 05:07.640 --> 05:09.080 So, good luck. 05:11.860 --> 05:21.640 Actually, we see a lot of people, a lot of researchers that haven't been in the spooler and now we see a lot of research on the spooler. 05:21.880 --> 05:24.220 We hope we contributed well. 05:25.300 --> 05:26.620 Definitely. 05:30.190 --> 05:32.390 So, I see another question. 05:33.130 --> 05:39.490 Yeah, so the other vols, were they found by fuzzing or code review? 05:40.570 --> 05:42.990 So, actually, good question. 05:42.990 --> 05:54.890 So, after we started fuzzing and we had our first crash, we were intrigued enough in order to move to manual source code auditing and manual binary auditing. 05:54.890 --> 05:57.850 So, it was found completely manually, 100%. 05:57.850 --> 06:09.930 And we just looked at the code and we understood how the mechanism works and what kind of use cases we can challenge the mechanism and we just found it manually. 06:10.370 --> 06:11.890 It was pretty cool. 06:14.350 --> 06:20.650 Basically, I know I do, I think Tamara as well, we use less fuzzing. 06:20.650 --> 06:23.730 We generally do more manual code auditing. 06:24.070 --> 06:32.250 But I think, you know, you can find interesting bugs using fuzzing and using manual code auditing. 06:32.910 --> 06:36.850 If you use both, it will be probably the best. 06:40.470 --> 06:45.630 Yeah, so you mentioned the Microsoft decision not to patch that SHD1. 06:45.630 --> 06:53.170 I mean, do you think that they were justified in their logic on that or would you like to see them patch it? 06:55.860 --> 07:06.480 Well, I think that they have a very clear security boundary and service criteria on MSRC. 07:06.960 --> 07:09.940 I don't want to say whether I think it's right or not. 07:09.940 --> 07:20.520 All I can say that they mentioned that local denial of service is not, you know, it's not past their service criteria and therefore it won't be fixed. 07:20.520 --> 07:25.560 Maybe they will decide to fix it if it will be used in order to abuse or something. 07:25.560 --> 07:28.060 But I respect their decision. 07:29.320 --> 07:30.640 Yeah, I totally agree. 07:30.640 --> 07:35.280 And maybe other vendors, endpoint vendors will release signature for that. 07:35.280 --> 07:41.780 Maybe the antivirus or other security control can manage to prevent this. 07:44.880 --> 07:47.280 Yeah, so you mentioned... Oh, go ahead. 07:47.520 --> 07:48.520 Oh, I have a question. 07:48.520 --> 07:57.020 So when I was watching the video, I noticed that when it came to the last path vulnerability, you kind of gave a very pregnant there, you know, no vulnerability yet. 07:57.260 --> 08:03.800 And is that more because you guys are expecting one to come out or have a theory that there's one out that just hasn't been released in the wild? 08:03.800 --> 08:06.280 Like, there was a big emphasis on that. 08:08.180 --> 08:12.280 We don't have anything up in our sleeve and we don't know about anything. 08:12.280 --> 08:16.200 And of course, if we will know, we will report it to Microsoft. 08:16.200 --> 08:26.420 But all we said is, you know, you have two paths which were exploited and you have the third one which might be exploited and might not. 08:26.420 --> 08:30.560 We don't know about anything that, you know, we know as much as you know. 08:31.020 --> 08:33.120 But I don't know. 08:33.120 --> 08:37.700 Maybe we will find that Microsoft has patched it in the future. 08:38.480 --> 08:39.840 But nothing concrete. 08:48.420 --> 08:48.960 Great. 08:48.960 --> 08:51.940 So we actually have another question on the line. 08:51.940 --> 09:00.480 It said, after your experience on this, what would you say to researchers attempting to replicate the same vulnerabilities on Siemen microcontrollers matching those in Iran? 09:05.620 --> 09:07.740 So, Tomer, do you want to take it? 09:08.780 --> 09:10.620 Siri, can you repeat the question? 09:12.620 --> 09:24.780 Yeah, it said, after your experience, what would you say to researchers attempting to replicate the same vulnerabilities on Siemen microcontrollers matching those in Iran? 09:25.840 --> 09:32.180 Well, actually, this is not the focus of our research, so we are not experts on that. 09:32.180 --> 09:41.400 I think that our research is basically focused on the propagation part of Succent and the Spuro service specifically. 09:41.440 --> 09:51.680 And the Spuro service is on the Windows Microsoft code, so it's not related to the, you know, to the hardware or anything else. 09:51.680 --> 09:56.160 Just any default Windows OS algorithm. 09:58.290 --> 10:06.650 I think it's a huge, you know, it's a huge domain, Stuxnet, and we have so many aspects to look. 10:06.650 --> 10:23.190 We focus on the Windows part, and we don't know if the fact that we found a vulnerability in the same domain in the Windows part will, you know, just said that if you will do the same in the Siemens PLC, it will be the same. 10:23.190 --> 10:35.090 But I think it is an interesting part that if you want to get into, just share it with the community, I think it will be interesting enough to people to come and see. 10:35.510 --> 10:38.910 So maybe we'll see you in DEF CON next year, answering this question. 10:39.830 --> 10:49.130 Yeah, something tells me if they actually have, anyone has an O-Day up their sleeve for Siemens microcontrollers, they're probably not presenting that at DEF CON, but we'll see. 10:52.730 --> 11:07.270 Right, so you talked about the spooler, or you demonstrated how the spooler was exploited by a local user to get the escalation. 11:08.230 --> 11:12.850 It seemed like you were hinting that this might still be a remote capability as well. 11:12.850 --> 11:14.750 Did you find that or not? 11:15.530 --> 11:30.630 No, actually, we were only focused on the local, the local tool installation pack vector, and we haven't found a way to bypass the patch, the original patch, to get the remote tool execution. 11:34.210 --> 12:00.710 Great, so it looks like we've got another question coming in, but let's see, we're all waiting for typing to be done, but so, you know, earlier you talked about walking through the the StuckNet process and sort of finding which vulnerabilities still existed. 12:01.190 --> 12:13.030 So your original intent was to recreate that and look for residual, or was it actually to look at, you know, what vulnerabilities that by themselves may be still available? 12:13.590 --> 12:23.070 So, yeah, the first question was if we, if building StuckNet 2.0 is possible, of course, legitimately. 12:24.030 --> 12:47.830 When we start to look at the components and we saw that if, for our luck, the community luck, the discovery, the, say, equivalent vulnerabilities that were found in the last decade to allegedly build the StuckNet 2.0 were disclosed to Microsoft in a safe manner, 12:47.830 --> 13:02.790 but if an evil corp that will manage to do it by themselves, a single actor, and allegedly can build equivalent capabilities, propagation capabilities of StuckNet. 13:02.790 --> 13:05.990 So we asked ourselves, okay, what else is missing? 13:05.990 --> 13:09.690 And the only missing part was the printer spooler vulnerability. 13:09.690 --> 13:14.190 So we thought it would be a very interesting research, and it was. 13:14.190 --> 13:19.290 So we started to dig in and found three vulnerabilities. 13:22.150 --> 13:29.010 Next question we have in chat is what do you think about the state of variant analysis in the Windows platform? 13:32.060 --> 13:34.450 What do you mean by variant analysis? 13:35.350 --> 13:39.550 We'll have a follow-up there and we'll get back to us. 13:40.270 --> 13:50.490 All right, so the next one was were there any unused methods found by you in StuckNet's code revealing any possible planned future attacks? 13:55.850 --> 14:05.950 Yeah, we didn't mean, I mean, we didn't look on StuckNet code or, you know, we just, we will focus on the vulnerability which were used with StuckNet. 14:05.950 --> 14:11.570 We didn't, and the propagation part, we didn't dive into StuckNet's code. 14:14.390 --> 14:23.550 Clarification on that last question, when it comes to variant analysis, they were speaking to like analysis existing vulnerabilities to find variants. 14:23.910 --> 14:24.310 I don't know. 14:24.310 --> 14:41.670 Okay, I think if I got it correctly, I think that the state, I mean, it's very interesting because I know that once someone finds a pretty common bug class, a lot of other researchers are diving into it and find a lot. 14:41.670 --> 14:50.290 I mean, if you can take a look of MSRC each month, obviously, releasing a bulletin of patch Tuesday. 14:50.670 --> 14:59.790 And I think that the very common vulnerability bug class is, of course, the elevation of privilege, which is caused by logic bugs. 14:59.790 --> 15:01.790 I think that you can see a lot. 15:01.970 --> 15:20.610 And I think that the trend got started, I don't know if officially, but at least what I know is James Forshaw just, you know, took a look of all of the file system privilege issues and released a lot of tools that helped other researchers to take a look of it. 15:20.610 --> 15:24.310 And then people just found a lot of variants. 15:24.310 --> 15:31.870 And so I think that is definitely a pretty discussed topic. 15:32.690 --> 15:40.870 And I know that I will keep in and take a look if the backlog still exists, if that answered your question. 15:41.070 --> 15:54.150 Yeah, if I may add, that's why we started to develop our driver, mitigation driver, it's not focused on a specific variant. 15:54.190 --> 15:57.750 It looks at the root cause of the entire arbitrary class. 16:00.030 --> 16:17.550 So I believe that if there will be a future exploit in this bug class and this driver, which is only a POC, someone will take it and make it more product ready, production ready. 16:17.550 --> 16:24.670 So we may catch some new and future exploits. 16:27.180 --> 16:37.940 I think it will be interesting to see if any vendor adopting the idea, implementing it in his own product. 16:38.080 --> 16:39.940 Yeah, I'm glad you mentioned the driver. 16:44.820 --> 16:49.400 I was interested in the analysis of those universal right locations. 16:51.540 --> 16:56.500 I mean, it seems like that's something that could be fixed in policy as well. 16:56.720 --> 17:03.660 What do you see the advantage of using the driver approach you did over just an ACL and a policy or something? 17:05.140 --> 17:09.140 I mean, it can be fixed by policy, right? 17:09.520 --> 17:13.980 I mean, we wanted to demonstrate this solution. 17:13.980 --> 17:22.480 It's not like we are saying that it's 100% sealed and there are no vulnerabilities that can bypass it. 17:22.480 --> 17:25.860 But we do think it was a pretty good way to demonstrate it. 17:25.860 --> 17:38.080 I think that the use of a minifilter driver is good because obviously you catch the IRPs and the IO requests pretty low and you can just block it and cancel it. 17:38.360 --> 17:46.720 I don't know what kind of whitelisting or policy you will use. 17:46.720 --> 17:52.400 Obviously, the vendor can just implement it by using his own minifilter driver. 17:52.400 --> 17:56.520 But I think it's a pretty good demonstration. 17:59.960 --> 18:03.440 So we talked about this a little before the call started. 18:03.900 --> 18:14.080 I think the most comical thing I saw in your presentation was that you all managed somehow to get the the LEET tag on your CVE. 18:14.080 --> 18:26.020 Was that something that you actually timed or was it just a happy coincidence that Microsoft labeled you guys LEET with their CVE-2021-337? 18:26.840 --> 18:28.520 It wasn't a happy coincidence. 18:28.520 --> 18:30.260 It was the happiest coincidence. 18:30.420 --> 18:33.300 I mean, we didn't organize anything. 18:33.300 --> 18:34.660 We didn't ask for it. 18:34.660 --> 18:35.980 We just got it. 18:35.980 --> 18:39.470 Thank you, Nate Warfield from MSRC. 18:39.970 --> 18:41.530 We signed it. 18:41.810 --> 18:47.450 It's an awesome CVE number and I think everyone wanted to get it. 18:49.410 --> 18:51.750 Maybe next year, one more time. 18:51.870 --> 19:00.990 I think I have all the big what-if questions, so I'm just going to throw this one out even after the other one. 19:00.990 --> 19:10.190 In your talk, you focused a bit about how the last patch, the previous patch, kind of killed the concept of remote execution and all of these were focused on local. 19:10.470 --> 19:19.150 With these new releases that you've just done, the POC releases, what do you think that there's a chance that these can kind of pivot into remote execution now? 19:21.150 --> 19:24.690 It's not likely, but we'll see. 19:33.140 --> 19:38.660 Yeah, I warned you guys against one-word answers, but we'll let you slide on that one. 19:39.340 --> 19:41.900 I feel like I just put a very pregnant question out there. 19:41.900 --> 19:43.100 It's like, come on, guys. 19:47.180 --> 19:50.060 No, we're pretty happy to have you guys. 19:50.060 --> 19:52.840 I think this is pretty interesting. 19:52.840 --> 19:53.800 I think there was a really... 19:53.800 --> 20:07.680 I really appreciated the sort of complete walkthrough of what the malware did and what exploited each step. 20:07.980 --> 20:21.560 And I think, like you said, this may have been... or there should have been something that was covered pretty extensively over the last 10 years, but going back and revisiting those can have happy coincidences as well, right? 20:23.910 --> 20:25.630 Yeah, definitely. 20:25.630 --> 20:32.570 I think that we'll be glad to see another briefing and walkthrough in a decade. 20:33.290 --> 20:40.570 So if there's someone we'll remember, it'll be probably still interesting to see. 20:40.650 --> 20:42.330 Next time on Vegas. 20:42.990 --> 20:44.270 Yeah, definitely. 20:49.340 --> 20:52.500 Okay, so we're coming up on only 10 minutes left. 20:52.500 --> 20:55.780 Do you guys have any last words you'd like to share about the research? 20:55.780 --> 21:06.240 I shared your GitHub out there, and I understand that you've kind of got one more release up your sleeves waiting for, you know, patch Tuesday next week. 21:07.320 --> 21:09.680 Do you want to give us a preview of what we may see then? 21:10.300 --> 21:13.740 Yeah, so actually, we gave it a preview during our talk. 21:13.740 --> 21:23.660 We had a video which demonstrated the demo of how we bypassed the patch of CB20201048 and how we re-exploited it. 21:23.660 --> 21:31.200 Obviously, we can't provide the details now, but we'll have to wait in the last moment when the patch will be released. 21:31.200 --> 21:35.340 We hope it will be on the following patch Tuesday. 21:35.360 --> 21:41.700 That's what NSRC told us, but we can't of course because we're not Microsoft, so we have to wait and see. 21:42.000 --> 21:58.320 And once we'll be able to make sure that it was already patched, we will release the POC in the GitHub repository that you published on the channel, and we will also provide a write-up, a technical blog post. 21:58.380 --> 22:00.120 So wait and see. 22:00.120 --> 22:03.140 We'll mention it on Twitter as well once it will be deployed. 22:06.920 --> 22:12.820 And the last thing I wanted to say if you want to add something, so go ahead. 22:12.820 --> 22:23.580 But I think that it was very interesting research, and we provided all of our technical materials in our GitHub repository. 22:23.680 --> 22:30.740 And if anyone would like to continue research in the same area or something, if you have any questions, go ahead. 22:30.740 --> 22:32.140 You can DM me on Twitter. 22:32.140 --> 22:47.860 You can mention me, and we'll be glad, Tomer and I, to help someone to keep... I think there are a lot of other areas which are related, not even on the spore itself, but even in the spore itself. 22:47.860 --> 22:51.780 It's a huge mechanism, and there are a lot of things to keep on investigating. 22:51.860 --> 22:58.780 And we didn't have much time, so if anyone would like to do it and would like some help, go ahead. 23:00.220 --> 23:01.640 Yeah, totally agree. 23:04.640 --> 23:08.740 Okay, well, so I'd really like to thank you guys for the talk you guys did. 23:08.740 --> 23:21.660 I want to congratulate you again on your first time at DEF CON, and if dropping two O-days for DEF CON is what we can see in the future from you guys, I'm sure we'll be inviting you back next year. 23:22.020 --> 23:23.200 So, thank you all. 23:23.200 --> 23:23.620 Thank you very much. 23:23.620 --> 23:24.440 It was a pleasure. 23:24.820 --> 23:27.480 It was fun, and we have started to work on it. 23:28.120 --> 23:29.040 Stay tuned.