1
00:00:01,120 --> 00:00:02,620
Hopefully everything will be working.

2
00:00:03,380 --> 00:00:07,220
Check the audio real quick and start into the questions.

3
00:00:13,630 --> 00:00:14,410
Alright.

4
00:00:14,830 --> 00:00:19,050
Looks like we are on Twitch.

5
00:00:19,050 --> 00:00:22,250
Can you verify that we've got audio available?

6
00:00:22,990 --> 00:00:24,330
Yeah, let me verify that.

7
00:00:24,330 --> 00:00:24,810
Standby.

8
00:00:24,810 --> 00:00:28,270
We're going to click over here and I have to turn myself on.

9
00:00:28,330 --> 00:00:29,130
Yeah, let me verify that.

10
00:00:29,130 --> 00:00:29,970
Yeah, we're in.

11
00:00:29,970 --> 00:00:30,990
Alright, great.

12
00:00:30,990 --> 00:00:43,570
Well, I'd like to welcome everybody to the Q&A on the Hacking Supply Chain presentation by Sholbi Oberman, Moshir Khal, and Ariel Song.

13
00:00:43,810 --> 00:00:47,530
And I hope I came halfway close to getting those names right.

14
00:00:47,670 --> 00:00:56,230
And I have the distinct pleasure of congratulating three brand new DEF CON speakers.

15
00:00:56,230 --> 00:01:01,850
And so we have a position with DEF CON where we share a shot with the new speakers.

16
00:01:01,850 --> 00:01:11,170
And so, although I'd love to be handing you a bottle right now, I'll ask you to take your favorite drink and join me in a quick shot.

17
00:01:12,970 --> 00:01:15,510
Cheers on your talk.

18
00:01:16,310 --> 00:01:17,110
Cheers.

19
00:01:22,970 --> 00:01:25,770
Okay, so that concludes the Q&A session.

20
00:01:27,450 --> 00:01:28,530
It's been good.

21
00:01:28,530 --> 00:01:29,950
Good questions.

22
00:01:30,650 --> 00:01:32,930
Well, yeah, the jokes don't get any better, guys.

23
00:01:32,930 --> 00:01:33,690
I'm sorry.

24
00:01:34,390 --> 00:01:38,650
No, we do actually have some questions already queued up on the chat.

25
00:01:38,650 --> 00:01:45,390
So the first one is, other than the one UPS you guys demoed, what other sort of devices did you successfully exploit?

26
00:01:48,250 --> 00:01:56,110
Yeah, so for the remote code execution, we exploited two different vulnerabilities on two different devices.

27
00:01:56,270 --> 00:02:00,370
They appear in our white papers with full details of the exploits.

28
00:02:00,370 --> 00:02:05,410
One is the UPS, and then the other one is called a DigiConnect module.

29
00:02:05,410 --> 00:02:09,050
It's a system or module for Ethernet connections.

30
00:02:09,090 --> 00:02:12,290
And then there's a few different devices that embed that module.

31
00:02:12,290 --> 00:02:17,650
The exploit would work the same on any device embedding that system or module.

32
00:02:17,670 --> 00:02:19,650
But that's just those two.

33
00:02:19,790 --> 00:02:30,230
And then for information leak and just denial of service and stuff like that, we exploited on quite a few different devices just to make sure they're vulnerable.

34
00:02:32,290 --> 00:02:33,090
Great.

35
00:02:33,090 --> 00:02:34,170
So we have another one.

36
00:02:34,970 --> 00:02:45,670
You have the track identified script that you provided, but we were wondering if there were more active indicators found, and if there will be an update to the track identification script.

37
00:02:50,390 --> 00:02:57,110
So we're staying with the same identification script that we've used to date.

38
00:02:57,110 --> 00:03:04,650
We have seen some false positives, and we're trying to investigate that and see why we get those false positives.

39
00:03:04,650 --> 00:03:07,870
There's something interesting going on.

40
00:03:07,870 --> 00:03:12,930
The reason we're getting false positives, and we're not quite sure what it is, so there might be updates on that front.

41
00:03:13,530 --> 00:03:20,750
And we have released, together with McAfee, we've released IPS-IDS signatures.

42
00:03:20,750 --> 00:03:23,910
So I'm not sure if that's the question or regarding detection.

43
00:03:23,970 --> 00:03:31,350
But for detection, we're using the same scripts, which anyone can just ask for, and we'll send you by mail.

