1
00:00:26,940 --> 00:00:30,240
Hey, is that Finnish kid Miko here at all?

2
00:00:30,750 --> 00:00:32,340
The Finnish kid?

3
00:00:32,520 --> 00:00:33,840
Yeah.

4
00:00:34,020 --> 00:00:35,880
Nah, I guess not.

5
00:00:43,540 --> 00:00:44,580
Foundation.

6
00:00:44,620 --> 00:00:45,280
It's

7
00:00:49,090 --> 00:00:51,350
a sad, sad state of affairs.

8
00:00:56,780 --> 00:00:57,500
Hello.

9
00:00:57,500 --> 00:01:03,460
Welcome to Linguistic Platform for Threat Development, the Extreme Hangover Edition.

10
00:01:03,860 --> 00:01:08,930
I'm Ben Kurtz, I work for a company called Imperfect Networks out in Burlington, Massachusetts.

11
00:01:10,790 --> 00:01:18,910
Today I'm going to talk to you about what I have cooked up over the past year, why I did it, and how it can help you do what you do.

12
00:01:28,550 --> 00:01:33,990
That's all well and good, but basically I'm going to talk about a design pattern for a...

13
00:01:34,790 --> 00:01:42,250
I'm going to give you a view from like 30,000 feet, it's just going to be like a broad overview, real abstract.

14
00:01:42,250 --> 00:01:49,650
I don't really have the time to go into the sort of details I'd like, but let's see.

15
00:01:49,870 --> 00:02:05,430
By applying some often overlooked corners of programming language theory to the development of network attacks, we can create a new type of threat platform which can handle every conceivable network protocol and run readily on any architecture that can handle embedded Linux.

16
00:02:05,730 --> 00:02:15,790
The ultimate goal is to reduce the total time to develop a threat to the time it takes to research and understand its behavior, plus two minutes or so.

17
00:02:15,950 --> 00:02:22,110
Once the threat is implemented, we also want the ability to store it in a database and play it back whenever.

18
00:02:25,870 --> 00:02:29,890
This presentation is divided into four sections, roughly.

19
00:02:30,250 --> 00:02:36,470
First, we'll look at the motivations for a new threat platform, which is hopefully not going to be too dull.

20
00:02:36,770 --> 00:02:42,970
Second, we'll take a closer look at what we need threats for and how the threat development and testing cycle works.

21
00:02:42,970 --> 00:02:55,610
The reason I'm going to go through that is because many people here look at threat development and threat testing from an enterprise standpoint or a pen testing standpoint, and I'm kind of coming at it from a slightly different angle.

22
00:02:55,610 --> 00:02:59,890
I need to encompass a broader spectrum of threats in a single system.

23
00:03:00,230 --> 00:03:06,250
I'm looking at it more from a manufacturing testing and regression testing standpoint.

24
00:03:07,810 --> 00:03:15,110
I'm going to take a little time and reframe what threat testing is in terms of the talk.

25
00:03:16,730 --> 00:03:21,730
Next, we'll summarize the design goals of the new system, then we get into the good bit.

26
00:03:21,810 --> 00:03:27,990
We'll look at some ideas from programming language theory and how we can use them to get what we want.

27
00:03:29,810 --> 00:03:31,690
Now, motivation.

28
00:03:34,150 --> 00:03:37,210
Why do we want a threat development platform in the first place?

29
00:03:37,570 --> 00:03:40,230
Simply, we want to break stuff.

30
00:03:41,030 --> 00:03:43,970
We want to break stuff and we're incredibly lazy.

31
00:03:44,290 --> 00:03:47,610
We want a tool that makes it easier to break stuff quickly.

32
00:03:48,010 --> 00:03:54,530
We also want to minimize the time from the first rumor we hear of a new threat to the ability to play it back on the wire with the touch of a button.

33
00:03:55,190 --> 00:04:00,050
Being up to date on new threats is a foot race and anything that helps us go faster is our friend.

34
00:04:05,430 --> 00:04:07,270
Why do we want to break stuff?

35
00:04:08,170 --> 00:04:13,250
There's two main reasons along the standard black hat, white hat divide.

36
00:04:13,870 --> 00:04:24,250
What I'm focusing on is we want to break network equipment and services that we develop and use so we can assure our customers of some degree of protection and reliability.

37
00:04:25,130 --> 00:04:27,930
There is no trust without testing.

38
00:04:28,150 --> 00:04:35,150
A lot of things are advertised as being secure and that's never been verified by anybody in many cases.

39
00:04:35,150 --> 00:04:42,110
And on the other side, we want to break stuff because we have malice in our hearts.

40
00:04:42,910 --> 00:04:48,830
Like any powerful technology, a threat platform can be a tool of assurance or a weapon.

41
00:04:48,930 --> 00:04:59,530
Since the malicious uses are fairly obvious, developing a threat and executing it quickly with a great amount of throughput, I won't really revisit this.

42
00:05:00,190 --> 00:05:08,050
Many security products such as intrusion detection systems are developed and brought to market with little or no testing against real live threats.

43
00:05:08,510 --> 00:05:16,070
Usually they're tested against a small set of handcrafted sample traffic that is designed to trigger existing threat signatures in the IDS.

44
00:05:16,210 --> 00:05:25,030
This means that the test cases are usually written to test what the IDS already does rather than to test its ability to protect against real threats.

45
00:05:26,630 --> 00:05:36,070
At some point you're going to have to test your network security products against real attacks rather than, you know, just handcrafted stuff.

46
00:05:36,070 --> 00:05:39,450
Otherwise you're providing your customers with only the illusion of security.

47
00:05:43,640 --> 00:05:48,260
There are numerous places that release vulnerabilities or exploits to the public.

48
00:05:48,500 --> 00:05:51,520
You probably all know most of these.

49
00:05:51,520 --> 00:05:56,740
You've got BugTrack, Security Focus, Full Disclosure, Mike Lynn...

50
00:05:59,080 --> 00:06:00,720
That's a drink.

51
00:06:00,720 --> 00:06:05,300
As soon as an exploit shows up on the net every potential attacker has access to it.

