 This is let's screw with end map, fingerprinting prevention through packet normalization. My name is Gregory Pickett with Hellfire Security, a quick plug. In overview of today's talk, we'll start with nosy bastards. Next is all about packet normalization, followed by working it out. And then putting it into practice and then finally finishing up. Final thoughts, that sort of thing. Okay? So let's start off with those nosy bastards. As network defenders, we see scans and probes of our network every single day. From the outside, from the inside, everybody is targeting us, identifying our assets. How they do it? Network stack implementation is highly discretionary. Differences identify the operating system type and version along attackers to identify their targets by matching the headers of their target to known operating system implementations. If your target has a TTL or time to live of 128 and uses the following options. Maximum segment size of 1460, followed by a single knob, that's actually or should be Windows scale, Windows scale of zero, followed by two knobs and ends in a sec or select then your target is likely Windows 2003 server. Implications, if they identify your assets, they know the weaknesses and how to attack them successfully without triggering your sensors, precision basically. So, anyone experience this recently? I'm sure more of you will actually experience this going home when they see that DEF CON T-shirt. It's effective life, but does it have to be? No, I say no. Why can't we remove the differences to remove their advantage, strip them of their ability to fingerprint to significantly reduce their chance of success? My answer, packet normalization. Okay, but what is packet normalization? It's not an entirely developed concept. There are many expressions but most incomplete or what I call confused and nothing involved what I had in mind. I'm going to start off by differentiating between normalization and scrubbing. Scrubbing is to do away with. Cancel. Normalization is to make normal, especially to cause to conform to a standard or norm. They are often, most of the time, used interchangeably and I believe this is a mistake. Scrubbing, removing parts, really just make a packet less of itself. It doesn't really move it toward a standard. In order to move something toward a standard, I believe that you have to reorganize its structure, not unlike what it is done in databases. Now, both of these are seen in varying degrees, often times in the same solution illustrating the confusion that is out there. We'll start off with scrubbing. PF, PF sense, net filter, all firewalls. They randomize the IP ID or they have the option to randomize the IP ID, clear the IP, do not fragment field. In addition, net filter allows you to set the IP type of service and the TTL and all three solutions is an army approaching. Our speaker is not a first time speaker. Defcon. What? Not a first time speaker? No, no, no. We may invite him to have a shot, but we're here for a very special reason tonight on a very special blossom. Sarah! Come on down. We got Sarah. Come on, Sarah. Round of applause for Sarah. Sarah, my God, you're on the price is right. That's awesome. Come on down. Come on down. Everybody, this is Sarah. Sarah has been running the camera. Thank you. We got a camera guy back here. All right. Too bad you're not getting any. No way, but even though this is not your first time speaking, you did not get shot two years ago at your first one, right? So you are owed. I made the mistake of mentioning that earlier. All right, everybody. Here's to Sarah. Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? Who? on this stage gets the double. Okay, so for all of you buying the SyncView DVD, it's going to be like, ooh. All right, here's to Sarah. Cheers. Thank you for coming. All I can say is I'm glad this is not thought con. It's getting there. So, net filter sets the, or allows you to set the IP type of service and the time to live. All three solutions will do IP fragment reassembly. Now, the primary concern, though, is like all firewalls, policy violations, abnormal packets and abnormal flows. Okay? They're some scrubbing with some normalization, but not enough nor the right kind of normalization. Not effective for fingerprinting prevention and not really practical, lacking the ability to cover the entire network. Then there are a variety of networking devices such as the Cisco ACE and Cisco ASA. Throw in some other scrubbing options, randomizing the TCP sequence number, clearing the TCP reserve field and urge fields, clearing some TCP options and enforcing a minimum IP time to live. Also, some fragment reassembly as well. As the other solutions, the primary concern is policy violations, abnormal packets and abnormal flows, keeping the bad things, obviously bad things out. All right? So, and as the others, there's, you know, the scrubbing with some normalization, but not enough nor the right kind of normalization. Not effective for fingerprinting prevention either and not practical. They're primitive devices for the most part. Therefore, they are not practical because they lack the ability to cover the entire network. This brings us to the first real, you know, totally normalization-only solution used by IPS and IDS devices, these sorts of devices. Main job, you know, as far as NISBase is concerned is IP fragment reassembly and doing some checks on the TTL to make sure that there is no evasion going on. The first solution that is truly there, just doing that normalization, primary concern, detecting attacks, detecting evasions. But it's a normalization-only solution and once again, not enough nor the right kind of normalization, not effective for fingerprinting prevention nor practical, lacking the ability to cover the entire network. Okay? Now, for those of you in the know, it's worth mentioning masquerading. Examples, IP personality, morph, IP morph. This solution, because it is a solution that, you know, it does begin to take a look at this, but what it's doing is it's a modification to the stack and the idea is for your host to pretend to be something else, like a printer. Now, that's, well, the way I look at it is it may be a little bit dangerous. Playing with those values. I don't want to degrade or break my connection. And speaking of degrading, we're talking about performance, of course. And, you know, so that kind of thing doesn't sit really well with me. And then, of course, it's a host-only solution. Through all the research that I did prior to submitting my application, I actually hadn't even heard of these solutions. So I'm probably not the only person who sees it this way as far as being, you know, the dangerous aspect. And it's not looking at this as a broader solution, all right? But it is worth mentioning because people have talked about it before. Okay? How about outgoing normalization? Have we seen anything like that? Not really. Outgoing or transit normalization hasn't really been discussed before as a solution. There's certainly nothing out there, even if there was, talking about, you know, printing fingerprinting, right? So when you look to prevent the fingerprints, it's important to take a look at that fingerprinting process. And of course, as NMAP is a major theme to the talk, this is where I will, you know, show you where I began, which is looking at NMAP and its process for fingerprinting targets. NMAP will send out TCP, UDP, and ICMP and probes. The probes are, they have responses, and NMAP will compile the results, the responses, into a fingerprint. It's composed of response attributes, response categories. It looks to categorize some of those responses. And then it also will record the structure into something like you see here. Okay? Now, what it does, it takes this fingerprint and it compares it against a database of previously enumerated operating systems. And it identifies or attempts to identify the target by finding a matching entry in this database. So it takes that target fingerprint, compares it against the database, and how closely it matches an entry in that database. Basically, that's where you get that number. It's 89%, 90%, 100%. It doesn't happen very often, but it does. Okay? So that's where I started. All right? NMAP fingerprint database. And if you just look at that just for a second, there's a lot there. It's very complex. And ultimately, too much trouble. I didn't want to work that hard, really. To unwrap, given that complexity. And then, of course, there are the other fingerprinting tools, not so famous. X-Probe 2, which is actually quite old. The newer one, CineFP. And then, of course, Nessus and the others, the vulnerability scanners. Well, you know, looking at these sorts of tools, it's really just not a good idea to begin chasing after every tool and its techniques. Ultimately, it's best just to try to disrupt any existing pattern. And so that's what I look to do with the normalization. Okay? Now, the algorithm that I developed to disrupt that pattern, it does start off with some scrubbing. The idea is to leave as little behind as possible for that fingerprint. Don't give them an inch, as it were. All right? So you clear those necessary values out, like the IP type of service, IP ECN, TCP urge, flag and urge pointer. Nice thing about doing this is that NMAP also uses some reflection probes. It will inject values into the probe and look for those values to be returned. There are some unusual, often obscure operating systems that will mirror values. They'll receive a packet and actually mirror the value back in the response. And NMAP is able to identify some operating systems just by that. All right? So you clear that out, and it takes care of that reflection probe. Next thing is you want to go ahead and randomize anything you can like the IP ID because NMAP and other tools like it do algorithm analysis. So we did not want to give them an opportunity to try to reverse engineer or just, you know, match it with an algorithm that they had previously enumerated and put into NMAP. And then this left me with the IP time to live and the TCP options. Now, in this case, scrubbing, clearing things out, randomizing wouldn't work. A new technique was going to be needed and this is where I apply the normalization. And this is what I came up with. Outgoing normalization, true packet normalization, as I say, to the rescue. Now, the algorithm to normalize the IP time to live makes some assumptions that the starting TTL was originally a well-known value. You can look that up on the internet. There's a list that as the packet traversed the network, it would be decremented only. And that the packet, you know, travels or would travel less than 32 hops. These are reasonable assumptions to make given the expectations that we have out there. It's true for 99% of the packets out there. So it turns out they're pretty solid, pretty sound assumptions. Now, what the algorithm does is it takes that current TTL and backs into one of those well-known values to estimate the number of hops traveled. Then it recalibrates the current TTL by taking a new standardized starting TTL of 255 and then subtracting the hops to come up with a recalibrated standardize version of that calculation to arrive with a brand new recalibrated current TTL and then it puts that in the packet. That's the process, the overall flow of the algorithm, the steps that it takes. This is a more logical view. The algorithm starts with the lowest well-known TTL first, making sure that the most likely TTL gets selected first. Then it moves on, the next one, the next one, and then just assumes, you know, it's at the bottom, it's going to be able to go ahead and assume it's already pretty much close to 255. All right. So there are actually several exceptions to this normalization to keep a number of layer three mechanisms from breaking, which we will talk about momentarily. Then there is the algorithm to normalize the TCP options. It starts out with some assumptions as well. There are only a few well-known options that are needed. Order was ultimately, though, unimportant. The requirement that I imposed on this was that the values not be changed. I did not want to degrade or even possibly disrupt that socket. The algorithm then, with those assumptions operating under that requirement, reads the necessary options and then discards the rest, rewrites then the options in the proper order or the order that I've selected and then fills out the remaining space with knobs to make sure it hits the right 32-bit boundaries so that first off, the packet is not displaced in memory in any way and the check sum could be calculated without any sort of problems. Okay. These are the options that I selected and their order. Maximum segment size, the window scale, selective act and then MD5 hash if present. So, after processing, an options list would look like this. Okay? Pretty simple. All right. But it's really nice on paper, but even better when you actually put it into action. So putting it all together, making everyone, all the packets, look the same with the proof of concept ID guard. Now, to put this on a piece of hardware, I wanted to make sure I selected a suitable platform, suitable hardware. The first thing I wanted to make sure was that it was already modified by others. I didn't want to reinvent the wheel. I didn't want to break new ground in the area. I wanted to spend the time with the normalization. I wanted to make sure there's plenty of documentation available. So for the hardware I chose the micro-tick router boards, the micro-tick RB450G specifically right there. Also, I identified a suitable operating system with an available base that I could then put into VM and spend most of my time developing the proof of concept there. And it also, I wanted to make sure that it had a writeable filing system, a writeable file system so I could make quick changes. For the OS, I picked open WRT. Now, this is a very, very, very abbreviated list of the steps that involve. I started out with the open WRT site. There is page after page of instructions. A lot of it is not specific. There are things missing. There's errors. Now from this, I condensed it into a very clear and concise set of instructions. Well, I call it clear and concise because I wrote it. You may feel otherwise. I'm going to be posting this on the project site after the talk so that you, what can avoid my pain? Putting this together. So that will be up there. Okay. We now want to talk about putting this on the hardware, you know, what worked because I know we are getting really tired of those nosy bastards. Okay. Well, we're going to start off with what didn't work or what didn't work so well by itself. The type of service clearing, the ECN clearing, urge flag, urge pointer clearing, the IP ID randomization, do not fragment flag clearing, and this grubbing. Okay. Now I say it didn't work so well alone. What really did at least help out, which made the rest of the algorithm possible, that would be the IP ID randomization. That did a good job of contributing to the rest of the algorithm, putting everything together and making it work real nice. The others I might ultimately remove because there's a possibility, even a remote possibility, that the sock could be disrupted, especially on an internal network with a type of service. So I might end up removing those later. But right now they're there. So what did the IP ID randomization help out? What did that synergy, what worked? Well, the time to live standardizing and the TCP option standardizing, the normalization. Okay. Now, of course, I can talk about this all day and just say this is really wonderful, but it's better to show you the results. We'll start off here and then show you a demo in just a few minutes. A Windows 7 target, unprotected. Looks like, wow, surprise. A Windows 7 host. A Windows Server 2003 target. Unprotected looks like a Windows 2003 host. And then an Ubuntu desktop, unprotected. Looks like a Linux host running the 2.6.x or 3.x kernel. And a Red Hat Enterprise target. Unprotected looks like a Linux host running the 2.6.x or 3.x kernel. I shouldn't say looks like, I should say identified because it does a pretty good job of identifying these and figuring out what they actually are. Now, Windows 7, protected by ID Guard, looks like an Allied Talisman. And then a Allied Wear Router. A Windows Server 2003 target. Protected by ID Guard looks like an Allied Talisman, Allied Wear Router. Ubuntu desktop protected by ID Guard looks like a Cisco router running iOS 12.x. See? Not so bad. And a Red Hat Enterprise target. Protected by ID Guard looks like a device running Embedded De-link. Yes, they are looking all the same. They're all looking like routers. Not so bad. And unless you are that router, then I guess it's not so great. Alright. So, in addition to those results, fantastic results, I would say, there are some other effects. NMAP does report a negative distance number. A little strange, but ultimately completely harmless. How about those other fingerprinting tools? The X-Probe, Grandpa there. CineFP, Nessus. Turns out that, well, for Nessus at least on the operating system, identification for the network and the transport layer, those mechanisms. So, they're confused. Equally confused. They see either nothing at all or have a completely wild off exactly like NMAP is. And then, of course, there are those other tools. The tools that we use to monitor and troubleshoot the network. Ping, TraceShot, two good examples. They're able to operate normally without any problems whatsoever. Now, I did talk about doing a demonstration. So, here we go. Because it's always good to just talk about it, but to show you. Okay, I'm going to make sure first off, the ID guard is not running so that you get a good look of what these things look like without it. I don't, nothing is fixed here. There we go. Just going to scan. I'll just take a few seconds there. Got a lot of VMs. There we go. Nope. Okay. Takes a very amount of time. Got the scanning machine here. The router is right here. And over here is the targets. There's about, it's taken unusually long, about a time. Over here we have the targets. There are four VMs running. Okay. A little slow for some reason. Keep in mind this is without ID guard. So, whatever is going on, it's on its own. Okay. I have some time to fill. All right there. Okay. So, this is performing the normal activity. I put a dash O even though, I mean, you can do a dash A. But, you know, as you can see sometimes it's a little squirrely, so there's no use kind of putting more things in the way to go wrong. Okay, so the first target is identified as a Linux host running the 2.6.x or 3.x kernel. Hope everyone can see that. It looks like it far-folded the second one. As I said, it was looking like it was having some problems. These are VMs anyway. All right, so the third target is identified as a Microsoft Windows 2003 host. Sounds like disk gum music over there. It's a party. So the fourth target is identified as a Linux host running the 2.6.x or 3.x kernel. So this is exactly what we expected, accurate identification. All right, there we go. Run that again. Hopefully it's not as squirrely as it was just a moment ago. Now, we're running this. The performance is fine. Runs the exact same speed. There we go. See? That's what it was supposed to look like the first time. They're actually, when you run the scan with ID guard in place, the time is the same. There is no degradation of network performance. Okay. So the first target looks like, trend map, looks like and device running embedded D-link. Okay. The second target looks like an Allied Taliesin, Allied Wear router. I had actually never even heard of these people until I did this. The third target looks like an Allied Taliesin, Allied Wear router. All right. Fantastic. And the fourth target looks like to end map like a Cisco router running iOS 12.x. Fantastic. Thank you. And now we want to go ahead and I'm hoping the network continues to operate as it's supposed to. Let's go ahead and run a trace route. There we go. Function normally. Because we want to make sure that not only is the network running well as it should be running with ID guard in place, but the hosts are also operating functionally. Are they able to carry out the tasks that they've been given? Well, as we see, as we saw earlier, the, there we go. SSH works fine. Okay. Not interrupted in any way. And then we actually have a web server running over there. We want to make sure that that web server is available, that we can browse to that web site. And there's four VMs running over there. And of course, it is iOS. So there's a little delay. All right. So, network is working great. And I think I might have the time to run SYNFP real quick. I'm one of the targets. Okay. Has anyone here used SYNFP before? Do you use it? No? Okay. There we go. So unknown OS. I threw that in there because it is a little bit more recent than like last year, two years ago. Two years ago. They had an update to it. It's not quite as old as X probe. Okay. So we saw some fantastic results. There are some challenges like authorized activity and other methods of identification like banners and direct query and identification through layer seven. The first challenge, authorized activity, scanners, manager platforms, the resolution to that sort of challenge, ID guard excludes them. You can load ID guard with an exclusion to allow that sort of authorized activity to occur unhindered. So by loading ID guard with exclusion, it tells ID guard to basically leave that traffic alone, do not perform any normalizations, any transformations on the traffic. Okay. So the challenge is overcome. The second challenge, banners and direct query. There's Windows networking available. So we have a Windows host. There's an application layer query. And OS details are returned in the reply. The resolution is split into two parts. On the perimeter network, those protocols are generally not available, should not be available. So that just leaves us with the internal network. Those sorts of application layer queries and specifically those application layer replies will have to be normalized as well to provide an additional fingerprinting prevention capability. Okay. So while a challenge now, ultimately, it won't be. Okay. Then there are also some concerns. Upstream and downstream fragmentation, TTL tenuation, it's just what I'm calling it. Probably not accurately described, but you'll understand what I'm talking about in just a second. TTL special uses, as we saw before, the trace route. And TCP option sensitivity. And how about link local routing protocols? Okay, especially RIP. First concern, upstream fragmentation. The IP ID is randomized at some point while, you know, packet is traversing the network. And, you know, ID guard is there. It randomized the IP ID. After that, another router sees it, needs to fragment it. It can't. Sends a message back to the original host. The host is a bit confused because it never sent a packet with that IP ID. It just, you know, keeps saying that original packet. The resolution is, you know, ID guard excludes, I'm sorry, ID guard clears the do not fragment field. Now this does break MTU path discovery. I have not had a problem with that so far. You may have a problem, so it's something that I will be continuing to look into. If you run into this sort of problem, you can always add an exclusion. That particular host. Okay. So, problem solved. Then there is the second concern of downstream fragmentation. Each fragment is given a different IP ID. Therefore, the destination can't reassemble the original resolution. Access switch placement. Go ahead and have that IP ID randomized before my, you know, encounter, the packet might encounter a router that would need to fragment. And then, of course, ID guard excludes fragments just in case the host actually does the fragmentation. So both of those together means the problem is solved. Okay. Then there is a concern of TTL tenuation. That's what I'm calling it. Packet travels more than 32 hops. Not all these hops are accounted for. And therefore, the packet, TTL is continually extended. You know, traveled and got a number of hops, 66 hops, and it's basically only recalibrated with two. So it would have more available hops to make before it expired if this happens more than one time. Then there's a possibility that a routing loop could occur. The resolution to that, access switch placement. So that the change to the TTL occurs before any routing activity begins. And then after, when it's already the destination when it doesn't matter anymore. Okay. So problem solved. Then there is the concern of TTL special uses. The TTL is recalibrated. You know, one becomes 254. Two becomes 253. The TTL time to live never runs out. Therefore, no intermediate hop reports and trace route fails. The resolution, ID guard excludes ICMP echo requests from the TTL transformation. And then ID guard excludes the UDB tracer range from all, you know, TTL transformations. Problem solved. And then link local routing protocols. The rip packet has a TTL of one. TTL of 255 is abnormal. The packet then is malformed. Resolution ID guard excludes routing protocols. Okay. And then this concern which is always lingering in any of these sorts of cases. Issues of performance that might break something. Poorly coded application. Who knows? What else? You know, it is a concern, but we have to at some point in time begin to hold our developers, hold our vendors accountable. So while it is a concern, for the most part, my idea is that maybe we should begin, you know, getting them to fix these things and not continue to propagate poorly coded software. So it's there. We need to be aware of it, but I'm not as worried about it myself. And that's what testing is for. Okay. Now, so we have some concerns and some challenges. For the most part, not really a big deal so far. So what are our benefits for putting this in place on our network? It does shield the network from casual attackers. Casual attacker, your script kitty, they have a new exploit. They are aware of a weak configuration. They're going to go looking for that particular host. These hosts are generally, you know, popular, ultimately common. They're not going to find those sorts of targets. They're going to move on looking for something that matches what they're looking to attack. And you have automated assaults. You have any sort of classification going on. Scanning, looking for those targets that match an exploit that they have. So they categorize it. Matching exploit. The targets are going to be less likely to fall into one of these categories. Therefore, the software on the server, this bot, is not going to really believe it has anything to launch against this target. It's going to move on. And then oblique threats. If you have someone making a toehold, they're not going to have that target that they prepared for, the preferable next step where they like to move when they go laterally. So it is a good job helping to shield the network from these sorts of threats. And of course, it helps protect unmanaged, unpatched and unhardened devices. Because as it moves past these targets, moves beyond them, then the fact that the target is unmanaged, unpatched and unhardened becomes less of an issue. And then it also helps defeat canned exploits. If there is some sort of identification, it's going to make it much more difficult for them to get a precise, even though they say they know what's Windows through other means, without that exact version and that service pack, then they're going to have to launch the exploit canned. And as we know, exploits in order to be most effective need that context. So without that context, it's going to lower their chances of success overall. Okay, so the antacid results and great benefits, network wide. So what's next now that we have the solution to getting this out there in place? First off, more platforms, open source router firmware, DDWRT, putting it there. And then switches where it ultimately belongs. There's some native Linux switches. MacroTik has one. Arius, I believe is the name. There are Linux versions of the extreme switches, Cisco switches in particular. So trying to get some sort of modification there. That may require permission, of course. And so if I plan to do production trials, because that's what we want to do is we want to take these switches and put them into some sort of trial out there, starting the test environment, of course, and then into production. So does anyone interested in running a trial, please contact me after the talk. And then from there, with those switches in place, talking to the vendors. Because I want to get this out there as a feature on the switches. Like IGMP and DHCP snooping, I think that would really add a lot of benefit to that access space, that access switch space. So if you're also a vendor or just a vendor, I would love to also talk to you after the presentation to begin that conversation, begin that path. All right. So some final thoughts. There's a couple more things after this, but this is just like a summary. Accurate target identification is key to a successful attack. Identification that is way too easy to perform. Let's change that with fingerprint prevention. I've proven that it can be done. Now we just need to make it happen. The proof of concept will be available this afternoon. There's version 0.5. It's a POC, after all. It has the IPv4 support right now. Version 0.6 will be out in about a month. I'm still working out some kinks with the IPv6 support. That will be there. And then, oh, yes, application layer queries they will be dealt with. So there will be a version right after that to handle that. There's the SHA-1 hash. I tried a SHA-256 hash, but it's too big. Just out of control. So we'll just do a SHA-1. And that is actually where the POC will be available momentarily. It will be a source. And then soon, like, I, well, I'm giving this one away. So I've got to make myself a new router. And it'll be a perfect opportunity to test the package. Open WR2 package. So that'll be up there too. Okay. And some links to provide some context to today's talk. There we go. Should I back up for the hash? I think he's got that. All right. Are we good? Okay. And then this is a special time of the talk right here. Special thanks to a couple of people there. Aditya Sudh for working out the many, many problems in my abstract. And then Kenny, Annie Security, Kevin Fogarty, Kathy Gillette, and Nick Pruitt. Now the reason for this, this is the last one. So this will conclude my talk, but I want to make sure that I get everyone's attention for this. Nick Pruitt, I promised him that I would get his face upon a slide at DEF CON. This is my second time around, sorry, I thought I would get that out of the way. And here he is in all his glory. He sent me many pictures. This is the one that I wanted to use. This is probably how he would prefer to be remembered. Okay. In fact, right back there, if everyone there he is, just so he's properly embarrassed, there we are. Okay. So that's it. Thank you.