WEBVTT 00:26.940 --> 00:30.240 Hey, is that Finnish kid Miko here at all? 00:30.750 --> 00:32.340 The Finnish kid? 00:32.520 --> 00:33.840 Yeah. 00:34.020 --> 00:35.880 Nah, I guess not. 00:43.540 --> 00:44.580 Foundation. 00:44.620 --> 00:45.280 It's 00:49.090 --> 00:51.350 a sad, sad state of affairs. 00:56.780 --> 00:57.500 Hello. 00:57.500 --> 01:03.460 Welcome to Linguistic Platform for Threat Development, the Extreme Hangover Edition. 01:03.860 --> 01:08.930 I'm Ben Kurtz, I work for a company called Imperfect Networks out in Burlington, Massachusetts. 01:10.790 --> 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. 01:28.550 --> 01:33.990 That's all well and good, but basically I'm going to talk about a design pattern for a... 01:34.790 --> 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. 01:42.250 --> 01:49.650 I don't really have the time to go into the sort of details I'd like, but let's see. 01:49.870 --> 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. 02:05.730 --> 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. 02:15.950 --> 02:22.110 Once the threat is implemented, we also want the ability to store it in a database and play it back whenever. 02:25.870 --> 02:29.890 This presentation is divided into four sections, roughly. 02:30.250 --> 02:36.470 First, we'll look at the motivations for a new threat platform, which is hopefully not going to be too dull. 02:36.770 --> 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. 02:42.970 --> 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. 02:55.610 --> 02:59.890 I need to encompass a broader spectrum of threats in a single system. 03:00.230 --> 03:06.250 I'm looking at it more from a manufacturing testing and regression testing standpoint. 03:07.810 --> 03:15.110 I'm going to take a little time and reframe what threat testing is in terms of the talk. 03:16.730 --> 03:21.730 Next, we'll summarize the design goals of the new system, then we get into the good bit. 03:21.810 --> 03:27.990 We'll look at some ideas from programming language theory and how we can use them to get what we want. 03:29.810 --> 03:31.690 Now, motivation. 03:34.150 --> 03:37.210 Why do we want a threat development platform in the first place? 03:37.570 --> 03:40.230 Simply, we want to break stuff. 03:41.030 --> 03:43.970 We want to break stuff and we're incredibly lazy. 03:44.290 --> 03:47.610 We want a tool that makes it easier to break stuff quickly. 03:48.010 --> 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. 03:55.190 --> 04:00.050 Being up to date on new threats is a foot race and anything that helps us go faster is our friend. 04:05.430 --> 04:07.270 Why do we want to break stuff? 04:08.170 --> 04:13.250 There's two main reasons along the standard black hat, white hat divide. 04:13.870 --> 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. 04:25.130 --> 04:27.930 There is no trust without testing. 04:28.150 --> 04:35.150 A lot of things are advertised as being secure and that's never been verified by anybody in many cases. 04:35.150 --> 04:42.110 And on the other side, we want to break stuff because we have malice in our hearts. 04:42.910 --> 04:48.830 Like any powerful technology, a threat platform can be a tool of assurance or a weapon. 04:48.930 --> 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. 05:00.190 --> 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. 05:08.510 --> 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. 05:16.210 --> 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. 05:26.630 --> 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. 05:36.070 --> 05:39.450 Otherwise you're providing your customers with only the illusion of security. 05:43.640 --> 05:48.260 There are numerous places that release vulnerabilities or exploits to the public. 05:48.500 --> 05:51.520 You probably all know most of these. 05:51.520 --> 05:56.740 You've got BugTrack, Security Focus, Full Disclosure, Mike Lynn... 05:59.080 --> 06:00.720 That's a drink. 06:00.720 --> 06:05.300 As soon as an exploit shows up on the net every potential attacker has access to it. 06:06.440 --> 06:07.320 Me? 06:09.460 --> 06:10.560 I do? 06:13.930 --> 06:16.010 I've got to put a stop to that right now. 06:17.730 --> 06:18.610 Alright. 06:19.470 --> 06:23.410 You need to know that you're safe from each new threat as soon as it becomes public. 06:24.750 --> 06:29.710 Private threats are kind of an unknown quantity but you can definitely keep up with the mailing list. 06:29.710 --> 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. 06:41.510 --> 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. 06:51.730 --> 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. 06:58.910 --> 07:04.270 To be assured that you can handle all publicly known threats you have to keep up the mailing lists. 07:04.710 --> 07:07.850 Zero-day protection requires zero-day testing. 07:11.370 --> 07:15.470 Honestly, there's only three steps here but it looks better with five. 07:17.310 --> 07:19.890 We're going to spend a few minutes talking about threat testing. 07:19.890 --> 07:29.430 This is from a manufacturing, network equipment manufacturer standpoint rather than from a pen testing or enterprise security testing standpoint. 07:30.390 --> 07:35.270 For each new threat that you want to develop and test a threat developer goes through several steps. 07:35.470 --> 07:37.570 And that's three, not five. 07:38.510 --> 07:40.070 First, the threat must be researched. 07:40.070 --> 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. 07:47.530 --> 07:52.130 Next, you have to implement the threat which means writing the PERL code or the C code. 07:52.130 --> 07:57.310 And finally, your service or equipment is tested against the new threat to see if it's vulnerable. 07:58.570 --> 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. 08:09.810 --> 08:15.730 All these steps can be very time consuming to the point that many QA departments don't bother. 08:16.370 --> 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. 08:24.350 --> 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. 08:34.430 --> 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. 08:42.110 --> 08:43.290 Mind sweeper. 08:45.070 --> 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. 08:58.610 --> 09:01.490 It's easier to break something than it is to fix it. 09:03.390 --> 09:05.870 So if you're on the defense, you have a disadvantage. 09:07.790 --> 09:12.850 So what are your options to speed up threat turnaround time and to minimize your window of vulnerability? 09:13.670 --> 09:17.210 Your first option is to hire more people to handle the daily updates. 09:17.210 --> 09:23.770 Some places have upwards of 20 employees working on researching and implementing new threats as they come out. 09:24.150 --> 09:25.510 Some places. 09:25.610 --> 09:26.650 No names. 09:27.010 --> 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. 09:36.370 --> 09:40.530 So for any single threat, your window of vulnerability remains the same. 09:40.670 --> 09:46.310 It's kind of like, you know, you can't parallelize baby creation. 09:46.310 --> 09:50.990 From start to finish it takes a certain amount of time, given a certain set of tools. 09:57.170 --> 09:59.350 Alright, I'll drink for that one. 10:07.740 --> 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. 10:14.340 --> 10:16.160 And that's what we're going to talk about. 10:16.160 --> 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. 10:35.220 --> 10:37.880 This is probably not a popular idea. 10:37.880 --> 10:39.760 I love my job. 10:40.000 --> 10:42.880 My inclination is to say, hey, we'll hire more people. 10:42.880 --> 10:46.280 We'll give more people jobs that they can love. 10:46.740 --> 10:48.840 But this is an expensive proposition. 10:48.840 --> 10:50.080 You suck. 10:58.990 --> 11:00.990 I'm trying not to. 11:01.110 --> 11:03.010 Peer pressure, you know. 11:07.590 --> 11:10.190 That was your fault, man. 11:13.110 --> 11:14.730 You have a drinking song? 11:21.010 --> 11:23.110 He just did. 11:23.230 --> 11:25.730 This is 11:31.900 --> 11:33.540 going downhill quickly. 11:37.840 --> 11:40.580 I'm Ben Kurtz 12:06.330 --> 12:07.210 . 12:47.980 --> 12:51.780 This is tequila, you know. 12:59.030 --> 13:00.270 Yeah. 13:03.830 --> 13:06.350 Only in the morning, right. 13:09.850 --> 13:10.790 All right. 13:15.630 --> 13:16.350 Very good. 13:16.350 --> 13:17.950 Well, I've got to press on. 13:17.950 --> 13:19.250 Or I'm going to run over. 13:22.730 --> 13:25.890 I can't actually focus on my notes at the moment. 13:28.170 --> 13:29.210 All right. 13:29.490 --> 13:31.490 So, where was I? 13:31.490 --> 13:33.890 We were talking about hiring more people, right. 13:34.690 --> 13:36.610 Or not hiring more people, right. 13:36.610 --> 13:41.870 It's an expensive proposition for a smaller company and a difficult proposition for a larger company. 13:42.730 --> 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. 13:49.590 --> 13:53.370 Yeah, it's a problem. 13:56.610 --> 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. 14:05.230 --> 14:07.150 Which is you guys, really. 14:10.470 --> 14:16.330 Even if you do find a skilled security guru, you're going to want to maximize his or her output. 14:16.370 --> 14:18.690 This means we need better tools. 14:22.970 --> 14:26.590 There are a couple of existing threat platforms. 14:28.290 --> 14:30.690 Metasploit is pretty cool. 14:30.690 --> 14:35.870 It gives you a mix and match ability with exploits written in Perl and various types of shell codes. 14:35.870 --> 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. 14:43.870 --> 14:50.330 It doesn't provide an easy interface or any regression testing tools or reporting. 14:51.130 --> 14:54.670 There's also Canvas which is similar but in Python. 14:55.590 --> 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. 15:02.310 --> 15:05.170 It's more of an enterprise pen testing type solution. 15:05.170 --> 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. 15:18.890 --> 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. 15:34.350 --> 15:38.650 It's great for use on a live network where you don't really want to break anything. 15:39.530 --> 15:48.670 It's not so great for testing with live threats on network equipment, IDS systems, stuff like that. 15:49.870 --> 15:58.590 Historically speaking, the most widely used threat platform has been Perl or C with some escaped shellcode. 15:59.450 --> 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. 16:06.090 --> 16:13.190 This is kind of a societal safety valve, but it stands in the way of speed and efficiency in threat development. 16:14.110 --> 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. 16:23.350 --> 16:31.550 When the CEO hears about a new threat on the news, he wants assurance that his product copes with it quickly. 16:31.550 --> 16:36.850 There isn't a lot of time for inefficiency, which means mucking about with Perl. 16:37.690 --> 16:46.450 So, a new threat platform has to provide the versatility to handle all types of attacks, not just shellcode exploits. 16:46.450 --> 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. 16:57.710 --> 16:59.370 You want to know yes or no. 17:03.860 --> 17:06.440 So, we're past the boring bit. 17:07.580 --> 17:09.520 We're on to the good stuff. 17:09.820 --> 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. 17:17.480 --> 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. 17:25.060 --> 17:29.460 We don't want to limit ourselves to running on a particular hardware architecture. 17:29.760 --> 17:38.160 We might want to run from a laptop, or from a blade server, or from every blade in a bunch of... 17:38.160 --> 17:40.460 Wow, sorry, tequila moment. 17:43.240 --> 17:43.820 Racks? 17:43.820 --> 17:44.940 Ah, that's the word. 17:44.940 --> 17:45.720 Good deal. 17:45.920 --> 17:46.980 Yeah, one more. 17:53.760 --> 17:57.240 We also don't want to limit ourselves to a particular network medium. 17:58.100 --> 18:02.960 We want to be able to handle copper pairs, but we also want to do fiber and wireless. 18:03.620 --> 18:08.480 Additionally, we want to be able to target anything, regardless of what it is or where it is on the network. 18:08.480 --> 18:10.240 We're not limiting ourselves to services. 18:10.240 --> 18:15.360 In fact, we're focusing on hardware-level testing. 18:17.320 --> 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. 18:30.460 --> 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. 18:43.100 --> 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. 18:57.980 --> 19:02.060 To accurately reproduce some types of network... oh, I just did that one. 19:02.060 --> 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. 19:13.940 --> 19:18.160 But statistics are insanely boring, so I'm going to skip over that bit. 19:18.280 --> 19:27.220 Since the execution of one threat might involve playback from different network nodes, the statistics have to be aggregated. 19:28.520 --> 19:32.920 And that will happen... we'll get into that in a little bit. 19:36.010 --> 19:37.570 Wow, I've got to take a moment. 19:40.610 --> 19:41.830 You guys suck. 19:52.130 --> 19:54.450 This is harder than it looks, guys, come on. 19:55.830 --> 19:56.710 Alright. 19:57.750 --> 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. 20:03.970 --> 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. 20:09.950 --> 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. 20:18.550 --> 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. 20:28.630 --> 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. 20:36.350 --> 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. 20:44.250 --> 20:46.230 Grammars serve two purposes. 20:47.490 --> 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. 20:55.010 --> 20:56.930 So it's kind of like an input and output. 20:56.990 --> 21:02.050 You can use a grammar to generate an output, or you can use a grammar to interpret an input. 21:03.090 --> 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. 21:18.590 --> 21:19.230 Compilers. 21:19.230 --> 21:24.610 A compiler is something that translates a valid expression in one language to a valid expression in another language. 21:24.610 --> 21:26.790 It's basically a language translator. 21:28.170 --> 21:36.210 The compilers you're used to translate from a programming language like C to a particular architecture's instruction language. 21:36.470 --> 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. 21:44.670 --> 21:47.630 A compiler makes use of two grammars. 21:47.750 --> 21:53.070 The grammar of the input language for Java would be the Java language spec. 21:53.070 --> 21:57.810 And the grammar of the output language, in this case bytecode. 21:59.770 --> 22:04.970 It uses the input grammar for validation and the output grammar for generation. 22:05.670 --> 22:07.690 Compilers work in four stages. 22:07.950 --> 22:09.510 I'm just going to skim through this. 22:09.510 --> 22:15.210 First is lexing, where the input expression is broken into tokens based on whitespace and other syntax. 22:16.290 --> 22:18.510 Next, these tokens are parsed. 22:18.510 --> 22:24.510 During the parse, the input grammar is used to build a parse tree, which represents the meaning of the expression. 22:24.730 --> 22:30.670 This meaning is stored in an internal data structure called the intermediate representation. 22:31.470 --> 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. 22:47.690 --> 22:53.550 So, this is the key part. 22:53.890 --> 22:55.690 The parser generator. 22:56.170 --> 23:03.890 A parser generator is just a special compiler that can read its input and output grammars dynamically at runtime. 23:04.550 --> 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. 23:13.070 --> 23:17.670 You may have heard of YACC or Java CC. 23:20.930 --> 23:21.970 Bison? 23:23.550 --> 23:28.130 Yeah, Bison, YACC, Lex, that suite of tools like Java CC. 23:29.050 --> 23:31.290 If I had any books left, I'd give you one. 23:31.290 --> 23:32.590 I should have held out. 23:34.070 --> 23:36.030 I'm switching to water. 23:39.330 --> 23:40.850 Please. 23:42.790 --> 23:44.710 It's true. 23:47.170 --> 23:48.690 Okay. 23:48.690 --> 23:55.090 YACC and Java CC predominantly just generate parsing code for eBNF grammars. 23:55.090 --> 24:03.230 They take eBNF grammars in as an input and then those two tools are fixed for their output grammar. 24:03.230 --> 24:07.570 So Java CC puts out Java code that parses an eBNF spec. 24:07.950 --> 24:11.710 Not the spec, but the grammar specified by an eBNF file. 24:12.250 --> 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. 24:22.190 --> 24:26.830 You can simply update the grammar specifications and reload them. 24:27.170 --> 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. 24:38.830 --> 24:43.350 An example of such a situation... 24:46.970 --> 24:48.670 Network protocols. 24:49.110 --> 24:54.550 One of our stated goals is that we want one system to handle all possible threats. 24:54.790 --> 24:58.690 We want to be able to fuzz each field of every protocol. 24:58.830 --> 25:02.850 We want to deliver a malicious payload in every protocol. 25:02.850 --> 25:07.750 And we want to be able to intelligently DOS every protocol. 25:08.290 --> 25:15.110 And we want to be able to import PCAP files in any protocol, edit them, and play them back. 25:18.070 --> 25:25.410 I'm way too lazy to code and debug all this support for every possible protocol. 25:26.210 --> 25:28.330 Fortunately, there's a shortcut. 25:31.560 --> 25:37.760 Network protocols are languages that are designed to be easily handled by low-level code. 25:38.300 --> 25:41.320 As a result, most of them are very simple. 25:41.800 --> 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. 25:53.740 --> 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. 26:04.340 --> 26:10.260 We deal with checksums and internet header lengths at the engine level, which we'll get to in a little bit. 26:10.780 --> 26:17.660 So we're going to use grammars to represent network protocols, both to understand incoming traffic and to generate outgoing traffic. 26:17.740 --> 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. 26:38.230 --> 26:42.870 Each network protocol we specify is essentially just an ordered list of fields. 26:42.970 --> 26:46.890 Most protocols allow other protocols to be encapsulated in them. 26:46.930 --> 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. 26:58.810 --> 27:00.770 You'll see this in a little bit. 27:01.290 --> 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. 27:21.170 --> 27:26.510 This is the simplest example of a protocol specification, and it's for Ethernet. 27:28.790 --> 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. 27:37.650 --> 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. 27:48.230 --> 27:56.030 The various fields go to regular expressions that you can use to validate them. 27:56.030 --> 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. 28:08.450 --> 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. 28:17.410 --> 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. 28:37.750 --> 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, 28:52.710 --> 28:56.150 and to correctly deal with PCAP imports. 28:56.150 --> 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. 29:12.350 --> 29:19.150 So each of these protocol definitions is a template for creating a series of packets. 29:19.350 --> 29:26.490 The user will be able to stack these templates to create a representation of any type of encapsulated network traffic. 29:26.590 --> 29:33.430 A common protocol stack involves combining three different protocol definitions, Ethernet, IP, and TCP. 29:35.130 --> 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. 29:59.270 --> 29:59.950 Well... 30:01.270 --> 30:08.090 Some protocols are a little bit more complicated, and can have a number of different forms based on a type field. 30:08.090 --> 30:15.050 Examples of some of these protocols are ICMP, DHCP, and OSPF. 30:15.050 --> 30:20.070 We can still deal with these protocols by splitting up their definitions into separate chunks. 30:20.070 --> 30:26.210 It's kind of like making lookahead tables, if anyone's written a compiler before. 30:30.560 --> 30:32.680 I'm so good with Daya. 30:35.950 --> 30:41.590 Here's an example for OSPF, which has several different packet types. 30:41.730 --> 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. 30:49.050 --> 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. 30:57.430 --> 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. 31:13.870 --> 31:17.910 OSPF, I think, has six different packet types? 31:18.170 --> 31:19.690 Is it five? 31:19.690 --> 31:24.710 So you'd have the header, and then five subtypes that would follow from there. 31:29.710 --> 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. 31:39.090 --> 31:42.770 Does anyone in here know about the LLK algorithm? 31:44.510 --> 31:45.750 LLK? 31:49.550 --> 31:50.630 Right. 31:50.630 --> 31:55.910 LLK basically just keeps increasing the lookahead until it finds a match. 31:56.010 --> 31:59.950 So it's pretty inefficient from a code standpoint. 32:01.530 --> 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. 32:14.330 --> 32:15.970 Man, this tequila. 32:16.510 --> 32:18.290 It's getting on top of me. 32:19.310 --> 32:23.550 The basic flow of creating a threat file goes like this. 32:25.770 --> 32:26.730 Is it? 32:29.290 --> 32:30.330 No, it's not... 32:31.390 --> 32:33.070 Thank you. 32:34.430 --> 32:36.110 Bunch of sadists. 32:37.310 --> 32:40.490 The protocol definitions are loaded into a GUI. 32:40.950 --> 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. 32:53.090 --> 32:56.750 This is really only an issue for Mac addresses and IP addresses. 32:56.890 --> 33:00.750 For your 13-bit HEX field, no one's expecting anything other than HEX. 33:04.270 --> 33:10.730 The user then creates a threat file by selecting which protocols to use and filling in the fields. 33:11.030 --> 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. 33:29.290 --> 33:32.510 The GUI provides the user with three abilities. 33:32.510 --> 33:40.610 First, the user can select and stack protocols to create an arbitrary encapsulation of network protocols. 33:40.750 --> 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. 33:50.530 --> 33:57.310 And finally, the user can assign functions, variables, or values to any field of any protocol. 34:07.570 --> 34:09.370 Here's a sample screenshot. 34:10.470 --> 34:14.410 It's an example of how a GUI can be used to create a protocol stack. 34:15.230 --> 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. 34:25.750 --> 34:31.630 The interface must allow you to create any protocol stack you want, even ones that are complete madness. 34:33.290 --> 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. 34:41.430 --> 34:43.330 You're trying to create bad traffic. 34:43.830 --> 34:52.630 So you can't hold the users of your interface to any kind of sane standards. 34:53.490 --> 34:55.270 Common sense no longer applies. 34:59.490 --> 35:05.170 The interface also allows you to add a series of outputs of any combination of protocols. 35:05.790 --> 35:07.390 It's pretty simple. 35:07.710 --> 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. 35:22.630 --> 35:24.510 It's kind of like Ethereal, actually. 35:26.330 --> 35:29.090 You all have looked at PCAP files in Ethereal, I'm assuming. 35:29.090 --> 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. 35:37.330 --> 35:40.250 So you see your first frame, your second frame, your third frame. 35:40.250 --> 35:47.430 When you open those up, you see all of the protocols that are in that stack, essentially. 35:47.950 --> 35:54.210 So what I'm calling a stack is everything that's encapsulated in one Ethernet frame in Ethereal. 35:54.210 --> 35:59.150 And what I'm calling a series is like your list of all the frames. 35:59.470 --> 36:04.850 So basically, our GUI allows you to create these structures rather than just viewing them. 36:04.870 --> 36:10.450 And we'll also be able to import from PCAP, edit, boot it back out. 36:17.420 --> 36:24.020 And then, with your empty instance, you just fill in the values you want for each field. 36:24.020 --> 36:31.300 Values that are left blank should be filled in with typical defaults at the time the thread is executed. 36:31.680 --> 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. 36:41.940 --> 36:48.980 Our GUI understands that false is 1 bit 0, and true is 1 bit 1. 36:49.700 --> 36:53.440 And some of our fields are variables, which start with a dollar sign. 36:54.040 --> 36:59.360 These values, like destination IP, can vary from run to run. 36:59.380 --> 37:02.180 Like every time you run the thread, you might be targeting a different machine. 37:02.400 --> 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. 37:10.640 --> 37:12.300 It's just a little convenience thing. 37:14.480 --> 37:19.520 We've also set several of our fields to functions, which start with the at symbol. 37:19.520 --> 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. 37:32.440 --> 37:40.740 That just tells the thread engine to put in a random value for each iteration. 37:40.740 --> 37:45.440 It just picks a random value from the minimum to the maximum, and puts that in there. 37:46.460 --> 37:54.140 We have decided on a minimal subset of functions, because functions are things that get passed down to the engine. 37:54.140 --> 37:58.140 Things like timestamp, random values, or ranges. 37:58.140 --> 38:00.580 It's something you want the engine to handle at the lowest level. 38:00.780 --> 38:07.540 But we want to keep our engine code running quickly, so we want to minimize what we're doing with functions. 38:09.300 --> 38:11.780 This syntax doesn't matter at all. 38:14.060 --> 38:19.860 You could pick any way of specifying functions, any way of specifying variables. 38:25.420 --> 38:29.500 Here is our minimal function subset. 38:30.390 --> 38:35.910 From this, you can do most every operation that you want to. 38:39.360 --> 38:42.620 I guess they'd be like atomic operations. 38:44.680 --> 38:52.400 The most useful are range, which will range from the minimum argument to the maximum argument. 38:52.400 --> 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. 39:01.320 --> 39:03.280 Random I already talked about. 39:03.540 --> 39:06.120 Random string is something you might want to do for fuzzing. 39:06.120 --> 39:09.740 You can generate a random ASCII string of a particular length. 39:09.900 --> 39:14.340 But more useful for fuzzing is the homogenous string of length X. 39:14.340 --> 39:16.940 Which is kind of like a fill function. 39:16.940 --> 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. 39:32.400 --> 39:35.960 Also, you need concatenation for closure. 39:36.200 --> 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. 39:46.960 --> 39:47.620 I've got 39:55.610 --> 39:58.590 to hide this. 40:00.570 --> 40:01.890 I can't even smoke. 40:01.890 --> 40:03.810 Oh, you suck. 40:04.310 --> 40:05.470 Alright. 40:05.470 --> 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. 40:16.370 --> 40:20.250 One useful thing to do with threats is to include a good amount of metadata. 40:20.850 --> 40:25.270 Metadata descriptions and target info so you can easily sort them into a database. 40:26.170 --> 40:30.810 The threat file is just a serialization of all the info from the GUI. 40:30.810 --> 40:36.870 So it's pretty much just the information you saw on the screen before dumped out into some common format. 40:38.210 --> 40:40.410 You know, XML works. 40:42.170 --> 40:49.290 To execute the threat, the variables will have to be substituted for real values and the functions resolved. 40:53.190 --> 40:58.750 Which brings us to the next part of our platform, the binding and execution of a threat. 40:59.770 --> 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. 41:18.110 --> 41:22.610 This is also when the variables in the threat are substituted for actual values. 41:25.370 --> 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. 41:33.850 --> 41:36.390 We call this the bound threat. 41:36.590 --> 41:47.230 The bound threat gets passed over a management interface, whatever you're using, from the design machine to the threat engine. 41:55.110 --> 42:00.150 The threat engine is like a virtual machine for network traffic. 42:00.330 --> 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. 42:09.250 --> 42:15.530 Its sole purpose is to read the bound threat in, evaluate the functions, and boot out a packet stream. 42:16.530 --> 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. 42:30.930 --> 42:34.730 So you can do like a man-in-the-middle or a multi-part conversation. 42:35.750 --> 42:48.250 By allowing threat definitions to contain different roles for different nodes in a cluster, you can do fairly complex stuff. 42:48.250 --> 42:51.040 Like the man-in-the-middle. 42:57.610 --> 43:01.470 Now, our last design goal. 43:01.470 --> 43:03.690 Import from PCAP. 43:03.990 --> 43:11.130 Once you have the parser generator and the protocol definitions, this is pretty straightforward. 43:11.170 --> 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. 43:19.530 --> 43:24.390 So you basically just get binary of all of your Ethernet frames in a series. 43:25.210 --> 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. 43:37.450 --> 43:38.610 Thank you. 43:38.950 --> 43:40.490 I'm dying. 43:59.820 --> 44:01.380 You people and your tequila. 44:01.380 --> 44:02.260 Ten? 44:05.730 --> 44:06.850 What? 44:07.210 --> 44:08.710 Oh, crap. 44:10.890 --> 44:11.510 Okay. 44:13.430 --> 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. 44:22.990 --> 44:29.110 So you look at your list of fields and bit lengths, and you can decompose a PCAP file, 44:32.910 --> 44:38.630 which, like, protocol objects, you can pull out the values for all your fields and all this. 44:41.690 --> 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. 44:48.810 --> 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. 44:56.830 --> 45:01.030 You may want to put in, like, a different destination MAC address, or a different destination IP. 45:02.030 --> 45:08.090 If you're going the clustering route, there's an additional step for PCAP files with multiple traffic sources. 45:08.230 --> 45:13.810 The user will have to explicitly assign each source to one of the clustered threat engines. 45:13.810 --> 45:19.230 So if you're going for a multi-node playback, a PCAP import actually requires some user interaction. 45:26.470 --> 45:32.250 And here's some amazing word graphics about the general flow of a PCAP import. 45:32.250 --> 45:37.290 We take our protocol spec and the PCAP file, and boot out a threat file. 45:41.820 --> 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. 45:51.320 --> 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. 46:02.920 --> 46:10.320 We can also create more complicated and realistic test beds in the same integrated environment. 46:10.440 --> 46:16.220 And we can edit and playback PCAP files and deal with any current or future protocols. 46:16.280 --> 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. 46:24.540 --> 46:26.820 But does anyone need clarification on something? 47:00.770 --> 47:05.990 Yeah, we kind of took a pretty serious shortcut there. 47:06.350 --> 47:07.290 In our protocol... 47:08.110 --> 47:14.890 A lot of protocols will have some sort of field which says what's encapsulated within them. 47:14.890 --> 47:17.090 Like Ethernet has the packet type and so on. 47:17.090 --> 47:18.850 Some of them don't. 47:18.850 --> 47:22.950 So , like TCP and FTP, for instance. 47:22.950 --> 47:30.270 It's like you don't know by looking at your TCP fields what, if any, protocol is encapsulated in it. 47:30.650 --> 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. 47:50.600 --> 47:51.940 Cool, yeah. 47:53.600 --> 47:54.920 Sounds good. 47:55.200 --> 47:56.400 Anyone else? 47:57.440 --> 47:58.160 Shoot. 48:00.140 --> 48:01.440 No demo. 48:02.460 --> 48:03.260 Sorry. 48:04.480 --> 48:05.020 It has 48:21.550 --> 48:27.470 to be another... 48:27.470 --> 48:29.890 It's something you add to the threat file. 48:33.110 --> 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. 48:40.030 --> 48:45.490 So you say, well, we want to fragment in this manner, from here to here in our series. 48:45.490 --> 48:49.750 And then the engine has to accommodate that. 49:11.410 --> 49:15.390 You mean by streams, you mean fragmentation or like sessions? 49:18.850 --> 49:19.570 Yeah. 49:34.140 --> 49:35.560 I don't think I can... 49:35.560 --> 49:37.660 Are we done? 49:39.160 --> 49:40.420 Okie dokie. 49:42.380 --> 49:44.160 I'm going to clear out.