start	end	text
4920	10120	And it turns out that when you're doing spell check, it would really help if you check all the files.
10120	13380	So sorry about the introducing thing. Oh well.
15400	21360	Okay, so we're going to talk about a lot of stuff. One of the most important things that we wanted to highlight
21360	27400	is a new way that we are keeping track of connection state as we're talking to remote systems.
27400	30900	So that's what the scatter connect is all about. And you'll see that in detail.
30900	32960	In fact, that's the first thing that we're going to hit off.
33020	36700	Then we're going to talk a little bit about the tool that we're releasing today.
36960	45600	We actually have released it previously, but this new version has somewhere around 25,000 lines of code change.
45600	51780	So it's definitely different. And then we're going to demonstrate some of what it can do.
52160	57120	So, I'm Robert Lee. I do stuff with a couple companies.
57120	60960	And this is Jack, and we also have Anthony here in the audience.
60960	66340	We've been working really hard on this stuff, so hopefully you'll be able to appreciate some of what we've been working on.
67240	72400	Okay, so nice and simple. You've all seen a TCP three-way handshake before.
72400	76800	The concept is simple. You're trying to initiate a connection. You send a SYN packet.
76800	82200	You expect a SYN ACK if it's open. You acknowledge it, and then your connection is open.
82200	85600	It's actually two one-way connections, but whatever.
87880	92780	I'm not sure if you can see this, but I'll visually walk you through what's happening here.
92840	100460	The very first process, the master control on the far left is what's going to keep track of all the state connections.
100740	107620	In this particular example, we are doing a TCP port 80 full connection with a remote host.
107620	110720	That's the one on the far right with the little globe thing.
110720	120900	What happens is the master control tells the first sender, the one on the very top, that we are trying to connect to that remote network.
120900	128160	And then the sender will actually create a packet, spoofing its source IP address to come from the receiver.
128340	132360	If you can see it, the receiver machine is the one on the far bottom.
132680	138380	When the remote host, the 192.168.1.1, receives that SYN packet,
138380	143760	it responds to the SYN packet based on the IP address that it thought it came from.
143760	145900	So that's how the receiver receives it.
145980	152560	Once the receiver receives the SYN ACK, it sends the meta information back to the master control thread,
152560	157920	who then schedules an acknowledgment to be sent through an immediate sender.
157920	159440	So that's the one in the middle.
159500	165600	So the acknowledgment is then sent back to 192.168.1.1, and the three-way handshake is complete.
165600	168660	Now, I know this looks pretty crazy, and you're probably asking yourself right now,
168660	170440	why would you do it this way?
170440	173400	And I'm glad you asked that question. We'll answer that later.
173400	176980	But the important part here is that you understand that at this point,
176980	183600	we have taken the TCP IP stack and moved it out of kernel space and essentially into user LAN space.
183600	189320	And we've made it so that you can have a three-way handshake amongst a cluster of machines.
189320	196160	But to the end machine on the right-hand side, it's all a normal connection to him.
196900	203980	Once his handshake is complete, we can also then send arbitrary payload-specific stuff.
203980	209820	So if you wanted to do a GET request or any arbitrary payload can be sent at that point.
210000	211920	Important stuff.
212540	219540	Okay, so I just explained all this, but I'll go through it one more time just for clarity.
219960	224040	The first process, again, is the unicorn scan main thread.
224080	227300	Second process is the sender that's Unisend.
227300	229540	That's the one that actually assembles the packets.
230820	234480	Again, we have the concept of batch sender and immediate sender.
234480	238980	The batch sender, it turns out, is the one that you give large work units to.
238980	244760	So you can say, I want to scan this slash 16 network, and I'm looking to do these ports.
244760	247440	And you tell it what speed to do it, et cetera, et cetera.
247440	250160	So it just goes out and sends a bazillion send packets.
250760	256760	The listener process, the one on the bottom, Unilisten, is the one that's collecting all the information that comes back to it
256760	261940	and sending all the metadata back to the main unicorn scan thread.
262380	266100	And then the immediate mode is the one that completes the three-way handshake.
267020	269300	They're not actually threads, by the way.
269300	270460	They're actually processes.
270460	271900	We just call them threads.
272040	273640	Because we're silly like that.
275480	276700	Okay, cool.
276700	278340	I've talked about all this.
278520	280580	Is that part clear at all?
280900	281560	All right, cool.
281560	282660	We did it twice.
282880	287340	Now I'm going to talk about some problems that we were banging our heads against.
287340	291660	By the way, all we do with the companies is we do a lot of security testing.
291660	293000	Really big networks.
294500	299400	We've been eating a lot of dirt with tools that didn't do what we needed to do.
299400	301440	So that's basically why we did this.
301440	306420	But one of the first problems that we ran into is the whole UDP thing.
306740	314160	Just to summarize, when you're doing UDP scanning, traditionally you're sending a UDP probe with a blank datagram.
314160	318940	And you're hoping that the machine on the other side will send you an ICMP packet.
318940	321800	So if the ports close, you'll know.
321800	326720	And you basically, the ones that you don't get the message back from, you assume that it's open.
326780	330440	The problem is it turns out people are actually using firewalls.
330440	337120	And so when you're doing testing from a remote perspective, if you can't get on the ICMP message coming back to you,
337120	339140	then it's kind of a useless process.
339140	340000	That's one of the problems.
340000	344880	The other problem is you can't go really fast, even if the machine's sitting next to you and there's no filtering going on,
344880	347060	because ICMP messages are rate limited.
347060	350280	So it's a really slow and ugly process.
350800	356400	So what we ended up doing, as a quick and dirty workaround,
356400	360620	is we were taking the individual programs like BIG or SNMP walk,
360620	365460	and we were scripting it to send the actual client probes.
365460	372080	And then we got this idea, maybe it would be cool if we had an automated way of doing all those probes
372080	376780	without having to manage the individual tools and all the individual output.
376780	378220	But we'll come back to that.
379180	387060	Another problem we had with our TCP scanning is that it was a large effort to do what we really wanted to do,
387060	391660	which is actually talk to the service that we wanted to interact with.
391660	400560	So typically if you're scanning like a Slash 8, just based on the resource limitations on your side alone,
400560	405380	usually you'll have to do a send scan first and keep track of which ports are open.
405380	410400	And then on the open ports, you can go back and actually do a banner grab.
410460	414380	And then as a third step, you can start interacting with the remote service.
414380	417820	You can use AMAP or manual testing or whatever.
418460	422860	But it's difficult, especially if you're testing a dynamic network that's really large,
422860	426680	because by the time you're done with your first pass, things have changed.
426940	430180	Because it turns out that these networks are getting really big,
430180	433500	especially now that we're starting to move into IPv6 stuff.
433500	441000	But the tools that we're using today are not really useful if you're testing 65,000 to 4 billion machines at a time.
441740	447420	And even if you were, playing with set and knock with the text output is really overwhelming.
448960	450640	Really overwhelming.
451880	457340	Okay, some more problems that we have with any vulnerability scanner that we've played with
457340	466060	is that the probes that they do don't really share the information in a way that makes a lot of sense.
466100	471600	So one of our favorite examples to make fun of is the situation where some sort of device in the middle
471600	477380	is altering the TCP IP stack enough to where your operating system probe comes back and says,
477380	479680	hey, it's an Amiga Miami OS machine.
479680	481640	Who the hell runs Amiga Miami OS?
481640	486840	But anyhow, then the second probe that actually connects to TCP port 80 and does a banner grab
486840	489400	will show you that it's an IIS 5 machine.
489680	496320	And then because they have an IPS or something actively killing connections when it sees something bad across the wire,
496320	504020	when you send your Apache exploit, it kills the session and your tool thinks that the DOS attack was successful.
504020	509400	So then you come back and find out that Apache DOS vulnerability was successful.
509500	515000	So that's fine. If you're testing one machine, you can go through the false positives and figure out what's really going on.
515000	519160	But imagine doing this times 4 billion machines. Not really useful.
519440	524680	So to be useful in the future, these modules are going to need to share the information more intelligently.
525960	529060	Some more problems that we're having is with the timing.
529740	540040	In order to more efficiently use the resources that you have available to you, we need to be able to control how fast we're sending.
540040	543660	And I'll give you the two examples in the open source space.
543660	548160	We have the scanran tool that provided a minus B option for bandwidth.
548400	553040	But I probably just haven't played with it enough.
553040	559160	But in my experience, anything over like 5K to 10K, I was noticing a lot of packet loss.
559160	561200	And it also became bursty.
561660	563880	And so it didn't really work out.
563880	570480	Mostly because of the way that the sleep timer was working and the get time of day counter was working.
570540	573900	And then with nmap, you have normal, aggressive, insane or things like that.
573900	577340	But even in insane mode, it doesn't scale to high speeds.
577420	584780	And there's a lot of paralyzation going on there that's kind of tricking you into thinking that it's doing more than it is.
584780	590720	But the timing of how fast you can go is still greatly affected by the machines that you're probing.
590720	598760	To nmap's credit, we actually got nmap to send out more packets per second than we did scanran.
601360	603720	Oh, just some raw numbers real quick.
604440	610080	With our tool at this point, on a standard copper gigabit card,
610080	614440	we're successful at sending over 160,000 packets per second reliably.
614440	621580	And we're working with some FPGA people to get that in the 500,000 to million packet per second range.
621760	625240	But we're still working on that. That's pie in the sky at this point.
626060	633920	But from an average laptop, you can expect anywhere from 17,000 to 70,000 packets per second being pretty reliable to send.
634120	639020	But you're still going to want to break it up into different processes and I'll show you why.
639640	642580	Some more mindset. Okay, so now we've told you about some problems.
642580	644500	What are we going to do to solve these problems?
644560	649240	Well, from the get-go, we were designing this with scalability in mind.
649480	653480	I talked about efficient use of resources and I'm going to give you a bus analogy.
654160	660360	Basically, I watched Sesame Street as a kid and they were trying to pollute our minds with this political message
660360	663780	that buses are better than Ferraris because they're more efficient.
664360	668540	But in the example, they had 100 kids on the left and 100 kids on the right
668540	675340	and they had three small sports cars ferreting people from one site to another site.
675340	680420	They gave them a 20-minute head start and then they had the other 100 kids all jump on one bus and just go.
681400	683340	Let me break it down technically now.
683760	689960	When you use an individual machine, there's only so fast that you can reliably send and receive packets.
689960	694500	So even if you could get Nmap or ScanRan to go at 70,000 packets per second,
694500	697460	you're not going to have any room left to receive messages.
697460	704280	And so you're going to have to throw all that back to something more reasonable around the 35,000, 30,000 packet per second range
704280	708620	if you actually want to get the messages to come back to you.
708700	712820	So that's not going to be an efficient use of even a single machine.
712840	720640	But with scalability in mind, we know that we need to be able to have one logical working scanning system
720640	726100	that can scale beyond the limitations of any single resource, any single machine.
726100	728460	So it's not the same as just going faster.
728460	732620	I quoted some really ridiculous packet per second rates from a single machine,
732620	738500	but obviously if you go that fast to any network that we're playing with today, you're going to obliterate it.
738500	745040	I mean, I've seen some of these networks with even the big high-end Juniper firewalls
745040	750380	sitting in front of multiple OC3s that fall over dead at even 8,000 packets per second
750380	753740	if they have that stupid sin scan protection thing on.
753740	758900	By the way, funny, if any Juniper people are listening, I don't get that.
758900	764120	Protection that completely doshes your CPU is... well, I don't understand that at all.
764120	765900	Anyhow, moving on.
766900	768280	Okay, accuracy.
768760	775820	If you're collecting a lot of information and it's a lot of invalid information, then you're wasting your time.
775820	780820	This is my problem with those log aggregation systems where you have the garbage in, garbage out model.
780820	783340	If you can't trust the information, it's kind of worthless.
783340	789220	One of the problems that we have with a lot of tools is they try to be smarter than is programmatically possible.
790460	795840	Basically, I think tools should introduce stimulus and record response and let the humans analyze.
795860	799580	Computers are good at doing the tedious automated parts, humans are good at thinking,
799580	802160	and we shouldn't really mix the two more than we have to.
804540	805380	Flexibility.
805720	809700	At this point, with this framework, and you'll see examples of this,
809700	815480	any stimulus that you want to introduce to the remote side, currently we support TCP and UDP,
815480	820620	but we're going to support ICP and pretty much anything else that you can do over IP.
820780	826940	And then, depending on which contracts happen, we're also going to support a lot of other protocols.
827300	833640	But if you have the hardware and you need to write something to the hardware, we're going to be able to support it in the future.
834240	835520	And then security.
835620	838520	It should go with that same, but it doesn't really.
838520	846160	We tried to put some formal thought into this, and we actually selected one of the IDS protection profiles from the Common Criteria
846160	852000	to build our implementation of the scanner against.
852000	857340	And we also provide a sample security policy for use with SELinux.
857740	863000	And yeah, that was at least in the design phase when we considered that.
863000	871480	We don't actually have the entire protection profile implemented, but we designed it so that we could when we actually release one.
871480	876180	And obviously with an open source tool, we don't have $5 million to formally go through the process,
876180	878880	but if anyone here wants to sponsor that, we would love it.
881550	882510	Cool.
884830	887830	All right, yeah, so what does it do?
887830	894410	Right, people have been calling it a port scanner, and we're hopeful that after today, they'll see that it's more than that.
894410	897550	But currently, it can do TCP and UDP port scanning.
897550	901810	It can do stateless banner grabbing or active remote OS application, blah, blah, blah.
901810	903030	It can do stuff.
903030	911210	And some more interesting things is that instead of just sending a non-protocol specific probe,
911210	915250	we actually can send the same thing that a normal client would do.
915250	917550	So let's say that you're trying to find DNS servers.
917550	921750	Instead of just sending a blank datagram to UDP port 53,
921750	926270	we support a number of different payloads out of the default config file.
926270	928950	One of them can ask it for local host.
928950	931030	One of them can do a chaos.
932950	935670	If you're talking to a bind server, you're trying to find out what version it is.
936190	944210	But now we're doing just-in-time processing to where you can stuff things in there that you need to calculate on the fly.
944210	951190	So for, like, Dan Bernstein's DNS server, we put one in there that will ask it for the IP address that you're talking to.
951190	954810	So it can stuff the IP that it's talking to in there on the fly.
954810	959750	But any other thing that you need to calculate right before creating the packet, that also works.
960710	964010	And then for TCP, it's going to become more important nowadays as well,
964010	969010	because a lot of the networks that we're testing have those things that complete the three-way handshake
969010	971370	on behalf of the devices that are behind it.
971370	977550	And so you're going to find situations where every single port on every single IP on the remote network come back as open.
977670	980670	And you need to be able to send protocol-specific payloads
980670	982890	so you can figure out which ones are tricking you.
983490	987310	Then one of the other things that we put in there is a metamorphic shellcode encoder
987310	992870	to make it so that when you are delivering other types of payloads,
992870	997590	that you can make it so that they are not easily fingerprintable.
997910	1003270	So not only is the NOPS-led metamorphic, but the encoder itself is as well.
1003610	1008050	And so basically there's nothing to write a signature for at this point.
1008050	1010370	We'll see.
1010570	1013530	Okay, and then we also can log to PCAP files.
1013530	1016490	And everything we do, and I can't stress this enough,
1016490	1023010	everything we're doing from this point forward has hooks to talk to relational databases on the back end,
1023010	1026450	because you cannot process this amount of data without one.
1027670	1030110	Okay, so now I'm going to pass the mic over to Jack.
1031270	1032990	Alright, how are we doing everyone?
1032990	1034810	Are we falling asleep yet?
1035890	1038470	Alright, I guess not.
1038610	1040870	Okay, well, there's three processes.
1040870	1043750	I guess it's pretty obvious what they do.
1043750	1045070	I'm not really going to talk about them.
1045070	1048490	Hopefully we're going to actually leave some time for some demos that we want to do.
1049510	1053670	Okay, one of the things that's different is that we try and use,
1053670	1058250	it's kind of a trivial algorithm to actually carry information inside the sequence number,
1058250	1060710	but the important part is that it's not one way.
1061010	1064790	So in other words, if we used MD5 and then lopped off part of it,
1064790	1065830	it wouldn't be one way.
1065830	1069350	So we can't do that because we actually need to do TCP connections.
1069670	1073890	The problem is that we can't actually have the guy who's sniffing and validating the sequence number
1073890	1078930	send back a question to the master thread to figure out if that's correct or not.
1078930	1083470	So we actually have to do that with a trivial algorithm.
1083750	1089470	Anyway, and then the scatter connect is we basically send out the SYN packets,
1089470	1093450	and then we gather on the syntax that we get back and act the connection
1093450	1097850	and actually do whatever it is that the scanner's configured to do.
1099390	1102390	Well, this is actually kind of long and drawn out.
1102390	1104230	What do I have, like 20 minutes left?
1105710	1107190	Half hour? Okay.
1107190	1108650	Well, I'll go through this.
1108650	1114970	It's actually 30 steps to a symbol SYN scan.
1114970	1120430	So basically, obviously the user would invoke the scanner from the command line.
1120530	1123930	It actually reads the configuration file first,
1123930	1127810	and then the actual command line arguments are parsed at that point
1127810	1130650	so that you can override the configuration file.
1130650	1134970	But if you get sick of typing certain options over and over, you just put them in there.
1135190	1139730	Anyways, the master process actually opens up binary modules
1139730	1142650	through whatever facilities on the system.
1142650	1147250	We use the LTDL interface now, so it's a bit more portable.
1147250	1150990	And we actually have auto-conf too, which is pretty ugly.
1151230	1157110	Anyways, the master process figures out whether or not you want it to run in a clustered mode,
1157110	1158930	which is a command line argument.
1159390	1162670	But this is actually for a local scan,
1162670	1167810	so we're just assuming that the master thread is actually going to fork children.
1168330	1171850	And then it actually records some information about them,
1171850	1175850	and it actually uses... the IPC goes through a Unix domain socket,
1175850	1179030	so it's actually a little bit faster than it used to be.
1179230	1182730	And then it actually uses signals to synchronize,
1182730	1187110	which I believe is actually causing us problems portability-wise.
1187110	1193010	So one of the problems with this release is that on certain machines the signals disappear,
1193010	1196190	and if we actually use reliable signals, it's not portable.
1196190	1199090	So we might actually have to change that a bit.
1199090	1206430	And then actually the important part is that we can't make the assumption we know what the other processes do,
1206930	1209210	because we don't know if we're in cluster mode.
1209210	1213030	If we're in cluster mode, all we know is an IP address and a port,
1213030	1215930	and we don't know if it's going to send or listen.
1216370	1217990	So we actually...
1217990	1219470	That's an important piece right there.
1219470	1222890	You don't have to have 16 machines to port scan one machine.
1222890	1224610	You can do it all from one machine.
1224690	1226790	You can't scale if you need to.
1226790	1227570	Okay.
1228450	1232850	Anyways, they connect up and send some information.
1232850	1236670	It's actually the listener that contains a lot of useful information early on,
1236670	1239810	because it's the guy who has the IP address that matters.
1239870	1243790	So actually during that handshake it sends the information back.
1244150	1245050	Anyways.
1245150	1248050	And then everyone syncs up with a ready message.
1248390	1251590	And then the master actually does something called stirring,
1251590	1255170	which actually would be doing the work unit allocation.
1255170	1258910	And we actually have some stuff to do that, but it's kind of specific to us.
1258910	1263870	I think in the general code we actually don't have anything useful when it stirs,
1263870	1268890	but if you actually had a big cluster and you wanted to actually distribute the send packets
1268890	1273230	amongst geographical areas, that's where you would put the code to do that,
1273230	1277890	so that you would actually have the shortest amount of hops between each sender.
1278230	1278730	Okay.
1278850	1279730	Anyways.
1279810	1280630	Right.
1280630	1286070	Then the listener fires up, and then we send the sender a batch work unit,
1286070	1288670	which basically means it's not going to get interrupted.
1289030	1295530	So hopefully, or if it's a batch sender anyways, we don't want to interrupt him.
1295530	1301790	We don't want him to have to pull the IPC channel, because it slows him down.
1302310	1302690	Okay.
1302690	1305030	And then the master just goes into a loop.
1305850	1309050	And when the sender finishes, it sends a work done,
1309050	1313150	and then we actually check to see if it has more work.
1313650	1316570	And if not, it just goes into a timeout state.
1316570	1323030	But meanwhile, any important things that are happening, such as TCP connections,
1323030	1326930	it will actually respond to those while it's in its timeout state,
1327450	1329930	or actually throughout the entire scan.
1330070	1333130	And then actually the master tells the sender and listener to quit,
1333130	1334610	and then the scan's done.
1335690	1336310	Right.
1336310	1336650	Okay.
1336650	1342150	So the important part about all that nonsense is that a general stack that's inside of a kernel
1343170	1346390	normally knows the remote target that it's going to talk to,
1346390	1348770	or remote host and port, but we don't.
1348770	1350590	So we actually don't have that model.
1350590	1352330	It's completely incompatible.
1352550	1359030	So we actually just kind of redid some of the decisions inside the stack
1359030	1363370	so that it would better fit a model where we don't know that information,
1363370	1365830	which is the scatter stuff.
1365830	1366530	Anyways.
1367410	1368290	Right.
1368530	1369030	Okay.
1369030	1373550	One of the important things is a lot of stacks we'll use like a hash table,
1373550	1376930	but we can't actually do that because we don't actually know who's going to talk to us.
1376930	1382330	A good example is if we scan a network that actually syntax packets,
1382330	1386370	it'll fill up our state table, and if there's nothing behind that device,
1386370	1389930	we'll have a bunch of dead entries in our connection table,
1389930	1394010	and we'll probably guess the size of the hash table wrong by doing that,
1394010	1397090	and our hash table will basically either collide to death,
1397090	1400870	or it'll have a bunch of linked lists instead of being a hash table.
1400870	1403110	So that's obviously not what we want.
1403110	1408870	We actually have to pick a data structure that responds better to unpredictable things like that,
1408870	1410370	like a binary tree.
1410850	1411590	Anyways.
1412410	1413630	So, right.
1413630	1417530	The point is that we can only have constant time lookups
1417530	1422210	if we actually have a good guess of how many things we're going to talk to which we don't.
1422210	1424110	So obviously we can't do that.
1424790	1430370	And even though generally we won't fill the table, we don't really know what's going to happen.
1431130	1432970	So, that's right.
1433150	1434010	Anyways.
1434930	1438270	Even if we did have a hash table that was big enough,
1438270	1440610	and this is just obviously for IPv4,
1441170	1443830	it would be quite a bit of RAM, actually,
1443830	1448030	just to store the connection entries, not even the data.
1448030	1450330	So that's obviously not very realistic.
1451250	1453410	It's just for the keys.
1453450	1454130	Anyway.
1454550	1454910	Yeah.
1454910	1455610	And, right.
1455610	1460010	Like I said, the reason why that's important is because as time goes on,
1460010	1463410	we see more and more devices to compensate for high-latency networks
1463410	1467910	that will answer part of the three-way handshake to kind of offload that
1467910	1472730	and keep the connection open for the high-latency device or improve the performance.
1472730	1474810	Or DDoS protection.
1475430	1479530	Or some obfuscated thing that people do to try and improve security,
1479530	1481430	which I'm sure that works real well.
1481970	1482650	Anyway.
1484690	1485290	Yeah.
1485290	1489170	So, one of the design goals is we need to be able to withstand this sort of network
1489170	1490870	because we're testing them.
1491510	1492170	Anyway.
1492850	1493510	Okay.
1493510	1493810	Yeah.
1493810	1494870	And, right.
1494870	1495750	I already said this.
1495750	1497450	We use a red-black tree.
1497470	1500150	One of the possible improvements that we're thinking of doing
1500150	1506670	is actually most of the time that's probably an unnecessary data structure.
1506670	1511350	We could probably use just a hash table and have constant time.
1511630	1515170	So, actually, what we want to do is actually switch on the fly.
1515170	1520090	If we actually pass a threshold and our table load goes too high,
1520090	1523010	we can actually dump it and turn it into a binary tree on the fly
1523010	1527550	and put a most frequently used cache in front of that.
1527550	1529510	I think it says it in here anyway.
1530350	1535970	Not most recently used, by the way, because that would be a lot of connections closing.
1536110	1541410	We actually need the top talkers, so you actually want it frequent, not recent.
1541730	1542330	Okay.
1542370	1543310	Anyway.
1543310	1548410	Here's some numbers about why we chose the algorithms that we did.
1548870	1554010	And the point was is we're just trying to prove that our measurements are somewhat valid,
1554010	1556350	but we actually inline some assembly in here.
1556350	1561310	You can see it here where we actually read the timestamp counter on a Pentium CPU.
1561670	1566050	And then we're actually going to overload our table and see what the performance numbers look like.
1566050	1569570	And these numbers actually indicate clock ticks.
1569810	1575510	And you can see here with the various load factors that our chained hash table
1576290	1582210	turns quickly into a bunch of linked lists and our red-black tree does not,
1582210	1585130	which should not be much of a surprise anyways.
1585270	1589590	But what's interesting about this actually is the amount of load that it took
1589590	1594090	for the CPU to actually get a really expensive lookup,
1594090	1597890	which is mainly due to the, I suppose, large cache on the CPU.
1597890	1599110	I'm not really sure.
1599330	1605690	But I figured at least that after a load of maybe four that it would start dropping off.
1605690	1612030	But it actually took somewhere around 30 for the performance to just go really badly.
1613510	1616090	So, right, I just actually talked about that before.
1616090	1616770	Whoops.
1617270	1620650	Right, but yeah, reset acts obviously we don't want to cache.
1620650	1623130	And those are always going to be the most recent.
1623130	1626550	So if we're going to do anything to improve the performance, we can't do that.
1626550	1632870	We actually have to calculate how often certain connections are being used and cache those instead.
1633330	1634370	Right.
1634950	1639250	Okay, so here's some examples from the payload configuration stuff.
1639350	1641630	It's just ASCII text.
1641990	1645470	But we tried to make it so that you could copy and paste stuff from like C
1645470	1647990	and put it into the configuration file.
1648230	1651090	But anyway, here's some example stuff.
1651310	1654470	Obviously UDP is a UDP payload.
1654710	1658750	If you don't get that, then I guess this is not going to make any sense.
1659350	1662770	And then the destination port is actually next.
1662770	1666950	And then the source port being negative one is just a wild card to say whatever.
1667130	1669890	And then one is interesting. That's a payload group.
1669890	1672810	One of the things that you can do is you can chain include files together
1672810	1675090	or configuration files together.
1675190	1679810	So you can actually have a bunch of different things that are meant for different sorts of environments.
1680150	1684110	Like, for example, if you want to scan for like Windows Trojans,
1684110	1687870	which are pretty popular, you probably want to put them in their own payload group.
1687870	1692690	And then you can just use the minus big G and then the numeric option for that payload group.
1692690	1695550	To kind of make that a little bit easier to do.
1696130	1700670	And actually, we have now TCP payloads, which we didn't have before.
1700970	1703470	And it's not still a real socket.
1703530	1707910	It's kind of a trigger response mechanism, but we try and do some TCP stuff.
1707930	1712130	But it turns out it's real hard because we actually emulate the operating system
1712130	1713930	we're appearing to come from.
1713930	1716790	So our stack code is non-trivial, unfortunately.
1717510	1720490	But for right now, you can definitely do this sort of thing
1720490	1723610	and test for, for example, open relays.
1724290	1726130	Anyway, and here's some screenshots.
1726130	1728210	Can you guys even see what that says?
1728390	1730930	No. I'm going to explain it.
1730930	1738070	This is a module written in C that's actually an HTTP module.
1738190	1740030	And it just does a head request.
1740310	1744650	And it's probably like, I don't know, 47 lines, apparently.
1745210	1748550	But that's what it looks like.
1748550	1753150	Okay, this is actually running a, I don't know, was this?
1753150	1757190	Yeah, this was actually a cluster that was Connect scanning
1757190	1759610	against Yahoo.com on port 80.
1760990	1766070	And you can see that at the end here, it's got some TCP statistics,
1766070	1767430	which are interesting.
1767430	1770290	But for each host, you can actually see a banner.
1770330	1773090	Now, that's probably not terribly exciting.
1773550	1776470	Here's probably some better contrast for you,
1776470	1779930	so you can understand why we did some of the things that we did.
1780010	1784330	This is actually a screenshot of Nmap scanning a website.
1785090	1788630	And it actually comes back and just says that those things are open.
1789190	1792670	And it took eight seconds or something, too.
1792790	1798450	But we can actually do the same thing and finish it in four seconds.
1798870	1800730	Well, I guess this really isn't race.
1800730	1802910	But the idea is, if you see here,
1802910	1807010	you can see, like, five open ports coming back,
1807010	1809110	which is identical to what we saw before.
1809130	1811310	But during the actual SYN scan,
1811310	1813170	we actually did the connection and grabbed the banner
1813770	1817170	without actually initiating another connection.
1817190	1822870	And we actually can tell what port really is open at high rates.
1823590	1826670	Okay. Here we go.
1826670	1829090	I can do these live, actually. We have internet.
1829090	1831530	Okay. Would you rather see live demos?
1831530	1833370	Because these things are kind of hard to read.
1833410	1836250	Yeah. Okay. Let's do some live stuff. Hang on.
1844540	1846300	Assuming my connection isn't dead.
1846300	1847380	All right. Cool.
1851260	1854060	So what you see here at this first screen,
1854060	1857560	locus-casio-3, that's our master thread.
1858540	1861940	4 is our... what is that?
1861940	1863980	That's the listener.
1863980	1867620	It's listening on the IP address that we're going to be sending from.
1867620	1870820	This one's number 5. This is actually the sender.
1870820	1872380	So just so you can see what that is.
1872380	1874400	And I'm just making sure that they're live and well.
1874400	1875720	And they appear to be.
1875880	1878680	So the first demo here.
1878680	1881700	Let me look inside this file real quick.
1883280	1887020	Well, unfortunately, no.
1889040	1890640	Maybe. Yeah.
1890720	1892980	We'll try, but all bets are off.
1892980	1895020	If everything breaks, it's your fault.
1911480	1913060	It's real big.
1917230	1917950	Okay.
1921560	1923200	I assume that's better.
1924900	1926440	You have to forgive me.
1926440	1929720	We're pretty hard on our laptops, and some of our keys are missing.
1936200	1939440	Okay. So this first one, I just wanted to show you inside it
1939440	1941140	so you knew I wasn't really cheating.
1941140	1943860	It's just a stupid shell script that runs my command for me.
1943960	1947160	Minus E, PGSQLDB just says for the output module,
1947160	1949100	go ahead and dump everything to a database.
1949120	1951080	I'm specifying the source IP to come from,
1951080	1953340	although in cluster mode, you don't really need to do that.
1953340	1955320	Minus V means a little bit more verbose.
1955420	1959420	W6 means emulate the Linux TCP IP stack properties,
1959420	1962180	mostly because that's the one that we've spent the most time with
1962180	1965840	to make sure that the connect mode stuff is reliable.
1966000	1968860	The minus Z is where we specify our drones.
1968860	1972120	Right now, the IPC channel is not protected.
1972120	1974200	Normally, if you're in a sensitive environment
1974200	1976400	or an environment that has any type of malice,
1976400	1982100	you would want to protect that over an encrypted channel of some sort.
1982240	1985040	I would have to recommend IPSec for that.
1985680	1988080	I've actually tested that. It works pretty well.
1988080	1993260	Minus big L5 is how long to wait after the batch sending is done.
1993260	1998920	Minus little r 9,000 means we're going to send around 9,000 packets per second.
1998920	2002140	We actually go a little bit lower than whatever you specify,
2002140	2004780	but it won't exceed 9,000 packets per second.
2004780	2010480	The 66.0.0.0.16 just means go to that CIDR block
2010480	2014320	and do 161 for the port, the disk port.
2014320	2016100	Minus MU is UDP mode,
2016100	2019220	and then minus big I is for impatient people like me
2019220	2021160	so you can see the data right away.
2021160	2022020	Right.
2028330	2031150	Which, of course, you don't actually want to use minus big I
2031150	2032730	when you're doing a scan that matters
2032730	2035970	because it's going to block on the master thread to write to the terminal,
2035970	2037250	which is fairly silly.
2037870	2041550	And it's not doing what I want, so I'm confused.
2046110	2047830	It's the font, man.
2072860	2074340	There you go. Okay.
2074340	2079700	So now these are some SNMP public community string version 1 machines
2079700	2080920	that are responding.
2080920	2083420	As you see, we're doing a slash 16 network,
2083420	2085560	and we're done sending,
2085560	2087500	and we're just waiting the five-second timeout,
2087500	2090380	and then it's going to process the results,
2090380	2092880	and it'll spit it back here pretty soon.
2093080	2096100	We're actually, I think, repeating the scan three times,
2096100	2099400	so if you're wondering why it's just sitting there now,
2099400	2103260	it's actually sending different SNMP payloads to try and get everyone.
2111560	2114540	XOR. It's pretty ugly, actually.
2114720	2116680	We're actually trying to figure out a better algorithm
2116680	2121600	that'll favor randomizing the more significant bits first,
2121600	2124000	but I actually haven't had time to get around to that,
2124000	2126220	so it just kind of XORs a random word.
2126220	2130500	So that was a slash 16 for SNMP with multiple payloads,
2130500	2132940	but those are absolutely open
2132940	2136560	because we sent a public community string request,
2136560	2138540	and it sent us back responses.
2138540	2142900	The TTL is wrapping over, thanks to our insane font size,
2142900	2144960	but if it wasn't, you would be able to see
2145600	2148140	the time-to-load value of the packet that's coming back to you,
2148140	2149900	and so you can quickly, as you're looking through it,
2149900	2153680	you can spot Windows Novell stacks versus Unix stacks
2153680	2156140	versus routing infrastructure.
2156180	2158400	But all of that went back to a database
2158400	2159980	that we may be able to show you,
2159980	2161200	but I don't want to run out of time
2161200	2163560	because we have some really cool fireworks at the end.
2169100	2172340	Some more demo 2.
2172360	2173740	This one is SMTP.
2173740	2177860	This one's actually going to look for open relay servers
2177860	2179640	in the same block,
2179640	2182200	and now we're actually doing three-way handshakes
2182200	2183560	with all those guys.
2183600	2185720	So this is TCP port 25.
2185720	2187920	We are absolutely connecting to them on port 25
2187920	2193420	and sending enough of a payload to elicit...
2193420	2195940	Well, basically what I did is I said,
2195940	2199360	I'm coming from an email address that I control,
2199360	2201600	sending to another email address that I control,
2201600	2203980	and that way I can get bounces back
2204380	2205900	telling me that I was a bad person,
2205900	2207960	or I can actually get the email that I sent.
2208080	2210220	But then, either way,
2210220	2212340	I still get the banner of all the systems
2212340	2213680	that we just talked to.
2214040	2215100	So if nothing else,
2215100	2217920	I now have version information in my database
2217920	2219420	that I can search through and say,
2219420	2221180	show me all the send mailboxes.
2221220	2222600	One thing that's important, too,
2222600	2224240	is that he had the immediate mode on,
2224240	2226260	but he was doing TCP connections,
2226260	2228440	so all the immediate things that needed to happen right away
2228440	2229560	got stalled.
2229720	2232780	So some of the TCP connections will actually kind of fail.
2232780	2234400	It makes for a better demo,
2234400	2236880	but you wouldn't do that in production, obviously.
2237380	2239940	Okay, so this next one is an HTTP GET request.
2239940	2241800	Again, we're going to connect to TCP port 80
2243180	2247340	and just hit all the people that are listening on port 80
2247340	2249800	and we'll do a GET request against them.
2251680	2252640	Yeah.
2263880	2268100	Okay, so that was a pretty simple GET request here.
2268420	2270600	That was a really small range.
2270600	2271840	Let's look at that.
2271880	2272980	That's just a slash 30.
2272980	2274960	That's Yahoo with a slash 30.
2275220	2276880	So, piece of cake, right?
2277120	2281180	Okay, let's see what else we have here.
2281880	2284700	Oh, I wanted to show you what was in the slide.
2285640	2286440	Sorry.
2286440	2291340	This is Nmap with port 70 through 82
2291340	2293560	against dietsecurity.com.
2293560	2296300	All ports come back open, which is what we expect
2296300	2298520	because we have a stupid device in the middle
2298520	2300920	that protects us from DDoS.
2302520	2305120	But here's with the unicorn scan
2305120	2307980	where we can actually enumerate what the protocol
2307980	2310540	behind the three-way handshake looks like.
2310540	2312620	So you see here that even though
2312620	2314400	the other ones came back as open,
2314400	2316920	in your database you can do a pretty simple
2317800	2320680	select statement to throw away the garbage properties.
2320840	2324300	And sometimes you'll even get better information
2324300	2326360	about the stack properties itself
2326360	2330540	because once you get sent to the right application
2330540	2332420	behind it, there's going to be telltale signs
2332420	2333960	that you're talking to a different device
2333960	2335660	than the one that actually completed the three-way handshake
2335660	2336580	for you.
2336920	2338560	But, yeah, it's pretty easy at this point
2338560	2339600	where you can actually...
2340060	2342600	It's kind of like the UDP situation all over again.
2342600	2344580	You know, in the UDP, again,
2344580	2346620	now we're sending real protocol payloads
2346620	2349180	as opposed to just counting on ICP messages.
2349200	2350920	But now in TCP land,
2350920	2353120	we're actually sending real protocol information
2353120	2354740	so we can get away from these devices
2354740	2356840	that just SYNAC everything.
2364310	2367990	This is just showing that we can do multiple payloads
2367990	2368830	all on one.
2368830	2373150	So this one's sending like 50 or so different payloads.
2373150	2374870	We've got some DNS servers,
2374870	2376630	we've got some SNMP servers.
2376910	2379030	Port 2367, don't know what that is.
2379490	2382130	137, yeah, all these are coming back to us now.
2382430	2384470	And I guess this is just showing off,
2385470	2389090	you know, what it looks like to do multiple payloads.
2389090	2391290	So that was the easy stuff.
2391450	2393310	Now comes the tricky part.
2393690	2394690	Hang on.
2407830	2410270	Okay, so I'm going to talk about what we're going to do now
2410270	2411290	and hopefully it won't break
2411710	2414230	because I was still writing code for it last night.
2415550	2419450	Anyway, what we do is we do basically a TCP connect scan
2420650	2422250	on port 80.
2422330	2423910	And there's actually a CGI script
2423910	2426010	that has a really dumb coding error in it.
2426290	2428630	We actually had some other stuff that we were going to do
2428630	2431490	but the political climate kind of got ugly.
2431490	2433030	Yeah, we were going to release some fun stuff
2433030	2436230	but unfortunately nobody wants to hear that sort of thing these days.
2436610	2440430	So we actually just reused some other stuff we had.
2440710	2442730	But basically it does a three-way handshake
2442730	2447670	and it actually generates the XOR encoder on the fly,
2447670	2449130	which is metamorphic.
2449650	2452790	And it actually does a two-stage exploit.
2452790	2454350	One of the problems that I had, though,
2454350	2459510	was that I didn't have enough time to write the two-stage NetBSD assembly.
2459510	2463310	So I cheated and used someone else's stuff
2463310	2464410	and it doesn't work.
2464410	2466730	So that just goes to show me...
2467330	2468450	Okay, so right.
2468450	2470350	We generate a metamorphic first stage
2470350	2471850	and we send the payload.
2472550	2474810	What we're supposed to want to do here
2474810	2478310	is Apache hands all the CGI scripts,
2478430	2482190	a writable file descriptor on two bits, the error logs.
2482190	2483910	So the first thing that we do in our shellcode
2483910	2485450	is we truncate that.
2485730	2490930	We create a socket and connect back to a second stage server
2490930	2494510	and we send it some information about the platform that we've just...
2494510	2496930	or the process that we've just compromised.
2497210	2500470	And we actually just send back a 32-bit word
2500470	2504930	saying what predefined constant that was.
2504930	2505530	So...
2505530	2508230	And then the shellcode server sends back
2508230	2513130	the length of the payload that we're going to send in the second stage
2513130	2517490	and it does memmap and opens up an anonymous memory region
2517490	2519010	at a fixed address.
2519010	2522550	And it loads a hacked binary into that area
2522550	2526390	and jumps to the beginning of the file,
2526390	2527470	which then...
2527470	2529450	And I mentioned that the ELF is hacked
2529450	2532610	because we actually overwrote the first part of the ELF header
2532610	2535850	with some assembly to jump to the entry point.
2536770	2540510	But the important point is that the second stage is written in C.
2540510	2543350	It's similar to the impurity stuff, actually.
2544110	2544830	Anyway.
2544970	2547390	And then we transfer control to the second stage code
2547390	2549870	by jumping to the ELF entry point.
2551310	2552630	Yeah. Oh, right.
2552630	2555090	So this is the part where I do it and it doesn't break.
2566060	2566720	Okay.
2566720	2568780	This is the NetBSD box.
2569420	2570040	Okay.
2570040	2572720	As you can see, this shellcode doesn't work.
2572760	2576740	So the only thing we can do is just look at port 4444.
2580300	2582420	This is the second stage server.
2585220	2588220	And then we actually have two of these clients.
2588220	2591040	One of them actually uses ncurses, so it opens up new windows
2591040	2592000	every time you get a shell.
2592000	2592980	It's kind of neat.
2592980	2595260	But we're having some terminal issues.
2595380	2597060	And we can't figure out ncurses.
2597060	2598080	It's kind of above us.
2598080	2599500	So we don't have that yet.
2620460	2622180	What he's going to show you is the TCP dump,
2622180	2624360	so you can see that it really is working.
2624680	2626040	And we're being told to hurry up,
2626040	2627480	so you've got like five seconds.
2627480	2628580	Okay, so here it goes.
2628580	2629620	Hopefully it won't crash.
2629800	2632260	Okay, so we first have to grab an IP address
2633300	2634700	that's not attached to the kernel.
2634700	2636460	As you can see, some stuff went by here.
2636460	2637600	So it connected to port 80.
2637600	2639680	It sent our payload.
2639700	2640740	And now we have a shell.
2640740	2644200	Yeah, so you can see here that the second stage shellcode server
2644200	2645260	got it connected back.
2645260	2647120	It sent back the word that said it was...
2647120	2649520	This particular one was Linux x86.
2649520	2651300	The important part about that demo, though,
2651300	2653280	is that after it got the...
2653280	2655060	It connected to two different hosts.
2655060	2656420	And after it got the SYNAC back,
2656420	2658100	it did operating system detection,
2658100	2662400	and it sent a platform-specific exploit to it on the fly.
2662400	2665900	It knew how to generate a platform-specific exploit on the fly.
2665920	2667060	So that was actually pretty cool.
2667060	2669700	Unfortunately, we don't have time to explain in more detail.
2669700	2672060	But if you're interested, come find us.
2672060	2672660	Yeah.
2672760	2675480	And you can actually watch DVDs in ASCII,
2675480	2677780	which was the entire point of doing that.
