1
00:00:00,000 --> 00:00:04,180
You've been with the Packet Hacking Village and the Speaker Workshop before.

2
00:00:04,820 --> 00:00:14,660
As I said, this is the fifth anniversary of the Speaker Workshop at the Packet Hacking Village.

3
00:00:15,120 --> 00:00:16,900
And I think you've spoken at all five.

4
00:00:17,360 --> 00:00:18,920
I think you've spoken at all five.

5
00:00:19,020 --> 00:00:21,020
I know you were out missing once.

6
00:00:22,040 --> 00:00:25,680
Like an old friend of ours.

7
00:00:26,880 --> 00:00:29,280
And you've given quite a few talks.

8
00:00:30,000 --> 00:00:39,320
And so it feels for me, it just feels like for me, not only the annual tradition to come here to DEF CON and the Packet Hacking Village,

9
00:00:39,600 --> 00:00:43,460
but also to give an introduction to both Chet Hosmer and Mike Grego.

10
00:00:46,060 --> 00:00:46,820
Thanks, Ming.

11
00:00:46,920 --> 00:00:47,640
Thanks for having us.

12
00:00:48,780 --> 00:00:50,500
I'm going to let Chet kick things off.

13
00:00:50,840 --> 00:00:51,280
Great.

14
00:00:51,380 --> 00:00:52,120
Thanks, Mike.

15
00:00:52,300 --> 00:00:53,140
Hey, welcome, everybody.

16
00:00:53,640 --> 00:00:56,440
We're going to talk about covert TCP with a twist today.

17
00:00:56,620 --> 00:00:59,600
Give you a little history about this, which is really kind of interesting,

18
00:00:59,600 --> 00:01:02,880
because we've come 20 years from the history that I'm going to talk about,

19
00:01:02,960 --> 00:01:04,740
and we're no better off than we were 20 years ago.

20
00:01:05,160 --> 00:01:09,020
So hopefully we can work together to correct that problem.

21
00:01:09,220 --> 00:01:10,400
Can you guys hear me okay in the back?

22
00:01:10,500 --> 00:01:11,040
Everything good?

23
00:01:11,200 --> 00:01:11,540
Okay.

24
00:01:11,780 --> 00:01:12,180
No?

25
00:01:14,780 --> 00:01:15,780
How about that?

26
00:01:16,360 --> 00:01:17,180
Yeah, that better?

27
00:01:17,360 --> 00:01:17,960
All right, good.

28
00:01:18,400 --> 00:01:20,240
So anyway, welcome.

29
00:01:21,140 --> 00:01:25,980
Mike and I have done this talk together, similar talks together for quite some time,

30
00:01:26,040 --> 00:01:27,680
so hopefully you guys will enjoy this.

31
00:01:27,900 --> 00:01:28,980
Just a quick introduction.

32
00:01:29,600 --> 00:01:30,720
Mike will do one for him as well.

33
00:01:31,200 --> 00:01:33,700
We've been working on the area of secondography and data hiding,

34
00:01:33,780 --> 00:01:37,640
I have, for over 20 years now, before anybody even knew what it was.

35
00:01:38,600 --> 00:01:44,220
And was working with the Air Force Research Lab back in the mid-1990s,

36
00:01:44,240 --> 00:01:47,040
and there were two groups at the Air Force Research Lab.

37
00:01:47,200 --> 00:01:49,520
There was the Offensive Information Warfare Branch

38
00:01:49,520 --> 00:01:51,840
and the Defensive Information Warfare Branch.

39
00:01:52,000 --> 00:01:53,540
I worked on the defensive side,

40
00:01:53,640 --> 00:01:56,020
and we first started looking at secondography and data hiding.

41
00:01:56,460 --> 00:01:59,240
My first course of action was to go steal the best guy,

42
00:01:59,600 --> 00:02:01,100
that was on the offensive side,

43
00:02:01,220 --> 00:02:03,640
and have him come and work for us on the defensive side.

44
00:02:04,140 --> 00:02:06,540
And really start to look at how we're going to actually detect,

45
00:02:08,560 --> 00:02:11,240
disrupt this kind of activity that's out there.

46
00:02:11,560 --> 00:02:15,360
And since then, Mike and I wrote the book, Data Hiding, a couple years ago, together.

47
00:02:16,000 --> 00:02:20,220
Mike kicked it off and brought me into that so we could actually share the book,

48
00:02:20,340 --> 00:02:22,700
and it's been really, really popular out there as well.

49
00:02:22,800 --> 00:02:25,260
And since then, I've written several, and Mike has written several as well.

50
00:02:25,360 --> 00:02:29,240
So I also teach in the Cybersecurity Graduate Program at Utica College,

51
00:02:29,600 --> 00:02:32,900
and I teach in the Digital Forensic Graduate Program at Champlain College.

52
00:02:33,080 --> 00:02:36,780
So if any of those folks, and sometimes there's folks in the audience from my classes,

53
00:02:36,820 --> 00:02:40,180
if you are, welcome from that perspective.

54
00:02:40,320 --> 00:02:42,020
Let me turn it over to Mike to have him introduce himself,

55
00:02:42,200 --> 00:02:43,220
and then we'll kick this off.

56
00:02:44,420 --> 00:02:45,400
Awesome. Thanks, Chet.

57
00:02:46,340 --> 00:02:51,140
So my background, while not nearly as many years as Chet,

58
00:02:55,080 --> 00:02:58,380
I've been focusing on Stego as well for quite some time,

59
00:02:58,420 --> 00:02:59,580
I think about 17 or 18 years.

60
00:02:59,600 --> 00:03:03,420
I was really inspired by it kind of organically,

61
00:03:03,900 --> 00:03:06,300
and soon after had actually met Chet,

62
00:03:06,440 --> 00:03:09,340
and we've shared research and ideas ever since then,

63
00:03:09,380 --> 00:03:10,460
and collaborate quite a bit.

64
00:03:11,960 --> 00:03:14,540
Currently work for a company now, 802 Secure.

65
00:03:14,600 --> 00:03:16,580
We focus on IOT security,

66
00:03:17,360 --> 00:03:21,640
and so a lot of the current testing involves an IOT lab,

67
00:03:21,800 --> 00:03:24,140
where we do a lot of analysis, reverse engineering,

68
00:03:24,320 --> 00:03:25,660
and some of that will be incorporated

69
00:03:25,660 --> 00:03:27,140
in what we're covering today.

70
00:03:27,840 --> 00:03:28,360
Furthermore,

71
00:03:29,600 --> 00:03:30,640
along the Stego front,

72
00:03:31,360 --> 00:03:35,080
just got out of a talk that we did in track four

73
00:03:35,570 --> 00:03:38,660
on deep neural networks for social Stego,

74
00:03:38,860 --> 00:03:42,360
so leveraging social media for covert communications,

75
00:03:43,090 --> 00:03:45,020
as well as ML for automating that

76
00:03:45,020 --> 00:03:46,960
from an offensive ethical standpoint.

77
00:03:47,680 --> 00:03:52,440
And then something else, having spoken at DEF CON 12,

78
00:03:53,420 --> 00:03:55,420
released a tool called StegSpy,

79
00:03:55,660 --> 00:03:58,200
whereby the idea behind it was to kind of take

80
00:03:58,200 --> 00:03:59,440
a little bit of a different approach,

81
00:03:59,600 --> 00:04:03,460
to Steg analysis in identifying hidden content,

82
00:04:03,700 --> 00:04:06,900
by saying, well, with all the really cool things

83
00:04:06,900 --> 00:04:10,040
that even Chet and his company were doing at the time,

84
00:04:10,120 --> 00:04:12,660
is there a way you can go about fingerprinting

85
00:04:12,660 --> 00:04:15,500
the actual applications that are being used

86
00:04:15,500 --> 00:04:16,940
to perform this Steganography?

87
00:04:17,200 --> 00:04:19,480
And having mapped that and fingerprinted that,

88
00:04:19,620 --> 00:04:21,320
understanding what kind of fingerprints,

89
00:04:21,800 --> 00:04:24,440
or remnants that they would leave behind in the image,

90
00:04:24,540 --> 00:04:27,040
and look more for images that had evidence

91
00:04:27,040 --> 00:04:29,400
of a tool being used to hide the data,

92
00:04:29,400 --> 00:04:34,880
data rather than looking for the hidden data itself. So we can go ahead and jump into it.

93
00:04:34,920 --> 00:04:45,040
I think Chet has the first part. Thanks, Mike. So back in 1997 when we were starting to really

94
00:04:45,040 --> 00:04:50,200
get into looking at steganography and how it was going to affect, I read this article written

95
00:04:50,200 --> 00:04:57,600
by Craig Rowland in First Monday, the Hacker Publication. It was published on May 5th, 1997.

96
00:04:57,600 --> 00:05:02,860
So Cinco de Mayo, 1997. Can't forget that date. There's a link here in the brief that you can

97
00:05:02,860 --> 00:05:06,900
go get the actual article that Craig wrote. I want to kind of walk you through what he talked

98
00:05:06,900 --> 00:05:12,840
about then. Is Craig in the room, by the way? Did he come? No. Too bad. Anyway, I met him once a

99
00:05:12,840 --> 00:05:18,340
long time ago. Really interesting guy. So anyway, the concept was, it really intrigued me

100
00:05:18,340 --> 00:05:22,260
because we were looking at steganography from the perspective of hiding information in images,

101
00:05:22,600 --> 00:05:27,140
audio files, videos, that kind of thing. And what Craig did was he kind of broke the ground

102
00:05:27,140 --> 00:05:32,000
in looking at this from a covert communication perspective and actually being able to hide

103
00:05:32,000 --> 00:05:36,500
information in protocol streams. And we're going to talk about that today. So that's kind of just

104
00:05:36,500 --> 00:05:41,600
the kickoff of this. So just kind of a quick definition that came out of the 1985 Orange Book

105
00:05:41,600 --> 00:05:47,080
from the Department of Defense to define what corporate communication actually is. It's any

106
00:05:47,080 --> 00:05:52,000
communication channel that can be exploited by a process to transfer information in a manner that

107
00:05:52,000 --> 00:05:56,600
violates the system security policy. So basically the concept is I want to be able to leak

108
00:05:56,600 --> 00:06:00,380
information out of the organization. I want to be able to communicate with people without anybody

109
00:06:00,380 --> 00:06:06,220
knowing. So again, just to find the difference between encryption and steganography, encryption is

110
00:06:06,220 --> 00:06:11,960
all about keeping information private so that only those that contain the key, hold the keys, can

111
00:06:11,960 --> 00:06:16,520
actually decipher the information unless you have a lot of time in big computers, right? The

112
00:06:16,520 --> 00:06:23,660
purpose behind steganography is to hide the mere existence of the message, right? So very

