1
00:00:00,000 --> 00:00:05,580
Welcome to the presentation about Cotopaxi toolkit for testing IoT devices.

2
00:00:05,580 --> 00:00:08,660
At the beginning, a short introduction about myself.

3
00:00:08,720 --> 00:00:10,140
My name is Jakub Botwicz.

4
00:00:10,140 --> 00:00:16,240
Currently, I work in Samsung R&D Center in Poland, where I lead a small team of security pen testers.

5
00:00:16,340 --> 00:00:25,420
In recent three years, I have reported more than 30 CVEs to different open source components, mostly IoT libraries.

6
00:00:25,420 --> 00: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.

7
00:00:33,540 --> 00:00:39,940
I would like to acknowledge also other contributors who added new features or performed quality reviews of the tool.

8
00:00:39,960 --> 00:00:41,680
They are listed on the slide.

9
00:00:42,780 --> 00:00:44,820
What was the idea for Cotopaxi?

10
00:00:44,820 --> 00: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.

11
00:00:51,760 --> 00: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.

12
00:01:05,420 --> 00: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.

13
00:01:14,880 --> 00:01:23,420
There were lots of gaps, and the major tool Shodan search engine could be used only for public devices.

14
00:01:24,040 --> 00:01:32,160
Currently, the situation changed a little bit for better with the new tools that appeared during last years.

15
00:01:32,780 --> 00:01:39,300
But still, when you have a look at specific protocols, there are still multiple gaps to fill.

16
00:01:40,000 --> 00: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.

17
00:01:53,800 --> 00:02:02,440
Similarly, in Wireshark, it supports most of new protocols but only on standard ports.

18
00:02:02,440 --> 00:02:13,180
On the slide, you can see example of Coop traffic that was shown as unknown UDP protocol.

19
00:02:14,140 --> 00:02:20,240
Only after manual change using decodeS function, you will receive decoded Coop packets.

20
00:02:21,340 --> 00: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.

21
00:02:36,500 --> 00:02:40,940
All of that was used as a foundation for Cotopaxi.

22
00:02:43,320 --> 00:02:52,880
The most important information about Cotopaxi, it was released to public as an open source project under GPL2 license.

23
00:02:52,880 --> 00:02:58,780
It is available in the public GitHub repository in the Samsung organization.

24
00:02:58,780 --> 00:03:03,400
Currently, this is the fourth release of the tool with new features and vulnerabilities.

25
00:03:04,240 --> 00: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.

26
00:03:14,100 --> 00:03:17,740
Cotopaxi can be used by different security personnel.

27
00:03:17,800 --> 00: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.

28
00:03:30,320 --> 00: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.

29
00:03:42,960 --> 00: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.

30
00:03:52,540 --> 00:03:59,020
Currently, there are 10 tools in the toolkit and they support different phases of penetration testing.

31
00:03:59,020 --> 00:04:08,160
Starting from the reconnaissance phase, there is a service ping that checks availability of endpoints for specific protocols.

32
00:04:08,520 --> 00:04:17,600
The next one is security scanner that allows to detect and so on.

33
00:04:17,640 --> 00:04:23,540
Deer buster for resource listing in various protocols.

34
00:04:23,540 --> 00:04:29,540
Software finger painter that classifies software components used by the server.

35
00:04:29,540 --> 00:04:38,160
And the new tool for device identification that passively analyzes traffic and classifies devices using machine learning.

36
00:04:38,960 --> 00:04:46,260
In the pre-exploitation phase, there are amplification sniffer for detecting traffic amplifiers.

37
00:04:46,260 --> 00:04:53,540
Protocol fuzzer in two versions for testing clients and servers.

38
00:04:54,020 --> 00:04:58,720
And known vulnerability tester also in two versions.

39
00:05:00,060 --> 00:05:06,200
Cotopaxi currently supports 10 protocols, three of them were added in this version.

40
00:05:07,000 --> 00:05:17,240
These are advanced message queuing protocol, AMQP, MQTT for sensor networks, and the QUIC protocol.