44
00:03:31,350 --> 00:03:41,750
And there's some false positives with those scripts, unfortunately.

45
00:03:44,730 --> 00:03:45,390
Great.

46
00:03:45,390 --> 00:03:54,970
So we have another question about, is there a way to safety-release consumer projects based upon ESP32 or ESP8266?

47
00:03:55,050 --> 00:03:58,710
If no, what hardware development kit would you recommend to start with?

48
00:03:59,770 --> 00:04:01,670
Is that relevant to your talk?

49
00:04:03,430 --> 00:04:05,890
I think it's a slight off topic.

50
00:04:11,360 --> 00:04:12,480
Okay.

51
00:04:14,720 --> 00:04:16,140
Moving on.

52
00:04:16,580 --> 00:04:19,340
So what research methodology was your use?

53
00:04:19,340 --> 00:04:23,000
Did you manually fuzz, review, or something else?

54
00:04:23,000 --> 00:04:28,760
I know from your talk, you talked about static analysis, and I was actually interested in hearing more about how you did that.

55
00:04:30,000 --> 00:04:41,360
Yeah, so we mainly reverse-engineered, and we were starting with a track demo they were offering on their website, and now they removed it.

56
00:04:41,360 --> 00:04:47,220
And then we purchased this DigiConnect device, and we found some headers online.

57
00:04:47,680 --> 00:05:01,160
And we had luck, because this DigiConnect device has symbols, so we can compile custom firmware, and we have debugging capabilities.

58
00:05:01,680 --> 00:05:10,220
So we reversed the firmware, and that's basically how we found most of the vulnerabilities.

59
00:05:10,900 --> 00:05:19,060
And along the way, with the research, we purchased more devices, and found some more variants of the vulnerabilities.

60
00:05:20,440 --> 00:05:22,380
So, yeah.

61
00:05:22,820 --> 00:05:32,940
However, on the UPS device, that's relevant regarding our methodology of exploitation, we saw a slightly different version of Trek.

62
00:05:33,200 --> 00:05:45,280
And we also had... well, we didn't invest much in creating debugging capabilities, so we didn't have a JTAG connector, or a PDB interface, or nothing of that sort.

63
00:05:46,460 --> 00:05:52,400
So we relied mainly on laborious static analysis.

64
00:05:54,460 --> 00:06:04,520
And also some relatively informative crash dumps, small stack traces, stuff like that.

65
00:06:05,880 --> 00:06:06,980
So, yeah.

66
00:06:08,940 --> 00:06:17,860
So researching heap corruptions using static analysis, I think, may be not traditional.

67
00:06:19,560 --> 00:06:22,520
So had you had better tools, would you have used them?

68
00:06:22,520 --> 00:06:26,680
Or do you think you got the results because you went the way you did?

69
00:06:28,100 --> 00:06:36,960
Well, if we had better tools, we would definitely use them, but we didn't see fit to invest in creating these tools.

70
00:06:37,760 --> 00:06:41,500
Just because the exploitation primitive is relatively strong.

71
00:06:41,500 --> 00:06:44,460
It's a controlled overflow of the heap.

72
00:06:44,460 --> 00:06:49,340
And the heap on this device is very simple, rather deterministic.

73
00:06:49,380 --> 00:06:53,680
So we decided to go for the low-hanging fruit first, and paid off.

74
00:06:54,500 --> 00:07:03,360
For the actual vulnerability research, I think the manual static analysis was really the way to go.

75
00:07:03,360 --> 00:07:09,880
Just because there were so many different architectures and different versions, and different types of devices.

76
00:07:09,880 --> 00:07:19,540
So there wasn't one tool that could be used to emulate all of these, or fuzz all of these, or something of that sort.

77
00:07:20,380 --> 00:07:27,100
And there were a lot of special cases of different types, even architectures that weren't supported by IDA, and stuff like that.

78
00:07:27,100 --> 00:07:32,260
So , yeah, I think this was a case for manual analysis.

79
00:07:34,100 --> 00:07:35,480
Well, great.

80
00:07:35,480 --> 00:07:36,660
So we have another question.

81
00:07:36,660 --> 00:07:41,760
Your second whitepaper, is it independent of the first one, or did it build on the first one?

82
00:07:43,280 --> 00:07:44,540
Completely independent.

