 I'm sorry about the slight delay. My name is Ophio Arkin, and during this talk, I'll be releasing Expert 2, version of that three. Prior to that, I'll be talking about several aspects of doing active OS fingerprinting. Basically, we're gonna discuss the problems that are usually associated with active OS fingerprinting. We'll see how we can remedy that. A bit about myself, the founder of the security group, also founder of Encytics, I'm just a technical officer there. I've done some research about infrastructure discovery versus AP security and OS detection. And I'm also a member of the OS security alliance. So, what is OS detection? OS detection is basically the process of trying to determine what is the underlying operating system of a certain remote element. Traditional approach will send some packets, we'll examine the stack behavior, usually with IP, UDP, TCP, and ICMP in order to draw some conclusions about that underlying OS. 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. Just because the traditional approach is to use TCP-IP stack-based fingerprinting, usually limited to those protocol I have mentioned, it doesn't say, it doesn't mean that we cannot use the application layer also to provide us with information about the OS. There are several tools out there that does active OS fingerprinting. NMAP, for example, is a good tool doing that. Xbox Two and others. Basically these tools varies with the way of operation usually because of the different tests they're using. Basically the packets they're sending to the target host trying to enumerate the operating system, the number of packets they're sending the way of operation. Why is that important for us to identify the underlying operating system? Well, I guess that for each and one of us is something different. Some needs 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. If we go and look at the strength of doing your remote active OS fingerprinting, then one of the things that is the most important is that we can control everything. We can control what parameters that we would like to scan. We can control the speed that we perform the scan, the initiation of the scan, the time of the initiation. Usually such a tool will provide with fast results if there are no obstacles on the way. And of course it can also cover entire IP ranges. Several companies use this kind of tools. They might scan from one single point to multiple. This is where the tool is installed on one element on the network and scans multiple. And there are some other implementations where a scanning tool will be installed on different parts of the network and will scan from their other parts of the network. That's basically it. These are all the strengths. There are a lot of weaknesses. The weaknesses go into different categories. 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. So let's start by looking at the scanning conditions and the environment attack and the environment effects. Basically when we perform an OS detection or basically any other scan, we do not control the quality of the scan. We cannot control over anything basically. Whatever is between us to the target may determine what we're going to get back. So probably most of you know this. If you scan an element on a local network, this is one thing. You scan an element that is on the internet, that is something else. And basically those locations of the target systems will determine what you're getting. It's most likely that when you scan an element that is on your local network, you'll get better results. When you scan an element that is on the internet, you'll get, well, sometimes nothing. And also the path between the scanning element to the target also determines what we will be getting. The problem currently is that we do not have any kind of intelligence about what do we have between us to the target. There is currently no tool that is gonna tell us, okay, there's a file here, a proxy between us to the target, or something else that prevents us or changed the way either our packet or the returning packet had arrived to us. In order to have good results with any OS fingerprinting tool, we 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, meaning it will be up. 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. So just a quick example, if the scanning machine scans 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. This is also true if you have personal firewall and install on the machine, that will prevent OS detection from working. You'll never get any active OS detection works working like that. Another example is that if some of you, not hinting, sits at home and wants to scan a www.companythatyoulike.com, and that company that you like.com has load balancers in front of its web servers. Well, the initial approach of voice fingerprinting will not work here. Some of those load balancers will answer themselves to the probe, 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. So basically, the results 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. Sometimes when we send packets through the target, there is something along the way, like a scrubber, a firewall. I don't know how many of you are familiar with Tech Point firewall, but that firewall can scrub several fields inside a packet that comes back. And those kind of alterations will prevent us from determining what is the underlying OS there. Sometimes if a tool uses Malforn packets, those packets will also be dropped by an intrusion prevention system or other system that checks for the legitimacy of the packet. So some examples would include some weird TCP-IP flight combinations, like SYNFIN, CNERESET. Those will never go through an IPS and never be able to reach the target. So of course, the tool that you are using is using crafted packets and it's sending crafted packets throughout the internet. Then that tool will not be able to provide with good results. The other problem that we have there is that sometimes those Malforn packets may have another hidden effect that might cause some TCP-IP stacks to crash, especially when those stacks doesn't need to do too many things, especially we can name printers. We can name print servers and things like that. And of course, there are some other smart people out there that want to obscure the way that their operating system works. So they change the characteristics of the TCP-IP stack behavior by altering some kernel parameters, tunable kernel parameters. So if you are familiar with several commands, with the for example, the CCTL command and the NDD command on SON, then you are able to tune the parameters also. On Linux, it's very easy to perform these kind of things. So let's go into some signature-based related issue. The signature database is the most important piece of any OS detection tool. If the signature database will be corrupted, if the signatures will not be inserted to see 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, still the results that the tool will be performing will be poor. This is a traditional argue between those who strictly control their signature database to those who allow people to submit signatures for their tool. My approach is that if I want to insert signature, I want it to work in most cases, I won't insert a signature that someone sent me off a firewall device because there is no use of it as music. So basically my approach takes it to the extreme, basically that I need to go and I need to see the device, I need to verify the OS, I need to verify in some cases what it is actually running. The lab environment is the best way to do this and therefore when you enter the signature in question to the signature database, it can work in most of the cases. Some of the other tools that are out there simply would say, okay, there's 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 and you try to run a certain test and at the end of the day, what you get is a mixed results that never comes close to the reality. So we can strictly control the process of inserting signatures into the database. Sure, it has its downside, it's a slower process, 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 and the one plus of it is that it is extremely accurate. On the other end, if we do not control the signature database, then signatures are inserted because they are there. The creation process is not controlled. If those signatures are created in the wrongfully manner, then we have a corrupted database and a controlled one, which is extremely inaccurate. When we do all this fingerprinting, we fingerprint the way that the software reacts to the probes that we send. When we fingerprint the hardware-based device, basically we fingerprint the way the firmware actually answers us 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 form the same manufacturers, most of them will run the either the same firmware or a slightly different firmware. Usually it depends either on their role or the manufacturer decides that he wants one firmware to roll. So there are a few examples with that. Cisco 7200 will be fingerprinting as 2950 as the switch 2950 as a 6500 running iOS and even as the Aeronauts wireless access points. Why? Because they are all running iOS and with traditional TCP and P-based stack fingerprinting we're not able to tell the difference of their roles. Oh, there are other nice examples, foundry networks usually around 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 slightly different firmware, depends on the year and the updates. But unfortunately, some most fingerprinting tools don't take this into account and at the end of the day, it also brings them to the for having a corrupted database when you do fingerprinting of HP what you get is not that this is an HP printer, that it might be a home printer, corporate printer or whatever else printer and other things, but at the end of the day, that's the firmware, not the model. 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. 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. If we do not control what is inside the database, then we're unable to update that. 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. And of course, there is one other small issue which is political issue. 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. There is 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's actually being used, then you don't want your work to be stolen as well. This 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 the entire signature database into those tools because they know that people would just go download the signature database, enjoy what they have done and basically don't pay them anything. There are some issues that relates to the way the OS fingerprinting tool actually works. Scan results needs to be matched with the signature database. There are actually two ways of doing that. Actually, they can be more. 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 even if some of those tests had failed. So these are the two approaches that we have. Another problem is that Stex looks alike with new release operating systems and there are only n number of tests and number of parameters that we can look for. So theoretically, somewhere along the line, the number of possible matches should be reached. 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. So what we need to have is the ability of a tool to have fingerprinting tests that has multiple parameters inside of them that they represent different OSs in different, many parameters are different among the TCPIP stack and that allows us to receive better overall results. Another problem that we have is that 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. For example, if we will not receive CNAC response for a CN request to an open port or we'll not get this kind of response at all, or we'll not receive port and reachable for UDP packet, then basically the way that we'll have results basically will not have too much. I've touched this slightly beforehand. This is the problem of having slight differences between the TCPIP stacks of newly released operating systems to another one. XPSP2, for example, and Windows 2003 share the same characteristics of the stack. So does Windows 2000 and XP with no SP and SP1. And so does some Linux kernels share the same characteristics. This actually brings us to the point that we cannot have granular results. 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. 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. 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. When we're using a tool, we would like to have the maximum flexibility with the tool. We would like to have the ability to control what models it is using. So if we know that we operate against a web server, we're not gonna use tests that we assume that will be dropped or not be answered. So an active OS fingerprinting tool needs to have all of these models controlled and has to allow the user to specify exactly which models you want to use and what types of brackets you want to send to the host. Another problem, and this is the last of the row, is that sometimes active OS fingerprinting tools will pose in an out of service condition to those elements they're scanning. 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 and that will cause the element to crash or just drop packets. I have a Kairos Aramida FS-1900 printer in my office. If I scan it, we then map the printer crashes to the point that they have to go and I have to power off the printer and power it on. So the summary for this is that we need to understand the terrain, we need to understand what we're scanning, we need to understand what's between us to the target. 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. 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 the well-fortified elements sitting behind different kind of security mechanisms. There are some other approaches that came and say, 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 drew conclusions about what we see. So there are some researches. If you heard about the tool called TBIT, basically they look for the current state of TCP-IP implementation or TCP implementations on web servers. So they took the tool and say, 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's actually doesn't do anything because they're still at the point with which the Windows operating system as a group will be identified. 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. So if we look at the needed solution, then we need intelligence in scanning. We need to understand it there and that we operate against. And we need the active OS fingerprinting tool to understand the quality of perceived results in order to react to the received results with proper targeted OS detection tools. 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. Something along the lines of, you can't see this because it's all screwed. Something along the lines of, we send several packets, we analyze what we've received back, we see which ports have opened, what services, or what type of family of operating system we are 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. Question until this point. Okay. So for the past four years, I've been one of the developers of X-Probe Tool, which is an active OS fingerprinting tool, open source, remote active OS fingerprinting tool that you can use. I mean, if you like it, you use it. If you don't, you don't. The project represents our take, our beliefs, and basically it's our fun to create it. If you use it, great. If not, again, it's your choice. It was voted one of the top 75 network security tools. It replaced that map as the OS detection engine for a Nessus, after if you're familiar with Nessus, Nessus uses SMB, NTP, and then it will use the OS fingerprinting test that are found with X-Probe Tool. Yeah. Unfortunately, if you are at the application layer, they will play with some of those parameters as well. X-Probe Tool basically uses less packets than any other OS fingerprinting tool. Well, we at least try to. It does not disturb the operation of the target system. You can control whatever models you would like to use. And of course, at the end of the day, if you use it in the lab against whatever you'll put there, you'll see that it will give you more accurate results than any other tool. I'll skip this slide, basically, what we did along the four years. The different software models that we have there, basically, we have some discovery models, some information gathering models, and some OS detection models, of course. The tool has a very extensive command line options, which I will not go into, because you didn't come for this now. The tool is able to detect if there are obstacles between the tool and a target system. So for example, you have to have a proxy between you and the target system. It is able to detect that. And other gizmos that I'll go through. So very fast, discovery models basically are designed to perform host detection. Their aim is to, 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. This is important because when you're scanning something, you don't want to timeout too fast on that one. There's also a port scanner with the tool. You can specify ports to be scanned. The user either capital T or capital U for UDP and TCP, respectively, there are some examples for that. So you get a list with any other tool of the open ports, closed ports, and filtered ports. So if you want perfect results, you need to have an open TCP port, a closed TCP port, includes UDP port, and either receive replies for echo request, timestamp request, and address request request. Before this version, we introduced another OS fingerprinting model called Reset Act. Basically what we do there is we send two scenes to a closed port and we compare them. That test actually allowed us to differentiate between the different groups of the Linux kernels, and we can actually divide them into, what's that, seven groups. This is a very useful tool, you need to have the understanding if this is a 2.4-based kernel or 2.6-based kernel, and also go inside those families of kernels and have some information there. Some other useful command line options by default, if you're on X-Probe Tube with minus V and minus 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. You're also able to automatically generate signatures using the capital F command line, and you can save the information using the minus O command line. Okay, that you can do yourself at home, you can play with it. The version that we are releasing today is available for download. You can either go to my website or you can directly go to our page at SourceForge. 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, bless ya, in different scanning conditions. We also have new signatures and we also have several bug fixes. The first app-based OS fingerprinting model that we have entered, and it's not something new, but it's good to have in a tool. It's an SMB-based model, basically very good against Microsoft Windows-based machines that have their file and print sharing working. It basically retrieves the native OS and native LUNMAN parameters from the SMB session setup in NX Replies, 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, and basically it allows us granularity when it comes to Windows operating systems. So we have different, you have new keywords that you specify the information there called smb-underscore-LUNMAN and smb-underscore-native-OS. You put the information there, it all works. This is an example, too. Not using the SMB model at the end of the day, what you see is the results are all mixed up, XP with 2000, and we can't see really the differentiation. This model works automatically when you tell the model to use port 139, when you port scan port 139, so you specify the minus T139 with the command line. It's automatically executed, and at the end of the day, the results are Windows 2000, because this is a Windows 2000 service spec for this machine. Another model that we have inserted is a SNMP-based model. Mostly it's good when it is used against, well, those elements that use SNMP, but also when you have a 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. Currently only SNMP v2 is being supported, but an X version will have v1 and v3 as well. And it needs to have UDP port 161 open in order to operate. So this is an example with FreeBSD-53. You can see, if you can look at it actually, that the SNMP community string was public. There you can look at the export to.conf and specify there, and what the information was extracted from the FreeBSD-503-based machine. You can see that this actually contributed to the fact that we got FreeBSD-53 with 100% and the other FreeBSDs with less percentage than that. We have also new signatures for the different Apple Mac OS X. We have missed those signatures for quite a long time. We have updated the signatures for Linux FreeBSD and OpenBSD, and we also have fixed several bug fixes we have with the tool. And we would like to take the tool to a different level by automating the scans, by understanding the terrain, but I guess it'll take us a bit of time to do that. Questions? Yes. If you use SMB and SNMP and you do port scan, you're not stealth. Any IDS, IPS or anything that will look for these kind of parameters will pick you up easily. That's the problem as well. If you're not having the information prior, then you cannot really be stealth. Yes. Any test actually have its own weight inside the big pie of OS fingerprinting tests. Each parameter has its own weight as well, 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%. One other thing that I want to mention, this is a project that my fellow co-authors are doing. It's called STIF, stands for Security Tools Integration Framework, which basically is a platform to automate security analysis. You can check that project with the URL that is being shown at the bottom. It's a very cool project, very cool guys. You should check their project as well. Other questions? Thank you for having me today and enjoy the conference.