WEBVTT 00:00.000 --> 00:05.580 Welcome to the presentation about Cotopaxi toolkit for testing IoT devices. 00:05.580 --> 00:08.660 At the beginning, a short introduction about myself. 00:08.720 --> 00:10.140 My name is Jakub Botwicz. 00:10.140 --> 00:16.240 Currently, I work in Samsung R&D Center in Poland, where I lead a small team of security pen testers. 00:16.340 --> 00:25.420 In recent three years, I have reported more than 30 CVEs to different open source components, mostly IoT libraries. 00:25.420 --> 00:33.160 In my free time, I climb and trek in the mountains, especially Isle of Active Volcanoes, which inspired the name of the toolkit. 00:33.540 --> 00:39.940 I would like to acknowledge also other contributors who added new features or performed quality reviews of the tool. 00:39.960 --> 00:41.680 They are listed on the slide. 00:42.780 --> 00:44.820 What was the idea for Cotopaxi? 00:44.820 --> 00:51.760 One thing is that the overall security level of IoT devices is still very low, so there is a lot of testing to do. 00:51.760 --> 01:04.440 Another topic is that there are new protocols used mainly in IoT devices like Coop, DTLS, or MQTT, and most of these new protocols are not supported by security testing tools. 01:05.420 --> 01:14.660 If you look at the slide, you will see the landscape of security tools for IoT devices when we started preparing Cotopaxi back in 2017. 01:14.880 --> 01:23.420 There were lots of gaps, and the major tool Shodan search engine could be used only for public devices. 01:24.040 --> 01:32.160 Currently, the situation changed a little bit for better with the new tools that appeared during last years. 01:32.780 --> 01:39.300 But still, when you have a look at specific protocols, there are still multiple gaps to fill. 01:40.000 --> 01:52.940 For example, when you run nmap scan on a device using Coop protocol on non-standard port, you will receive a lot of unknown protocols or wild guesses based only on port numbers. 01:53.800 --> 02:02.440 Similarly, in Wireshark, it supports most of new protocols but only on standard ports. 02:02.440 --> 02:13.180 On the slide, you can see example of Coop traffic that was shown as unknown UDP protocol. 02:14.140 --> 02:20.240 Only after manual change using decodeS function, you will receive decoded Coop packets. 02:21.340 --> 02:34.960 So when in 2017 our team performed large-scale assessment of multiple IoT components, we got ideas for new tools, large corpus with malformed packets, and a pack of new vulnerabilities. 02:36.500 --> 02:40.940 All of that was used as a foundation for Cotopaxi. 02:43.320 --> 02:52.880 The most important information about Cotopaxi, it was released to public as an open source project under GPL2 license. 02:52.880 --> 02:58.780 It is available in the public GitHub repository in the Samsung organization. 02:58.780 --> 03:03.400 Currently, this is the fourth release of the tool with new features and vulnerabilities. 03:04.240 --> 03:12.920 When it comes to this strange name, Cotopaxi is an active volcano in Ecuador and it's quite interesting target for climbing. 03:14.100 --> 03:17.740 Cotopaxi can be used by different security personnel. 03:17.800 --> 03:30.120 If you're a pentester, you can use it when you're performing black box assessment of large environments like smart home, smart factory, or smart city. 03:30.320 --> 03:42.740 If you're a security researcher, you can analyze network traffic of tested device, identify known vulnerabilities, or check for OEM devices. 03:42.960 --> 03:51.940 And finally, if you're a developer or vendor, you can fuzz your devices and check whether they can be used in distributed denial of service attacks. 03:52.540 --> 03:59.020 Currently, there are 10 tools in the toolkit and they support different phases of penetration testing. 03:59.020 --> 04:08.160 Starting from the reconnaissance phase, there is a service ping that checks availability of endpoints for specific protocols. 04:08.520 --> 04:17.600 The next one is security scanner that allows to detect and so on. 04:17.640 --> 04:23.540 Deer buster for resource listing in various protocols. 04:23.540 --> 04:29.540 Software finger painter that classifies software components used by the server. 04:29.540 --> 04:38.160 And the new tool for device identification that passively analyzes traffic and classifies devices using machine learning. 04:38.960 --> 04:46.260 In the pre-exploitation phase, there are amplification sniffer for detecting traffic amplifiers. 04:46.260 --> 04:53.540 Protocol fuzzer in two versions for testing clients and servers. 04:54.020 --> 04:58.720 And known vulnerability tester also in two versions. 05:00.060 --> 05:06.200 Cotopaxi currently supports 10 protocols, three of them were added in this version. 05:07.000 --> 05:17.240 These are advanced message queuing protocol, AMQP, MQTT for sensor networks, and the QUIC protocol. 05:17.240 --> 05:21.060 I will shortly tell about the two of them. 05:21.260 --> 05:30.080 QUIC is the new protocol designed by Google and widely used in their applications and IoT devices. 05:30.080 --> 05:40.440 It is mainly like TCP and TLS in one with support for multiple streams and low latency and connection setup. 05:40.440 --> 05:43.820 And it's also UDP based. 05:44.240 --> 05:47.780 The second of new protocols is MQTT-SN. 05:47.780 --> 05:54.340 This is an UDP clone of the most popular IoT protocol MQTT. 05:54.400 --> 06:02.720 It was designed for sensor networks, what is quite popular in IoT world. 06:03.620 --> 06:10.680 Okay, first and basic tool in the Cotopaxi toolkit is ServicePink. 06:10.680 --> 06:20.440 It's used by all other tools to check whether there's an active server of protocol at a specific address and port. 06:20.640 --> 06:26.800 It uses a set of payloads for each protocol to test endpoints. 06:26.860 --> 06:31.780 And this is an extension of usual port scan using NMAP. 06:32.680 --> 06:35.660 The next tool is ServiceFingerprinter. 06:35.660 --> 06:40.840 This is an equivalent to NMAP, service and application version detection. 06:40.920 --> 06:53.860 However, NMAP works only using server responses comparison for a list of inputs, while Cotopaxi uses machine learning classifier based on the number of requests and responses. 06:55.140 --> 06:59.280 And the next tool is used for device identification. 06:59.280 --> 07:01.620 This is a new feature in this version. 07:01.680 --> 07:08.820 It is based on two large corpuses of IoT traffic provided by authors of papers listed on the slide. 07:09.020 --> 07:14.640 After recording sample of traffic, we can classify all devices that were 07:17.720 --> 07:30.820 communicating, but you need to make sure that you have captured all of packets going in and out of device, so that the classification results were accurate. 07:31.580 --> 07:44.940 The next tool performs resource listing, and it's similar to popular dirbuster, but works for a wider range of protocols like co-op, multicast DNS, ssdp, rtsp. 07:45.460 --> 07:52.000 You need to provide a list of resource names and Cotopaxi will check each of them on the server. 07:52.200 --> 07:59.480 There are some predefined lists for each protocol available in the list's subdirectory. 08:01.100 --> 08:03.360 Next feature is a protocol fuzzer. 08:03.360 --> 08:19.240 It is using a corpus of malformed packets prepared using American Fuzzalab fuzzer, and it checks whether device crashed after receiving packet, or what was the time of packet processing. 08:19.240 --> 08:30.060 Usually, packets processed longer are more interesting for further analysis and mutations, and can be used for next steps of fuzzing. 08:31.200 --> 08:33.900 The next tool is vulnerability tester. 08:33.900 --> 08:43.980 We have five classes of vulnerabilities, information disclosures, crashes, traffic amplifications, memory leaks, and remote code execution. 08:44.120 --> 08:55.760 In this version, we have 10 new vulnerabilities that were added to the database, and in total 34 issues. 08:56.820 --> 09:05.120 Here we can see a sample of vulnerabilities found by us, and that can be identified by Cotopaxi. 09:05.120 --> 09:25.220 For example, we have here a malformed DNS packet that causes infinite loops in a tiny SVC MDNS server, or a single packet that induces six packets in response from the server, which can be used for distributed denial of service attacks. 09:26.020 --> 09:42.320 And the last, but not least, tool in our toolkit is the amplification sniffer that dumps all packets, and analyze input and output of the server, calculate the amplification factor for tested device. 09:43.120 --> 09:49.620 Short information how IoT devices can be used to perform distributed denials of service attacks. 09:49.620 --> 10:07.780 It is possible, after identifying a large number of vulnerabilities devices, that attackers send packets with spoofed source addresses, and device sends responses to victim, causing traffic overload. 10:07.780 --> 10:21.080 It's possible easily in UDP based protocols, where there is no handshake at the beginning of communications, so UDP based protocols like co-op or DTLS can be used for such attacks. 10:22.000 --> 10:31.060 So finally, before we start the demo, short information what you can do to start with Cotopaxi. 10:31.220 --> 10:38.120 First, download the tool from the repository, read the manual and install it. 10:38.120 --> 10:48.520 Of course, use it and hack different devices, but only when you have a consent of the owner, or you are the owner. 10:48.700 --> 10:55.620 If you find any errors in the toolkit, pre-support it using GitHub issues. 10:55.920 --> 11:01.200 Using the same way, you can contribute new vulnerabilities or new code. 11:05.540 --> 11:13.160 So we can now start using Cotopaxi with the first tool named ServicePink. 11:13.160 --> 11:20.680 As for all the tools in the toolkit, you can use "-h", to receive help. 11:20.800 --> 11:42.360 And you can see that for this tool, you need to provide destination address in the form of hostname, single IP address or multiple addresses by a list separated by a comma or by a mask. 11:42.360 --> 11:53.220 Similarly for port, you can use single port, multiple ports with a range or with a list with a comma. 11:58.720 --> 12:06.400 We have a test environment here with multiple devices 12:11.990 --> 12:15.530 to test. 12:15.670 --> 12:28.190 For example, port 2000 with one of the available servers. 12:28.190 --> 12:40.650 If you see on the right side, when you try to use nmap, you will receive information that there is some unknown service on the port. 12:40.650 --> 12:49.890 However, when you use Cotopaxi, you will receive information that the server here is empty. 12:50.490 --> 12:55.250 Similarly for UDP-based 12:58.710 --> 13:02.050 ports, you can also check them 13:05.430 --> 13:13.530 in the pink and we receive information that the server here is co-op. 13:19.200 --> 13:23.520 And the next tool I would like to show you is the ServerPink.enter. 13:25.120 --> 13:30.560 Again, we need to provide the IP address on the port and the protocol. 13:31.520 --> 13:47.060 And after executing this, we can see that the server was alive before and after the test and it was identified as using io-coop. 13:47.060 --> 14:05.960 If we get the verbose, we will see all the packets that were sent and the vector of attributes that was used for classification and finally the result. 14:07.510 --> 14:18.600 Okay, we can also check the resource listener. 14:19.120 --> 14:37.480 Again, we need to provide the IP address port and for this tool we need to provide also a list of the resources that we will be looking at the server. 14:38.180 --> 14:49.790 And for Cotopaxi, there are multiple lists for each of the protocol and they are provided in the folder Cotopaxi lists. 14:56.990 --> 15:06.490 You can see here the results for the following endpoints. 15:06.490 --> 15:11.290 So we're out, advanced, advanced, graded, basic, big, and so on. 15:11.290 --> 15:28.530 And during the testing, the tool also provided calculated amplification factor for each of the URLs. 15:28.590 --> 15:44.750 And you can see that for some of the URLs that the amplification factors are quite big, so this tool, this endpoint can be used for traffic amplification attacks. 15:51.080 --> 15:59.980 In the next test, we will use the setup with IoT light bulb connected with the smartphone hub. 15:59.980 --> 16:18.620 As you can see, the light bulb is continuously steered to change the color and the hub is still available using the standard pin. 16:19.060 --> 16:28.270 Okay, so we will now ping it using Cotopaxi. 16:33.300 --> 16:38.000 You see that it responds to the DTLS protocol. 16:38.000 --> 16:45.700 So we can now start fuzzing using the protocol fuzzer. 16:48.600 --> 16:59.040 So we are using the same IP port and the switch for DTLS protocol. 17:06.650 --> 17:20.170 And what happened here is the Cotopaxi started fuzzing, sent the first packet, the packet was responded. 17:20.170 --> 17:28.750 But with the next packet, the hub crashed. 17:28.950 --> 17:36.290 So Cotopaxi is waiting for the hub to reload. 17:36.290 --> 17:41.830 And after this, it will continue fuzzing with the next payloads. 17:42.790 --> 17:47.510 You can see the lights on the hub. 17:47.510 --> 17:52.170 They are showing the current status of the hub. 17:52.170 --> 17:58.630 When the light gets dark, the hub is going down. 18:07.260 --> 18:13.680 So after each crash, Cotopaxi waits 60 seconds. 18:13.840 --> 18:19.700 And you can see that again the next packet caused again a crash. 18:23.860 --> 18:30.730 And during the crash, the light bulb does not change the color. 18:34.520 --> 18:49.320 The corpus is quite big for DTLS protocol, so that the whole test could take a really long time. 18:49.320 --> 18:58.480 But we can stop it and we will receive information that Cotopaxi found two payloads that caused crash. 18:58.480 --> 19:03.890 And these are the files that are crashing. 19:05.850 --> 19:20.110 We can also use Vulnerability Tester, because we already have the payloads in the database. 19:20.860 --> 19:25.320 Okay, so now we see that the hub is running. 19:27.120 --> 19:29.220 We can check it with ping. 19:37.510 --> 19:41.510 Again, we will see that it responds to DTLS. 19:44.270 --> 19:50.460 And we can now crash it. 19:52.280 --> 20:07.280 You can see that the lights went dark and the server and the Cotopaxi checked that this device is vulnerable to this attack. 20:19.880 --> 20:22.660 And the hub is back again. 20:25.850 --> 20:36.770 And now I will show you how to use AmplifierDetector to check which services can be used to perform distributed denial-of-service attacks. 20:36.790 --> 20:41.870 We have here a wire shark that will show us the whole traffic. 20:41.870 --> 20:45.420 In this window, we will run the AmplifierDetector. 20:46.230 --> 20:55.730 You can see the syntax is as follows, that you need to provide IP address of the host that will be monitored. 20:58.950 --> 21:08.530 And now we will first perform service ping to identify whether the server is really responding. 21:10.550 --> 21:14.670 Okay, you can now see the first traffic going in and out. 21:17.410 --> 21:23.010 Currently, the amplification factor is very low. 21:24.650 --> 21:48.030 But when we start to perform resource listing to the same IP address on the port, we will see some larger responses where the co-op server will provide some larger data. 21:57.310 --> 22:22.010 Okay, and now you will see the highest amplification factor was 2048 and it was provided using the following request and response. 22:24.430 --> 22:39.410 And when we stop the amplification detector, we will receive again the same packet that was the highest amplification factor. 22:40.670 --> 22:58.710 Also, the resource locator provides us also with information about amplification factor for each of the provided requests and responses. 23:01.190 --> 23:07.630 I have already shown you how to use the standard versions of Protocol Fuzzer and Vulnerability Tester. 23:07.630 --> 23:10.370 Now we used client versions. 23:11.690 --> 23:21.870 Okay, so here we have an implementation of co-op client and here is the Cotopaxi client Protocol Fuzzer. 23:22.350 --> 23:25.210 We will start it. 23:26.930 --> 23:32.690 It will be listening as a server on port 10000. 23:33.470 --> 23:39.190 And now we can start the client. 23:39.850 --> 24:01.610 And as you can see, client initiated traffic, sent request to the server and server responded with the payload as you can see here in Wireshark. 24:02.350 --> 24:11.910 When we start initiate next transmission, we will receive next payloads. 24:12.310 --> 24:19.110 We can stop it at any time and see how many payloads were sent. 24:20.250 --> 24:23.690 Similarly works the Vulnerability Tester. 24:24.290 --> 24:31.350 It also listens at a particular port. 24:32.510 --> 24:43.130 And when we start a client, we will receive information which payloads were sent and we can see what happened on the client side. 24:45.070 --> 24:53.790 And finally, after sending all payloads for this protocol, we receive information summary. 24:55.390 --> 25:11.910 Similarly to the server version, we can always see a list of all issues that can be that can be tested using this tool. 25:14.830 --> 25:21.030 The next tool I would like to show you is device identification, which is a new feature in this version. 25:21.370 --> 25:31.950 To use it, you need to provide a pickup file with recorded traffic for the host you would like to test. 25:32.490 --> 25:42.630 You can see here we have an example dump open in Wireshark. 25:46.010 --> 26:07.150 We can load just the whole file without showing the IP address and then the tool will try to classify every IP address that is included in this dump. 26:07.570 --> 26:12.630 And here you see the results for every IP. 26:13.850 --> 26:31.390 If there is no one distinct class, you will see the whole similar classes with the percentage probability. 26:31.390 --> 26:54.690 For larger dumps, it is possible to stop loading at any moment, and the whole packets that were already loaded will be processed afterwards. 26:54.690 --> 27:06.570 Okay, now we can click ctrl-c to break loading and you can see the classification results. 27:11.810 --> 27:27.790 And finally, we can just select one IP address, one device to be classified using option minus i. 27:36.550 --> 27:49.670 And in this case, after loading packets, we can see only results of classification for this one selected device. 27:53.020 --> 28:00.140 Currently, the device identification tool supports around 55 devices. 28:00.140 --> 28:19.340 If you have any other device that is not supported yet, please send us a pickup file with the dump of the traffic network and we will add it to the next version of Cotopaxi. 28:19.340 --> 28:34.580 And of course, if you see that any device was incorrectly classified, also please send us your dump and we will fix it. 28:37.670 --> 28:40.870 Thank you for watching the presentation and demo. 28:40.870 --> 28:47.970 If you have any questions, please ask them using the DEF CON chat. 28:47.970 --> 28:49.110 Thank you!