[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:51.350] It's a sad, sad state of affairs. [00:56.780 --> 00:57.500] Hello. [00:57.500 --> 01:01.200] Welcome to Linguistic Platform for Threat Development, [01:01.200 --> 01:03.460] the Extreme Hangover Edition. [01:03.860 --> 01:07.280] I'm Ben Kurtz, I work for a company called Imperfect Networks [01:07.280 --> 01:08.930] out in Burlington, Massachusetts. [01:10.790 --> 01:13.790] Today I'm going to talk to you about what I have cooked up [01:13.790 --> 01:16.810] over the past year, why I did it, [01:16.810 --> 01:18.910] and how it can help you do what you do. [01:28.550 --> 01:30.550] That's all well and good, but basically I'm going to talk [01:30.550 --> 01:33.990] about a design pattern for a... [01:34.790 --> 01:37.830] I'm going to give you a view from like 30,000 feet, [01:37.830 --> 01:40.770] it's just going to be like a broad overview, [01:40.770 --> 01:42.250] real abstract. [01:42.250 --> 01:44.870] I don't really have the time to go into the sort of details [01:44.870 --> 01:49.650] I'd like, but let's see. [01:49.870 --> 01:52.270] By applying some often overlooked corners [01:52.270 --> 01:54.310] of programming language theory to the development [01:54.310 --> 01:56.830] of network attacks, we can create a new type [01:56.830 --> 01:59.910] of threat platform which can handle every conceivable [01:59.910 --> 02:03.590] network protocol and run readily on any architecture [02:03.590 --> 02:05.430] that can handle embedded Linux. [02:05.730 --> 02:07.870] The ultimate goal is to reduce the total time [02:07.870 --> 02:10.470] to develop a threat to the time it takes to research [02:10.470 --> 02:15.790] and understand its behavior, plus two minutes or so. [02:15.950 --> 02:17.990] Once the threat is implemented, we also want [02:17.990 --> 02:19.870] the ability to store it in a database [02:19.870 --> 02:22.110] and play it back whenever. [02:25.870 --> 02:29.890] This presentation is divided into four sections, roughly. [02:30.250 --> 02:31.500] First, we'll look at the motivations [02:32.030 --> 02:34.650] for a new threat platform, which is hopefully [02:34.650 --> 02:36.470] not going to be too dull. [02:36.770 --> 02:38.910] Second, we'll take a closer look at what we need [02:38.910 --> 02:41.230] threats for and how the threat development [02:41.230 --> 02:42.970] and testing cycle works. [02:42.970 --> 02:45.270] The reason I'm going to go through that is because [02:45.910 --> 02:48.630] many people here look at threat development [02:48.630 --> 02:50.950] and threat testing from an enterprise standpoint [02:50.950 --> 02:54.010] or a pen testing standpoint, and I'm kind of [02:54.010 --> 02:55.610] coming at it from a slightly different angle. [02:55.610 --> 02:57.730] I need to encompass a broader spectrum [02:57.730 --> 02:59.890] of threats in a single system. [03:00.230 --> 03:03.850] I'm looking at it more from a manufacturing testing [03:03.850 --> 03:06.250] and regression testing standpoint. [03:07.810 --> 03:09.530] I'm going to take a little time and reframe [03:10.450 --> 03:15.110] what threat testing is in terms of the talk. [03:16.730 --> 03:19.490] Next, we'll summarize the design goals [03:19.490 --> 03:21.730] of the new system, then we get into the good bit. [03:21.810 --> 03:24.530] We'll look at some ideas from programming language theory [03:24.530 --> 03:27.990] and how we can use them to get what we want. [03:29.810 --> 03:31.690] Now, motivation. [03:34.150 --> 03:36.010] Why do we want a threat development platform [03:36.010 --> 03:37.210] 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:49.330] We also want to minimize the time [03:49.330 --> 03:51.290] from the first rumor we hear of a new threat [03:51.290 --> 03:53.210] to the ability to play it back on the wire [03:53.210 --> 03:54.530] with the touch of a button. [03:55.190 --> 03:57.430] Being up to date on new threats is a foot race [03:57.430 --> 04:00.050] 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:09.930] There's two main reasons [04:09.930 --> 04:13.250] along the standard black hat, white hat divide. [04:13.870 --> 04:16.170] What I'm focusing on is we want to break [04:16.170 --> 04:19.190] network equipment and services that we develop and use [04:19.190 --> 04:21.110] so we can assure our customers [04:21.110 --> 04:24.250] of some degree of protection and reliability. [04:25.130 --> 04:27.930] There is no trust without testing. [04:28.150 --> 04:30.890] A lot of things are advertised as being secure [04:30.890 --> 04:35.150] and that's never been verified by anybody in many cases. [04:35.150 --> 04:37.950] And on the other side, [04:37.950 --> 04:42.110] we want to break stuff because we have malice in our hearts. [04:42.910 --> 04:45.250] Like any powerful technology, [04:45.330 --> 04:48.830] a threat platform can be a tool of assurance or a weapon. [04:48.930 --> 04:51.790] Since the malicious uses are fairly obvious, [04:51.790 --> 04:54.130] developing a threat and executing it quickly [04:54.130 --> 04:56.830] with a great amount of throughput, [04:56.830 --> 04:59.530] I won't really revisit this. [05:00.190 --> 05:03.390] Many security products such as intrusion detection systems [05:03.390 --> 05:04.710] are developed and brought to market [05:04.710 --> 05:08.050] with little or no testing against real live threats. [05:08.510 --> 05:10.610] Usually they're tested against a small set [05:10.610 --> 05:12.370] of handcrafted sample traffic [05:12.370 --> 05:16.070] that is designed to trigger existing threat signatures in the IDS. [05:16.210 --> 05:19.010] This means that the test cases are usually written [05:19.010 --> 05:21.470] to test what the IDS already does [05:21.470 --> 05:25.030] rather than to test its ability to protect against real threats. [05:26.630 --> 05:28.390] At some point you're going to have to test [05:28.390 --> 05:31.190] your network security products against real attacks [05:31.190 --> 05:36.070] rather than, you know, just handcrafted stuff. [05:36.070 --> 05:37.530] Otherwise you're providing your customers [05:37.530 --> 05:39.450] with only the illusion of security. [05:43.640 --> 05:46.340] There are numerous places that release vulnerabilities [05:46.340 --> 05:48.260] or exploits to the public. [05:48.500 --> 05:51.520] You probably all know most of these. [05:51.520 --> 05:56.160] You've got BugTrack, Security Focus, Full Disclosure, [05:56.160 --> 05:56.740] Mike Lynn... [05:59.080 --> 06:00.720] That's a drink. [06:00.720 --> 06:02.640] As soon as an exploit shows up on the net [06:02.640 --> 06:05.300] 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:20.910] You need to know that you're safe [06:20.910 --> 06:23.410] from each new threat as soon as it becomes public. [06:24.750 --> 06:26.550] Private threats are kind of an unknown quantity [06:26.550 --> 06:29.710] but you can definitely keep up with the mailing list. [06:29.710 --> 06:32.810] You have to do this partly out of prudence [06:32.810 --> 06:35.230] and partly because your boss called you in a panic [06:35.230 --> 06:36.910] because his boss called him in a panic [06:36.910 --> 06:38.610] because the CEO called him in a panic [06:38.610 --> 06:40.750] after hearing about some worm on the news. [06:41.510 --> 06:43.890] The threat developer needs to stay on top of the [06:43.890 --> 06:46.470] the O-Day threats, mostly to be able to say [06:46.470 --> 06:48.530] yes, we've already accounted for that [06:48.530 --> 06:50.290] and we're testing against it. [06:51.730 --> 06:53.170] You could just say this anyway [06:53.170 --> 06:54.790] but you're still going to want to actually go out [06:54.790 --> 06:57.730] and do the work before anyone checks up on you. [06:58.910 --> 07:02.330] To be assured that you can handle all publicly known threats [07:02.330 --> 07:04.270] 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:13.130] Honestly, there's only three steps here [07:13.130 --> 07:15.470] 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:23.270] This is from a manufacturing, network equipment manufacturer standpoint [07:23.270 --> 07:25.010] rather than from a pen testing [07:25.010 --> 07:29.430] or enterprise security testing standpoint. [07:30.390 --> 07:32.990] For each new threat that you want to develop and test [07:33.170 --> 07:35.270] 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:41.550] You have to figure out what it targets, [07:41.550 --> 07:44.390] what the packets look like, what protocols it uses, [07:44.390 --> 07:46.370] how it behaves, and so on. [07:47.530 --> 07:49.010] Next, you have to implement the threat [07:49.010 --> 07:52.130] which means writing the PERL code or the C code. [07:52.130 --> 07:54.510] And finally, your service or equipment is tested [07:54.510 --> 07:57.310] against the new threat to see if it's vulnerable. [07:58.570 --> 08:00.690] Then you begin the cycle again with the next threat [08:00.690 --> 08:05.830] or sometimes developing one will lead you to another like a variant. [08:09.810 --> 08:11.890] All these steps can be very time consuming [08:11.890 --> 08:15.730] to the point that many QA departments don't bother. [08:16.370 --> 08:20.130] The time period from when an exploit first enters the public domain [08:20.130 --> 08:22.210] until you release a patch to defend against it [08:22.210 --> 08:23.710] is your window of vulnerability. [08:24.350 --> 08:26.270] The testing side of the equation is at [08:26.450 --> 08:28.330] a serious disadvantage from the start [08:28.330 --> 08:30.250] since a would-be attacker can usually [08:30.250 --> 08:32.350] just download sample code for an exploit [08:32.350 --> 08:33.810] and go to town. [08:34.430 --> 08:36.350] If it takes two weeks to research, [08:36.350 --> 08:37.530] implement, and test a threat, [08:37.530 --> 08:40.070] that's including all your QA guys' vacation times, [08:40.070 --> 08:41.830] coffee breaks, and so on. [08:42.110 --> 08:43.290] Mind sweeper. [08:45.070 --> 08:46.850] But if it takes you two weeks to research, [08:46.850 --> 08:47.930] implement, and test a threat, [08:47.930 --> 08:49.610] your window of vulnerability is two weeks [08:49.610 --> 08:52.690] where an attacker doesn't need more than an hour or two [08:52.690 --> 08:56.850] 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:10.230] So what are your options to speed up threat turnaround time [09:10.230 --> 09:12.850] and to minimize your window of vulnerability? [09:13.670 --> 09:15.290] Your first option is to hire more people [09:15.290 --> 09:17.210] to handle the daily updates. [09:17.210 --> 09:19.410] Some places have upwards of 20 employees [09:19.730 --> 09:22.210] working on researching and implementing new threats [09:22.210 --> 09:23.770] as they come out. [09:24.150 --> 09:26.650] Some places. No names. [09:27.010 --> 09:30.090] This approach allows you to deal with more threats concurrently, [09:30.090 --> 09:32.730] but each threat must be developed and tested in parallel [09:32.730 --> 09:35.810] using the same time-consuming tools. [09:36.370 --> 09:38.130] So for any single threat, [09:38.130 --> 09:40.530] your window of vulnerability remains the same. [09:40.670 --> 09:42.570] It's kind of like, you know, [09:42.570 --> 09:46.310] you can't parallelize baby creation. [09:46.310 --> 09:49.090] From start to finish it takes a certain amount of time, [09:49.090 --> 09:50.990] given a certain set of tools. [09:57.170 --> 09:59.350] Alright, I'll drink for that one. [10:07.740 --> 10:09.620] The second option is to improve the tools [10:09.620 --> 10:12.180] that threat developers use to speed up the process [10:12.180 --> 10:14.140] 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:18.480] By automating the common and repetitive tasks [10:19.080 --> 10:20.480] associated with threat development [10:20.480 --> 10:22.900] and by only forcing a developer [10:22.900 --> 10:25.940] to describe the unique aspects of a threat, [10:25.940 --> 10:28.750] 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:33.540] This is going downhill quickly. [11:37.840 --> 12:07.210] I'm Ben Kurtz. [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:38.770] It's an expensive proposition for a smaller company [13:38.770 --> 13:41.870] 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 --> 13:59.230] There aren't really any college curriculums that teach this stuff [13:59.230 --> 14:05.230] 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:38.430] The downside is that the scope of the attacks are limited [14:38.430 --> 14:43.830] 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 --> 14:57.730] Metasploit and Canvas are good at what they do [14:57.730 --> 15:02.310] 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:11.650] They don't really deal with denial of service or worm simulation or man-in-the-middle attacks or fuzzing [15:11.650 --> 15:18.570] or a variety of other types of threats that concern IDS vendors or network equipment manufacturers. [15:18.890 --> 15:23.590] We also have Nessus which is primarily an auditing tool [15:23.590 --> 15:28.290] and is designed to report on vulnerable version numbers of services [15:28.290 --> 15:33.430] 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:19.730] IDS vendors and network equipment manufacturers just want a QA guy to check off a list of threats [16:19.730 --> 16:23.350] 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:53.990] It has to include tools to develop new threats quickly and the ability to run live threats, [16:53.990 --> 16:59.370] not just to check to see if something might possibly be vulnerable. You want to know yes or no. [17:03.860 --> 17:09.520] So, we're past the boring bit. We're on to the good stuff. [17:09.820 --> 17:13.700] We've talked a bit about the problems we're hoping to solve with our new systems, [17:13.700 --> 17:17.480] 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:46.980] Racks? Ah, that's the word. Good deal. 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:15.360] We're not limiting ourselves to services. In fact, we're focusing on hardware-level testing. [18:17.320 --> 18:22.760] Since it's often the case that a developer gets a packet capture of an attack before it's even identified, [18:22.760 --> 18:29.560] 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:36.200] To accurately reproduce some types of network threats, such as a man-in-the-middle or a DDoS, [18:36.200 --> 18:41.800] we need the ability to support playback of network traffic from multiple sources on a network. [18:43.100 --> 18:50.720] We're going to require a distributed architecture where we can have a number of different threat engines on a network [18:50.720 --> 18:56.800] 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:08.420] Our tool is going to have a few bells and whistles that make it easier to use as a threat testing platform, [19:08.420 --> 19:13.000] 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:25.160] Since the execution of one threat might involve playback from different network nodes, [19:25.160 --> 19:27.220] 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:24.610] Compilers. 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:09.510] Compilers work in four stages. 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:32.590] If I had any books left, I'd give you one. 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:31.270] Because it's so easy to add support for a new grammar to a parser generator, [24:31.270 --> 24:38.130] 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:46.660] In fact, if you exclude things like checksums and internet header lengths, [25:46.660 --> 25:52.320] network protocols can be represented by the simplest subset of grammars, the normal grammars. [25:53.740 --> 25:58.020] This allows us to make a lot of assumptions in writing our parser generator, [25:58.020 --> 26:02.480] 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:23.780] Since there are an insanely large number of protocols out there, both public and proprietary, [26:23.780 --> 26:29.820] 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:53.650] We handle this encapsulation, I'm going to call it stacking, of protocols by using a special rule, [26:53.650 --> 26:58.810] 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:08.090] Each protocol that allows encapsulation will have a payload rule that can be made to point at either another protocol's grammar [27:08.590 --> 27:12.750] 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:35.070] The start rule goes to just Ethernet, and the Ethernet production rule, [27:35.070 --> 27:37.650] on the right hand side is just the list of fields in Ethernet. [27:37.650 --> 27:40.870] You've got source MAC, desk MAC, packet type, and the payload rule, [27:40.870 --> 27:46.670] 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:04.130] You've got hex fields from 1-bit length, some of them are like 13 bits, [28:04.130 --> 28:08.450] they're very strange sizes, up to like 64 or 128 bits. [28:08.450 --> 28:13.030] But some of the data types people are used to seeing in human-readable form, [28:13.650 --> 28:16.970] IP addresses, MAC addresses, and stuff like this. [28:17.410 --> 28:23.910] So you can keep your regular expressions for those types of data type validations in a common location, [28:23.910 --> 28:28.670] and refer to them within your specific protocol definitions. [28:37.750 --> 28:41.410] One thing that's not on here, but that's important to mention, [28:41.410 --> 28:45.230] is that we can't just use a normal grammar like this, [28:45.230 --> 28:48.430] we also need to decorate the grammar with a little bit of additional information, [28:48.430 --> 28:52.710] 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:00.850] The most important thing is that each field needs to be marked with its bit length, [29:00.850 --> 29:05.250] 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:30.670] A common protocol stack involves combining three different protocol definitions, [29:30.670 --> 29:33.430] Ethernet, IP, and TCP. [29:35.130 --> 29:39.510] Ethernet's payload points to IP, IP's payload points to TCP, [29:39.510 --> 29:48.150] 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:03.910] Some protocols are a little bit more complicated, [30:03.910 --> 30:08.090] 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:44.870] All of the different OSPF packets share a common header, [30:44.870 --> 30:48.870] which contains the type field indicating what the rest of the packet looks like. [30:49.050 --> 30:54.250] To handle this situation, we can simply create a protocol definition to represent the header, [30:54.250 --> 30:57.430] and a separate definition for each of the packet types. [30:57.430 --> 31:05.650] What I have been calling protocol definitions is actually somewhat inaccurate, [31:05.650 --> 31:12.390] 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:33.910] This is something we do in order to keep using normal grammars, [31:33.910 --> 31:38.210] 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:06.790] Using this scheme, basically breaking off the header allows us to avoid going into LLK territory, [32:06.790 --> 32:08.530] 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:44.610] The GUI examines the protocol files for information about fields, [32:44.610 --> 32:46.570] and what sort of data types they're expecting, [32:46.570 --> 32:52.970] 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:13.770] This information is fed into the parser generator, [33:13.770 --> 33:17.510] which uses the selected protocol definitions as the input grammar, [33:17.510 --> 33:23.130] 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:45.450] Second, the user can arrange any number of these stacks in any order, [33:45.450 --> 33:50.470] 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:22.450] All of the protocols or subsections of protocols that we have defined appear on the left, [34:22.450 --> 34:25.170] 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:38.370] If you want to do three levels of Ethernet or something, we can't limit that in the GUI, [34:38.370 --> 34:41.430] 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:12.410] In this example, the left panel shows you a list of the available protocol stacks, [35:12.410 --> 35:17.910] and the user just chooses a stack and adds an empty instance of it to the series, [35:17.910 --> 35:20.690] 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:34.770] When you see a packet capture in Ethereal, in the middle panel, you see this expandable tree, [35:34.770 --> 35:37.050] 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:37.520] You'll notice that some of our fields are set to values, such as internet header length, [36:37.520 --> 36:41.220] 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:05.780] So we kind of just put little tags in here that say, [37:05.780 --> 37:08.580] hey, when you run this, we're going to ask you to fill these values in, [37:08.580 --> 37:10.640] 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:25.730] The only function we're using here is random, which is in source IP, [37:26.820 --> 37:30.730] 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:51.000] We have decided on a minimal subset of functions, [37:51.000 --> 37:54.140] 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:04.480] But we want to keep our engine code running quickly, [38:04.480 --> 38:07.540] 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:26.880] So you can use that with range to, say, make a series of slashes in a URL request [39:26.880 --> 39:29.720] 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:41.100] And checksums are best handled as a function that is something that's dealt with by the engine [39:41.100 --> 39:43.320] rather than at the designer level. [39:46.960 --> 39:58.590] I've got 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:08.350] The threat file just contains a representation of your threat [40:08.350 --> 40:12.110] including the stacks of protocols, the series of stacks, [40:12.110 --> 40:16.310] 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:33.370] So it's pretty much just the information you saw on the screen before [40:34.190 --> 40:36.870] dumped out into some common format. [40:38.210 --> 40:40.410] You know, XML works. [40:42.170 --> 40:45.530] To execute the threat, the variables will have to be substituted [40:45.530 --> 40:49.290] for real values and the functions resolved. [40:53.190 --> 40:55.950] Which brings us to the next part of our platform, [40:55.950 --> 40:58.750] the binding and execution of a threat. [40:59.770 --> 41:04.170] This stage runs a threat file from your repository or your database [41:04.170 --> 41:07.170] back into the parser generator, [41:07.170 --> 41:12.050] but this time we're using the appropriate protocol grammars as the output [41:12.050 --> 41:16.430] 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:30.350] This produces a chunk of binary that closely resembles the final packet stream, [41:30.350 --> 41:33.410] 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:40.890] The bound threat gets passed over a management interface, [41:40.890 --> 41:42.470] whatever you're using, [41:42.470 --> 41:47.230] 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:03.090] It must be a small, fast piece of code, [42:03.090 --> 42:08.570] which is why we wanted to keep the operations that we do with it fairly atomic. [42:09.250 --> 42:11.990] Its sole purpose is to read the bound threat in, [42:11.990 --> 42:15.530] evaluate the functions, and boot out a packet stream. [42:16.530 --> 42:21.330] Another important aspect of the threat engine is that it must allow clustering, [42:23.510 --> 42:30.550] 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:42.790] By allowing threat definitions to contain different roles for different nodes in a cluster, [42:42.790 --> 42:48.250] 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:08.830] Once you have the parser generator and the protocol definitions, [43:08.830 --> 43:11.130] this is pretty straightforward. [43:11.170 --> 43:13.510] All you need to do is write an importer, [43:13.510 --> 43:15.430] which strips off the PCAP header, [43:15.430 --> 43:19.530] 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:27.370] You can then use your parser generator, [43:27.370 --> 43:30.750] with your protocol definitions as the input grammar, [43:31.110 --> 43:33.430] to decompose the PCAP file, [43:33.430 --> 43:37.450] 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:16.430] So this time we're using the protocol definitions, [44:16.430 --> 44:20.890] which have each field for each segment of our protocol stacks, [44:20.890 --> 44:22.870] broken out by bit length. [44:22.990 --> 44:25.410] So you look at your list of fields and bit lengths, [44:25.410 --> 44:29.110] and you can decompose a PCAP file, [44:32.910 --> 44:36.050] which, like, protocol objects, [44:36.050 --> 44:38.630] you can pull out the values for all your fields and all this. [44:41.690 --> 44:43.250] Once you have it loaded in the GUI, [44:43.250 --> 44:45.570] you can edit it like any other threat, [44:46.250 --> 44:48.310] and boot out a threat file. [44:48.810 --> 44:51.150] You know, a common thing to do is to substitute [44:51.150 --> 44:53.150] some of your fields with variables, [44:53.150 --> 44:56.670] rather than just playing back the PCAP exactly as it was. [44:56.830 --> 44:59.090] You may want to put in, like, a different destination MAC address, [44:59.090 --> 45:01.030] or a different destination IP. [45:02.030 --> 45:03.670] If you're going the clustering route, [45:03.670 --> 45:05.510] there's an additional step for PCAP files [45:05.510 --> 45:08.090] with multiple traffic sources. [45:08.230 --> 45:11.210] The user will have to explicitly assign each source [45:11.210 --> 45:13.810] to one of the clustered threat engines. [45:13.810 --> 45:16.130] So if you're going for a multi-node playback, [45:16.290 --> 45:19.230] a PCAP import actually requires some user interaction. [45:26.470 --> 45:29.250] And here's some amazing word graphics [45:29.250 --> 45:32.250] about the general flow of a PCAP import. [45:32.250 --> 45:35.250] We take our protocol spec and the PCAP file, [45:35.250 --> 45:37.290] and boot out a threat file. [45:41.820 --> 45:44.980] So, to sum up, [45:44.980 --> 45:47.120] the task of developing network threats [45:47.120 --> 45:49.380] is essentially that of writing a series of expressions [45:49.380 --> 45:51.240] in a variety of languages. [45:51.320 --> 45:54.520] By using compilers or parser generators, [45:54.520 --> 45:57.100] we can automate a good portion of the grunt work [45:57.100 --> 46:00.280] and provide integrated development environments [46:00.280 --> 46:02.920] that can speed up most of the common tasks. [46:02.920 --> 46:04.740] We can also create more complicated [46:04.740 --> 46:07.380] and realistic test beds [46:07.920 --> 46:10.320] in the same integrated environment. [46:10.440 --> 46:13.340] And we can edit and playback PCAP files [46:13.340 --> 46:16.220] and deal with any current or future protocols. [46:16.280 --> 46:18.680] We're going to do some questions, [46:18.680 --> 46:20.500] which should be rather interesting, [46:20.500 --> 46:24.040] 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:12.010] A lot of protocols will have some sort of field [47:12.010 --> 47:14.890] 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:25.950] It's like you don't know by looking at your TCP fields [47:26.910 --> 47:30.270] what, if any, protocol is encapsulated in it. [47:30.650 --> 47:34.730] In our case, we just added that to the protocol definitions [47:35.670 --> 47:37.610] as kind of a hint, [47:37.610 --> 47:40.790] 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:27.470] It has to be another... [48:27.470 --> 48:29.890] It's something you add to the threat file. [48:33.110 --> 48:35.690] Yeah, you have to manually add something to the threat file [48:35.690 --> 48:39.750] and you have to manually add a case to your engine to deal with it. [48:40.030 --> 48:43.090] So you say, well, we want to fragment in this manner, [48:43.530 --> 48:45.490] 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.