41
00:05:17,240 --> 00:05:21,060
I will shortly tell about the two of them.

42
00:05:21,260 --> 00:05:30,080
QUIC is the new protocol designed by Google and widely used in their applications and IoT devices.

43
00:05:30,080 --> 00:05:40,440
It is mainly like TCP and TLS in one with support for multiple streams and low latency and connection setup.

44
00:05:40,440 --> 00:05:43,820
And it's also UDP based.

45
00:05:44,240 --> 00:05:47,780
The second of new protocols is MQTT-SN.

46
00:05:47,780 --> 00:05:54,340
This is an UDP clone of the most popular IoT protocol MQTT.

47
00:05:54,400 --> 00:06:02,720
It was designed for sensor networks, what is quite popular in IoT world.

48
00:06:03,620 --> 00:06:10,680
Okay, first and basic tool in the Cotopaxi toolkit is ServicePink.

49
00:06:10,680 --> 00: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.

50
00:06:20,640 --> 00:06:26,800
It uses a set of payloads for each protocol to test endpoints.

51
00:06:26,860 --> 00:06:31,780
And this is an extension of usual port scan using NMAP.

52
00:06:32,680 --> 00:06:35,660
The next tool is ServiceFingerprinter.

53
00:06:35,660 --> 00:06:40,840
This is an equivalent to NMAP, service and application version detection.

54
00:06:40,920 --> 00: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.

55
00:06:55,140 --> 00:06:59,280
And the next tool is used for device identification.

56
00:06:59,280 --> 00:07:01,620
This is a new feature in this version.

57
00:07:01,680 --> 00:07:08,820
It is based on two large corpuses of IoT traffic provided by authors of papers listed on the slide.

58
00:07:09,020 --> 00:07:14,640
After recording sample of traffic, we can classify all devices that were

59
00:07:17,720 --> 00: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.

60
00:07:31,580 --> 00: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.

61
00:07:45,460 --> 00:07:52,000
You need to provide a list of resource names and Cotopaxi will check each of them on the server.

62
00:07:52,200 --> 00:07:59,480
There are some predefined lists for each protocol available in the list's subdirectory.

63
00:08:01,100 --> 00:08:03,360
Next feature is a protocol fuzzer.

64
00:08:03,360 --> 00: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.

65
00:08:19,240 --> 00:08:30,060
Usually, packets processed longer are more interesting for further analysis and mutations, and can be used for next steps of fuzzing.

66
00:08:31,200 --> 00:08:33,900
The next tool is vulnerability tester.

67
00:08:33,900 --> 00:08:43,980
We have five classes of vulnerabilities, information disclosures, crashes, traffic amplifications, memory leaks, and remote code execution.

68
00:08:44,120 --> 00:08:55,760
In this version, we have 10 new vulnerabilities that were added to the database, and in total 34 issues.

69
00:08:56,820 --> 00:09:05,120
Here we can see a sample of vulnerabilities found by us, and that can be identified by Cotopaxi.

70
00:09:05,120 --> 00: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.

71
00:09:26,020 --> 00: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.

72
00:09:43,120 --> 00:09:49,620
Short information how IoT devices can be used to perform distributed denials of service attacks.

73
00:09:49,620 --> 00: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.

74
00:10:07,780 --> 00: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.

75
00:10:22,000 --> 00:10:31,060
So finally, before we start the demo, short information what you can do to start with Cotopaxi.

76
00:10:31,220 --> 00:10:38,120
First, download the tool from the repository, read the manual and install it.

77
00:10:38,120 --> 00: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.

78
00:10:48,700 --> 00:10:55,620
If you find any errors in the toolkit, pre-support it using GitHub issues.

79
00:10:55,920 --> 00:11:01,200
Using the same way, you can contribute new vulnerabilities or new code.

80
00:11:05,540 --> 00:11:13,160
So we can now start using Cotopaxi with the first tool named ServicePink.

81
00:11:13,160 --> 00:11:20,680
As for all the tools in the toolkit, you can use "-h", to receive help.

