[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:33.890] Basically, we're going to discuss the problems that are usually associated with active voice fingerprinting, [00:33.890 --> 00:36.090] and we'll see how we can remedy that. [00:36.490 --> 00:44.210] A bit about myself, I'm the founder of the C-Security Group, also founder of NCITEC, [00:44.210 --> 00:46.190] I'm the Chief Technical Officer there. [00:46.930 --> 00:53.710] I've done some research about infrastructure discovery, voice over IP security, and OS detection, [00:53.710 --> 00:57.810] 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:17.750] Traditional approach will send some packets, will examine the stack behavior, [01:17.750 --> 01:26.070] usually with IP, UDP, TCP, and ICP, in order to draw some conclusions about that underlying OS. [01:26.070 --> 01:35.510] Usually, when results are received from a target element, those results will be compared to a certain signature database, [01:35.610 --> 01:40.570] a certain tool will have, in an effort to find a match. [01:41.930 --> 01:50.010] Just because the traditional approach is to use TCP IP stack-based fingerprinting, usually limited to those protocols I've mentioned, [01:50.010 --> 01:57.230] 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:26.230] Basically, the packets they are sending to the target host, trying to enumerate the operating system, [02:26.230 --> 02:29.030] 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 --> 02:50.510] Some need that to do vulnerability assessment, some like to have some context about their network, [02:50.510 --> 03:00.890] 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:09.010] If we go and look at the strength of doing remote active OS fingerprinting, [03:09.010 --> 03:14.690] 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:32.690] Usually such a tool will provide with fast results if there are no obstacles on the way, [03:32.690 --> 03:36.570] 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:05.330] That's basically it. 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:19.550] The biggest problem is the scanning conditions and the environment effects on the scan, [04:20.030 --> 04:26.410] the way that the OS detection tool operates, the signature database is not a major caveat, [04:26.770 --> 04:29.690] 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:46.190] Basically, when we perform an OS detection or basically any other scan, [04:46.190 --> 04:49.030] 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 --> 05:52.590] There is currently no tool that is going to tell us, [05:52.590 --> 06:01.750] 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:11.950] In order to have good results with any OS fingerprinting tool, you have to have the target machine willing to talk to you, [06:11.950 --> 06:15.410] meaning that your packets will arrive to the target machine, [06:15.410 --> 06:20.330] and also that the target machine will be operational on the network, meaning it will be up. [06:20.330 --> 06:27.270] And of course, if you don't have elements such as network-based firewalls, host-based firewalls, [06:27.270 --> 06:33.310] not-enabled devices, load balancers, and other things between you to the target. [06:33.310 --> 06:40.510] So, just a quick example, if the scanning machine scans a local network, [06:40.510 --> 06:43.650] there is a firewall between the scanning machine to one of the networks, [06:43.650 --> 06:50.250] and it prevents the sending packets through to targets that part of the network will not be identified, [06:50.250 --> 06:53.090] 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:16.170] Another example is that if some of you, not hinting, sits at home and wants to scan www.companythatyoulike.com, [07:17.110 --> 07:23.110] 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:37.850] Some of them will change some of the parameters that will go back to the scanner, [07:37.850 --> 07:46.570] and some of them even, if there is no one OS that operates on the web servers behind the load balancers, [07:46.570 --> 07:49.170] then you might get funny results back. [07:51.730 --> 08:00.790] So basically, the result will be that if the packets that you need in order to draw conclusions about the OS is being dropped, [08:00.790 --> 08:02.710] 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:17.870] I don't know how many of you are familiar with checkpoint firewall, [08:17.870 --> 08:23.910] 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:43.250] Sometimes, if a tool uses malformed packets, those packets will also be dropped by an intrusion prevention system [08:43.250 --> 08:50.250] 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:12.170] So of course, if the tool that you are using is using crafted packets and is sending crafted packets throughout the Internet, [09:12.170 --> 09:16.890] then that tool will not be able to provide good results. [09:16.890 --> 09:24.970] The other problem that we have there is that sometimes those malformed packets may have another hidden effect [09:24.970 --> 09:36.490] 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:12.990] So if you are familiar with several commands, for example, the CCTL command and the NDD command on Sun, [10:12.990 --> 10:18.230] then you are able to tune the parameters. 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:42.480] If the signature database will be corrupted, if the signatures will not be inserted to the signature database in a correct manner, [10:43.040 --> 10:49.120] then at the end of the day, you'll have a corrupted signature database, and it will not help the tool, [10:49.120 --> 10:54.480] 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:09.240] This is a traditional argue between those who strictly control their signature database [11:09.240 --> 11:13.720] 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:42.550] Basically, I need to go and I need to see the device. 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:05.670] Some of the other tools that are out there simply would say, [12:05.670 --> 12:09.650] okay, there is a webpage here, let's submit some signatures, [12:10.150 --> 12:16.050] and then you don't know what was the actual test there and that this signature was produced at. [12:16.050 --> 12:19.790] And you try to run a certain test, and at the end of the day, [12:19.790 --> 12:24.470] 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:37.430] Sure, it has its downside. It's a slower process. [12:37.470 --> 12:42.030] It has a limit on the number of signatures and devices that you can insert into the database [12:42.030 --> 12:45.870] 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:52.890] On the other hand, if we do not control the signature database, [12:52.890 --> 12:56.490] then signatures are inserted because they are there. [12:56.970 --> 13:00.330] The creation process is not controlled. [13:01.090 --> 13:04.590] If those signatures are created in a wrongfully manner, [13:04.590 --> 13:07.570] then we have a corrupted database and not a controlled one, [13:07.570 --> 13:09.550] which is extremely inaccurate. [13:12.370 --> 13:17.610] When we do OS fingerprinting, we fingerprint the way that the software reacts [13:17.610 --> 13:20.430] to the probes that we send. [13:20.430 --> 13:23.010] When we fingerprint a hardware-based device, [13:23.010 --> 13:27.170] basically we fingerprint the way the firmware actually answers us. [13:27.170 --> 13:30.830] And this is a common mistake when we go and we try to do this thing [13:31.910 --> 13:35.670] because if you are familiar with hardware-based devices, [13:35.670 --> 13:38.810] then most of them will, for the same manufacturers, [13:38.810 --> 13:45.190] most of them will run either the same firmware or a slightly different firmware. [13:45.190 --> 13:49.670] Usually it depends either on their role, [13:49.670 --> 13:54.630] 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:06.670] Cisco 7200 will be fingerprinting as 2950, as the Switch 2950, [14:06.670 --> 14:13.190] as a 6500 running iOS, and even as the Aeronet's wireless access points. [14:13.190 --> 14:14.970] Why? Because they are all running iOS, [14:14.970 --> 14:19.130] and with traditional TCP-IP-based stack fingerprinting, [14:19.130 --> 14:22.210] 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:28.330] Foundry Networks usually run the same OS, [14:28.330 --> 14:30.850] sorry, the same firmware on all of their systems, [14:30.850 --> 14:36.170] and also the printers, if you're familiar with HP printers, [14:36.170 --> 14:40.590] those will also run the same firmware or a slightly different firmware, [14:40.590 --> 14:43.610] depending on the year and the updates. [14:44.710 --> 14:47.670] But, unfortunately, some OS fingerprinting tools [14:47.670 --> 14:49.650] don't take this into account, [14:49.650 --> 14:53.590] and at the end of the day, it also brings them to the... [14:54.190 --> 14:57.170] for having a corrupted database, [14:57.170 --> 14:59.230] when you do a fingerprinting of HP, [14:59.230 --> 15:01.770] what you get is not that this is an HP printer, [15:01.770 --> 15:05.970] you get that it might be a home printer, [15:06.310 --> 15:09.870] a corporate printer, or whatever else printer and other things, [15:09.870 --> 15:13.110] but at the end of the day, that's the firmware, not the model. [15:17.730 --> 15:22.930] When we want to expand and use other fingerprinting tests, [15:22.930 --> 15:25.410] and we want to expand what we have, [15:25.410 --> 15:28.250] then we need to go through the entire signature database [15:28.250 --> 15:29.790] and we need to update it. [15:30.850 --> 15:34.950] If we need to do so, as part of the signatures [15:34.950 --> 15:38.210] or part of the tool evolution, [15:38.210 --> 15:39.910] then we need to go through the entire signatures [15:39.910 --> 15:41.590] and update them with new tests. [15:42.410 --> 15:45.770] If we do not control what is inside the database, [15:45.770 --> 15:47.850] then we are unable to update that. [15:48.010 --> 15:50.150] So, we might have new tests that we want to have, [15:50.150 --> 15:53.210] we might have new things that we want to introduce, [15:53.730 --> 15:55.930] but at the end of the day, we can't do that, [15:55.930 --> 15:57.850] because we don't have control of that. [15:58.270 --> 16:00.810] And, of course, there is one other small issue, [16:00.810 --> 16:02.750] which is a political issue. [16:03.470 --> 16:07.110] The political issue is that many open source tools [16:07.110 --> 16:09.290] basically are abused, [16:09.290 --> 16:11.910] because many commercial companies do not read the license [16:11.910 --> 16:15.610] and they take the signature database [16:15.610 --> 16:19.470] and they claim it as their own. [16:20.030 --> 16:22.770] There are some examples for that, [16:22.770 --> 16:24.230] but at the end of the day, [16:24.230 --> 16:26.910] when you contribute something to the open source community [16:26.910 --> 16:30.110] and you hope that it is actually being used, [16:30.110 --> 16:33.430] then you don't want your work to be stolen as well. [16:34.850 --> 16:39.290] This is actually causing some guys that manufacture, [16:39.290 --> 16:43.570] that actually develop open source tools, [16:43.570 --> 16:47.510] not to insert the entire knowledge into those tools, [16:47.510 --> 16:51.150] or sometimes not to insert their entire signature database [16:51.150 --> 16:52.910] into those tools, because they know [16:53.190 --> 16:57.350] that people will just go download the signature database, [16:57.350 --> 16:58.450] enjoy what they have done, [16:58.450 --> 17:00.810] and basically don't pay them anything. [17:03.430 --> 17:06.510] There are some issues that relate to the way [17:07.350 --> 17:10.710] the OS fingerprinting tool actually works. [17:12.790 --> 17:14.630] Scanning results needs to be matched [17:14.630 --> 17:17.170] 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:23.530] Either you do strict signature matching, [17:23.530 --> 17:26.150] where you search for a 100% match [17:26.150 --> 17:28.710] between what you've got to the signature database, [17:28.710 --> 17:32.090] or that you use statistical analysis approach, [17:32.090 --> 17:36.170] which basically says we'll find the best match for you, [17:36.170 --> 17:38.030] 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 --> 17:51.610] Another problem is that Stacks looks alike [17:51.610 --> 17:54.490] with new released operating systems, [17:54.490 --> 17:57.590] and there are only n number of tests, [17:57.590 --> 18:00.370] or n number of parameters that we can look for. [18:00.370 --> 18:03.870] So theoretically, somewhere along the line, [18:03.870 --> 18:06.830] the number of possible matches should be reached. [18:06.830 --> 18:09.130] Although this number is still currently high, [18:09.130 --> 18:11.210] there are classes of different operating systems [18:11.210 --> 18:15.790] that even when we use several new OS fingerprinting tests [18:15.790 --> 18:17.490] or old OS fingerprinting tests, [18:17.490 --> 18:21.130] we're still unable to distinguish between their Stacks [18:21.130 --> 18:27.250] because the tests that we're using are insufficient to do so. [18:27.250 --> 18:30.410] So what we need to have is the ability of a tool [18:30.410 --> 18:36.690] to have fingerprinting tests that have multiple parameters inside of them, [18:36.690 --> 18:41.150] that they represent different OSs, [18:41.150 --> 18:45.670] that many parameters are different among the TCPIP Stack, [18:45.670 --> 18:50.190] and that allows us to receive better overall results. [18:53.690 --> 18:55.390] Another problem that we have is that [18:55.390 --> 18:59.110] when some tests are regarded better than others, [18:59.110 --> 19:01.130] it means that if they would fail, [19:01.130 --> 19:04.930] then the quality of results that we will have will be lowered. [19:06.310 --> 19:09.630] For example, if we would not receive SYNAC response [19:09.630 --> 19:13.330] for a SYN request to an open port, [19:13.330 --> 19:15.990] or we'll not get this kind of response at all, [19:15.990 --> 19:19.830] or we'll not receive port enrichable for UDP packet, [19:19.830 --> 19:23.110] then basically the way that we'll have results [19:23.110 --> 19:25.830] will not have too much. [19:28.890 --> 19:32.010] I've touched this slightly beforehand. [19:32.290 --> 19:35.250] This is the problem of having slight differences [19:35.250 --> 19:39.750] between the TCPIP Stacks of newly released operating systems [19:39.750 --> 19:41.390] to an older one. [19:42.350 --> 19:45.250] XPSP2, for example, and Windows 2003 [19:45.890 --> 19:49.430] 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:02.870] This actually brings us to the point [20:02.870 --> 20:05.930] that we cannot have granular results. [20:05.930 --> 20:08.050] What we have is just grouped results [20:08.050 --> 20:11.070] that at the end of the day might say, [20:11.070 --> 20:13.230] okay, this is a Windows system, [20:13.230 --> 20:16.450] but actually it will not list the underlying OS. [20:19.430 --> 20:22.190] Another problem that we have is that the type of information [20:22.190 --> 20:25.490] that we are able to extract using traditional TCPIP Stack [20:25.490 --> 20:27.570] fingerprinting is limited, [20:27.570 --> 20:30.170] and one of the examples can be shown [20:30.170 --> 20:34.070] with the different Windows operating system service packs. [20:34.970 --> 20:37.610] Traditional TCPIP-based tools [20:38.210 --> 20:41.190] are not able to tell the service pack in most of the cases, [20:41.190 --> 20:45.070] and this is a problem if you want to use the information [20:45.070 --> 20:46.990] for other tools like vulnerability assessment. [20:58.310 --> 21:01.210] When we're using a tool, [21:01.210 --> 21:04.370] 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:10.890] So if we know that we operate against a web server, [21:10.890 --> 21:12.930] we're not going to use tests that we assume [21:12.930 --> 21:16.710] that will be dropped or not be answered. [21:16.750 --> 21:19.230] So an active OS fingerprinting tool needs to have [21:19.230 --> 21:21.370] all of its models controlled [21:21.370 --> 21:24.610] and has to allow the user to specify exactly [21:24.610 --> 21:25.830] which models you want to use [21:25.830 --> 21:29.750] and what types of packets you want to send [21:29.750 --> 21:33.350] to the host. [21:37.370 --> 21:38.590] Another problem, [21:38.590 --> 21:41.370] and this is the last of the row, [21:41.370 --> 21:45.010] is that sometimes active OS fingerprinting tools [21:45.010 --> 21:48.570] will pose an out-of-service condition [21:48.570 --> 21:50.650] to those elements they're scanning. [21:50.730 --> 21:52.910] The problem is that sometimes those will use [21:52.910 --> 21:55.910] non-RFC compliant packets [21:55.910 --> 21:58.550] or the pace of the scan will be too fast [21:58.550 --> 22:01.230] for the element to handle. [22:01.430 --> 22:03.950] And that will cause the element to crash [22:03.950 --> 22:06.490] 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:13.570] If I scan it with nmap, [22:13.570 --> 22:15.650] the printer crashes to the point that I have to go [22:15.650 --> 22:18.490] and I have to power off the printer and power it on. [22:22.550 --> 22:23.310] So, [22:23.310 --> 22:25.970] the summary for this is that [22:26.990 --> 22:28.890] we need to understand the Terran, [22:28.890 --> 22:30.730] we need to understand what we're scanning, [22:30.730 --> 22:33.550] we need to understand what's between us to the target. [22:34.470 --> 22:37.410] If we cannot meet the conditions that we need [22:37.410 --> 22:39.790] in order to get good results, then basically [22:40.370 --> 22:42.710] we're not going to get any kind of results. [22:44.950 --> 22:47.430] We need to understand those conditions [22:47.430 --> 22:50.910] in order to build better tools that will allow us [22:50.910 --> 22:53.270] to receive results even if we're operating [22:53.270 --> 22:55.910] against a well-fortified element [22:56.430 --> 22:59.270] sitting behind different [22:59.270 --> 23:03.250] kind of security mechanisms. [23:08.640 --> 23:09.620] There are some other [23:09.620 --> 23:12.000] approaches that came and said, okay, let's decide [23:12.000 --> 23:14.760] or let's see if we can bypass those problems and [23:14.760 --> 23:18.100] basically what they have said is that, okay, let's take one protocol, [23:18.100 --> 23:21.720] we try to analyze that and we'll use only that protocol [23:21.720 --> 23:24.460] in order to draw conclusions about what we see. [23:24.460 --> 23:26.500] So there are some researchers, [23:27.420 --> 23:30.100] if you heard about a tool called TBIT, [23:30.820 --> 23:34.080] basically they look for the current state [23:34.080 --> 23:36.920] of TCP implementation or TCP implementations [23:36.920 --> 23:40.060] on web servers. So they took the tool and said, [23:40.060 --> 23:42.700] okay, this is something that we can use [23:42.700 --> 23:44.660] in order to do OS fingerprinting, [23:44.660 --> 23:46.920] but the problem is that using [23:48.180 --> 23:50.740] multiple tests only against an open [23:50.740 --> 23:53.780] TCP port, it actually doesn't do anything [23:53.780 --> 23:56.700] because you're still at the point [23:56.700 --> 23:59.900] which the Windows operating [23:59.900 --> 24:02.740] system as a group will be identified. And we can actually [24:02.740 --> 24:05.120] perform these kind of tests [24:05.660 --> 24:08.120] only with one packet when we do not need [24:08.380 --> 24:10.720] all of those packets in order to do that. [24:10.720 --> 24:13.560] So if we look at the needed solution, [24:13.560 --> 24:16.860] then we need intelligence in scanning, we need to understand [24:16.860 --> 24:19.580] the terrain that we operate against, and we need [24:19.580 --> 24:22.620] the active OS fingerprinting tool to understand the quality of received [24:23.240 --> 24:25.680] results in order to react to the received [24:25.680 --> 24:28.260] results with proper targeted [24:29.860 --> 24:31.720] OS detection tools. [24:32.600 --> 24:34.680] So at the end of the day, what we're looking for [24:34.680 --> 24:37.800] is we're looking for a tool that will have [24:37.800 --> 24:40.240] the ability not only to perform [24:41.600 --> 24:43.860] stack-based OS fingerprinting, the traditional [24:43.860 --> 24:46.460] approach, but also to have the ability [24:46.460 --> 24:48.740] to have application-based [24:51.060 --> 24:53.620] 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:00.680] something along the lines of [25:01.720 --> 25:05.000] we send several packets, we analyze what we receive [25:05.000 --> 25:07.760] back, we see which ports are open, what [25:07.760 --> 25:10.840] services, what type of family of operating [25:10.840 --> 25:13.420] system we're operating against, and then [25:13.840 --> 25:16.860] the tool will be able to launch automatically the kind of [25:16.860 --> 25:20.460] application-based fingerprinting [25:20.460 --> 25:22.800] test that needs to be run against those family [25:22.800 --> 25:25.940] of operating systems. Questions [25:25.940 --> 25:27.240] until this point? [25:28.660 --> 25:30.980] No questions. Okay. [25:30.980 --> 25:34.220] So, for the past [25:34.220 --> 25:36.920] four years, I've been one of the developers of [25:36.920 --> 25:39.680] Xprog2, which is an active OS fingerprinting tool. [25:40.020 --> 25:43.140] Open source, remote active OS fingerprinting [25:43.140 --> 25:45.780] 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:52.500] The project represents our take, our beliefs, [25:52.500 --> 25:55.020] and basically it's our fund to create it. If you use it, [25:55.020 --> 25:57.920] great. If not, again, it's your choice. [25:59.000 --> 26:01.040] It was voted one of the top [26:01.040 --> 26:04.220] 75 network security tools. It replaced Nmap [26:04.220 --> 26:06.920] as the OS detection engine for Nessus after... [26:07.940 --> 26:09.720] if you're familiar with Nessus, Nessus uses [26:10.380 --> 26:12.840] SMB, NTP, and then it will use [26:12.840 --> 26:16.100] the OS fingerprinting test that I found with Xprog2. [26:17.480 --> 26:18.440] Yeah. [26:23.500 --> 26:25.180] Unfortunately, yes. If you are [26:25.180 --> 26:27.160] the application layer, they will play with some of those [26:27.980 --> 26:29.280] parameters as well. [26:32.660 --> 26:33.960] Xprog2 basically uses [26:34.600 --> 26:36.940] less packets than any other OS fingerprinting tool. [26:36.940 --> 26:39.680] Well, we at least try to. It does not [26:39.680 --> 26:41.800] disturb the operation of the target system. [26:42.300 --> 26:45.240] You can control whatever models you would like to use. And of course, [26:45.860 --> 26:48.320] at the end of the day, if you use it in the lab against [26:48.320 --> 26:51.480] whatever you put there, you'll see that it will give you more accurate results [26:51.480 --> 26:53.340] than any other tool. [26:54.340 --> 26:56.800] I'll skip this slide. Basically, what we did [26:56.800 --> 26:58.320] along the four years. [27:00.220 --> 27:02.960] The different software models that we have there. [27:03.080 --> 27:05.820] Basically, we have some discovery models, [27:05.820 --> 27:08.820] some information gathering models, and some [27:09.720 --> 27:11.760] OS detection models, of course. [27:14.380 --> 27:17.660] The tool has a very extensive command line options, [27:17.660 --> 27:21.520] which I will not go into, because you didn't come for this now. [27:21.520 --> 27:24.700] The tool is able to detect if there are obstacles [27:24.700 --> 27:27.640] between the tool and the target system. [27:27.640 --> 27:30.580] So, for example, if you have a proxy between you and the target system, [27:30.580 --> 27:32.160] it is able to detect that. [27:33.220 --> 27:35.740] And other gizmos that I will go through. [27:36.540 --> 27:39.460] So, very fast, discovery models basically are designed [27:39.460 --> 27:41.060] to perform host detection. [27:41.700 --> 27:45.580] Their aim is not only to see that the host is alive, [27:45.580 --> 27:48.920] but also to aid the automatic [27:48.920 --> 27:52.060] receive timeout mechanism in understanding [27:52.060 --> 27:54.760] what is the timeout that needs to be automatically selected for [27:54.760 --> 27:57.700] the target host. This is important because when you [27:57.700 --> 28:02.300] are scanning something, you don't want to timeout too fast on that one. [28:03.000 --> 28:04.380] There is also a port scanner [28:04.380 --> 28:06.980] with the tool. You can specify [28:06.980 --> 28:09.760] ports to be scanned, either capital T or [28:09.760 --> 28:13.660] capital U for UDP and TCP, respectively. [28:13.760 --> 28:15.960] There are some examples for that. [28:15.960 --> 28:19.040] So you get a list with any other tool [28:19.040 --> 28:21.900] of the open ports, closed ports and filtered ports. [28:23.320 --> 28:25.120] So, if you want perfect [28:25.120 --> 28:28.140] results, you need to have an open TCP [28:28.140 --> 28:31.340] port, a closed TCP port, a closed UDP port [28:31.340 --> 28:34.200] and either receive replies [28:34.200 --> 28:37.280] for echo request, timestamp request [28:37.280 --> 28:38.600] and address request. [28:40.180 --> 28:43.060] Before this version, we introduced another [28:43.060 --> 28:45.780] OS fingerprinting model called ResetAct. Basically [28:45.780 --> 28:48.520] what we do there is we send two [28:49.140 --> 28:52.220] scenes to a closed port and we compare them. [28:52.220 --> 28:55.040] That test actually allowed us to differentiate [28:55.040 --> 28:58.060] between the different groups of the Linux [28:58.060 --> 29:01.140] kernels and we can actually divide them into [29:01.780 --> 29:03.340] seven groups. [29:03.780 --> 29:06.560] This is a very useful tool if you need to [29:07.460 --> 29:10.120] have the understanding if this is a 2.4 [29:10.120 --> 29:12.620] based kernel or a 2.6 based kernel and also go [29:12.620 --> 29:15.820] inside those families of kernels and have [29:15.820 --> 29:18.560] some information there. [29:19.260 --> 29:22.020] Some other useful command line options [29:22.020 --> 29:24.260] by default, if you run xprog2 with [29:24.260 --> 29:27.760] "-v and "-b", it automatically will try to enumerate [29:27.760 --> 29:30.760] several ports, so you don't need to [29:31.540 --> 29:33.360] specify a port scan, you just do [29:34.080 --> 29:36.720] lower v, uppercase B and the IP address. [29:36.720 --> 29:39.600] You are also able to automatically generate signatures [29:40.920 --> 29:42.980] using the capital F command line [29:42.980 --> 29:45.380] and you can save the information using the [29:45.380 --> 29:48.740] "-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 --> 29:55.420] The version that [29:55.420 --> 29:57.900] we are releasing today is available [29:57.900 --> 30:00.380] for download, you can either go to my website or [30:00.380 --> 30:03.000] directly go to our page at [30:05.720 --> 30:06.920] sourceforge.org. [30:06.920 --> 30:07.940] Basically what we have [30:08.760 --> 30:12.040] is we have two new application-based [30:12.040 --> 30:14.200] OS fingerprinting models inserted to the tool [30:14.200 --> 30:17.160] in order to help the tool operate better [30:17.960 --> 30:20.480] 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:27.440] The first app-based [30:27.440 --> 30:29.440] OS fingerprint model that we have entered [30:29.440 --> 30:32.720] and it's not something new, but it's good to have in a tool. [30:32.980 --> 30:35.340] It's an SMB-based model, basically very good [30:35.340 --> 30:38.440] against Microsoft Windows-based machines that have [30:38.440 --> 30:40.800] their file and print sharing working. [30:41.380 --> 30:44.440] It basically retrieves the native OS [30:44.440 --> 30:46.140] and native Lundman parameters [30:47.140 --> 30:51.260] from the SMB session setup and NX replies. [30:51.700 --> 30:53.620] And it helps us differentiate between [30:53.620 --> 30:56.320] different Windows OSes such as [30:56.320 --> 30:59.140] Windows XP in 2003 between several [30:59.140 --> 31:02.320] problems that we have between 2000 and XP. [31:02.320 --> 31:05.380] And basically it allows us granularity when it comes to [31:05.380 --> 31:08.140] Windows operating systems. So we have different [31:08.140 --> 31:11.500] you have new keywords that you specify the information there [31:11.500 --> 31:14.440] called SMB underscore Lundman and SMB underscore [31:14.440 --> 31:16.960] native OS. You put the information there [31:16.960 --> 31:19.780] it all works. This is an example [31:21.540 --> 31:23.400] not using the SMB [31:23.400 --> 31:25.760] model at the end of the day what you see is the results [31:26.400 --> 31:29.280] are all mixed up. XP with 2000 and we [31:29.280 --> 31:31.620] can't see really the differentiation. [31:33.100 --> 31:35.480] This model works automatically when you tell the [31:35.480 --> 31:38.260] model to use port 139 when you port scan [31:38.260 --> 31:41.060] port 139. So you specify the minus T [31:41.700 --> 31:44.400] 139 with the command line. It's [31:44.400 --> 31:47.340] automatically executed and at the end of the day the results are [31:47.340 --> 31:50.340] Windows 2000 because this is a Windows 2000 service pack [31:50.340 --> 31:53.300] for a machine. Another model [31:53.300 --> 31:56.360] that we have inserted is SNMP based [31:56.360 --> 31:59.140] model. Mostly it's good when [31:59.140 --> 32:01.380] it is used against [32:02.440 --> 32:05.460] well, those elements that use SNMP but also [32:05.460 --> 32:08.480] when you have certain kind of [32:08.480 --> 32:11.360] an element which is a hardware based and you want to [32:11.360 --> 32:13.680] extract that information in order to help you [32:14.270 --> 32:17.440] detect what's the underlying operating system. [32:17.440 --> 32:20.140] SNMP based model. Currently only SNMP v2 is [32:20.140 --> 32:22.440] being supported but the next version will have v1 and v3 [32:22.440 --> 32:24.840] as well. And it needs to have [32:24.840 --> 32:29.260] UDP port 161 open in order to operate. [32:29.260 --> 32:31.280] So this is an example with [32:31.280 --> 32:34.620] FreeBSD 5.3. You can see if you can [32:34.620 --> 32:39.660] look at it actually, that the SNMP [32:39.660 --> 32:40.560] community stream was public. [32:40.560 --> 32:43.800] There you can look at the export2.conf [32:43.800 --> 32:46.440] and specify there and what the information was [32:46.440 --> 32:49.000] extracted from the FreeBSD 5.3 [32:49.400 --> 32:52.500] based machine. You can see that this actually contributed [32:52.500 --> 32:54.900] to the fact that we got FreeBSD 5.3 [32:55.660 --> 32:58.640] with 100% and the other FreeBSDs [32:58.640 --> 33:00.720] with less percentage than that. [33:01.440 --> 33:04.740] We have also new signatures for [33:04.740 --> 33:07.540] 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:13.740] We have updated the signatures for Linux, FreeBSD and OpenBSD [33:13.740 --> 33:17.060] and we also have fixed several bug fixes that we have with the tool. [33:20.120 --> 33:22.640] And we would like to take the tool to [33:23.300 --> 33:25.880] a different level by automating the scans, [33:25.880 --> 33:28.320] by understanding the Terran, but [33:28.320 --> 33:31.280] I guess it will take us a bit of time to do that. [33:31.800 --> 33:34.040] Questions? Yes. [33:34.820 --> 33:41.460] If you use SMB and SNMP [33:41.460 --> 33:43.760] and you do port scan, you are not stealth. [33:45.520 --> 33:47.540] Any IDS, IPS or [33:48.100 --> 33:50.240] anything that will look for these kind of parameters [33:50.240 --> 33:51.720] will pick you up easily. [33:52.900 --> 33:55.860] That's the problem as well. If you are not [33:56.420 --> 33:58.780] having the information prior, then [33:59.860 --> 34:01.720] you cannot really be stealth. [34:03.040 --> 34:04.080] Yes. [34:11.110 --> 34:12.790] Any test actually [34:12.790 --> 34:15.890] has its own weight inside [34:15.890 --> 34:19.110] the BigPi of OS fingerprinting [34:19.110 --> 34:22.450] tests. Each parameter has its own weight as well. [34:22.450 --> 34:24.890] So if one of them is not being matched [34:24.890 --> 34:27.930] or there is a problem matching that parameter [34:27.930 --> 34:30.230] with the signature database, that will take [34:30.230 --> 34:33.590] the percentage of hit [34:33.590 --> 34:36.530] to be less than 100%. [34:36.530 --> 34:39.990] One other thing that I want to mention, [34:39.990 --> 34:41.330] this is a project that [34:42.510 --> 34:46.470] my fellow co-authors are doing. [34:46.470 --> 34:48.470] It's called STIF. It stands for [34:48.470 --> 34:51.630] Security Tools Integration Framework. [34:51.630 --> 34:54.730] It basically is a platform to automate [34:54.730 --> 34:57.430] security analysis. You can check [34:59.250 --> 35:00.530] that project [35:00.530 --> 35:03.330] with the URL that is being [35:03.870 --> 35:06.330] shown at the bottom. It's a very cool project. [35:06.330 --> 35:09.410] Very cool guys. 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.