All right, looks like we're live. So, thank you all for joining us this morning. 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. They're still around after, you know,
10 years later. But to start things off, we have two first-time speakers. And as our tradition
in DEF CON, we shot the noobs. And so, I'd like to invite you all to join me in a shot, folks.
Here's to your talk. Thank you. Cheers. All right, great. So, we actually have a first question on
the line. It said, can you please explain more about the fuzzing process when finding corruption
in the SHD files? Yeah, sure. So, actually, it was pretty interesting because we didn't want to
use some, I don't know, already existing tool. We wanted to do something on our own.
So, after we understood the SHD processing and all of this stuff, we just wanted to do
the most naive thing. We just written our own Python script, which takes already
existing SHD file, which works. And we just mutated it one by one, one byte at a time. And
we used zero to FF on each byte. And we didn't do anything that was, you know, dependent by
each byte. We just did it each byte at a time. Afterwards, we just dropped all the SHD files
and we wanted to make sure it's working. 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. So, we just modified the
spoiler service. We just patched it and we replaced the check with knobs, of course. And
then we just kicked around a kind of a spoiler, which was modified and it just worked. And then
it took 20 minutes. It processed all of the SHD files and it crashed. So, it was pretty cool.
We don't intend to release the Python script, but maybe we will. We need to discuss it.
Very cool. 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.
I mean, how much of studying that original code do you think
influenced your discovery of these remaining vulnerabilities?
Yeah, I think it was pretty much. Because when we started to look at it, we thought that,
okay, it's 10 years after Stuxnet. A lot of very strong researchers already research it.
What are the chances that we will find anything new? But we came with a lot of motivation.
And after seeing that the first patch was not fully patched and can be re-exploited and the
second patch and the third patch. So, we understood that we are onto something and
started the research. And after 20 minutes of fuzzing, you get your first crash and it's not usual.
And that gave us hope that we'll find more. And yeah, it's happened.
Great. We have another question from the audience. It said, was the SHD crash exploitable?
Actually, good question. From what we've seen, it wasn't exploitable. It was only one
byte which was controllable and it was pretty odd. I mean, we're pretty sure it wasn't exploitable.
But we really invite everyone to try and maybe to understand whether it's exploitable or not.
And if it's exploitable, tweet about it and you can mention me. It will be very interesting
because, as we mentioned, Microsoft didn't fix it. So, it might be more interesting and
maybe if you'll find something, you can report it to Microsoft as well. So, good luck.
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. We hope we contributed well.
Definitely. So, I see another question.
Yeah, so the other vols, were they found by fuzzing or code review?
So, actually, good question. 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. So, it was found completely manually, 100%. 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. It was pretty cool.
Basically, I know I do, I think Tamara as well, we use less fuzzing. We generally do
more manual code auditing. But I think, you know, you can find interesting bugs using
fuzzing and using manual code auditing. If you use both, it will be probably the best.
Yeah, so you mentioned the Microsoft decision not to patch that SHD1. I mean,
do you think that they were justified in their logic on that or would you like to see them patch
it? Well, I think that they have a very clear security boundary and service criteria on MSRC.
I don't want to say whether I think it's right or not. 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. Maybe they will decide to fix it if it will be used in order to abuse or
something. But I respect their decision. Yeah, I totally agree. And maybe other vendors, endpoint
vendors will release signature for that. Maybe the antivirus or other security control can manage to
prevent this. Yeah, so you mentioned... Oh, go ahead. Oh, I have a question. 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. 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? Like, there was a big emphasis on that. We don't have anything up in our sleeve and we
don't know about anything. And of course, if we will know, we will report it to Microsoft.
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. We don't know about anything that, you know, we know as
much as you know. But I don't know. Maybe we will find that Microsoft has patched it in the future.
But nothing concrete. Great. So we actually have another question on the line. 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? So, Tomer, do you want
to take it? Siri, can you repeat the question? 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? Well, actually, this is not the focus of our research,
so we are not experts on that. I think that our research is basically focused on the propagation
part of Succent and the Spuro service specifically. 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.
Just any default Windows OS algorithm. I think it's a huge, you know, it's a huge domain,
Stuxnet, and we have so many aspects to look. 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. 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. So maybe we'll see you in DEF CON next
year, answering this question. 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. Right, so you talked about the spooler, or you demonstrated how the spooler
was exploited by a local user to get the escalation. It seemed like you were hinting
that this might still be a remote capability as well. Did you find that or not?
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. 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. 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? So, yeah, the first question was if we, if building StuckNet 2.0
is possible, of course, legitimately. 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, 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. So
we asked ourselves, okay, what else is missing? And the only missing part was the printer spooler
vulnerability. So we thought it would be a very interesting research, and it was. So we started to
dig in and found three vulnerabilities. Next question we have in chat is what do you think
about the state of variant analysis in the Windows platform? What do you mean by variant analysis?
We'll have a follow-up there and we'll get back to us. 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?
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. We didn't,
and the propagation part, we didn't dive into StuckNet's code.
Clarification on that last question, when it comes to variant analysis, they were speaking to
like analysis existing vulnerabilities to find variants. I don't know. 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. I
mean, if you can take a look of MSRC each month, obviously, releasing a bulletin of patch Tuesday.
And I think that the very common vulnerability bug class is, of course, the elevation of
privilege, which is caused by logic bugs. I think that you can see a lot. 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. And then people just found a lot of variants.
And so I think that is definitely a pretty discussed topic. And I know that I will
keep in and take a look if the backlog still exists, if that answered your question.
Yeah, if I may add, that's why we started to develop our driver, mitigation driver,
it's not focused on a specific variant. It looks at the root cause of the entire
arbitrary class. 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. So we may catch some new and future exploits.
I think it will be interesting to see if any vendor adopting the idea,
implementing it in his own product. Yeah, I'm glad you mentioned the driver. I was
interested in the analysis of those universal right locations.
I mean, it seems like that's something that could be fixed in policy as well. What do you see the
advantage of using the driver approach you did over just an ACL and a policy or something?
I mean, it can be fixed by policy, right? I mean, we wanted to demonstrate this solution.
It's not like we are saying that it's 100% sealed and there are no vulnerabilities that
can bypass it. But we do think it was a pretty good way to demonstrate it. 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. I don't know what kind of whitelisting
or policy you will use. Obviously, the vendor can just implement it by using
his own minifilter driver. But I think it's a pretty good demonstration.
So we talked about this a little before the call started. 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. 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?
It wasn't a happy coincidence. It was the happiest coincidence. I mean, we didn't
organize anything. We didn't ask for it. We just got it. Thank you, Nate Warfield from MSRC.
We signed it. It's an awesome CVE number and I think everyone wanted to get it.
Maybe next year, one more time.
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. 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.
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?
It's not likely, but we'll see.
Yeah, I warned you guys against one-word answers, but we'll let you slide on that one.
I feel like I just put a very pregnant question out there. It's like,
come on, guys.
No, we're pretty happy to have you guys. I think this is pretty interesting. I think there was a
really... I really appreciated the sort of complete walkthrough of what the malware did and what
exploited each step. 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? Yeah, definitely. I think that we'll
be glad to see another briefing and walkthrough in a decade. So if there's someone we'll remember,
it'll be probably still interesting to see. Next time on Vegas.
Yeah, definitely.
Okay, so we're coming up on only 10 minutes left. Do you guys have any last words you'd
like to share about the research? 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. Do you want to give us a preview of what we may see then?
Yeah, so actually, we gave it a preview during our talk. We had a video which demonstrated the
demo of how we bypassed the patch of CB20201048 and how we re-exploited it. Obviously, we can't
provide the details now, but we'll have to wait in the last moment when the patch will be released.
We hope it will be on the following patch Tuesday. That's what NSRC told us, but we can't
of course because we're not Microsoft, so we have to wait and see. 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. So wait and see.
We'll mention it on Twitter as well once it will be deployed. And the last thing I wanted to say
if you want to add something, so go ahead. But I think that it was very interesting
research, and we provided all of our technical materials in our GitHub repository. And if anyone
would like to continue research in the same area or something, if you have any questions,
go ahead. You can DM me on Twitter. 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. It's a huge mechanism,
and there are a lot of things to keep on investigating. And we didn't have much time,
so if anyone would like to do it and would like some help, go ahead.
Yeah, totally agree.
Okay, well, so I'd really like to thank you guys for the talk you guys did. 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.
So, thank you all.
Thank you very much. It was a pleasure.
It was fun, and we have started to work on it.
Stay tuned.