82
00:11:20,800 --> 00: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.

83
00:11:42,360 --> 00:11:53,220
Similarly for port, you can use single port, multiple ports with a range or with a list with a comma.

84
00:11:58,720 --> 00:12:06,400
We have a test environment here with multiple devices

85
00:12:11,990 --> 00:12:15,530
to test.

86
00:12:15,670 --> 00:12:28,190
For example, port 2000 with one of the available servers.

87
00:12:28,190 --> 00: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.

88
00:12:40,650 --> 00:12:49,890
However, when you use Cotopaxi, you will receive information that the server here is empty.

89
00:12:50,490 --> 00:12:55,250
Similarly for UDP-based

90
00:12:58,710 --> 00:13:02,050
ports, you can also check them

91
00:13:05,430 --> 00:13:13,530
in the pink and we receive information that the server here is co-op.

92
00:13:19,200 --> 00:13:23,520
And the next tool I would like to show you is the ServerPink.enter.

93
00:13:25,120 --> 00:13:30,560
Again, we need to provide the IP address on the port and the protocol.

94
00:13:31,520 --> 00: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.

95
00:13:47,060 --> 00: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.

96
00:14:07,510 --> 00:14:18,600
Okay, we can also check the resource listener.

97
00:14:19,120 --> 00: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.

98
00:14:38,180 --> 00:14:49,790
And for Cotopaxi, there are multiple lists for each of the protocol and they are provided in the folder Cotopaxi lists.

99
00:14:56,990 --> 00:15:06,490
You can see here the results for the following endpoints.

100
00:15:06,490 --> 00:15:11,290
So we're out, advanced, advanced, graded, basic, big, and so on.

101
00:15:11,290 --> 00:15:28,530
And during the testing, the tool also provided calculated amplification factor for each of the URLs.

102
00:15:28,590 --> 00: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.

103
00:15:51,080 --> 00:15:59,980
In the next test, we will use the setup with IoT light bulb connected with the smartphone hub.

104
00:15:59,980 --> 00: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.

105
00:16:19,060 --> 00:16:28,270
Okay, so we will now ping it using Cotopaxi.

106
00:16:33,300 --> 00:16:38,000
You see that it responds to the DTLS protocol.

107
00:16:38,000 --> 00:16:45,700
So we can now start fuzzing using the protocol fuzzer.

108
00:16:48,600 --> 00:16:59,040
So we are using the same IP port and the switch for DTLS protocol.

109
00:17:06,650 --> 00:17:20,170
And what happened here is the Cotopaxi started fuzzing, sent the first packet, the packet was responded.

110
00:17:20,170 --> 00:17:28,750
But with the next packet, the hub crashed.

111
00:17:28,950 --> 00:17:36,290
So Cotopaxi is waiting for the hub to reload.

112
00:17:36,290 --> 00:17:41,830
And after this, it will continue fuzzing with the next payloads.

113
00:17:42,790 --> 00:17:47,510
You can see the lights on the hub.

114
00:17:47,510 --> 00:17:52,170
They are showing the current status of the hub.

115
00:17:52,170 --> 00:17:58,630
When the light gets dark, the hub is going down.

116
00:18:07,260 --> 00:18:13,680
So after each crash, Cotopaxi waits 60 seconds.

117
00:18:13,840 --> 00:18:19,700
And you can see that again the next packet caused again a crash.

118
00:18:23,860 --> 00:18:30,730
And during the crash, the light bulb does not change the color.

119
00:18:34,520 --> 00:18:49,320
The corpus is quite big for DTLS protocol, so that the whole test could take a really long time.

120
00:18:49,320 --> 00:18:58,480
But we can stop it and we will receive information that Cotopaxi found two payloads that caused crash.

121
00:18:58,480 --> 00:19:03,890
And these are the files that are crashing.

122
00:19:05,850 --> 00:19:20,110
We can also use Vulnerability Tester, because we already have the payloads in the database.

123
00:19:20,860 --> 00:19:25,320
Okay, so now we see that the hub is running.