83
00:07:45,040 --> 00:07:47,840
I mean, they're related because they're the same vulnerable.

84
00:07:47,840 --> 00:07:52,780
They're the same Ripple20, but different vulnerability, different device, different network.

85
00:07:57,780 --> 00:08:01,740
So for the DNS vulnerability, does the shellcode have to be alphanumeric?

86
00:08:01,740 --> 00:08:06,120
If so, is it possible to get an RCE on other architectures?

87
00:08:10,500 --> 00:08:17,100
Well, on the UPS device, as we said earlier, we saw a slightly new version of Trek.

88
00:08:17,100 --> 00:08:19,440
You can also see this in our presentation.

89
00:08:19,740 --> 00:08:25,580
That on some versions, alphanumeric characters and DNS domain names are enforced.

90
00:08:25,960 --> 00:08:29,600
And that's the overflow, you have to use alphanumeric characters.

91
00:08:29,600 --> 00:08:32,720
But on some versions, it is not enforced.

92
00:08:33,340 --> 00:08:36,300
So on the UPS device, it was enforced.

93
00:08:36,480 --> 00:08:40,680
And luckily, the processor was also x86 based.

94
00:08:41,980 --> 00:08:43,960
That's a solved problem.

95
00:08:43,960 --> 00:08:47,320
I mean, alphanumeric shellcode and x86 processor.

96
00:08:47,720 --> 00:08:57,400
So , I mean, it could probably be done in theory in a different way.

97
00:08:57,400 --> 00:09:03,560
For example, you can have a location primitive that allocates non-alphanumeric data with the heap.

98
00:09:03,640 --> 00:09:09,460
Such as just, you know, the DNS packet data, for example, is not alphanumeric, it's in the heap.

99
00:09:09,640 --> 00:09:12,580
So in theory, you could do something different.

100
00:09:13,720 --> 00:09:15,440
But we just chose the easy path.

101
00:09:15,440 --> 00:09:18,500
So yeah, it is exploitable on other architectures as well.

102
00:09:19,540 --> 00:09:20,500
Great.

103
00:09:20,780 --> 00:09:24,640
Yeah, I think it depends on the heap implementation also.

104
00:09:26,220 --> 00:09:39,140
So some strike versions use heap which is not validated and asserted as the UPS heap.

105
00:09:39,240 --> 00:09:47,220
So in these circumstances, it's probably more easy.

106
00:09:49,300 --> 00:09:50,480
Great.

107
00:09:50,480 --> 00:09:52,400
So another question came in.

108
00:09:52,400 --> 00:09:56,940
Are there similar TCPIP stacks that might be interesting to look at?

109
00:10:00,440 --> 00:10:03,920
That's a really interesting question.

110
00:10:05,720 --> 00:10:15,220
So with one of the vulnerabilities, we're not going to say which, but we looked for reference in other TCPIP stacks.

111
00:10:15,220 --> 00:10:24,720
And then we found that about half the TCPIP stacks that we looked at have the same variants of the thread vulnerabilities.

112
00:10:24,720 --> 00:10:28,040
And that's research we're going to be releasing in the future.

113
00:10:30,020 --> 00:10:35,100
So different TCPIP stacks seem to make the same types of mistakes.

114
00:10:35,100 --> 00:10:40,440
So that's a good way to do research into TCPIP stacks.

115
00:10:41,420 --> 00:10:45,820
And then as far as which TCPIP stacks to look at, there's a bunch.

116
00:10:45,820 --> 00:10:47,660
Just open Google.

117
00:10:48,880 --> 00:11:00,080
Depending on if you want proprietary or open source, just type in your search and you'll find that nobody's hiding the available TCPIP stacks.

118
00:11:00,080 --> 00:11:05,440
There's a bunch of proprietary or open source stacks out there.

119
00:11:05,440 --> 00:11:16,740
There seems to be a follow-up question that expands out a bit beyond just the TCPIP stack, since that was just an example of a library at the root of a huge supply chain.

120
00:11:16,740 --> 00:11:24,480
And did you see other libraries or other stacks that you would consider evaluating next?

121
00:11:25,620 --> 00:11:27,100
Yeah, we did.

122
00:11:27,460 --> 00:11:34,880
But we're still deciding what to evaluate next, so we're keeping those to ourselves at this point.

123
00:11:34,880 --> 00:11:38,760
Did you see other super interesting stacks with a really long supply chain?

