1
00:00:28,000 --> 00:00:31,440
All right, looks like we're live.

2
00:00:31,700 --> 00:00:35,600
So, thank you all for joining us this morning.

3
00:00:35,600 --> 00: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.

4
00:00:47,960 --> 00:00:51,260
They're still around after, you know, 10 years later.

5
00:00:51,340 --> 00:00:55,300
But to start things off, we have two first-time speakers.

6
00:00:55,480 --> 00:00:59,680
And as our tradition in DEF CON, we shot the noobs.

7
00:00:59,680 --> 00:01:03,980
And so, I'd like to invite you all to join me in a shot, folks.

8
00:01:04,220 --> 00:01:05,840
Here's to your talk.

9
00:01:08,000 --> 00:01:08,860
Thank you.

10
00:01:08,880 --> 00:01:09,660
Cheers.

11
00:01:12,260 --> 00:01:13,700
All right, great.

12
00:01:13,940 --> 00:01:17,300
So, we actually have a first question on the line.

13
00:01:17,560 --> 00:01:24,860
It said, can you please explain more about the fuzzing process when finding corruption in the SHD files?

14
00:01:26,760 --> 00:01:28,020
Yeah, sure.

15
00:01:28,520 --> 00:01:36,840
So, actually, it was pretty interesting because we didn't want to use some, I don't know, already existing tool.

16
00:01:36,840 --> 00:01:39,120
We wanted to do something on our own.

17
00:01:39,440 --> 00:01:52,200
So, after we understood the SHD processing and all of this stuff, we just wanted to do the most naive thing.

18
00:01:52,200 --> 00:01:56,300
We just written our own Python script, which takes already

19
00:01:59,340 --> 00:02:01,880
existing SHD file, which works.

20
00:02:01,880 --> 00:02:06,660
And we just mutated it one by one, one byte at a time.

21
00:02:06,660 --> 00:02:10,080
And we used zero to FF on each byte.

22
00:02:10,080 --> 00:02:16,180
And we didn't do anything that was, you know, dependent by each byte.

23
00:02:16,180 --> 00:02:19,840
We just did it each byte at a time.

24
00:02:20,900 --> 00:02:26,420
Afterwards, we just dropped all the SHD files and we wanted to make sure it's working.

25
00:02:26,420 --> 00: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.

26
00:02:33,780 --> 00:02:37,180
So, we just modified the spoiler service.

27
00:02:37,180 --> 00:02:41,600
We just patched it and we replaced the check with knobs, of course.

28
00:02:41,720 --> 00:02:47,480
And then we just kicked around a kind of a spoiler, which was modified and it just worked.

29
00:02:47,940 --> 00:02:49,120
And then it took 20 minutes.

30
00:02:49,120 --> 00:02:51,960
It processed all of the SHD files and it crashed.

31
00:02:52,280 --> 00:02:53,560
So, it was pretty cool.

32
00:02:54,940 --> 00:03:00,940
We don't intend to release the Python script, but maybe we will.

33
00:03:00,940 --> 00:03:02,500
We need to discuss it.

34
00:03:03,600 --> 00:03:04,520
Very cool.

35
00:03:04,520 --> 00: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.

36
00:03:19,540 --> 00:03:30,340
I mean, how much of studying that original code do you think influenced your discovery of these remaining vulnerabilities?

37
00:03:31,100 --> 00:03:33,660
Yeah, I think it was pretty much.

38
00:03:33,660 --> 00:03:40,660
Because when we started to look at it, we thought that, okay, it's 10 years after Stuxnet.

39
00:03:40,740 --> 00:03:45,100
A lot of very strong researchers already research it.

40
00:03:45,100 --> 00:03:49,120
What are the chances that we will find anything new?

41
00:03:49,120 --> 00:03:52,180
But we came with a lot of motivation.

42
00:03:52,280 --> 00: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.

43
00:04:01,160 --> 00:04:06,580
So, we understood that we are onto something and started the research.

44
00:04:06,580 --> 00:04:11,820
And after 20 minutes of fuzzing, you get your first crash and it's not usual.

45
00:04:11,860 --> 00:04:18,000
And that gave us hope that we'll find more.

46
00:04:18,000 --> 00:04:19,600
And yeah, it's happened.

47
00:04:23,480 --> 00:04:24,100
Great.

48
00:04:24,100 --> 00:04:26,420
We have another question from the audience.

49
00:04:26,420 --> 00:04:29,260
It said, was the SHD crash exploitable?

50
00:04:30,500 --> 00:04:32,280
Actually, good question.