113
00:06:23,660 --> 00:06:26,580
different concept of what we're trying to do in steganography. It's a very different concept than the

114
00:06:26,600 --> 00:06:30,420
steganography versus what we're doing in encryption, right? Kind of much more dangerous from that

115
00:06:30,420 --> 00:06:37,540
perspective and you can kind of see the idea behind that. So in Craig's original article, he

116
00:06:37,540 --> 00:06:43,440
basically had three different methods that he actually defined on how we could do this using the

117
00:06:43,440 --> 00:06:48,660
TCPIP protocol. How could we actually hide information in these protocols? And as I

118
00:06:48,660 --> 00:06:56,580
mentioned at the outset of this, most data structures, most protocols, most file structures, most

119
00:06:56,600 --> 00:07:02,860
have this limitation where there is no concept of being able to prevent the data structure or the

120
00:07:02,860 --> 00:07:08,780
protocol from carrying illicit information. It's not part of the thought process of those folks that

121
00:07:08,780 --> 00:07:17,100
are building that. Last year Mike and I spoke about the MP3 ID3 header and the vast amount of

122
00:07:17,100 --> 00:07:20,760
information that I can hide in that and transfer data and we showed how you could actually post

123
00:07:21,360 --> 00:07:26,580
music on popular websites and actually have that information included in the download. So that's a

124
00:07:26,580 --> 00:07:31,760
way that I can covertly communicate that way. So this has kind of come a long way but let's talk

125
00:07:31,760 --> 00:07:38,680
about the three different methods that Craig had defined. The first couple are fairly simple but

126
00:07:38,680 --> 00:07:43,140
kind of interesting and they still stick today. I have a lot of friends that work for defense

127
00:07:43,140 --> 00:07:48,060
contractors, big banks and that kind of stuff and I do this to them all the time to see if their

128
00:07:48,060 --> 00:07:56,100
defenses can detect any of this and they never can. So the first thing is this is what the TCPIP

129
00:07:56,100 --> 00:08:01,500
packet header looks like and by the way everything I'm going to talk about works with IPV4 and IPV6 so

130
00:08:01,500 --> 00:08:06,180
there's no difference. The same vulnerability exists. We didn't fix any of these problems when we

131
00:08:06,180 --> 00:08:12,260
went to the later version of IP. So we're going to talk about the identification field within the

132
00:08:12,260 --> 00:08:18,160
IP header. We're going to talk about the sequence numbers and the acknowledgment numbers that

133
00:08:18,160 --> 00:08:23,560
exist in the TCP packet for structure. Mike's going to talk a lot about wireless and a bunch of

134
00:08:23,560 --> 00:08:26,080
other stuff as well. But I'm going to focus just a little bit more on the TCPIP packet header and the

135
00:08:26,100 --> 00:08:30,100
same thing that Craig talked about originally so you can kind of see how we can actually use that

136
00:08:30,100 --> 00:08:37,380
same technique today in order to leak information. So the basic concept is pretty simple. We want to

137
00:08:37,380 --> 00:08:44,620
be able to use fields within the TCPIP header to convey information. And since these are standard

138
00:08:44,620 --> 00:08:50,080
protocols that you have to obey, these fields must be there, right? This information has to be part

139
00:08:50,080 --> 00:08:53,880
of the header in order to be able to send this out, whether it's in the IP header or whether it's

140
00:08:53,880 --> 00:08:56,080
in the TCP header. So basically, you leak information and then you send it to the TCPIP header. So

141
00:08:56,080 --> 00:09:01,920
looking at this information, we're looking for areas within those headers where we could actually

142
00:09:01,920 --> 00:09:08,700
hide information within those. So let's take a look at that. The first one we're going to look at is

143
00:09:08,700 --> 00:09:14,800
the identification field. So the identification field in the IP header is specifically used so that if

144
00:09:15,300 --> 00:09:20,520
let's say that I'm transmitting a packet, an IP packet, and it has to be broken down, right? It has

145
00:09:20,520 --> 00:09:26,060
to actually be fragmented. So that's the identification field. So the identification field in the IP

146
00:09:26,080 --> 00:09:27,060
header is basically used to provide information to the packet. So that packet would have to be

147
00:09:27,060 --> 00:09:33,300
fragmented. So the ID field is there so that if the packet becomes fragmented, we can put the pieces of

148
00:09:33,300 --> 00:09:38,160
the packet back together. So the ID field is used to basically provide a number so we know the

149
00:09:38,160 --> 00:09:44,240
sequence of the packet as if it was broken down. Today, this rarely happens, especially with smaller

150
00:09:44,240 --> 00:09:49,880
packets. They're typically not fragmented, so we can actually use that field as is to put any

151
00:09:49,880 --> 00:09:56,060
information in it that we want. So if I'm the sender of this particular packet, I can really

152
00:09:56,080 --> 00:10:05,320
replace the identification field with data. For example, I might put a value. It's a 16-bit number, so I

153
00:10:05,320 --> 00:10:10,040
could put a value in there, and then Mike could have a constant that we're going to divide by. So I

154
00:10:10,040 --> 00:10:13,860
can basically put a number, divide it by a constant, and then Mike will get the letter that I'm

155
00:10:13,860 --> 00:10:19,660
going to transfer in that particular field. So that's the first example. Really simple, just using

156
00:10:19,660 --> 00:10:25,140
the identification field in order to be able to do that. So as an example, this is what it would look

157
00:10:26,080 --> 00:10:31,680
like. Basically, I'm going to send this identification field that is here. The number you can see is

158
00:10:31,680 --> 00:10:39,420
17-152 is what I put in there. If I have a constant of 256, it gives me the number 67. So converting

159
00:10:39,420 --> 00:10:46,160
67 from ASCII to a letter is the letter C. So by just basically putting that value in the

160
00:10:46,160 --> 00:10:51,200
identification field, I've transferred the letter C to Mike. He's going to receive the message.

161
00:10:51,500 --> 00:10:55,700
Okay? Real simple. You've got to do a lot of these in order to be able to pass a message, or you

162
00:10:55,700 --> 00:10:58,580
could have some kind of code book for this. If we want to do this with a twist, I could use a

163
00:10:58,580 --> 00:11:03,280
code book, right? I could have standard messages that I want to communicate, and basically it could

164
00:11:03,280 --> 00:11:07,540
just be an index into that standard message. So now I can, from within an organization, I can

165
00:11:07,540 --> 00:11:13,100
basically push out information by just encoding information in that single field that I want to do

166
00:11:13,100 --> 00:11:21,160
it. So this is the simplest form that Craig talked about. So let's move to the next one. This is

167
00:11:21,160 --> 00:11:25,680
the manipulation of the initial sequence number. This is one that probably has been most used in

168
00:11:25,700 --> 00:11:29,240
talked about. I actually think the third method is really more

169
00:11:29,240 --> 00:11:33,140
interesting. But what this is, is that whenever we establish a

170
00:11:33,140 --> 00:11:36,700
TCP connection, we have to basically provide an initial

171
00:11:36,700 --> 00:11:39,900
sequence number. This kind of goes back in the history with

172
00:11:39,900 --> 00:11:43,140
the Robert Morris attack where the initial sequence number

173
00:11:43,680 --> 00:11:47,080
wasn't random. So in this case, the initiator of the

174
00:11:47,080 --> 00:11:50,060
communication, which typically is the client, is going to define

175
00:11:50,060 --> 00:11:53,180
this initial sequence number so that the server can respond with

176
00:11:53,180 --> 00:11:55,720
an acknowledgment of that sequence number, and now the

177
00:11:55,720 --> 00:12:00,200
sequence numbers will increment by one for every packet. But

178
00:12:00,200 --> 00:12:05,940
since we get to choose what that sequence number is, the same as

179
00:12:05,940 --> 00:12:07,580
we could choose whatever we wanted to put in the

180
00:12:07,580 --> 00:12:11,400
identification field, we can actually use that value in order

181
00:12:11,400 --> 00:12:15,660
to be able to convey information. In a similar manner that we did

182
00:12:15,660 --> 00:12:18,180
now, remember this is a bigger field, so this is a 32-bit

183
00:12:18,180 --> 00:12:21,660
number, so we could actually transmit a byte, a word, a

184
00:12:21,660 --> 00:12:22,820
double word, a quad word.

185
00:12:27,100 --> 00:12:31,500
So that's how this one works. So basically, the way this works,

186
00:12:31,560 --> 00:12:36,120
if I just take an example packet, this is what that TCP header

187
00:12:36,120 --> 00:12:39,660
would look like. If I extract the information from the header,

188
00:12:39,800 --> 00:12:42,420
we can see what the initial sequence number looks like down

189
00:12:42,420 --> 00:12:46,860
here. Again, it's a very large number, 32 bits in length, that

190
00:12:46,860 --> 00:12:49,100
we could encode anything we want into that initial sequence

191
00:12:49,100 --> 00:12:53,160
number. So if I take that to the next level and I extract the

192
00:12:53,180 --> 00:12:57,380
sequence number, and again, in this case, I've chosen a divisor,

193
00:12:57,380 --> 00:13:00,120
something that I want to divide that number by to actually convey

194
00:13:00,120 --> 00:13:03,160
the information. Now this looks really simple because once you

195
00:13:03,160 --> 00:13:05,860
figure this out, you can see what the message is. But clearly

196
00:13:05,860 --> 00:13:10,220
what we do is change the divisor for every sequence number that

197
00:13:10,220 --> 00:13:13,660
we send, so that you don't know what it's going to be. Mike has

198
00:13:13,660 --> 00:13:16,500
the code book so he knows what it's going to be. In this case,

199
00:13:16,500 --> 00:13:20,000
it will convert that to the letter H by dividing those two

200
00:13:20,000 --> 00:13:23,160
numbers. So all we have to do ahead of time is exchange the

201
00:13:23,180 --> 00:13:26,680
fact that I want to be able to communicate this, and all we have

202
00:13:26,680 --> 00:13:29,620
to do is have what the divisor or the method is to communicate.

203
00:13:29,980 --> 00:13:32,160
So that's pretty cool. Very similar to the identification

204
00:13:32,160 --> 00:13:37,380
field, we do this. Do we defend against this today? No. Nobody

205
00:13:37,380 --> 00:13:40,640
looks at the initial sequence number in order to be able to do

206
00:13:40,640 --> 00:13:43,880
this. The third method is really interesting because it can

207
00:13:43,880 --> 00:13:48,700
actually hide the identity of the sender and of the receiver.

208
00:13:48,920 --> 00:13:52,040
So let's talk about the third method, which I think is the most

209
00:13:52,040 --> 00:13:53,160
interesting one that we're going to talk about today. The third

210
00:13:53,180 --> 00:13:55,960
method is the method that Craig defined. And I just did an

211
00:13:55,960 --> 00:14:00,340
experiment with this last week to see if I could actually do this

