WEBVTT 00:01.120 --> 00:02.620 Hopefully everything will be working. 00:03.380 --> 00:07.220 Check the audio real quick and start into the questions. 00:13.630 --> 00:14.410 Alright. 00:14.830 --> 00:19.050 Looks like we are on Twitch. 00:19.050 --> 00:22.250 Can you verify that we've got audio available? 00:22.990 --> 00:24.330 Yeah, let me verify that. 00:24.330 --> 00:24.810 Standby. 00:24.810 --> 00:28.270 We're going to click over here and I have to turn myself on. 00:28.330 --> 00:29.130 Yeah, let me verify that. 00:29.130 --> 00:29.970 Yeah, we're in. 00:29.970 --> 00:30.990 Alright, great. 00:30.990 --> 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. 00:43.810 --> 00:47.530 And I hope I came halfway close to getting those names right. 00:47.670 --> 00:56.230 And I have the distinct pleasure of congratulating three brand new DEF CON speakers. 00:56.230 --> 01:01.850 And so we have a position with DEF CON where we share a shot with the new speakers. 01:01.850 --> 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. 01:12.970 --> 01:15.510 Cheers on your talk. 01:16.310 --> 01:17.110 Cheers. 01:22.970 --> 01:25.770 Okay, so that concludes the Q&A session. 01:27.450 --> 01:28.530 It's been good. 01:28.530 --> 01:29.950 Good questions. 01:30.650 --> 01:32.930 Well, yeah, the jokes don't get any better, guys. 01:32.930 --> 01:33.690 I'm sorry. 01:34.390 --> 01:38.650 No, we do actually have some questions already queued up on the chat. 01:38.650 --> 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? 01:48.250 --> 01:56.110 Yeah, so for the remote code execution, we exploited two different vulnerabilities on two different devices. 01:56.270 --> 02:00.370 They appear in our white papers with full details of the exploits. 02:00.370 --> 02:05.410 One is the UPS, and then the other one is called a DigiConnect module. 02:05.410 --> 02:09.050 It's a system or module for Ethernet connections. 02:09.090 --> 02:12.290 And then there's a few different devices that embed that module. 02:12.290 --> 02:17.650 The exploit would work the same on any device embedding that system or module. 02:17.670 --> 02:19.650 But that's just those two. 02:19.790 --> 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. 02:32.290 --> 02:33.090 Great. 02:33.090 --> 02:34.170 So we have another one. 02:34.970 --> 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. 02:50.390 --> 02:57.110 So we're staying with the same identification script that we've used to date. 02:57.110 --> 03:04.650 We have seen some false positives, and we're trying to investigate that and see why we get those false positives. 03:04.650 --> 03:07.870 There's something interesting going on. 03:07.870 --> 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. 03:13.530 --> 03:20.750 And we have released, together with McAfee, we've released IPS-IDS signatures. 03:20.750 --> 03:23.910 So I'm not sure if that's the question or regarding detection. 03:23.970 --> 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. 03:31.350 --> 03:41.750 And there's some false positives with those scripts, unfortunately. 03:44.730 --> 03:45.390 Great. 03:45.390 --> 03:54.970 So we have another question about, is there a way to safety-release consumer projects based upon ESP32 or ESP8266? 03:55.050 --> 03:58.710 If no, what hardware development kit would you recommend to start with? 03:59.770 --> 04:01.670 Is that relevant to your talk? 04:03.430 --> 04:05.890 I think it's a slight off topic. 04:11.360 --> 04:12.480 Okay. 04:14.720 --> 04:16.140 Moving on. 04:16.580 --> 04:19.340 So what research methodology was your use? 04:19.340 --> 04:23.000 Did you manually fuzz, review, or something else? 04:23.000 --> 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. 04:30.000 --> 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. 04:41.360 --> 04:47.220 And then we purchased this DigiConnect device, and we found some headers online. 04:47.680 --> 05:01.160 And we had luck, because this DigiConnect device has symbols, so we can compile custom firmware, and we have debugging capabilities. 05:01.680 --> 05:10.220 So we reversed the firmware, and that's basically how we found most of the vulnerabilities. 05:10.900 --> 05:19.060 And along the way, with the research, we purchased more devices, and found some more variants of the vulnerabilities. 05:20.440 --> 05:22.380 So, yeah. 05:22.820 --> 05:32.940 However, on the UPS device, that's relevant regarding our methodology of exploitation, we saw a slightly different version of Trek. 05:33.200 --> 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. 05:46.460 --> 05:52.400 So we relied mainly on laborious static analysis. 05:54.460 --> 06:04.520 And also some relatively informative crash dumps, small stack traces, stuff like that. 06:05.880 --> 06:06.980 So, yeah. 06:08.940 --> 06:17.860 So researching heap corruptions using static analysis, I think, may be not traditional. 06:19.560 --> 06:22.520 So had you had better tools, would you have used them? 06:22.520 --> 06:26.680 Or do you think you got the results because you went the way you did? 06:28.100 --> 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. 06:37.760 --> 06:41.500 Just because the exploitation primitive is relatively strong. 06:41.500 --> 06:44.460 It's a controlled overflow of the heap. 06:44.460 --> 06:49.340 And the heap on this device is very simple, rather deterministic. 06:49.380 --> 06:53.680 So we decided to go for the low-hanging fruit first, and paid off. 06:54.500 --> 07:03.360 For the actual vulnerability research, I think the manual static analysis was really the way to go. 07:03.360 --> 07:09.880 Just because there were so many different architectures and different versions, and different types of devices. 07:09.880 --> 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. 07:20.380 --> 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. 07:27.100 --> 07:32.260 So , yeah, I think this was a case for manual analysis. 07:34.100 --> 07:35.480 Well, great. 07:35.480 --> 07:36.660 So we have another question. 07:36.660 --> 07:41.760 Your second whitepaper, is it independent of the first one, or did it build on the first one? 07:43.280 --> 07:44.540 Completely independent. 07:45.040 --> 07:47.840 I mean, they're related because they're the same vulnerable. 07:47.840 --> 07:52.780 They're the same Ripple20, but different vulnerability, different device, different network. 07:57.780 --> 08:01.740 So for the DNS vulnerability, does the shellcode have to be alphanumeric? 08:01.740 --> 08:06.120 If so, is it possible to get an RCE on other architectures? 08:10.500 --> 08:17.100 Well, on the UPS device, as we said earlier, we saw a slightly new version of Trek. 08:17.100 --> 08:19.440 You can also see this in our presentation. 08:19.740 --> 08:25.580 That on some versions, alphanumeric characters and DNS domain names are enforced. 08:25.960 --> 08:29.600 And that's the overflow, you have to use alphanumeric characters. 08:29.600 --> 08:32.720 But on some versions, it is not enforced. 08:33.340 --> 08:36.300 So on the UPS device, it was enforced. 08:36.480 --> 08:40.680 And luckily, the processor was also x86 based. 08:41.980 --> 08:43.960 That's a solved problem. 08:43.960 --> 08:47.320 I mean, alphanumeric shellcode and x86 processor. 08:47.720 --> 08:57.400 So , I mean, it could probably be done in theory in a different way. 08:57.400 --> 09:03.560 For example, you can have a location primitive that allocates non-alphanumeric data with the heap. 09:03.640 --> 09:09.460 Such as just, you know, the DNS packet data, for example, is not alphanumeric, it's in the heap. 09:09.640 --> 09:12.580 So in theory, you could do something different. 09:13.720 --> 09:15.440 But we just chose the easy path. 09:15.440 --> 09:18.500 So yeah, it is exploitable on other architectures as well. 09:19.540 --> 09:20.500 Great. 09:20.780 --> 09:24.640 Yeah, I think it depends on the heap implementation also. 09:26.220 --> 09:39.140 So some strike versions use heap which is not validated and asserted as the UPS heap. 09:39.240 --> 09:47.220 So in these circumstances, it's probably more easy. 09:49.300 --> 09:50.480 Great. 09:50.480 --> 09:52.400 So another question came in. 09:52.400 --> 09:56.940 Are there similar TCPIP stacks that might be interesting to look at? 10:00.440 --> 10:03.920 That's a really interesting question. 10:05.720 --> 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. 10:15.220 --> 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. 10:24.720 --> 10:28.040 And that's research we're going to be releasing in the future. 10:30.020 --> 10:35.100 So different TCPIP stacks seem to make the same types of mistakes. 10:35.100 --> 10:40.440 So that's a good way to do research into TCPIP stacks. 10:41.420 --> 10:45.820 And then as far as which TCPIP stacks to look at, there's a bunch. 10:45.820 --> 10:47.660 Just open Google. 10:48.880 --> 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. 11:00.080 --> 11:05.440 There's a bunch of proprietary or open source stacks out there. 11:05.440 --> 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. 11:16.740 --> 11:24.480 And did you see other libraries or other stacks that you would consider evaluating next? 11:25.620 --> 11:27.100 Yeah, we did. 11:27.460 --> 11:34.880 But we're still deciding what to evaluate next, so we're keeping those to ourselves at this point. 11:34.880 --> 11:38.760 Did you see other super interesting stacks with a really long supply chain? 11:40.440 --> 11:44.660 I mean, that's how IoT is built, just like Lego blocks, right? 11:44.660 --> 11:50.800 So just take any device, break it apart, when you get to the smallest piece, that's your research target. 11:53.600 --> 11:54.240 Fantastic. 11:54.240 --> 11:56.200 So another question came in. 11:56.200 --> 12:01.180 How do you explain how you got to, quote, hundreds of millions of affected devices, unquote? 12:05.460 --> 12:11.600 So there's quite a lot of devices of different types, and we sort of tried to sum them up. 12:11.600 --> 12:17.880 The majority of the numbers actually come from Intel devices and HP devices. 12:17.960 --> 12:23.060 And then Digi also adds quite a big number of devices. 12:23.720 --> 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. 12:32.000 --> 12:34.080 To reach hundreds of millions. 12:34.600 --> 12:40.160 If you sort of count all the devices that contain the code, you'd probably reach billions. 12:40.160 --> 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. 12:48.820 --> 12:51.140 So it sort of depends how you count. 12:51.280 --> 12:56.480 But yeah, most of them are printers and Intel AMT. 12:57.760 --> 12:58.800 Great. 13:00.720 --> 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. 13:12.240 --> 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? 13:23.760 --> 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. 13:37.060 --> 13:41.600 And Ariel doing the exploitation work. 13:41.860 --> 13:50.680 And then for very brief periods, we used some outside help just when we were under timeline or something like that. 13:51.640 --> 13:57.500 Most of the people that you see there, most of the names actually work for JSOF. 13:59.120 --> 14:01.440 You'll see a few names that don't work for JSOF. 14:01.440 --> 14:08.480 One is the kid of one of the employees who we just mentioned because his mother was away. 14:08.800 --> 14:12.180 And then somebody else that helped along the way. 14:12.180 --> 14:15.540 But most of the work, 99% of the work was done in-house. 14:15.800 --> 14:16.720 Very cool. 14:17.360 --> 14:18.960 I have a really bad question. 14:18.960 --> 14:20.000 Are you ready for it? 14:20.000 --> 14:21.840 How'd you pick Liani? 14:23.760 --> 14:31.600 I mean, you talked about in your presentation why you gave the 20, but why Ripple? 14:34.220 --> 14:38.940 Okay, so we'll give you the real answer about why 20 that nobody knows. 14:38.940 --> 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. 14:48.460 --> 14:50.220 So that's why we went for 20. 14:50.220 --> 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. 14:57.340 --> 14:59.800 The Ripple is because of the Ripple effect, right? 14:59.800 --> 15:05.120 This one vulnerability that sort of expands and the impact expands and expands and expands. 15:05.120 --> 15:08.900 It's how we experienced it. 15:08.900 --> 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. 15:23.360 --> 15:29.940 So we felt like that really captures the supply chain Ripple effect. 15:30.340 --> 15:31.400 That's cool. 15:31.400 --> 15:32.960 I like what you're going with on that. 15:32.960 --> 15:35.380 So how big this one got? 15:35.380 --> 15:37.300 Obviously, this got a lot of attention. 15:37.300 --> 15:39.100 There were a lot of people talking about this. 15:39.100 --> 15:44.840 How has the added attention to your work changed the way that you do your work? 15:44.840 --> 15:46.380 Has it changed your daily life? 15:46.380 --> 15:50.880 Have you found more people are asking you questions about more stuff? 15:53.840 --> 15:56.400 So it's been quite busy. 15:57.400 --> 16:03.120 We've seen all kinds of responses, all kinds of questions, all kinds of reach out. 16:05.120 --> 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. 16:17.200 --> 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. 16:27.820 --> 16:34.000 We're hoping for sort of more long term, more companies thinking about the next, we're calling it Ripple 21. 16:34.000 --> 16:35.780 Like, how do you prevent the next time? 16:35.780 --> 16:39.680 How do vendors use security hygiene, exploit mitigations? 16:39.680 --> 16:42.400 You know, how they look into their supply chain? 16:42.400 --> 16:45.940 Because I think that's like, this is not the last time this is happening, right? 16:45.940 --> 16:48.240 Somebody asked about good research targets. 16:48.240 --> 16:52.680 So there's already people in the audience looking for the next supply chain vulnerability. 16:53.720 --> 16:57.320 And, you know, I think by this time next year, we'll have another one for sure. 16:57.920 --> 17:01.460 Probably not us going to be publishing it, but somebody will. 17:01.620 --> 17:09.160 So I think that's the interesting talk about how do we go forward from Ripple 20. 17:11.740 --> 17:12.280 Great. 17:12.280 --> 17:13.680 So we have a question. 17:13.680 --> 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? 17:27.990 --> 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. 17:37.990 --> 17:41.470 Some of the companies are still investigating whether they are vulnerable. 17:43.050 --> 17:44.850 So it's going to be difficult. 17:44.850 --> 17:48.410 Many of the devices are not going to be patched for years just for those reasons. 17:48.410 --> 17:50.630 Some of them it's difficult to patch. 17:50.630 --> 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. 18:00.570 --> 18:05.390 And they serve a lot of customers and we can't afford any downtime. 18:05.390 --> 18:11.750 And they're sort of trying all kinds of virtual patching, network level mitigations. 18:12.910 --> 18:14.670 I'm not sure how effective that is. 18:14.670 --> 18:16.290 I guess it could be effective if done right. 18:16.290 --> 18:22.590 But we definitely assume many of the devices are not going to be patched for years. 18:22.590 --> 18:25.830 That's my personal assumption. 18:27.750 --> 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? 18:38.400 --> 18:39.760 Hey, Gabe. 18:41.800 --> 18:47.380 So I think one lesson is look into your supply chain and understand their security. 18:47.940 --> 18:50.000 Ask them the right questions. 18:50.100 --> 18:56.300 And another question is prepare for vulnerabilities using good exploit mitigations and security hygiene. 18:56.620 --> 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. 19:03.800 --> 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. 19:14.300 --> 19:20.000 And then even though they didn't know about the Ripple 20 vulnerabilities, the impact was lesser. 19:20.960 --> 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, 19:46.060 --> 19:47.960 which was less safe. 19:47.960 --> 19:53.560 So third-party risk supply chain and exploit mitigations are the top two. 19:56.300 --> 19:57.080 Great, thank you. 19:57.080 --> 20:01.120 So another question from the audience, more of a general research question. 20:01.180 --> 20:04.000 When starting a project like this, how does the timeline work? 20:04.160 --> 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? 20:15.980 --> 20:22.640 So it's always difficult with research, but we've been doing this for a while. 20:22.640 --> 20:28.560 Our timeline worked more or less like this. 20:28.560 --> 20:36.340 We took the DEFCON and also Black Hat call for papers finish date. 20:37.080 --> 20:40.280 We took as much time as we thought we might need back. 20:40.280 --> 20:54.960 And then we also scheduled time for the disclosure process, the coordination process, etc. 20:54.960 --> 20:57.660 And that's when we started the specific research. 20:58.300 --> 21:02.520 And then towards the end, towards the disclosure date, we were scrambling with the exploit. 21:02.520 --> 21:07.120 And we actually pulled the exploit together in about three weeks from start to finish. 21:09.100 --> 21:14.900 But we sort of just dedicated a specific amount of time to hit DEFCON and Black Hat. 21:15.740 --> 21:19.900 Oftentimes, it's very, very hard to schedule this type of research. 21:19.900 --> 21:22.440 You never know what you're going to find, how long it's going to take. 21:25.480 --> 21:26.040 Great. 21:26.040 --> 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? 21:31.520 --> 21:34.620 Or was this mostly a hunting trip? 21:37.540 --> 21:38.960 There's always something. 21:39.080 --> 21:44.140 I don't think we've ever encountered a target where we haven't found anything. 21:47.640 --> 21:49.740 So, yeah, there's always something. 21:53.140 --> 21:53.980 Great. 21:56.400 --> 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? 22:10.220 --> 22:12.220 Did I hear you say yes now? 22:13.780 --> 22:16.000 They do have patches available. 22:16.000 --> 22:25.600 Of course, you have to patch your device using the patches, but they are available. 22:25.720 --> 22:27.120 You have to install them. 22:30.580 --> 22:31.140 Great. 22:31.140 --> 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. 22:38.940 --> 22:47.120 So folks, please keep the questions coming in the last eight minutes we've got here. 22:47.120 --> 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. 22:58.060 --> 23:02.620 So there was an additional question we started with. 23:02.820 --> 23:08.280 You had several things you talked about at the very beginning of your presentation. 23:08.880 --> 23:14.980 These are a number of vulnerabilities, yet you showed just one. 23:14.980 --> 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? 23:24.100 --> 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? 23:33.240 --> 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. 23:44.060 --> 23:48.060 We think it's cool because it will bypass NAT, right? 23:48.060 --> 23:53.760 The DNS request will exit your corporate network potentially, depends how it's configured. 23:54.700 --> 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. 24:07.940 --> 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. 24:14.280 --> 24:18.180 We do have some new research that we're going to be releasing in a few months. 24:18.180 --> 24:22.720 And then, of course, we do a lot of work for our customers. 24:22.720 --> 24:25.560 Most of our work is just for customers. 24:25.760 --> 24:28.580 We do penetration testing and research and stuff like that. 24:29.260 --> 24:36.760 From the research lab's side, a little bit more about Drupal 20, some new stuff we found out. 24:37.560 --> 24:45.200 Something that we sort of released only on Twitter, but we never called it documented on a white paper. 24:46.100 --> 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. 25:10.100 --> 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. 25:20.960 --> 25:29.620 And just our company firewall was blocking it, so we encapsulated the packets and they bypassed the firewall. 25:29.620 --> 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. 25:40.580 --> 25:45.320 It's currently under disclosure, a coordinated disclosure process. 25:46.200 --> 25:47.400 Great. 25:47.420 --> 25:53.420 Yeah, unfortunately your future research becomes DEF CON talks, you won't get to drink at those. 25:55.280 --> 25:56.720 That's only the first time. 25:57.440 --> 26:05.540 We did have one more question come in and said, is JSOF going to create any tools like Nmap, NSF, etc. 26:05.540 --> 26:08.780 to help bind the devices that may have these issues? 26:11.380 --> 26:15.040 So we already have detection scripts. 26:15.680 --> 26:22.180 You can send us an email, the address is on our website, and you can get the detection scripts. 26:22.180 --> 26:31.000 And also, correct me if I'm wrong, but we have the filters for... what's it called? 26:33.840 --> 26:41.100 So we have... there's passive detection scripts for the exploits themselves. 26:41.100 --> 26:46.960 We have some passive information about how to detect the track stack and some active detection scripts. 26:46.960 --> 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. 26:53.440 --> 27:01.400 They are also available, I think Tenable released them as a package and Zeek released them as a package. 27:02.160 --> 27:06.260 Probably a few others have released them as a package, but those are the ones we know about. 27:06.260 --> 27:09.820 And yeah, until we release them open source, you can just email us. 27:10.780 --> 27:16.460 Anyone whose legitimate request, we'll just send you the scripts. 27:18.400 --> 27:22.280 Take us a couple hours and you'll get the scripts in your email. 27:22.880 --> 27:27.460 Great, and if I remember correctly, your contact information is in the beginning of your talk, correct? 27:29.460 --> 27:30.720 I hope so. 27:30.720 --> 27:39.700 If not, it's just ripple20 at jsof-tech.jsof-tech.com. 27:42.320 --> 27:45.820 Hopefully someone was typing faster than I did when you said that. 27:45.980 --> 27:48.340 So we do have one last question. 27:48.560 --> 27:56.160 What specific recommendations would you have for third-party library vendors that could minimize the possibility of vulnerabilities like this? 27:58.180 --> 28:02.120 So code review would be a big one. 28:02.200 --> 28:06.500 Exploit mitigations would be another one. 28:06.500 --> 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. 28:27.920 --> 28:33.060 Because doing this once for Crack, it's just like we found one vulnerability and it affects everyone. 28:33.540 --> 28:36.380 Like one secure code review would protect everyone. 28:36.380 --> 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. 28:51.580 --> 29:00.580 And the more your clients should be asking you about your security and probably will be going forward. 29:01.720 --> 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. 29:12.420 --> 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. 29:23.960 --> 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. 29:39.640 --> 29:45.740 So I think a lot of these device manufacturers, they do realize where they end up. 29:45.740 --> 29:50.580 The thing is they started writing the code 20 years ago when nobody was thinking about security. 29:50.740 --> 29:54.700 And then the code probably worked really well and just nobody wanted to touch it. 29:54.700 --> 30:05.780 And somewhere along the line, all these companies sort of forgot that they probably revamped their own security processes and activities. 30:05.780 --> 30:11.120 But maybe they figured if there's something in a third party, it's like a third party problem. 30:11.120 --> 30:14.740 Or maybe they didn't realize they've been using this library for 20 years. 30:14.920 --> 30:20.060 So I don't think that it's that Treck didn't know where the code ends up. 30:20.060 --> 30:23.320 It's just 20 years ago, nobody was talking about security. 30:23.320 --> 30:24.560 And that's when the code was written. 30:24.560 --> 30:26.320 A lot of this code is really old. 30:26.320 --> 30:27.020 Not just Treck. 30:27.360 --> 30:28.760 All IoT code. 30:28.760 --> 30:32.820 A lot of the code is not very fresh code. 30:34.680 --> 30:35.620 Well, great, guys. 30:35.620 --> 30:37.360 So we're at the top of the hour. 30:37.400 --> 30:39.160 I want to be respectful of your time. 30:39.200 --> 30:41.800 I really appreciate you guys taking the time to take these Q&A's. 30:41.800 --> 30:45.680 And I appreciate all the questions that have come in on the Discord chat. 30:45.860 --> 30:48.320 Any last words before we call this, folks? 30:51.860 --> 30:52.500 All right, guys. 30:53.860 --> 30:57.080 We really look forward to more good work from you guys. 30:57.760 --> 30:58.320 All right. 30:58.320 --> 30:58.920 Have a good one. 30:58.920 --> 30:59.680 Thank you. 31:00.520 --> 31:01.000 Bye.