124
00:11:40,440 --> 00:11:44,660
I mean, that's how IoT is built, just like Lego blocks, right?

125
00:11:44,660 --> 00:11:50,800
So just take any device, break it apart, when you get to the smallest piece, that's your research target.

126
00:11:53,600 --> 00:11:54,240
Fantastic.

127
00:11:54,240 --> 00:11:56,200
So another question came in.

128
00:11:56,200 --> 00:12:01,180
How do you explain how you got to, quote, hundreds of millions of affected devices, unquote?

129
00:12:05,460 --> 00:12:11,600
So there's quite a lot of devices of different types, and we sort of tried to sum them up.

130
00:12:11,600 --> 00:12:17,880
The majority of the numbers actually come from Intel devices and HP devices.

131
00:12:17,960 --> 00:12:23,060
And then Digi also adds quite a big number of devices.

132
00:12:23,720 --> 00:12:31,120
But we just sort of tried to assess, given open information, how many of each of these types of devices is sold per year.

133
00:12:32,000 --> 00:12:34,080
To reach hundreds of millions.

134
00:12:34,600 --> 00:12:40,160
If you sort of count all the devices that contain the code, you'd probably reach billions.

135
00:12:40,160 --> 00:12:48,060
If you count all the actually affected and turned it on, it will be between tens of millions and hundreds of millions.

136
00:12:48,820 --> 00:12:51,140
So it sort of depends how you count.

137
00:12:51,280 --> 00:12:56,480
But yeah, most of them are printers and Intel AMT.

138
00:12:57,760 --> 00:12:58,800
Great.

139
00:13:00,720 --> 00:13:11,520
So one question I had was, when I look at your website, the company in your presentation, it looks like there's quite a big team that was involved in pulling this together.

140
00:13:12,240 --> 00:13:21,620
I mean, it sounds like the core of you all were at JSOF, but how did you rope in the collaborators that you used on this?

141
00:13:23,760 --> 00:13:37,020
So the vast majority of the work was done at JSOF, with Moshe doing most of the work from the beginning, finding the vulnerabilities, etc.

142
00:13:37,060 --> 00:13:41,600
And Ariel doing the exploitation work.

143
00:13:41,860 --> 00:13:50,680
And then for very brief periods, we used some outside help just when we were under timeline or something like that.

144
00:13:51,640 --> 00:13:57,500
Most of the people that you see there, most of the names actually work for JSOF.

145
00:13:59,120 --> 00:14:01,440
You'll see a few names that don't work for JSOF.

146
00:14:01,440 --> 00:14:08,480
One is the kid of one of the employees who we just mentioned because his mother was away.

147
00:14:08,800 --> 00:14:12,180
And then somebody else that helped along the way.

148
00:14:12,180 --> 00:14:15,540
But most of the work, 99% of the work was done in-house.

149
00:14:15,800 --> 00:14:16,720
Very cool.

150
00:14:17,360 --> 00:14:18,960
I have a really bad question.

151
00:14:18,960 --> 00:14:20,000
Are you ready for it?

152
00:14:20,000 --> 00:14:21,840
How'd you pick Liani?

153
00:14:23,760 --> 00:14:31,600
I mean, you talked about in your presentation why you gave the 20, but why Ripple?

154
00:14:34,220 --> 00:14:38,940
Okay, so we'll give you the real answer about why 20 that nobody knows.

155
00:14:38,940 --> 00:14:48,460
And the real reason why 20 is because if we called it Ripple 19, then people would associate it with the current affair, current situation.

156
00:14:48,460 --> 00:14:50,220
So that's why we went for 20.

157
00:14:50,220 --> 00:14:56,760
I mean, there's other reasons, but that's the behind the scenes just between you and me and all our viewers.

158
00:14:57,340 --> 00:14:59,800
The Ripple is because of the Ripple effect, right?

159
00:14:59,800 --> 00:15:05,120
This one vulnerability that sort of expands and the impact expands and expands and expands.

160
00:15:05,120 --> 00:15:08,900
It's how we experienced it.

161
00:15:08,900 --> 00:15:23,120
But it's also how over the years Threadstack sort of went from device to device and got wider and wider effect and wider and wider impact and embedded in more and more devices.

162
00:15:23,360 --> 00:15:29,940
So we felt like that really captures the supply chain Ripple effect.