212
00:14:00,340 --> 00:14:05,980
off popular servers and it works really good. So method three, the

213
00:14:05,980 --> 00:14:09,900
concept is that I want to expand on method two and actually on

214
00:14:09,900 --> 00:14:12,940
method one a little bit. And what we're going to do is we're

215
00:14:12,940 --> 00:14:18,400
going to have the, I want these two clients to be able to

216
00:14:18,400 --> 00:14:20,760
communicate with each other. Okay? And I want them to be able

217
00:14:20,760 --> 00:14:22,420
to do this fairly anonymously.

218
00:14:23,180 --> 00:14:26,280
So I don't know who the sender or the receiver is of the packets

219
00:14:26,280 --> 00:14:29,480
that we're going to exchange. So this is a little bit more difficult

220
00:14:29,480 --> 00:14:31,960
to do and we're going to use this method called the bounce

221
00:14:31,960 --> 00:14:36,480
method. So what we're going to do is we're going to send a

222
00:14:36,480 --> 00:14:39,680
request to a server, basically that same SYN packet that we

223
00:14:39,680 --> 00:14:43,020
talked about in the previous example. But I'm going to spoof

224
00:14:43,020 --> 00:14:47,460
the IP address of the sender. And I'm going to have the IP

225
00:14:47,460 --> 00:14:53,000
address be of where I really want the response to go. Okay? So I've

226
00:14:53,000 --> 00:14:55,340
got these two people that want to communicate. I've got the

227
00:14:55,340 --> 00:14:59,160
sender and the receiver. And the sender knows the IP address of

228
00:14:59,160 --> 00:15:02,960
the receiver. So when it basically sends the packet to

229
00:15:02,960 --> 00:15:06,300
the first server, it's going to bounce off that server and it's

230
00:15:06,300 --> 00:15:10,400
going to go to the, to the second client because I've spoofed

231
00:15:10,400 --> 00:15:14,340
that IP address. The second client's not going to respond to

232
00:15:14,340 --> 00:15:17,580
that. But he has the initial sequence number because it comes

233
00:15:17,580 --> 00:15:21,360
as the acknowledgement from the server. Comes in that packet. And

234
00:15:21,360 --> 00:15:22,980
since it does, he has the IP address of the sender and the

235
00:15:23,000 --> 00:15:27,040
response as that piece of data. So now you might say, well, that's

236
00:15:27,040 --> 00:15:29,080
kind of interesting. So let's take a look at how this actually

237
00:15:29,080 --> 00:15:34,120
works. So basically what happens is client one sends the SYN

238
00:15:34,120 --> 00:15:36,840
packet to let's say a server out there on the internet

239
00:15:36,840 --> 00:15:40,980
someplace. With the encoded information in the initial

240
00:15:40,980 --> 00:15:45,260
sequence number. But because it spoofed the IP address of the

241
00:15:45,260 --> 00:15:48,560
sender, the response or the acknowledgement is actually

242
00:15:48,560 --> 00:15:51,620
going to go to client number two. Okay? Just as I kind of

243
00:15:51,620 --> 00:15:52,920
talked about. Included.

244
00:15:53,000 --> 00:15:56,460
The encoded initial sequence number. Which again, using the

245
00:15:56,460 --> 00:15:58,800
method that I talked about earlier, you can just divide

246
00:15:58,800 --> 00:16:01,600
that and get the actual data out of that. You can use multiple

247
00:16:01,600 --> 00:16:07,220
methods in making that happen. So now we've actually sent

248
00:16:07,220 --> 00:16:11,920
information from client one to client two using that method.

249
00:16:12,300 --> 00:16:16,840
Now we've sort of masked who the sender and the receiver is.

250
00:16:17,020 --> 00:16:19,400
But you might say, well, wait a minute. The server's going to

251
00:16:19,400 --> 00:16:22,980
know where that request came from and where the response is.

252
00:16:23,000 --> 00:16:25,780
Where it went to. Right? Not going to know the sender, but

253
00:16:25,780 --> 00:16:28,320
it's going to know where the response is supposed to go. So

254
00:16:28,320 --> 00:16:31,800
it could track that. Well, you don't have to use the same

255
00:16:31,800 --> 00:16:36,520
server every time. Right? I could pick 1,000 servers out on

256
00:16:36,520 --> 00:16:40,320
the internet and send each one a single SYN packet and have the

257
00:16:40,320 --> 00:16:44,820
response go to the client. So now I've got these 1,000 servers

258
00:16:44,820 --> 00:16:47,140
out there that are going to respond to this. And this

259
00:16:47,140 --> 00:16:50,320
happens all the time. The packet's going to be dropped. But

260
00:16:50,320 --> 00:16:52,860
now I can bounce this off thousands of servers so that

261
00:16:53,000 --> 00:16:57,040
now I can't even identify who the recipient is because the

262
00:16:57,040 --> 00:16:59,720
recipient is different for each of the servers that we have. Does

263
00:16:59,720 --> 00:17:02,960
that make sense? Everybody kind of understand it? So basically

264
00:17:02,960 --> 00:17:07,240
the bounce method really kind of extends this attack to the

265
00:17:07,240 --> 00:17:10,300
level where now I can really hide the identity of the sender,

266
00:17:10,360 --> 00:17:13,800
which I could always do even if it was only to one server. But

267
00:17:13,800 --> 00:17:17,780
now I can hide or mask the identity of the receiver of the

268
00:17:17,780 --> 00:17:20,420
message because it's going to come from 1,000 different

269
00:17:20,420 --> 00:17:22,880
servers if I want to send a message that's of the

270
00:17:22,880 --> 00:17:22,980
local server. So now I can hide or mask the identity of the

271
00:17:23,000 --> 00:17:25,040
link 1,000 bytes. I've just got to pick 1,000 different

272
00:17:25,040 --> 00:17:28,360
servers to do this. And I did this with Google and Amazon at a

273
00:17:28,360 --> 00:17:31,220
bunch of places last week just to see if they would actually

274
00:17:31,220 --> 00:17:34,500
recognize the fact that I bounced this SYN packet off it

275
00:17:34,500 --> 00:17:36,560
and received it on this other client. It works perfectly.

276
00:17:36,720 --> 00:17:40,860
Nobody cares. Right. So 20 years and a few months later,

277
00:17:41,580 --> 00:17:48,500
the methods that Craig had defined really work today. We

278
00:17:48,500 --> 00:17:52,980
haven't improved the design of our protocols. We haven't

279
00:17:52,980 --> 00:17:56,800
secured either IP or TCP in order to be able to prevent this

280
00:17:56,800 --> 00:18:00,520
from happening. And we can communicate small pieces of

281
00:18:00,520 --> 00:18:03,100
information or large pieces of information, depending on how

282
00:18:03,100 --> 00:18:05,700
sophisticated we are. We'll talk about some more

283
00:18:05,700 --> 00:18:09,820
sophisticated pieces of this as we go forward in the talk. I'm

284
00:18:09,820 --> 00:18:12,060
going to talk about a couple and Mike will talk about some as

285
00:18:12,060 --> 00:18:16,020
well. But to just kind of set the stage that we've gone 20

286
00:18:16,020 --> 00:18:20,400
years and this has been a very public information about the

287
00:18:21,040 --> 00:18:22,960
methods that Craig had defined. And we're going to talk about

288
00:18:22,960 --> 00:18:24,800
some of the things that Craig had defined 20 years ago. And we're

289
00:18:24,800 --> 00:18:27,840
no better off. Because we tend to be chasing the shiny object.

290
00:18:28,540 --> 00:18:31,940
We don't actually focus on fundamentals of our protocols,

291
00:18:32,140 --> 00:18:34,860
of our data structures, of our file structures in order to

292
00:18:34,860 --> 00:18:37,920
prevent this kind of leakage of information. We tend to be

293
00:18:37,920 --> 00:18:41,000
focused on things that are kind of outside. What is the latest

294
00:18:41,000 --> 00:18:43,840
attack that we have? What is the thing that's going on? And we

295
00:18:43,840 --> 00:18:46,560
don't go back and look at the fundamentals that we're trying to

296
00:18:46,560 --> 00:18:50,720
protect against in order to do this. So just that's my soapbox

297
00:18:50,720 --> 00:18:51,200
for the day.

298
00:18:52,960 --> 00:18:55,220
I'm going to turn this back over to Mike who's going to talk

299
00:18:55,220 --> 00:18:59,560
about UDP and IOT and how those didn't get any better either.

300
00:18:59,980 --> 00:19:02,020
Even though we were able to create these brand new

301
00:19:02,020 --> 00:19:03,980
protocols and brand new techniques in order to

302
00:19:03,980 --> 00:19:08,020
communicate with these devices, we actually may be worse off,

303
00:19:08,080 --> 00:19:08,300
right?

304
00:19:10,120 --> 00:19:16,000
Great. Thanks, Chet. So as of late, I've been doing a lot of

305
00:19:16,000 --> 00:19:20,680
testing and modeling in an IOT lab I have at home. And when

306
00:19:20,680 --> 00:19:22,940
Chet came up with this idea, I was like, well, I'm going to do

307
00:19:22,940 --> 00:19:23,520
this. And I was like, well, I think it's a good idea for this

308
00:19:23,520 --> 00:19:27,120
talk. I said, gee, you know, I think that could be a good

309
00:19:27,120 --> 00:19:29,920
launch pad and make a nice addition that would be very

310
00:19:29,920 --> 00:19:32,500
complementary to what you're going to, what he's speaking

311
00:19:32,500 --> 00:19:40,580
about in terms of TCP and reveal this from a UDP standpoint. In

312
00:19:40,580 --> 00:19:44,600
terms of IOT, we've seen numerous articles about the

313
00:19:44,600 --> 00:19:50,360
inherent and lack of fundamental security across IOT, both within

314
00:19:50,360 --> 00:19:52,920
the devices as well as how they communicate and how it's

315
00:19:52,920 --> 00:19:57,640
communicate. And to that end, a lot of these devices support

316
00:19:57,640 --> 00:20:03,120
UPMP or more specifically SSDP. And this allows you to have an

317
00:20:03,120 --> 00:20:06,940
app that discovers a new device on the network, maybe even

318
00:20:06,940 --> 00:20:11,260
configure it, even allow devices to speak to one another or

319
00:20:11,260 --> 00:20:15,080
machine to machine, if you will. And how a lot of this

320
00:20:15,080 --> 00:20:19,060
communication is performed is believed to be maintained

321
00:20:19,060 --> 00:20:23,500
locally on the network through use of multicast broadcasted

322
00:20:23,500 --> 00:20:31,500
packets on the local network. So I said, you know, UPMP has been

323
00:20:31,500 --> 00:20:35,040
around for a long time as well, right? Microsoft has been around

324
00:20:35,040 --> 00:20:38,720
for numerous years. Yet again, we're probably not any better