124
00:19:27,120 --> 00:19:29,220
We can check it with ping.

125
00:19:37,510 --> 00:19:41,510
Again, we will see that it responds to DTLS.

126
00:19:44,270 --> 00:19:50,460
And we can now crash it.

127
00:19:52,280 --> 00: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.

128
00:20:19,880 --> 00:20:22,660
And the hub is back again.

129
00:20:25,850 --> 00: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.

130
00:20:36,790 --> 00:20:41,870
We have here a wire shark that will show us the whole traffic.

131
00:20:41,870 --> 00:20:45,420
In this window, we will run the AmplifierDetector.

132
00:20:46,230 --> 00: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.

133
00:20:58,950 --> 00:21:08,530
And now we will first perform service ping to identify whether the server is really responding.

134
00:21:10,550 --> 00:21:14,670
Okay, you can now see the first traffic going in and out.

135
00:21:17,410 --> 00:21:23,010
Currently, the amplification factor is very low.

136
00:21:24,650 --> 00: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.

137
00:21:57,310 --> 00: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.

138
00:22:24,430 --> 00:22:39,410
And when we stop the amplification detector, we will receive again the same packet that was the highest amplification factor.

139
00:22:40,670 --> 00:22:58,710
Also, the resource locator provides us also with information about amplification factor for each of the provided requests and responses.

140
00:23:01,190 --> 00:23:07,630
I have already shown you how to use the standard versions of Protocol Fuzzer and Vulnerability Tester.

141
00:23:07,630 --> 00:23:10,370
Now we used client versions.

142
00:23:11,690 --> 00:23:21,870
Okay, so here we have an implementation of co-op client and here is the Cotopaxi client Protocol Fuzzer.

143
00:23:22,350 --> 00:23:25,210
We will start it.

144
00:23:26,930 --> 00:23:32,690
It will be listening as a server on port 10000.

145
00:23:33,470 --> 00:23:39,190
And now we can start the client.

146
00:23:39,850 --> 00: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.

147
00:24:02,350 --> 00:24:11,910
When we start initiate next transmission, we will receive next payloads.

148
00:24:12,310 --> 00:24:19,110
We can stop it at any time and see how many payloads were sent.

149
00:24:20,250 --> 00:24:23,690
Similarly works the Vulnerability Tester.

150
00:24:24,290 --> 00:24:31,350
It also listens at a particular port.

151
00:24:32,510 --> 00: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.

152
00:24:45,070 --> 00:24:53,790
And finally, after sending all payloads for this protocol, we receive information summary.

153
00:24:55,390 --> 00: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.

154
00:25:14,830 --> 00:25:21,030
The next tool I would like to show you is device identification, which is a new feature in this version.

155
00:25:21,370 --> 00:25:31,950
To use it, you need to provide a pickup file with recorded traffic for the host you would like to test.

156
00:25:32,490 --> 00:25:42,630
You can see here we have an example dump open in Wireshark.

157
00:25:46,010 --> 00: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.

158
00:26:07,570 --> 00:26:12,630
And here you see the results for every IP.

159
00:26:13,850 --> 00:26:31,390
If there is no one distinct class, you will see the whole similar classes with the percentage probability.

160
00:26:31,390 --> 00: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.

161
00:26:54,690 --> 00:27:06,570
Okay, now we can click ctrl-c to break loading and you can see the classification results.

162
00:27:11,810 --> 00:27:27,790
And finally, we can just select one IP address, one device to be classified using option minus i.

163
00:27:36,550 --> 00:27:49,670
And in this case, after loading packets, we can see only results of classification for this one selected device.

164
00:27:53,020 --> 00:28:00,140
Currently, the device identification tool supports around 55 devices.

165
00:28:00,140 --> 00: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.

166
00:28:19,340 --> 00: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.

167
00:28:37,670 --> 00:28:40,870
Thank you for watching the presentation and demo.

168
00:28:40,870 --> 00:28:47,970
If you have any questions, please ask them using the DEF CON chat.

169
00:28:47,970 --> 00:28:49,110
Thank you!