[00:40.760 --> 00:42.280]  It is 2 o'clock, isn't it?
[00:49.260 --> 00:52.080]  Well, welcome to room B at 2 o'clock.
[00:52.220 --> 00:53.020]  It's 2 o'clock, right?
[00:53.620 --> 00:53.940]  Somewhere?
[00:54.700 --> 00:54.840]  Good.
[00:55.240 --> 00:55.500]  Good.
[00:56.200 --> 01:01.580]  Alright, just so you know, the schedule for the previously unscheduled area C is...
[01:01.580 --> 01:03.520]  2 o'clock is why forensics suck.
[01:04.780 --> 01:09.000]  3 o'clock is Python's TCP/IP stack, or Python AND.
[01:09.980 --> 01:11.740]  And at 4 o'clock we have media streaming.
[01:11.740 --> 01:18.920]  In here right now we have Packet Purgatory by Todd McDermott, and I will let him take it from here.
[01:19.180 --> 01:19.820]  Thank you very much.
[01:21.960 --> 01:22.540]  Thank you.
[01:23.160 --> 01:24.920]  I appreciate you all coming out here.
[01:25.100 --> 01:27.720]  I realize I'm up against Jello, which is pretty heavy competition.
[01:28.180 --> 01:31.540]  So thank you very much for coming by, and I hope you enjoy the show.
[01:32.780 --> 01:36.580]  To cover what we're going to be covering today, this is the intro.
[01:36.800 --> 01:38.020]  We're getting close to the end of it.
[01:38.020 --> 01:43.720]  But we're going to cover source routing, which is kind of the history of how Packet Purgatory evolved.
[01:44.080 --> 01:49.040]  And then we're going to cover internals of how Packet Purgatory works, how to use it.
[01:49.360 --> 01:53.500]  And then we're going to cover some projects that use Packet Purgatory.
[01:53.600 --> 02:00.380]  And the one that I'm going to focus most on is StegTunnel, which is a covert channel over arbitrary network TCP connections.
[02:01.240 --> 02:06.160]  And then we're going to go kind of into the future of Packet Purgatory and where I'd like to take it.
[02:06.280 --> 02:07.900]  And hopefully where you guys will take it.
[02:08.060 --> 02:08.860]  And any questions.
[02:08.980 --> 02:12.200]  Actually, I'm not much of a stickler for questions at the end.
[02:12.340 --> 02:19.240]  So, as a matter of fact, I have a really nasty tendency to just dive sideways into complete tangents without telling anyone where I'm going.
[02:19.240 --> 02:24.200]  So, if I do that, stick up your hand and say, wait, I don't understand what you just did.
[02:24.240 --> 02:27.500]  And I'll be happy to hopefully get back on track.
[02:28.780 --> 02:29.860]  So, why are you here?
[02:30.460 --> 02:33.420]  Hopefully to learn about this library or because you're not Dead Kennedys fans.
[02:33.640 --> 02:34.360]  Why am I here?
[02:34.460 --> 02:36.100]  I have a dirty, dirty secret.
[02:37.000 --> 02:41.040]  About a couple of years ago, the company that I was working at made me take sales training.
[02:41.840 --> 02:44.200]  And that's a piece of your soul you can just never get back.
[02:45.560 --> 02:49.040]  So, I'm going to try and sell you Packet Purgatory.
[02:49.040 --> 02:52.140]  If you're a coder, I would very much like it.
[02:52.300 --> 02:58.020]  It would make me feel warm and fuzzy inside if other people found this library useful and incorporated it into their own projects.
[02:58.200 --> 03:03.980]  If you're not a coder, I have a couple of tools, LSRTunnel, StegTunnel, which hopefully you'll find useful.
[03:04.200 --> 03:07.800]  But specifically, if you're a coder, I'm talking to you.
[03:08.360 --> 03:12.240]  And why I wrote it, that's the history section and we'll kind of get into that.
[03:12.240 --> 03:17.180]  First of all, how many of you are familiar with source routing and how that works?
[03:18.120 --> 03:18.520]  Some.
[03:18.640 --> 03:19.320]  But not enough.
[03:19.440 --> 03:20.140]  You get the lesson.
[03:21.000 --> 03:24.700]  Source routing is one of the IP options.
[03:24.880 --> 03:37.900]  IP options were ways to extend the IP protocol that were created way back in the day when people thought, you know, this IP thing's great, but we'd really like to have these additional features, functionality, that we're not sure how we're going to use it,
[03:37.960 --> 03:39.960]  but we'd like to be able to use it, perhaps.
[03:39.960 --> 03:44.460]  And unfortunately, in so doing, they open up a couple security bugs.
[03:45.480 --> 03:49.940]  This is a IP packet header, vastly simplified.
[03:50.440 --> 03:56.480]  What you see up here as the stuff is what you normally think of when you think of an IP header.
[03:56.620 --> 03:58.180]  You know, type of service field, all that stuff.
[03:58.340 --> 04:00.120]  And you've got the source address and the destination address.
[04:00.220 --> 04:01.100]  That's in the main field.
[04:01.200 --> 04:02.360]  And then we've got the options.
[04:03.140 --> 04:07.380]  Options come about an IP header when you just set the header length longer than five.
[04:07.380 --> 04:10.420]  And if you do that, it assumes you have options and it tries to parse them.
[04:11.040 --> 04:24.420]  And within the source routing option, specifically, you've got a pointer, and then you've got a multiple, this can be an arbitrary number of, well, arbitrary up to like eight, number of source route hops.
[04:24.600 --> 04:29.620]  Now, if it's strict source routing, you have to specify hop by hop by hop, and they've all got to be direct connections.
[04:29.800 --> 04:33.820]  So you're specifying this, and then it's got to be one jump to that, and then it's got to be one jump to this.
[04:33.820 --> 04:37.440]  If you are doing loose source routing, the hops can be anywhere on the network.
[04:37.800 --> 04:48.200]  So you can say, I want hop A to go to China, and then I want hop B to be back in Czechoslovakia, and then hop C through this router in Texas, and then finally through the destination.
[04:50.100 --> 05:02.520]  And this has potential... the reason it's in there and the way it's actually used today is ISPs will actually check to see if they are cheating on their peering agreements with each other.
[05:02.760 --> 05:11.740]  So if I am an ISP and I have a peering agreement with you, my peering agreement will generally state something like, I'm supposed to take it as far along my network as possible before I dump it off to my peer.
[05:11.880 --> 05:26.260]  So if I have a hop from San Francisco to New York, and my peer also has a hop from San Francisco to New York, and my source is in San Francisco and my destination is in New York, I should be taking this from San Francisco to New York, then dumping it to my peer who can deliver it to his final destination.
[05:26.700 --> 05:34.280]  Some ISPs will cheat on this and dump it in San Francisco to their peer, who will then take it to New New York, and they've got to pay for the long haul bandwidth.
[05:35.060 --> 05:46.820]  Now, so they'll actually, they'll source route packets to their competitor's site, their competitor's router in San Francisco, their competitor, their peer, their friends, right?
[05:48.320 --> 05:58.540]  And see, will they actually take that packet on their own network from San Francisco to New York, or will they dump it straight back on your network and make you route it over the long haul?
[05:58.700 --> 06:03.980]  So a lot of peering agreements will actually require that source routing be turned on, at least on the border routers.
[06:05.200 --> 06:07.000]  Now, the security implications of this.
[06:07.160 --> 06:14.820]  The way that source routing actually works is you have the source IP address, and this stays constant throughout the entire life of the packet.
[06:15.020 --> 06:17.020]  Then you have a destination IP address.
[06:17.140 --> 06:22.380]  Now, this is a destination of the next hop that you're expecting this packet to take.
[06:22.380 --> 06:28.200]  So if you're routing through China, Czechoslovakia, Houston, you're going to be saying, this is the destination of China.
[06:28.340 --> 06:30.900]  And then down here, you'll have Czechoslovakia and Houston.
[06:32.460 --> 06:39.600]  And what will happen is this option pointer points to Czechoslovakia as the next hop, hypothetically.
[06:39.780 --> 06:46.280]  And then as the packet goes along from hop to hop to hop, you'll change hop A with the destination.
[06:46.460 --> 06:51.500]  So once it gets to China, the Chinese router will say, oh, this is a source router packet.
[06:51.700 --> 06:54.220]  This is not destined finally for me.
[06:54.360 --> 06:55.980]  I need to forward this on.
[06:56.260 --> 07:01.060]  We'll swap the IP options and we'll then send it on its merry way.
[07:02.840 --> 07:10.320]  Now, and then when it gets to Czechoslovakia, they replace that particular pointer and then it goes on to its final destination.
[07:10.500 --> 07:14.400]  And the final destination, it looks and it says, oh, the pointer is off the end of the length of the option.
[07:14.560 --> 07:16.600]  Therefore, its final destination is me.
[07:16.720 --> 07:17.900]  I should process this packet.
[07:19.420 --> 07:21.300]  Now, I didn't discover this.
[07:21.340 --> 07:24.760]  I was just reading Stevens TCP/IP Illustrated Volume 2, as is my want.
[07:24.920 --> 07:30.020]  And I realized that this could be used to spoof packets quite effectively.
[07:30.020 --> 07:42.380]  Because one of the things about source routed packets is that on TCP connections, as RFC specified, when you receive the source routed packet, you're supposed to reverse the source route when you're replying to it.
[07:42.540 --> 07:50.580]  So it becomes really easy to have this host up here state, I am a host in Czechoslovakia.
[07:50.580 --> 07:53.380]  And I have been asked to forward this to you.
[07:53.940 --> 07:55.400]  And this is my host in Houston.
[07:55.680 --> 08:02.040]  So now when the host in Houston actually gets this, he's going to think that it came from this guy over here.
[08:02.920 --> 08:04.320]  Because this is what the source route says.
[08:04.420 --> 08:06.200]  The original source is this guy over here.
[08:06.360 --> 08:09.000]  But in reality, there's just this one guy playing man in the middle.
[08:09.180 --> 08:23.620]  And because loose source routing does not require that you actually be in a sniffing network advantage position, you can, from an arbitrary spot on the network, spoof these packets back and, you know, and get the responses.
[08:24.140 --> 08:34.920]  And, you know, if you look in the web logs, you know, if you're web surfing, you'll show up as this original host, which you claim is the original source, but things are just being routed back to you.
[08:35.200 --> 08:36.200]  So is that clear?
[08:36.680 --> 08:38.500]  Does anyone want me to clarify?
[08:38.780 --> 08:39.840]  Okay, cool.
[08:40.460 --> 08:44.400]  Now, and then when the response comes back, you process it.
[08:44.700 --> 08:46.700]  Well, I say you process it.
[08:47.840 --> 08:50.200]  Now, it's pretty easy to generate one of these packets.
[08:50.400 --> 08:56.900]  It's... you just go through and you write a raw IP packet with the source route option set properly, and bang, you're done.
[08:57.040 --> 08:57.280]  You're ready.
[08:59.240 --> 09:05.280]  Unfortunately, if you generate that raw IP packet, you're going to get something back that isn't destined to you.
[09:05.300 --> 09:08.380]  And you're going to have to process in some way to make sense of.
[09:08.860 --> 09:13.940]  And so I wanted to effectively write an exploit for this kind of behavior.
[09:14.160 --> 09:30.480]  And I realized that rather than writing a individual piece of software that used raw sockets and libpcap and understood HTTP and used libpcap and raw sockets and kind of understood SMTP or whatever I wanted to spoof as, our login was a great one.
[09:30.580 --> 09:35.800]  If you have something in the slash dot our hosts file, you pretend to be that and bam, you're in, you've got that trust relationship.
[09:36.640 --> 09:59.260]  So rather than actually generating each of these tools individually, I said, you know, it'd be really great if I had some way of intercepting my packets on the outbound direction before they leave my host and modifying them so that I don't have to speak that lower level protocol or,
[09:59.280 --> 10:01.440]  you know, the higher level layer seven protocol.
[10:01.600 --> 10:05.120]  Because my tools, my regular stock clients will do it for me.
[10:05.860 --> 10:19.200]  And then on the packets on the way back in, before they reach my kernel and generate a spurious reset or ICMP error message, it'd be great if I could take those packets and modify them before I actually let my kernel see that.
[10:19.200 --> 10:22.640]  And so that was kind of the genesis of the idea of packet purgatory.
[10:22.760 --> 10:24.080]  So I wrote a tool called LSRTunnel.
[10:24.480 --> 10:25.600]  You can download it now.
[10:25.700 --> 10:26.360]  It's BSD license.
[10:27.880 --> 10:30.160]  Which does this for loose source routing.
[10:30.940 --> 10:33.620]  And it all worked and everything was happy.
[10:33.800 --> 10:41.220]  And if you want to know actually how commonplace it is today, the BSDs are generally pretty good.
[10:41.320 --> 10:43.600]  NetBSD still reverses source routes by default.
[10:44.460 --> 10:46.520]  Linux doesn't even understand source routes.
[10:46.720 --> 10:48.860]  You can't turn it on in the Linux kernel.
[10:49.020 --> 10:50.100]  It's just the code's not in there.
[10:50.820 --> 10:53.420]  Windows, however, does reverse source routes by default.
[10:53.600 --> 10:58.420]  They actually reverse their reset packets too, which is kind of a way you could fingerprint them if you wanted to do that.
[10:59.880 --> 11:02.220]  A lot of firewalls will block it by default though.
[11:02.400 --> 11:07.920]  So don't expect this to work on the open Internet on a fairly regular basis.
[11:07.920 --> 11:10.380]  Because the OS's by and large aren't patched.
[11:10.440 --> 11:13.380]  But the firewalls, most firewalls will just block anything with IP options.
[11:13.540 --> 11:14.300]  As they should.
[11:15.040 --> 11:17.980]  They're kind of old and crufty and not used for anything useful.
[11:19.040 --> 11:25.620]  So I went through and I started writing this other project called StegTunnel, which I'm going to get to in more detail in a bit.
[11:26.160 --> 11:30.740]  And I noticed that I was cutting and pasting a lot of the same code out of LSRTunnel.
[11:31.200 --> 11:34.880]  And I said, you know, I really ought to split this off and make this a library.
[11:35.080 --> 11:38.900]  So that not only can I use it and, you know, I only have to maintain one code base.
[11:39.100 --> 11:41.460]  Uh, but other people could make use of it as well.
[11:41.800 --> 11:49.880]  So, uh, the idea behind, uh, Packet Purgatory is that you've got, this is a view of your host.
[11:50.060 --> 11:54.400]  And you've got, uh, the cloud on the outside, as ever it was, it is.
[11:54.580 --> 11:58.420]  You've got your network interface and you've got your kernel, which generally is what's speaking TCP/IP.
[11:58.620 --> 12:02.180]  And I wanted to put a user space wedge in between there.
[12:02.180 --> 12:08.100]  Now, there are some functionality that allows you to mangle packets in and out on various OS's.
[12:08.260 --> 12:17.480]  Uh, for example, there's IP mangle in, uh, in IP tables on Linux, uh, which enables you to insert a kernel module that will mangle packets on the way in and way out.
[12:17.820 --> 12:20.300]  But unfortunately, that's not very portable.
[12:20.440 --> 12:22.000]  It's IP tables on Linux only.
[12:22.260 --> 12:34.720]  So I really wanted to separate this off into an API that would run on most OS's and, uh, would enable people to write user land programs that could accomplish this, uh, fairly easily, fairly smoothly.
[12:34.800 --> 12:39.280]  I wanted to clean API so it wasn't hard to mangle the packets on the way in and out.
[12:40.300 --> 12:41.700]  Are there any questions on that?
[12:42.960 --> 12:52.660]  So, kind of the view of, uh, how Packet Purgatory works is it's built, consider it a pyramid, the all-seeing pyramid, if you will.
[12:52.840 --> 12:56.080]  As I feel this guy's eyes burning into my back, I'm standing up here.
[12:57.000 --> 13:01.540]  Uh, Packet Purgatory is built on libpcap and libdnet.
[13:01.740 --> 13:04.900]  Uh, I assume, well, I'll get to libpcap in a bit.
[13:05.220 --> 13:10.800]  And, and the idea is that you can take off that top block really easily and replace it with StegTunnel.
[13:10.920 --> 13:14.980]  So, as I make improvements to the underlying libraries, uh, it's really easy.
[13:15.240 --> 13:17.880]  The, the API is going to be fairly fixed and constant.
[13:17.900 --> 13:23.620]  And it, it becomes really easy to write tools that just sit on top and will just modify the packets.
[13:23.960 --> 13:27.140]  And I've got a code example coming up that I'm, I'm going to illustrate that in.
[13:28.040 --> 13:30.980]  So, I assume everyone here is, is familiar with libpcap.
[13:31.160 --> 13:32.600]  Raise your hand if you're familiar with libpcap.
[13:33.100 --> 13:33.540]  Yeah.
[13:33.680 --> 13:33.840]  Okay.
[13:34.040 --> 13:34.560]  That's everybody.
[13:34.720 --> 13:36.340]  Open source packet capture library.
[13:36.480 --> 13:37.160]  It is the end-all be-all.
[13:37.820 --> 13:38.560]  Uh, libdnet.
[13:38.780 --> 13:40.260]  How many people here are familiar with libdnet?
[13:41.240 --> 13:42.100]  Not quite as many.
[13:42.240 --> 13:42.320]  Okay.
[13:43.140 --> 13:48.180]  Libdnet is, uh, a, it's an API written by Doug Song.
[13:48.480 --> 13:50.360]  It's the dumb networking library.
[13:50.500 --> 13:52.280]  But it's actually rather intelligent and smart.
[13:52.420 --> 13:59.660]  Uh, I got into it when, uh, I wanted to start modifying IP options on, uh, TCP/IP packets.
[13:59.820 --> 14:03.520]  And libnet by Mike Schiffman didn't offer that functionality at the time.
[14:03.660 --> 14:04.380]  It, it, it may now.
[14:04.740 --> 14:09.500]  But, uh, it did not provide a clean interface to create packets with IP options.
[14:09.680 --> 14:10.780]  And libdnet did.
[14:10.980 --> 14:13.780]  And it has the capability to write raw IP packets as well.
[14:14.180 --> 14:17.400]  Uh, so I'm using it for raw IP packet injection.
[14:17.400 --> 14:24.900]  Uh, it also has the capability of, of really messing with all kinds of OS system internals and providing a clean API across all these different OSs.
[14:25.020 --> 14:33.120]  So if you want to modify your route table, the way you would do that, you know, at a C API level is different for Linux than it is for BSD.
[14:33.400 --> 14:41.660]  But libdnet aggregates all of these methods and enables you to make one function call that will modify that route table on all these different OSs.
[14:41.660 --> 14:43.800]  So, I didn't need to do that work.
[14:43.940 --> 14:45.620]  So, I, I wrote on top of it.
[14:45.780 --> 14:49.460]  Uh, so I'm using it to, to modify my ARP, uh, table, my local ARP table.
[14:49.660 --> 14:51.380]  I'm using it to write raw Ethernet frames.
[14:51.500 --> 14:55.820]  I'm using it to control my local firewall, which is kind of a sticky wicket at this point.
[14:55.900 --> 14:56.720]  And I'll, I'll get into that.
[14:58.280 --> 15:03.220]  I'm using it to screw on with my interfaces, uh, route table modification, everything.
[15:04.360 --> 15:08.660]  So, that's the underlying building blocks that I'm building Packet Purgatory on top of.
[15:09.700 --> 15:11.940]  And, what really enables me to get away with this.
[15:12.440 --> 15:16.740]  Um, there are two modes currently in Packet Purgatory.
[15:16.940 --> 15:22.580]  Uh, the reason why there are two modes is because not every OS supports all the functionality that I need.
[15:22.800 --> 15:32.680]  Uh, the idea behind this, though, is that no matter which mode you are using, the code that you write is the same, except for set mode to foo.
[15:33.240 --> 15:37.920]  Uh, so, loopback firewall mode, this is the internals of how Packet Purgatory works.
[15:38.160 --> 15:44.440]  I modify the firewall rule sets so that it will actually block all incoming packets by default.
[15:44.680 --> 15:46.620]  There's a new rule that comes in that says block everything.
[15:47.600 --> 15:50.860]  Uh, that enables the kernel to get out of my way.
[15:50.940 --> 15:52.860]  Because I don't want my kernel to be sitting in there.
[15:52.960 --> 15:57.000]  And if I'm messing with packets when the responses come in, it's going to be generating spurious resets.
[15:57.200 --> 15:58.740]  It, I, I don't want to deal with that.
[15:58.840 --> 16:00.960]  So, I block everything with a firewall rule.
[16:00.960 --> 16:08.840]  Uh, but I'm using lidpcap to sniff off of that interface so that I'm really getting everything, but it's being filtered through my user space program.
[16:08.980 --> 16:09.820]  It's not going to the kernel.
[16:10.360 --> 16:16.740]  Um, once I get that, I re-inject the packets after I've modified them out over the loopback interface.
[16:17.000 --> 16:21.940]  And there's no firewall in the loopback interface, so it will actually deliver the packet to its destination.
[16:22.540 --> 16:27.940]  And I also have modified the route table so that the default route is out the loopback interface.
[16:28.080 --> 16:29.500]  Next hop on 27001.
[16:29.800 --> 16:33.600]  Um, this doesn't work on Solaris because they don't have a full loopback interface.
[16:33.760 --> 16:36.660]  So, again, you couldn't use this mode on that OS.
[16:36.980 --> 16:42.880]  Uh, but on Linux BSD, actually OpenBSD recently modified it and it kind of screwed it up, so I got to fix that.
[16:43.280 --> 16:47.820]  Uh, but Linux and some of the BSDs and the older OpenBSDs, it works just fine.
[16:48.000 --> 16:52.220]  You modify it so you're routing outbound packets out the loopback interface.
[16:52.340 --> 16:54.160]  You're sniffing on the loopback interface.
[16:54.960 --> 17:05.440]  And, uh, when you sniff that packet, you can then tweak the packet as you will and then you'll do a raw Ethernet write out the, uh, the Ethernet interface that's appropriate.
[17:05.600 --> 17:10.840]  It remembers what the route table used to look like before you screwed it up, you cruel route table mangler you.
[17:11.840 --> 17:16.160]  And, uh, and so it'll remember that and it'll look up the proper interfaces and do a raw Ethernet write.
[17:16.280 --> 17:19.000]  And all of this is pretty much invisible to the coder.
[17:19.360 --> 17:23.240]  Uh, this is just what is happening underneath when you're in loopback firewall mode.
[17:23.660 --> 17:26.100]  Are there any questions on loopback firewall mode?
[17:26.440 --> 17:27.000]  No?
[17:27.480 --> 17:27.740]  Okay.
[17:28.120 --> 17:31.480]  The other mode that's implemented currently is proxy mode.
[17:32.940 --> 17:36.000]  The idea behind proxy mode is that it's the most portable of all modes.
[17:36.140 --> 17:37.020]  Everything supports it.
[17:37.960 --> 17:42.640]  Uh, the idea is that you're running everything through this proxy IP down here.
[17:42.640 --> 17:49.760]  Uh, so, when you send out traffic, uh, this proxy IP does not really exist.
[17:49.880 --> 17:50.940]  There's no real host here.
[17:51.040 --> 17:52.200]  It's a figment of your imagination.
[17:52.200 --> 18:00.640]  You've got an IP address that, uh, that exists only in, in your host's, uh, screwed up deranged kernel at this point.
[18:01.080 --> 18:05.840]  Uh, when you send out traffic, you're going to send it out to the proxy host.
[18:06.100 --> 18:09.860]  Uh, and you're going to sniff on that interface that the proxy host would normally be sitting on.
[18:09.980 --> 18:12.540]  And so that you can in, in, intercept outbound packets that way.
[18:12.660 --> 18:22.660]  After you're done modifying those packets, the proxy host will then change the source IP so that it looks like it's coming from the proxy host and go out to the remote host.
[18:23.180 --> 18:25.840]  Once the remote host receives the packet, it's going to respond.
[18:25.880 --> 18:32.180]  And because it's responding to the same source IP, it's going to respond back to the proxy host, which you are arping for and, and doing all the appropriate things.
[18:32.280 --> 18:34.660]  So it's got to be on the local, same local subnet as you are.
[18:34.840 --> 18:38.720]  Uh, but so long as it's on From that subnet, everything is golden.
[18:40.200 --> 18:44.940]  And then at that point, you have the opportunity to modify any packets, change it around how you will.
[18:45.100 --> 18:48.080]  It will replace the destination IP with your local IP.
[18:48.260 --> 18:50.980]  It will replace the source IP with the proxy host's IP again.
[18:51.180 --> 18:52.940]  And then it will re-inject it back to you.
[18:53.320 --> 18:54.380]  It's really simple.
[18:54.660 --> 18:57.760]  It's a clean way of getting the kernel out of your way.
[18:58.120 --> 19:00.100]  Pretty much every OS supports it.
[19:00.240 --> 19:10.080]  And the only ugly thing with proxy mode is that there's got to be a one-to-one relationship, unless you want to do a little fancy footwork, between proxy hosts and remote hosts.
[19:10.380 --> 19:24.500]  So for scanning tools, this is really simple, you know, because generally all you're ever going to want is one remote host scanned at any given time, unless you're doing... what was that scanner that... scan rad.
[19:24.720 --> 19:24.980]  Yeah.
[19:26.600 --> 19:29.920]  There are scanning tools that want to do multiple hosts at a single time.
[19:30.280 --> 19:36.400]  But for things like LSRScan, where you're checking for source router behavior, LSRTunnel, that's pretty easy.
[19:36.500 --> 19:45.240]  If you're running a server, it becomes a little bit more difficult, because honestly, it's really quirky to have to say, well, that's my client for my server.
[19:46.080 --> 19:52.280]  You can see how I implemented that in StegTunnel, where I'm actually reassigning ports as things come in.
[19:52.440 --> 19:56.540]  You know, so if you come in on this port... I've got to maintain a unique port IP pair.
[19:57.020 --> 19:59.740]  So you can look at the StegTunnel source and see how I did that.
[19:59.860 --> 20:05.600]  But if you're doing a server thing, I'd recommend that you use loopback firewall mode, because it's going to end up being a lot cleaner.
[20:05.700 --> 20:08.200]  So be on an OS that supports loopback firewall mode.
[20:08.560 --> 20:11.880]  But I'm going to implement more modes in the future.
[20:12.980 --> 20:16.700]  One of the ideas that I've got is I've got control over the interfaces.
[20:16.840 --> 20:19.220]  I could just strip the IP addresses off all the interfaces.
[20:19.380 --> 20:24.280]  So now I actually have my real IP address, but my interface no longer thinks it's that IP address.
[20:24.380 --> 20:26.540]  And then I just route things into loopback.
[20:26.680 --> 20:28.680]  So I don't have to have a supported firewall.
[20:29.320 --> 20:36.460]  Currently LibDNet supports PF, IPF, and IP chains, but they don't support IP tables is the big one that it's missing.
[20:38.100 --> 20:40.580]  So I could de-address interfaces.
[20:40.800 --> 20:47.380]  And that would kind of get me the same effect of blocking all inbound traffic while still being able to keep my IP address.
[20:47.480 --> 20:51.580]  And so I don't have to worry about IP addresses changing and I lose this one-to-one correlation.
[20:52.860 --> 20:58.580]  FreeBSD actually has a built-in device that just recently got added that allows you to hijack packets.
[20:58.660 --> 21:01.080]  And it's great, but it's only on FreeBSD.
[21:01.280 --> 21:13.040]  So I'm going to try and roll that in and make that an option so that you can write Packet Purgatory programs and they will cleanly make use of, if you've got that FreeBSD device available to you, it'll make use of that.
[21:13.340 --> 21:16.880]  And IP tables, I would love to tap into their mangle mode somehow.
[21:17.120 --> 21:26.800]  Unfortunately, the admittedly scant research that I've done into it suggests that when you're inserting packet mangling rules into IP tables, you're doing it as a kernel module.
[21:27.160 --> 21:29.980]  And that's not a really clean API.
[21:30.180 --> 21:38.400]  So probably I'm going to have to end up doing something where you've got code and it gets inserted in and then it opens up a device and then I communicate back and forth with the device.
[21:38.720 --> 21:40.520]  That's going to be kind of an interesting one to write.
[21:40.520 --> 21:47.780]  If anyone does have IP tables mangling experience, I would love to talk to you after the talk.
[21:49.100 --> 21:50.760]  So that's the internals.
[21:50.840 --> 21:53.600]  That's how Packet Purgatory works at a low level.
[21:54.060 --> 21:55.240]  How do you use it?
[21:55.360 --> 21:56.920]  How do you as a coder use it?
[21:57.180 --> 22:00.400]  The underlying concept is that you've got packet handlers.
[22:00.560 --> 22:13.720]  These are functions that you register with the program that say, on the inbound, pass this packet pointer to this function so that I can modify this packet and then forward it on its merry way when you return from the function.
[22:13.960 --> 22:17.360]  And then outbound, you also register another packet handler.
[22:17.460 --> 22:22.700]  Now, you can register null as both of these packet handlers if you want, in which case it'll just pass it through.
[22:23.320 --> 22:24.780]  And that's all well and good.
[22:24.880 --> 22:34.620]  And actually, if you do not register an inbound packet handler on the loopback firewall mode, it won't change firewall rule sets.
[22:34.640 --> 22:36.260]  So you don't need to have a supported firewall.
[22:36.860 --> 22:40.580]  And actually, that'd be a really good way to re-implement frag route if anyone wanted to do it that way.
[22:41.140 --> 22:47.800]  Because you get that access to... you modify the route table so you get to modify outbound packets, but you don't have to worry about changing the responses.
[22:49.360 --> 22:56.260]  And there's also... there's a state variable that gets passed back and forth between these two functions when you register them.
[22:56.460 --> 23:01.400]  So let me kind of run you through a Packet Purgatory packet handling function.
[23:01.780 --> 23:04.920]  This is a pretty simple program that I wrote.
[23:05.720 --> 23:07.400]  This would be an outbound handler.
[23:07.620 --> 23:15.320]  And the purpose of this outbound handler is... the type of service bits are pretty much never used these days within the IP header.
[23:15.640 --> 23:17.200]  But there's some fun ones in there.
[23:17.780 --> 23:26.320]  My favorite is the precedence flash override to be used in the, you know, kind of messages going over the old ARPANET saying, launch the nuclear missiles now.
[23:27.380 --> 23:29.940]  That's when you would use such packet type of service.
[23:31.640 --> 23:41.520]  Usually, when you are using your computer, you wouldn't have access to modifying those bits unless you had recompiled your kernel or done something like that.
[23:41.620 --> 23:44.020]  But with Packet Purgatory, it's really easy.
[23:44.060 --> 23:53.860]  This is the total extent of the code that will enable you to modify all your packets that go out and set the precedence flash override bit in your types of service.
[23:53.980 --> 23:56.940]  And if your ISP is looking, they can freak out or do whatever they will.
[23:58.740 --> 23:59.960]  But... beg pardon?
[24:01.040 --> 24:02.960]  This is a packet handling function.
[24:03.200 --> 24:04.660]  It's kind of a callback.
[24:06.200 --> 24:08.660]  I'll show you how it gets called on the next slide.
[24:08.760 --> 24:10.120]  And you'll see how it gets used.
[24:10.420 --> 24:14.520]  But we pass in... this is the Packet Purgatory handle.
[24:14.740 --> 24:15.740]  It's the context.
[24:16.280 --> 24:18.680]  Which just contains state about Packet Purgatory.
[24:18.860 --> 24:21.740]  It's not... you don't really need to go into the internals of that.
[24:21.860 --> 24:24.360]  It's just there if you wanted to look at the header files.
[24:24.860 --> 24:26.520]  Then you've got a pointer to this packet.
[24:26.660 --> 24:28.160]  This is your outbound packet.
[24:29.040 --> 24:30.500]  It starts at the IP header.
[24:30.640 --> 24:32.740]  You don't have Ethernet knowledge at this point.
[24:32.780 --> 24:36.220]  If you want to do raw Ethernet injection, it's not really set up for that.
[24:36.440 --> 24:48.180]  So if you're modifying the IP... and one of the things that LibDNet provides for you is it provides these structures which you can then overlay, because it's all pragma-packed, onto areas of memory.
[24:48.300 --> 24:54.020]  And then at that point, you can just treat those areas of memory... you can use the structure to address particular fields within there.
[24:54.160 --> 24:56.800]  So you can do IP-DEST as your destination address.
[24:56.960 --> 24:58.100]  And you can mess around with that.
[24:59.140 --> 25:03.560]  So at this point, what I'm doing is I'm specifically setting the type of service field.
[25:03.680 --> 25:07.240]  So I'm overlaying this structure onto my memory.
[25:07.700 --> 25:09.440]  Then I'm setting the type of service field.
[25:09.580 --> 25:10.640]  And then I just return 0.
[25:10.880 --> 25:12.940]  Return 0 means forward this packet on.
[25:13.300 --> 25:15.820]  Return 1 means drop this packet.
[25:16.160 --> 25:17.460]  Do Do not forward it on.
[25:17.660 --> 25:20.460]  Return minus one means stop the program something is hideously wrong.
[25:21.280 --> 25:28.020]  And if you wanted to inject more packets, let's say you have a packet in and you want to do... you wanted to re-implement frag route.
[25:28.480 --> 25:32.960]  You wanted to have a multiple to one correlation between your packets.
[25:33.120 --> 25:42.460]  There's a function available to you called packet p packet inject, which enables you to simply just put in these buffers and it will automatically route them and find out the right place to put them.
[25:42.660 --> 25:43.880]  So that's available to you.
[25:43.980 --> 25:51.680]  And then I've got this third variable up in the header, this unused... that would be the state variable.
[25:51.860 --> 26:06.620]  If you wanted to put something in that your program needed to communicate between what's going out on the outbound and what's coming in on the inbound and change how you're processing your packets based off of that, you just define a structure and pass it back and forth between these two headers.
[26:06.880 --> 26:08.320]  Are there any questions on that?
[26:09.360 --> 26:09.800]  No?
[26:10.040 --> 26:10.140]  Okay.
[26:11.460 --> 26:13.280]  This is the rest of the program.
[26:13.640 --> 26:16.620]  I can fit the whole program on two slides in a pretty big font.
[26:17.920 --> 26:18.840]  I've got a handle.
[26:19.520 --> 26:21.000]  And I initialize the handle.
[26:21.320 --> 26:23.800]  If the handle comes back null, I exit.
[26:24.120 --> 26:25.400]  And then I say start.
[26:25.740 --> 26:26.620]  And it starts.
[26:26.760 --> 26:30.200]  And you'll notice that this outbound here is where I'm registering my outbound function.
[26:30.460 --> 26:37.920]  It's the inbound... the inbound function, the outbound function, and then this would be the state pointer structure.
[26:38.220 --> 26:41.020]  This is all in the man pages if you want to read about that specifically.
[26:41.300 --> 26:43.120]  And then return zero is never reached.
[26:43.280 --> 26:45.260]  It's just to stop the compiler from complaining.
[26:46.560 --> 26:50.840]  So, it's a fairly clean, fairly simple API to use.
[26:50.980 --> 26:52.340]  At least, I hope it is.
[26:52.660 --> 26:59.060]  And it makes it really trivial to muck around with your packets on the inbound and outbound ways.
[26:59.520 --> 27:02.540]  Are there any questions on how to use Packet Purgatory?
[27:03.380 --> 27:03.820]  Yes?
[27:06.440 --> 27:09.000]  If you are... the question is, can you be operating a firewall?
[27:09.200 --> 27:17.300]  If you are operating a firewall, you are bypassing the firewall because you're blocking all the packets on the way in, but then you're re-injecting them.
[27:17.440 --> 27:25.000]  So, you could code up your own user space rules and state, you know, kind of replicate your firewall rule set in your Packet Purgatory program.
[27:26.520 --> 27:27.780]  If that's what you want it to do.
[27:28.340 --> 27:31.740]  Otherwise, you would be bypassing your firewall rule sets in loopback firewall mode.
[27:31.780 --> 27:33.780]  If you're using proxy mode, you wouldn't be bypassing your firewall.
[27:33.900 --> 27:40.200]  Although, you would be losing IP-related information because you wouldn't be able to distinguish what remote IPs were talking to you.
[27:40.220 --> 27:41.340]  It all looks like it's the proxy.
[27:42.960 --> 27:43.860]  Are there any other questions?
[27:45.100 --> 27:45.460]  Cool.
[27:45.800 --> 27:45.940]  Okay.
[27:47.620 --> 27:52.460]  So, next up, I'm going to talk about a program that I implemented using Packet Purgatory.
[27:52.620 --> 27:55.220]  It's kind of the sample program along with LSRTunnel.
[27:56.320 --> 27:57.620]  And that's StegTunnel.
[27:57.720 --> 28:02.360]  StegTunnel is covert channels over network traffic.
[28:03.240 --> 28:04.880]  And I've got this quote in here.
[28:05.040 --> 28:06.240]  This is a Bruce Schneier quote.
[28:06.460 --> 28:08.420]  There are two kinds of cryptography in this world.
[28:08.760 --> 28:13.920]  Cryptography that will stop your kid sister from reading your files and cryptography that will stop major governments from reading your files.
[28:14.320 --> 28:17.860]  And this is kind of can be applied to Stegonography.
[28:17.860 --> 28:24.200]  Stegonography in that there's Stegonography which will stop major governments from being aware that you're communicating.
[28:24.600 --> 28:27.800]  And there's Stegonography that will stop your local sysadmin from being aware that you're communicating.
[28:28.580 --> 28:40.880]  And one of the things that distinguishes strong Stegonography from weak Stegonography is weak Stegonography often makes the assumption that the enemy does not know the system being used.
[28:41.460 --> 28:44.600]  And lives or dies based off of that premise.
[28:46.860 --> 28:54.220]  Claude Shannon, World War II cryptographer, believed that the secrecy, the strength of a system should lie only within the strength of the key.
[28:54.680 --> 28:59.980]  And if the enemy knew the key, then at that point, the system is broken, there's nothing you can do.
[29:00.140 --> 29:05.060]  But if the enemy knows what the internals of the system are, then it's okay.
[29:06.060 --> 29:11.920]  Because so long as they don't know that key, they shouldn't be able to break the system simply by knowing about the system.
[29:11.920 --> 29:15.160]  Now, steganography kind of has a different victory condition than cryptography.
[29:15.260 --> 29:21.620]  Cryptography is solely if you've got files that can be read, then your crypto is broken.
[29:22.800 --> 29:27.060]  But if they can't read it, your cryptographic method is successful.
[29:27.940 --> 29:35.640]  Steganography, it's simply if your adversary is able to distinguish your traffic as carrying extra information.
[29:35.640 --> 29:38.140]  There's something in there above and beyond the cover.
[29:38.360 --> 29:40.660]  At that point, you have lost.
[29:41.320 --> 29:44.720]  And a lot of steganographic systems will fall down on this.
[29:45.220 --> 29:57.500]  Specifically, there'll be weaknesses in the stego system that if you know details about how the stego system works and you are sniffing on traffic, you can look for characteristics of that stego system and everything will fall apart.
[30:00.340 --> 30:01.080]  Let's see.
[30:01.920 --> 30:06.520]  StegTunnel kind of owes a debt to Craig Rowland's covert TCP program.
[30:06.740 --> 30:08.000]  How many are familiar with that?
[30:08.960 --> 30:09.440]  Okay.
[30:09.820 --> 30:14.220]  Craig Rowland back in 96 wrote a program called covert TCP.
[30:14.620 --> 30:24.720]  And this program would take information and it would stuff it in the initial sequence number of the TCP header and then would send these packets out.
[30:24.860 --> 30:27.440]  It would use raw IP writes to write these packets out to the network.
[30:27.540 --> 30:36.620]  And the idea is that a remote receiver, you know, was sniffing with libpcap would be able to receive these packets, decode the information out of the initial sequence number, and all was well and good.
[30:37.180 --> 30:44.820]  The problem with covert TCP was that it only ever sent one packet repeatedly with different initial sequence numbers.
[30:45.000 --> 30:47.260]  It wasn't actually doing three-way handshakes.
[30:47.380 --> 30:49.340]  It was just, you know, spoofing raw packets out there.
[30:50.660 --> 31:02.200]  Which, if you know that that's how it's doing it and you're looking for, you know, indications that someone's passing around steganographic network traffic, at that point it becomes really obvious that all I need to do is look for singletons.
[31:02.300 --> 31:09.320]  I need to look for TCP packets that I don't think are part of any particular TCP stream and bang, I know that information is being transferred.
[31:09.480 --> 31:13.680]  And even if it's encrypted, even if I don't know what that information is, the steganography is broken.
[31:14.180 --> 31:16.780]  The crypto is a different story, but the steganography is broken.
[31:16.880 --> 31:17.600]  The stego system is broken.
[31:17.860 --> 31:20.620]  So I'm not saying StegTunnel has reached that bar.
[31:20.720 --> 31:21.460]  I'd like to think it has.
[31:21.580 --> 31:25.740]  But there hasn't been enough analysis for me to sit up here and say, yes, we have achieved strong steganography.
[31:25.880 --> 31:27.440]  But that's where I'd like to set the bar.
[31:28.960 --> 31:32.060]  Now, network steganography is clearly not the only steganography.
[31:33.920 --> 31:39.760]  File image steganography has actually gotten probably most of the attention, hiding information in JPEGs.
[31:40.060 --> 31:44.280]  And that's because there's a large area to hide around in.
[31:45.500 --> 31:46.520]  Let me demonstrate.
[31:47.160 --> 31:53.760]  If we've got a TCP header, you know, this is your your famous TCP/IP header that I'm sure you all are familiar with and know and love.
[31:54.000 --> 31:56.380]  Where could we actually hide information in?
[31:56.500 --> 31:58.520]  Now, there's a lot of fields in here.
[31:58.720 --> 32:01.040]  And you would think there's a lot of places you could hide stuff in there.
[32:02.320 --> 32:04.480]  But the version is always going to be four.
[32:04.660 --> 32:05.740]  So that's straight out.
[32:06.200 --> 32:08.680]  Your destination IP, I mean, that's got to be set.
[32:08.880 --> 32:10.440]  You can't just mess around with that.
[32:10.740 --> 32:13.760]  Your destination port, that's probably going to be fairly widely known too.
[32:14.040 --> 32:16.480]  Your checksums are going to be based on your packet contents.
[32:16.760 --> 32:19.240]  Sequence numbers tend to be, you know, OS finger specific.
[32:20.080 --> 32:21.440]  There's really, there's no...
[32:21.440 --> 32:22.340]  I'm sorry.
[32:22.500 --> 32:23.320]  There's nothing I can do.
[32:27.390 --> 32:27.910]  All right.
[32:28.150 --> 32:30.090]  Taking it seriously, what can we do?
[32:31.150 --> 32:34.430]  A lot of people, this would be like an example of weak steganography.
[32:34.530 --> 32:35.630]  And actually, I used to think this too.
[32:35.790 --> 32:40.610]  Wouldn't it be neat if we could take, you know, information and put it in the reserved field in TCP because no one uses that?
[32:40.710 --> 32:42.190]  Well, no one uses that.
[32:42.470 --> 32:44.670]  So if anyone looks at that, you're busted.
[32:46.190 --> 32:51.630]  So the IP IDs are not random on every OS, but they're random on some OSes.
[32:52.170 --> 32:58.810]  OpenBSD, if you're using the Gen2 hardened kernels, GR Security Linux, they're random on some OSes.
[32:58.890 --> 33:02.030]  So there are some OSes out there that actually provide random IP IDs.
[33:02.490 --> 33:04.850]  Source ports, again, are random on some OSes.
[33:04.970 --> 33:06.250]  Sequence numbers are actually pretty good.
[33:06.330 --> 33:08.910]  They're supposed to be random on all OSes.
[33:08.950 --> 33:11.750]  Now, how closely they achieve that is, you know, up in the air.
[33:11.870 --> 33:20.370]  But these are the three fields that I've taken as, all right, I have a chance of hiding data in there and actually not having it be detected because it's supposed to be random.
[33:21.630 --> 33:25.710]  JPEG images, I've got a lot of different areas to hide things in.
[33:26.250 --> 33:31.050]  And some systems are better at this than others.
[33:32.330 --> 33:38.190]  Outguess is probably the best JPEG system that I'm aware of, but even that was broken a couple of years ago.
[33:38.710 --> 33:46.110]  It's hard because you've got to replicate, you can't just be random, which if you've got good cryptography, you're supposed to be random.
[33:46.410 --> 33:49.130]  Most of these things are biased in some way, shape or form.
[33:49.230 --> 33:56.950]  So you're trying to hide information in your JPEG images and you don't bias your randomness the same way that real JPEGs have their randomness biased.
[33:57.210 --> 33:57.870]  You're hosed.
[33:57.930 --> 33:59.770]  You can be detected pretty easily.
[34:01.150 --> 34:13.430]  And I've actually had people come up to me and tell me, Todd, you know, I can detect StegTunnel because your sequence numbers, their randomness looks different than this other OSes randomness.
[34:13.510 --> 34:14.310]  And I went, oh, God.
[34:14.950 --> 34:15.990]  How do I fix this?
[34:16.110 --> 34:21.910]  So I changed my random number generator because he had been keying off of a particular weakness in how I was seeding my random number generator.
[34:22.350 --> 34:23.510]  So I changed that.
[34:23.710 --> 34:26.270]  I haven't heard back from him, so I hope I fixed that.
[34:27.510 --> 34:29.210]  It took about 10,000 samples.
[34:29.770 --> 34:33.650]  So ideally, you're at least making steganography detection very, very expensive.
[34:34.290 --> 34:37.390]  As I said, I'm not guaranteeing I've reached that high bar yet.
[34:37.610 --> 34:39.990]  I would love to see more analysis done on the topic.
[34:40.530 --> 34:42.210]  So this is where I'm hiding my information.
[34:42.450 --> 34:44.290]  IPIDs, source ports, and sequence numbers.
[34:44.730 --> 34:50.070]  Now, the way I actually do it is on initial sequence number generation, I randomize my IPID.
[34:50.170 --> 34:51.010]  That's kind of a nonce.
[34:51.250 --> 34:54.530]  I randomize... well, the source port, actually, I don't change, but that's part of the nonce too.
[34:54.670 --> 34:56.190]  The whole packet is actually part of the nonce.
[34:56.450 --> 34:58.290]  Not bad to have extra nonce stuff in there.
[34:59.230 --> 35:04.190]  And then I will SHA-1 hash the packet contents and the secret.
[35:04.350 --> 35:05.870]  Both sides need to have a shared secret.
[35:05.990 --> 35:10.310]  This is where the secrecy must depend on the key, not the secrecy of the system comes in.
[35:10.450 --> 35:19.490]  And if that xord with the sequence number comes out to be zero or one, then we've got a StegTunnel potential transfer going on.
[35:19.590 --> 35:21.650]  And at that point, you've negotiated your connection.
[35:21.970 --> 35:24.690]  And your sequence numbers are just going to increment at this point.
[35:24.710 --> 35:26.510]  So they're being used as a nonce now.
[35:26.790 --> 35:28.630]  But they're not being used to hide any information.
[35:28.770 --> 35:31.410]  All the information hiding at that point goes into the IPID.
[35:32.030 --> 35:35.430]  So, are there any questions on how that works?
[35:35.690 --> 35:37.370]  I'm going to demo it in just a little bit.
[35:37.530 --> 35:38.410]  Yes, in the back.
[35:41.850 --> 35:43.270]  I get two bytes per packet.
[35:43.650 --> 35:45.010]  Yeah, bandwidth crazy, baby.
[35:47.170 --> 35:55.710]  That's probably one of the reasons why JPEGs are popular to pass information around in, because they offer, you know, each one of them is 100 kilobytes.
[35:55.790 --> 35:58.970]  So it's pretty easy to hide, you know, a kilobyte of information in there.
[36:00.630 --> 36:02.890]  With StegTunnel, I'm going to show you.
[36:03.030 --> 36:09.650]  I mean, if you've got a decent amount of network traffic and you limit yourself to transferring around text, you're actually not in a bad spot.
[36:10.210 --> 36:15.030]  If you are trying to pass large files over StegTunnel, you're going to be waiting a while.
[36:15.470 --> 36:23.610]  And not to mention the fact that there's the possibility, at least in the default modes, of that file getting corrupted.
[36:23.670 --> 36:31.210]  Now, I have additional... I have a file transfer mode specifically built into StegTunnel, which does do error correction and a checksum at the end.
[36:31.210 --> 36:35.430]  It uses a Hamming code, actually, to try and detect block... because...
[36:35.430 --> 36:42.710]  Okay, let me segue a little bit into why file integrity sucks over this kind of tunnel.
[36:44.430 --> 36:56.950]  If I lose a packet, as happens, so I'm told on the Internet occasionally, if I lose a packet and I retransmit, I cannot just simply retransmit my lost information.
[36:56.950 --> 37:01.170]  Because if I retransmit my lost information, I've got the same packet going over again.
[37:01.310 --> 37:03.030]  It's going to use the same nots and the same key.
[37:03.210 --> 37:05.470]  And at that point, I'd have the same IPID.
[37:05.910 --> 37:07.590]  That clearly is wrong.
[37:08.030 --> 37:12.930]  Because things that have random IPIDs don't use the same IPID on retransmits.
[37:13.630 --> 37:21.210]  So, at that point, in order to be undetectable, I have to completely randomize my IPID, which means whatever the other side gets is garbage.
[37:21.930 --> 37:23.250]  But I've only got two bytes.
[37:23.250 --> 37:26.290]  I don't have enough room to put a checksum in here.
[37:26.830 --> 37:31.650]  The old X modem checksum was one byte.
[37:31.870 --> 37:35.930]  And that has a chance of being wrong one in 256 times.
[37:36.150 --> 37:40.310]  I'd be losing half my data to this pseudo checksum every packet.
[37:40.530 --> 37:44.170]  So, I've got to just re-randomize it and hope that the other side figures it out.
[37:44.230 --> 37:48.350]  Now, if you've got text, you're passing English back and forth, that's pretty easy to recover from.
[37:48.450 --> 37:49.230]  You've got a garbled packet.
[37:49.350 --> 37:49.570]  Fine.
[37:49.750 --> 37:50.030]  Okay.
[37:50.710 --> 38:05.550]  If you are transferring a file, I've actually got the file split up in such a way that I can do hamming error detection and correction on a single lost packet within your hamming block size, which you can lose one out of every seven packets right now and you're still okay.
[38:06.050 --> 38:09.830]  It's a little bit slower because of that, but you can do it.
[38:10.490 --> 38:16.290]  So, yeah, throughput is limited, as is often the case with interesting stego systems.
[38:16.530 --> 38:17.490]  Are there any other questions?
[38:19.730 --> 38:20.370]  All right.
[38:21.450 --> 38:22.010]  All right.
[38:22.110 --> 38:22.530]  It's demo time.
[38:23.570 --> 38:26.910]  So, at this point, I hope that everything works.
[38:27.910 --> 38:30.930]  I'm going to start up... Can everyone see that?
[38:32.070 --> 38:32.590]  No.
[38:32.730 --> 38:33.430]  No one can see that.
[38:34.090 --> 38:35.230]  You can't see it.
[38:35.350 --> 38:35.770]  Wow.
[38:35.770 --> 38:35.810]  No.
[38:51.300 --> 38:52.280]  Is that better?
[38:53.000 --> 38:53.360]  Yes.
[38:53.500 --> 38:53.620]  Okay.
[38:53.840 --> 38:54.060]  Let me...
[39:02.750 --> 39:03.110]  Oops.
[39:03.310 --> 39:03.930]  I started it.
[39:05.330 --> 39:05.790]  All right.
[39:05.970 --> 39:07.190]  So, I'm starting up my steg server.
[39:07.630 --> 39:11.250]  Because I only have one system up here, I'm going to be using proxy mode.
[39:11.250 --> 39:16.210]  So, I'm kind of going out to one proxy, over to another proxy, and then back to myself again.
[39:16.370 --> 39:18.790]  So, I'm talking with myself, but, you know, hey, it works.
[39:19.370 --> 39:25.290]  So, I'm starting up my steg server, and I enter my extremely secure passphrase here, and my routes have gone away.
[39:25.510 --> 39:29.710]  So, allow me to quickly re-IP my thing.
[39:29.890 --> 39:30.110]  Okay.
[39:30.250 --> 39:34.890]  It needs to know what the route is, because it needs to know which interface this particular thing is.
[39:35.350 --> 39:41.090]  And unfortunately, my DHCP daemon, which I thought I killed, apparently likes to wipe out my routes occasionally.
[39:41.270 --> 39:41.570]  So, anyway.
[39:42.050 --> 39:43.530]  So, I enter my passphrase.
[39:43.610 --> 39:43.950]  I'm running.
[39:45.770 --> 39:47.290]  At this point, I start up my client.
[39:47.390 --> 39:48.630]  I enter the same passphrase.
[39:48.630 --> 39:53.050]  Now, at this point, if I SSH, or do any arbitrary TCP connection.
[39:53.190 --> 39:55.370]  I'm going to use SSH, because I've got an SSH server running.
[39:55.510 --> 39:58.390]  But I could literally tunnel this over any arbitrary TCP connection.
[39:58.830 --> 40:01.470]  So, I'm going to SSH to 10-0-0-22.
[40:02.090 --> 40:05.910]  And at this point, you can see I'm running in verbose mode, and it says I've got a new session keyed.
[40:06.010 --> 40:08.110]  So, I can pass in messages.
[40:08.430 --> 40:14.210]  And as soon as I pass traffic across it, it comes out on the other side.
[40:15.050 --> 40:21.590]  So, now, I'm at the mercy, of the user to generate this traffic for me.
[40:21.750 --> 40:26.650]  But that's really the only way that I can create sessions that don't look screwed up in some way.
[40:26.710 --> 40:35.930]  Because if I had, you know, automated session traffic being generated when I've got a message to send, you know, if I'm running this over HTTP, well, how do I generate a realistic looking HTTP GET?
[40:36.550 --> 40:37.890]  I don't worry about it.
[40:37.970 --> 40:40.610]  All I do is I say, you, the user, drive the session.
[40:40.670 --> 40:42.530]  You're going to create a realistic looking session.
[40:42.970 --> 40:47.850]  And therefore, I'm going to just hide down in the IP IDs and sequence numbers underneath your session.
[40:48.030 --> 40:51.190]  Now, if you've got SSH, it's kind of silly to be using steganography.
[40:51.330 --> 40:52.310]  I mean, you've got an encrypted tunnel.
[40:52.350 --> 40:53.390]  You should probably be trusting that.
[40:53.750 --> 41:04.910]  But if you are under a repressive government that doesn't allow cryptography, hypothetically, then you would be in a situation where you could use unencrypted traffic.
[41:05.050 --> 41:06.790]  It all looks normal and okay.
[41:07.470 --> 41:09.030]  And you're passing messages underneath it.
[41:09.150 --> 41:11.430]  So, you know, we've got another message back from this guy.
[41:11.550 --> 41:13.210]  And it's just standard in, standard out at this point.
[41:13.290 --> 41:22.950]  So, it's pretty easy to tunnel, you know, switch the IP of the server to 69.93.
[41:27.140 --> 41:29.600]  And it just waits there until I generate a little more traffic.
[41:30.080 --> 41:30.410]  Boom.
[41:30.800 --> 41:31.680]  It's on the other side.
[41:31.980 --> 41:33.660]  And you can also transfer files over this.
[41:33.740 --> 41:35.100]  And I've got a repeating text message mode.
[41:35.200 --> 41:41.500]  So, if you've got, if you've got a text message that you want sent out to everybody, you know, now is the time for all good men to come to the aid of their country.
[41:41.660 --> 41:43.870]  You can put it up there and it will repeat to any client that connects.
[41:43.870 --> 41:45.300]  Who knows the passphrase, obviously.
[41:46.720 --> 41:47.410]  So, that's it.
[41:47.540 --> 41:49.100]  And session closes and we're done.
[41:49.300 --> 41:50.890]  That's your hidden connection.
[41:51.140 --> 41:52.460]  Your covert channel, so to speak.
[41:52.620 --> 41:52.820]  Thank you.
[42:01.450 --> 42:07.030]  To get back to the file transfer format, I just wanted to illustrate what that is, kind of the internals.
[42:07.250 --> 42:13.370]  The first 80 bytes of any file transfer, first zero to 80 bytes, if it detects a null byte, that's the file name.
[42:13.550 --> 42:15.250]  You can't have files longer than 80 bytes getting transferred.
[42:15.470 --> 42:21.450]  Then it transmits the size, a checksum for the file, and then you've got this hamming encoded data after that until it hits the size.
[42:21.830 --> 42:22.370]  All right.
[42:22.610 --> 42:25.290]  And I'm going to zip along because I'm getting the warning.
[42:26.370 --> 42:27.170]  Other ideas.
[42:27.410 --> 42:39.990]  In one hour in this very room, Kathy Wang is going to be giving a presentation on Morph, which is a way of modifying TCP/IP stacks of host OSes, unbeknownst to that host OS, to look like other operating systems.
[42:40.870 --> 42:46.390]  Another kind of neat idea that you could do if you wanted to play with Packet Purgatory would be a reverse engineering man in the middle.
[42:46.490 --> 42:51.830]  Let's say you've got a digital rights management scheme that uses some weird protocol and you don't want to write something entirely for that protocol.
[42:52.070 --> 42:59.230]  You could use this to capture packets, tweak with them as you will, you know, without understanding full details of the protocol, and send it on its merry way.
[42:59.270 --> 43:00.390]  So it would be useful for that.
[43:00.970 --> 43:05.810]  If you wanted to selectively TCP replay packets, you know, so you capture one packet and then replay it multiple times.
[43:06.230 --> 43:08.110]  Packet Purgatory would be very easy to do that.
[43:08.590 --> 43:12.630]  If you wanted to write a proxy, I mean, there's some very good HTTP proxies out there.
[43:12.750 --> 43:18.210]  So it becomes really easy to do HTTP without using Packet Purgatory, just pointing it at a different port.
[43:18.370 --> 43:24.190]  But let's say you wanted to do an SMTP proxy or, you know, some new protocol that there aren't proxies existing for.
[43:24.390 --> 43:34.430]  It'd be really easy to have more... or, I'm sorry, Packet Purgatory sit in the middle and then just capture the packets and then you can only poke at the individual bits that you want to poke and then release.
[43:34.630 --> 43:38.090]  And you don't need to worry about fully getting all the underlying details.
[43:39.630 --> 43:40.890]  So, those are ideas.
[43:41.110 --> 43:42.270]  I hope I've given you some ideas.
[43:42.370 --> 43:43.370]  I hope you enjoyed Packet Purgatory.
[43:43.570 --> 43:44.070]  We have a question.
[43:44.210 --> 43:44.350]  Yes.
[43:46.790 --> 43:49.050]  Will this work through a regular firewall?
[43:49.250 --> 43:49.510]  Yes.
[43:49.730 --> 43:55.530]  It will work through a regular firewall so long as the way that you're tweaking the packets wouldn't cause the regular firewall to block it.
[43:55.650 --> 44:02.990]  So, as I said, adding IP options at that point, you have to worry about the firewall scrubbing any packets with IP options.
[44:03.110 --> 44:07.370]  But so long as it's still a legit packet, you know, you've just tweaked the type of service field.
[44:07.510 --> 44:09.890]  If you're not... if your firewall's not scrubbing on that, yeah, absolutely.
[44:12.030 --> 44:12.510]  Yes?
[44:16.580 --> 44:17.640]  Can I get your spot?
[44:18.080 --> 44:18.480]  Ah.
[44:20.820 --> 44:21.300]  Sorry.
[44:21.920 --> 44:24.260]  I don't know why I put the thanks slide after the question slide.
[44:25.420 --> 44:30.320]  The source code is all available at www.synacklabs.net slash projects.
[44:30.600 --> 44:38.360]  And you can find source code for Packet Purgatory, StegTunnel, morph, and LSRTunnel, and LSRScan, and an encrypted email list.
[44:38.440 --> 44:39.660]  I've gotten a whole slew of other projects.
[44:39.820 --> 44:40.700]  They're all in SourceForge?
[44:40.700 --> 44:41.300]  No.
[44:41.420 --> 44:42.280]  They're not all in SourceForge.
[44:42.420 --> 44:43.620]  They're all in Syn Ack Labs.
[44:43.720 --> 44:43.940]  Yeah.
[44:43.960 --> 44:44.000]  Okay.
[44:44.440 --> 44:47.960]  And then another one was, if you had a large amount of data to send, Uh-huh.
[44:48.160 --> 45:00.440]  And, you know, you only got a limited amount of user packets that you can use, can you just frack the crap out of their packets in order to have more packets to get your stuff through?
[45:00.560 --> 45:10.100]  The question was, if I had a large amount of data to send, and I had a limited number of underlying cover packets, could I just fragment the hell out of my packets and send the data that way?
[45:10.280 --> 45:15.620]  Yes, I could, but I'd be worried about compromising my, my steganographic cover at that point, because that would look unusual.
[45:16.300 --> 45:19.780]  So, I had another question in the back there.
[45:22.240 --> 45:23.300]  Can I make the slides available?
[45:23.420 --> 45:27.880]  Yes, I will post the slides on the website, uh, on Syn Ack Labs, when I get home.
[45:30.820 --> 45:35.740]  Is there a, uh, there is a tutorial available on the, on the website as well.
[45:36.020 --> 45:37.320]  Uh, it's a little out of date.
[45:37.420 --> 45:39.340]  It doesn't cover, like, the pack and inject function.
[45:39.340 --> 45:41.880]  Uh, and there's also a man page that comes with the library.
[45:41.940 --> 45:43.900]  And I'm going to be updating the tutorial probably this week.
[45:45.020 --> 45:47.540]  So, are there any other questions?
[45:48.780 --> 45:50.080]  Well, thank you very much for your time.
[45:50.220 --> 45:50.720]  I appreciate it.