163
00:15:30,340 --> 00:15:31,400
That's cool.

164
00:15:31,400 --> 00:15:32,960
I like what you're going with on that.

165
00:15:32,960 --> 00:15:35,380
So how big this one got?

166
00:15:35,380 --> 00:15:37,300
Obviously, this got a lot of attention.

167
00:15:37,300 --> 00:15:39,100
There were a lot of people talking about this.

168
00:15:39,100 --> 00:15:44,840
How has the added attention to your work changed the way that you do your work?

169
00:15:44,840 --> 00:15:46,380
Has it changed your daily life?

170
00:15:46,380 --> 00:15:50,880
Have you found more people are asking you questions about more stuff?

171
00:15:53,840 --> 00:15:56,400
So it's been quite busy.

172
00:15:57,400 --> 00:16:03,120
We've seen all kinds of responses, all kinds of questions, all kinds of reach out.

173
00:16:05,120 --> 00:16:16,860
Mostly to date, most of the stuff has been sort of reactionary network operators, you know, want to figure out what to do about Ripple 20.

174
00:16:17,200 --> 00:16:26,260
And then, of course, some researchers interested in the work, reaching out, asking questions, companies wanting to collaborate on helping mitigate and fix these issues.

175
00:16:27,820 --> 00:16:34,000
We're hoping for sort of more long term, more companies thinking about the next, we're calling it Ripple 21.

176
00:16:34,000 --> 00:16:35,780
Like, how do you prevent the next time?

177
00:16:35,780 --> 00:16:39,680
How do vendors use security hygiene, exploit mitigations?

178
00:16:39,680 --> 00:16:42,400
You know, how they look into their supply chain?

179
00:16:42,400 --> 00:16:45,940
Because I think that's like, this is not the last time this is happening, right?

180
00:16:45,940 --> 00:16:48,240
Somebody asked about good research targets.

181
00:16:48,240 --> 00:16:52,680
So there's already people in the audience looking for the next supply chain vulnerability.

182
00:16:53,720 --> 00:16:57,320
And, you know, I think by this time next year, we'll have another one for sure.

183
00:16:57,920 --> 00:17:01,460
Probably not us going to be publishing it, but somebody will.

184
00:17:01,620 --> 00:17:09,160
So I think that's the interesting talk about how do we go forward from Ripple 20.

185
00:17:11,740 --> 00:17:12,280
Great.

186
00:17:12,280 --> 00:17:13,680
So we have a question.

187
00:17:13,680 --> 00:17:23,680
How do you evaluate the patchability of such high level supply chain vulnerabilities down the line, especially with regard to less frequently updated IoT?

188
00:17:27,990 --> 00:17:37,710
So we sort of know, it's called common knowledge or something that we say that some devices are unpatchable and some of the companies we know ceased operations.

189
00:17:37,990 --> 00:17:41,470
Some of the companies are still investigating whether they are vulnerable.

190
00:17:43,050 --> 00:17:44,850
So it's going to be difficult.

191
00:17:44,850 --> 00:17:48,410
Many of the devices are not going to be patched for years just for those reasons.

192
00:17:48,410 --> 00:17:50,630
Some of them it's difficult to patch.

193
00:17:50,630 --> 00:17:59,470
We have seen companies reach out and saying, we can't patch these devices for a while because they're too critical.

194
00:18:00,570 --> 00:18:05,390
And they serve a lot of customers and we can't afford any downtime.

195
00:18:05,390 --> 00:18:11,750
And they're sort of trying all kinds of virtual patching, network level mitigations.

196
00:18:12,910 --> 00:18:14,670
I'm not sure how effective that is.

197
00:18:14,670 --> 00:18:16,290
I guess it could be effective if done right.

198
00:18:16,290 --> 00:18:22,590
But we definitely assume many of the devices are not going to be patched for years.

199
00:18:22,590 --> 00:18:25,830
That's my personal assumption.

200
00:18:27,750 --> 00:18:34,910
So I guess a follow-up question to that would be, if you're a developer of IoT, what's the lesson to take from this?

201
00:18:38,400 --> 00:18:39,760
Hey, Gabe.

202
00:18:41,800 --> 00:18:47,380
So I think one lesson is look into your supply chain and understand their security.

203
00:18:47,940 --> 00:18:50,000
Ask them the right questions.

204
00:18:50,100 --> 00:18:56,300
And another question is prepare for vulnerabilities using good exploit mitigations and security hygiene.

