Welcome to the presentation about Cotopaxi toolkit for testing IoT devices.
At the beginning, a short introduction about myself. My name is Jakub Botwicz. Currently,
I work in Samsung R&D Center in Poland, where I lead a small team of security pen testers.
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 Isle 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 Cotopaxi? One thing is that the 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 Coop, 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 Cotopaxi 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 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. Similarly, in Wireshark, it supports most of new protocols but only on standard ports.
On the slide, you can see example of Coop traffic that was shown as unknown UDP protocol.
Only after manual change using decodeS function, you will receive decoded Coop packets.
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.
All of that was used as a foundation for Cotopaxi.
The most important information about Cotopaxi, it was released to public as an open source
project under GPL2 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, Cotopaxi is an active volcano in Ecuador
and it's quite interesting target for climbing. Cotopaxi 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. 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.
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
detect and so on. Deer buster 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 analyzes traffic and classifies 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.
Cotopaxi currently supports 10 protocols, three of them were added in this version.
These are advanced message queuing protocol, AMQP, MQTT for sensor networks, and the QUIC
protocol. I will shortly tell about the two of them. QUIC 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 MQTT-SN. This is an UDP clone of the most popular
IoT protocol MQTT. It was designed for sensor networks, what is quite popular in IoT world.
Okay, first and basic tool in the Cotopaxi 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. And this is an extension of usual port scan using NMAP.
The next tool is ServiceFingerprinter. This is an equivalent to NMAP, service and application
version detection. 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.
And the next tool is used for device identification. This is a new feature in
this version. It is based on two large corpuses 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 dirbuster, 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 Cotopaxi will check each of them on the server. There are some
predefined lists for each protocol available in the list's subdirectory.
Next feature is a protocol fuzzer. 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. Usually, packets processed longer
are more interesting for further 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 10 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 Cotopaxi. 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.
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. 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 attackers send 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
Cotopaxi. 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 Cotopaxi with the first tool named ServicePink. As for
all the tools in the toolkit, you can use "-h", to receive help. 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. 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 2000 with one of the available servers. 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. However, when you use Cotopaxi, 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 receive information that the server here is
co-op. And the next tool I would like to show you is the ServerPink.enter.
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 before and after the test
and it was identified as using io-coop. 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 resource 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 Cotopaxi, there are
multiple lists for each of the protocol and they are provided in the folder Cotopaxi lists.
You can see here the results for the following
endpoints. So we're out, advanced, advanced, graded, basic, big, and so on. And during
the testing, the tool also provided calculated amplification factor for each
of the URLs. 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.
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 pin. Okay, so we will now
ping it using Cotopaxi. You see that it responds to the 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.
And what happened here is the Cotopaxi started fuzzing, sent the first packet,
the packet was responded. But with the next packet, the hub crashed. So Cotopaxi
is waiting for the hub to reload. And after this, it 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, Cotopaxi waits
60 seconds. And you can see that again the next packet caused again a crash.
And during the crash, the light bulb does not change the color.
The corpus is quite big for DTLS protocol, so that the whole test could take a really
long time. But we can stop it and we will receive information that Cotopaxi found two payloads
that caused 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 ping. Again, we will see that it responds to DTLS. And we can now crash it.
You can see that the lights went dark and the server and the Cotopaxi checked that
this device is vulnerable to this attack. And the hub is back again.
And now I will show you how to use AmplifierDetector 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 AmplifierDetector.
You can see the syntax is as follows, that you need to provide
IP address of the host that will be monitored.
And now we will first perform service ping 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 co-op server will provide some larger
data. Okay, and now 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 an implementation of co-op client and here is the Cotopaxi client
Protocol Fuzzer. We will start it.
It will be listening as a server on port 10000. And now we can
start the client. 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.
When we start initiate next transmission, we will receive next payloads.
We can stop it at any time and see how many payloads were sent.
Similarly works the Vulnerability Tester. It also listens at a particular port.
And when we start a client, we will receive information which payloads were sent and we
can see what happened on the client side. And finally, after sending all payloads
for this protocol, we receive information summary.
Similarly to the server version, we can always see a list of all issues that can be
that can be tested using this tool.
The next tool I would like to show you is device identification,
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 an 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 larger dumps, it is possible to stop loading at any moment,
and the whole packets that were already loaded will be processed afterwards.
Okay, 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, the device identification tool supports
around 55 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 Cotopaxi. 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 the presentation and demo. If you have any questions,
please ask them using the DEF CON chat. Thank you!