WEBVTT 00:07.240 --> 00:09.530 Sorry about the slight delay. 00:12.370 --> 00:18.150 My name is Ophir Arkin, and during this talk, I will be releasing XProbe 2.0.3. 00:19.510 --> 00:24.720 Prior to that, I will be talking about several aspects of doing active voice fingerprinting. 00:25.590 --> 00:36.090 Basically, we're going to discuss the problems that are usually associated with active voice fingerprinting, and we'll see how we can remedy that. 00:36.490 --> 00:46.190 A bit about myself, I'm the founder of the C-Security Group, also founder of NCITEC, I'm the Chief Technical Officer there. 00:46.930 --> 00:57.810 I've done some research about infrastructure discovery, voice over IP security, and OS detection, and I'm also a member of the Voice Over IP Security Alliance. 00:58.850 --> 01:00.770 So, what is OS detection? 01:00.770 --> 01:10.930 OS detection is basically the process of trying to determine what is the underlying operating system of a certain remote element. 01:11.370 --> 01:26.070 Traditional approach will send some packets, will examine the stack behavior, usually with IP, UDP, TCP, and ICP, in order to draw some conclusions about that underlying OS. 01:26.070 --> 01:40.570 Usually, when results are received from a target element, those results will be compared to a certain signature database, a certain tool will have, in an effort to find a match. 01:41.930 --> 01:57.230 Just because the traditional approach is to use TCP IP stack-based fingerprinting, usually limited to those protocols I've mentioned, doesn't mean that we cannot use the application layer also to provide us with information about the OS. 02:00.670 --> 02:06.270 There are several tools out there that does active OS fingerprinting. 02:07.130 --> 02:11.270 Nmap, for example, is a good tool doing that, Xpub2 and others. 02:11.270 --> 02:19.410 Basically, these tools vary with the way of operation, usually because of the different tests they are using. 02:19.410 --> 02:29.030 Basically, the packets they are sending to the target host, trying to enumerate the operating system, the number of packets they are sending, and the way of operation. 02:32.030 --> 02:36.710 Why is that important for us, to identify the underlying operating system? 02:36.710 --> 02:41.510 Well, I guess that for each and one of us, it's something different. 02:43.330 --> 03:00.890 Some need that to do vulnerability assessment, some like to have some context about their network, and there are some companies who use OS detection as a means to have some context for their network intrusion detection systems and network intrusion prevention systems. 03:01.870 --> 03:14.690 If we go and look at the strength of doing remote active OS fingerprinting, then one of the things that is the most important is that we can control everything. 03:14.710 --> 03:18.110 We can control what parameters that we would like to scan. 03:18.110 --> 03:25.870 We can control the speed that we perform the scan, the initiation of the scan, the time of the initiation. 03:27.350 --> 03:36.570 Usually such a tool will provide with fast results if there are no obstacles on the way, and then of course it can also cover entire IP ranges. 03:38.150 --> 03:40.610 Several companies use these kind of tools. 03:40.710 --> 03:45.050 They might scan from one single point to a multipoint. 03:45.050 --> 03:49.590 This is where the tool is installed on one element on the network and scans multiple. 03:49.590 --> 04:01.650 And there are some other implementations where a scanning tool will be installed on different parts of the network and will scan from there other parts of the network. 04:02.750 --> 04:03.950 That's basically it. 04:03.950 --> 04:05.330 These are all the strengths. 04:05.330 --> 04:06.750 There are a lot of weaknesses. 04:08.330 --> 04:12.190 The weaknesses go into different categories. 04:13.190 --> 04:29.690 The biggest problem is the scanning conditions and the environment effects on the scan, the way that the OS detection tool operates, the signature database is not a major caveat, and also some other tool-related issues. 04:30.470 --> 04:35.110 So let's start by looking at the scanning conditions and the environment effect. 04:38.390 --> 04:49.030 Basically, when we perform an OS detection or basically any other scan, we do not control the quality of the scan. 04:49.030 --> 04:51.590 We cannot control over anything, basically. 04:51.930 --> 04:57.590 Whatever is between us to the target may determine what we're going to get back. 04:57.910 --> 05:00.490 So probably most of you know this. 05:00.490 --> 05:04.650 If you scan an element on a local network, this is one thing. 05:04.650 --> 05:08.890 If you scan an element that is on the Internet, that is something else. 05:09.690 --> 05:15.690 And basically, those locations of the target systems will determine what you're getting. 05:15.690 --> 05:21.990 It's most likely that when you scan an element that is on your local network, you'll get better results. 05:21.990 --> 05:26.550 When you scan an element that is on the Internet, you'll get, well, sometimes nothing. 05:26.550 --> 05:34.510 And also the path between the scanning element to the target also determines what we will be getting. 05:34.990 --> 05:46.130 The problem currently is that we do not have any kind of intelligence about what do we have between us to the target. 05:46.130 --> 06:01.750 There is currently no tool that is going to tell us, or something else that prevents us or changed the way either our packet or the returning packet had arrived to us. 06:04.410 --> 06:19.070 In order to have good results with any OS fingerprinting tool, you have to have the target machine willing to talk to you, meaning that your packets will arrive to the target machine, and also that the target machine will be operational on the network, 06:19.070 --> 06:20.330 meaning it will be up. 06:20.330 --> 06:33.310 And of course, if you don't have elements such as network-based firewalls, host-based firewalls, not-enabled devices, load balancers, and other things between you to the target. 06:33.310 --> 06:53.090 So, just a quick example, if the scanning machine scans a local network, there is a firewall between the scanning machine to one of the networks, and it prevents the sending packets through to targets that part of the network will not be identified, and those hosts will not be listed by the tool. 06:53.210 --> 06:56.330 This is also true if you have personal firewall installed on a machine. 06:56.330 --> 06:58.730 That will prevent OS detection from working. 06:58.990 --> 07:02.890 You'll never get any active OS detection working like that. 07:02.890 --> 07:23.110 Another example is that if some of you, not hinting, sits at home and wants to scan www.companythatyoulike.com, and that company that you like.com has load balancers in front of its web servers. 07:23.110 --> 07:26.490 Well, the initial approach of voice fingerprinting will not work here. 07:27.010 --> 07:31.910 Some of those load balancers will answer themselves through the probe. 07:31.910 --> 07:49.170 Some of them will change some of the parameters that will go back to the scanner, and some of them even, if there is no one OS that operates on the web servers behind the load balancers, then you might get funny results back. 07:51.730 --> 08:02.710 So basically, the result will be that if the packets that you need in order to draw conclusions about the OS is being dropped, then you'll not get anything. 08:04.950 --> 08:13.070 Sometimes, when we send packets to the target, there is something along the way, like a scrubber, a firewall. 08:13.290 --> 08:23.910 I don't know how many of you are familiar with checkpoint firewall, but that firewall can scrub several fields inside a packet that comes back. 08:23.910 --> 08:31.650 And those kind of alterations will prevent us from determining what is the underlying OS there. 08:32.910 --> 08:50.250 Sometimes, if a tool uses malformed packets, those packets will also be dropped by an intrusion prevention system or other system that checks for the legitimacy of the packet. 08:50.250 --> 08:58.530 So some examples would include some weird TCP-IP flag combinations, like SYNFIN, SYNRESET. 08:58.530 --> 09:03.630 Those will never go through an IPS and will never be able to reach the target. 09:04.210 --> 09:16.890 So of course, if the tool that you are using is using crafted packets and is sending crafted packets throughout the Internet, then that tool will not be able to provide good results. 09:16.890 --> 09:36.490 The other problem that we have there is that sometimes those malformed packets may have another hidden effect that might cause some TCP-IP stacks to crash, especially when those stacks don't need to do too many things. 09:36.490 --> 09:43.130 Especially, we can name printers, we can name print servers, and things like that. 09:43.930 --> 09:53.450 And of course, there are some other smart people out there that want to obscure the way that their operating system works. 09:53.710 --> 10:03.530 So they change the characteristics of the TCP-IP stack behavior by altering some kernel parameters, tunable kernel parameters. 10:03.530 --> 10:14.950 So if you are familiar with several commands, for example, the CCTL command and the NDD command on Sun, then you are able to tune the parameters. 10:14.950 --> 10:18.230 Also, on Linux, it's very easy to perform these kinds of things. 10:22.020 --> 10:26.800 So let's go into some signature-based related issues. 10:27.980 --> 10:33.460 The signature database is the most important piece of any OS detection tool. 10:33.460 --> 10:54.480 If the signature database will be corrupted, if the signatures will not be inserted to the signature database in a correct manner, then at the end of the day, you'll have a corrupted signature database, and it will not help the tool, even if the tool is using the most admirable test out there. 10:54.680 --> 10:59.640 Still, the results that the tool will be performing will be poor. 11:00.440 --> 11:13.720 This is a traditional argue between those who strictly control their signature database to those who allow people to submit signatures for their tool. 11:14.200 --> 11:19.380 My approach is that if I want to insert a signature, I want it to work. 11:19.380 --> 11:26.910 In most cases, I won't insert a signature that someone sent me off a firewall device because there is no use of it. 11:29.510 --> 11:31.030 That's music. 11:32.170 --> 11:36.330 So basically, my approach takes it to the extreme. 11:36.330 --> 11:40.250 Basically, I need to go and I need to see the device. 11:40.250 --> 11:42.550 I need to verify the OS. 11:42.550 --> 11:48.070 I need to verify, in some cases, what it is actually running. 11:48.890 --> 11:52.470 The lab environment is the best way to do this. 11:52.470 --> 12:00.290 And therefore, when you enter the signature in question to the signature database, it will work in most of the cases. 12:01.410 --> 12:16.050 Some of the other tools that are out there simply would say, okay, there is a webpage here, let's submit some signatures, and then you don't know what was the actual test there and that this signature was produced at. 12:16.050 --> 12:24.470 And you try to run a certain test, and at the end of the day, what you get is a mixed result that never comes close to the reality. 12:25.250 --> 12:32.890 So we can strictly control the process of inserting signatures into the database. 12:32.990 --> 12:35.510 Sure, it has its downside. 12:35.890 --> 12:37.430 It's a slower process. 12:37.470 --> 12:45.870 It has a limit on the number of signatures and devices that you can insert into the database because we can't buy them all or we can't access them all. 12:45.990 --> 12:49.610 And the one plus of it is that it is extremely accurate. 12:49.610 --> 12:56.490 On the other hand, if we do not control the signature database, then signatures are inserted because they are there. 12:56.970 --> 13:00.330 The creation process is not controlled. 13:01.090 --> 13:09.550 If those signatures are created in a wrongfully manner, then we have a corrupted database and not a controlled one, which is extremely inaccurate. 13:12.370 --> 13:20.430 When we do OS fingerprinting, we fingerprint the way that the software reacts to the probes that we send. 13:20.430 --> 13:27.170 When we fingerprint a hardware-based device, basically we fingerprint the way the firmware actually answers us. 13:27.170 --> 13:45.190 And this is a common mistake when we go and we try to do this thing because if you are familiar with hardware-based devices, then most of them will, for the same manufacturers, most of them will run either the same firmware or a slightly different firmware. 13:45.190 --> 13:54.630 Usually it depends either on their role, or the manufacturer decides that he wants one firmware or two. 13:54.830 --> 13:57.390 So there are a few examples with that. 13:58.930 --> 14:13.190 Cisco 7200 will be fingerprinting as 2950, as the Switch 2950, as a 6500 running iOS, and even as the Aeronet's wireless access points. 14:13.190 --> 14:13.430 Why ? 14:13.430 --> 14:22.210 Because they are all running iOS, and with traditional TCP-IP-based stack fingerprinting, we're not able to tell the difference of their roles. 14:22.510 --> 14:24.610 There are other nice examples. 14:24.890 --> 14:43.610 Foundry Networks usually run the same OS, sorry, the same firmware on all of their systems, and also the printers, if you're familiar with HP printers, those will also run the same firmware or a slightly different firmware, depending on the year and the updates. 14:44.710 --> 14:53.590 But, unfortunately, some OS fingerprinting tools don't take this into account, and at the end of the day, it also brings them to the... 14:54.190 --> 15:11.950 for having a corrupted database, when you do a fingerprinting of HP, what you get is not that this is an HP printer, you get that it might be a home printer, a corporate printer, or whatever else printer and other things, but at the end of the day, that's the firmware, 15:11.950 --> 15:13.110 not the model. 15:17.730 --> 15:29.790 When we want to expand and use other fingerprinting tests, and we want to expand what we have, then we need to go through the entire signature database and we need to update it. 15:30.850 --> 15:41.590 If we need to do so, as part of the signatures or part of the tool evolution, then we need to go through the entire signatures and update them with new tests. 15:42.410 --> 15:47.850 If we do not control what is inside the database, then we are unable to update that. 15:48.010 --> 15:57.850 So, we might have new tests that we want to have, we might have new things that we want to introduce, but at the end of the day, we can't do that, because we don't have control of that. 15:58.270 --> 16:02.750 And, of course, there is one other small issue, which is a political issue. 16:03.470 --> 16:19.470 The political issue is that many open source tools basically are abused, because many commercial companies do not read the license and they take the signature database and they claim it as their own. 16:20.030 --> 16:33.430 There are some examples for that, but at the end of the day, when you contribute something to the open source community and you hope that it is actually being used, then you don't want your work to be stolen as well. 16:34.850 --> 16:57.350 This is actually causing some guys that manufacture, that actually develop open source tools, not to insert the entire knowledge into those tools, or sometimes not to insert their entire signature database into those tools, because they know that people will just go download the signature database, 16:57.350 --> 17:00.810 enjoy what they have done, and basically don't pay them anything. 17:03.430 --> 17:10.710 There are some issues that relate to the way the OS fingerprinting tool actually works. 17:12.790 --> 17:17.170 Scanning results needs to be matched with the signature database. 17:17.750 --> 17:19.830 There are actually two ways of doing that. 17:19.830 --> 17:21.950 Actually, there can be more. 17:21.950 --> 17:38.030 Either you do strict signature matching, where you search for a 100% match between what you've got to the signature database, or that you use statistical analysis approach, which basically says we'll find the best match for you, and we will present you with the best match, 17:38.030 --> 17:42.030 even if some of those tests had failed. 17:42.590 --> 17:45.090 So these are the two approaches that we have. 17:47.910 --> 18:00.370 Another problem is that Stacks looks alike with new released operating systems, and there are only n number of tests, or n number of parameters that we can look for. 18:00.370 --> 18:06.830 So theoretically, somewhere along the line, the number of possible matches should be reached. 18:06.830 --> 18:27.250 Although this number is still currently high, there are classes of different operating systems that even when we use several new OS fingerprinting tests or old OS fingerprinting tests, we're still unable to distinguish between their Stacks because the tests that we're using are insufficient to do so. 18:27.250 --> 18:50.190 So what we need to have is the ability of a tool to have fingerprinting tests that have multiple parameters inside of them, that they represent different OSs, that many parameters are different among the TCPIP Stack, and that allows us to receive better overall results. 18:53.690 --> 19:04.930 Another problem that we have is that when some tests are regarded better than others, it means that if they would fail, then the quality of results that we will have will be lowered. 19:06.310 --> 19:25.830 For example, if we would not receive SYNAC response for a SYN request to an open port, or we'll not get this kind of response at all, or we'll not receive port enrichable for UDP packet, then basically the way that we'll have results will not have too much. 19:28.890 --> 19:32.010 I've touched this slightly beforehand. 19:32.290 --> 19:41.390 This is the problem of having slight differences between the TCPIP Stacks of newly released operating systems to an older one. 19:42.350 --> 19:49.430 XPSP2, for example, and Windows 2003 share the same characteristics of the stack. 19:49.430 --> 19:56.570 So does Windows 2000 and XP with no OSP and SP1. 19:56.810 --> 20:00.890 And so does some Linux kernels share the same characteristics. 20:01.290 --> 20:05.930 This actually brings us to the point that we cannot have granular results. 20:05.930 --> 20:16.450 What we have is just grouped results that at the end of the day might say, okay, this is a Windows system, but actually it will not list the underlying OS. 20:19.430 --> 20:34.070 Another problem that we have is that the type of information that we are able to extract using traditional TCPIP Stack fingerprinting is limited, and one of the examples can be shown with the different Windows operating system service packs. 20:34.970 --> 20:46.990 Traditional TCPIP-based tools are not able to tell the service pack in most of the cases, and this is a problem if you want to use the information for other tools like vulnerability assessment. 20:58.310 --> 21:04.370 When we're using a tool, we would like to have the maximum flexibility with the tool. 21:04.470 --> 21:07.670 We would like to have the ability to control what models it is using. 21:07.670 --> 21:16.710 So if we know that we operate against a web server, we're not going to use tests that we assume that will be dropped or not be answered. 21:16.750 --> 21:33.350 So an active OS fingerprinting tool needs to have all of its models controlled and has to allow the user to specify exactly which models you want to use and what types of packets you want to send to the host. 21:37.370 --> 21:50.650 Another problem, and this is the last of the row, is that sometimes active OS fingerprinting tools will pose an out-of-service condition to those elements they're scanning. 21:50.730 --> 22:01.230 The problem is that sometimes those will use non-RFC compliant packets or the pace of the scan will be too fast for the element to handle. 22:01.430 --> 22:06.490 And that will cause the element to crash or use extra packets. 22:08.070 --> 22:12.050 I have a Kyocera Amida FS-1900 printer in my office. 22:12.190 --> 22:18.490 If I scan it with nmap, the printer crashes to the point that I have to go and I have to power off the printer and power it on. 22:22.550 --> 22:33.550 So, the summary for this is that we need to understand the Terran, we need to understand what we're scanning, we need to understand what's between us to the target. 22:34.470 --> 22:42.710 If we cannot meet the conditions that we need in order to get good results, then basically we're not going to get any kind of results. 22:44.950 --> 23:03.250 We need to understand those conditions in order to build better tools that will allow us to receive results even if we're operating against a well-fortified element sitting behind different kind of security mechanisms. 23:08.640 --> 23:24.460 There are some other approaches that came and said, okay, let's decide or let's see if we can bypass those problems and basically what they have said is that, okay, let's take one protocol, we try to analyze that and we'll use only that protocol in order to draw conclusions about what we see. 23:24.460 --> 23:38.200 So there are some researchers, if you heard about a tool called TBIT, basically they look for the current state of TCP implementation or TCP implementations on web servers. 23:38.660 --> 24:02.020 So they took the tool and said, okay, this is something that we can use in order to do OS fingerprinting, but the problem is that using multiple tests only against an open TCP port, it actually doesn't do anything because you're still at the point which the Windows operating system as a group will be identified. 24:02.140 --> 24:10.720 And we can actually perform these kind of tests only with one packet when we do not need all of those packets in order to do that. 24:10.720 --> 24:31.720 So if we look at the needed solution, then we need intelligence in scanning, we need to understand the terrain that we operate against, and we need the active OS fingerprinting tool to understand the quality of received results in order to react to the received results with proper targeted OS detection tools. 24:32.600 --> 24:53.620 So at the end of the day, what we're looking for is we're looking for a tool that will have the ability not only to perform stack-based OS fingerprinting, the traditional approach, but also to have the ability to have application-based fingerprinting tests along with the tool. 24:54.280 --> 24:55.840 Something along the lines of... 24:55.840 --> 24:58.800 you can't see this because it's all screwed... 24:59.620 --> 25:24.380 something along the lines of we send several packets, we analyze what we receive back, we see which ports are open, what services, what type of family of operating system we're operating against, and then the tool will be able to launch automatically the kind of application-based fingerprinting test that needs to be run against those family of operating systems. 25:25.340 --> 25:27.240 Questions until this point? 25:28.660 --> 25:30.080 No questions. 25:30.140 --> 25:30.980 Okay. 25:30.980 --> 25:39.680 So, for the past four years, I've been one of the developers of Xprog2, which is an active OS fingerprinting tool. 25:40.020 --> 25:45.780 Open source, remote active OS fingerprinting tool that you can use... I mean, if you like it, you use it. 25:45.780 --> 25:47.080 If you don't, you don't. 25:48.980 --> 25:54.380 The project represents our take, our beliefs, and basically it's our fund to create it. 25:54.380 --> 25:55.340 If you use it, great. 25:55.340 --> 25:57.920 If not, again, it's your choice. 25:59.000 --> 26:03.240 It was voted one of the top 75 network security tools. 26:03.240 --> 26:06.920 It replaced Nmap as the OS detection engine for Nessus after... 26:07.940 --> 26:16.100 if you're familiar with Nessus, Nessus uses SMB, NTP, and then it will use the OS fingerprinting test that I found with Xprog2. 26:17.480 --> 26:18.440 Yeah. 26:23.500 --> 26:24.740 Unfortunately, yes. 26:24.740 --> 26:29.280 If you are the application layer, they will play with some of those parameters as well. 26:32.660 --> 26:36.940 Xprog2 basically uses less packets than any other OS fingerprinting tool. 26:36.940 --> 26:38.420 Well, we at least try to. 26:39.020 --> 26:41.800 It does not disturb the operation of the target system. 26:42.300 --> 26:44.600 You can control whatever models you would like to use. 26:44.600 --> 26:53.340 And of course, at the end of the day, if you use it in the lab against whatever you put there, you'll see that it will give you more accurate results than any other tool. 26:54.340 --> 26:55.540 I'll skip this slide. 26:55.540 --> 26:58.320 Basically, what we did along the four years. 27:00.220 --> 27:02.960 The different software models that we have there. 27:03.080 --> 27:11.760 Basically, we have some discovery models, some information gathering models, and some OS detection models, of course. 27:14.380 --> 27:21.520 The tool has a very extensive command line options, which I will not go into, because you didn't come for this now. 27:21.520 --> 27:27.640 The tool is able to detect if there are obstacles between the tool and the target system. 27:27.640 --> 27:32.160 So, for example, if you have a proxy between you and the target system, it is able to detect that. 27:33.220 --> 27:35.740 And other gizmos that I will go through. 27:36.540 --> 27:41.060 So, very fast, discovery models basically are designed to perform host detection. 27:41.700 --> 27:56.280 Their aim is not only to see that the host is alive, but also to aid the automatic receive timeout mechanism in understanding what is the timeout that needs to be automatically selected for the target host. 27:56.280 --> 28:02.300 This is important because when you are scanning something, you don't want to timeout too fast on that one. 28:03.000 --> 28:05.640 There is also a port scanner with the tool. 28:06.080 --> 28:13.660 You can specify ports to be scanned, either capital T or capital U for UDP and TCP, respectively. 28:13.760 --> 28:15.960 There are some examples for that. 28:15.960 --> 28:21.900 So you get a list with any other tool of the open ports, closed ports and filtered ports. 28:23.320 --> 28:38.600 So, if you want perfect results, you need to have an open TCP port, a closed TCP port, a closed UDP port and either receive replies for echo request, timestamp request and address request. 28:40.180 --> 28:45.500 Before this version, we introduced another OS fingerprinting model called ResetAct. 28:45.500 --> 28:52.220 Basically what we do there is we send two scenes to a closed port and we compare them. 28:52.220 --> 29:03.340 That test actually allowed us to differentiate between the different groups of the Linux kernels and we can actually divide them into seven groups. 29:03.780 --> 29:18.560 This is a very useful tool if you need to have the understanding if this is a 2.4 based kernel or a 2.6 based kernel and also go inside those families of kernels and have some information there. 29:19.260 --> 29:36.720 Some other useful command line options by default, if you run xprog2 with "-v and "-b", it automatically will try to enumerate several ports, so you don't need to specify a port scan, you just do lower v, uppercase B and the IP address. 29:36.720 --> 29:48.740 You are also able to automatically generate signatures using the capital F command line and you can save the information using the "-o command line". 29:48.740 --> 29:52.000 Okay, that you can do yourself at home, you can play with it. 29:54.180 --> 30:06.920 The version that we are releasing today is available for download, you can either go to my website or directly go to our page at sourceforge.org. 30:06.920 --> 30:20.480 Basically what we have is we have two new application-based OS fingerprinting models inserted to the tool in order to help the tool operate better in different scanning conditions. 30:20.480 --> 30:24.680 We also have new signatures and we also have several bug fixes. 30:25.180 --> 30:32.720 The first app-based OS fingerprint model that we have entered and it's not something new, but it's good to have in a tool. 30:32.980 --> 30:40.800 It's an SMB-based model, basically very good against Microsoft Windows-based machines that have their file and print sharing working. 30:41.380 --> 30:51.260 It basically retrieves the native OS and native Lundman parameters from the SMB session setup and NX replies. 30:51.700 --> 31:02.320 And it helps us differentiate between different Windows OSes such as Windows XP in 2003 between several problems that we have between 2000 and XP. 31:02.320 --> 31:07.240 And basically it allows us granularity when it comes to Windows operating systems. 31:07.240 --> 31:16.000 So we have different you have new keywords that you specify the information there called SMB underscore Lundman and SMB underscore native OS. 31:16.000 --> 31:18.480 You put the information there it all works. 31:18.760 --> 31:27.760 This is an example not using the SMB model at the end of the day what you see is the results are all mixed up. 31:27.760 --> 31:31.620 XP with 2000 and we can't see really the differentiation. 31:33.100 --> 31:39.500 This model works automatically when you tell the model to use port 139 when you port scan port 139. 31:39.500 --> 31:43.620 So you specify the minus T 139 with the command line. 31:43.960 --> 31:51.660 It's automatically executed and at the end of the day the results are Windows 2000 because this is a Windows 2000 service pack for a machine. 31:52.280 --> 31:57.340 Another model that we have inserted is SNMP based model. 31:57.540 --> 32:17.440 Mostly it's good when it is used against well, those elements that use SNMP but also when you have certain kind of an element which is a hardware based and you want to extract that information in order to help you detect what's the underlying operating system. 32:17.440 --> 32:17.440 based model . 32:17.440 --> 32:22.960 Currently only SNMP v2 is being supported but the next version will have v1 and v3 as well . 32:23.760 --> 32:27.440 And it needs to have UDP port 161 open in order to operate. 32:27.580 --> 32:32.180 So this is an example with FreeBSD 5.3. 32:32.180 --> 32:40.560 You can see if you can look at it actually, that the SNMP community stream was public. 32:40.560 --> 32:50.360 There you can look at the export2.conf and specify there and what the information was extracted from the FreeBSD 5.3 based machine. 32:50.360 --> 33:00.720 You can see that this actually contributed to the fact that we got FreeBSD 5.3 with 100% and the other FreeBSDs with less percentage than that. 33:01.440 --> 33:07.540 We have also new signatures for the different Apple Mac OS X. 33:07.540 --> 33:10.500 We have missed those signatures for quite a long time. 33:10.660 --> 33:17.060 We have updated the signatures for Linux, FreeBSD and OpenBSD and we also have fixed several bug fixes that we have with the tool. 33:20.120 --> 33:31.280 And we would like to take the tool to a different level by automating the scans, by understanding the Terran, but I guess it will take us a bit of time to do that. 33:31.800 --> 33:32.820 Questions? 33:33.300 --> 33:34.040 Yes. 33:34.820 --> 33:35.080 If 33:38.460 --> 33:43.760 you use SMB and SNMP and you do port scan, you are not stealth. 33:45.520 --> 33:51.720 Any IDS, IPS or anything that will look for these kind of parameters will pick you up easily. 33:52.900 --> 33:54.500 That's the problem as well. 33:54.860 --> 34:01.720 If you are not having the information prior, then you cannot really be stealth. 34:03.040 --> 34:04.080 Yes. 34:11.110 --> 34:20.130 Any test actually has its own weight inside the BigPi of OS fingerprinting tests. 34:20.130 --> 34:22.450 Each parameter has its own weight as well. 34:22.450 --> 34:36.530 So if one of them is not being matched or there is a problem matching that parameter with the signature database, that will take the percentage of hit to be less than 100%. 34:36.530 --> 34:46.470 One other thing that I want to mention, this is a project that my fellow co-authors are doing. 34:46.470 --> 34:47.570 It's called STIF. 34:47.570 --> 34:51.630 It stands for Security Tools Integration Framework. 34:51.630 --> 34:56.950 It basically is a platform to automate security analysis. 34:56.950 --> 35:05.270 You can check that project with the URL that is being shown at the bottom. 35:05.270 --> 35:06.330 It's a very cool project. 35:06.330 --> 35:07.370 Very cool guys. 35:07.370 --> 35:09.410 You should check their project as well. 35:10.170 --> 35:11.250 Other questions? 35:13.150 --> 35:15.090 Thank you for having me today. 35:15.610 --> 35:17.070 Enjoy the conference.