52
00:06:06,440 --> 00:06:07,320
Me?

53
00:06:09,460 --> 00:06:10,560
I do?

54
00:06:13,930 --> 00:06:16,010
I've got to put a stop to that right now.

55
00:06:17,730 --> 00:06:18,610
Alright.

56
00:06:19,470 --> 00:06:23,410
You need to know that you're safe from each new threat as soon as it becomes public.

57
00:06:24,750 --> 00:06:29,710
Private threats are kind of an unknown quantity but you can definitely keep up with the mailing list.

58
00:06:29,710 --> 00:06:40,750
You have to do this partly out of prudence and partly because your boss called you in a panic because his boss called him in a panic because the CEO called him in a panic after hearing about some worm on the news.

59
00:06:41,510 --> 00:06:50,290
The threat developer needs to stay on top of the the O-Day threats, mostly to be able to say yes, we've already accounted for that and we're testing against it.

60
00:06:51,730 --> 00:06:57,730
You could just say this anyway but you're still going to want to actually go out and do the work before anyone checks up on you.

61
00:06:58,910 --> 00:07:04,270
To be assured that you can handle all publicly known threats you have to keep up the mailing lists.

62
00:07:04,710 --> 00:07:07,850
Zero-day protection requires zero-day testing.

63
00:07:11,370 --> 00:07:15,470
Honestly, there's only three steps here but it looks better with five.

64
00:07:17,310 --> 00:07:19,890
We're going to spend a few minutes talking about threat testing.

65
00:07:19,890 --> 00:07:29,430
This is from a manufacturing, network equipment manufacturer standpoint rather than from a pen testing or enterprise security testing standpoint.

66
00:07:30,390 --> 00:07:35,270
For each new threat that you want to develop and test a threat developer goes through several steps.

67
00:07:35,470 --> 00:07:37,570
And that's three, not five.

68
00:07:38,510 --> 00:07:40,070
First, the threat must be researched.

69
00:07:40,070 --> 00:07:46,370
You have to figure out what it targets, what the packets look like, what protocols it uses, how it behaves, and so on.

70
00:07:47,530 --> 00:07:52,130
Next, you have to implement the threat which means writing the PERL code or the C code.

71
00:07:52,130 --> 00:07:57,310
And finally, your service or equipment is tested against the new threat to see if it's vulnerable.

72
00:07:58,570 --> 00:08:05,830
Then you begin the cycle again with the next threat or sometimes developing one will lead you to another like a variant.

73
00:08:09,810 --> 00:08:15,730
All these steps can be very time consuming to the point that many QA departments don't bother.

74
00:08:16,370 --> 00:08:23,710
The time period from when an exploit first enters the public domain until you release a patch to defend against it is your window of vulnerability.

75
00:08:24,350 --> 00:08:33,810
The testing side of the equation is at a serious disadvantage from the start since a would-be attacker can usually just download sample code for an exploit and go to town.

76
00:08:34,430 --> 00:08:41,830
If it takes two weeks to research, implement, and test a threat, that's including all your QA guys' vacation times, coffee breaks, and so on.

77
00:08:42,110 --> 00:08:43,290
Mind sweeper.

78
00:08:45,070 --> 00:08:56,850
But if it takes you two weeks to research, implement, and test a threat, your window of vulnerability is two weeks where an attacker doesn't need more than an hour or two and that's a pretty conservative estimate.

79
00:08:58,610 --> 00:09:01,490
It's easier to break something than it is to fix it.

80
00:09:03,390 --> 00:09:05,870
So if you're on the defense, you have a disadvantage.

81
00:09:07,790 --> 00:09:12,850
So what are your options to speed up threat turnaround time and to minimize your window of vulnerability?

82
00:09:13,670 --> 00:09:17,210
Your first option is to hire more people to handle the daily updates.

83
00:09:17,210 --> 00:09:23,770
Some places have upwards of 20 employees working on researching and implementing new threats as they come out.

84
00:09:24,150 --> 00:09:25,510
Some places.

85
00:09:25,610 --> 00:09:26,650
No names.

86
00:09:27,010 --> 00:09:35,810
This approach allows you to deal with more threats concurrently, but each threat must be developed and tested in parallel using the same time-consuming tools.

87
00:09:36,370 --> 00:09:40,530
So for any single threat, your window of vulnerability remains the same.

88
00:09:40,670 --> 00:09:46,310
It's kind of like, you know, you can't parallelize baby creation.

89
00:09:46,310 --> 00:09:50,990
From start to finish it takes a certain amount of time, given a certain set of tools.

90
00:09:57,170 --> 00:09:59,350
Alright, I'll drink for that one.

91
00:10:07,740 --> 00:10:14,140
The second option is to improve the tools that threat developers use to speed up the process of developing a single threat.

92
00:10:14,340 --> 00:10:16,160
And that's what we're going to talk about.

93
00:10:16,160 --> 00:10:28,750
By automating the common and repetitive tasks associated with threat development and by only forcing a developer to describe the unique aspects of a threat, the threat turnaround time can be greatly reduced.

94
00:10:35,220 --> 00:10:37,880
This is probably not a popular idea.

95
00:10:37,880 --> 00:10:39,760
I love my job.

96
00:10:40,000 --> 00:10:42,880
My inclination is to say, hey, we'll hire more people.

97
00:10:42,880 --> 00:10:46,280
We'll give more people jobs that they can love.

98
00:10:46,740 --> 00:10:48,840
But this is an expensive proposition.

99
00:10:48,840 --> 00:10:50,080
You suck.

100
00:10:58,990 --> 00:11:00,990
I'm trying not to.

101
00:11:01,110 --> 00:11:03,010
Peer pressure, you know.

102
00:11:07,590 --> 00:11:10,190
That was your fault, man.

103
00:11:13,110 --> 00:11:14,730
You have a drinking song?

104
00:11:21,010 --> 00:11:23,110
He just did.

105
00:11:23,230 --> 00:11:25,730
This is

106
00:11:31,900 --> 00:11:33,540
going downhill quickly.