51
00:04:32,400 --> 00:04:35,760
From what we've seen, it wasn't exploitable.

52
00:04:35,760 --> 00:04:42,560
It was only one byte which was controllable and it was pretty odd.

53
00:04:42,560 --> 00:04:45,280
I mean, we're pretty sure it wasn't exploitable.

54
00:04:45,280 --> 00:04:50,700
But we really invite everyone to try and maybe to understand whether it's exploitable or not.

55
00:04:50,700 --> 00:04:56,180
And if it's exploitable, tweet about it and you can mention me.

56
00:04:56,660 --> 00:05:02,000
It will be very interesting because, as we mentioned, Microsoft didn't fix it.

57
00:05:02,000 --> 00:05:07,640
So, it might be more interesting and maybe if you'll find something, you can report it to Microsoft as well.

58
00:05:07,640 --> 00:05:09,080
So, good luck.

59
00:05:11,860 --> 00: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.

60
00:05:21,880 --> 00:05:24,220
We hope we contributed well.

61
00:05:25,300 --> 00:05:26,620
Definitely.

62
00:05:30,190 --> 00:05:32,390
So, I see another question.

63
00:05:33,130 --> 00:05:39,490
Yeah, so the other vols, were they found by fuzzing or code review?

64
00:05:40,570 --> 00:05:42,990
So, actually, good question.

65
00:05:42,990 --> 00: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.

66
00:05:54,890 --> 00:05:57,850
So, it was found completely manually, 100%.

67
00:05:57,850 --> 00: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.

68
00:06:10,370 --> 00:06:11,890
It was pretty cool.

69
00:06:14,350 --> 00:06:20,650
Basically, I know I do, I think Tamara as well, we use less fuzzing.

70
00:06:20,650 --> 00:06:23,730
We generally do more manual code auditing.

71
00:06:24,070 --> 00:06:32,250
But I think, you know, you can find interesting bugs using fuzzing and using manual code auditing.

72
00:06:32,910 --> 00:06:36,850
If you use both, it will be probably the best.

73
00:06:40,470 --> 00:06:45,630
Yeah, so you mentioned the Microsoft decision not to patch that SHD1.

74
00:06:45,630 --> 00: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?

75
00:06:55,860 --> 00:07:06,480
Well, I think that they have a very clear security boundary and service criteria on MSRC.

76
00:07:06,960 --> 00:07:09,940
I don't want to say whether I think it's right or not.

77
00:07:09,940 --> 00: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.

78
00:07:20,520 --> 00:07:25,560
Maybe they will decide to fix it if it will be used in order to abuse or something.

79
00:07:25,560 --> 00:07:28,060
But I respect their decision.

80
00:07:29,320 --> 00:07:30,640
Yeah, I totally agree.

81
00:07:30,640 --> 00:07:35,280
And maybe other vendors, endpoint vendors will release signature for that.

82
00:07:35,280 --> 00:07:41,780
Maybe the antivirus or other security control can manage to prevent this.

83
00:07:44,880 --> 00:07:47,280
Yeah, so you mentioned... Oh, go ahead.

84
00:07:47,520 --> 00:07:48,520
Oh, I have a question.

85
00:07:48,520 --> 00: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.

86
00:07:57,260 --> 00: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?

87
00:08:03,800 --> 00:08:06,280
Like, there was a big emphasis on that.

88
00:08:08,180 --> 00:08:12,280
We don't have anything up in our sleeve and we don't know about anything.

89
00:08:12,280 --> 00:08:16,200
And of course, if we will know, we will report it to Microsoft.

90
00:08:16,200 --> 00: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.

91
00:08:26,420 --> 00:08:30,560
We don't know about anything that, you know, we know as much as you know.

92
00:08:31,020 --> 00:08:33,120
But I don't know.

93
00:08:33,120 --> 00:08:37,700
Maybe we will find that Microsoft has patched it in the future.

94
00:08:38,480 --> 00:08:39,840
But nothing concrete.

95
00:08:48,420 --> 00:08:48,960
Great.

96
00:08:48,960 --> 00:08:51,940
So we actually have another question on the line.

97
00:08:51,940 --> 00: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?

98
00:09:05,620 --> 00:09:07,740
So, Tomer, do you want to take it?

99
00:09:08,780 --> 00:09:10,620
Siri, can you repeat the question?

100
00:09:12,620 --> 00: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?

101
00:09:25,840 --> 00:09:32,180
Well, actually, this is not the focus of our research, so we are not experts on that.