205
00:18:56,620 --> 00:19:03,800
So some of the vendors affected were actually able to release a statement saying, yes, we're affected, but it's not that bad.

206
00:19:03,800 --> 00:19:14,300
Like Greenhills and Intel to some extent with some of their devices, because they use different types of exploit mitigations and security hygiene.

207
00:19:14,300 --> 00:19:20,000
And then even though they didn't know about the Ripple 20 vulnerabilities, the impact was lesser.

208
00:19:20,960 --> 00:19:46,060
And then even with the Schneider UPS devices, which of course have been patched since, the heap was a stronger version of the heap than we've seen in other devices, and therefore was slightly more difficult to exploit than, say, the DigiConnect device that used an older allocator,

209
00:19:46,060 --> 00:19:47,960
which was less safe.

210
00:19:47,960 --> 00:19:53,560
So third-party risk supply chain and exploit mitigations are the top two.

211
00:19:56,300 --> 00:19:57,080
Great, thank you.

212
00:19:57,080 --> 00:20:01,120
So another question from the audience, more of a general research question.

213
00:20:01,180 --> 00:20:04,000
When starting a project like this, how does the timeline work?

214
00:20:04,160 --> 00:20:12,480
You say, like, let's give it a month and then you give up, or you allocate three people until they figure out something, or is it some other approach?

215
00:20:15,980 --> 00:20:22,640
So it's always difficult with research, but we've been doing this for a while.

216
00:20:22,640 --> 00:20:28,560
Our timeline worked more or less like this.

217
00:20:28,560 --> 00:20:36,340
We took the DEFCON and also Black Hat call for papers finish date.

218
00:20:37,080 --> 00:20:40,280
We took as much time as we thought we might need back.

219
00:20:40,280 --> 00:20:54,960
And then we also scheduled time for the disclosure process, the coordination process, etc.

220
00:20:54,960 --> 00:20:57,660
And that's when we started the specific research.

221
00:20:58,300 --> 00:21:02,520
And then towards the end, towards the disclosure date, we were scrambling with the exploit.

222
00:21:02,520 --> 00:21:07,120
And we actually pulled the exploit together in about three weeks from start to finish.

223
00:21:09,100 --> 00:21:14,900
But we sort of just dedicated a specific amount of time to hit DEFCON and Black Hat.

224
00:21:15,740 --> 00:21:19,900
Oftentimes, it's very, very hard to schedule this type of research.

225
00:21:19,900 --> 00:21:22,440
You never know what you're going to find, how long it's going to take.

226
00:21:25,480 --> 00:21:26,040
Great.

227
00:21:26,040 --> 00:21:31,520
So I guess a follow-up question would be, I mean, did you feel confident you were going to find something when you started?

228
00:21:31,520 --> 00:21:34,620
Or was this mostly a hunting trip?

229
00:21:37,540 --> 00:21:38,960
There's always something.

230
00:21:39,080 --> 00:21:44,140
I don't think we've ever encountered a target where we haven't found anything.

231
00:21:47,640 --> 00:21:49,740
So, yeah, there's always something.

232
00:21:53,140 --> 00:21:53,980
Great.

233
00:21:56,400 --> 00:22:09,920
So I think you answered this a minute ago, but one of the questions that came up out of band was, did the UPSs devices that you demonstrated, did those have patches available?

234
00:22:10,220 --> 00:22:12,220
Did I hear you say yes now?

235
00:22:13,780 --> 00:22:16,000
They do have patches available.

236
00:22:16,000 --> 00:22:25,600
Of course, you have to patch your device using the patches, but they are available.

237
00:22:25,720 --> 00:22:27,120
You have to install them.

238
00:22:30,580 --> 00:22:31,140
Great.

239
00:22:31,140 --> 00:22:38,180
So we've reached that point where my abilities to do radio completely fail me because I've run out of questions.

240
00:22:38,940 --> 00:22:47,120
So folks, please keep the questions coming in the last eight minutes we've got here.

241
00:22:47,120 --> 00:22:58,060
I will offer you guys a chance to elaborate on anything that you wanted to add to your talks or any additional points you wanted to make while we're looking for more questions.

242
00:22:58,060 --> 00:23:02,620
So there was an additional question we started with.

243
00:23:02,820 --> 00:23:08,280
You had several things you talked about at the very beginning of your presentation.