325
00:20:38,720 --> 00:20:42,320
off with UPMP than we were when Microsoft first released it,

326
00:20:42,360 --> 00:20:47,440
right? And now it's been adopted as part of IOT. And in

327
00:20:47,440 --> 00:20:49,040
addition to that, it also has been adopted as part of the

328
00:20:51,080 --> 00:20:56,020
IPv6 with all the backward compatibilities as well. But in

329
00:20:56,020 --> 00:20:59,840
terms of what I like to call stupid, simple discovery

330
00:20:59,840 --> 00:21:02,820
protocol or really simple service discovery protocol,

331
00:21:03,560 --> 00:21:07,680
being a component of UPMP, you have a variety of packets that

332
00:21:07,680 --> 00:21:11,540
are leveraged in terms of identifying these devices on the

333
00:21:11,540 --> 00:21:14,880
network or those devices advertising themselves on the

334
00:21:14,880 --> 00:21:18,780
network. So everybody can find one another. MSerch, for

335
00:21:18,780 --> 00:21:19,040
example, is a very popular service. It's a very popular

336
00:21:19,060 --> 00:21:22,560
service. For example, is a discovery packet. It can be sent

337
00:21:22,560 --> 00:21:24,860
by an app, can be sent by a device to go out there and

338
00:21:24,860 --> 00:21:27,960
discover the IOT devices. And then furthermore, there's

339
00:21:27,960 --> 00:21:32,080
another type of packet called a notify packet. Typically devices

340
00:21:32,080 --> 00:21:37,140
who have employed this SSDP type capability will wake up from time

341
00:21:37,140 --> 00:21:40,140
to time and typically on a regular frequency advertise

342
00:21:40,140 --> 00:21:48,120
themselves. Peeling the onion back a little bit further, what

343
00:21:48,120 --> 00:21:49,040
are the characteristics of a notification packet? Well, the

344
00:21:49,040 --> 00:21:52,020
features and characteristics of these packets. There is what's

345
00:21:52,020 --> 00:21:58,380
called a ULA OPT field. This is for unique local addresses and

346
00:21:58,380 --> 00:22:03,140
site routable. But specifically, the OPT value within that

347
00:22:03,140 --> 00:22:08,020
carries a URL, which is an optional field, I believe hence

348
00:22:08,020 --> 00:22:13,000
the OPT label within the packets, but in addition, is used

349
00:22:13,000 --> 00:22:17,860
within both notify and MSerch messages. The interesting thing is

350
00:22:17,860 --> 00:22:22,780
that supported not only an IPv4 but IPv6 for backward

351
00:22:22,780 --> 00:22:30,000
compatibility. So I said to what extent could this be used for

352
00:22:30,000 --> 00:22:33,860
communicating covertly? Is this a free form field? Is this a

353
00:22:33,860 --> 00:22:38,460
field that is used by the vendor of the IOT device to basically

354
00:22:38,460 --> 00:22:43,520
define characteristics about the actual IOT device? So we've

355
00:22:43,520 --> 00:22:46,100
got the IP address, there are serial numbers, other things

356
00:22:46,100 --> 00:22:49,280
that are embedded within these types of packets but in addition

357
00:22:49,280 --> 00:22:54,820
to that this OPT field usually carries a standard URL that

358
00:22:54,820 --> 00:22:58,740
really points back to the schema or more importantly the

359
00:22:58,740 --> 00:23:02,700
information about UPnP. So in the spec there's kind of limited

360
00:23:02,700 --> 00:23:06,840
information about it but I said you know in playing around with

361
00:23:06,840 --> 00:23:09,280
all these different fields this was almost like a free form

362
00:23:09,280 --> 00:23:12,880
field. You could put a different URL in here that might

363
00:23:12,880 --> 00:23:16,080
point to command and control. First of all you could put a

364
00:23:16,100 --> 00:23:17,300
different URL in here. Furthermore it doesn't even have

365
00:23:17,300 --> 00:23:20,280
to be a URL. So you can go in here and put any kind of text,

366
00:23:20,420 --> 00:23:27,000
any type of content, clear text or cyphered within this field. So

367
00:23:27,000 --> 00:23:30,460
that's exactly what I did to see to what extent this would be

368
00:23:30,460 --> 00:23:34,540
communicated across the network and successfully received by the

369
00:23:34,540 --> 00:23:38,260
actual intended recipient. Or furthermore if it's broadcasted

370
00:23:38,260 --> 00:23:40,760
to all the devices on the network. And it worked

371
00:23:40,760 --> 00:23:43,620
completely successfully, no issues whatsoever. And

372
00:23:43,620 --> 00:23:45,840
certainly could be a method by which you could communicate

373
00:23:46,100 --> 00:23:51,320
covertly using UDP in what would arguably maybe be a

374
00:23:51,320 --> 00:23:53,740
different technique but similar to what you're trying to

375
00:23:53,740 --> 00:23:59,060
accomplish with TCP. So it also makes for a great dead drop. So

376
00:23:59,060 --> 00:24:01,040
you could just you know if you're communicating this

377
00:24:01,040 --> 00:24:04,480
covertly and it does harbor a URL that could point to

378
00:24:04,480 --> 00:24:07,920
something benign like a WordPress site or even a link on

379
00:24:07,920 --> 00:24:10,980
social media where an image might reside with hidden content

380
00:24:10,980 --> 00:24:16,080
as well. And this just gives you a little bit more of a

381
00:24:18,300 --> 00:24:22,480
zoomed in view of this actual field that comprises this actual

382
00:24:22,480 --> 00:24:31,700
packet that's part of SSDP. So again designed to incorporate a

383
00:24:31,700 --> 00:24:34,720
URL of your choice typically used by the vendor who creates

384
00:24:34,720 --> 00:24:38,920
that particular IOT device. But as I mentioned doesn't have to be

385
00:24:38,920 --> 00:24:42,080
a URL. You can put any kind of content you want in this field

386
00:24:42,080 --> 00:24:45,420
to whatever extent you want. I don't know the size limitations

387
00:24:45,420 --> 00:24:46,080
of that yet. I'm just as sure about the dimensions of what it

388
00:24:46,100 --> 00:24:48,620
yet. But nonetheless you can certainly hide a variety of

389
00:24:48,620 --> 00:24:51,860
content in here. If you wanted to further obfuscate that, you

390
00:24:51,860 --> 00:24:59,120
could of course go ahead and cipher that as well. And well,

391
00:24:59,180 --> 00:25:03,080
although this is designed for sort of the local network, what

392
00:25:03,080 --> 00:25:07,120
we've seen in terms of IoT with Mirai and even other variants

393
00:25:07,120 --> 00:25:11,780
that predate Mirai and their infections of IoT devices is

394
00:25:11,780 --> 00:25:14,240
that this coming in from the Internet would potentially

395
00:25:14,240 --> 00:25:18,360
target your router or your router with your firewall and

396
00:25:18,960 --> 00:25:21,340
furthermore would those packets be allowed into the internal

397
00:25:21,340 --> 00:25:25,080
network and thus with this type of thing, could those packets

398
00:25:25,080 --> 00:25:27,860
escape out or have a communication with the actual

399
00:25:27,860 --> 00:25:35,640
router itself. So theoretically, the router itself could

400
00:25:35,640 --> 00:25:39,340
actually pass this on to the Internet and to an intended

401
00:25:39,340 --> 00:25:43,520
recipient. And in addition, a lot of these fields could be

402
00:25:43,520 --> 00:25:44,220
exploited in there.

403
00:25:46,860 --> 00:25:50,480
So in the diagram here, if you had a two-way communication

404
00:25:50,860 --> 00:25:54,600
between two different IoT devices or an individual to an

405
00:25:54,600 --> 00:25:58,720
IoT device and vice versa, you could send this hidden content

406
00:25:58,720 --> 00:26:01,860
in what appears to be normal discovery protocol information

407
00:26:01,860 --> 00:26:06,560
leveraging SSDP that's actually harboring hidden content within

408
00:26:06,560 --> 00:26:10,240
the actual packet, probably undetected by any of the local

409
00:26:10,240 --> 00:26:14,180
IDS, MPS or other features you may have for your secure

410
00:26:14,220 --> 00:26:17,100
security products on the actual network and then receive this

411
00:26:17,100 --> 00:26:19,860
on the other end to actually reveal the hidden message.

412
00:26:24,460 --> 00:26:28,760
The other area that I did a lot of testing with, and this is

413
00:26:28,760 --> 00:26:32,840
actually covered in our book, has to do with Wi-Fi and layer

414
00:26:32,840 --> 00:26:37,600
two packets. So in terms of wireless, there's a variety of

415
00:26:39,120 --> 00:26:43,260
beacon packets, probe response, probe request, a variety of

416
00:26:43,260 --> 00:26:44,200
different types of packets that are available online. Perhaps,

417
00:26:44,220 --> 00:26:50,240
packets that are used within that. One of those within the beacon packet is something

418
00:26:50,240 --> 00:26:57,600
called an information element field or information element field, kind of used in exchangeably,

419
00:26:57,680 --> 00:27:03,840
but this field sometimes is leveraged by the vendor. So in a beacon packet, you've got

420
00:27:03,840 --> 00:27:10,380
a number of fields here, right, including the SSID and the BSSID, but you additionally

421
00:27:10,380 --> 00:27:15,620
have this information element field, and that information element field sometimes is used

422
00:27:15,620 --> 00:27:20,280
by the vendor. In there, they may say, hey, you know, I'm an Aruba, I'm a Motorola, I'm

423
00:27:20,280 --> 00:27:26,420
a Cisco, but many times this field actually goes unused, and it can hold up to 256 bytes

424
00:27:26,420 --> 00:27:32,400
of actual data. So if I wanted to leverage this to hide information, that's a decent

425
00:27:32,400 --> 00:27:37,620
amount of information for actually hiding text, and as Chet, you know, mentioned earlier,

426
00:27:37,880 --> 00:27:40,060
if you send multiple packets,

427
00:27:40,380 --> 00:27:46,780
which I did with this with my DDWRT, you can actually have a very extensive message or content

428
00:27:46,780 --> 00:27:51,940
that's split across these beacon packets such that they can be put together on the receiving end

429
00:27:51,940 --> 00:28:01,620
to reveal the hidden content or the message. So I went ahead and did that and hid a message

430
00:28:01,620 --> 00:28:07,940
within the IE field. It totally was accepted, you know, by the protocol. It was transmitted.

431
00:28:08,200 --> 00:28:10,260
I sent it from my DDWRT.

432
00:28:10,380 --> 00:28:17,520
I sent it to the IE device and monitored this and also determined that a laptop I had was

433
00:28:17,520 --> 00:28:21,120
receiving these packets and that you could communicate this back and forth.

434
00:28:27,780 --> 00:28:40,360
I was using SCAPI. SCAPI, yep, automated with Python. Yep. And so what would be the application of this?

