And it turns out that when you're doing spell check, it would really help if you check all the files.
So sorry about the introducing thing. Oh well.
Okay, so we're going to talk about a lot of stuff. One of the most important things that we wanted to highlight
is a new way that we are keeping track of connection state as we're talking to remote systems.
So that's what the scatter connect is all about. And you'll see that in detail.
In fact, that's the first thing that we're going to hit off.
Then we're going to talk a little bit about the tool that we're releasing today.
We actually have released it previously, but this new version has somewhere around 25,000 lines of code change.
So it's definitely different. And then we're going to demonstrate some of what it can do.
So, I'm Robert Lee. I do stuff with a couple companies.
And this is Jack, and we also have Anthony here in the audience.
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.
Okay, so nice and simple. You've all seen a TCP three-way handshake before.
The concept is simple. You're trying to initiate a connection. You send a SYN packet.
You expect a SYN ACK if it's open. You acknowledge it, and then your connection is open.
It's actually two one-way connections, but whatever.
I'm not sure if you can see this, but I'll visually walk you through what's happening here.
The very first process, the master control on the far left is what's going to keep track of all the state connections.
In this particular example, we are doing a TCP port 80 full connection with a remote host.
That's the one on the far right with the little globe thing.
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.
And then the sender will actually create a packet, spoofing its source IP address to come from the receiver.
If you can see it, the receiver machine is the one on the far bottom.
When the remote host, the 192.168.1.1, receives that SYN packet,
it responds to the SYN packet based on the IP address that it thought it came from.
So that's how the receiver receives it.
Once the receiver receives the SYN ACK, it sends the meta information back to the master control thread,
who then schedules an acknowledgment to be sent through an immediate sender.
So that's the one in the middle.
So the acknowledgment is then sent back to 192.168.1.1, and the three-way handshake is complete.
Now, I know this looks pretty crazy, and you're probably asking yourself right now,
why would you do it this way?
And I'm glad you asked that question. We'll answer that later.
But the important part here is that you understand that at this point,
we have taken the TCP IP stack and moved it out of kernel space and essentially into user LAN space.
And we've made it so that you can have a three-way handshake amongst a cluster of machines.
But to the end machine on the right-hand side, it's all a normal connection to him.
Once his handshake is complete, we can also then send arbitrary payload-specific stuff.
So if you wanted to do a GET request or any arbitrary payload can be sent at that point.
Important stuff.
Okay, so I just explained all this, but I'll go through it one more time just for clarity.
The first process, again, is the unicorn scan main thread.
Second process is the sender that's Unisend.
That's the one that actually assembles the packets.
Again, we have the concept of batch sender and immediate sender.
The batch sender, it turns out, is the one that you give large work units to.
So you can say, I want to scan this slash 16 network, and I'm looking to do these ports.
And you tell it what speed to do it, et cetera, et cetera.
So it just goes out and sends a bazillion send packets.
The listener process, the one on the bottom, Unilisten, is the one that's collecting all the information that comes back to it
and sending all the metadata back to the main unicorn scan thread.
And then the immediate mode is the one that completes the three-way handshake.
They're not actually threads, by the way.
They're actually processes.
We just call them threads.
Because we're silly like that.
Okay, cool.
I've talked about all this.
Is that part clear at all?
All right, cool.
We did it twice.
Now I'm going to talk about some problems that we were banging our heads against.
By the way, all we do with the companies is we do a lot of security testing.
Really big networks.
We've been eating a lot of dirt with tools that didn't do what we needed to do.
So that's basically why we did this.
But one of the first problems that we ran into is the whole UDP thing.
Just to summarize, when you're doing UDP scanning, traditionally you're sending a UDP probe with a blank datagram.
And you're hoping that the machine on the other side will send you an ICMP packet.
So if the ports close, you'll know.
And you basically, the ones that you don't get the message back from, you assume that it's open.
The problem is it turns out people are actually using firewalls.
And so when you're doing testing from a remote perspective, if you can't get on the ICMP message coming back to you,
then it's kind of a useless process.
That's one of the problems.
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,
because ICMP messages are rate limited.
So it's a really slow and ugly process.
So what we ended up doing, as a quick and dirty workaround,
is we were taking the individual programs like BIG or SNMP walk,
and we were scripting it to send the actual client probes.
And then we got this idea, maybe it would be cool if we had an automated way of doing all those probes
without having to manage the individual tools and all the individual output.
But we'll come back to that.
Another problem we had with our TCP scanning is that it was a large effort to do what we really wanted to do,
which is actually talk to the service that we wanted to interact with.
So typically if you're scanning like a Slash 8, just based on the resource limitations on your side alone,
usually you'll have to do a send scan first and keep track of which ports are open.
And then on the open ports, you can go back and actually do a banner grab.
And then as a third step, you can start interacting with the remote service.
You can use AMAP or manual testing or whatever.
But it's difficult, especially if you're testing a dynamic network that's really large,
because by the time you're done with your first pass, things have changed.
Because it turns out that these networks are getting really big,
especially now that we're starting to move into IPv6 stuff.
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.
And even if you were, playing with set and knock with the text output is really overwhelming.
Really overwhelming.
Okay, some more problems that we have with any vulnerability scanner that we've played with
is that the probes that they do don't really share the information in a way that makes a lot of sense.
So one of our favorite examples to make fun of is the situation where some sort of device in the middle
is altering the TCP IP stack enough to where your operating system probe comes back and says,
hey, it's an Amiga Miami OS machine.
Who the hell runs Amiga Miami OS?
But anyhow, then the second probe that actually connects to TCP port 80 and does a banner grab
will show you that it's an IIS 5 machine.
And then because they have an IPS or something actively killing connections when it sees something bad across the wire,
when you send your Apache exploit, it kills the session and your tool thinks that the DOS attack was successful.
So then you come back and find out that Apache DOS vulnerability was successful.
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.
But imagine doing this times 4 billion machines. Not really useful.
So to be useful in the future, these modules are going to need to share the information more intelligently.
Some more problems that we're having is with the timing.
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.
And I'll give you the two examples in the open source space.
We have the scanran tool that provided a minus B option for bandwidth.
But I probably just haven't played with it enough.
But in my experience, anything over like 5K to 10K, I was noticing a lot of packet loss.
And it also became bursty.
And so it didn't really work out.
Mostly because of the way that the sleep timer was working and the get time of day counter was working.
And then with nmap, you have normal, aggressive, insane or things like that.
But even in insane mode, it doesn't scale to high speeds.
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.
But the timing of how fast you can go is still greatly affected by the machines that you're probing.
To nmap's credit, we actually got nmap to send out more packets per second than we did scanran.
Oh, just some raw numbers real quick.
With our tool at this point, on a standard copper gigabit card,
we're successful at sending over 160,000 packets per second reliably.
And we're working with some FPGA people to get that in the 500,000 to million packet per second range.
But we're still working on that. That's pie in the sky at this point.
But from an average laptop, you can expect anywhere from 17,000 to 70,000 packets per second being pretty reliable to send.
But you're still going to want to break it up into different processes and I'll show you why.
Some more mindset. Okay, so now we've told you about some problems.
What are we going to do to solve these problems?
Well, from the get-go, we were designing this with scalability in mind.
I talked about efficient use of resources and I'm going to give you a bus analogy.
Basically, I watched Sesame Street as a kid and they were trying to pollute our minds with this political message
that buses are better than Ferraris because they're more efficient.
But in the example, they had 100 kids on the left and 100 kids on the right
and they had three small sports cars ferreting people from one site to another site.
They gave them a 20-minute head start and then they had the other 100 kids all jump on one bus and just go.
Let me break it down technically now.
When you use an individual machine, there's only so fast that you can reliably send and receive packets.
So even if you could get Nmap or ScanRan to go at 70,000 packets per second,
you're not going to have any room left to receive messages.
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
if you actually want to get the messages to come back to you.
So that's not going to be an efficient use of even a single machine.
But with scalability in mind, we know that we need to be able to have one logical working scanning system
that can scale beyond the limitations of any single resource, any single machine.
So it's not the same as just going faster.
I quoted some really ridiculous packet per second rates from a single machine,
but obviously if you go that fast to any network that we're playing with today, you're going to obliterate it.
I mean, I've seen some of these networks with even the big high-end Juniper firewalls
sitting in front of multiple OC3s that fall over dead at even 8,000 packets per second
if they have that stupid sin scan protection thing on.
By the way, funny, if any Juniper people are listening, I don't get that.
Protection that completely doshes your CPU is... well, I don't understand that at all.
Anyhow, moving on.
Okay, accuracy.
If you're collecting a lot of information and it's a lot of invalid information, then you're wasting your time.
This is my problem with those log aggregation systems where you have the garbage in, garbage out model.
If you can't trust the information, it's kind of worthless.
One of the problems that we have with a lot of tools is they try to be smarter than is programmatically possible.
Basically, I think tools should introduce stimulus and record response and let the humans analyze.
Computers are good at doing the tedious automated parts, humans are good at thinking,
and we shouldn't really mix the two more than we have to.
Flexibility.
At this point, with this framework, and you'll see examples of this,
any stimulus that you want to introduce to the remote side, currently we support TCP and UDP,
but we're going to support ICP and pretty much anything else that you can do over IP.
And then, depending on which contracts happen, we're also going to support a lot of other protocols.
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.
And then security.
It should go with that same, but it doesn't really.
We tried to put some formal thought into this, and we actually selected one of the IDS protection profiles from the Common Criteria
to build our implementation of the scanner against.
And we also provide a sample security policy for use with SELinux.
And yeah, that was at least in the design phase when we considered that.
We don't actually have the entire protection profile implemented, but we designed it so that we could when we actually release one.
And obviously with an open source tool, we don't have $5 million to formally go through the process,
but if anyone here wants to sponsor that, we would love it.
Cool.
All right, yeah, so what does it do?
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.
But currently, it can do TCP and UDP port scanning.
It can do stateless banner grabbing or active remote OS application, blah, blah, blah.
It can do stuff.
And some more interesting things is that instead of just sending a non-protocol specific probe,
we actually can send the same thing that a normal client would do.
So let's say that you're trying to find DNS servers.
Instead of just sending a blank datagram to UDP port 53,
we support a number of different payloads out of the default config file.
One of them can ask it for local host.
One of them can do a chaos.
If you're talking to a bind server, you're trying to find out what version it is.
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.
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.
So it can stuff the IP that it's talking to in there on the fly.
But any other thing that you need to calculate right before creating the packet, that also works.
And then for TCP, it's going to become more important nowadays as well,
because a lot of the networks that we're testing have those things that complete the three-way handshake
on behalf of the devices that are behind it.
And so you're going to find situations where every single port on every single IP on the remote network come back as open.
And you need to be able to send protocol-specific payloads
so you can figure out which ones are tricking you.
Then one of the other things that we put in there is a metamorphic shellcode encoder
to make it so that when you are delivering other types of payloads,
that you can make it so that they are not easily fingerprintable.
So not only is the NOPS-led metamorphic, but the encoder itself is as well.
And so basically there's nothing to write a signature for at this point.
We'll see.
Okay, and then we also can log to PCAP files.
And everything we do, and I can't stress this enough,
everything we're doing from this point forward has hooks to talk to relational databases on the back end,
because you cannot process this amount of data without one.
Okay, so now I'm going to pass the mic over to Jack.
Alright, how are we doing everyone?
Are we falling asleep yet?
Alright, I guess not.
Okay, well, there's three processes.
I guess it's pretty obvious what they do.
I'm not really going to talk about them.
Hopefully we're going to actually leave some time for some demos that we want to do.
Okay, one of the things that's different is that we try and use,
it's kind of a trivial algorithm to actually carry information inside the sequence number,
but the important part is that it's not one way.
So in other words, if we used MD5 and then lopped off part of it,
it wouldn't be one way.
So we can't do that because we actually need to do TCP connections.
The problem is that we can't actually have the guy who's sniffing and validating the sequence number
send back a question to the master thread to figure out if that's correct or not.
So we actually have to do that with a trivial algorithm.
Anyway, and then the scatter connect is we basically send out the SYN packets,
and then we gather on the syntax that we get back and act the connection
and actually do whatever it is that the scanner's configured to do.
Well, this is actually kind of long and drawn out.
What do I have, like 20 minutes left?
Half hour? Okay.
Well, I'll go through this.
It's actually 30 steps to a symbol SYN scan.
So basically, obviously the user would invoke the scanner from the command line.
It actually reads the configuration file first,
and then the actual command line arguments are parsed at that point
so that you can override the configuration file.
But if you get sick of typing certain options over and over, you just put them in there.
Anyways, the master process actually opens up binary modules
through whatever facilities on the system.
We use the LTDL interface now, so it's a bit more portable.
And we actually have auto-conf too, which is pretty ugly.
Anyways, the master process figures out whether or not you want it to run in a clustered mode,
which is a command line argument.
But this is actually for a local scan,
so we're just assuming that the master thread is actually going to fork children.
And then it actually records some information about them,
and it actually uses... the IPC goes through a Unix domain socket,
so it's actually a little bit faster than it used to be.
And then it actually uses signals to synchronize,
which I believe is actually causing us problems portability-wise.
So one of the problems with this release is that on certain machines the signals disappear,
and if we actually use reliable signals, it's not portable.
So we might actually have to change that a bit.
And then actually the important part is that we can't make the assumption we know what the other processes do,
because we don't know if we're in cluster mode.
If we're in cluster mode, all we know is an IP address and a port,
and we don't know if it's going to send or listen.
So we actually...
That's an important piece right there.
You don't have to have 16 machines to port scan one machine.
You can do it all from one machine.
You can't scale if you need to.
Okay.
Anyways, they connect up and send some information.
It's actually the listener that contains a lot of useful information early on,
because it's the guy who has the IP address that matters.
So actually during that handshake it sends the information back.
Anyways.
And then everyone syncs up with a ready message.
And then the master actually does something called stirring,
which actually would be doing the work unit allocation.
And we actually have some stuff to do that, but it's kind of specific to us.
I think in the general code we actually don't have anything useful when it stirs,
but if you actually had a big cluster and you wanted to actually distribute the send packets
amongst geographical areas, that's where you would put the code to do that,
so that you would actually have the shortest amount of hops between each sender.
Okay.
Anyways.
Right.
Then the listener fires up, and then we send the sender a batch work unit,
which basically means it's not going to get interrupted.
So hopefully, or if it's a batch sender anyways, we don't want to interrupt him.
We don't want him to have to pull the IPC channel, because it slows him down.
Okay.
And then the master just goes into a loop.
And when the sender finishes, it sends a work done,
and then we actually check to see if it has more work.
And if not, it just goes into a timeout state.
But meanwhile, any important things that are happening, such as TCP connections,
it will actually respond to those while it's in its timeout state,
or actually throughout the entire scan.
And then actually the master tells the sender and listener to quit,
and then the scan's done.
Right.
Okay.
So the important part about all that nonsense is that a general stack that's inside of a kernel
normally knows the remote target that it's going to talk to,
or remote host and port, but we don't.
So we actually don't have that model.
It's completely incompatible.
So we actually just kind of redid some of the decisions inside the stack
so that it would better fit a model where we don't know that information,
which is the scatter stuff.
Anyways.
Right.
Okay.
One of the important things is a lot of stacks we'll use like a hash table,
but we can't actually do that because we don't actually know who's going to talk to us.
A good example is if we scan a network that actually syntax packets,
it'll fill up our state table, and if there's nothing behind that device,
we'll have a bunch of dead entries in our connection table,
and we'll probably guess the size of the hash table wrong by doing that,
and our hash table will basically either collide to death,
or it'll have a bunch of linked lists instead of being a hash table.
So that's obviously not what we want.
We actually have to pick a data structure that responds better to unpredictable things like that,
like a binary tree.
Anyways.
So, right.
The point is that we can only have constant time lookups
if we actually have a good guess of how many things we're going to talk to which we don't.
So obviously we can't do that.
And even though generally we won't fill the table, we don't really know what's going to happen.
So, that's right.
Anyways.
Even if we did have a hash table that was big enough,
and this is just obviously for IPv4,
it would be quite a bit of RAM, actually,
just to store the connection entries, not even the data.
So that's obviously not very realistic.
It's just for the keys.
Anyway.
Yeah.
And, right.
Like I said, the reason why that's important is because as time goes on,
we see more and more devices to compensate for high-latency networks
that will answer part of the three-way handshake to kind of offload that
and keep the connection open for the high-latency device or improve the performance.
Or DDoS protection.
Or some obfuscated thing that people do to try and improve security,
which I'm sure that works real well.
Anyway.
Yeah.
So, one of the design goals is we need to be able to withstand this sort of network
because we're testing them.
Anyway.
Okay.
Yeah.
And, right.
I already said this.
We use a red-black tree.
One of the possible improvements that we're thinking of doing
is actually most of the time that's probably an unnecessary data structure.
We could probably use just a hash table and have constant time.
So, actually, what we want to do is actually switch on the fly.
If we actually pass a threshold and our table load goes too high,
we can actually dump it and turn it into a binary tree on the fly
and put a most frequently used cache in front of that.
I think it says it in here anyway.
Not most recently used, by the way, because that would be a lot of connections closing.
We actually need the top talkers, so you actually want it frequent, not recent.
Okay.
Anyway.
Here's some numbers about why we chose the algorithms that we did.
And the point was is we're just trying to prove that our measurements are somewhat valid,
but we actually inline some assembly in here.
You can see it here where we actually read the timestamp counter on a Pentium CPU.
And then we're actually going to overload our table and see what the performance numbers look like.
And these numbers actually indicate clock ticks.
And you can see here with the various load factors that our chained hash table
turns quickly into a bunch of linked lists and our red-black tree does not,
which should not be much of a surprise anyways.
But what's interesting about this actually is the amount of load that it took
for the CPU to actually get a really expensive lookup,
which is mainly due to the, I suppose, large cache on the CPU.
I'm not really sure.
But I figured at least that after a load of maybe four that it would start dropping off.
But it actually took somewhere around 30 for the performance to just go really badly.
So, right, I just actually talked about that before.
Whoops.
Right, but yeah, reset acts obviously we don't want to cache.
And those are always going to be the most recent.
So if we're going to do anything to improve the performance, we can't do that.
We actually have to calculate how often certain connections are being used and cache those instead.
Right.
Okay, so here's some examples from the payload configuration stuff.
It's just ASCII text.
But we tried to make it so that you could copy and paste stuff from like C
and put it into the configuration file.
But anyway, here's some example stuff.
Obviously UDP is a UDP payload.
If you don't get that, then I guess this is not going to make any sense.
And then the destination port is actually next.
And then the source port being negative one is just a wild card to say whatever.
And then one is interesting. That's a payload group.
One of the things that you can do is you can chain include files together
or configuration files together.
So you can actually have a bunch of different things that are meant for different sorts of environments.
Like, for example, if you want to scan for like Windows Trojans,
which are pretty popular, you probably want to put them in their own payload group.
And then you can just use the minus big G and then the numeric option for that payload group.
To kind of make that a little bit easier to do.
And actually, we have now TCP payloads, which we didn't have before.
And it's not still a real socket.
It's kind of a trigger response mechanism, but we try and do some TCP stuff.
But it turns out it's real hard because we actually emulate the operating system
we're appearing to come from.
So our stack code is non-trivial, unfortunately.
But for right now, you can definitely do this sort of thing
and test for, for example, open relays.
Anyway, and here's some screenshots.
Can you guys even see what that says?
No. I'm going to explain it.
This is a module written in C that's actually an HTTP module.
And it just does a head request.
And it's probably like, I don't know, 47 lines, apparently.
But that's what it looks like.
Okay, this is actually running a, I don't know, was this?
Yeah, this was actually a cluster that was Connect scanning
against Yahoo.com on port 80.
And you can see that at the end here, it's got some TCP statistics,
which are interesting.
But for each host, you can actually see a banner.
Now, that's probably not terribly exciting.
Here's probably some better contrast for you,
so you can understand why we did some of the things that we did.
This is actually a screenshot of Nmap scanning a website.
And it actually comes back and just says that those things are open.
And it took eight seconds or something, too.
But we can actually do the same thing and finish it in four seconds.
Well, I guess this really isn't race.
But the idea is, if you see here,
you can see, like, five open ports coming back,
which is identical to what we saw before.
But during the actual SYN scan,
we actually did the connection and grabbed the banner
without actually initiating another connection.
And we actually can tell what port really is open at high rates.
Okay. Here we go.
I can do these live, actually. We have internet.
Okay. Would you rather see live demos?
Because these things are kind of hard to read.
Yeah. Okay. Let's do some live stuff. Hang on.
Assuming my connection isn't dead.
All right. Cool.
So what you see here at this first screen,
locus-casio-3, that's our master thread.
4 is our... what is that?
That's the listener.
It's listening on the IP address that we're going to be sending from.
This one's number 5. This is actually the sender.
So just so you can see what that is.
And I'm just making sure that they're live and well.
And they appear to be.
So the first demo here.
Let me look inside this file real quick.
Well, unfortunately, no.
Maybe. Yeah.
We'll try, but all bets are off.
If everything breaks, it's your fault.
It's real big.
Okay.
I assume that's better.
You have to forgive me.
We're pretty hard on our laptops, and some of our keys are missing.
Okay. So this first one, I just wanted to show you inside it
so you knew I wasn't really cheating.
It's just a stupid shell script that runs my command for me.
Minus E, PGSQLDB just says for the output module,
go ahead and dump everything to a database.
I'm specifying the source IP to come from,
although in cluster mode, you don't really need to do that.
Minus V means a little bit more verbose.
W6 means emulate the Linux TCP IP stack properties,
mostly because that's the one that we've spent the most time with
to make sure that the connect mode stuff is reliable.
The minus Z is where we specify our drones.
Right now, the IPC channel is not protected.
Normally, if you're in a sensitive environment
or an environment that has any type of malice,
you would want to protect that over an encrypted channel of some sort.
I would have to recommend IPSec for that.
I've actually tested that. It works pretty well.
Minus big L5 is how long to wait after the batch sending is done.
Minus little r 9,000 means we're going to send around 9,000 packets per second.
We actually go a little bit lower than whatever you specify,
but it won't exceed 9,000 packets per second.
The 66.0.0.0.16 just means go to that CIDR block
and do 161 for the port, the disk port.
Minus MU is UDP mode,
and then minus big I is for impatient people like me
so you can see the data right away.
Right.
Which, of course, you don't actually want to use minus big I
when you're doing a scan that matters
because it's going to block on the master thread to write to the terminal,
which is fairly silly.
And it's not doing what I want, so I'm confused.
It's the font, man.
There you go. Okay.
So now these are some SNMP public community string version 1 machines
that are responding.
As you see, we're doing a slash 16 network,
and we're done sending,
and we're just waiting the five-second timeout,
and then it's going to process the results,
and it'll spit it back here pretty soon.
We're actually, I think, repeating the scan three times,
so if you're wondering why it's just sitting there now,
it's actually sending different SNMP payloads to try and get everyone.
XOR. It's pretty ugly, actually.
We're actually trying to figure out a better algorithm
that'll favor randomizing the more significant bits first,
but I actually haven't had time to get around to that,
so it just kind of XORs a random word.
So that was a slash 16 for SNMP with multiple payloads,
but those are absolutely open
because we sent a public community string request,
and it sent us back responses.
The TTL is wrapping over, thanks to our insane font size,
but if it wasn't, you would be able to see
the time-to-load value of the packet that's coming back to you,
and so you can quickly, as you're looking through it,
you can spot Windows Novell stacks versus Unix stacks
versus routing infrastructure.
But all of that went back to a database
that we may be able to show you,
but I don't want to run out of time
because we have some really cool fireworks at the end.
Some more demo 2.
This one is SMTP.
This one's actually going to look for open relay servers
in the same block,
and now we're actually doing three-way handshakes
with all those guys.
So this is TCP port 25.
We are absolutely connecting to them on port 25
and sending enough of a payload to elicit...
Well, basically what I did is I said,
I'm coming from an email address that I control,
sending to another email address that I control,
and that way I can get bounces back
telling me that I was a bad person,
or I can actually get the email that I sent.
But then, either way,
I still get the banner of all the systems
that we just talked to.
So if nothing else,
I now have version information in my database
that I can search through and say,
show me all the send mailboxes.
One thing that's important, too,
is that he had the immediate mode on,
but he was doing TCP connections,
so all the immediate things that needed to happen right away
got stalled.
So some of the TCP connections will actually kind of fail.
It makes for a better demo,
but you wouldn't do that in production, obviously.
Okay, so this next one is an HTTP GET request.
Again, we're going to connect to TCP port 80
and just hit all the people that are listening on port 80
and we'll do a GET request against them.
Yeah.
Okay, so that was a pretty simple GET request here.
That was a really small range.
Let's look at that.
That's just a slash 30.
That's Yahoo with a slash 30.
So, piece of cake, right?
Okay, let's see what else we have here.
Oh, I wanted to show you what was in the slide.
Sorry.
This is Nmap with port 70 through 82
against dietsecurity.com.
All ports come back open, which is what we expect
because we have a stupid device in the middle
that protects us from DDoS.
But here's with the unicorn scan
where we can actually enumerate what the protocol
behind the three-way handshake looks like.
So you see here that even though
the other ones came back as open,
in your database you can do a pretty simple
select statement to throw away the garbage properties.
And sometimes you'll even get better information
about the stack properties itself
because once you get sent to the right application
behind it, there's going to be telltale signs
that you're talking to a different device
than the one that actually completed the three-way handshake
for you.
But, yeah, it's pretty easy at this point
where you can actually...
It's kind of like the UDP situation all over again.
You know, in the UDP, again,
now we're sending real protocol payloads
as opposed to just counting on ICP messages.
But now in TCP land,
we're actually sending real protocol information
so we can get away from these devices
that just SYNAC everything.
This is just showing that we can do multiple payloads
all on one.
So this one's sending like 50 or so different payloads.
We've got some DNS servers,
we've got some SNMP servers.
Port 2367, don't know what that is.
137, yeah, all these are coming back to us now.
And I guess this is just showing off,
you know, what it looks like to do multiple payloads.
So that was the easy stuff.
Now comes the tricky part.
Hang on.
Okay, so I'm going to talk about what we're going to do now
and hopefully it won't break
because I was still writing code for it last night.
Anyway, what we do is we do basically a TCP connect scan
on port 80.
And there's actually a CGI script
that has a really dumb coding error in it.
We actually had some other stuff that we were going to do
but the political climate kind of got ugly.
Yeah, we were going to release some fun stuff
but unfortunately nobody wants to hear that sort of thing these days.
So we actually just reused some other stuff we had.
But basically it does a three-way handshake
and it actually generates the XOR encoder on the fly,
which is metamorphic.
And it actually does a two-stage exploit.
One of the problems that I had, though,
was that I didn't have enough time to write the two-stage NetBSD assembly.
So I cheated and used someone else's stuff
and it doesn't work.
So that just goes to show me...
Okay, so right.
We generate a metamorphic first stage
and we send the payload.
What we're supposed to want to do here
is Apache hands all the CGI scripts,
a writable file descriptor on two bits, the error logs.
So the first thing that we do in our shellcode
is we truncate that.
We create a socket and connect back to a second stage server
and we send it some information about the platform that we've just...
or the process that we've just compromised.
And we actually just send back a 32-bit word
saying what predefined constant that was.
So...
And then the shellcode server sends back
the length of the payload that we're going to send in the second stage
and it does memmap and opens up an anonymous memory region
at a fixed address.
And it loads a hacked binary into that area
and jumps to the beginning of the file,
which then...
And I mentioned that the ELF is hacked
because we actually overwrote the first part of the ELF header
with some assembly to jump to the entry point.
But the important point is that the second stage is written in C.
It's similar to the impurity stuff, actually.
Anyway.
And then we transfer control to the second stage code
by jumping to the ELF entry point.
Yeah. Oh, right.
So this is the part where I do it and it doesn't break.
Okay.
This is the NetBSD box.
Okay.
As you can see, this shellcode doesn't work.
So the only thing we can do is just look at port 4444.
This is the second stage server.
And then we actually have two of these clients.
One of them actually uses ncurses, so it opens up new windows
every time you get a shell.
It's kind of neat.
But we're having some terminal issues.
And we can't figure out ncurses.
It's kind of above us.
So we don't have that yet.
What he's going to show you is the TCP dump,
so you can see that it really is working.
And we're being told to hurry up,
so you've got like five seconds.
Okay, so here it goes.
Hopefully it won't crash.
Okay, so we first have to grab an IP address
that's not attached to the kernel.
As you can see, some stuff went by here.
So it connected to port 80.
It sent our payload.
And now we have a shell.
Yeah, so you can see here that the second stage shellcode server
got it connected back.
It sent back the word that said it was...
This particular one was Linux x86.
The important part about that demo, though,
is that after it got the...
It connected to two different hosts.
And after it got the SYNAC back,
it did operating system detection,
and it sent a platform-specific exploit to it on the fly.
It knew how to generate a platform-specific exploit on the fly.
So that was actually pretty cool.
Unfortunately, we don't have time to explain in more detail.
But if you're interested, come find us.
Yeah.
And you can actually watch DVDs in ASCII,
which was the entire point of doing that.