[00:28.000 --> 00:35.900]  All right, looks like we're live. So, thank you all for joining us this morning. I have
[00:37.200 --> 00:44.080]  Palig Hadar and Tomer Barr, who are going to be here to be talking about their research into the
[00:44.080 --> 00:50.100]  Stuxnet printing vulnerabilities that they found. They're still around after, you know,
[00:50.100 --> 00:56.300]  10 years later. But to start things off, we have two first-time speakers. And as our tradition
[00:56.300 --> 01:03.980]  in DEF CON, we shot the noobs. And so, I'd like to invite you all to join me in a shot, folks.
[01:04.220 --> 01:16.420]  Here's to your talk. Thank you. Cheers. All right, great. So, we actually have a first question on
[01:16.420 --> 01:22.300]  the line. It said, can you please explain more about the fuzzing process when finding corruption
[01:22.300 --> 01:31.600]  in the SHD files? Yeah, sure. So, actually, it was pretty interesting because we didn't want to
[01:31.600 --> 01:39.120]  use some, I don't know, already existing tool. We wanted to do something on our own.
[01:39.440 --> 01:50.080]  So, after we understood the SHD processing and all of this stuff, we just wanted to do
[01:50.080 --> 01:56.300]  the most naive thing. We just written our own Python script, which takes already
[01:59.340 --> 02:06.960]  existing SHD file, which works. And we just mutated it one by one, one byte at a time. And
[02:06.960 --> 02:14.460]  we used zero to FF on each byte. And we didn't do anything that was, you know, dependent by
[02:15.280 --> 02:23.580]  each byte. We just did it each byte at a time. Afterwards, we just dropped all the SHD files
[02:24.100 --> 02:28.720]  and we wanted to make sure it's working. And we understood that there's a kind of a limit
[02:29.400 --> 02:35.880]  in the service that it won't process more than 256 files at a time. So, we just modified the
[02:35.880 --> 02:41.900]  spoiler service. We just patched it and we replaced the check with knobs, of course. And
[02:41.900 --> 02:48.280]  then we just kicked around a kind of a spoiler, which was modified and it just worked. And then
[02:48.280 --> 02:53.560]  it took 20 minutes. It processed all of the SHD files and it crashed. So, it was pretty cool.
[02:54.940 --> 03:02.500]  We don't intend to release the Python script, but maybe we will. We need to discuss it.
[03:03.600 --> 03:11.820]  Very cool. Yeah, I was pretty impressed with the ability or what you guys did in
[03:11.820 --> 03:18.640]  walking through the entire, for lack of a better term, kill chain of the Stuxnet.
[03:19.540 --> 03:24.420]  I mean, how much of studying that original code do you think
[03:24.420 --> 03:30.340]  influenced your discovery of these remaining vulnerabilities?
[03:31.100 --> 03:38.340]  Yeah, I think it was pretty much. Because when we started to look at it, we thought that,
[03:38.340 --> 03:45.100]  okay, it's 10 years after Stuxnet. A lot of very strong researchers already research it.
[03:45.100 --> 03:52.180]  What are the chances that we will find anything new? But we came with a lot of motivation.
[03:52.280 --> 03:59.340]  And after seeing that the first patch was not fully patched and can be re-exploited and the
[03:59.340 --> 04:05.420]  second patch and the third patch. So, we understood that we are onto something and
[04:05.420 --> 04:11.820]  started the research. And after 20 minutes of fuzzing, you get your first crash and it's not usual.
[04:11.860 --> 04:19.600]  And that gave us hope that we'll find more. And yeah, it's happened.
[04:23.480 --> 04:29.260]  Great. We have another question from the audience. It said, was the SHD crash exploitable?
[04:30.500 --> 04:36.480]  Actually, good question. From what we've seen, it wasn't exploitable. It was only one
[04:36.480 --> 04:45.280]  byte which was controllable and it was pretty odd. 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:58.460]  And if it's exploitable, tweet about it and you can mention me. It will be very interesting
[04:58.460 --> 05:03.420]  because, as we mentioned, Microsoft didn't fix it. So, it might be more interesting and
[05:04.000 --> 05:09.080]  maybe if you'll find something, you can report it to Microsoft as well. So, good luck.
[05:11.860 --> 05:15.840]  Actually, we see a lot of people, a lot of researchers that haven't been
[05:15.840 --> 05:24.220]  in the spooler and now we see a lot of research on the spooler. We hope we contributed well.
[05:25.300 --> 05:32.390]  Definitely. 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:47.410]  So, actually, good question. So, after we started fuzzing and we had our first crash,
[05:47.410 --> 05:53.810]  we were intrigued enough in order to move to manual source code auditing and manual
[05:53.810 --> 06:00.510]  binary auditing. So, it was found completely manually, 100%. And we just looked at the code
[06:01.490 --> 06:06.210]  and we understood how the mechanism works and what kind of use cases we can
[06:06.790 --> 06:11.890]  challenge the mechanism and we just found it manually. It was pretty cool.
[06:14.350 --> 06:21.750]  Basically, I know I do, I think Tamara as well, we use less fuzzing. We generally do
[06:21.750 --> 06:28.770]  more manual code auditing. But I think, you know, you can find interesting bugs using
[06:29.790 --> 06:36.850]  fuzzing and using manual code auditing. If you use both, it will be probably the best.
[06:40.470 --> 06:46.290]  Yeah, so you mentioned the Microsoft decision not to patch that SHD1. I mean,
[06:46.290 --> 06:52.590]  do you think that they were justified in their logic on that or would you like to see them patch
[06:52.590 --> 07:06.480]  it? Well, I think that they have a very clear security boundary and service criteria on MSRC.
[07:06.960 --> 07:12.620]  I don't want to say whether I think it's right or not. All I can say that they mentioned that
[07:12.620 --> 07:19.400]  local denial of service is not, you know, it's not past their service criteria and therefore
[07:19.400 --> 07:25.040]  it won't be fixed. Maybe they will decide to fix it if it will be used in order to abuse or
[07:25.040 --> 07:32.760]  something. But I respect their decision. Yeah, I totally agree. And maybe other vendors, endpoint
[07:32.760 --> 07:39.760]  vendors will release signature for that. Maybe the antivirus or other security control can manage to
[07:40.520 --> 07:49.120]  prevent this. Yeah, so you mentioned... Oh, go ahead. Oh, I have a question. So when I was
[07:49.120 --> 07:54.120]  watching the video, I noticed that when it came to the last path vulnerability, you kind of gave
[07:54.240 --> 07:58.980]  a very pregnant there, you know, no vulnerability yet. And is that more because you guys are
[07:58.980 --> 08:03.220]  expecting one to come out or have a theory that there's one out that just hasn't been released in
[08:03.220 --> 08:10.940]  the wild? Like, there was a big emphasis on that. We don't have anything up in our sleeve and we
[08:10.940 --> 08:16.200]  don't know about anything. And of course, if we will know, we will report it to Microsoft.
[08:16.200 --> 08:24.100]  But all we said is, you know, you have two paths which were exploited and you have the third one
[08:24.100 --> 08:29.400]  which might be exploited and might not. We don't know about anything that, you know, we know as
[08:29.400 --> 08:37.700]  much as you know. But I don't know. Maybe we will find that Microsoft has patched it in the future.
[08:38.480 --> 08:52.140]  But nothing concrete. Great. So we actually have another question on the line. It said,
[08:52.140 --> 08:55.900]  after your experience on this, what would you say to researchers attempting to replicate the
[08:55.900 --> 09:06.900]  same vulnerabilities on Siemen microcontrollers matching those in Iran? So, Tomer, do you want
[09:06.900 --> 09:17.340]  to take it? Siri, can you repeat the question? Yeah, it said, after your experience, what would
[09:17.340 --> 09:22.620]  you say to researchers attempting to replicate the same vulnerabilities on Siemen microcontrollers
[09:22.620 --> 09:30.120]  matching those in Iran? Well, actually, this is not the focus of our research,
[09:30.120 --> 09:37.200]  so we are not experts on that. I think that our research is basically focused on the propagation
[09:37.200 --> 09:43.600]  part of Succent and the Spuro service specifically. And the Spuro service is on the Windows
[09:44.900 --> 09:51.680]  Microsoft code, so it's not related to the, you know, to the hardware or anything else.
[09:51.680 --> 10:03.270]  Just any default Windows OS algorithm. I think it's a huge, you know, it's a huge domain,
[10:03.270 --> 10:11.330]  Stuxnet, and we have so many aspects to look. We focus on the Windows part, and we don't know if
[10:11.330 --> 10:19.550]  the fact that we found a vulnerability in the same domain in the Windows part will, you know,
[10:19.550 --> 10:23.950]  just said that if you will do the same in the Siemens PLC, it will be the same. But I think it
[10:23.950 --> 10:32.050]  is an interesting part that if you want to get into, just share it with the community, I think
[10:32.050 --> 10:37.010]  it will be interesting enough to people to come and see. So maybe we'll see you in DEF CON next
[10:37.010 --> 10:42.430]  year, answering this question. Yeah, something tells me if they actually have, anyone has an
[10:42.430 --> 10:47.130]  O-Day up their sleeve for Siemens microcontrollers, they're probably not presenting that at DEF CON,
[10:47.130 --> 11:02.310]  but we'll see. Right, so you talked about the spooler, or you demonstrated how the spooler
[11:02.310 --> 11:09.990]  was exploited by a local user to get the escalation. It seemed like you were hinting
[11:09.990 --> 11:14.750]  that this might still be a remote capability as well. Did you find that or not?
[11:15.530 --> 11:20.310]  No, actually, we were only focused on the local, the local tool installation
[11:21.070 --> 11:27.990]  pack vector, and we haven't found a way to bypass the patch, the original patch,
[11:27.990 --> 11:38.130]  to get the remote tool execution. Great, so it looks like we've got another question coming in,
[11:38.130 --> 11:45.670]  but let's see, we're all waiting for typing to be done, but
[11:47.170 --> 11:56.290]  so, you know, earlier you talked about walking through the the StuckNet process and sort of
[11:56.290 --> 12:03.650]  finding which vulnerabilities still existed. So your original intent was to recreate that
[12:03.650 --> 12:10.810]  and look for residual, or was it actually to look at, you know, what vulnerabilities that by
[12:10.810 --> 12:20.490]  themselves may be still available? So, yeah, the first question was if we, if building StuckNet 2.0
[12:20.490 --> 12:28.930]  is possible, of course, legitimately. When we start to look at the components and we saw that
[12:29.690 --> 12:39.290]  if, for our luck, the community luck, the discovery, the, say, equivalent vulnerabilities
[12:39.290 --> 12:45.550]  that were found in the last decade to allegedly build the StuckNet 2.0 were disclosed to Microsoft
[12:45.550 --> 12:55.430]  in a safe manner, but if an evil corp that will manage to do it by themselves, a single actor,
[12:55.430 --> 13:03.030]  and allegedly can build equivalent capabilities, propagation capabilities of StuckNet. So
[13:03.030 --> 13:08.630]  we asked ourselves, okay, what else is missing? And the only missing part was the printer spooler
[13:08.630 --> 13:15.310]  vulnerability. So we thought it would be a very interesting research, and it was. So we started to
[13:15.310 --> 13:25.330]  dig in and found three vulnerabilities. Next question we have in chat is what do you think
[13:25.330 --> 13:34.450]  about the state of variant analysis in the Windows platform? What do you mean by variant analysis?
[13:35.350 --> 13:42.310]  We'll have a follow-up there and we'll get back to us. All right, so the next one was
[13:42.930 --> 13:46.710]  were there any unused methods found by you in StuckNet's code
[13:46.710 --> 13:50.490]  revealing any possible planned future attacks?
[13:55.850 --> 14:02.090]  Yeah, we didn't mean, I mean, we didn't look on StuckNet code or, you know, we just,
[14:02.860 --> 14:06.850]  we will focus on the vulnerability which were used with StuckNet. We didn't,
[14:06.850 --> 14:11.570]  and the propagation part, we didn't dive into StuckNet's code.
[14:14.390 --> 14:19.310]  Clarification on that last question, when it comes to variant analysis, they were speaking to
[14:19.310 --> 14:27.450]  like analysis existing vulnerabilities to find variants. I don't know. Okay, I think if I got it
[14:27.450 --> 14:34.430]  correctly, I think that the state, I mean, it's very interesting because I know that once someone
[14:34.430 --> 14:41.670]  finds a pretty common bug class, a lot of other researchers are diving into it and find a lot. I
[14:41.670 --> 14:50.290]  mean, if you can take a look of MSRC each month, obviously, releasing a bulletin of patch Tuesday.
[14:50.670 --> 14:55.910]  And I think that the very common vulnerability bug class is, of course, the elevation of
[14:55.910 --> 15:03.350]  privilege, which is caused by logic bugs. I think that you can see a lot. And I think that the trend
[15:03.350 --> 15:10.650]  got started, I don't know if officially, but at least what I know is James Forshaw just, you know,
[15:10.650 --> 15:17.530]  took a look of all of the file system privilege issues and released a lot of tools
[15:18.250 --> 15:24.310]  that helped other researchers to take a look of it. And then people just found a lot of variants.
[15:24.310 --> 15:35.730]  And so I think that is definitely a pretty discussed topic. And I know that I will
[15:35.730 --> 15:40.870]  keep in and take a look if the backlog still exists, if that answered your question.
[15:41.070 --> 15:51.230]  Yeah, if I may add, that's why we started to develop our driver, mitigation driver,
[15:51.230 --> 15:56.070]  it's not focused on a specific variant. It looks at the root cause of the entire
[15:56.070 --> 16:08.950]  arbitrary class. So I believe that if there will be a future exploit in this
[16:08.950 --> 16:14.050]  bug class and this driver, which is only a POC, someone will take it and make it more
[16:14.570 --> 16:24.670]  product ready, production ready. So we may catch some new and future exploits.
[16:27.180 --> 16:35.080]  I think it will be interesting to see if any vendor adopting the idea,
[16:35.080 --> 16:45.500]  implementing it in his own product. Yeah, I'm glad you mentioned the driver. I was
[16:45.500 --> 16:49.400]  interested in the analysis of those universal right locations.
[16:51.540 --> 16:58.080]  I mean, it seems like that's something that could be fixed in policy as well. What do you see the
[16:58.080 --> 17:03.660]  advantage of using the driver approach you did over just an ACL and a policy or something?
[17:05.140 --> 17:13.980]  I mean, it can be fixed by policy, right? I mean, we wanted to demonstrate this solution.
[17:13.980 --> 17:21.260]  It's not like we are saying that it's 100% sealed and there are no vulnerabilities that
[17:21.260 --> 17:26.660]  can bypass it. But we do think it was a pretty good way to demonstrate it. I think that the use
[17:28.300 --> 17:35.560]  of a minifilter driver is good because obviously you catch the IRPs and the IO requests pretty low
[17:35.560 --> 17:42.240]  and you can just block it and cancel it. I don't know what kind of whitelisting
[17:44.400 --> 17:49.600]  or policy you will use. Obviously, the vendor can just implement it by using
[17:49.600 --> 17:56.520]  his own minifilter driver. But I think it's a pretty good demonstration.
[17:59.960 --> 18:06.780]  So we talked about this a little before the call started. I think the most comical thing
[18:06.780 --> 18:10.900]  I saw in your presentation was that you all managed somehow to get the
[18:11.650 --> 18:18.900]  the LEET tag on your CVE. Was that something that you actually timed or was it just a happy
[18:18.900 --> 18:26.020]  coincidence that Microsoft labeled you guys LEET with their CVE-2021-337?
[18:26.840 --> 18:31.340]  It wasn't a happy coincidence. It was the happiest coincidence. I mean, we didn't
[18:32.160 --> 18:39.470]  organize anything. We didn't ask for it. We just got it. Thank you, Nate Warfield from MSRC.
[18:39.970 --> 18:47.450]  We signed it. 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 --> 18:59.870]  I think I have all the big what-if questions, so I'm just going to throw this one out even after
[18:59.870 --> 19:05.590]  the other one. In your talk, you focused a bit about how the last patch, the previous patch,
[19:05.590 --> 19:10.190]  kind of killed the concept of remote execution and all of these were focused on local.
[19:10.470 --> 19:14.230]  With these new releases that you've just done, the POC releases,
[19:14.230 --> 19:19.150]  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:42.080]  I feel like I just put a very pregnant question out there. It's like,
[19:42.080 --> 19:43.100]  come on, guys.
[19:47.180 --> 19:53.800]  No, we're pretty happy to have you guys. I think this is pretty interesting. I think there was a
[19:53.800 --> 20:06.460]  really... I really appreciated the sort of complete walkthrough of what the malware did and what
[20:06.460 --> 20:11.620]  exploited each step. And I think, like you said, this may have been... or there should have been
[20:11.620 --> 20:17.440]  something that was covered pretty extensively over the last 10 years, but going back and
[20:17.440 --> 20:26.750]  revisiting those can have happy coincidences as well, right? Yeah, definitely. I think that we'll
[20:26.750 --> 20:36.590]  be glad to see another briefing and walkthrough in a decade. So if there's someone we'll remember,
[20:36.590 --> 20:42.330]  it'll be probably still interesting to see. Next time on Vegas.
[20:42.990 --> 20:44.270]  Yeah, definitely.
[20:49.340 --> 20:54.080]  Okay, so we're coming up on only 10 minutes left. Do you guys have any last words you'd
[20:54.080 --> 20:59.380]  like to share about the research? I shared your GitHub out there, and I understand that
[21:00.340 --> 21:05.260]  you've kind of got one more release up your sleeves waiting for, you know, patch Tuesday
[21:05.260 --> 21:09.680]  next week. Do you want to give us a preview of what we may see then?
[21:10.300 --> 21:17.080]  Yeah, so actually, we gave it a preview during our talk. We had a video which demonstrated the
[21:17.080 --> 21:24.800]  demo of how we bypassed the patch of CB20201048 and how we re-exploited it. Obviously, we can't
[21:24.800 --> 21:31.200]  provide the details now, but we'll have to wait in the last moment when the patch will be released.
[21:31.200 --> 21:37.300]  We hope it will be on the following patch Tuesday. That's what NSRC told us, but we can't
[21:37.300 --> 21:44.600]  of course because we're not Microsoft, so we have to wait and see. And once we'll be able to make
[21:44.600 --> 21:51.040]  sure that it was already patched, we will release the POC in the GitHub repository that you published
[21:51.040 --> 22:00.120]  on the channel, and we will also provide a write-up, a technical blog post. So wait and see.
[22:00.120 --> 22:09.800]  We'll mention it on Twitter as well once it will be deployed. And the last thing I wanted to say
[22:09.800 --> 22:15.420]  if you want to add something, so go ahead. But I think that it was very interesting
[22:16.920 --> 22:24.420]  research, and we provided all of our technical materials in our GitHub repository. And if anyone
[22:24.420 --> 22:30.240]  would like to continue research in the same area or something, if you have any questions,
[22:30.240 --> 22:36.800]  go ahead. You can DM me on Twitter. You can mention me, and we'll be glad, Tomer and I,
[22:36.800 --> 22:44.140]  to help someone to keep... I think there are a lot of other areas which are related,
[22:44.140 --> 22:48.860]  not even on the spore itself, but even in the spore itself. It's a huge mechanism,
[22:48.860 --> 22:53.420]  and there are a lot of things to keep on investigating. And we didn't have much time,
[22:53.420 --> 22:58.780]  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.980]  Okay, well, so I'd really like to thank you guys for the talk you guys did. I want to
[23:08.980 --> 23:15.800]  congratulate you again on your first time at DEF CON, and if dropping two O-days for DEF CON
[23:16.720 --> 23:21.660]  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:24.440]  Thank you very much. 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.