435
00:28:40,380 --> 00:28:48,800
If I modified a beacon packet and inserted a message into the IE field, even if I used something

436
00:28:48,800 --> 00:28:55,260
fundamental like air replay to replay a PCAP file or I automated it in SCAPI, I could communicate

437
00:28:55,260 --> 00:29:00,860
covert messages over enemy lines, for example. And while although people in the neighboring

438
00:29:00,860 --> 00:29:07,140
airspace would just see a whole bunch of access points all sending beacon packets, how would

439
00:29:07,140 --> 00:29:13,160
you distinguish that out of, you know, 10, 50, 100 access points seen in the local airspace

440
00:29:13,160 --> 00:29:18,720
that one of these is communicating covertly? And therefore over, you know, enemy lines

441
00:29:18,720 --> 00:29:22,960
or to a different building or someone on, you know, the other side of the coffee shop

442
00:29:22,960 --> 00:29:29,200
for that matter provides a really covert way of doing that versus actually using a wireless

443
00:29:29,200 --> 00:29:34,700
ad hoc network, for example, in which a Russian spy was actually caught using that technique.

444
00:29:37,140 --> 00:29:42,280
And as I mentioned, I prototyped this and configured it within SCAPI so that you could run this

445
00:29:42,280 --> 00:29:49,760
using Python. And essentially I called this Wi-Fi stego stuffing. The reason I called it that

446
00:29:49,760 --> 00:29:57,080
was back a number of years back, Microsoft had done a bunch of research around beacon

447
00:29:57,080 --> 00:30:07,000
stuffing. I believe the intent behind it was if you walked into a store and you had your Wi-Fi

448
00:30:07,140 --> 00:30:11,560
enabled on your smart phone, they would detect when you came into the store because they

449
00:30:11,560 --> 00:30:16,220
would be looking for probe requests, for example, from your device, right, to connect to networks

450
00:30:16,220 --> 00:30:24,020
that you had previously used. But in gathering that information, they could actually distinguish

451
00:30:24,020 --> 00:30:30,580
that if you had their store app on the device that I see your device, you have the app associated

452
00:30:30,580 --> 00:30:35,180
to this particular MAC address, let's say, for your Wi-Fi. I know you're in the store.

453
00:30:35,280 --> 00:30:37,080
I'm going to respond with, you know, you're in the store. I'm going to respond with a

454
00:30:37,140 --> 00:30:42,280
beacon packet stuffed with a coupon that's going to flag it in the app and give you a one-time use

455
00:30:42,280 --> 00:30:48,140
coupon was sort of like what they were looking to do at that time. Yeah, exactly. I didn't want to

456
00:30:48,140 --> 00:30:56,080
mention any by name, but yes, exactly. Yep. And there's others too. Yeah. And so it's kind of

457
00:30:56,080 --> 00:31:00,220
exploiting that method in a different way, but more for covert communications essentially.

458
00:31:00,520 --> 00:31:05,900
So in terms of beacon stuffing, I said I'll call it Wi-Fi stego stuffing instead.

459
00:31:08,560 --> 00:31:16,700
All right. And with that, I'll turn it back over to chat. Thanks, Mike. So let's take this to kind

460
00:31:16,700 --> 00:31:22,920
of a different level. A number of years ago, we started to take a look at how we would hide data

461
00:31:22,920 --> 00:31:32,400
within streaming protocols. And especially things like audio streams, VoIP streams, that kind

462
00:31:32,400 --> 00:31:36,060
of stuff to see if we could actually use that as a method to be able to leak information out.

463
00:31:37,140 --> 00:31:43,280
And to be absolutely honest, it's really a pain in the neck. And part of the reason is that those

464
00:31:43,280 --> 00:31:48,960
packets that are part of either the VoIP stream or a media stream, they're encoded. They use

465
00:31:48,960 --> 00:31:53,980
different encoding methods. There's a very small amount of information in every packet, right? It's

466
00:31:53,980 --> 00:32:00,740
not large. It's very brief. It can be lost because it's unreliable, right? And if you lose a couple

467
00:32:00,740 --> 00:32:06,660
packets, no big deal. You can still hear the audio just fine. And that kind of thing. So it didn't

468
00:32:07,140 --> 00:32:12,560
at least the folks that we were talking to didn't believe that it was a viable method to be able to

469
00:32:12,560 --> 00:32:17,840
use in order to be able to communicate information using those streaming protocols by hiding

470
00:32:17,840 --> 00:32:24,680
information, by modifying the payload section of those packets. Okay? Sort of makes sense. Just

471
00:32:24,680 --> 00:32:32,280
kind of a complicated thing to actually do. Well, I wasn't done. I was certain there was a way to

472
00:32:32,280 --> 00:32:37,120
actually do this and do this effectively without, you know, I wanted to do this on my own. So I

473
00:32:37,140 --> 00:32:40,400
thought I'd just say that this is a lot more simply than what people were talking about. So

474
00:32:40,400 --> 00:32:44,900
obviously one of the problems with covert communication over these channels is there are just

475
00:32:44,900 --> 00:32:50,300
many different protocols. We talked about TCP and UDP, but then we've got RTP and we've got

476
00:32:50,300 --> 00:32:56,140
NoteTella, we've got VoIP, we've got RTSP and so on and so forth. There's all of these different

477
00:32:56,140 --> 00:33:04,780
protocols that are available to communicate streaming information. So the reason that this is a

478
00:33:05,640 --> 00:33:07,120
problem is obviously these streaming protocols are not as easy to use as they are to communicate. So

479
00:33:07,140 --> 00:33:11,600
streaming protocols are ubiquitous. And most organizations don't prevent people from being

480
00:33:11,600 --> 00:33:17,080
able to use these protocols to stream music over their networks. And understandably, their

481
00:33:17,080 --> 00:33:21,780
employees want to be able to listen to Pandora while they're at work, right? So the sheer volume

482
00:33:21,780 --> 00:33:26,100
of the streaming packets flowing in and out of an organization, even if it's allowed, even if it's

483
00:33:26,100 --> 00:33:32,300
VoIP that's being used, can be enormous. So how do you actually monitor this? Other than

484
00:33:32,300 --> 00:33:37,120
encryption, much of the streaming traffic goes unchecked. Again, due to some of the other

485
00:33:37,120 --> 00:33:41,740
several factors that I've kind of mentioned, the complexity of the encoding method, the large

486
00:33:41,740 --> 00:33:46,480
number of packets, the relatively small size of each packet, because you want these packets to be

487
00:33:46,480 --> 00:33:52,060
really small, at least the content portion. So if you do lose some information, it won't affect the

488
00:33:52,060 --> 00:33:57,940
actual experience of the folks that are listening to the streaming data. And obviously today, from a

489
00:33:57,940 --> 00:34:02,280
leakage perspective, if you look at data leak protection technology that's out there, it almost

490
00:34:02,280 --> 00:34:07,100
exclusively focuses on e-mail and web traffic and those kinds of things. It doesn't focus on, you know,

491
00:34:07,120 --> 00:34:15,120
streaming data that's coming from media. So let's talk about how Bob and Alice might pull this off and

492
00:34:15,120 --> 00:34:19,780
again why it's complicated. So when Alice wants to communicate with Bob and they want to basically

493
00:34:19,780 --> 00:34:24,640
carry out the streaming protocol, we have these packets that are going to go across. And the packets

494
00:34:24,640 --> 00:34:28,840
have a header, as I mentioned, that's pretty standardized. It is standardized. And then they have

495
00:34:28,840 --> 00:34:33,880
the payload. So again, most of the focus up to this point has been on the payload portion of how to

496
00:34:37,120 --> 00:34:42,220
communicate it over. There's a couple of problems. Besides the fact that it's complicated to include

497
00:34:42,220 --> 00:34:48,020
things within this encoding method, it's going to mess up the sound of the media. Right? If I

498
00:34:48,020 --> 00:34:53,740
actually encode other information within those, the payload portion, it's going to potentially have

499
00:34:53,740 --> 00:35:00,420
some impact on what you hear. Okay? Does that make sense? So we actually don't really want to do

500
00:35:00,420 --> 00:35:07,100
that. So basically the way this works, you know, in normal situations, it's going to be, you know,

501
00:35:07,120 --> 00:35:07,380
going to be letting Bob and Alice communicate with each other. So we'll have to have a little bit of

502
00:35:07,380 --> 00:35:10,000
time to do it more often. So the way the world has been organized is each of the packets contain a

503
00:35:10,000 --> 00:35:17,000
portion of a message that we want to communicate between Bob and Alice. So the question is how do we

504
00:35:17,000 --> 00:35:22,560
actually pull this off without getting into all the messy stuff that I talked about and kind of

505
00:35:22,560 --> 00:35:28,640
extending onto the core concepts behind what Craig Roland was talking about within this environment?

506
00:35:29,520 --> 00:35:34,080
So let's take a look at this in a little bit different way and assuming I have control of both ends

507
00:35:34,080 --> 00:35:37,100
of this interface. I can say this clearly, I don't have control over this interface. I've just got to

508
00:35:37,100 --> 00:35:42,920
could extract a packet out. And what I want to be able to do is

509
00:35:43,320 --> 00:35:46,100
instead of letting all the packets flow, I want to pull one

510
00:35:46,100 --> 00:35:48,980
out and just delay it. So remember on the other end, these

511
00:35:48,980 --> 00:35:51,120
are going to come in in a sequence and have to be

512
00:35:51,120 --> 00:35:56,880
reassembled. Remember this is unreliable link technology in

513
00:35:56,880 --> 00:35:59,820
all of these protocols. It's not like TCP. So basically they're

514
00:35:59,820 --> 00:36:02,180
going to come in potentially out of order. There's going to be

515
00:36:02,180 --> 00:36:06,220
packets missing. So I'm going to intentionally pull out one of

516
00:36:06,220 --> 00:36:10,380
the packets and not have it go through. And what we're going to

517
00:36:10,380 --> 00:36:14,180
do, let me pull this all up so I can see it because it's a little

518
00:36:14,180 --> 00:36:21,460
bit out of sequence. Give me one second. So the concept is if I

519
00:36:21,460 --> 00:36:25,260
extract this packet out of the stream and then I reinsert it

520
00:36:25,260 --> 00:36:29,020
later, what's going to happen when it gets, since it's out of

521
00:36:29,020 --> 00:36:33,420
sequence and it's quite delayed, what's going to happen with the

522
00:36:33,420 --> 00:36:36,200
normal music player on the other end?

523
00:36:37,600 --> 00:36:40,440
It's going to throw the packet away. And it's going to throw the

524
00:36:40,440 --> 00:36:43,460
packet away because in the stream of things, it's already

525
00:36:44,060 --> 00:36:47,960
compensated for the fact that the packet is missing. So it's