107
00:11:37,840 --> 00:11:40,580
I'm Ben Kurtz

108
00:12:06,330 --> 00:12:07,210
.

109
00:12:47,980 --> 00:12:51,780
This is tequila, you know.

110
00:12:59,030 --> 00:13:00,270
Yeah.

111
00:13:03,830 --> 00:13:06,350
Only in the morning, right.

112
00:13:09,850 --> 00:13:10,790
All right.

113
00:13:15,630 --> 00:13:16,350
Very good.

114
00:13:16,350 --> 00:13:17,950
Well, I've got to press on.

115
00:13:17,950 --> 00:13:19,250
Or I'm going to run over.

116
00:13:22,730 --> 00:13:25,890
I can't actually focus on my notes at the moment.

117
00:13:28,170 --> 00:13:29,210
All right.

118
00:13:29,490 --> 00:13:31,490
So, where was I?

119
00:13:31,490 --> 00:13:33,890
We were talking about hiring more people, right.

120
00:13:34,690 --> 00:13:36,610
Or not hiring more people, right.

121
00:13:36,610 --> 00:13:41,870
It's an expensive proposition for a smaller company and a difficult proposition for a larger company.

122
00:13:42,730 --> 00:13:48,530
If you look around this conference, you guys and your friends back home are pretty much the hiring pool for our entire country.

123
00:13:49,590 --> 00:13:53,370
Yeah, it's a problem.

124
00:13:56,610 --> 00:14:05,230
There aren't really any college curriculums that teach this stuff and it can be incredibly difficult to find the sort of employees with the passion and personal drive to learn it on their own.

125
00:14:05,230 --> 00:14:07,150
Which is you guys, really.

126
00:14:10,470 --> 00:14:16,330
Even if you do find a skilled security guru, you're going to want to maximize his or her output.

127
00:14:16,370 --> 00:14:18,690
This means we need better tools.

128
00:14:22,970 --> 00:14:26,590
There are a couple of existing threat platforms.

129
00:14:28,290 --> 00:14:30,690
Metasploit is pretty cool.

130
00:14:30,690 --> 00:14:35,870
It gives you a mix and match ability with exploits written in Perl and various types of shell codes.

131
00:14:35,870 --> 00:14:43,830
The downside is that the scope of the attacks are limited and it's difficult to add new exploits quickly even if you know Perl.

132
00:14:43,870 --> 00:14:50,330
It doesn't provide an easy interface or any regression testing tools or reporting.

133
00:14:51,130 --> 00:14:54,670
There's also Canvas which is similar but in Python.

134
00:14:55,590 --> 00:15:02,310
Metasploit and Canvas are good at what they do which is primarily running exploits that will result in control of a box.

135
00:15:02,310 --> 00:15:05,170
It's more of an enterprise pen testing type solution.

136
00:15:05,170 --> 00:15:18,570
They don't really deal with denial of service or worm simulation or man-in-the-middle attacks or fuzzing or a variety of other types of threats that concern IDS vendors or network equipment manufacturers.

137
00:15:18,890 --> 00:15:33,430
We also have Nessus which is primarily an auditing tool and is designed to report on vulnerable version numbers of services and to avoid running an actual exploit as much as possible.

138
00:15:34,350 --> 00:15:38,650
It's great for use on a live network where you don't really want to break anything.

139
00:15:39,530 --> 00:15:48,670
It's not so great for testing with live threats on network equipment, IDS systems, stuff like that.

140
00:15:49,870 --> 00:15:58,590
Historically speaking, the most widely used threat platform has been Perl or C with some escaped shellcode.

141
00:15:59,450 --> 00:16:05,690
Many threat developers are of the opinion that if you can't write an exploit in Perl, you have no business messing with it.

142
00:16:06,090 --> 00:16:13,190
This is kind of a societal safety valve, but it stands in the way of speed and efficiency in threat development.

143
00:16:14,110 --> 00:16:23,350
IDS vendors and network equipment manufacturers just want a QA guy to check off a list of threats and run a test, see what happens.

144
00:16:23,350 --> 00:16:31,550
When the CEO hears about a new threat on the news, he wants assurance that his product copes with it quickly.

145
00:16:31,550 --> 00:16:36,850
There isn't a lot of time for inefficiency, which means mucking about with Perl.

146
00:16:37,690 --> 00:16:46,450
So, a new threat platform has to provide the versatility to handle all types of attacks, not just shellcode exploits.

147
00:16:46,450 --> 00:16:57,710
It has to include tools to develop new threats quickly and the ability to run live threats, not just to check to see if something might possibly be vulnerable.

148
00:16:57,710 --> 00:16:59,370
You want to know yes or no.

149
00:17:03,860 --> 00:17:06,440
So, we're past the boring bit.

150
00:17:07,580 --> 00:17:09,520
We're on to the good stuff.

151
00:17:09,820 --> 00:17:17,480
We've talked a bit about the problems we're hoping to solve with our new systems, so now we're on to our wish list, the design goals of our new platform.

152
00:17:17,480 --> 00:17:24,800
We want one tool that can handle all possible threats, including exploit shellcode, denial of service, man-in-the-middle, and fuzzing.

153
00:17:25,060 --> 00:17:29,460
We don't want to limit ourselves to running on a particular hardware architecture.

154
00:17:29,760 --> 00:17:38,160
We might want to run from a laptop, or from a blade server, or from every blade in a bunch of...

155
00:17:38,160 --> 00:17:40,460
Wow, sorry, tequila moment.

156
00:17:43,240 --> 00:17:43,820
Racks?

157
00:17:43,820 --> 00:17:44,940
Ah, that's the word.

158
00:17:44,940 --> 00:17:45,720
Good deal.

159
00:17:45,920 --> 00:17:46,980
Yeah, one more.

160
00:17:53,760 --> 00:17:57,240
We also don't want to limit ourselves to a particular network medium.

161
00:17:58,100 --> 00:18:02,960
We want to be able to handle copper pairs, but we also want to do fiber and wireless.

162
00:18:03,620 --> 00:18:08,480
Additionally, we want to be able to target anything, regardless of what it is or where it is on the network.