102
00:09:32,180 --> 00:09:41,400
I think that our research is basically focused on the propagation part of Succent and the Spuro service specifically.

103
00:09:41,440 --> 00: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.

104
00:09:51,680 --> 00:09:56,160
Just any default Windows OS algorithm.

105
00:09:58,290 --> 00: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.

106
00:10:06,650 --> 00: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.

107
00:10:23,190 --> 00: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.

108
00:10:35,510 --> 00:10:38,910
So maybe we'll see you in DEF CON next year, answering this question.

109
00:10:39,830 --> 00: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.

110
00:10:52,730 --> 00: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.

111
00:11:08,230 --> 00:11:12,850
It seemed like you were hinting that this might still be a remote capability as well.

112
00:11:12,850 --> 00:11:14,750
Did you find that or not?

113
00:11:15,530 --> 00: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.

114
00:11:34,210 --> 00: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.

115
00:12:01,190 --> 00: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?

116
00:12:13,590 --> 00:12:23,070
So, yeah, the first question was if we, if building StuckNet 2.0 is possible, of course, legitimately.

117
00:12:24,030 --> 00: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,

118
00:12:47,830 --> 00: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.

119
00:13:02,790 --> 00:13:05,990
So we asked ourselves, okay, what else is missing?

120
00:13:05,990 --> 00:13:09,690
And the only missing part was the printer spooler vulnerability.

121
00:13:09,690 --> 00:13:14,190
So we thought it would be a very interesting research, and it was.

122
00:13:14,190 --> 00:13:19,290
So we started to dig in and found three vulnerabilities.

123
00:13:22,150 --> 00:13:29,010
Next question we have in chat is what do you think about the state of variant analysis in the Windows platform?

124
00:13:32,060 --> 00:13:34,450
What do you mean by variant analysis?

125
00:13:35,350 --> 00:13:39,550
We'll have a follow-up there and we'll get back to us.

126
00:13:40,270 --> 00: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?

127
00:13:55,850 --> 00: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.

128
00:14:05,950 --> 00:14:11,570
We didn't, and the propagation part, we didn't dive into StuckNet's code.

129
00:14:14,390 --> 00: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.

130
00:14:23,910 --> 00:14:24,310
I don't know.

131
00:14:24,310 --> 00: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.

132
00:14:41,670 --> 00:14:50,290
I mean, if you can take a look of MSRC each month, obviously, releasing a bulletin of patch Tuesday.

133
00:14:50,670 --> 00: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.

134
00:14:59,790 --> 00:15:01,790
I think that you can see a lot.

135
00:15:01,970 --> 00: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.

136
00:15:20,610 --> 00:15:24,310
And then people just found a lot of variants.

137
00:15:24,310 --> 00:15:31,870
And so I think that is definitely a pretty discussed topic.

138
00:15:32,690 --> 00: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.

139
00:15:41,070 --> 00: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.

140
00:15:54,190 --> 00:15:57,750
It looks at the root cause of the entire arbitrary class.

141
00:16:00,030 --> 00: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.

142
00:16:17,550 --> 00:16:24,670
So we may catch some new and future exploits.

143
00:16:27,180 --> 00:16:37,940
I think it will be interesting to see if any vendor adopting the idea, implementing it in his own product.

144
00:16:38,080 --> 00:16:39,940
Yeah, I'm glad you mentioned the driver.

145
00:16:44,820 --> 00:16:49,400
I was interested in the analysis of those universal right locations.

146
00:16:51,540 --> 00:16:56,500
I mean, it seems like that's something that could be fixed in policy as well.

147
00:16:56,720 --> 00: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?

148
00:17:05,140 --> 00:17:09,140
I mean, it can be fixed by policy, right?

149
00:17:09,520 --> 00:17:13,980
I mean, we wanted to demonstrate this solution.

150
00:17:13,980 --> 00:17:22,480
It's not like we are saying that it's 100% sealed and there are no vulnerabilities that can bypass it.

151
00:17:22,480 --> 00:17:25,860
But we do think it was a pretty good way to demonstrate it.

152
00:17:25,860 --> 00: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.

153
00:17:38,360 --> 00:17:46,720
I don't know what kind of whitelisting or policy you will use.

154
00:17:46,720 --> 00:17:52,400
Obviously, the vendor can just implement it by using his own minifilter driver.

155
00:17:52,400 --> 00:17:56,520
But I think it's a pretty good demonstration.

156
00:17:59,960 --> 00:18:03,440
So we talked about this a little before the call started.

