 Come to the presentation about Kotopaxi Toolkit for Testing IoT Devices. At the beginning, a short introduction about myself. My name is Jakub Botvich. Currently, I work in the Samsung Current Decentre in Poland, where I lead a small team of security pentesters. In recent three years, I have reported more than 30 CVEs to different open-source components, mostly IoT libraries. In my free time, I climb and trek in the mountains, especially ILO of active volcanoes, which inspired the name of the toolkit. I would like to acknowledge also other contributors who added new features or performed quality reviews of the tool. They are listed on the slide. What was the idea for Kotopaxi? One thing is that overall security level of IoT devices is still very low, so there is a lot of testing to do. Another topic is that there are new protocols used mainly in IoT devices, like co-op DTLS or MQTT, and most of these new protocols are not supported by security testing tools. If you look at the slide, you will see the landscape of security tools for IoT devices when we started preparing Kotopaxi back in 2017. There were lots of gaps, and the major tool, Shodan, search engine could be used only for public devices. Currently, the situation changed a little bit for better with the new tools that appeared during last years. But still, when you have a look at specific protocols, there are still multiple gaps to fill. For example, when you run an MAP scan on a device using co-op protocol on non-standard port, you will receive a lot of unknown protocols that are wild guesses based only on port numbers. Similarly, in Wireshark, it supports most of new protocols, but only on standard ports. On the slide, you can see an example of co-op traffic that was shown as an unknown UDP protocol. Only after manual change using the code S function you will receive the coded co-op packets. So when in 2017 our team performed a large-scale assessment of multiple IoT components, we got ideas for new tools, large corpus with malformed packets, and a pack of new vulnerabilities. All of that was used as a foundation for Kotopaxi. The most important information about Kotopaxi is released to the public as an open-source project under GPL tool license. It is available in the public GitHub repository in the Samsung organization. Currently, this is the fourth release of the tool with new features and vulnerabilities. When it comes to this strange name, Kotopaxi is an active volcano in Ecuador, and it's quite an interesting target for climbing. Kotopaxi can be used by different security personnel. 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. If you're a security researcher, you can analyze network traffic of tested device, identify known vulnerabilities, or check for OEM devices. 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. Currently, there are 10 tools in the toolkit, and they support different phases of penetration testing. Starting from the reconnaissance phase, there is a service ping that checks availability of endpoints for specific protocols. The next one is security scanner that allows to verify security properties like cryptography certificates and so on. Deerbuster for resource listing in various protocols. Software Finger Painter that classifies software components used by the server. And the new tool for device identification that passively analyzed traffic and classify devices using machine learning. In the pre-exploitation phase, there are amplification sniffer for detecting traffic amplifiers, protocol fuzzer in two versions for testing clients and servers, and known vulnerability tester also in two versions. Kotopaxi currently support 10 protocols. Three of them were added in this version. These are advanced message queuing protocol, AMQP, MQTT for sensor networks, and the Qwik protocol. I will shortly tell about two of them. Qwik is the new protocol designed by Google and widely used in their applications and IoT devices. It is mainly like TCP and TLS in one with support for multiple streams and low latency and connection setup. And it's also UDP based. The second of new protocols is MQTTSN. This is a UDP clone of the most popular IoT protocol MQTT. It was designed for sensor networks, what is quite popular in IoT world. First and basic tool in the Kotopaxi toolkit is ServicePink. It's used by all other tools to check whether there's an active server of protocol at a specific address and port. It uses a set of payloads for each protocol to test endpoints. This is an extension of usual ports using EndMap. The next tool is ServiceFingerPinter. This is an equivalent to EndMap service and application version detection. However, EndMap works only using server responses comparison for a list of inputs, while Kotopaxi uses machine learning classifier based on a number of requests and responses. The next tool is used for device identification. This is a new feature in this version. It is based on two large corpus of IoT traffic provided by authors of papers listed on the slide. After recording sample of traffic, we can classify all devices that were 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. The next tool performs resource listing and it's similar to popular DeerBuster but works for a wider range of protocols like Co-op, Multicast DNS, SSDP, RTSP. You need to provide a list of resource names and Kotopaxi will check each of them on the server. There are some predefined lists for each protocol available in the list's sub-director. The next feature is a protocol fuzzer. It is using corpus of malformed packets prepared using Camerican FuzzyLob fuzzer. It checks whether the device crashed after receiving packet or what was the time of packet processing. Usually packets processed longer are more interesting for feather analysis and mutations and can be used for next steps of fuzzing. The next tool is Vulnerability Tester. We have five classes of Vulnerabilities, information disclosures, crashes, traffic amplifications, memory leaks and remote code execution. In this version, we have ten new vulnerabilities that were added to the database and in total 34 issues. Here we can see a sample of vulnerabilities found by us and that can be identified by Kotopaxi. For example, we have here a malformed DNS packet that cause infinite loop in 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. And the last but not least tool in our toolkit is the amplification sneer that dumps all packets and analyze input and output of the server, calculate amplification factor for tested device. Short information how IoT devices can be used to perform distributed denials of service attacks it is possible after identifying a large number of vulnerabilities devices that attacker sends packets with spoofed source addresses and device sends responses to victim causing traffic overload. 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. So finally, before we start the demo, short information what you can do to start with Kotopaxi. First, download the tool from the repository, read the manual and install it. Of course, use it and hack different devices but only when you have a consent of the owner or you are the owner. If you find any errors in the toolkit, pre-support it using GitHub issues. Using the same way, you can contribute new vulnerabilities or new code. So we can now start using Kotopaxi with the first tool named ServicePink. As for all the tools in the toolkit, you can use minus H to receive help. And you can see that for this tool, you need to provide destination address in the first form of hostname, single ID address or multiple addresses by at least separated by a comma or by a mask. Similarly for port, you can use single port, multiple ports with a range or with a list with a comma. We have a test environment here with multiple devices to test. For example, port 3000 with one of the available servers. If you see on the right side, when you try to use Endmap, you will receive information that there is some unknown service on the port. However, when you use Kotopaxi, you will receive information that the server here is empty. Similarly for UDP-based ports, you can also check them in the pink and we will receive information that the server here is caught. And the next tool I would like to show you is the server in that center. Again, we need to provide the IP address on the port and the protocol. And after executing this, we can see that the server was alive and before and after the test. And it was identified as using IO co-op. 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. Okay, we can also check the source listener 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. And for Kotopaxi, there are multiple lists for each of the protocol and they are provided in the folder Kotopaxi lists. You can see here the results for the following endpoints were found, advanced, advanced, rated, basic, big and so on. And during the testing, the tool also provided a calculated amplification factor for each of the URLs. And you can see that for some of the URLs that amplification factors are quite big. So this endpoint can be used for traffic amplification attacks. In the next test, we will use the setup with IoT light bulb connected with the smartphone hub. As you can see, the light bulb is continuously steered to change the color and the hub is still available using the standard ping. Okay, so we will now ping it using Kotopaxi. You see that it responds to DTLS protocol. So we can now start fuzzing using the protocol fuzzer. So we are using the same IP port and the switch for DTLS protocol. What happened here is Kotopaxi started fuzzing, sent the first packet. The packet was responded. But with the next packet, the hub crashed. So Kotopaxi is waiting for the hub to reload. And after this, the light will continue fuzzing with the next payloads. You can see the lights on the hub. They are showing the current status of the hub. When the light gets dark, the hub is going down. So after each crash, Kotopaxi waits 60 seconds. And the next packet causes a crash. And during the crash, the light bulb doesn't change the color. The corpus is quite big for DTLS protocol. So the whole test could take a really long time. But we can stop it and we will receive information that Kotopaxi found two payloads that caused the crash. And these are the files that are crashing. We can also use Vulnerability tester because we already have the payloads in the database. Okay, so now we see that the hub is running. We can check it with pink. Again, we will see that it responds to DLS. And we can now crash it. You can see that the lights went dark. And the server and Kotopaxi checked that this device is vulnerable to this attack. Yes, and the hub is back again. And now I will show you an amplifier detector to check which services can be used to perform distributed denial of service attacks. We have here a wire shark that will show us the whole traffic. In this window, we will run the amplifier detector. You can see the sent access as follows that you need to provide IP address of the host that will be monitored. And now we will first perform service pink to identify whether the server is really responding. Okay, you can now see the first traffic going in and out. Currently, the amplification factor is very low. But when we start to perform resource listing to the same IP address on the port, we will see some larger responses where the Kotop server will provide some larger data. Okay, and now you have you will see the highest amplification factor was 2048 and it was provided using the following request and response. And when we stop the amplification detector we will receive again the same packet that was the highest amplification factor. Also the resource locator provides us also with information about amplification factor for each of the provided requests and responses. I have already shown you how to use the standard versions of protocol fuzzer and vulnerability tester. Now we used client versions. Okay, so here we have implementation of co-op client and here is the Kotopaxi client protocol fuzzer. We will start it. It will be listening as a server on port 10,000. And now we can start the client. And as you can see client initiated traffic, sent the request to the server and server responded with the payload. As you can see here in Wireshark. When we start initiate the next transmission we will receive the next payloads. We can stop it at any time and see how many payloads were sent. Similarly works the vulnerability tester. It also listened to at a particular port. And when we start a client we will receive information which payload were sent and we can see what happened on the client side. And finally after sending all payloads for this protocol we will receive information and summary. Similarly to the server version we can always see a list of all issues that can be tested using this tool. The next tool I would like to show you is a notification which is a new feature in this version. To use it you need to provide a pickup file with recorded traffic for the host you would like to test. You can see here we have example dump open in Wireshark. 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 and here you see the results for every IP. If there is no one distinct class you will see the whole similar classes with the percentage probability for a larger dumps it is possible to stop loading at any moment and the whole packets that were already loaded will be processed afterwards. Now we can click Ctrl C to break loading and you can see the classification results and finally we can just select one IP address one device to be classified using option minus I and in this case after loading packets we can see only results of classification for this one selected device. Currently device identification tool supports around devices 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 Kotapaxi and of course if you see that any device was incorrectly classified also please send us your dump and we will fix it. Thank you for watching presentation demo if you have any questions please ask them using DEF CON chat Thank you.