163
00:18:08,480 --> 00:18:10,240
We're not limiting ourselves to services.

164
00:18:10,240 --> 00:18:15,360
In fact, we're focusing on hardware-level testing.

165
00:18:17,320 --> 00:18:29,560
Since it's often the case that a developer gets a packet capture of an attack before it's even identified, we need to support PCAP imports into our system, so you can import a PCAP file, edit it, and play it back.

166
00:18:30,460 --> 00:18:41,800
To accurately reproduce some types of network threats, such as a man-in-the-middle or a DDoS, we need the ability to support playback of network traffic from multiple sources on a network.

167
00:18:43,100 --> 00:18:56,800
We're going to require a distributed architecture where we can have a number of different threat engines on a network that can all play back different roles of a conversation, like something you import from a PCAP file.

168
00:18:57,980 --> 00:19:02,060
To accurately reproduce some types of network... oh, I just did that one.

169
00:19:02,060 --> 00:19:13,000
Our tool is going to have a few bells and whistles that make it easier to use as a threat testing platform, including the collection and aggregation of a variety of statistics.

170
00:19:13,940 --> 00:19:18,160
But statistics are insanely boring, so I'm going to skip over that bit.

171
00:19:18,280 --> 00:19:27,220
Since the execution of one threat might involve playback from different network nodes, the statistics have to be aggregated.

172
00:19:28,520 --> 00:19:32,920
And that will happen... we'll get into that in a little bit.

173
00:19:36,010 --> 00:19:37,570
Wow, I've got to take a moment.

174
00:19:40,610 --> 00:19:41,830
You guys suck.

175
00:19:52,130 --> 00:19:54,450
This is harder than it looks, guys, come on.

176
00:19:55,830 --> 00:19:56,710
Alright.

177
00:19:57,750 --> 00:20:03,830
Now we're going to do a quick review of some of the concepts of programming language theory we use in this system.

178
00:20:03,970 --> 00:20:09,830
By quick, I mean that this is probably going to go right over your heads if you never took a Foundations of CS class.

179
00:20:09,950 --> 00:20:17,890
But the reason I feel comfortable kind of skimming over it is that there's tons of books on this subject written by people much smarter than I am.

180
00:20:18,550 --> 00:20:26,150
So, if you haven't taken a Foundations class, this is basically a list of words to put into Google or Wikipedia.

181
00:20:28,630 --> 00:20:36,250
The bits we're interested in are all related to languages and translating one language to another, which is pretty much all of programming language theory.

182
00:20:36,350 --> 00:20:43,710
The most important concept is the idea of a grammar, which is a set of formal rules describing the structure of valid expressions in a language.

183
00:20:44,250 --> 00:20:46,230
Grammars serve two purposes.

184
00:20:47,490 --> 00:20:55,010
They can be used generatively to produce valid expressions, or they can be used to determine whether a given string is a valid expression in a language.

185
00:20:55,010 --> 00:20:56,930
So it's kind of like an input and output.

186
00:20:56,990 --> 00:21:02,050
You can use a grammar to generate an output, or you can use a grammar to interpret an input.

187
00:21:03,090 --> 00:21:15,110
The most common method of describing a grammar is the extended Bacchus-Noer form, or eBNF, which we'll touch on briefly later, but that's something I'll have to Google.

188
00:21:18,590 --> 00:21:19,230
Compilers.

189
00:21:19,230 --> 00:21:24,610
A compiler is something that translates a valid expression in one language to a valid expression in another language.

190
00:21:24,610 --> 00:21:26,790
It's basically a language translator.

191
00:21:28,170 --> 00:21:36,210
The compilers you're used to translate from a programming language like C to a particular architecture's instruction language.

192
00:21:36,470 --> 00:21:44,470
Or another one that many people are familiar with is the Java compiler, which translates from the Java language to Java bytecode.

193
00:21:44,670 --> 00:21:47,630
A compiler makes use of two grammars.

194
00:21:47,750 --> 00:21:53,070
The grammar of the input language for Java would be the Java language spec.

195
00:21:53,070 --> 00:21:57,810
And the grammar of the output language, in this case bytecode.

196
00:21:59,770 --> 00:22:04,970
It uses the input grammar for validation and the output grammar for generation.

197
00:22:05,670 --> 00:22:07,690
Compilers work in four stages.

198
00:22:07,950 --> 00:22:09,510
I'm just going to skim through this.

199
00:22:09,510 --> 00:22:15,210
First is lexing, where the input expression is broken into tokens based on whitespace and other syntax.

200
00:22:16,290 --> 00:22:18,510
Next, these tokens are parsed.

201
00:22:18,510 --> 00:22:24,510
During the parse, the input grammar is used to build a parse tree, which represents the meaning of the expression.

202
00:22:24,730 --> 00:22:30,670
This meaning is stored in an internal data structure called the intermediate representation.

203
00:22:31,470 --> 00:22:41,650
And finally, the output grammar is applied to the intermediate representation to generate a valid expression in the destination language that has the same meaning as the original expression.

204
00:22:47,690 --> 00:22:53,550
So, this is the key part.

205
00:22:53,890 --> 00:22:55,690
The parser generator.

206
00:22:56,170 --> 00:23:03,890
A parser generator is just a special compiler that can read its input and output grammars dynamically at runtime.

207
00:23:04,550 --> 00:23:11,090
So it's sort of like a general purpose compiler that you can use to translate any one language to any other language.

208
00:23:13,070 --> 00:23:17,670
You may have heard of YACC or Java CC.

209
00:23:20,930 --> 00:23:21,970
Bison?

210
00:23:23,550 --> 00:23:28,130
Yeah, Bison, YACC, Lex, that suite of tools like Java CC.

211
00:23:29,050 --> 00:23:31,290
If I had any books left, I'd give you one.

212
00:23:31,290 --> 00:23:32,590
I should have held out.

213
00:23:34,070 --> 00:23:36,030
I'm switching to water.

214
00:23:39,330 --> 00:23:40,850
Please.

215
00:23:42,790 --> 00:23:44,710
It's true.