157
00:18:03,900 --> 00: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.

158
00:18:14,080 --> 00: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?

159
00:18:26,840 --> 00:18:28,520
It wasn't a happy coincidence.

160
00:18:28,520 --> 00:18:30,260
It was the happiest coincidence.

161
00:18:30,420 --> 00:18:33,300
I mean, we didn't organize anything.

162
00:18:33,300 --> 00:18:34,660
We didn't ask for it.

163
00:18:34,660 --> 00:18:35,980
We just got it.

164
00:18:35,980 --> 00:18:39,470
Thank you, Nate Warfield from MSRC.

165
00:18:39,970 --> 00:18:41,530
We signed it.

166
00:18:41,810 --> 00:18:47,450
It's an awesome CVE number and I think everyone wanted to get it.

167
00:18:49,410 --> 00:18:51,750
Maybe next year, one more time.

168
00:18:51,870 --> 00: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.

169
00:19:00,990 --> 00: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.

170
00:19:10,470 --> 00: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?

171
00:19:21,150 --> 00:19:24,690
It's not likely, but we'll see.

172
00:19:33,140 --> 00:19:38,660
Yeah, I warned you guys against one-word answers, but we'll let you slide on that one.

173
00:19:39,340 --> 00:19:41,900
I feel like I just put a very pregnant question out there.

174
00:19:41,900 --> 00:19:43,100
It's like, come on, guys.

175
00:19:47,180 --> 00:19:50,060
No, we're pretty happy to have you guys.

176
00:19:50,060 --> 00:19:52,840
I think this is pretty interesting.

177
00:19:52,840 --> 00:19:53,800
I think there was a really...

178
00:19:53,800 --> 00:20:07,680
I really appreciated the sort of complete walkthrough of what the malware did and what exploited each step.

179
00:20:07,980 --> 00: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?

180
00:20:23,910 --> 00:20:25,630
Yeah, definitely.

181
00:20:25,630 --> 00:20:32,570
I think that we'll be glad to see another briefing and walkthrough in a decade.

182
00:20:33,290 --> 00:20:40,570
So if there's someone we'll remember, it'll be probably still interesting to see.

183
00:20:40,650 --> 00:20:42,330
Next time on Vegas.

184
00:20:42,990 --> 00:20:44,270
Yeah, definitely.

185
00:20:49,340 --> 00:20:52,500
Okay, so we're coming up on only 10 minutes left.

186
00:20:52,500 --> 00:20:55,780
Do you guys have any last words you'd like to share about the research?

187
00:20:55,780 --> 00: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.

188
00:21:07,320 --> 00:21:09,680
Do you want to give us a preview of what we may see then?

189
00:21:10,300 --> 00:21:13,740
Yeah, so actually, we gave it a preview during our talk.

190
00:21:13,740 --> 00: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.

191
00:21:23,660 --> 00: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.

192
00:21:31,200 --> 00:21:35,340
We hope it will be on the following patch Tuesday.

193
00:21:35,360 --> 00: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.

194
00:21:42,000 --> 00: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.

195
00:21:58,380 --> 00:22:00,120
So wait and see.

196
00:22:00,120 --> 00:22:03,140
We'll mention it on Twitter as well once it will be deployed.

197
00:22:06,920 --> 00:22:12,820
And the last thing I wanted to say if you want to add something, so go ahead.

198
00:22:12,820 --> 00:22:23,580
But I think that it was very interesting research, and we provided all of our technical materials in our GitHub repository.

199
00:22:23,680 --> 00:22:30,740
And if anyone would like to continue research in the same area or something, if you have any questions, go ahead.

200
00:22:30,740 --> 00:22:32,140
You can DM me on Twitter.

201
00:22:32,140 --> 00: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.

202
00:22:47,860 --> 00:22:51,780
It's a huge mechanism, and there are a lot of things to keep on investigating.

203
00:22:51,860 --> 00: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.

204
00:23:00,220 --> 00:23:01,640
Yeah, totally agree.

205
00:23:04,640 --> 00:23:08,740
Okay, well, so I'd really like to thank you guys for the talk you guys did.

206
00:23:08,740 --> 00: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.

207
00:23:22,020 --> 00:23:23,200
So, thank you all.

208
00:23:23,200 --> 00:23:23,620
Thank you very much.

209
00:23:23,620 --> 00:23:24,440
It was a pleasure.

210
00:23:24,820 --> 00:23:27,480
It was fun, and we have started to work on it.

211
00:23:28,120 --> 00:23:29,040
Stay tuned.