526
00:36:47,960 --> 00:36:53,100
not going to have any impact on what we hear. But I can put

527
00:36:53,100 --> 00:36:56,220
anything I want now in that payload because I know it's not

528
00:36:56,220 --> 00:36:59,580
going to actually play music. So I can put, use that entire

529
00:36:59,580 --> 00:37:03,540
payload for whatever content that I want to transfer over

530
00:37:03,540 --> 00:37:06,200
that, over that medium. So now what I do is I do a

531
00:37:06,220 --> 00:37:07,960
different thing. I take the message that I want and I start

532
00:37:07,960 --> 00:37:11,020
to break it up into packets that I'm delaying and actually

533
00:37:11,020 --> 00:37:13,880
sending them over in that way. So all I do is end up with packets

534
00:37:13,880 --> 00:37:17,440
that are delayed. So on the other end, all Bob has to do is

535
00:37:17,440 --> 00:37:21,400
extract the delayed packets. So if Bob is watching the network,

536
00:37:21,540 --> 00:37:24,100
all he has to do is basically say, wait, but this packet is way

537
00:37:24,100 --> 00:37:27,320
delayed. I'm going to pull that out and I know it has content in

538
00:37:27,320 --> 00:37:30,520
it that was meant for me. Right? And it's not going to affect

539
00:37:30,520 --> 00:37:33,340
wherever that stream was going to because it's going to have

540
00:37:33,340 --> 00:37:36,200
thrown that packet away already and not going to use it in the

541
00:37:36,220 --> 00:37:38,800
system in order to play the music or communicate the voice.

542
00:37:38,920 --> 00:37:42,260
So it will have no impact on what the user was. So I can be a man

543
00:37:42,260 --> 00:37:44,880
in the middle here in order to be able to pull these packets out,

544
00:37:44,920 --> 00:37:50,080
insert what I want, and have them be sent across the wire in

545
00:37:50,080 --> 00:37:53,620
this fashion. So the advantages of this approach, again,

546
00:37:53,680 --> 00:37:56,100
remember, there's a lot of naysayers out there saying that

547
00:37:56,100 --> 00:37:59,900
we couldn't use this kind of protocol, this streaming

548
00:37:59,900 --> 00:38:02,580
protocol, in order to convey any meaningful information using

549
00:38:02,580 --> 00:38:06,200
Stego. The advantages are the volume of streaming traffic is

550
00:38:06,220 --> 00:38:09,440
enormous. Most of it is not checked. Some of the

551
00:38:09,440 --> 00:38:12,820
disadvantages of this approach is it's a little bit more complex

552
00:38:12,820 --> 00:38:16,900
to pull off. Right? So we had to write some significant Python

553
00:38:16,900 --> 00:38:19,640
scripts on both ends in order to be able to do this. But it is

554
00:38:20,160 --> 00:38:23,540
easy to do once you actually build that. So that normal data

555
00:38:23,540 --> 00:38:28,380
loss can corrupt or lose the message content. However, as we

556
00:38:28,380 --> 00:38:31,120
talked about before, when you look at things that are in the

557
00:38:31,120 --> 00:38:34,580
IP header, right, they're still going to be there. So we can use

558
00:38:34,580 --> 00:38:38,620
things like the identification field within the IP header in

559
00:38:38,620 --> 00:38:42,680
order to be able to re-sync or provide error correction to the

560
00:38:42,680 --> 00:38:46,280
packets that may be lost. So even if we do lose packets, we

561
00:38:46,280 --> 00:38:49,940
can actually recover from that by using other fields within the

562
00:38:49,940 --> 00:38:54,040
IP header that are not really used that much or are not

563
00:38:54,040 --> 00:38:58,540
necessary in order to carry this out. So this is an example where

564
00:38:58,540 --> 00:39:03,820
taking Craig's original work and looking at, first of all, we

565
00:39:03,820 --> 00:39:04,560
haven't solved that problem. We haven't solved that problem. We

566
00:39:04,580 --> 00:39:06,640
haven't solved that problem either. But taking it to the next

567
00:39:06,640 --> 00:39:09,600
level with all of the different protocols and formats and data

568
00:39:09,600 --> 00:39:13,800
structures that we have, we can actually exploit this today to

569
00:39:13,800 --> 00:39:17,400
leak information out and we're not checking it. Unless you're a

570
00:39:17,400 --> 00:39:20,220
very sophisticated organization looking at this, you're not

571
00:39:20,220 --> 00:39:24,540
going to be detecting this within your environment. And I'm

572
00:39:24,540 --> 00:39:25,720
going to turn it back over to Mike.

573
00:39:34,580 --> 00:39:38,220
Yeah. So that was actually the last slide, right? Yeah. Okay.

574
00:39:38,260 --> 00:39:44,180
Cool. So a few other things I was going to mention. You know,

575
00:39:44,180 --> 00:39:51,220
last year when we presented, we had explored MP3s and the ID3

576
00:39:51,220 --> 00:39:56,460
headers and the type of content that could be hidden in that, how

577
00:39:56,460 --> 00:40:00,260
you could identify that from a forensic perspective. And one of

578
00:40:00,260 --> 00:40:04,080
the interesting things we actually stumbled upon during that testing

579
00:40:04,080 --> 00:40:12,120
was in modifying an MP3 and hiding some content in it, started to

580
00:40:12,120 --> 00:40:16,100
upload it to various music services. And one of those was a

581
00:40:16,100 --> 00:40:24,100
streaming music service. A very popular one. Yes. And in doing so,

582
00:40:24,100 --> 00:40:29,300
had accidentally discovered that if you had, say, like a musician

583
00:40:29,300 --> 00:40:33,280
type of account that you can, anybody, I believe, can actually

584
00:40:33,280 --> 00:40:38,280
create, you can upload your music to create a band or a channel,

585
00:40:38,400 --> 00:40:42,860
right, that people could bring up on their streaming music player

586
00:40:42,860 --> 00:40:47,240
or app, for that matter, and listen to it playing back. And what

587
00:40:47,240 --> 00:40:51,660
was kind of interesting was in doing this, found that you could

588
00:40:51,660 --> 00:40:54,800
upload that music and it would be playing and it would be

589
00:40:54,800 --> 00:40:58,600
streaming, really, for anybody, just like in posting an image to

590
00:40:58,600 --> 00:41:02,240
social media or, as Chet mentioned, you know, over the network.

591
00:41:03,280 --> 00:41:06,880
But only the intended recipient would know it was out there. So

592
00:41:06,880 --> 00:41:10,520
bottom line, if you were the intended recipient, you would go to

593
00:41:10,520 --> 00:41:13,460
that band, you would listen to the streaming music, wait for that

594
00:41:13,460 --> 00:41:17,400
music, and within Chrome on a PC, you can actually download that

595
00:41:17,400 --> 00:41:22,080
MP3. And that MP3 would contain that covert message. And we

596
00:41:22,080 --> 00:41:25,580
actually tested that and it actually worked. So just

597
00:41:26,000 --> 00:41:29,780
something else to think about, too. So in terms of, like,

598
00:41:30,480 --> 00:41:33,260
additional research, I'm doing more research on some of the, you

599
00:41:33,280 --> 00:41:38,640
know, some of the other protocols, aside from SSDP, UPMP, to see

600
00:41:38,640 --> 00:41:42,660
what other fields can be used for hiding content and communicating

601
00:41:42,660 --> 00:41:46,760
that. And I don't know, Chet, I know you're doing additional

602
00:41:46,760 --> 00:41:48,920
research. I don't know if you wanted to comment on anything else.

603
00:41:49,800 --> 00:41:54,240
Well, Mike and I presented this morning at, in SkyTalks, and we

604
00:41:54,240 --> 00:41:57,400
talked briefly about some of the other fields within these

605
00:41:57,400 --> 00:42:00,380
protocols that are vulnerable. We talked about time to live. We

606
00:42:00,380 --> 00:42:03,200
talked about some other fields within those protocols. But right

607
00:42:03,280 --> 00:42:07,560
now what we're doing is looking at a variety of protocols that are

608
00:42:07,560 --> 00:42:11,420
available with IOT devices and looking at how those could be

609
00:42:11,420 --> 00:42:13,640
exploited and those special protocols that are being

610
00:42:13,640 --> 00:42:17,000
developed there in order to be able to do that. Our real reason

611
00:42:17,000 --> 00:42:21,580
for presenting this, however, is for us to really think about how

612
00:42:21,580 --> 00:42:25,560
we actually do this better. Right? We tend to take this for

613
00:42:25,560 --> 00:42:29,300
granted and we don't consider the data hiding elements of,

614
00:42:29,500 --> 00:42:31,820
whether it's a protocol, which we're talking about today,

615
00:42:32,020 --> 00:42:33,260
whether it's a data-hiding element, whether it's a data

616
00:42:33,280 --> 00:42:38,100
structure for a particular file format. For example, one of the

617
00:42:38,100 --> 00:42:41,680
things on the multimedia side that we discovered was the

618
00:42:41,680 --> 00:42:46,520
ability to hide information within an MP4 file using a

619
00:42:46,520 --> 00:42:53,020
program called TCStack. And that actually includes a TrueCrypt

620
00:42:53,020 --> 00:42:57,020
volume right within the movie. So now I can actually play the

621
00:42:57,020 --> 00:43:00,100
movie. It plays perfectly. But if I bring that up in TrueCrypt,

622
00:43:00,160 --> 00:43:03,260
I can actually extract the hidden content and actually mount it as

623
00:43:03,280 --> 00:43:06,700
a volume. So all of these data structures have these

624
00:43:06,700 --> 00:43:09,940
traditional vulnerabilities built into them because I guess

625
00:43:09,940 --> 00:43:14,680
just nobody cares. Right? So I'm trying to kind of encourage you

626
00:43:14,680 --> 00:43:18,860
guys to care. So in the graduate programs that I teach in, we

627
00:43:18,860 --> 00:43:21,740
kind of are looking at ways that we could actually secure these

628
00:43:21,740 --> 00:43:25,920
protocols and secure these file structures such that they can't

629
00:43:25,920 --> 00:43:28,860
be manipulated. As Mike mentioned, when we talked about

630
00:43:28,860 --> 00:43:33,260
the ID3 header of MP3, many of you may know, but the IBHR is a

631
00:43:33,280 --> 00:43:33,480
company that's been working on the ID3 header for a long time.

632
00:43:33,480 --> 00:43:37,200
And the ID3 header has images associated with it. Whoever built

633
00:43:37,200 --> 00:43:42,740
this structure for the ID3 were certainly audiophiles that were

634
00:43:42,740 --> 00:43:46,080
interested in including all kinds of information in the ID3

635
00:43:46,080 --> 00:43:49,900
header of an MP3, which is great. It's artist information. It's