216
00:23:47,170 --> 00:23:48,690
Okay.

217
00:23:48,690 --> 00:23:55,090
YACC and Java CC predominantly just generate parsing code for eBNF grammars.

218
00:23:55,090 --> 00:24:03,230
They take eBNF grammars in as an input and then those two tools are fixed for their output grammar.

219
00:24:03,230 --> 00:24:07,570
So Java CC puts out Java code that parses an eBNF spec.

220
00:24:07,950 --> 00:24:11,710
Not the spec, but the grammar specified by an eBNF file.

221
00:24:12,250 --> 00:24:22,070
The advantage of a parser generator over a compiler is that it's very easy to modify and update the input and output languages without code changes.

222
00:24:22,190 --> 00:24:26,830
You can simply update the grammar specifications and reload them.

223
00:24:27,170 --> 00:24:38,130
Because it's so easy to add support for a new grammar to a parser generator, they're good for situations where you have to deal with a large number of different languages and constantly add support for new ones.

224
00:24:38,830 --> 00:24:43,350
An example of such a situation...

225
00:24:46,970 --> 00:24:48,670
Network protocols.

226
00:24:49,110 --> 00:24:54,550
One of our stated goals is that we want one system to handle all possible threats.

227
00:24:54,790 --> 00:24:58,690
We want to be able to fuzz each field of every protocol.

228
00:24:58,830 --> 00:25:02,850
We want to deliver a malicious payload in every protocol.

229
00:25:02,850 --> 00:25:07,750
And we want to be able to intelligently DOS every protocol.

230
00:25:08,290 --> 00:25:15,110
And we want to be able to import PCAP files in any protocol, edit them, and play them back.

231
00:25:18,070 --> 00:25:25,410
I'm way too lazy to code and debug all this support for every possible protocol.

232
00:25:26,210 --> 00:25:28,330
Fortunately, there's a shortcut.

233
00:25:31,560 --> 00:25:37,760
Network protocols are languages that are designed to be easily handled by low-level code.

234
00:25:38,300 --> 00:25:41,320
As a result, most of them are very simple.

235
00:25:41,800 --> 00:25:52,320
In fact, if you exclude things like checksums and internet header lengths, network protocols can be represented by the simplest subset of grammars, the normal grammars.

236
00:25:53,740 --> 00:26:02,480
This allows us to make a lot of assumptions in writing our parser generator, which simplifies the code and speeds things up immensely.

237
00:26:04,340 --> 00:26:10,260
We deal with checksums and internet header lengths at the engine level, which we'll get to in a little bit.

238
00:26:10,780 --> 00:26:17,660
So we're going to use grammars to represent network protocols, both to understand incoming traffic and to generate outgoing traffic.

239
00:26:17,740 --> 00:26:29,820
Since there are an insanely large number of protocols out there, both public and proprietary, the parser generator will allow us to easily add support for new protocols without mucking about with our code.

240
00:26:38,230 --> 00:26:42,870
Each network protocol we specify is essentially just an ordered list of fields.

241
00:26:42,970 --> 00:26:46,890
Most protocols allow other protocols to be encapsulated in them.

242
00:26:46,930 --> 00:26:58,810
We handle this encapsulation, I'm going to call it stacking, of protocols by using a special rule, it's kind of like a non-terminal, called the payload rule, in each of our protocol grammars.

243
00:26:58,810 --> 00:27:00,770
You'll see this in a little bit.

244
00:27:01,290 --> 00:27:12,750
Each protocol that allows encapsulation will have a payload rule that can be made to point at either another protocol's grammar or to a chunk of arbitrary binary information, like a shellcode.

245
00:27:21,170 --> 00:27:26,510
This is the simplest example of a protocol specification, and it's for Ethernet.

246
00:27:28,790 --> 00:27:37,650
The start rule goes to just Ethernet, and the Ethernet production rule, on the right hand side is just the list of fields in Ethernet.

247
00:27:37,650 --> 00:27:46,670
You've got source MAC, desk MAC, packet type, and the payload rule, which is what would point to whatever you're encapsulating in Ethernet.

248
00:27:48,230 --> 00:27:56,030
The various fields go to regular expressions that you can use to validate them.

249
00:27:56,030 --> 00:28:08,450
You've got hex fields from 1-bit length, some of them are like 13 bits, they're very strange sizes, up to like 64 or 128 bits.

250
00:28:08,450 --> 00:28:16,970
But some of the data types people are used to seeing in human-readable form, IP addresses, MAC addresses, and stuff like this.

251
00:28:17,410 --> 00:28:28,670
So you can keep your regular expressions for those types of data type validations in a common location, and refer to them within your specific protocol definitions.

252
00:28:37,750 --> 00:28:52,710
One thing that's not on here, but that's important to mention, is that we can't just use a normal grammar like this, we also need to decorate the grammar with a little bit of additional information, which allows us to generate packet streams correctly,

253
00:28:52,710 --> 00:28:56,150
and to correctly deal with PCAP imports.

254
00:28:56,150 --> 00:29:05,250
The most important thing is that each field needs to be marked with its bit length, so that you know how many bits to read in, how many bits to put out.

255
00:29:12,350 --> 00:29:19,150
So each of these protocol definitions is a template for creating a series of packets.

256
00:29:19,350 --> 00:29:26,490
The user will be able to stack these templates to create a representation of any type of encapsulated network traffic.

257
00:29:26,590 --> 00:29:33,430
A common protocol stack involves combining three different protocol definitions, Ethernet, IP, and TCP.

258
00:29:35,130 --> 00:29:48,150
Ethernet's payload points to IP, IP's payload points to TCP, and TCP's payload will be, it could be empty, or it could be a shellcode, or any chunk of binary.

259
00:29:59,270 --> 00:29:59,950
Well...

260
00:30:01,270 --> 00:30:08,090
Some protocols are a little bit more complicated, and can have a number of different forms based on a type field.

261
00:30:08,090 --> 00:30:15,050
Examples of some of these protocols are ICMP, DHCP, and OSPF.

