1 00:00:00,042 --> 00:00:02,918 GREGORY PICKETT: This is "Let's screw 2 00:00:02,918 --> 00:00:08,375 with nmap," fingerprinting prevention through packet normalization. 3 00:00:10,167 --> 00:00:16,375 I am Gregory Pickett with Hellfire Security a quick plug there. 4 00:00:16,459 --> 00:00:20,626 Here is an overview of today's talk. 5 00:00:20,999 --> 00:00:25,083 We will start with "nosey bastards," then "all 6 00:00:25,083 --> 00:00:32,999 about packet normalization" followed by "working it out," and then "putting it 7 00:00:32,999 --> 00:00:41,999 into practice," and finally "finishing up," final thoughts, that sort of thing. 8 00:00:42,999 --> 00:00:46,375 So let's start with "Those nosey bastards." 9 00:00:50,167 --> 00:00:55,501 We see scans and probes of our network every single day 10 00:00:55,501 --> 00:01:00,959 from the outside, the inside, everybody is targeting us, 11 00:01:00,959 --> 00:01:03,999 identifying our assets. 12 00:01:03,999 --> 00:01:06,918 So how do they do it? 13 00:01:06,959 --> 00:01:10,959 Network stack implementation is highly discretionary. 14 00:01:11,209 --> 00:01:15,626 DIPs identify the operating system type and version, 15 00:01:15,626 --> 00:01:18,999 along with attackers, to identify targets 16 00:01:18,999 --> 00:01:25,375 by patch matching target headers to known system implementations. 17 00:01:25,792 --> 00:01:33,167 If your target has a TTL or "time to live" of 128, and if it uses 18 00:01:33,167 --> 00:01:38,125 the following options, maximum segment size 19 00:01:38,125 --> 00:01:44,542 of 1460 followed by a single NOP Windows scale of zero, 20 00:01:44,542 --> 00:01:51,999 followed by two NOPs, and ends in a sec or select vac, the target 21 00:01:51,999 --> 00:01:56,751 is likely a Windows 2003 server. 22 00:01:57,667 --> 00:01:59,209 Implications. 23 00:01:59,501 --> 00:02:04,501 If they identify your assets, they know the weaknesses, and how 24 00:02:04,501 --> 00:02:09,209 to attack them successfully without triggering your sensors, 25 00:02:09,209 --> 00:02:12,083 so basically precision. 26 00:02:13,167 --> 00:02:15,584 Anyone experience this recently? 27 00:02:15,999 --> 00:02:18,751 I am sure more of you will actually experience this going 28 00:02:18,751 --> 00:02:21,834 home when you see the DEF CON T shirt. 29 00:02:22,834 --> 00:02:24,834 It is a fact of life. 30 00:02:25,999 --> 00:02:28,334 But does it have to be? 31 00:02:28,999 --> 00:02:30,501 I say, no! 32 00:02:31,417 --> 00:02:38,083 Why don't we remove the differences to remove their advantage, strip them 33 00:02:38,083 --> 00:02:44,250 of their ability to fingerprint to significantly reduce their chance 34 00:02:44,250 --> 00:02:46,250 of success? 35 00:02:47,417 --> 00:02:53,209 My answer: Packet normalization. 36 00:02:54,083 --> 00:02:58,209 So okay, but what is packet normalization? 37 00:02:58,792 --> 00:03:01,125 The concept isn't entirely developed yet. 38 00:03:01,709 --> 00:03:06,167 There are many expressions, but most are incomplete or what I call 39 00:03:06,167 --> 00:03:10,999 "confused" and do not involve what I have in mind. 40 00:03:14,667 --> 00:03:20,083 I will start off by differentiating between normalization and scrubbing. 41 00:03:20,167 --> 00:03:23,959 Scrubbing is "to do away with" or cancel. 42 00:03:23,999 --> 00:03:27,918 Normalization is to make normal, causing to conform 43 00:03:27,918 --> 00:03:30,501 to a standard or norm. 44 00:03:32,709 --> 00:03:35,125 Most of the time they are used interchangeably, 45 00:03:35,125 --> 00:03:37,834 which I believe is a mistake. 46 00:03:37,918 --> 00:03:42,999 Scrubbing or removing parts really makes a packet less of itself; 47 00:03:42,999 --> 00:03:47,250 it doesn't really move it toward a standard. 48 00:03:47,584 --> 00:03:54,999 In order to do that, I believe you have to reorganize its structure, not 49 00:03:54,999 --> 00:03:59,709 unlike what is done in databases. 50 00:03:59,709 --> 00:04:03,709 Both of these are seen in varying degrees, an often times 51 00:04:03,709 --> 00:04:08,876 in the same solution, illustrating the confusion out there. 52 00:04:09,209 --> 00:04:16,999 We will start off with scrubbing, PF, PF accepts, Net Filter they have 53 00:04:16,999 --> 00:04:26,501 the option to randomize the IP ID, clear the IP "do not fragment" field. 54 00:04:26,626 --> 00:04:38,999 In addition, Net Filter allows you to set the type of service and TTL, 55 00:04:38,999 --> 00:04:50,542 and all three solutions there is an army approaching, I see. 56 00:04:50,542 --> 00:04:55,375 (Applause) Our speaker is not a first time DEF CON speaker. 57 00:04:56,999 --> 00:05:00,083 We may invite him to have a shot, but we are here 58 00:05:00,083 --> 00:05:02,999 for a special reason tonight. 59 00:05:05,584 --> 00:05:07,709 We've got Sarah. 60 00:05:07,709 --> 00:05:08,999 Come on down. 61 00:05:12,626 --> 00:05:15,999 My God, Sarah, you are moving like you are on The Price is Right. 62 00:05:19,083 --> 00:05:23,209 Everybody, this is Sarah who has been running 63 00:05:23,209 --> 00:05:25,209 the camera. 64 00:05:27,834 --> 00:05:29,999 We have a cameraguy back here. 65 00:05:35,459 --> 00:05:37,709 Too bad you're not gettin' any. 66 00:05:41,125 --> 00:05:45,959 Even though this isn't your first time speaking, you did not get your shot two 67 00:05:45,959 --> 00:05:48,834 years ago at your the first one. 68 00:05:48,834 --> 00:05:50,999 GREGORY PICKETT: I did not, and I made the mistake 69 00:05:50,999 --> 00:05:53,459 of mentioning that earlier. 70 00:05:53,459 --> 00:05:54,459 So you are owed. 71 00:05:55,626 --> 00:05:58,834 Okay, everybody, here is to Sarah. 72 00:06:04,542 --> 00:06:07,834 (Applause) We got calls for a double. 73 00:06:07,834 --> 00:06:12,459 There is an extra shot, so the one on the stage gets the double! 74 00:06:18,083 --> 00:06:25,999 For all of you who buy the sync view DVD, it will be all wiggly. 75 00:06:25,999 --> 00:06:26,999 Here is to Sarah! 76 00:06:26,999 --> 00:06:27,999 Cheers! 77 00:06:33,083 --> 00:06:35,292 (Applause) Thank you for coming. 78 00:06:41,709 --> 00:06:42,999 Rookie! 79 00:06:49,542 --> 00:06:57,083 GREGORY PICKETT: I am glad this is not SHOT CON. 80 00:07:02,751 --> 00:07:10,417 Net Filter allows you to set the IP type service and time to live. 81 00:07:10,751 --> 00:07:16,751 All three solutions will do IP fragment reassembly, 82 00:07:16,751 --> 00:07:24,584 but like all firewalls, policy violations and abnormal packets 83 00:07:24,584 --> 00:07:28,959 and flows are the concern. 84 00:07:28,959 --> 00:07:31,999 Some scrubbing with some normalizations happens, 85 00:07:31,999 --> 00:07:36,999 but not enough, nor is the right kind of normalization effective 86 00:07:36,999 --> 00:07:41,834 for fingerprinting prevention, lacking the ability to cover 87 00:07:41,834 --> 00:07:44,209 the entire network. 88 00:07:44,876 --> 00:07:51,083 Then there are networking devices like Cisco Ace and SA, throwing 89 00:07:51,083 --> 00:07:57,999 in other scrubbing options randomizing TPC sequence number and clearing 90 00:07:57,999 --> 00:08:04,167 the reserve and urge fields, clearing TPC options and enforcing 91 00:08:04,167 --> 00:08:10,999 a minimum IP time to live, as well as fragment reassembly. 92 00:08:10,999 --> 00:08:16,292 With regard to other solutions, the concern is policy violations 93 00:08:16,292 --> 00:08:22,292 and abnormal flows and keeping the bad things out. 94 00:08:25,918 --> 00:08:29,999 As the others, the scrubbing with some normalization, 95 00:08:29,999 --> 00:08:35,083 but not enough for the right kind of normalization, not effective 96 00:08:35,083 --> 00:08:38,999 for fingerprinting prevention either. 97 00:08:39,584 --> 00:08:42,999 They are primitive devices, but they are not practical 98 00:08:42,999 --> 00:08:47,876 because they lack the ability to cover the entire network. 99 00:08:49,999 --> 00:08:55,918 This brings us to the first real totally normalization 100 00:08:55,918 --> 00:09:01,292 only solution used by IPS and IDS devices. 101 00:09:01,292 --> 00:09:07,083 These sorts of devices, their main job in this space is IP fragment reassembly, 102 00:09:07,083 --> 00:09:11,501 and doing some checks on the TTL to make sure there 103 00:09:11,501 --> 00:09:14,584 is no evasion happening. 104 00:09:14,999 --> 00:09:19,999 The first solution that is truly there, just doing the normalization. 105 00:09:20,459 --> 00:09:23,999 The primary concern is detecting attacks, 106 00:09:23,999 --> 00:09:28,999 detecting evasions, but it is normalized and not enough or 107 00:09:28,999 --> 00:09:32,876 the right kind of normalization, not effective 108 00:09:32,876 --> 00:09:38,292 for fingerprinting prevention, nor practical, lacking the ability 109 00:09:38,292 --> 00:09:41,792 to cover the entire network. 110 00:09:42,083 --> 00:09:46,751 For those in the "know," it is worth mentioning masquerading. 111 00:09:46,751 --> 00:09:51,334 Some examples are IP personality, morph and IP morph. 112 00:09:52,125 --> 00:09:57,083 Because this solution does begin looking at this, but it 113 00:09:57,083 --> 00:10:02,999 is a modification to the stack, the idea is for the host to pretend 114 00:10:02,999 --> 00:10:07,334 to be something else, like a printer. 115 00:10:09,083 --> 00:10:12,584 The way I look at it, it may be a little dangerous, playing 116 00:10:12,584 --> 00:10:14,626 with those values. 117 00:10:14,626 --> 00:10:16,876 I don't want to degrade or break my connection, 118 00:10:16,876 --> 00:10:21,459 and speaking of degrading, we are of course speaking of performance; 119 00:10:21,459 --> 00:10:26,250 that kind of thing doesn't really sit very well with me. 120 00:10:26,250 --> 00:10:30,000 And then of course, it is a "host only" solution. 121 00:10:31,250 --> 00:10:34,999 Through all the research I did prior to submitting my application, 122 00:10:34,999 --> 00:10:38,542 I had not even heard of these solutions, so I am probably not 123 00:10:38,542 --> 00:10:41,667 the only person who sees it this way, as far as seeing 124 00:10:41,667 --> 00:10:46,459 the dangerous aspect and not looking at this as a broader solution. 125 00:10:46,999 --> 00:10:49,209 But it is worth mentioning because people have talked 126 00:10:49,209 --> 00:10:51,626 about this sort of thing before. 127 00:10:53,876 --> 00:10:55,667 How about outgoing normalization? 128 00:10:55,667 --> 00:10:58,417 Have we seen anything like that? 129 00:10:59,000 --> 00:11:00,999 Not really. 130 00:11:00,999 --> 00:11:04,167 Outgoing transit normalization really hasn't been discussed before, 131 00:11:04,167 --> 00:11:07,709 and there certainly isn't anything out there that is talking 132 00:11:07,709 --> 00:11:10,751 about protecting the fingerprinting. 133 00:11:13,918 --> 00:11:17,375 When you look to prevent the fingerprints, it is important 134 00:11:17,375 --> 00:11:20,876 to look at that fingerprinting process. 135 00:11:21,250 --> 00:11:24,999 As nmap is a major theme to the talk, and this is where I 136 00:11:24,999 --> 00:11:29,584 will show you where I began, looking at nmap and its process 137 00:11:29,584 --> 00:11:32,626 for fingerprinting targets. 138 00:11:32,834 --> 00:11:37,417 Nmap will send out TCP and UDC and ICNP probes which have 139 00:11:37,417 --> 00:11:42,834 responses, and nmap will compile the results, the responses 140 00:11:42,834 --> 00:11:45,501 into a fingerprint. 141 00:11:45,501 --> 00:11:49,959 It is composed of response attributes, response categories that are looking 142 00:11:49,959 --> 00:11:54,125 to categorize some responses, as well as recording the structure 143 00:11:54,125 --> 00:11:57,417 into something like you see here. 144 00:11:58,999 --> 00:12:02,083 What it does, it compares this fingerprint 145 00:12:02,083 --> 00:12:05,999 against a database of previously enumerated operating 146 00:12:05,999 --> 00:12:10,999 systems, attempting to identify the target by finding a matching entry 147 00:12:10,999 --> 00:12:13,125 in the database. 148 00:12:13,125 --> 00:12:17,626 It compares the target fingerprint, and how closely it matches, that 149 00:12:17,626 --> 00:12:21,542 is basically where you get the number of 89 or 90 or 150 00:12:21,542 --> 00:12:23,999 a hundred percent. 151 00:12:23,999 --> 00:12:29,375 It doesn't happen very often, but it does happen, and that 152 00:12:29,375 --> 00:12:34,709 is where I started, the nmap database. 153 00:12:35,918 --> 00:12:38,334 There is a lot there. 154 00:12:38,667 --> 00:12:44,250 It is very complex, and ultimately it is too much trouble; I didn't want 155 00:12:44,250 --> 00:12:49,751 to work that hard to unwrap, given that complexity. 156 00:12:50,125 --> 00:12:55,083 Of course there are the other fingerprinting tools that aren't 157 00:12:55,083 --> 00:13:01,876 so famous, X probe II, quite old, NF SNP and Nexus and other scanners. 158 00:13:05,501 --> 00:13:09,459 Looking at these sorts of tools, it really isn't a good idea 159 00:13:09,459 --> 00:13:13,999 to begin chasing after every tool and its techniques. 160 00:13:13,999 --> 00:13:17,834 It is ultimately best to just try to disrupt any existing pattern, 161 00:13:17,834 --> 00:13:22,375 and that is what I look to do with the normalization. 162 00:13:24,626 --> 00:13:28,959 The algorithm I developed to disrupt the pattern does start 163 00:13:28,959 --> 00:13:31,626 off with some scrubbing. 164 00:13:31,751 --> 00:13:35,751 The idea is to leave behind as little as possible for that print; 165 00:13:35,751 --> 00:13:39,125 don't give them an inch, as it were. 166 00:13:40,918 --> 00:13:46,584 You clear those necessary values out, like the IP type service, IP ECN, 167 00:13:46,584 --> 00:13:50,125 to see the urge flag and pointer. 168 00:13:50,209 --> 00:13:54,083 The nice thing about doing this, nmap uses reflection probes 169 00:13:54,083 --> 00:14:00,375 to inject values into the probe, looking for those values to be returned. 170 00:14:00,709 --> 00:14:03,999 This is a somewhat unusual and often obscure operating system 171 00:14:03,999 --> 00:14:05,999 that will mirror values, receiving 172 00:14:05,999 --> 00:14:10,209 a packet and mirroring back the value in the response. 173 00:14:10,542 --> 00:14:13,125 An nmap is able to identify some operating system just 174 00:14:13,125 --> 00:14:15,709 from that, clearing it out and taking care 175 00:14:15,709 --> 00:14:18,083 of that reflection probe. 176 00:14:18,250 --> 00:14:21,834 Next, you want to randomize anything you can, 177 00:14:21,834 --> 00:14:27,999 like the IP ID, because nmap and tools like it do algorithm analysis. 178 00:14:32,876 --> 00:14:36,459 We didn't want to try to allow them to reverse engineer 179 00:14:36,459 --> 00:14:40,125 with an algorithm previously enumerated, so this left me 180 00:14:40,125 --> 00:14:43,999 with the IP time to live and TCP options. 181 00:14:44,417 --> 00:14:49,417 In this case, scrubbing or clearing out or randomizing wouldn't work, 182 00:14:49,417 --> 00:14:52,999 so a new technique would be needed. 183 00:14:52,999 --> 00:14:57,999 This is where I apply the normalization, and this is what I came 184 00:14:57,999 --> 00:15:03,542 up with: Outgoing normalization and true packet normalization 185 00:15:03,542 --> 00:15:05,876 to the rescue! 186 00:15:07,501 --> 00:15:10,083 The algorithm to normalize the IP time 187 00:15:10,083 --> 00:15:14,709 to live makes some assumptions that the starting TPC was originally 188 00:15:14,709 --> 00:15:18,709 a well known value, and you can look it up on the Internet; 189 00:15:18,709 --> 00:15:20,834 there is a list. 190 00:15:21,584 --> 00:15:27,083 As the bracket traversed the network, it would be decremented only, and 191 00:15:27,083 --> 00:15:32,501 the packet would travel less than 32 hops, and these assumptions are 192 00:15:32,501 --> 00:15:36,999 reasonable, given the expectations out there. 193 00:15:36,999 --> 00:15:39,083 It's true for 99% of the packets out there, so it turns 194 00:15:39,083 --> 00:15:42,083 out they're pretty sound assumptions. 195 00:15:43,292 --> 00:15:47,334 Now with the algorithm, it takes the current TTL and backs into one 196 00:15:47,334 --> 00:15:50,292 of those well known values to estimate the number 197 00:15:50,292 --> 00:15:52,334 of hops traveled. 198 00:15:52,417 --> 00:15:55,918 It then recalibrates the current TTC by taking 199 00:15:55,918 --> 00:16:01,751 a new standardized starting TTL of 255, subtracting the hops, to come 200 00:16:01,751 --> 00:16:07,918 up with a recalibrated standardized version of the calculation to arrive 201 00:16:07,918 --> 00:16:12,375 with a brand new recalibrated current TTL. 202 00:16:12,375 --> 00:16:15,918 Then it puts that in the packet, which is the process, the overall flow 203 00:16:15,918 --> 00:16:18,334 of the algorithm's steps. 204 00:16:18,334 --> 00:16:21,999 This is a more logical view. 205 00:16:22,459 --> 00:16:26,083 The algorithm starts with the lowest well known TTL, 206 00:16:26,083 --> 00:16:31,167 first making sure the most likely TTL gets selected first. 207 00:16:31,250 --> 00:16:36,167 Then it moves to the next and the next one, and assumes 208 00:16:36,167 --> 00:16:41,083 at the bottom that it's already close to 55. 209 00:16:43,876 --> 00:16:47,292 There are actually several exceptions to this normalization to keep 210 00:16:47,292 --> 00:16:49,083 a number of layer three mechanisms 211 00:16:49,083 --> 00:16:52,959 from breaking, which we will talk about momentarily. 212 00:16:53,999 --> 00:16:57,584 Then there is the algorithm to normalize the TCP options. 213 00:16:57,584 --> 00:17:00,999 It also starts with some assumptions. 214 00:17:00,999 --> 00:17:03,751 There are only a few well known options that 215 00:17:03,751 --> 00:17:05,375 are needed. 216 00:17:05,501 --> 00:17:07,999 Ultimately, order was not important. 217 00:17:08,375 --> 00:17:12,542 The requirement I imposed was that the values not be changed; 218 00:17:12,542 --> 00:17:17,918 I did not want to degrade or even possibly disrupt that socket. 219 00:17:18,250 --> 00:17:20,999 The algorithm, with those assumptions and operating 220 00:17:20,999 --> 00:17:24,542 under that requirement, it reads the necessary options 221 00:17:24,542 --> 00:17:26,999 and discards the rest. 222 00:17:27,709 --> 00:17:31,667 It rewrites the options in the proper order or the order I select, 223 00:17:31,667 --> 00:17:34,083 and then it fills out the remaining space 224 00:17:34,083 --> 00:17:36,959 with NOPs hitting the right 32 bit boundaries, 225 00:17:36,959 --> 00:17:40,999 so checks can be calculated without further problems. 226 00:17:47,334 --> 00:17:54,083 These are the options and their order: Maximum segment size, window scale, 227 00:17:54,083 --> 00:17:58,667 selective AK and MD5 past and present. 228 00:17:58,834 --> 00:18:04,999 So after processing, an options list would look like this. 229 00:18:08,959 --> 00:18:11,292 So that's pretty simple. 230 00:18:11,876 --> 00:18:15,876 It is really nice on paper, but it's even better when put 231 00:18:15,876 --> 00:18:20,999 into action, putting it all together and making all packets look 232 00:18:20,999 --> 00:18:25,250 the same with the proof of concept idguard. 233 00:18:26,999 --> 00:18:31,834 To put this on hardware, I wanted to select a suitable platform, 234 00:18:31,834 --> 00:18:34,083 suitable hardware. 235 00:18:34,083 --> 00:18:38,999 The first thing I wanted to be sure of was that it was already modified 236 00:18:38,999 --> 00:18:41,999 by others, as I didn't want to reinvent 237 00:18:41,999 --> 00:18:46,959 the wheel so that I can spend normalization time. 238 00:18:46,959 --> 00:18:49,167 I wanted plenty of documentation available. 239 00:18:49,167 --> 00:18:51,999 So for the hardware, I used router boards, 240 00:18:51,999 --> 00:18:56,083 specifically this one, as well as identifying 241 00:18:56,083 --> 00:19:01,417 a suitable operating system with an available space to put 242 00:19:01,417 --> 00:19:06,999 into VM to spend time developing proof of concept. 243 00:19:07,375 --> 00:19:11,083 I also wanted to make sure that it had a rival 244 00:19:11,083 --> 00:19:17,083 or editable filing system so that I could make quick changes. 245 00:19:17,292 --> 00:19:20,083 For the OS, I pick Open WRT. 246 00:19:22,667 --> 00:19:27,334 This is a very, very, very abbreviated list 247 00:19:27,334 --> 00:19:30,876 of the steps involved. 248 00:19:30,999 --> 00:19:33,417 I started out with the Open WRT site. 249 00:19:33,876 --> 00:19:37,250 There is page after page of instructions. 250 00:19:37,250 --> 00:19:38,959 A lot of it is not specific. 251 00:19:38,999 --> 00:19:42,083 There are things missing, as well as errors. 252 00:19:42,626 --> 00:19:45,999 From this, I condensed it into a clear and concise set 253 00:19:45,999 --> 00:19:48,083 of instructions. 254 00:19:52,292 --> 00:19:55,999 I will be posting this on the project site after the talk, 255 00:19:55,999 --> 00:19:58,167 so that way, you can avoid my pain 256 00:19:58,167 --> 00:20:01,542 from putting this together yourself. 257 00:20:02,876 --> 00:20:04,417 So that will be up there. 258 00:20:09,334 --> 00:20:11,667 Now putting it on the hardware. 259 00:20:11,667 --> 00:20:12,667 What worked? 260 00:20:12,999 --> 00:20:16,999 I know we are getting tired of those nosey bastards. 261 00:20:20,918 --> 00:20:24,667 We will start with what didn't work so well 262 00:20:24,667 --> 00:20:30,959 by itself: Type of service, clearing, ECN clearing, urge flag or point 263 00:20:30,959 --> 00:20:36,667 of clearing, IPI randomization not due to fragment flag clearing, 264 00:20:36,667 --> 00:20:39,125 and the scrubbing. 265 00:20:39,918 --> 00:20:43,876 I say it didn't work so well alone, but what really did help 266 00:20:43,876 --> 00:20:48,167 out and which made the rest of the algorithm possible that would be 267 00:20:48,167 --> 00:20:51,999 the IP ID randomization, doing a good job of contributing 268 00:20:51,999 --> 00:20:56,125 to the algorithm and putting it together nicely. 269 00:20:56,417 --> 00:21:00,501 The others I may ultimately remove because of the possibility even 270 00:21:00,501 --> 00:21:03,999 a remote possibility that the socket could be disrupted, 271 00:21:03,999 --> 00:21:08,709 especially on an internal network with that type of service. 272 00:21:08,709 --> 00:21:12,999 So I may end up removing them, but for now they are there. 273 00:21:13,083 --> 00:21:16,751 So what do the IP ID randomizations help, 274 00:21:16,751 --> 00:21:19,999 the synergy of what worked? 275 00:21:20,999 --> 00:21:25,167 The time to live standardizing and TCP option standardizing, 276 00:21:25,167 --> 00:21:27,542 the normalization. 277 00:21:30,167 --> 00:21:32,834 I can talk about this all day and just say it 278 00:21:32,834 --> 00:21:37,125 is really wonderful, but it is better to show you the results. 279 00:21:37,125 --> 00:21:38,959 We will start here, and then show you a demo 280 00:21:38,959 --> 00:21:40,834 in a few minutes. 281 00:21:41,083 --> 00:21:44,083 Windows 7 target, unprotected. 282 00:21:44,542 --> 00:21:48,334 Wow, surprise, a Windows 7 host. 283 00:21:48,918 --> 00:21:53,375 A Windows server 2003 target, unprotected, looks 284 00:21:53,375 --> 00:21:56,999 like a Windows 2003 host. 285 00:21:57,417 --> 00:21:59,999 And then an Abuntu desktop, not protected, looks likes 286 00:21:59,999 --> 00:22:01,918 a Lennox host. 287 00:22:05,999 --> 00:22:11,876 And then a Red Hat Enterprise target, unprotected, looks 288 00:22:11,876 --> 00:22:18,083 like a Lennox host running the 2.6.X or 3.X kernel. 289 00:22:19,751 --> 00:22:22,834 It does a pretty good job of identifying these and what they are, 290 00:22:22,834 --> 00:22:25,250 so I shouldn't say "unprotected." 291 00:22:25,417 --> 00:22:30,459 Now Windows 7 protected by ID Guard. 292 00:22:31,501 --> 00:22:35,083 Looks like an Allied Telesyn router. 293 00:22:37,876 --> 00:22:47,250 Windows 2003 server protected by idguard, looks like the same router. 294 00:22:48,999 --> 00:22:55,999 This desktop looks like a Cisco router running IOS 12.6; 295 00:22:55,999 --> 00:22:58,417 not so bad. 296 00:22:58,501 --> 00:23:04,459 And Red Hat Enterprise target protected by idguard. 297 00:23:04,459 --> 00:23:07,959 Looks like a device running in an embedded D link. 298 00:23:09,459 --> 00:23:14,083 Yes, they are looking all the same, like routers. 299 00:23:14,292 --> 00:23:18,999 Not so bad unless you are that router, and then I guess it's not so great. 300 00:23:23,834 --> 00:23:30,751 In addition to those fantastic results, there are some other effects. 301 00:23:30,959 --> 00:23:33,999 Nmap does report a negative distance number, 302 00:23:33,999 --> 00:23:38,834 a little strange, but ultimately completely harmless. 303 00:23:39,083 --> 00:23:43,792 How about those other printing tools? 304 00:23:43,918 --> 00:23:45,918 X probe, grandpa there. 305 00:23:46,125 --> 00:23:47,999 Syn FP. 306 00:23:47,999 --> 00:23:53,999 Turns out for Nessus, at least on the operating system identification 307 00:23:53,999 --> 00:23:58,999 for the network and transport layer, those mechanisms are 308 00:23:58,999 --> 00:24:01,542 equally confused. 309 00:24:01,542 --> 00:24:08,083 They see either nothing at all, or they have a completely wildly off view. 310 00:24:09,501 --> 00:24:12,751 Then, of course, the other tools we use to monitor 311 00:24:12,751 --> 00:24:16,083 and troubleshoot, the network like ping and tray shot, 312 00:24:16,083 --> 00:24:19,501 two good examples which are able to operate normally 313 00:24:19,501 --> 00:24:22,250 with no problems whatsoever. 314 00:24:22,999 --> 00:24:27,417 I did talk about the demonstration, so here we go. 315 00:24:28,792 --> 00:24:32,167 It is always good to show you. 316 00:24:38,999 --> 00:24:44,083 I am going to first make sure idguard is not running, so that you get 317 00:24:44,083 --> 00:24:49,167 a good look at what these things look like without it. 318 00:24:50,417 --> 00:24:52,501 Nothing is "fixed" here. 319 00:24:59,125 --> 00:25:00,542 There we go. 320 00:25:00,584 --> 00:25:02,876 It will scan. 321 00:25:02,876 --> 00:25:04,334 It's just taking a few seconds. 322 00:25:05,834 --> 00:25:10,501 It takes a varying amount of time. 323 00:25:11,501 --> 00:25:16,626 I have the scanning machine here, router here. 324 00:25:18,999 --> 00:25:23,417 Over here is the targets. 325 00:25:23,417 --> 00:25:25,999 This is taking an unusually long amount of time. 326 00:25:27,751 --> 00:25:30,083 Over here we have the targets. 327 00:25:30,083 --> 00:25:31,209 Four VMs are running. 328 00:25:34,459 --> 00:25:37,918 For some reason, it is a little slow. 329 00:25:37,918 --> 00:25:39,834 Keep in mind, this is without idguard. 330 00:25:39,834 --> 00:25:48,918 So whatever is going on, it is on its own. 331 00:25:48,918 --> 00:25:49,999 I have some time to fill. 332 00:25:50,709 --> 00:25:55,250 So this is performing the normal activity, and I put 333 00:25:55,250 --> 00:26:00,167 a "dash O" but you can do a "dash A" but you can see it 334 00:26:00,167 --> 00:26:05,876 is sometimes a little squirrely, so no use putting more things 335 00:26:05,876 --> 00:26:08,959 in the way to go wrong. 336 00:26:16,167 --> 00:26:21,125 The first target is identified as Lennox host running 2.6.X 337 00:26:21,125 --> 00:26:23,334 or 3.X kernel. 338 00:26:23,834 --> 00:26:30,834 It looks like it far felled the second one. 339 00:26:30,918 --> 00:26:33,292 It was looking like it was having problems. 340 00:26:37,667 --> 00:26:44,751 The third target is a Microsoft Windows 2003 host. 341 00:26:46,083 --> 00:26:50,459 Sounds like disco music over there; it's a party. 342 00:26:51,375 --> 00:26:57,501 So the fourth target is identified as Lennox host running this kernel, 343 00:26:57,501 --> 00:27:02,375 so what we expected, accurate identification. 344 00:27:02,375 --> 00:27:03,375 All right. 345 00:27:03,375 --> 00:27:04,375 There we go. 346 00:27:17,083 --> 00:27:23,999 I will run it again. 347 00:27:23,999 --> 00:27:28,584 Hopefully it won't be as squirrely as it was a moment ago. 348 00:27:30,542 --> 00:27:35,417 Running this, the performance is fine. 349 00:27:35,417 --> 00:27:37,667 It runs the exact same speed. 350 00:27:37,709 --> 00:27:41,292 That is what it was supposed to look like the first time. 351 00:27:42,999 --> 00:27:47,083 When you run the scan with idguard in place, the time is the same, 352 00:27:47,083 --> 00:27:50,459 no degradation of network performance. 353 00:27:53,959 --> 00:27:59,375 The first target looks likes Tran Map; looks like the device is running 354 00:27:59,375 --> 00:28:02,083 in an embedded D link. 355 00:28:03,209 --> 00:28:09,542 The second target looks like an Allied Telesyn router 356 00:28:09,542 --> 00:28:18,083 and I had never heard of these people until I actually did this. 357 00:28:19,999 --> 00:28:23,209 The third target looks like the same router; fantastic. 358 00:28:28,959 --> 00:28:31,999 And the fourth target, to nmap it looks 359 00:28:31,999 --> 00:28:36,626 like a Cisco router running IOS 12.X; fantastic. 360 00:28:45,417 --> 00:28:46,876 (Applause) Thank you. 361 00:28:46,876 --> 00:28:51,834 I hope the network continues to operate as it is supposed to. 362 00:28:51,834 --> 00:28:56,792 It is going around a tracer route. 363 00:28:56,792 --> 00:28:57,792 There we go. 364 00:28:57,792 --> 00:28:58,999 It functions normally. 365 00:28:58,999 --> 00:29:03,083 We want to make sure that not only the network is running as it should 366 00:29:03,083 --> 00:29:06,999 with idguard in place, but the hosts are also functioning 367 00:29:06,999 --> 00:29:11,209 normal and are able to carry out the given tasks. 368 00:29:22,250 --> 00:29:27,999 As we saw earlier, SSH works fine, not interrupted in any way. 369 00:29:28,709 --> 00:29:32,918 Then we have a web server running over there. 370 00:29:37,999 --> 00:29:41,999 We want to make sure the web server is available, that we can browse 371 00:29:41,999 --> 00:29:43,876 to the website. 372 00:29:47,876 --> 00:29:50,999 There are four VMs running over there. 373 00:29:50,999 --> 00:29:57,459 And then, of course, it is IIS so there is a little delay. 374 00:29:57,459 --> 00:30:05,209 So the network is working great, and I think I might have the time 375 00:30:05,209 --> 00:30:12,375 to run Sen FP real quick on one of the targets. 376 00:30:15,459 --> 00:30:17,959 Has anyone here used Sen FP before? 377 00:30:26,999 --> 00:30:30,667 I threw it in there because it is more recent than 378 00:30:30,667 --> 00:30:34,751 like two years ago when they had an update. 379 00:30:35,250 --> 00:30:37,999 It isn't quite as old as X probe. 380 00:30:45,999 --> 00:30:49,959 So we saw some fantastic results. 381 00:30:50,999 --> 00:30:54,292 There are some challenges like authorized activity, 382 00:30:54,292 --> 00:30:58,626 and other identification like banner and query and identification 383 00:30:58,626 --> 00:31:00,667 through Layer 7. 384 00:31:01,834 --> 00:31:05,167 The first challenge, authorized activity. 385 00:31:05,334 --> 00:31:07,999 Scanners manage their platforms. 386 00:31:07,999 --> 00:31:11,626 Idguard excludes the resolution to that challenge. 387 00:31:12,876 --> 00:31:16,876 You can load it with an exclusion to allow that sort 388 00:31:16,876 --> 00:31:21,083 of authorized activity to occur unhindered. 389 00:31:22,083 --> 00:31:26,125 By loading idguard with the exclusion, it tells idguard 390 00:31:26,125 --> 00:31:31,083 to basically leave alone the traffic and perform no transformations 391 00:31:31,083 --> 00:31:35,542 on that traffic, so the challenge is overcome. 392 00:31:36,999 --> 00:31:40,542 The second challenge, banners and direct query. 393 00:31:40,542 --> 00:31:41,999 There is network available. 394 00:31:43,709 --> 00:31:50,083 Application layer query and OS detail are returned in the reply. 395 00:31:50,209 --> 00:31:53,167 The resolution is split into two parts. 396 00:31:53,209 --> 00:31:56,292 On the perimeter network, those protocols are generally not 397 00:31:56,292 --> 00:31:58,876 available, should not be, just leaving us 398 00:31:58,876 --> 00:32:01,334 with the internal network. 399 00:32:02,417 --> 00:32:06,918 Those application layer queries and replies will have 400 00:32:06,918 --> 00:32:12,999 to be normalized as well, in order to provide an additional fingerprinting 401 00:32:12,999 --> 00:32:15,876 prevention capability. 402 00:32:16,876 --> 00:32:22,999 So a challenge that is existing now and ultimately it won't be, 403 00:32:22,999 --> 00:32:28,999 but there are also some concerns with upstream and downstream 404 00:32:28,999 --> 00:32:34,999 fragmentation or what I am calling TTL attenuation. 405 00:32:34,999 --> 00:32:38,999 That may not be not very accurately described, but you will understand. 406 00:32:39,375 --> 00:32:41,751 TTL special uses. 407 00:32:41,751 --> 00:32:44,999 As we saw before, the trace route and TCP option sensitivity, 408 00:32:44,999 --> 00:32:47,876 and then how about link loading protocols, 409 00:32:47,876 --> 00:32:49,918 especially RIP. 410 00:32:50,417 --> 00:32:52,959 First, upstream fragmentation. 411 00:32:53,167 --> 00:32:59,334 The IP ID is randomized at some point, at work traversing the network. 412 00:33:01,626 --> 00:33:03,999 Idguard randomized the ID. 413 00:33:04,501 --> 00:33:06,999 Another router sees it, can't fragment. 414 00:33:06,999 --> 00:33:09,999 It sends a message back to the host, which is confused 415 00:33:09,999 --> 00:33:14,876 because it never sent a bracket with the IP ID; it keeps sending 416 00:33:14,876 --> 00:33:17,250 the original packet. 417 00:33:20,959 --> 00:33:24,999 The resolution, idguard clears the fragment field, 418 00:33:24,999 --> 00:33:28,501 which breaks MTU path discovery. 419 00:33:28,626 --> 00:33:33,167 I haven't so far had a problem with that, but you may. 420 00:33:33,167 --> 00:33:36,459 That is something I will continue to look into. 421 00:33:36,876 --> 00:33:41,083 If you run into this problem, you can all add an exclusion 422 00:33:41,083 --> 00:33:45,834 for that particular host, so problem solved. 423 00:33:47,792 --> 00:33:52,792 Then there is the second concern of downstream fragmentation. 424 00:33:52,834 --> 00:33:56,999 Each fragment is given a different IP ID. 425 00:33:56,999 --> 00:33:58,999 Therefore, the destination can't reassemble 426 00:33:58,999 --> 00:34:00,709 the original. 427 00:34:00,834 --> 00:34:04,999 The resolution, access switch placement, go ahead 428 00:34:04,999 --> 00:34:11,083 and have the IP ID randomize before the packet might encounter 429 00:34:11,083 --> 00:34:15,792 a router that would need to fragment. 430 00:34:16,834 --> 00:34:19,626 And then of course, Idguard excludes fragments, 431 00:34:19,626 --> 00:34:21,375 just in case. 432 00:34:21,834 --> 00:34:24,667 The host actually does the fragmentation. 433 00:34:24,667 --> 00:34:27,999 So both those together mean the problem is solved. 434 00:34:30,125 --> 00:34:35,999 Then what I call TTL attenuation, when a packet travels 435 00:34:35,999 --> 00:34:41,999 more than 32 hops which aren't all accounted for, so TTL 436 00:34:41,999 --> 00:34:45,667 is continually extended. 437 00:34:47,375 --> 00:34:55,083 It got 66 hops and recalibrated with 2, so it would have more available hops 438 00:34:55,083 --> 00:34:57,999 before expiration. 439 00:34:59,250 --> 00:35:02,125 If it happens again, routing may occur. 440 00:35:02,375 --> 00:35:05,417 The resolution is access switch placement so that 441 00:35:05,417 --> 00:35:09,999 the change to the TTL occurs before any routing activity begins, 442 00:35:09,999 --> 00:35:13,876 and then after when it is already at the destination 443 00:35:13,876 --> 00:35:16,375 and no longer matters. 444 00:35:17,584 --> 00:35:19,375 So problem solved. 445 00:35:21,125 --> 00:35:25,334 Then there is the concern of TTL special uses. 446 00:35:25,334 --> 00:35:26,918 The TTL is recalibrated. 447 00:35:26,999 --> 00:35:30,999 1 becomes 254, and 2 becomes 253. 448 00:35:30,999 --> 00:35:34,626 The TTL time to live never runs out. 449 00:35:34,999 --> 00:35:38,709 Therefore, no intermediate hop reports; trail fails. 450 00:35:38,999 --> 00:35:44,999 Resolution idguard excludes echo request from the TTL transformation, 451 00:35:44,999 --> 00:35:49,792 and then idguard excludes the DUDB trace route range 452 00:35:49,792 --> 00:35:53,375 from all TTL transformations. 453 00:35:53,626 --> 00:35:57,999 Problem solved. 454 00:35:57,999 --> 00:36:00,083 Then link local writing protocols. 455 00:36:00,083 --> 00:36:02,876 The packet has a TTL of 1. 456 00:36:02,999 --> 00:36:08,417 TTL of 255 is abnormal; bracket is malformed. 457 00:36:08,999 --> 00:36:12,959 Resolution, idguard excludes write in protocols. 458 00:36:16,417 --> 00:36:21,999 This concern which always lingers, issues with performance that it might 459 00:36:21,999 --> 00:36:26,083 break something, point of code application and who knows 460 00:36:26,083 --> 00:36:27,999 what else. 461 00:36:28,959 --> 00:36:32,999 It is a concern, but at some point in time we have to begin 462 00:36:32,999 --> 00:36:37,292 to hold our developers and vendors accountable. 463 00:36:37,292 --> 00:36:40,334 So while it is a concern, for the most part my idea 464 00:36:40,334 --> 00:36:45,542 is maybe we should begin getting them to fix these things and not continue 465 00:36:45,542 --> 00:36:48,999 to propagate poorly coded software. 466 00:36:48,999 --> 00:36:55,083 So it is there, we need to be aware of it, but I'm not as worried about it myself. 467 00:36:55,125 --> 00:36:58,250 That is what testing is for. 468 00:37:01,501 --> 00:37:04,959 So we have some concerns and challenges. 469 00:37:04,959 --> 00:37:07,417 For the most part, so far it's really not a big deal. 470 00:37:07,999 --> 00:37:09,999 So what are the benefits for putting this in place 471 00:37:09,999 --> 00:37:11,667 on our network? 472 00:37:11,999 --> 00:37:14,834 It shields the network from casual attackers. 473 00:37:15,083 --> 00:37:19,709 The script KD, they have a new exploit. 474 00:37:19,709 --> 00:37:23,083 They are aware of a weakened configuration. 475 00:37:23,209 --> 00:37:26,250 They will go looking for that particular host. 476 00:37:26,250 --> 00:37:31,083 These hosts are generally popular, ultimately common, and 477 00:37:31,083 --> 00:37:35,876 they won't find those sorts of targets. 478 00:37:35,876 --> 00:37:38,918 They will move on and look for something that matches what 479 00:37:38,918 --> 00:37:41,999 they are looking to attack, automated assaults 480 00:37:41,999 --> 00:37:45,501 with classification going on, scanning and looking 481 00:37:45,501 --> 00:37:49,999 for those targets that match an exploit they have. 482 00:37:49,999 --> 00:37:52,292 So they categorize it, the matching exploit. 483 00:37:52,999 --> 00:37:56,999 The targets will be less likely to fall under one of these categories, 484 00:37:56,999 --> 00:38:01,209 so the software on the server, this BO, it really won't believe it has anything 485 00:38:01,209 --> 00:38:04,959 to launch against this target; it will move on. 486 00:38:04,959 --> 00:38:06,792 And then oblique threats. 487 00:38:06,792 --> 00:38:09,584 If somebody makes a toe hold, they won't have the target 488 00:38:09,584 --> 00:38:12,792 they made for the preferable next step of where 489 00:38:12,792 --> 00:38:16,292 they like to go when moving laterally. 490 00:38:16,334 --> 00:38:21,626 So it does a good shielding job for the network from these threats, 491 00:38:21,626 --> 00:38:26,083 and it helps protect unmanaged and unpatched devices, 492 00:38:26,083 --> 00:38:30,918 because as it moves beyond these targets, the fact that 493 00:38:30,918 --> 00:38:35,083 the target is unmanaged, unpatched and unhardened, 494 00:38:35,083 --> 00:38:38,542 it becomes less of an issue. 495 00:38:39,209 --> 00:38:42,167 Also, helping to defeat canned exploits. 496 00:38:42,167 --> 00:38:47,083 If there is an identification, it makes it much more difficult. 497 00:38:48,834 --> 00:38:52,542 If they know it is Windows, without the exact version 498 00:38:52,542 --> 00:38:57,751 and service pack, they will have to launch the exploit can. 499 00:38:57,999 --> 00:39:01,999 Exploits, to be most effective, need that context. 500 00:39:01,999 --> 00:39:03,792 Without that context, it will lower their chances 501 00:39:03,792 --> 00:39:05,709 of overall success. 502 00:39:07,999 --> 00:39:10,999 So fantastic results, great benefits network wide. 503 00:39:12,083 --> 00:39:15,083 So what is next, now that we have the solution to getting this 504 00:39:15,083 --> 00:39:16,999 out there in place? 505 00:39:17,209 --> 00:39:22,125 First, more platforms, open source router firmware DD WRT, 506 00:39:22,125 --> 00:39:27,542 and then switches where it ultimately belongs. 507 00:39:27,667 --> 00:39:30,125 There are some native Lennox switches. 508 00:39:30,125 --> 00:39:33,542 Matrotek has one, and I believe Aureus is the name. 509 00:39:33,542 --> 00:39:35,834 There are Lennox versions of extreme switches, 510 00:39:35,834 --> 00:39:39,209 and Cisco switches in particular, to try to get some sort 511 00:39:39,209 --> 00:39:43,999 of modification there, and of course they require permission. 512 00:39:47,417 --> 00:39:50,542 We want to take these switches and put them in some sort of trial 513 00:39:50,542 --> 00:39:53,542 out there, starting in a test environment. 514 00:39:54,417 --> 00:39:57,959 Is anyone interested in running a trial? 515 00:39:57,959 --> 00:39:59,876 If you are, contact me after the talk. 516 00:40:00,209 --> 00:40:04,542 From there, with those switches in place, talking to the vendors, 517 00:40:04,542 --> 00:40:08,751 because I want to get it out there as a feature on the switches, 518 00:40:08,751 --> 00:40:11,542 like IGMP and DHCP snooping. 519 00:40:11,542 --> 00:40:14,751 I think it would add benefit to that access switch post. 520 00:40:15,042 --> 00:40:19,542 So if you are a vendor, I would like to speak with you 521 00:40:19,542 --> 00:40:23,999 after the presentation to begin that path. 522 00:40:31,292 --> 00:40:33,999 This is a summary. 523 00:40:34,375 --> 00:40:38,876 Accurate target identification is key to a successful attack, 524 00:40:38,876 --> 00:40:43,584 identification that is way too easy to perform. 525 00:40:43,584 --> 00:40:46,751 So let's change that with fingerprint prevention. 526 00:40:46,751 --> 00:40:48,709 I have proven it can be done. 527 00:40:48,999 --> 00:40:50,667 Now we just need to make it happen. 528 00:40:51,667 --> 00:40:55,292 Proof of concept will be available this afternoon. 529 00:40:55,375 --> 00:40:57,209 There is Version .5. 530 00:40:57,209 --> 00:40:58,250 It is a POC. 531 00:40:59,167 --> 00:41:03,334 It has the IPV for support right now. 532 00:41:03,876 --> 00:41:06,626 Version .6 will be out in about a month. 533 00:41:06,626 --> 00:41:10,959 I am still working out some kinks with the IV6 support. 534 00:41:11,250 --> 00:41:16,459 And application layer queries, they will be dealt with. 535 00:41:16,459 --> 00:41:20,083 There will be a version right after that to handle that. 536 00:41:20,125 --> 00:41:22,209 There is the hash. 537 00:41:22,250 --> 00:41:26,876 I tried 256, but it was too big. 538 00:41:28,292 --> 00:41:32,209 That is where the POC will be available momentarily. 539 00:41:32,334 --> 00:41:35,999 It will be sourced, and I am giving this one away, 540 00:41:35,999 --> 00:41:40,083 so I have to make myself a new router. 541 00:41:40,292 --> 00:41:43,792 It will be a perfect opportunity to test the package, so that will be 542 00:41:43,792 --> 00:41:45,501 up there too. 543 00:41:46,501 --> 00:41:52,083 And here are some links to provide some context to today's talk. 544 00:41:53,167 --> 00:41:56,959 Should I back up for the hash? 545 00:42:01,334 --> 00:42:12,167 Are we good? 546 00:42:12,709 --> 00:42:20,999 And this is the special time of the talk, special thanks to a couple people. 547 00:42:21,250 --> 00:42:26,999 This person helped me work out the many problems in the abstract, 548 00:42:26,999 --> 00:42:31,834 as well as Kenny, Kevin, Kathy and Nick. 549 00:42:32,417 --> 00:42:36,125 This is the last one which will conclude my talk, but I want 550 00:42:36,125 --> 00:42:39,834 to make sure I have everyone's attention. 551 00:42:41,125 --> 00:42:45,999 I promised Nick Pruitt I would get him face on a slide at DEF CON. 552 00:42:50,959 --> 00:42:54,334 Here he is in all his glory. 553 00:42:54,918 --> 00:42:56,834 He sent me many pictures. 554 00:42:56,834 --> 00:42:58,417 This is the one I wanted to use. 555 00:42:58,417 --> 00:43:01,459 This is probably how he would prefer to be remembered. 556 00:43:03,999 --> 00:43:10,459 In fact, there he is, just so that he is properly embarrassed. 557 00:43:12,083 --> 00:43:13,501 So that's it. 558 00:43:13,501 --> 00:43:14,501 Thank you.