636
00:43:49,900 --> 00:43:53,120
information about the publisher. It's information about the tracks

637
00:43:53,120 --> 00:43:55,960
and how they were put together and images of the band and the

638
00:43:55,960 --> 00:43:59,900
singers and all of that kind of information is part of the header.

639
00:44:00,400 --> 00:44:03,260
But that means that there are images contained within the ID3

640
00:44:03,720 --> 00:44:07,460
right? So you've seen this in your car, right? You play a song

641
00:44:07,460 --> 00:44:11,300
within the car and the image of the artist pops up on your dash

642
00:44:11,300 --> 00:44:15,220
screen. You can put as many of those as you want in the ID3

643
00:44:15,220 --> 00:44:19,880
header. There's no limit to that. So now I can actually put 20 or 30

644
00:44:19,880 --> 00:44:22,520
images in there. I can put the lyrics of the song. I can

645
00:44:22,520 --> 00:44:25,720
synchronize the lyrics in there. But I can also hide whatever I

646
00:44:25,720 --> 00:44:29,620
want in those images that are there. So again, the general

647
00:44:29,620 --> 00:44:32,840
concept that we're talking about is the fact that these protocols

648
00:44:33,260 --> 00:44:37,200
and these data structures have no security in them to prevent the

649
00:44:37,200 --> 00:44:39,540
hiding of information. So that's kind of what we're trying to encourage

650
00:44:39,540 --> 00:44:43,000
you to think about. And I guess with that, we'd love to hear questions,

651
00:44:44,480 --> 00:44:47,600
comments, and I guess you should come up to the mic if you're going to

652
00:44:47,600 --> 00:44:48,240
do that, right?

653
00:44:48,560 --> 00:44:58,960
Yeah. Feel free. Question and answer. Assuming that I'm not a Russian

654
00:44:58,960 --> 00:45:01,660
spy, what are some of the consequences?

655
00:45:10,360 --> 00:45:18,480
Yeah, I mean, yeah, see if I can paraphrase it correctly. Yeah,

656
00:45:18,620 --> 00:45:22,400
yeah. Like other than a Russian spy, what would be the, you know,

657
00:45:22,440 --> 00:45:26,040
what, like a practical use case for this, either offensively or

658
00:45:26,040 --> 00:45:30,120
defensively. Yeah. Yeah. So there's a variety of use cases,

659
00:45:30,160 --> 00:45:33,240
right? And we actually covered this, we just announced this

660
00:45:33,260 --> 00:45:36,860
hour ago we did a presentation. You were there, right, on doing

661
00:45:36,860 --> 00:45:41,560
this on social media. There's a lot of different use cases. So

662
00:45:41,560 --> 00:45:45,440
aside from a Russian spy, whether it be a dead drop or

663
00:45:45,440 --> 00:45:49,040
covert communications, it could be used for data exfiltration

664
00:45:49,040 --> 00:45:52,180
within a corporation or an enterprise or an organization.

665
00:45:53,380 --> 00:45:57,240
And in addition to that, we've seen with things like Hammer

666
00:45:57,240 --> 00:46:00,980
Toss and others where it can be, and Operation Shady Rat for

667
00:46:00,980 --> 00:46:06,500
that matter, where it can be used for pointing to a specific

668
00:46:06,500 --> 00:46:11,600
URL where an image resides and within that image is hidden like

669
00:46:11,600 --> 00:46:16,060
updated CNC information such as a different URL or an IP

670
00:46:16,060 --> 00:46:19,420
address to allow the malware to update itself by occasionally

671
00:46:19,420 --> 00:46:22,680
going to what appears to be a very benign location like

672
00:46:22,680 --> 00:46:26,460
WordPress, downloading an image that is just of a cat and again

673
00:46:26,460 --> 00:46:29,960
looking very benign but again contained within all of this is

674
00:46:29,960 --> 00:46:30,640
this infrastructure.

675
00:46:30,980 --> 00:46:34,260
For updating the CNC and leveraging that to further

676
00:46:34,260 --> 00:46:40,400
like exfiltrate information. The flip side of this also is while

677
00:46:40,400 --> 00:46:44,200
we look for areas in which we can hide this information, there's

678
00:46:44,200 --> 00:46:47,980
a lot of metadata fields. As Chet alluded to with MP3s and the

679
00:46:47,980 --> 00:46:51,760
ID3 headers, we explored that last year and there was a plethora

680
00:46:51,760 --> 00:46:53,880
of different ways in which you could hide information and

681
00:46:53,880 --> 00:46:57,800
furthermore in the talk we just did, hey, I've got an MP3, I'm

682
00:46:57,800 --> 00:47:00,800
going to post that to social media, you know, and leave that

683
00:47:00,980 --> 00:47:04,660
as a dead drop for somebody else and rather than actually change

684
00:47:04,660 --> 00:47:08,880
anything for the audio or the MP3 itself but rather the JPEG

685
00:47:08,880 --> 00:47:13,680
within the MP3 that displays on your MP3 player, hide the data

686
00:47:13,680 --> 00:47:17,140
there instead, right? Or append data to the end of the file

687
00:47:17,140 --> 00:47:19,600
beyond the end of file marker. So there's a plethora of

688
00:47:19,600 --> 00:47:26,280
different like use cases. Are other groups, agencies, good or

689
00:47:26,280 --> 00:47:30,140
bad, using this for covert communications? You know, I guess

690
00:47:30,140 --> 00:47:30,960
a lot of that's left to you to decide. I think that's a good

691
00:47:30,980 --> 00:47:33,840
way to get off to spy movies, but, you know, there's certainly a

692
00:47:33,840 --> 00:47:36,200
variety of use cases. I don't know, did I miss anything, Chet,

693
00:47:36,240 --> 00:47:38,760
you wanted to add? Okay. All right. Cool. Thanks.

694
00:47:41,540 --> 00:47:47,300
So currently while there are no security around the abuse of

695
00:47:47,300 --> 00:47:52,760
these protocols, can an organization use its firewall to

696
00:47:53,660 --> 00:47:57,120
monitor the egress of these protocols and drop these

697
00:47:57,120 --> 00:47:59,880
packets? Yeah, I'll let Chet take that one first.

698
00:48:00,980 --> 00:48:05,940
Yeah, there's two things that you can do. One is you can jam the

699
00:48:05,940 --> 00:48:10,420
protocols. So I talked earlier today at the Sky Talks talking

700
00:48:10,420 --> 00:48:13,520
about embedding information in the time to live field, the upper

701
00:48:13,520 --> 00:48:17,440
bits that are never used. So if you're there, if you have a way

702
00:48:17,440 --> 00:48:20,360
to store and forward packets, you can basically jam those channels

703
00:48:20,360 --> 00:48:23,880
by basically overwriting the data. If information is leaking

704
00:48:23,880 --> 00:48:27,140
out as part of MP3s, I can re-encode it. If it's a JPEG, I

705
00:48:27,140 --> 00:48:30,600
can re-encode the JPEG. I mean, obviously this is what Facebook and

706
00:48:30,600 --> 00:48:33,380
those do. When you post an image to Facebook, it eliminates

707
00:48:33,380 --> 00:48:36,360
the geotag and the header information of the JPEG, but it

708
00:48:36,360 --> 00:48:39,460
also actually re-encodes the image. So if there was something

709
00:48:39,460 --> 00:48:41,220
hidden in it, it's supposed to wipe it out. Now, those

710
00:48:41,220 --> 00:48:44,560
algorithms are not perfect, and we've figured out ways around

711
00:48:44,560 --> 00:48:47,660
that. But nonetheless, at least it's an attempt. So one of the

712
00:48:47,660 --> 00:48:50,940
most effective ways is to jam those protocols if you think

713
00:48:50,940 --> 00:48:54,780
that's happening. The other thing to do is to be able to monitor

714
00:48:55,340 --> 00:48:58,240
those behaviors. We talked about the initial sequence numbers. We

715
00:48:58,240 --> 00:49:00,220
talked about some of the other things that we can do. One of

716
00:49:00,600 --> 00:49:04,300
those aspects, and you can, if you're looking for that carefully,

717
00:49:04,820 --> 00:49:08,200
you can actually have a sensor that would look at that specific

718
00:49:08,200 --> 00:49:12,300
information and then be able to detect anomalies within the

719
00:49:12,300 --> 00:49:15,740
behavior of those protocols that we would not normally see. For

720
00:49:15,740 --> 00:49:20,340
example, information hidden in the identification field. Initial

721
00:49:20,340 --> 00:49:23,340
sequence numbers that don't appear to be random. So those

722
00:49:23,340 --> 00:49:26,920
kinds of things we can detect. But the question is, is anybody

723
00:49:26,920 --> 00:49:30,160
looking from that perspective? I don't know if you want to add to

724
00:49:30,600 --> 00:49:33,660
that. Yeah, the only thing I would add, and I think Chet kind of

725
00:49:33,660 --> 00:49:37,900
hit on this, is in modeling out the network and knowing what's

726
00:49:37,900 --> 00:49:41,500
normal, leveraging that to determine what's anomalistic

727
00:49:41,500 --> 00:49:46,080
that's going on. But that's very difficult to do, but attainable in

728
00:49:46,080 --> 00:49:52,700
today's world, right? So we've spent a lot of time talking about

729
00:49:53,160 --> 00:49:58,340
how this has been an inherent 20-year, probably 30-year problem.

730
00:49:58,780 --> 00:50:00,440
We've been doing it a long time.

731
00:50:02,220 --> 00:50:09,500
We're old. So do we fix the problem? Or do we continue to let

732
00:50:09,500 --> 00:50:14,380
it go? And if we fix it, is it at the vendor level? Is it at the

733
00:50:15,140 --> 00:50:20,180
protocol federal regulation level? Yeah, so I think there's a

734
00:50:20,180 --> 00:50:24,980
number of different viewpoints. I'll hit on one or two, and then

735
00:50:24,980 --> 00:50:28,680
I know Chet's very passionate about this one, too. What we

736
00:50:28,680 --> 00:50:30,580
just presented a little while ago, I think there's a number of

737
00:50:30,600 --> 00:50:31,360
different views. One was that the most common view in track

738
00:50:31,360 --> 00:50:36,100
four here at DEF CON was leveraging social media for

739
00:50:36,100 --> 00:50:39,880
covert communications, but further automating that or

740
00:50:39,880 --> 00:50:44,100
testing it in an ethical way, but from an offensive

741
00:50:44,100 --> 00:50:49,260
standpoint, and automating it using machine learning. The

742
00:50:49,260 --> 00:50:53,460
intent behind that was to say, while we're running around

743
00:50:53,460 --> 00:50:57,840
trying to find ways in which we can detect this stuff, with the

744
00:50:57,840 --> 00:51:00,580
technology we have today, could we simulate that in a way that's

745
00:51:00,600 --> 00:51:00,780
more user-friendly? And I think that's what we're trying to