262
00:30:15,050 --> 00:30:20,070
We can still deal with these protocols by splitting up their definitions into separate chunks.

263
00:30:20,070 --> 00:30:26,210
It's kind of like making lookahead tables, if anyone's written a compiler before.

264
00:30:30,560 --> 00:30:32,680
I'm so good with Daya.

265
00:30:35,950 --> 00:30:41,590
Here's an example for OSPF, which has several different packet types.

266
00:30:41,730 --> 00:30:48,870
All of the different OSPF packets share a common header, which contains the type field indicating what the rest of the packet looks like.

267
00:30:49,050 --> 00:30:57,430
To handle this situation, we can simply create a protocol definition to represent the header, and a separate definition for each of the packet types.

268
00:30:57,430 --> 00:31:12,390
What I have been calling protocol definitions is actually somewhat inaccurate, because you may be using more than one of these grammar chunks to define a particular protocol.

269
00:31:13,870 --> 00:31:17,910
OSPF, I think, has six different packet types?

270
00:31:18,170 --> 00:31:19,690
Is it five?

271
00:31:19,690 --> 00:31:24,710
So you'd have the header, and then five subtypes that would follow from there.

272
00:31:29,710 --> 00:31:38,210
This is something we do in order to keep using normal grammars, so we can keep our nice assumptions about how to write our parser generator.

273
00:31:39,090 --> 00:31:42,770
Does anyone in here know about the LLK algorithm?

274
00:31:44,510 --> 00:31:45,750
LLK?

275
00:31:49,550 --> 00:31:50,630
Right.

276
00:31:50,630 --> 00:31:55,910
LLK basically just keeps increasing the lookahead until it finds a match.

277
00:31:56,010 --> 00:31:59,950
So it's pretty inefficient from a code standpoint.

278
00:32:01,530 --> 00:32:08,530
Using this scheme, basically breaking off the header allows us to avoid going into LLK territory, which keeps our code very simple.

279
00:32:14,330 --> 00:32:15,970
Man, this tequila.

280
00:32:16,510 --> 00:32:18,290
It's getting on top of me.

281
00:32:19,310 --> 00:32:23,550
The basic flow of creating a threat file goes like this.

282
00:32:25,770 --> 00:32:26,730
Is it?

283
00:32:29,290 --> 00:32:30,330
No, it's not...

284
00:32:31,390 --> 00:32:33,070
Thank you.

285
00:32:34,430 --> 00:32:36,110
Bunch of sadists.

286
00:32:37,310 --> 00:32:40,490
The protocol definitions are loaded into a GUI.

287
00:32:40,950 --> 00:32:52,970
The GUI examines the protocol files for information about fields, and what sort of data types they're expecting, so that it can represent the values of the various fields in the way that the user is expecting.

288
00:32:53,090 --> 00:32:56,750
This is really only an issue for Mac addresses and IP addresses.

289
00:32:56,890 --> 00:33:00,750
For your 13-bit HEX field, no one's expecting anything other than HEX.

290
00:33:04,270 --> 00:33:10,730
The user then creates a threat file by selecting which protocols to use and filling in the fields.

291
00:33:11,030 --> 00:33:23,130
This information is fed into the parser generator, which uses the selected protocol definitions as the input grammar, and outputs to a threat file, which can be stored in a database for later use.

292
00:33:29,290 --> 00:33:32,510
The GUI provides the user with three abilities.

293
00:33:32,510 --> 00:33:40,610
First, the user can select and stack protocols to create an arbitrary encapsulation of network protocols.

294
00:33:40,750 --> 00:33:50,470
Second, the user can arrange any number of these stacks in any order, and define the behavior of the threat in terms of iteration or looping.

295
00:33:50,530 --> 00:33:57,310
And finally, the user can assign functions, variables, or values to any field of any protocol.

296
00:34:07,570 --> 00:34:09,370
Here's a sample screenshot.

297
00:34:10,470 --> 00:34:14,410
It's an example of how a GUI can be used to create a protocol stack.

298
00:34:15,230 --> 00:34:25,170
All of the protocols or subsections of protocols that we have defined appear on the left, and your stack appears on the right.

299
00:34:25,750 --> 00:34:31,630
The interface must allow you to create any protocol stack you want, even ones that are complete madness.

300
00:34:33,290 --> 00:34:41,430
If you want to do three levels of Ethernet or something, we can't limit that in the GUI, because you have no idea what people are going to want to do.

301
00:34:41,430 --> 00:34:43,330
You're trying to create bad traffic.

302
00:34:43,830 --> 00:34:52,630
So you can't hold the users of your interface to any kind of sane standards.

303
00:34:53,490 --> 00:34:55,270
Common sense no longer applies.

304
00:34:59,490 --> 00:35:05,170
The interface also allows you to add a series of outputs of any combination of protocols.

305
00:35:05,790 --> 00:35:07,390
It's pretty simple.

306
00:35:07,710 --> 00:35:20,690
In this example, the left panel shows you a list of the available protocol stacks, and the user just chooses a stack and adds an empty instance of it to the series, which is on the right, although there's only one thing in the series.

307
00:35:22,630 --> 00:35:24,510
It's kind of like Ethereal, actually.

308
00:35:26,330 --> 00:35:29,090
You all have looked at PCAP files in Ethereal, I'm assuming.

309
00:35:29,090 --> 00:35:37,050
When you see a packet capture in Ethereal, in the middle panel, you see this expandable tree, and it's broken out by Ethernet frames.

310
00:35:37,330 --> 00:35:40,250
So you see your first frame, your second frame, your third frame.

311
00:35:40,250 --> 00:35:47,430
When you open those up, you see all of the protocols that are in that stack, essentially.

312
00:35:47,950 --> 00:35:54,210
So what I'm calling a stack is everything that's encapsulated in one Ethernet frame in Ethereal.

313
00:35:54,210 --> 00:35:59,150
And what I'm calling a series is like your list of all the frames.

314
00:35:59,470 --> 00:36:04,850
So basically, our GUI allows you to create these structures rather than just viewing them.

315
00:36:04,870 --> 00:36:10,450
And we'll also be able to import from PCAP, edit, boot it back out.