244
00:23:08,880 --> 00:23:14,980
These are a number of vulnerabilities, yet you showed just one.

245
00:23:14,980 --> 00:23:24,100
Would you talk a little more maybe about why just the one and any other things we can look forward to seeing in the future?

246
00:23:24,100 --> 00:23:29,020
I know you talked about it a little bit, but there are some other questions about what are the work you're doing?

247
00:23:33,240 --> 00:23:43,080
We chose this vulnerability because we think it's sort of the most interesting vulnerability, and we had a cool exploit on a demo to show that it's real.

248
00:23:44,060 --> 00:23:48,060
We think it's cool because it will bypass NAT, right?

249
00:23:48,060 --> 00:23:53,760
The DNS request will exit your corporate network potentially, depends how it's configured.

250
00:23:54,700 --> 00:24:07,500
I think we're mostly done with Drupal 20 because we're looking forward to our next research project in the research lab.

251
00:24:07,940 --> 00:24:14,000
There are some offshoots, some other stuff that we found out that we're still working on and we're going to be releasing shortly.

252
00:24:14,280 --> 00:24:18,180
We do have some new research that we're going to be releasing in a few months.

253
00:24:18,180 --> 00:24:22,720
And then, of course, we do a lot of work for our customers.

254
00:24:22,720 --> 00:24:25,560
Most of our work is just for customers.

255
00:24:25,760 --> 00:24:28,580
We do penetration testing and research and stuff like that.

256
00:24:29,260 --> 00:24:36,760
From the research lab's side, a little bit more about Drupal 20, some new stuff we found out.

257
00:24:37,560 --> 00:24:45,200
Something that we sort of released only on Twitter, but we never called it documented on a white paper.

258
00:24:46,100 --> 00:25:10,100
And the listeners might find interesting is that the track stack actually supports encapsulation of IP and IP, and it will forward packets to itself if the destination address is the right one, which is really cool because that can help you bypass firewalls and other network equipment that might stop exploitation.

259
00:25:10,100 --> 00:25:19,300
And we found that out when we wanted to test the exploit routes over the internet, not this exploit, but the one for the DigiConnect.

260
00:25:20,960 --> 00:25:29,620
And just our company firewall was blocking it, so we encapsulated the packets and they bypassed the firewall.

261
00:25:29,620 --> 00:25:40,440
So that's something new, but mostly we're working towards our next research, and I think in a couple of months we should be able to release that.

262
00:25:40,580 --> 00:25:45,320
It's currently under disclosure, a coordinated disclosure process.

263
00:25:46,200 --> 00:25:47,400
Great.

264
00:25:47,420 --> 00:25:53,420
Yeah, unfortunately your future research becomes DEF CON talks, you won't get to drink at those.

265
00:25:55,280 --> 00:25:56,720
That's only the first time.

266
00:25:57,440 --> 00:26:05,540
We did have one more question come in and said, is JSOF going to create any tools like Nmap, NSF, etc.

267
00:26:05,540 --> 00:26:08,780
to help bind the devices that may have these issues?

268
00:26:11,380 --> 00:26:15,040
So we already have detection scripts.

269
00:26:15,680 --> 00:26:22,180
You can send us an email, the address is on our website, and you can get the detection scripts.

270
00:26:22,180 --> 00:26:31,000
And also, correct me if I'm wrong, but we have the filters for... what's it called?

271
00:26:33,840 --> 00:26:41,100
So we have... there's passive detection scripts for the exploits themselves.

272
00:26:41,100 --> 00:26:46,960
We have some passive information about how to detect the track stack and some active detection scripts.

273
00:26:46,960 --> 00:26:52,660
You can email them to us, we also plan to release them open source, we just haven't gotten around to it yet.

274
00:26:53,440 --> 00:27:01,400
They are also available, I think Tenable released them as a package and Zeek released them as a package.

275
00:27:02,160 --> 00:27:06,260
Probably a few others have released them as a package, but those are the ones we know about.

276
00:27:06,260 --> 00:27:09,820
And yeah, until we release them open source, you can just email us.

277
00:27:10,780 --> 00:27:16,460
Anyone whose legitimate request, we'll just send you the scripts.

278
00:27:18,400 --> 00:27:22,280
Take us a couple hours and you'll get the scripts in your email.

