start	end	text
28000	35900	All right, looks like we're live. So, thank you all for joining us this morning. I have
37200	44080	Palig Hadar and Tomer Barr, who are going to be here to be talking about their research into the
44080	50100	Stuxnet printing vulnerabilities that they found. They're still around after, you know,
50100	56300	10 years later. But to start things off, we have two first-time speakers. And as our tradition
56300	63980	in DEF CON, we shot the noobs. And so, I'd like to invite you all to join me in a shot, folks.
64220	76420	Here's to your talk. Thank you. Cheers. All right, great. So, we actually have a first question on
76420	82300	the line. It said, can you please explain more about the fuzzing process when finding corruption
82300	91600	in the SHD files? Yeah, sure. So, actually, it was pretty interesting because we didn't want to
91600	99120	use some, I don't know, already existing tool. We wanted to do something on our own.
99440	110080	So, after we understood the SHD processing and all of this stuff, we just wanted to do
110080	116300	the most naive thing. We just written our own Python script, which takes already
119340	126960	existing SHD file, which works. And we just mutated it one by one, one byte at a time. And
126960	134460	we used zero to FF on each byte. And we didn't do anything that was, you know, dependent by
135280	143580	each byte. We just did it each byte at a time. Afterwards, we just dropped all the SHD files
144100	148720	and we wanted to make sure it's working. And we understood that there's a kind of a limit
149400	155880	in the service that it won't process more than 256 files at a time. So, we just modified the
155880	161900	spoiler service. We just patched it and we replaced the check with knobs, of course. And
161900	168280	then we just kicked around a kind of a spoiler, which was modified and it just worked. And then
168280	173560	it took 20 minutes. It processed all of the SHD files and it crashed. So, it was pretty cool.
174940	182500	We don't intend to release the Python script, but maybe we will. We need to discuss it.
183600	191820	Very cool. Yeah, I was pretty impressed with the ability or what you guys did in
191820	198640	walking through the entire, for lack of a better term, kill chain of the Stuxnet.
199540	204420	I mean, how much of studying that original code do you think
204420	210340	influenced your discovery of these remaining vulnerabilities?
211100	218340	Yeah, I think it was pretty much. Because when we started to look at it, we thought that,
218340	225100	okay, it's 10 years after Stuxnet. A lot of very strong researchers already research it.
225100	232180	What are the chances that we will find anything new? But we came with a lot of motivation.
232280	239340	And after seeing that the first patch was not fully patched and can be re-exploited and the
239340	245420	second patch and the third patch. So, we understood that we are onto something and
245420	251820	started the research. And after 20 minutes of fuzzing, you get your first crash and it's not usual.
251860	259600	And that gave us hope that we'll find more. And yeah, it's happened.
263480	269260	Great. We have another question from the audience. It said, was the SHD crash exploitable?
270500	276480	Actually, good question. From what we've seen, it wasn't exploitable. It was only one
276480	285280	byte which was controllable and it was pretty odd. I mean, we're pretty sure it wasn't exploitable.
285280	290700	But we really invite everyone to try and maybe to understand whether it's exploitable or not.
290700	298460	And if it's exploitable, tweet about it and you can mention me. It will be very interesting
298460	303420	because, as we mentioned, Microsoft didn't fix it. So, it might be more interesting and
304000	309080	maybe if you'll find something, you can report it to Microsoft as well. So, good luck.
311860	315840	Actually, we see a lot of people, a lot of researchers that haven't been
315840	324220	in the spooler and now we see a lot of research on the spooler. We hope we contributed well.
325300	332390	Definitely. So, I see another question.
333130	339490	Yeah, so the other vols, were they found by fuzzing or code review?
340570	347410	So, actually, good question. So, after we started fuzzing and we had our first crash,
347410	353810	we were intrigued enough in order to move to manual source code auditing and manual
353810	360510	binary auditing. So, it was found completely manually, 100%. And we just looked at the code
361490	366210	and we understood how the mechanism works and what kind of use cases we can
366790	371890	challenge the mechanism and we just found it manually. It was pretty cool.
374350	381750	Basically, I know I do, I think Tamara as well, we use less fuzzing. We generally do
381750	388770	more manual code auditing. But I think, you know, you can find interesting bugs using
389790	396850	fuzzing and using manual code auditing. If you use both, it will be probably the best.
400470	406290	Yeah, so you mentioned the Microsoft decision not to patch that SHD1. I mean,
406290	412590	do you think that they were justified in their logic on that or would you like to see them patch
412590	426480	it? Well, I think that they have a very clear security boundary and service criteria on MSRC.
426960	432620	I don't want to say whether I think it's right or not. All I can say that they mentioned that
432620	439400	local denial of service is not, you know, it's not past their service criteria and therefore
439400	445040	it won't be fixed. Maybe they will decide to fix it if it will be used in order to abuse or
445040	452760	something. But I respect their decision. Yeah, I totally agree. And maybe other vendors, endpoint
452760	459760	vendors will release signature for that. Maybe the antivirus or other security control can manage to
460520	469120	prevent this. Yeah, so you mentioned... Oh, go ahead. Oh, I have a question. So when I was
469120	474120	watching the video, I noticed that when it came to the last path vulnerability, you kind of gave
474240	478980	a very pregnant there, you know, no vulnerability yet. And is that more because you guys are
478980	483220	expecting one to come out or have a theory that there's one out that just hasn't been released in
483220	490940	the wild? Like, there was a big emphasis on that. We don't have anything up in our sleeve and we
490940	496200	don't know about anything. And of course, if we will know, we will report it to Microsoft.
496200	504100	But all we said is, you know, you have two paths which were exploited and you have the third one
504100	509400	which might be exploited and might not. We don't know about anything that, you know, we know as
509400	517700	much as you know. But I don't know. Maybe we will find that Microsoft has patched it in the future.
518480	532140	But nothing concrete. Great. So we actually have another question on the line. It said,
532140	535900	after your experience on this, what would you say to researchers attempting to replicate the
535900	546900	same vulnerabilities on Siemen microcontrollers matching those in Iran? So, Tomer, do you want
546900	557340	to take it? Siri, can you repeat the question? Yeah, it said, after your experience, what would
557340	562620	you say to researchers attempting to replicate the same vulnerabilities on Siemen microcontrollers
562620	570120	matching those in Iran? Well, actually, this is not the focus of our research,
570120	577200	so we are not experts on that. I think that our research is basically focused on the propagation
577200	583600	part of Succent and the Spuro service specifically. And the Spuro service is on the Windows
584900	591680	Microsoft code, so it's not related to the, you know, to the hardware or anything else.
591680	603270	Just any default Windows OS algorithm. I think it's a huge, you know, it's a huge domain,
603270	611330	Stuxnet, and we have so many aspects to look. We focus on the Windows part, and we don't know if
611330	619550	the fact that we found a vulnerability in the same domain in the Windows part will, you know,
619550	623950	just said that if you will do the same in the Siemens PLC, it will be the same. But I think it
623950	632050	is an interesting part that if you want to get into, just share it with the community, I think
632050	637010	it will be interesting enough to people to come and see. So maybe we'll see you in DEF CON next
637010	642430	year, answering this question. Yeah, something tells me if they actually have, anyone has an
642430	647130	O-Day up their sleeve for Siemens microcontrollers, they're probably not presenting that at DEF CON,
647130	662310	but we'll see. Right, so you talked about the spooler, or you demonstrated how the spooler
662310	669990	was exploited by a local user to get the escalation. It seemed like you were hinting
669990	674750	that this might still be a remote capability as well. Did you find that or not?
675530	680310	No, actually, we were only focused on the local, the local tool installation
681070	687990	pack vector, and we haven't found a way to bypass the patch, the original patch,
687990	698130	to get the remote tool execution. Great, so it looks like we've got another question coming in,
698130	705670	but let's see, we're all waiting for typing to be done, but
707170	716290	so, you know, earlier you talked about walking through the the StuckNet process and sort of
716290	723650	finding which vulnerabilities still existed. So your original intent was to recreate that
723650	730810	and look for residual, or was it actually to look at, you know, what vulnerabilities that by
730810	740490	themselves may be still available? So, yeah, the first question was if we, if building StuckNet 2.0
740490	748930	is possible, of course, legitimately. When we start to look at the components and we saw that
749690	759290	if, for our luck, the community luck, the discovery, the, say, equivalent vulnerabilities
759290	765550	that were found in the last decade to allegedly build the StuckNet 2.0 were disclosed to Microsoft
765550	775430	in a safe manner, but if an evil corp that will manage to do it by themselves, a single actor,
775430	783030	and allegedly can build equivalent capabilities, propagation capabilities of StuckNet. So
783030	788630	we asked ourselves, okay, what else is missing? And the only missing part was the printer spooler
788630	795310	vulnerability. So we thought it would be a very interesting research, and it was. So we started to
795310	805330	dig in and found three vulnerabilities. Next question we have in chat is what do you think
805330	814450	about the state of variant analysis in the Windows platform? What do you mean by variant analysis?
815350	822310	We'll have a follow-up there and we'll get back to us. All right, so the next one was
822930	826710	were there any unused methods found by you in StuckNet's code
826710	830490	revealing any possible planned future attacks?
835850	842090	Yeah, we didn't mean, I mean, we didn't look on StuckNet code or, you know, we just,
842860	846850	we will focus on the vulnerability which were used with StuckNet. We didn't,
846850	851570	and the propagation part, we didn't dive into StuckNet's code.
854390	859310	Clarification on that last question, when it comes to variant analysis, they were speaking to
859310	867450	like analysis existing vulnerabilities to find variants. I don't know. Okay, I think if I got it
867450	874430	correctly, I think that the state, I mean, it's very interesting because I know that once someone
874430	881670	finds a pretty common bug class, a lot of other researchers are diving into it and find a lot. I
881670	890290	mean, if you can take a look of MSRC each month, obviously, releasing a bulletin of patch Tuesday.
890670	895910	And I think that the very common vulnerability bug class is, of course, the elevation of
895910	903350	privilege, which is caused by logic bugs. I think that you can see a lot. And I think that the trend
903350	910650	got started, I don't know if officially, but at least what I know is James Forshaw just, you know,
910650	917530	took a look of all of the file system privilege issues and released a lot of tools
918250	924310	that helped other researchers to take a look of it. And then people just found a lot of variants.
924310	935730	And so I think that is definitely a pretty discussed topic. And I know that I will
935730	940870	keep in and take a look if the backlog still exists, if that answered your question.
941070	951230	Yeah, if I may add, that's why we started to develop our driver, mitigation driver,
951230	956070	it's not focused on a specific variant. It looks at the root cause of the entire
956070	968950	arbitrary class. So I believe that if there will be a future exploit in this
968950	974050	bug class and this driver, which is only a POC, someone will take it and make it more
974570	984670	product ready, production ready. So we may catch some new and future exploits.
987180	995080	I think it will be interesting to see if any vendor adopting the idea,
995080	1005500	implementing it in his own product. Yeah, I'm glad you mentioned the driver. I was
1005500	1009400	interested in the analysis of those universal right locations.
1011540	1018080	I mean, it seems like that's something that could be fixed in policy as well. What do you see the
1018080	1023660	advantage of using the driver approach you did over just an ACL and a policy or something?
1025140	1033980	I mean, it can be fixed by policy, right? I mean, we wanted to demonstrate this solution.
1033980	1041260	It's not like we are saying that it's 100% sealed and there are no vulnerabilities that
1041260	1046660	can bypass it. But we do think it was a pretty good way to demonstrate it. I think that the use
1048300	1055560	of a minifilter driver is good because obviously you catch the IRPs and the IO requests pretty low
1055560	1062240	and you can just block it and cancel it. I don't know what kind of whitelisting
1064400	1069600	or policy you will use. Obviously, the vendor can just implement it by using
1069600	1076520	his own minifilter driver. But I think it's a pretty good demonstration.
1079960	1086780	So we talked about this a little before the call started. I think the most comical thing
1086780	1090900	I saw in your presentation was that you all managed somehow to get the
1091650	1098900	the LEET tag on your CVE. Was that something that you actually timed or was it just a happy
1098900	1106020	coincidence that Microsoft labeled you guys LEET with their CVE-2021-337?
1106840	1111340	It wasn't a happy coincidence. It was the happiest coincidence. I mean, we didn't
1112160	1119470	organize anything. We didn't ask for it. We just got it. Thank you, Nate Warfield from MSRC.
1119970	1127450	We signed it. It's an awesome CVE number and I think everyone wanted to get it.
1129410	1131750	Maybe next year, one more time.
1131870	1139870	I think I have all the big what-if questions, so I'm just going to throw this one out even after
1139870	1145590	the other one. In your talk, you focused a bit about how the last patch, the previous patch,
1145590	1150190	kind of killed the concept of remote execution and all of these were focused on local.
1150470	1154230	With these new releases that you've just done, the POC releases,
1154230	1159150	what do you think that there's a chance that these can kind of pivot into remote execution now?
1161150	1164690	It's not likely, but we'll see.
1173140	1178660	Yeah, I warned you guys against one-word answers, but we'll let you slide on that one.
1179340	1182080	I feel like I just put a very pregnant question out there. It's like,
1182080	1183100	come on, guys.
1187180	1193800	No, we're pretty happy to have you guys. I think this is pretty interesting. I think there was a
1193800	1206460	really... I really appreciated the sort of complete walkthrough of what the malware did and what
1206460	1211620	exploited each step. And I think, like you said, this may have been... or there should have been
1211620	1217440	something that was covered pretty extensively over the last 10 years, but going back and
1217440	1226750	revisiting those can have happy coincidences as well, right? Yeah, definitely. I think that we'll
1226750	1236590	be glad to see another briefing and walkthrough in a decade. So if there's someone we'll remember,
1236590	1242330	it'll be probably still interesting to see. Next time on Vegas.
1242990	1244270	Yeah, definitely.
1249340	1254080	Okay, so we're coming up on only 10 minutes left. Do you guys have any last words you'd
1254080	1259380	like to share about the research? I shared your GitHub out there, and I understand that
1260340	1265260	you've kind of got one more release up your sleeves waiting for, you know, patch Tuesday
1265260	1269680	next week. Do you want to give us a preview of what we may see then?
1270300	1277080	Yeah, so actually, we gave it a preview during our talk. We had a video which demonstrated the
1277080	1284800	demo of how we bypassed the patch of CB20201048 and how we re-exploited it. Obviously, we can't
1284800	1291200	provide the details now, but we'll have to wait in the last moment when the patch will be released.
1291200	1297300	We hope it will be on the following patch Tuesday. That's what NSRC told us, but we can't
1297300	1304600	of course because we're not Microsoft, so we have to wait and see. And once we'll be able to make
1304600	1311040	sure that it was already patched, we will release the POC in the GitHub repository that you published
1311040	1320120	on the channel, and we will also provide a write-up, a technical blog post. So wait and see.
1320120	1329800	We'll mention it on Twitter as well once it will be deployed. And the last thing I wanted to say
1329800	1335420	if you want to add something, so go ahead. But I think that it was very interesting
1336920	1344420	research, and we provided all of our technical materials in our GitHub repository. And if anyone
1344420	1350240	would like to continue research in the same area or something, if you have any questions,
1350240	1356800	go ahead. You can DM me on Twitter. You can mention me, and we'll be glad, Tomer and I,
1356800	1364140	to help someone to keep... I think there are a lot of other areas which are related,
1364140	1368860	not even on the spore itself, but even in the spore itself. It's a huge mechanism,
1368860	1373420	and there are a lot of things to keep on investigating. And we didn't have much time,
1373420	1378780	so if anyone would like to do it and would like some help, go ahead.
1380220	1381640	Yeah, totally agree.
1384640	1388980	Okay, well, so I'd really like to thank you guys for the talk you guys did. I want to
1388980	1395800	congratulate you again on your first time at DEF CON, and if dropping two O-days for DEF CON
1396720	1401660	is what we can see in the future from you guys, I'm sure we'll be inviting you back next year.
1402020	1403200	So, thank you all.
1403200	1404440	Thank you very much. It was a pleasure.
1404820	1407480	It was fun, and we have started to work on it.
1408120	1409040	Stay tuned.