316
00:36:17,420 --> 00:36:24,020
And then, with your empty instance, you just fill in the values you want for each field.

317
00:36:24,020 --> 00:36:31,300
Values that are left blank should be filled in with typical defaults at the time the thread is executed.

318
00:36:31,680 --> 00:36:41,220
You'll notice that some of our fields are set to values, such as internet header length, and the flags CE, DF, and MF.

319
00:36:41,940 --> 00:36:48,980
Our GUI understands that false is 1 bit 0, and true is 1 bit 1.

320
00:36:49,700 --> 00:36:53,440
And some of our fields are variables, which start with a dollar sign.

321
00:36:54,040 --> 00:36:59,360
These values, like destination IP, can vary from run to run.

322
00:36:59,380 --> 00:37:02,180
Like every time you run the thread, you might be targeting a different machine.

323
00:37:02,400 --> 00:37:10,640
So we kind of just put little tags in here that say, hey, when you run this, we're going to ask you to fill these values in, because they're likely to be different from run to run.

324
00:37:10,640 --> 00:37:12,300
It's just a little convenience thing.

325
00:37:14,480 --> 00:37:19,520
We've also set several of our fields to functions, which start with the at symbol.

326
00:37:19,520 --> 00:37:30,730
The only function we're using here is random, which is in source IP, and source port, and sequence number, and source MAC.

327
00:37:32,440 --> 00:37:40,740
That just tells the thread engine to put in a random value for each iteration.

328
00:37:40,740 --> 00:37:45,440
It just picks a random value from the minimum to the maximum, and puts that in there.

329
00:37:46,460 --> 00:37:54,140
We have decided on a minimal subset of functions, because functions are things that get passed down to the engine.

330
00:37:54,140 --> 00:37:58,140
Things like timestamp, random values, or ranges.

331
00:37:58,140 --> 00:38:00,580
It's something you want the engine to handle at the lowest level.

332
00:38:00,780 --> 00:38:07,540
But we want to keep our engine code running quickly, so we want to minimize what we're doing with functions.

333
00:38:09,300 --> 00:38:11,780
This syntax doesn't matter at all.

334
00:38:14,060 --> 00:38:19,860
You could pick any way of specifying functions, any way of specifying variables.

335
00:38:25,420 --> 00:38:29,500
Here is our minimal function subset.

336
00:38:30,390 --> 00:38:35,910
From this, you can do most every operation that you want to.

337
00:38:39,360 --> 00:38:42,620
I guess they'd be like atomic operations.

338
00:38:44,680 --> 00:38:52,400
The most useful are range, which will range from the minimum argument to the maximum argument.

339
00:38:52,400 --> 00:39:01,320
So you could target a range of IP addresses from 192.168.0.1 to 192.168.0.255 or something like that.

340
00:39:01,320 --> 00:39:03,280
Random I already talked about.

341
00:39:03,540 --> 00:39:06,120
Random string is something you might want to do for fuzzing.

342
00:39:06,120 --> 00:39:09,740
You can generate a random ASCII string of a particular length.

343
00:39:09,900 --> 00:39:14,340
But more useful for fuzzing is the homogenous string of length X.

344
00:39:14,340 --> 00:39:16,940
Which is kind of like a fill function.

345
00:39:16,940 --> 00:39:29,720
So you can use that with range to, say, make a series of slashes in a URL request that just increase by one each time it loops through.

346
00:39:32,400 --> 00:39:35,960
Also, you need concatenation for closure.

347
00:39:36,200 --> 00:39:43,320
And checksums are best handled as a function that is something that's dealt with by the engine rather than at the designer level.

348
00:39:46,960 --> 00:39:47,620
I've got

349
00:39:55,610 --> 00:39:58,590
to hide this.

350
00:40:00,570 --> 00:40:01,890
I can't even smoke.

351
00:40:01,890 --> 00:40:03,810
Oh, you suck.

352
00:40:04,310 --> 00:40:05,470
Alright.

353
00:40:05,470 --> 00:40:16,310
The threat file just contains a representation of your threat including the stacks of protocols, the series of stacks, and all the variables and functions and values that you're using.

354
00:40:16,370 --> 00:40:20,250
One useful thing to do with threats is to include a good amount of metadata.

355
00:40:20,850 --> 00:40:25,270
Metadata descriptions and target info so you can easily sort them into a database.

356
00:40:26,170 --> 00:40:30,810
The threat file is just a serialization of all the info from the GUI.

357
00:40:30,810 --> 00:40:36,870
So it's pretty much just the information you saw on the screen before dumped out into some common format.

358
00:40:38,210 --> 00:40:40,410
You know, XML works.

359
00:40:42,170 --> 00:40:49,290
To execute the threat, the variables will have to be substituted for real values and the functions resolved.

360
00:40:53,190 --> 00:40:58,750
Which brings us to the next part of our platform, the binding and execution of a threat.

361
00:40:59,770 --> 00:41:16,430
This stage runs a threat file from your repository or your database back into the parser generator, but this time we're using the appropriate protocol grammars as the output and the threat file format as the input.

362
00:41:18,110 --> 00:41:22,610
This is also when the variables in the threat are substituted for actual values.

363
00:41:25,370 --> 00:41:33,410
This produces a chunk of binary that closely resembles the final packet stream, except for the functions which have to be resolved a little later.

364
00:41:33,850 --> 00:41:36,390
We call this the bound threat.

365
00:41:36,590 --> 00:41:47,230
The bound threat gets passed over a management interface, whatever you're using, from the design machine to the threat engine.

366
00:41:55,110 --> 00:42:00,150
The threat engine is like a virtual machine for network traffic.

367
00:42:00,330 --> 00:42:08,570
It must be a small, fast piece of code, which is why we wanted to keep the operations that we do with it fairly atomic.

368
00:42:09,250 --> 00:42:15,530
Its sole purpose is to read the bound threat in, evaluate the functions, and boot out a packet stream.

369
00:42:16,530 --> 00:42:30,550
Another important aspect of the threat engine is that it must allow clustering, so that the management machine can initiate a threat execution on several engines at once.

