[00:00.000 --> 00:03.980]  ...with morph and future directions.
[00:06.940 --> 00:09.220]  So what is OS fingerprinting?
[00:10.100 --> 00:12.620]  Well, it's been around for a little while.
[00:13.340 --> 00:27.180]  Now, before Nmap, people were doing OS fingerprinting already by doing things like Telnetting to the host and looking at what kind of OS information was coming back from the banners.
[00:27.740 --> 00:32.240]  So it's not like OS fingerprinting started when Nmap came out.
[00:33.060 --> 00:49.560]  There's also manual reconnaissance, which is doing things like looking at postings of, you know, email questions by people who work in certain places, saying, oh, you know, I'm having a problem with my AIX, you know, box and, you know, what can I do?
[00:50.060 --> 00:55.460]  And you look at where they posted this from and go, oh, that place is using AIX.
[00:55.460 --> 00:58.100]  So just, you know, things like that.
[00:59.240 --> 01:04.700]  And, you know, then KSO came out and did active fingerprinting techniques.
[01:05.040 --> 01:08.380]  And they really were the first people to do that.
[01:08.380 --> 01:19.580]  And they did a really good job because then Fyodor took those techniques and developed that further into Namp along with, you know, more active fingerprinting techniques.
[01:20.160 --> 01:22.400]  And that was really good as well.
[01:23.960 --> 01:26.600]  Passive fingerprinting is a little bit different.
[01:26.960 --> 01:34.500]  The idea is the same, but it's, you know, instead of using active solicitation of responses, we're looking at passive.
[01:34.500 --> 01:43.200]  So you're sitting and sniffing traffic that's coming from someone else and you're trying to figure out what they are based on what you see.
[01:45.000 --> 01:50.500]  And we have timing analysis, which is pretty clever, I think.
[01:50.680 --> 01:55.760]  And there was a proof of concept tool that came out called Ring.
[01:56.380 --> 01:59.380]  And the authors wrote a white paper about it.
[02:00.880 --> 02:02.800]  They didn't release Ring.
[02:03.020 --> 02:04.420]  So it was proof of concept.
[02:04.680 --> 02:15.520]  But it was still a very good idea because they said, okay, well, what happens if someone sends us a response to a SIM packet that we send and we drop it?
[02:17.120 --> 02:20.200]  And how long does it take before they send another one?
[02:21.260 --> 02:23.540]  And then we drop it and how long does it take?
[02:23.740 --> 02:26.480]  So then we measure the timing between the packets.
[02:26.480 --> 02:29.520]  And based on that information, we can figure out what they are.
[02:33.250 --> 02:37.570]  So I kind of covered the history a little bit on the last slide.
[02:37.770 --> 02:39.430]  But here's just to clarify.
[02:40.510 --> 02:48.130]  CASEL came out first and then, you know, Nmap developed the technique further and added some new techniques.
[02:48.130 --> 02:50.810]  And then passive OS fingerprinting.
[02:51.590 --> 03:03.730]  And then Ofer Arkin thought of like, oh, you know, what happens if we use ICMP packets to, you know, do active fingerprinting to see what they respond to ICMP informational packets.
[03:04.130 --> 03:05.970]  So that was also really good.
[03:06.370 --> 03:07.410]  And Ring.
[03:10.540 --> 03:14.720]  So why do we even care about defeating OS fingerprinting?
[03:14.960 --> 03:19.560]  How many people in here have done pen tests or vulnerability assessment before?
[03:20.980 --> 03:21.460]  Okay.
[03:21.640 --> 03:22.600]  So some people have.
[03:23.880 --> 03:30.880]  When you go and you do one of those tasks, you connect up into the network and you say, oh, okay.
[03:31.640 --> 03:34.000]  Or you can do it remotely, depending.
[03:34.320 --> 03:37.280]  But you say, okay, well, what do I want to find out?
[03:37.280 --> 03:42.680]  I want to find out as much information about that network or that host as possible.
[03:43.360 --> 03:51.860]  So you sit there and you say, okay, well, let me do a scan on that host, see what ports are open and what they are.
[03:52.180 --> 03:56.960]  You know, so that what they are information is really important.
[03:57.420 --> 04:04.740]  Because that's what you're going to use to look at your arsenal here of tools and decide what you're going to use against them.
[04:04.740 --> 04:13.920]  So that's one of the most important pieces of information that you can get about a target host is their OS.
[04:14.940 --> 04:21.360]  Now, OS scanners exploit the host OS behavior.
[04:21.360 --> 04:41.660]  And what I mean by that is, you know, when you have TCP implementation, RFC 793, it says, okay, if, you know, you get a SIM packet, you respond with a SYN/ACK or something, and it specifies how you respond to certain types of packets.
[04:42.500 --> 04:48.420]  That's really important, except that it doesn't give details about every single thing.
[04:48.740 --> 04:51.860]  So there are lots of packet combinations.
[04:51.880 --> 05:03.900]  For example, a SYN/FIN urge push, that if that was sent to the remote host, you know, the stack implementation wouldn't necessarily know what to do with it.
[05:05.480 --> 05:07.000]  So that's a problem.
[05:07.300 --> 05:07.880]  So that's a problem.
[05:07.880 --> 05:13.240]  And so every single vendor does their stack implementation differently.
[05:14.080 --> 05:17.940]  And that leads to honesty by the OS.
[05:18.300 --> 05:25.480]  And in return, you know, that leads to OS scanners being able to figure out what they are based on their behavior.
[05:26.860 --> 05:34.140]  But I don't want to, like, go away thinking, you know, this is the vendor's fault, because it's not necessarily entirely the vendor's fault.
[05:34.260 --> 05:35.440]  They do the best they can.
[05:35.840 --> 05:46.900]  But in reality, the RFC 793 doesn't specify if you get a FIN packet exactly how you should respond to it.
[05:47.140 --> 05:51.260]  So, for example, if Windows gets a FIN packet, it sends back a reset.
[05:51.880 --> 05:55.620]  But if OpenBSD gets a FIN packet, it just drops it.
[05:55.700 --> 05:56.160]  That's it.
[05:56.280 --> 05:57.600]  It doesn't respond to that.
[05:58.620 --> 06:04.480]  So I think there may need to be some tightening done on some of this, you know, on the RFC.
[06:04.840 --> 06:07.380]  So it's not really entirely the vendor's fault.
[06:10.120 --> 06:12.020]  All right, so now we get to Morph.
[06:12.180 --> 06:13.000]  What is Morph?
[06:14.100 --> 06:22.080]  Well, I wanted Morph to be a user-land process that allows the user to select whether they want to be...
[06:22.080 --> 06:27.880]  Right now, the implementation allows you to select whether you want to be OpenBSD or Windows 2000.
[06:28.640 --> 06:33.000]  You can't select Linux yet, but I plan to implement that.
[06:34.620 --> 06:42.080]  Now, currently, you can install Morph on a Linux machine, but you can't install it on any other OS.
[06:42.080 --> 06:46.080]  And I do plan on implementing installation on more OSs.
[06:47.600 --> 06:55.580]  But what Morph will do is it will handle, like, all of your inbound packets via its inbound handler.
[06:57.020 --> 07:10.240]  And depending on what type of packet it is, it will either send the packet onto the kernel and then have the kernel send the packet back out to outbound handler and then to the remote host.
[07:10.460 --> 07:19.020]  Or it will reply directly to the remote host from the inbound handler if the packet is something like, you know, destined for a closed port.
[07:20.340 --> 07:23.180]  And I'll go into a lot more detail about that later.
[07:26.460 --> 07:31.880]  And another thing I wanted to mention is Morph is definitely not production quality yet.
[07:32.040 --> 07:35.300]  So don't go take Morph and install it on your production server.
[07:35.960 --> 07:43.380]  And, you know, like to be about complaints about, you know, the production server going down because it's not there yet.
[07:43.380 --> 07:44.220]  Yeah.
[07:47.920 --> 07:51.420]  When do I predict that it will be for production servers?
[07:54.300 --> 07:55.200]  Any idea?
[07:57.300 --> 08:00.840]  Well, I, you know, it's relatively stable right now.
[08:02.700 --> 08:06.120]  But I really haven't tested it on a production server.
[08:06.220 --> 08:11.240]  So I don't want to, you know, give that kind of impression that it will work on there.
[08:11.240 --> 08:14.440]  As for timeline, I really don't know.
[08:14.680 --> 08:19.780]  It depends on how busy I am and, you know, how much time I have to implement more for Morph.
[08:19.860 --> 08:22.340]  And I do have a lot of future plans for it.
[08:25.570 --> 08:30.330]  Morph is BSD licensed, which I thought was the best way to do it for me.
[08:30.890 --> 08:34.620]  And it can be downloaded at the Syn Ack Labs project website.
[08:37.380 --> 08:45.280]  And actually assessing my synopsis for the talk that Morph 0.2 is being released, but actually I'm doing 0.3.
[08:45.560 --> 08:48.620]  So there's an extra release over.
[08:52.200 --> 08:55.860]  Now, Morph is built on Packet Purgatory Library.
[08:56.100 --> 08:59.480]  How many people here were at the 2 o'clock talk on?
[08:59.820 --> 09:00.500]  Okay.
[09:00.860 --> 09:01.540]  Oh, good.
[09:01.540 --> 09:06.380]  So, I have some people in here who already know what Packet Purgatory is.
[09:07.060 --> 09:15.580]  Now, Packet Purgatory, for the benefit of those who weren't here, acts as kind of a wedge between the OS kernel and the network interface.
[09:16.400 --> 09:21.980]  And it makes it really easy for me to use Packet Purgatory to build Morph on.
[09:22.780 --> 09:27.900]  In fact, it probably saved me about 4,000 lines of code, which is great for me.
[09:29.760 --> 09:35.200]  Now, Packet Purgatory is built on libpcap and libdnet, as some of you know.
[09:35.880 --> 09:41.320]  And so, indirectly, Morph does use libpcap and libdnet.
[09:41.580 --> 09:44.720]  Morph uses libpcap to sniff on the interface.
[09:45.000 --> 09:50.180]  And uses libdnet to write raw Ethernet and raw IP packets.
[09:50.180 --> 09:57.250]  And also to manipulate the route table and firewall rules under the loopback firewall mode.
[10:00.660 --> 10:10.060]  From a high-level architecture standpoint, I'm going to talk about this and then go into more detail on Morph implementation.
[10:10.060 --> 10:22.600]  You can see that there's a remote host sending either a response to us, Morph, or, you know, initiating a connection to Morph.
[10:22.880 --> 10:36.840]  So, when the response... when the remote host sends the packet, Packet Purgatory is acting as that wedge and intercepts that packet and sends it along to Morph inbound handler.
[10:37.800 --> 10:58.140]  And Morph will look at the packet and say, oh, okay, I'm either going to respond directly back to the remote host, or, since this packet is, you know, of certain type, which I'll go into more detail later, I'll route it over to the kernel right now and have the kernel work on responding to it.
[10:58.140 --> 11:13.240]  And when the kernel responds to it, then it sends it back out and via Packet Purgatory, again, grabbing that packet, the packet gets sent to the Morph outbound handler and then heads back to the remote host.
[11:13.880 --> 11:19.260]  And in the next diagram, you can see it's a breakdown in a little more detail of Morph.
[11:19.380 --> 11:28.200]  And you can see that Morph has an inbound handler, a state table, and an outbound handler, which those three components together make up Morph.
[11:29.420 --> 11:40.580]  So now you can see more detail that when the remote host sends the packet and Morph gets it and says, oh, okay, well, let's say this packet is destined for a closed port.
[11:41.340 --> 11:47.340]  Well, since it's destined for a closed port, I don't really need to send it through to the host OS kernel.
[11:47.480 --> 12:00.640]  I'll just respond to it directly from the inbound handler and say, okay, well, inbound handler writes the proper response depending on the OS that you want to emulate, and that packet goes back to remote host.
[12:01.420 --> 12:05.000]  Now, let's say that packet was destined for an open port.
[12:05.520 --> 12:09.960]  So the Morph inbound handler looks at that and say, oh, okay, this is a SIN packet.
[12:09.960 --> 12:12.220]  It's destined for an open port.
[12:12.220 --> 12:19.940]  I'm going to, you know, save that SIN session in the state table so that I can keep track of this session.
[12:21.000 --> 12:28.780]  And then I'm going to pass that packet along to the host OS kernel, which will respond to that packet.
[12:28.780 --> 12:32.280]  However, the underlying kernel is going to respond to it.
[12:33.040 --> 12:47.360]  Send it back out to outbound handler, which is going to look at the packet and say, ah, I'm going to rewrite the relevant parts of the headers to reflect the OS that we want to emulate, and then send it back out to the remote host.
[12:50.220 --> 12:56.700]  Now, packet purgatory, some of you were at the talk, so you have more of an idea.
[12:57.000 --> 13:01.880]  But this is more information about packet purgatory for those who weren't at the talk.
[13:02.420 --> 13:17.380]  And like I mentioned, you know, packet purgatory uses libpcap and libdnet to sniff on the interface and also through route table manipulation and firewall rule manipulation.
[13:17.740 --> 13:23.740]  It's not a kernel module, BSD license, and it can be downloaded at the SYNAC Labs website.
[13:27.600 --> 13:41.120]  So, now I'm going to go into detail about packet purgatory utilizing libpcap and libdnet and see how that affects Morph in terms of proxy mode and loopback firewall mode.
[13:42.320 --> 13:45.860]  So, there's two modes that packet purgatory uses.
[13:46.220 --> 13:48.700]  There's a proxy mode and loopback firewall mode.
[13:48.920 --> 14:02.920]  And in Morph, we use the proxy mode when we have a firewall on the host that's not supported by libdnet, such as libdnet supports, you know, IP chains, IPF, and PF.
[14:02.920 --> 14:07.220]  So, if you're not using those firewalls, then use the proxy mode.
[14:07.720 --> 14:14.000]  Another advantage for the proxy mode is that your firewall rules don't just get dropped.
[14:14.500 --> 14:14.960]  Okay?
[14:15.100 --> 14:21.760]  But if you're using the loopback firewall mode, effectively your firewall is being put out of the picture.
[14:24.750 --> 14:26.650]  Okay, here it is in detail.
[14:26.950 --> 14:46.710]  For proxy mode, we can see that remote host, let's say remote host sends in a packet, and, you know, vllibpcap sniffing on the interface packet purgatory, which is labeled here in this diagram as proxy IP, we're in proxy mode.
[14:47.710 --> 14:52.290]  So, vllibpcap sends the packet along to the inbound handler of Morph.
[14:53.070 --> 14:58.170]  And so, Morph looks at that packet, and let's say it's destined for closed port.
[14:58.470 --> 15:03.050]  So, Morph says, oh, okay, I'm just going to respond directly to the remote host.
[15:03.050 --> 15:10.530]  So, I'm going to do a libdnet raw IP write back to the remote host because it's a closed port.
[15:11.330 --> 15:25.770]  Or, if it's for an open port, then Morph will look at it and say, okay, I'm going to do a raw IP write via libdnet and send that packet along to the host OS kernel, which will respond to that packet.
[15:27.210 --> 15:47.750]  And send the packet along, and vllibpcap sniffing on the interface, packet proxy will send that packet to outbound, which will then rewrite the packet to reflect the emulated OS and do a raw IP write via libdnet and send it back to the remote host.
[15:48.530 --> 15:53.230]  So that, in a more detailed picture, is how Morph is handling the packets.
[15:54.650 --> 16:04.670]  Now, for loopback firewall mode, we're using packet proxy to block, you know, the host OS kernel from getting that packet right away.
[16:05.590 --> 16:14.230]  So, remote host sends the packet, and, you know, now we have packet purgatory sitting there as a firewall.
[16:15.790 --> 16:35.810]  And via libpcap, that packet is sent to inbound handler of Morph, which looks at the packet and says, okay, I'm either going to do a direct response to the remote host, like we saw in the last scenario, or we're going to do a libdnet raw IP write and send it to the loopback interface.
[16:35.810 --> 16:47.810]  Okay, and if that happens, then the host OS kernel responds to it and sends it along via libpcap sniffing on the interface.
[16:48.310 --> 16:51.070]  And that packet goes to outbound.
[16:52.210 --> 16:57.110]  And outbound takes that packet and does a raw Ethernet write this time.
[16:57.110 --> 17:02.510]  I can't do a raw IP write, but then it would go back to the loopback interface.
[17:03.390 --> 17:05.930]  And then the remote host gets a response.
[17:10.410 --> 17:11.010]  Okay.
[17:13.390 --> 17:16.850]  There are some OS scanners that are Morph for 4 right now.
[17:17.530 --> 17:20.770]  There's KSO, MMAP, XPROBE2.
[17:21.450 --> 17:25.830]  I'm still working on doing the passive OS fingerprinting fooling.
[17:27.030 --> 17:29.070]  And there's a timing analysis.
[17:29.510 --> 17:34.490]  Now, I have an idea how I would implement that, but it's just not implemented yet right now.
[17:38.150 --> 17:46.590]  Now, I think it's worth bringing up some of the other tools that have tried to fool OS scanners and have, you know, done so successfully.
[17:47.310 --> 17:56.150]  For example, there's FPF, which was written as a loadable kernel module for Linux, which made it not portable.
[17:56.710 --> 17:59.290]  So I didn't like that aspect of the tool.
[17:59.530 --> 18:07.930]  And plus, it was a little bit buggy because when I tried to compile and install it, it, you know, segfaulted, so that's not very good.
[18:08.950 --> 18:14.990]  Now, IP personality, I like the fact that it could emulate certain OSs.
[18:15.890 --> 18:20.930]  But again, it's a patch for the Linux kernel, so that makes it not very portable.
[18:21.950 --> 18:28.870]  And I really was looking for something that would be portable and be able to do OS emulation.
[18:29.650 --> 18:35.570]  And so I thought, hey, you know, if I write Morph, then that will do both of those, and that will be what I want.
[18:37.970 --> 18:43.090]  So that's why Morph was, you know, kind of created because of this.
[18:46.780 --> 18:47.680]  All right.
[18:48.500 --> 18:55.280]  Now, all of the current OS fingerprinting techniques, I can defeat with Morph.
[18:56.060 --> 19:05.060]  Active fingerprinting, passive fingerprinting, timing analysis techniques, I think all of these can be defeated with Morph.
[19:05.060 --> 19:08.840]  I know how I would do timing analysis, it's just not implemented yet.
[19:12.950 --> 19:15.990]  Now, before we do this, let's do the demo.
[19:30.060 --> 19:39.290]  Okay, so I have this host here, which is going to be running Morph, first as Windows 2000 and then as OpenBSD.
[19:39.290 --> 19:46.400]  And then from this host here, I'm going to run Nmap against it, and you'll see on the screen, the output of Nmap.
[19:54.910 --> 19:57.250]  Okay, running as Windows 2000.
[20:01.150 --> 20:03.590]  Hope everyone can read the font here.
[20:04.330 --> 20:04.810]  Is that okay?
[20:06.170 --> 20:07.730]  All right, let's see.
[20:08.350 --> 20:15.050]  Okay, so I'm going to do the Nmap scan, and just to save some time, I'm going to pick one open port and one closed port.
[20:15.050 --> 20:17.810]  And that host is 10-0-0-0-4.
[20:28.170 --> 20:32.110]  All right, so now it's saying it's Windows 2000 or Windows XP.
[20:33.450 --> 20:37.070]  Okay, so now I'm going to change this host's OS to OpenBSD.
[20:51.500 --> 20:53.480]  All right, let's do the scan again.
[21:06.840 --> 21:08.320]  Okay, so we have OpenBSD.
[21:10.080 --> 21:18.180]  Now what I'm going to do is stop running Morphs, and then do a scan on this host again, so you can see that the underlying OS is Linux.
[21:42.870 --> 21:49.970]  All right, so that's the underlying host OS, and you know, so that's what I've got so far.
[22:01.980 --> 22:09.220]  Okay, so now I'm going to go into a little bit more detail about the different OS scanning tools and how Morph feels with them.
[22:10.480 --> 22:16.180]  There's KSO, which I started with because I thought it was the simplest tool to start with.
[22:17.050 --> 22:27.060]  And it uses an active fingerprinting technique and actually sends seven packets over to the target host, all of which are destined for open ports.
[22:28.240 --> 22:29.600]  It's pretty simple.
[22:29.780 --> 22:30.900]  It's not too complicated.
[22:32.200 --> 22:37.320]  Now I do want to mention that the OS fingerprints on KSO are a bit outdated.
[22:37.320 --> 22:40.480]  I don't think they're really maintaining it very much anymore.
[22:40.860 --> 22:42.940]  They're only up to the 2-1 kernel.
[22:46.200 --> 22:52.240]  Okay, so this is a table that I put together on how Morph responds to KSO packets.
[22:52.660 --> 22:58.620]  So you can see on the left-hand side that, you know, the KSO packet types are in that column.
[22:58.900 --> 23:06.140]  And then the Morph handling status is on the right side, and that consists of inbound, state table, and outbound.
[23:06.140 --> 23:19.920]  So some packets, you know, such as fin, that's an interesting case because if an inbound handler gets a fin packet, then it looks at it and says, well, am I emulating Windows or not?
[23:20.040 --> 23:22.900]  Because if I am, I better be sending a reset back.
[23:23.540 --> 23:30.700]  Now if I'm not emulating Windows and, you know, I'm Linux or OpenBSD, then I don't respond at all to that packet.
[23:32.380 --> 23:41.500]  The SIN I mentioned a couple times, that's another case where Morph looks at the packet and says, is this destined for an open port or a closed port?
[23:41.800 --> 23:59.680]  And if it's destined for an open port, then Morph sends it along to the kernel, which then routes it to outbound, but saves the session in the state table so we know that when we send a SIN app and then they send an app back that will know that that was part of the same connection.
[24:00.240 --> 24:02.960]  That's going to be very important to maintain the state.
[24:05.280 --> 24:08.300]  The other cases aren't really that interesting.
[24:08.760 --> 24:16.860]  The SIN plus XXX plus YYY, that's just flags that are not really used very often, like ECN.
[24:17.560 --> 24:22.740]  So that's whatever the emulated OS wants to respond to that.
[24:25.610 --> 24:42.850]  Now there's X-Probe 2, which I really liked working with because, well, I'm looking at, you know, X-Probe 2 fingerprints and I'm looking at M-Map fingerprints and I say, hey, you know, M-Map is very exact about what it expects.
[24:43.110 --> 24:47.970]  So if you don't match exactly your signature, then it's not going to know what you are.
[24:47.970 --> 25:02.910]  X-Probe 2's, I guess, ingenuity is that it does kind of a fuzzy fingerprint logic thing where it gets back a response and it says, oh, this is about a 70% match.
[25:03.090 --> 25:07.350]  So this is the highest probability that it's this OS.
[25:07.970 --> 25:15.350]  Well, I said, well, Ofer's pretty clever, you know, for doing the fuzzy OS fingerprinting thing, but he's really making this easier for me.
[25:16.150 --> 25:21.150]  Because I'm sitting here going, oh, okay, I either have to be really exact or I don't.
[25:21.770 --> 25:24.290]  So not having to be really exact is cool.
[25:25.950 --> 25:30.350]  X-Probe 2 is an active fingerprinting techniques scanner.
[25:31.730 --> 25:36.490]  And it sends four different types of ICMP packets to the target host.
[25:36.870 --> 25:43.370]  One of those packets that it sends is an information request packet, which I thought, what the heck is that?
[25:43.370 --> 25:48.090]  So I looked at, you know, Richard Stevens' TCP IP Illustrated Volume 1.
[25:48.210 --> 25:49.270]  I just loved that book.
[25:50.250 --> 25:54.850]  And what it says, it said that information request packet is obsolete.
[25:55.490 --> 26:00.310]  Like, well, who is using an obsolete packet then?
[26:00.590 --> 26:04.650]  And so I looked through X-Probe 2's fingerprints.
[26:04.650 --> 26:07.850]  I'm like, okay, no, no, no, no.
[26:08.910 --> 26:10.370]  Yes, who is that?
[26:10.630 --> 26:11.470]  It's AIS.
[26:12.030 --> 26:15.130]  I was like, you know, get with it.
[26:15.510 --> 26:16.990]  Modernize, you know, kind of thing.
[26:17.870 --> 26:19.210]  So that was pretty funny.
[26:19.350 --> 26:25.750]  I was like, oh, okay, so that's why Ofer even bothered to put that in there because AIX uses it.
[26:25.950 --> 26:26.790]  It's obsolete.
[26:28.910 --> 26:31.830]  There's a UDP packet that's sent as well.
[26:33.330 --> 26:34.790]  ICMP on reachables.
[26:35.090 --> 26:36.150]  Not a big deal.
[26:36.490 --> 26:43.690]  And the final packet is a vanilla regular SIN packet, which we had already dealt with in case so.
[26:46.170 --> 26:49.110]  And here's the table for X-Probe 2.
[26:50.510 --> 26:58.970]  And you can see here that there are four information, ICMP informational packets on the left, and the UDP and the SIN.
[26:59.830 --> 27:02.870]  Most of these responses are very interesting.
[27:02.870 --> 27:13.290]  Since the ICMP packets are informational, I just had the inbound handler respond directly to the remote host when they get that type of packet.
[27:14.070 --> 27:16.110]  There's no point in passing it through.
[27:17.510 --> 27:27.250]  UDP, that's, you know, we look at whether the port is destined, you know, open port or is closed port destination, and respond accordingly.
[27:27.770 --> 27:29.630]  And same goes for the SIN.
[27:32.550 --> 27:33.110]  Nmap.
[27:33.770 --> 27:39.630]  I chose to go with that one last because it's the most challenging for the reason that I explained earlier.
[27:39.630 --> 27:40.910]  It's very exact.
[27:41.550 --> 27:54.850]  And I can't tell you how frustrated I was with, you know, looking at the cases over and over again, doing the tests over and over again, and getting all these responses back from Nmap saying, I don't know who you are.
[27:54.910 --> 27:57.370]  And I'm like, I'm only one option off.
[27:57.930 --> 27:58.290]  You know?
[27:59.950 --> 28:00.690]  Oh, well.
[28:00.930 --> 28:01.890]  Made all the difference.
[28:03.330 --> 28:08.110]  But Nmap sends nine different types of packets to the target host.
[28:08.910 --> 28:14.610]  And four of those packets are for closed ports and five of those are for open port.
[28:14.830 --> 28:27.610]  So if you've ever run Nmap and you see messages like, you know, host OS prediction is going to be less reliable, that's probably because it couldn't either find an open port or a closed port.
[28:27.610 --> 28:34.910]  So in that case, it can't run like half of its test cases, which would definitely make it a lot more, a lot less reliable.
[28:38.090 --> 28:41.910]  Nmap uses the most test cases out of all of the ones that I looked at.
[28:43.690 --> 28:46.290]  And it can be kind of a challenge sometimes.
[28:46.290 --> 28:53.010]  I had to run a lot of TCP dump, you know, hex dump cases and look at what's going on.
[28:55.510 --> 28:58.410]  So here's the table for that, for Nmap.
[28:58.710 --> 29:04.010]  And you can see on the left open port, closed port type packets that are sending.
[29:06.150 --> 29:14.650]  Most of these cases, obviously all the closed port packets are going to be responded to by inbound directly.
[29:17.290 --> 29:20.870]  I don't think any of these cases are really that interesting.
[29:21.510 --> 29:26.650]  SYN/FIN urge push is a null packet that's like no flag set.
[29:29.150 --> 29:30.370]  So that's that.
[29:31.950 --> 29:39.470]  Now the morph state table, I wanted to talk a little more detail about because I really haven't yet.
[29:40.050 --> 29:49.670]  The remote host will send a packet, and let's say, you know, it sends a packet and it's got a sequence number of some sort.
[29:50.070 --> 30:01.950]  And your OS, your underlying OS, is more random about generating a sequence number according to Nmap than your emulated OS.
[30:02.070 --> 30:08.230]  So let's say you're trying to emulate Windows 2000, and your underlying OS is Linux or OpenBSD.
[30:09.430 --> 30:14.510]  Well, Linux and OpenBSD are a lot more random about sequence numbers than Windows is.
[30:14.650 --> 30:16.190]  So how do we handle that?
[30:16.430 --> 30:20.610]  And I think that's a very good example to use for how the state table is being used.
[30:21.230 --> 30:26.750]  So when that happens, what outbound will do...
[30:26.750 --> 30:28.970]  Let's say I initiate the connection, okay?
[30:29.070 --> 30:31.010]  So I send a syn to a remote host.
[30:31.270 --> 30:42.650]  So outbound looks at that packet going out and says, oh, the underlying host generated a, you know, well, outbound is going to generate a sequence number.
[30:43.210 --> 30:51.490]  But that sequence number is going to be different in randomness than the underlying host.
[30:51.790 --> 31:00.290]  So I'm going to take the offset of those two numbers and store that offset in the state table.
[31:00.930 --> 31:02.410]  Why do I want to do that?
[31:02.570 --> 31:13.490]  It's because otherwise the remote host is going to look at the number and the next number that it gets back on the connection and say, well, this doesn't make any sense.
[31:13.490 --> 31:17.770]  It's not, you know, very random or it's very random when it shouldn't be.
[31:18.030 --> 31:24.430]  So I store that offset in the state table and remember that information.
[31:24.690 --> 31:28.450]  Send the packet along to the remote host, which sends a syn act back.
[31:28.450 --> 31:39.830]  And in the acknowledgement number, then I subtract the offset from that acknowledgement number before I send it back to the kernel so the kernel won't be all confused.
[31:40.510 --> 31:46.110]  You know, so that's a situation where the state table is really being used to advantage.
[31:48.690 --> 31:54.950]  The sequence number thing is definitely a complicated issue that has to be handled.
[31:56.970 --> 32:05.550]  So we have other OS scanners that, you know, need to be fooled in order for Morph to be more complete of a tool.
[32:06.250 --> 32:08.930]  One of those is the passive OS fingerprinting.
[32:09.050 --> 32:19.250]  I figured that in order to fool that, I mean, there's really no active solicitation by the passive OS fingerprinting tool.
[32:19.250 --> 32:28.110]  So what I need to do is be really good about things like sequence number generation and making sure I'm consistent with what I say I am.
[32:28.890 --> 32:41.530]  And as long as I'm doing stuff like that and also timing analysis, if I'm doing all of those things correctly, then the passive OS fingerprinting should be taken care of.
[32:42.290 --> 32:50.870]  Now the packet timing analysis, ring, that's another issue that I'm going to have to use the state table for.
[32:51.270 --> 33:06.790]  I'm going to have to know, okay, since I'm emulating this OS, and I never really talked about how ring works, but rings will send a syn packet, and then when I send a syn act back, it will take that packet and drop it.
[33:06.790 --> 33:15.390]  So after a set amount of time, according to what OS I am, I'll send another one, another syn act, because I don't think they ever got it.
[33:15.770 --> 33:17.270]  And they'll drop that too.
[33:17.430 --> 33:30.630]  And they'll just keep doing that, and they'll calculate the timing difference between those subsequent packets, and then figure out what OS you are based on that, because, you know, every OS does it differently.
[33:31.970 --> 33:38.230]  So in that case, what I'm going to need to do is I'm going to need to, first of all, I know what I'm emulating.
[33:38.510 --> 33:45.230]  And I know what the expected time difference for packet retransmission for what I'm emulating.
[33:45.670 --> 33:54.670]  So let's say I've got this amount of time, and I send a syn act, and they drop it, and I never hear anything back.
[33:54.670 --> 34:02.090]  So after this amount of time, I send another syn act according to what I want to emulate.
[34:02.310 --> 34:15.960]  But in the case of if that time passes before I, you know, want to send another packet, then I have to make sure that it's double the original time that I was going to retransmit.
[34:18.540 --> 34:21.700]  And that's going to be useful to have a state table to do.
[34:23.760 --> 34:28.380]  There's a tool called Snack Time that I didn't really look at a lot.
[34:28.520 --> 34:48.080]  But they said on their site that what they were doing was, since Ring was proof of concept and was never released, they were going to take the techniques from Ring that was discussed in the white paper, and they were going to add in some other passive OS fingerprinting techniques and put together Snack Time.
[34:48.260 --> 34:52.160]  So that's one of the tools that I want to take a look at more.
[34:55.620 --> 35:00.060]  There was a talk at CANSEC West earlier this year.
[35:00.200 --> 35:01.420]  I think it was in April.
[35:02.660 --> 35:05.940]  And I don't know how many people here were at CANSEC West.
[35:07.400 --> 35:08.280]  Okay, one.
[35:08.840 --> 35:09.460]  All right.
[35:11.080 --> 35:15.100]  There was a talk on new OS fingerprinting techniques.
[35:15.100 --> 35:24.520]  So I think this guy works for NFR, and he's developed some new techniques for what's currently existing.
[35:25.220 --> 35:30.980]  A lot of what he's doing is actually expanding on timing analysis.
[35:31.300 --> 35:34.180]  But he does this in various creative ways.
[35:34.520 --> 35:39.400]  For example, he'll use layer 7 information to do timing analysis.
[35:40.220 --> 35:46.140]  For example, he'll send an HTTP GET packet over to the remote host.
[35:46.460 --> 35:48.840]  And the remote host will respond.
[35:50.140 --> 35:52.680]  HTTP, you know, respond to that.
[35:53.320 --> 35:57.380]  And he'll look at that, and he'll, you know, drop it.
[35:58.180 --> 36:02.900]  And then after a certain amount of time, the host will retransmit that packet again.
[36:03.500 --> 36:08.220]  And he'll take all those timing differences, and he'll say, ah, this is their OS.
[36:08.220 --> 36:13.220]  Because this is how they deal with application level retransmission.
[36:13.620 --> 36:19.900]  Which, apparently, is different timing than, like, regular TCP flag retransmission.
[36:21.940 --> 36:23.600]  So that's very interesting.
[36:23.960 --> 36:26.140]  And he expands on the timing analysis.
[36:26.140 --> 36:40.520]  So that instead of just dropping your SYN/ACK and calculating how much time it takes for another one, he'll drop other types of packets and see how long it takes you to, you know, respond again with that one.
[36:41.860 --> 36:45.340]  He'll also do things like measure the window behavior.
[36:45.340 --> 36:51.000]  So you've got your, you know, your send buffer.
[36:51.820 --> 36:56.560]  And he'll look at that, and he'll say, okay, so you got your send buffer.
[36:56.740 --> 36:58.460]  You're sending me this information.
[37:00.000 --> 37:04.440]  Well, I'm just not, you know, going to tell you that I've got this information.
[37:04.440 --> 37:06.320]  And then you're going to try and send it again.
[37:06.940 --> 37:12.520]  And after a while, he'll take the timing differences between those, and he'll figure out what your OS is.
[37:14.760 --> 37:18.080]  And he actually has, like, 37 test cases.
[37:18.260 --> 37:19.220]  I mean, think about this.
[37:19.340 --> 37:20.500]  NMAP has, like, nine.
[37:22.920 --> 37:28.980]  So I think I'm going to be spending a lot of time looking at his test cases and seeing what I can do about that.
[37:32.270 --> 37:41.310]  Okay, so we sat there, we talked about all these OS fingerprinting techniques and this bad thing, that implementation.
[37:41.310 --> 37:45.410]  What can you really do to avoid being fingerprinted?
[37:46.170 --> 37:50.270]  Well, like I said earlier, it's not really vendor's fault entirely.
[37:50.270 --> 37:55.250]  There are really legitimate gray areas in stack implementation.
[37:57.130 --> 38:08.690]  So maybe what we need to do is have another RFC which defines more clearly exactly what kind of behavior we should expect under certain conditions.
[38:09.190 --> 38:12.450]  So that everyone can follow the same specifications.
[38:14.970 --> 38:25.770]  Now, another thing that you can do is, if you're really paranoid, you can take your server and you can make that a proxy.
[38:26.070 --> 38:29.590]  And then, like, you can have your high value target behind that.
[38:30.210 --> 38:33.530]  And so you're proxying all those hosts behind you.
[38:33.530 --> 38:38.330]  And so if someone tries to scan them, they never figure out what they are.
[38:38.470 --> 38:41.230]  They only know what your proxy host is.
[38:41.690 --> 38:46.690]  But if you're really paranoid, you can do something like install Morph on your proxy host.
[38:47.690 --> 38:55.030]  And don't worry about the high value targets that your proxy obviously hardened them and do all those traditional security things.
[38:55.570 --> 38:57.250]  Morph is just a layer, by the way.
[38:57.390 --> 38:59.510]  It's not going to save you from everything.
[39:00.790 --> 39:08.030]  And then, by doing that, you know, you can just avoid having people figure out what OS you're running.
[39:11.670 --> 39:16.010]  Now, there are a lot of challenges to defeating OS fingerprinting.
[39:16.510 --> 39:18.910]  And I think it's important to share that.
[39:19.470 --> 39:28.650]  First of all, if you're going to be advertising a different window size than what your underlying OS is supporting, be very careful about that.
[39:28.650 --> 39:35.010]  For example, Linux, the window size is, you know, 5.7K bytes.
[39:35.430 --> 39:38.270]  For Windows, it's like 64K bytes.
[39:38.790 --> 39:55.130]  So if you tell somebody your underlying OS is Linux, and you're trying to emulate Windows 2000, and you tell somebody, oh, my window size is 64K bytes, they're going to push back 64K bytes of stuff to you.
[39:55.130 --> 40:02.530]  And you're going to go, oh, wait, my underlying OS is confused, because it's not, you know, it's not ready for that.
[40:02.770 --> 40:11.590]  So what you're going to do, and what I've done, is I'm going to save that information in the state table.
[40:11.590 --> 40:12.570]  Right?
[40:12.730 --> 40:27.750]  So they push me 64K bytes worth of stuff, and I save that information in the state table, and then I push off that information off the state table to the underlying OS at a rate that it's comfortable with, so it's not completely confused.
[40:31.370 --> 40:44.050]  Now, I went into this earlier, but having to distinguish between normal and abnormal connections, using a state table to figure out, oh, well, someone just sent me a SYN Act.
[40:44.290 --> 40:51.270]  Was that because I just sent them a SYN, or did they just send me a SYN Act without any solicitation from me?
[40:52.430 --> 40:55.530]  And I would use the state table to figure that out.
[40:55.830 --> 41:04.010]  Read off the state table, and if there's no SYN connection that's recorded there, then I'll be like, oh, this isn't legitimate.
[41:04.450 --> 41:08.450]  So I'll just have the inbound handler respond directly to it.
[41:09.770 --> 41:16.730]  Now, even with all these challenges, even if I do morph, you know, completely correctly, and it works perfectly.
[41:17.330 --> 41:35.390]  The problem is, if someone runs NMAP against me and looks at what ports I have open, and my underlying OS is Windows 2000, and I'm saying I'm OpenBSD, and they say, you know, they see that I have port 137 and 139 net files open, that's not going to work.
[41:37.070 --> 41:42.550]  So this OS fingerprinting defeating technique isn't going to help against that.
[41:43.110 --> 41:47.450]  What it is useful for, though, is for the casual scanner.
[41:47.950 --> 41:59.570]  Let's say somebody, you know, is scanning a large block of IPs and just wants to see what hosts out there are running Windows, so that they can target more later.
[42:00.390 --> 42:07.910]  So in that case, they would do the scan, and they would say, okay, well, these hosts say they're Windows, so I'm just going to focus on these IPs.
[42:08.650 --> 42:14.470]  In that case, that would help you, because they're not looking for you as a target directly.
[42:17.370 --> 42:20.990]  Also, there are some automated attacks, like the NMDA worm.
[42:21.570 --> 42:23.950]  They don't care what OS you're running.
[42:24.210 --> 42:28.690]  They're going to go and knock on every single door, and that's not going to...
[42:28.690 --> 42:31.590]  Morph isn't going to be able to help in that situation either.
[42:31.590 --> 42:33.610]  Your underlying OS is Windows.
[42:34.230 --> 42:34.390]  Whoops.
[42:35.110 --> 42:38.090]  You know, NMDA doesn't care what you say you are.
[42:41.270 --> 42:41.930]  All right.
[42:42.110 --> 42:45.750]  There's a lot of work that I have to do for Morph still.
[42:46.390 --> 42:51.170]  And one of those is that I'd like to support more emulation of OSs.
[42:51.370 --> 42:57.730]  You know, for example, it would be cool to be able to emulate Linux, Solaris, all these other OSs.
[42:59.350 --> 43:09.830]  Also, it would be really great to be able to get Morph to install on Windows, because I figured that most people who would be using tools like this would be running Windows.
[43:12.890 --> 43:21.410]  Now, also, the timing analysis and the passive OS fingerprinting tools, it would be really nice to be able to afford those as well.
[43:21.410 --> 43:23.810]  So I'll be working on that next.
[43:25.750 --> 43:33.630]  Eventually, farther down the line, when I have Morph as a much better package, there's Polymorph that I want to implement.
[43:33.650 --> 43:37.670]  And that's going to look more into pooling application scanners.
[43:37.870 --> 43:49.750]  Not necessarily closing the ports for those applications, but messing around with the layer 7 information so that the application scanners won't know necessarily what's running.
[43:50.710 --> 43:55.150]  And, of course, everyone loves a GUI, so I'm just going to put in a GUI support for Morph.
[43:55.170 --> 43:58.630]  That would be pretty easy compared to the other stuff that I want to do.
[44:00.570 --> 44:02.410]  Here are some people who helped me out.
[44:02.590 --> 44:13.330]  I really appreciate it, either by writing, you know, libraries that I can build Morph on, or by reviewing my slides or suggestions for the slides.
[44:15.310 --> 44:16.430]  Any questions?
[44:16.950 --> 44:17.270]  Yeah.
[44:17.730 --> 44:32.010]  Why is it important to emulate other operating systems instead of just masking your own?
[44:33.510 --> 44:37.310]  Well, you're kind of masking your own operating system with Morph.
[44:37.310 --> 44:40.150]  I mean, the rest work is going to be determined.
[44:41.290 --> 44:42.490]  It's framed for her.
[44:44.350 --> 44:44.870]  Oh.
[44:45.070 --> 44:45.390]  This would be...
[44:45.390 --> 44:46.550]  This would be...
[44:46.550 --> 44:48.130]  I don't know what operating system is.
[44:48.630 --> 44:50.350]  She then should never give them up to
[44:55.560 --> 45:00.730]  the other computer, whereas if your mask results in the 2000...
[45:00.730 --> 45:14.360]  Right, and like I mentioned, if you have the casual attacker who's doing the mask scan on a block of IPs to see how many Windows machines there are out there, this is where it can really help to use Morph.
[45:15.120 --> 45:22.980]  Now, if you do something like you don't want to tell them what you are at all, you don't want to give them any information, they might get curious and target you more.
[45:23.730 --> 45:26.060]  You know, oh, wow, this is a puzzle here.
[45:36.290 --> 45:43.980]  Well, I think most attacks are right now focused on Windows, not OpenBSD, so...
[45:46.530 --> 45:48.070]  Okay.
[46:14.950 --> 46:26.370]  Well, I think that if you're already targeted, as you know, someone already knows that they want to attack your machine, I don't think Morph can help you in that case.
[46:26.770 --> 46:36.750]  So it doesn't even matter that they just want to do a port scan and, you know, see what applications you're running, because if they get to that point, then I don't think Morph can help you.
[46:41.190 --> 46:46.470]  Morph, I see it as kind of another layer of security that you can think about using.
[46:46.950 --> 46:52.110]  It's not, not by any means, a solution, a complete solution.
[46:53.850 --> 46:55.970]  I had a lot of fun working on this.
[46:56.110 --> 46:58.410]  I think this is a really fun research project.
[47:01.170 --> 47:08.970]  Well, I wanted to do something, you know, contribute to the community, and I thought that this would be a really cool way to do it.
[47:17.190 --> 47:18.950]  Oh, I can't really hear you.
[47:19.230 --> 47:20.150]  Can you use the microphone?
[47:20.490 --> 47:20.810]  Thank you.
[47:29.130 --> 47:34.750]  You know, it's really like you can modify the state table to maybe emulate like other hosts that are on the network.
[47:36.690 --> 47:37.690]  Have you looked at HoneyD?
[47:37.930 --> 47:38.270]  Yeah.
[47:38.570 --> 47:38.810]  Okay.
[47:38.890 --> 47:41.430]  I mean, it seems like it's a little similar.
[47:43.830 --> 47:44.370]  Right.
[47:44.570 --> 47:48.930]  This is a, this completely takes over your host.
[47:49.770 --> 47:58.930]  And HoneyD is kind of, it sets up many virtual machines on your host, so your host is still free to reply as it wishes.
[47:59.330 --> 48:02.790]  But Morph is a complete takeover of the host.
[48:02.790 --> 48:03.250]  Okay.
[48:03.390 --> 48:03.990]  So...
[48:06.760 --> 48:07.420]  Yeah.
[48:11.590 --> 48:20.510]  Do I understand it correctly that Morph is only responding to active probes, and it's not scrubbing like all traffic that's coming through?
[48:20.710 --> 48:25.530]  It's waiting to see an X probe or an Nmap packet before it scrubs traffic?
[48:27.050 --> 48:32.390]  So you're asking if Morph is effective against X probe?
[48:32.710 --> 48:32.990]  No.
[48:33.130 --> 48:39.650]  Is it scrubbing all traffic that it sees, or is it only scrubbing traffic when it sees an Nmap probe, an X probe?
[48:41.230 --> 48:46.450]  Oh, it's scrubbing traffic for every single packet that comes in to that host.
[48:46.690 --> 48:47.070]  Okay.
[48:47.070 --> 48:50.250]  It doesn't have to be relevant to OS scanner at all.
[48:50.730 --> 48:51.130]  Okay.
[48:51.370 --> 48:51.910]  That's my question.
[48:51.910 --> 49:00.730]  Because it completely takes over the host and Morph will completely respond according to what emulating OS you want to be.
[49:00.950 --> 49:01.330]  Okay.
[49:01.610 --> 49:01.750]  Thanks.
[49:02.050 --> 49:05.550]  So it can be a regular traffic packet.
[49:07.830 --> 49:15.430]  And actually, you know what I should have demoed is a SSH connection into this host while Morph is running.
[49:15.650 --> 49:16.770]  But that'll work too.
[49:17.410 --> 49:19.350]  So I just want to make sure that works.
[49:19.550 --> 49:24.750]  Because that means that you can still do regular connections and stuff over that.
[49:30.430 --> 49:31.110]  Thank you.