279
00:27:22,880 --> 00:27:27,460
Great, and if I remember correctly, your contact information is in the beginning of your talk, correct?

280
00:27:29,460 --> 00:27:30,720
I hope so.

281
00:27:30,720 --> 00:27:39,700
If not, it's just ripple20 at jsof-tech.jsof-tech.com.

282
00:27:42,320 --> 00:27:45,820
Hopefully someone was typing faster than I did when you said that.

283
00:27:45,980 --> 00:27:48,340
So we do have one last question.

284
00:27:48,560 --> 00:27:56,160
What specific recommendations would you have for third-party library vendors that could minimize the possibility of vulnerabilities like this?

285
00:27:58,180 --> 00:28:02,120
So code review would be a big one.

286
00:28:02,200 --> 00:28:06,500
Exploit mitigations would be another one.

287
00:28:06,500 --> 00:28:27,920
But for third-party library suppliers like Crack that are relied on by a pretty big amount of IoT and critical devices, I'd say penetration testing and a really good security review and secure code review, as well as just securing the design is absolutely necessary.

288
00:28:27,920 --> 00:28:33,060
Because doing this once for Crack, it's just like we found one vulnerability and it affects everyone.

289
00:28:33,540 --> 00:28:36,380
Like one secure code review would protect everyone.

290
00:28:36,380 --> 00:28:51,580
So the deeper you are in the supply chain, or well I guess deeper depends on where you're coming from, but the further at the beginning of the supply chain you are, the more you should be investing in your security.

291
00:28:51,580 --> 00:29:00,580
And the more your clients should be asking you about your security and probably will be going forward.

292
00:29:01,720 --> 00:29:12,420
Yeah, I think one of the lessons from your talk was to recognize the fact that these things do have, like you said, that ripple effect.

293
00:29:12,420 --> 00:29:23,940
And if you're a maker of libraries, be careful of where your code may end up at if it has those vulnerabilities in it.

294
00:29:23,960 --> 00:29:37,660
I don't think anybody building TCP IP stacks were imagining that they could be protecting incubation technologies or other medical systems that keep people alive.

295
00:29:39,640 --> 00:29:45,740
So I think a lot of these device manufacturers, they do realize where they end up.

296
00:29:45,740 --> 00:29:50,580
The thing is they started writing the code 20 years ago when nobody was thinking about security.

297
00:29:50,740 --> 00:29:54,700
And then the code probably worked really well and just nobody wanted to touch it.

298
00:29:54,700 --> 00:30:05,780
And somewhere along the line, all these companies sort of forgot that they probably revamped their own security processes and activities.

299
00:30:05,780 --> 00:30:11,120
But maybe they figured if there's something in a third party, it's like a third party problem.

300
00:30:11,120 --> 00:30:14,740
Or maybe they didn't realize they've been using this library for 20 years.

301
00:30:14,920 --> 00:30:20,060
So I don't think that it's that Treck didn't know where the code ends up.

302
00:30:20,060 --> 00:30:23,320
It's just 20 years ago, nobody was talking about security.

303
00:30:23,320 --> 00:30:24,560
And that's when the code was written.

304
00:30:24,560 --> 00:30:26,320
A lot of this code is really old.

305
00:30:26,320 --> 00:30:27,020
Not just Treck.

306
00:30:27,360 --> 00:30:28,760
All IoT code.

307
00:30:28,760 --> 00:30:32,820
A lot of the code is not very fresh code.

308
00:30:34,680 --> 00:30:35,620
Well, great, guys.

309
00:30:35,620 --> 00:30:37,360
So we're at the top of the hour.

310
00:30:37,400 --> 00:30:39,160
I want to be respectful of your time.

311
00:30:39,200 --> 00:30:41,800
I really appreciate you guys taking the time to take these Q&A's.

312
00:30:41,800 --> 00:30:45,680
And I appreciate all the questions that have come in on the Discord chat.

313
00:30:45,860 --> 00:30:48,320
Any last words before we call this, folks?

314
00:30:51,860 --> 00:30:52,500
All right, guys.

315
00:30:53,860 --> 00:30:57,080
We really look forward to more good work from you guys.

316
00:30:57,760 --> 00:30:58,320
All right.

317
00:30:58,320 --> 00:30:58,920
Have a good one.

318
00:30:58,920 --> 00:30:59,680
Thank you.

319
00:31:00,520 --> 00:31:01,000
Bye.