370
00:42:30,930 --> 00:42:34,730
So you can do like a man-in-the-middle or a multi-part conversation.

371
00:42:35,750 --> 00:42:48,250
By allowing threat definitions to contain different roles for different nodes in a cluster, you can do fairly complex stuff.

372
00:42:48,250 --> 00:42:51,040
Like the man-in-the-middle.

373
00:42:57,610 --> 00:43:01,470
Now, our last design goal.

374
00:43:01,470 --> 00:43:03,690
Import from PCAP.

375
00:43:03,990 --> 00:43:11,130
Once you have the parser generator and the protocol definitions, this is pretty straightforward.

376
00:43:11,170 --> 00:43:19,530
All you need to do is write an importer, which strips off the PCAP header, and gives you the binary of your packets.

377
00:43:19,530 --> 00:43:24,390
So you basically just get binary of all of your Ethernet frames in a series.

378
00:43:25,210 --> 00:43:37,450
You can then use your parser generator, with your protocol definitions as the input grammar, to decompose the PCAP file, and translate it into your own intermediate representation.

379
00:43:37,450 --> 00:43:38,610
Thank you.

380
00:43:38,950 --> 00:43:40,490
I'm dying.

381
00:43:59,820 --> 00:44:01,380
You people and your tequila.

382
00:44:01,380 --> 00:44:02,260
Ten?

383
00:44:05,730 --> 00:44:06,850
What?

384
00:44:07,210 --> 00:44:08,710
Oh, crap.

385
00:44:10,890 --> 00:44:11,510
Okay.

386
00:44:13,430 --> 00:44:22,870
So this time we're using the protocol definitions, which have each field for each segment of our protocol stacks, broken out by bit length.

387
00:44:22,990 --> 00:44:29,110
So you look at your list of fields and bit lengths, and you can decompose a PCAP file,

388
00:44:32,910 --> 00:44:38,630
which, like, protocol objects, you can pull out the values for all your fields and all this.

389
00:44:41,690 --> 00:44:48,310
Once you have it loaded in the GUI, you can edit it like any other threat, and boot out a threat file.

390
00:44:48,810 --> 00:44:56,670
You know, a common thing to do is to substitute some of your fields with variables, rather than just playing back the PCAP exactly as it was.

391
00:44:56,830 --> 00:45:01,030
You may want to put in, like, a different destination MAC address, or a different destination IP.

392
00:45:02,030 --> 00:45:08,090
If you're going the clustering route, there's an additional step for PCAP files with multiple traffic sources.

393
00:45:08,230 --> 00:45:13,810
The user will have to explicitly assign each source to one of the clustered threat engines.

394
00:45:13,810 --> 00:45:19,230
So if you're going for a multi-node playback, a PCAP import actually requires some user interaction.

395
00:45:26,470 --> 00:45:32,250
And here's some amazing word graphics about the general flow of a PCAP import.

396
00:45:32,250 --> 00:45:37,290
We take our protocol spec and the PCAP file, and boot out a threat file.

397
00:45:41,820 --> 00:45:51,240
So, to sum up, the task of developing network threats is essentially that of writing a series of expressions in a variety of languages.

398
00:45:51,320 --> 00:46:02,920
By using compilers or parser generators, we can automate a good portion of the grunt work and provide integrated development environments that can speed up most of the common tasks.

399
00:46:02,920 --> 00:46:10,320
We can also create more complicated and realistic test beds in the same integrated environment.

400
00:46:10,440 --> 00:46:16,220
And we can edit and playback PCAP files and deal with any current or future protocols.

401
00:46:16,280 --> 00:46:24,040
We're going to do some questions, which should be rather interesting, because I have no idea if I made any sense at all.

402
00:46:24,540 --> 00:46:26,820
But does anyone need clarification on something?

403
00:47:00,770 --> 00:47:05,990
Yeah, we kind of took a pretty serious shortcut there.

404
00:47:06,350 --> 00:47:07,290
In our protocol...

405
00:47:08,110 --> 00:47:14,890
A lot of protocols will have some sort of field which says what's encapsulated within them.

406
00:47:14,890 --> 00:47:17,090
Like Ethernet has the packet type and so on.

407
00:47:17,090 --> 00:47:18,850
Some of them don't.

408
00:47:18,850 --> 00:47:22,950
So , like TCP and FTP, for instance.

409
00:47:22,950 --> 00:47:30,270
It's like you don't know by looking at your TCP fields what, if any, protocol is encapsulated in it.

410
00:47:30,650 --> 00:47:40,790
In our case, we just added that to the protocol definitions as kind of a hint, rather than trying to figure it out automatically.

411
00:47:50,600 --> 00:47:51,940
Cool, yeah.

412
00:47:53,600 --> 00:47:54,920
Sounds good.

413
00:47:55,200 --> 00:47:56,400
Anyone else?

414
00:47:57,440 --> 00:47:58,160
Shoot.

415
00:48:00,140 --> 00:48:01,440
No demo.

416
00:48:02,460 --> 00:48:03,260
Sorry.

417
00:48:04,480 --> 00:48:05,020
It has

418
00:48:21,550 --> 00:48:27,470
to be another...

419
00:48:27,470 --> 00:48:29,890
It's something you add to the threat file.

420
00:48:33,110 --> 00:48:39,750
Yeah, you have to manually add something to the threat file and you have to manually add a case to your engine to deal with it.

421
00:48:40,030 --> 00:48:45,490
So you say, well, we want to fragment in this manner, from here to here in our series.

422
00:48:45,490 --> 00:48:49,750
And then the engine has to accommodate that.

423
00:49:11,410 --> 00:49:15,390
You mean by streams, you mean fragmentation or like sessions?

424
00:49:18,850 --> 00:49:19,570
Yeah.

425
00:49:34,140 --> 00:49:35,560
I don't think I can...

426
00:49:35,560 --> 00:49:37,660
Are we done?

427
00:49:39,160 --> 00:49:40,420
Okie dokie.

428
00:49:42,380 --> 00:49:44,160
I'm going to clear out.