746
00:51:00,780 --> 00:51:02,540
do. We're trying to simulate it from an offensive standpoint,

747
00:51:02,820 --> 00:51:07,340
and leverage ML and neural nets to actually discover a whole bunch

748
00:51:07,340 --> 00:51:10,540
of new ways that humans haven't figured out, but the machine can.

749
00:51:10,840 --> 00:51:16,880
And the result being that here are another 2,000 methods that, to

750
00:51:16,880 --> 00:51:20,300
our knowledge, nobody has used, but are ways in which the data

751
00:51:20,300 --> 00:51:24,220
could be hidden in what we demonstrated across social media,

752
00:51:24,360 --> 00:51:27,380
and then leverage that intelligence for better defense.

753
00:51:29,700 --> 00:51:30,580
Yeah, the other thing I wanted to say is that, you know, we've

754
00:51:30,580 --> 00:51:30,700
been trying to try to send data to a large number of organizations

755
00:51:30,700 --> 00:51:32,940
Well, the thing that we're trying to do is we're trying to inspire,

756
00:51:33,740 --> 00:51:38,080
encourage the standards bodies to really take a look at this. So

757
00:51:38,080 --> 00:51:41,520
we keep trying to bring this awareness of this problem, and a

758
00:51:41,520 --> 00:51:45,040
lot of the big organizations are actually looking at this. McAfee

759
00:51:45,040 --> 00:51:47,560
actually has just released a bunch of information about the

760
00:51:47,560 --> 00:51:50,640
concern for steganography, which we've been talking to them about

761
00:51:50,640 --> 00:51:53,960
for 10 years. And now they're seeing this as a real problem.

762
00:51:54,080 --> 00:51:58,020
So once the standards bodies realize that the protocols they're

763
00:51:58,020 --> 00:51:59,960
defining the data structures that are coming out

764
00:51:59,960 --> 00:52:02,000
that people are using are vulnerable

765
00:52:02,000 --> 00:52:04,020
to this, hopefully they'll actually

766
00:52:04,020 --> 00:52:05,580
start to take steps

767
00:52:05,580 --> 00:52:07,860
that will actually redefine

768
00:52:07,860 --> 00:52:10,100
those protocols in a way that we can eliminate

769
00:52:10,100 --> 00:52:12,200
this. I mean, part of it starts

770
00:52:12,200 --> 00:52:14,140
at even, you know, Mike

771
00:52:14,140 --> 00:52:16,040
and I both being authors, I mean,

772
00:52:16,080 --> 00:52:17,840
it's like DRM doesn't exist.

773
00:52:18,060 --> 00:52:19,120
It's just worthless.

774
00:52:19,460 --> 00:52:21,300
It's not about writing back code anymore.

775
00:52:22,100 --> 00:52:23,580
Right. Right.

776
00:52:23,700 --> 00:52:25,940
We can't blame the vendors

777
00:52:25,940 --> 00:52:27,200
for writing back code.

778
00:52:28,080 --> 00:52:29,820
Because they have a highway

779
00:52:29,820 --> 00:52:31,980
that promotes illicit behavior.

780
00:52:32,460 --> 00:52:33,780
Yeah, and they're

781
00:52:34,660 --> 00:52:36,360
abiding by standards that have

782
00:52:36,360 --> 00:52:38,000
these fundamental flaws in them

783
00:52:38,000 --> 00:52:39,540
so they can hide behind that.

784
00:52:40,160 --> 00:52:41,460
Because they're writing into the standard.

785
00:52:41,660 --> 00:52:42,220
Yep, exactly.

786
00:52:43,460 --> 00:52:48,180
That was rhetorical, yeah.

787
00:52:48,980 --> 00:52:50,380
Any other questions?

788
00:52:51,260 --> 00:52:51,900
Yes.

789
00:52:52,120 --> 00:52:52,760
Yes.

790
00:52:52,760 --> 00:52:53,600
I have a question about your

791
00:52:53,600 --> 00:52:55,500
safe-looking attack.

792
00:52:55,840 --> 00:52:57,820
What is the Bible or

793
00:52:57,820 --> 00:52:59,420
rather just checks that you cannot

794
00:53:00,420 --> 00:53:01,640
use any address

795
00:53:01,640 --> 00:53:03,380
but you can use

796
00:53:03,380 --> 00:53:04,100
all of it.

797
00:53:04,860 --> 00:53:06,220
It might quite be a back address.

798
00:53:06,480 --> 00:53:08,020
Can you use these cards to

799
00:53:08,020 --> 00:53:08,680
communication?

800
00:53:12,160 --> 00:53:14,560
Yeah, no, that's a great question.

801
00:53:14,780 --> 00:53:16,440
And it kind of goes to a talk that we did

802
00:53:16,440 --> 00:53:18,420
a couple years ago about actually

803
00:53:18,420 --> 00:53:19,840
being able to spoof the MAC address

804
00:53:19,840 --> 00:53:22,160
and changing those. So obviously it's going to affect

805
00:53:22,160 --> 00:53:23,380
the ARP table and that kind of stuff.

806
00:53:23,540 --> 00:53:25,580
But at the time that the SYN comes in, right,

807
00:53:26,300 --> 00:53:27,800
that is just going to be a lot of trouble.

808
00:53:27,820 --> 00:53:29,560
We responded to and acknowledged unless

809
00:53:29,560 --> 00:53:32,580
that particular IP address has been blocked.

810
00:53:32,940 --> 00:53:34,840
And if you're not abusive, right,

811
00:53:34,900 --> 00:53:37,040
if I only use that server one time

812
00:53:37,040 --> 00:53:39,340
to basically spoof the IP address,

813
00:53:39,520 --> 00:53:41,580
it's not going to look like a denial-of-service attack

814
00:53:41,580 --> 00:53:44,100
because I've only sent one packet, right,

815
00:53:44,180 --> 00:53:45,400
to that particular server.

816
00:53:45,620 --> 00:53:47,620
So the only way to do this is to distribute

817
00:53:47,620 --> 00:53:49,700
the effect over thousands or millions

818
00:53:49,700 --> 00:53:51,780
of devices that I want to bounce this packet

819
00:53:51,780 --> 00:53:53,260
off of in Craig's original,

820
00:53:53,440 --> 00:53:55,600
this is not my design, this was Craig's

821
00:53:56,160 --> 00:53:57,120
original article.

822
00:53:57,120 --> 00:53:58,760
This still stands today.

823
00:53:59,160 --> 00:54:01,580
I can use that to basically hide the identity

824
00:54:01,580 --> 00:54:03,080
of the sender and the receiver

825
00:54:03,080 --> 00:54:06,080
by using that method, you know, judiciously.

826
00:54:06,380 --> 00:54:07,960
It's like denial-of-service, right?

827
00:54:08,020 --> 00:54:09,140
One of the things that you want to do

828
00:54:09,140 --> 00:54:10,400
with denial-of-service, I want to have

829
00:54:10,400 --> 00:54:13,600
millions of IP addresses that I've compromised,

830
00:54:14,280 --> 00:54:16,620
right, and have packets sent from all of those

831
00:54:16,620 --> 00:54:18,060
IP addresses that I've compromised,

832
00:54:18,180 --> 00:54:20,120
not from one location, right?

833
00:54:20,280 --> 00:54:22,180
So even if I shut those off, I'm still going to have

834
00:54:22,180 --> 00:54:23,480
millions that I have to deal with.

835
00:54:23,600 --> 00:54:25,720
And we obviously deal with that a different way

836
00:54:25,720 --> 00:54:26,340
to...

837
00:54:27,120 --> 00:54:28,140
From a denial-of-service perspective,

838
00:54:28,300 --> 00:54:29,400
we handle that differently today.

839
00:54:29,540 --> 00:54:33,500
But nonetheless, the issue is exactly what you said.

840
00:54:33,660 --> 00:54:37,540
It's like nobody's going to basically defend against this

841
00:54:37,540 --> 00:54:40,080
because it's a non-issue to that one server

842
00:54:40,080 --> 00:54:42,560
getting that one packet from that client

843
00:54:42,560 --> 00:54:43,960
that never gets responded to.

844
00:54:45,740 --> 00:54:46,300
Right.

845
00:54:49,620 --> 00:54:50,180
Right.

846
00:55:02,900 --> 00:55:04,300
After you've done that.

847
00:55:04,340 --> 00:55:04,920
Exactly right.

848
00:55:05,060 --> 00:55:07,260
But the ISPs typically don't do that, right?

849
00:55:07,320 --> 00:55:09,820
So the question is, I want to find out whether

850
00:55:09,820 --> 00:55:12,880
you're talking about a guy who is in a company

851
00:55:12,880 --> 00:55:15,160
in the Internet trying to steal

852
00:55:15,160 --> 00:55:19,080
as extroverted data from companies.

853
00:55:19,400 --> 00:55:20,820
But then in that case,

854
00:55:21,020 --> 00:55:24,000
the spoof of technology wouldn't work.

855
00:55:24,340 --> 00:55:24,860
Correct.

856
00:55:25,220 --> 00:55:26,000
You would do that.

857
00:55:26,300 --> 00:55:26,820
Right.

858
00:55:27,120 --> 00:55:30,140
But then you mentioned method one, method two,

859
00:55:30,140 --> 00:55:32,740
where you can use IP, IP ID,

860
00:55:32,940 --> 00:55:34,980
or TCP initial signal number.

861
00:55:35,140 --> 00:55:38,180
But some of the firewalls will overwrite them,

862
00:55:38,260 --> 00:55:39,200
will rewrite them.

863
00:55:39,240 --> 00:55:39,440
Correct.

864
00:55:39,840 --> 00:55:40,760
That's the defense.

865
00:55:40,900 --> 00:55:41,280
Right.

866
00:55:41,340 --> 00:55:42,920
Those firewalls at the egress points

867
00:55:42,920 --> 00:55:45,600
will actually rewrite those.

868
00:55:45,740 --> 00:55:47,640
If they do the same thing with time to live,

869
00:55:47,700 --> 00:55:48,760
whatever, if they see that wrong,

870
00:55:48,860 --> 00:55:49,820
they'll actually fix it.

871
00:55:49,900 --> 00:55:50,280
Right.

872
00:55:50,360 --> 00:55:52,560
But they're not implemented very often.

873
00:55:52,760 --> 00:55:53,120
Right.

874
00:55:53,320 --> 00:55:54,200
They're not always.

875
00:55:54,360 --> 00:55:54,680
Yep.

876
00:55:57,120 --> 00:56:00,840
And so that's a wrap for Chet and Mike.

877
00:56:02,580 --> 00:56:04,460
Chet and Mike, welcome back.

878
00:56:04,580 --> 00:56:05,540
Always a pleasure.

879
00:56:06,080 --> 00:56:07,000
Always a pleasure.