[00:00.000 --> 00:05.580]  Welcome to the presentation about Cotopaxi toolkit for testing IoT devices.
[00:05.580 --> 00:10.640]  At the beginning, a short introduction about myself. My name is Jakub Botwicz. Currently,
[00:10.640 --> 00:16.240]  I work in Samsung R&D Center in Poland, where I lead a small team of security pen testers.
[00:16.340 --> 00:23.620]  In recent three years, I have reported more than 30 CVEs to different open source components,
[00:23.620 --> 00:28.700]  mostly IoT libraries. In my free time, I climb and trek in the mountains,
[00:28.700 --> 00:33.160]  especially Isle of Active Volcanoes, which inspired the name of the toolkit.
[00:33.540 --> 00:37.580]  I would like to acknowledge also other contributors who added new features or
[00:37.580 --> 00:41.680]  performed quality reviews of the tool. They are listed on the slide.
[00:42.780 --> 00:48.140]  What was the idea for Cotopaxi? One thing is that the overall security level of IoT devices
[00:48.140 --> 00:53.680]  is still very low, so there is a lot of testing to do. Another topic is that there are new
[00:53.680 --> 01:01.340]  protocols used mainly in IoT devices like Coop, DTLS, or MQTT, and most of these new protocols
[01:01.340 --> 01:08.180]  are not supported by security testing tools. If you look at the slide, you will see the
[01:08.180 --> 01:14.660]  landscape of security tools for IoT devices when we started preparing Cotopaxi back in 2017.
[01:14.880 --> 01:21.760]  There were lots of gaps, and the major tool Shodan search engine could be used only for
[01:21.760 --> 01:29.440]  public devices. Currently, the situation changed a little bit for better with the new tools that
[01:29.440 --> 01:37.240]  appeared during last years. But still, when you have a look at specific protocols, there are still
[01:37.240 --> 01:44.340]  multiple gaps to fill. For example, when you run nmap scan on a device using Coop protocol on
[01:44.340 --> 01:51.340]  non-standard port, you will receive a lot of unknown protocols or wild guesses based only on
[01:51.340 --> 02:02.440]  port numbers. 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:28.560]  So when in 2017 our team performed large-scale assessment of multiple IoT components, we got
[02:28.560 --> 02:34.960]  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:49.000]  The most important information about Cotopaxi, it was released to public as an open source
[02:49.000 --> 02:57.360]  project under GPL2 license. It is available in the public GitHub repository in the Samsung
[02:57.360 --> 03:03.400]  organization. Currently, this is the fourth release of the tool with new features and vulnerabilities.
[03:04.240 --> 03:09.040]  When it comes to this strange name, Cotopaxi is an active volcano in Ecuador
[03:09.040 --> 03:16.720]  and it's quite interesting target for climbing. Cotopaxi can be used by different security
[03:16.720 --> 03:22.140]  personnel. If you're a pentester, you can use it when you're performing black box assessment
[03:22.880 --> 03:31.500]  of large environments like smart home, smart factory, or smart city. If you're a security
[03:31.500 --> 03:38.300]  researcher, you can analyze network traffic of tested device, identify known vulnerabilities,
[03:38.300 --> 03:45.820]  or check for OEM devices. And finally, if you're a developer or vendor, you can
[03:45.820 --> 03:51.940]  fuzz your devices and check whether they can be used in distributed denial of service attacks.
[03:52.540 --> 03:57.900]  Currently, there are 10 tools in the toolkit and they support different phases of penetration
[03:57.900 --> 04:04.720]  testing. Starting from the reconnaissance phase, there is a service ping that checks
[04:04.720 --> 04:15.800]  availability of endpoints for specific protocols. The next one is security scanner that allows to
[04:15.800 --> 04:24.700]  detect and so on. Deer buster for resource listing in various protocols. Software finger
[04:24.700 --> 04:31.560]  painter that classifies software components used by the server. And the new tool for device
[04:31.560 --> 04:38.160]  identification that passively analyzes traffic and classifies devices using machine learning.
[04:38.960 --> 04:44.640]  In the pre-exploitation phase, there are amplification sniffer for detecting traffic
[04:44.640 --> 04:53.540]  amplifiers. 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:16.180]  These are advanced message queuing protocol, AMQP, MQTT for sensor networks, and the QUIC
[05:16.180 --> 05:24.180]  protocol. I will shortly tell about the two of them. QUIC is the new protocol designed by Google
[05:24.180 --> 05:34.000]  and widely used in their applications and IoT devices. It is mainly like TCP and TLS in one
[05:34.000 --> 05:43.820]  with support for multiple streams and low latency and connection setup. And it's also UDP based.
[05:44.240 --> 05:51.400]  The second of new protocols is MQTT-SN. This is an UDP clone of the most popular
[05:51.400 --> 06:02.720]  IoT protocol MQTT. It was designed for sensor networks, what is quite popular in IoT world.
[06:03.620 --> 06:12.960]  Okay, first and basic tool in the Cotopaxi toolkit is ServicePink. It's used by all other tools
[06:14.340 --> 06:20.440]  to check whether there's an active server of protocol at a specific address and port.
[06:20.640 --> 06:24.700]  It uses a set of payloads for each protocol to test
[06:25.340 --> 06:31.780]  endpoints. And this is an extension of usual port scan using NMAP.
[06:32.680 --> 06:39.220]  The next tool is ServiceFingerprinter. This is an equivalent to NMAP, service and application
[06:39.220 --> 06:47.060]  version detection. However, NMAP works only using server responses comparison for a list of inputs,
[06:47.060 --> 06:53.860]  while Cotopaxi uses machine learning classifier based on the number of requests and responses.
[06:55.140 --> 07:00.440]  And the next tool is used for device identification. This is a new feature in
[07:00.440 --> 07:06.900]  this version. It is based on two large corpuses of IoT traffic provided by authors of papers
[07:06.900 --> 07:14.640]  listed on the slide. After recording sample of traffic, we can classify all devices that were
[07:17.720 --> 07:23.880]  communicating, but you need to make sure that you have captured all of packets
[07:23.880 --> 07:30.820]  going in and out of device, so that the classification results were accurate.
[07:31.580 --> 07:38.080]  The next tool performs resource listing, and it's similar to popular dirbuster, but works
[07:38.080 --> 07:46.740]  for a wider range of protocols like co-op, multicast DNS, ssdp, rtsp. You need to provide
[07:46.920 --> 07:52.960]  a list of resource names and Cotopaxi will check each of them on the server. There are some
[07:52.960 --> 07:59.480]  predefined lists for each protocol available in the list's subdirectory.
[08:01.100 --> 08:07.900]  Next feature is a protocol fuzzer. It is using a corpus of malformed packets prepared
[08:08.300 --> 08:15.320]  using American Fuzzalab fuzzer, and it checks whether device crashed after receiving packet,
[08:15.320 --> 08:21.580]  or what was the time of packet processing. Usually, packets processed longer
[08:21.580 --> 08:28.940]  are more interesting for further analysis and mutations, and can be used for next steps of
[08:28.940 --> 08:36.840]  fuzzing. The next tool is vulnerability tester. We have five classes of vulnerabilities,
[08:36.840 --> 08:42.480]  information disclosures, crashes, traffic amplifications, memory leaks, and remote
[08:42.480 --> 08:50.640]  code execution. In this version, we have 10 new vulnerabilities that were added to the database,
[08:50.640 --> 09:01.500]  and in total 34 issues. Here we can see a sample of vulnerabilities found by us, and
[09:02.640 --> 09:10.060]  that can be identified by Cotopaxi. For example, we have here a malformed DNS packet that causes
[09:10.720 --> 09:19.000]  infinite loops in a tiny SVC MDNS server, or a single packet that induces six packets
[09:19.000 --> 09:25.220]  in response from the server, which can be used for distributed denial of service attacks.
[09:26.020 --> 09:33.340]  And the last, but not least, tool in our toolkit is the amplification sniffer that dumps all
[09:33.340 --> 09:39.320]  packets, and analyze input and output of the server, calculate the amplification
[09:40.120 --> 09:46.600]  factor for tested device. Short information how IoT devices can be used to perform
[09:47.240 --> 09:53.720]  distributed denials of service attacks. It is possible, after identifying a large number of
[09:53.720 --> 10:02.460]  vulnerabilities devices, that attackers send packets with spoofed source addresses,
[10:02.460 --> 10:10.180]  and device sends responses to victim, causing traffic overload. It's possible easily in UDP
[10:10.180 --> 10:14.860]  based protocols, where there is no handshake at the beginning of communications,
[10:15.580 --> 10:21.080]  so UDP based protocols like co-op or DTLS can be used for such attacks.
[10:22.000 --> 10:29.800]  So finally, before we start the demo, short information what you can do to start with
[10:29.800 --> 10:38.120]  Cotopaxi. First, download the tool from the repository, read the manual and install it.
[10:38.120 --> 10:46.760]  Of course, use it and hack different devices, but only when you have a consent of the owner,
[10:46.760 --> 10:52.760]  or you are the owner. If you find any errors in the toolkit, pre-support it
[10:53.320 --> 11:01.200]  using GitHub issues. Using the same way, you can contribute new vulnerabilities or new code.
[11:05.540 --> 11:14.100]  So we can now start using Cotopaxi with the first tool named ServicePink. As for
[11:14.100 --> 11:23.260]  all the tools in the toolkit, you can use "-h", to receive help. And you can see that for this
[11:23.260 --> 11:31.740]  tool, you need to provide destination address in the form of hostname, single IP address or
[11:31.740 --> 11:44.440]  multiple addresses by a list separated by a comma or by a mask. Similarly for port,
[11:44.440 --> 11:53.220]  you can use single port, multiple ports with a range or with a list with a comma.
[11:58.720 --> 12:17.730]  We have a test environment here with multiple devices to test. For example,
[12:20.210 --> 12:32.190]  port 2000 with one of the available servers. If you see on the right side,
[12:32.190 --> 12:38.330]  when you try to use nmap, you will receive information that there is some unknown
[12:39.050 --> 12:45.210]  service on the port. However, when you use Cotopaxi, you will receive information that
[12:45.210 --> 12:55.250]  the server here is empty. Similarly for UDP-based
[12:58.710 --> 13:12.110]  ports, you can also check them in the pink and we receive information that the server here is
[13:12.110 --> 13:23.520]  co-op. 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:41.880]  And after executing this, we can see that the server was alive before and after the test
[13:41.880 --> 13:55.080]  and it was identified as using io-coop. If we get the verbose, we will see all the packets that were
[13:55.080 --> 14:05.960]  sent and the vector of attributes that was used for classification and finally the result.
[14:07.510 --> 14:25.280]  Okay, we can also check the resource listener. Again, we need to provide the IP address port
[14:25.920 --> 14:31.140]  and for this tool we need to provide also a list of the
[14:33.200 --> 14:40.860]  resources that we will be looking at the server. And for Cotopaxi, there are
[14:41.680 --> 14:49.790]  multiple lists for each of the protocol and they are provided in the folder Cotopaxi lists.
[14:56.990 --> 15:03.610]  You can see here the results for the following
[15:05.350 --> 15:12.370]  endpoints. So we're out, advanced, advanced, graded, basic, big, and so on. And during
[15:15.130 --> 15:25.450]  the testing, the tool also provided calculated amplification factor for each
[15:26.300 --> 15:33.690]  of the URLs. And you can see that for some of the URLs that the amplification factors are
[15:34.260 --> 15:44.750]  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:08.940]  As you can see, the light bulb is continuously steered to change the
[16:08.940 --> 16:21.330]  color and the hub is still available using the standard pin. Okay, so we will now
[16:23.190 --> 16:38.000]  ping it using Cotopaxi. 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:18.070]  And what happened here is the Cotopaxi started fuzzing, sent the first packet,
[17:18.070 --> 17:30.290]  the packet was responded. But with the next packet, the hub crashed. So Cotopaxi
[17:30.290 --> 17:41.830]  is waiting for the hub to reload. And after this, it will continue fuzzing with the next payloads.
[17:42.790 --> 17:52.170]  You can see the lights on the hub. They are showing the current status of the hub.
[17:52.170 --> 18:11.060]  When the light gets dark, the hub is going down. So after each crash, Cotopaxi waits
[18:11.940 --> 18:19.700]  60 seconds. 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:46.460]  The corpus is quite big for DTLS protocol, so that the whole test could take a really
[18:47.640 --> 18:57.120]  long time. But we can stop it and we will receive information that Cotopaxi found two payloads
[18:57.120 --> 19:03.890]  that caused crash. And these are the files that are crashing.
[19:05.850 --> 19:08.080]  We can also use
[19:10.740 --> 19:20.110]  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:50.460]  We can check it with ping. Again, we will see that it responds to DTLS. And we can now crash it.
[19:52.280 --> 20:01.800]  You can see that the lights went dark and the server and the Cotopaxi checked that
[20:01.800 --> 20:22.660]  this device is vulnerable to this attack. And the hub is back again.
[20:25.850 --> 20:31.850]  And now I will show you how to use AmplifierDetector to check which services can be used
[20:31.850 --> 20:39.370]  to perform distributed denial-of-service attacks. We have here a wire shark that will
[20:39.370 --> 20:45.420]  show us the whole traffic. In this window, we will run the AmplifierDetector.
[20:46.230 --> 20:51.210]  You can see the syntax is as follows, that you need to provide
[20:51.910 --> 20:55.730]  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:34.650]  But when we start to perform resource listing to the same IP address on the port,
[21:34.650 --> 21:44.330]  we will see some larger responses where the co-op server will provide some larger
[21:45.670 --> 22:09.250]  data. Okay, and now you will see the highest amplification factor was
[22:09.930 --> 22:22.010]  2048 and it was provided using the following request and response.
[22:24.430 --> 22:33.350]  And when we stop the amplification detector, we will receive again the same
[22:34.470 --> 22:39.410]  packet that was the highest amplification factor.
[22:40.670 --> 22:52.150]  Also, the resource locator provides us also with information about amplification factor for each
[22:53.870 --> 22:58.710]  of the provided requests and responses.
[23:01.190 --> 23:04.910]  I have already shown you how to use the standard versions of
[23:04.910 --> 23:10.370]  Protocol Fuzzer and Vulnerability Tester. Now we used client versions.
[23:11.690 --> 23:19.730]  Okay, so here we have an implementation of co-op client and here is the Cotopaxi client
[23:19.730 --> 23:25.210]  Protocol Fuzzer. We will start it.
[23:26.930 --> 23:35.110]  It will be listening as a server on port 10000. And now we can
[23:36.770 --> 23:42.670]  start the client. And as you can see,
[23:43.630 --> 23:51.890]  client initiated traffic, sent request to the server and server responded
[23:52.850 --> 24:01.610]  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:31.350]  Similarly works the Vulnerability Tester. It also listens at a particular port.
[24:32.510 --> 24:39.370]  And when we start a client, we will receive information which payloads were sent and we
[24:39.370 --> 24:49.230]  can see what happened on the client side. And finally, after sending all payloads
[24:49.230 --> 24:53.790]  for this protocol, we receive information summary.
[24:55.390 --> 25:05.350]  Similarly to the server version, we can always see a list of all issues that can be
[25:06.730 --> 25:11.910]  that can be tested using this tool.
[25:14.830 --> 25:18.550]  The next tool I would like to show you is device identification,
[25:18.550 --> 25:25.150]  which is a new feature in this version. To use it, you need to provide a pickup file
[25:26.670 --> 25:31.950]  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 --> 25:59.150]  We can load just the whole file without showing the IP address and then the tool will try to classify
[26:00.510 --> 26:12.630]  every IP address that is included in this dump. And here you see the results for every IP.
[26:13.850 --> 26:27.410]  If there is no one distinct class, you will see the whole similar classes with the
[26:28.130 --> 26:43.050]  percentage probability. For larger dumps, it is possible to stop loading at any moment,
[26:43.050 --> 26:54.690]  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:45.030]  And in this case, after loading packets, we can see only results of classification for this
[27:46.110 --> 27:56.180]  one selected device. Currently, the device identification tool supports
[27:56.880 --> 28:07.280]  around 55 devices. If you have any other device that is not supported yet,
[28:07.280 --> 28:15.780]  please send us a pickup file with the dump of the traffic network and we will
[28:16.460 --> 28:24.780]  add it to the next version of Cotopaxi. And of course, if you see that any device was incorrectly
[28:25.520 --> 28:34.580]  classified, also please send us your dump and we will fix it.
[28:37.670 --> 28:42.770]  Thank you for watching the presentation and demo. If you have any questions,
[28:42.770 --> 28:49.110]  please ask them using the DEF CON chat. Thank you!