 my talk to the memory of our true explorers and I think that the picture speaks for itself. The source code for the new version of X-Probe 2 is available from the security website. This presentation would also be available early next week and there is also a white paper that you can download basically outlines in great details the work that we have done and the things that we have implemented for X-Probe 2 O2RC1. Well, currently I am the CIS of International Telephone Carrier. I do computer security research on my own spare time. If you remember the Etherleak paper about the friend-bedding information leakage. This is a paper I wrote along with Josh Anderson. I also published several papers on IP telephony security and other papers. I'm also a member of the high-end project. The X-Probe 2 project is an open-source project which has three developers myself, Fyodor Erichkin, which is the other Fyodor, if you didn't know, Meteor, Kidri Alev, two Russians and one Israeli living in on basically three different time zones, which is kind of interesting. What is X-Probe 2? I bet that some of you know. It's a remote active operating system fingerprinting tool. It is an alternative to other fingerprinting tools and it was voted by several of you, I guess, as one of the top 75 security tools and it was actually was among the top 50. Why it's so important to use active OS fingerprinting tools and where can we use them or the information they produce? There are several examples illustrated here. First of all, we need the context. We need the context for IDS systems. We need the context for vulnerability assessment tools and most of us need to build an equity inventory. These kind of tools help tremendously in doing these kind of tasks and of course there are some other individuals who use the tools for other usage scenarios, I guess. X-Probe 2 project basically, as I said before, is an open source project. It reflects its developers' beliefs and ideas. We do hope it contributes to the community at large, to the security community at large and we do encourage people to contribute to the project. We know that several companies and individuals were inspired by X-Probe 2 so they decided to lift off or lift some techniques and technologies from it but they don't even bother to credit us. First version of X-Probe 2 was released two years ago at Black Hat in 2001, June 2001. It was only a mission statement, relying only on several ICMP-based fingerprinting methods that I've researched. It was a static decision tree, as I said before, nothing much. It was a mission statement, a working mission statement. Last year at DEF CON 10 we have released a newer version of X-Probe 2 which had several enhancements. We were the first open source tool to implement fuzzy logic. Fuzzy logic is a matching algorithm between the probe results we received from targeted operating systems and the signature database that we have. Again, X-Probe 2.0.2 was relying on ICMP-based fingerprinting tests only. Last act real, we have released O.1 release. It's really hard when you work with software engineers to bump up the versions. I was like, cool, so we can release a DEF CON 1.0. They were like, well, you know what, O.2 RC1 is good enough. O.1 release sends RC-compliant packets. There is no more X-Probe 2 in the payload. We went through a lot of bug fixes. We added a lot of signatures. And we also support the IPID equals sent fingerprinting method, which if you want to learn about, is outlined on my website. X-Probe 2.0.2 RC1 was released yesterday, as well as the white paper. This part of the presentation will go quickly through several issues with active operating system fingerprinting. If some of you or have any question, please raise your hand and I will stop and answer the question. When we do fingerprinting and we do operating system fingerprinting, we fingerprint the way the operating system has the software reacts to the problems that we send. When we fingerprint a hardware-based device, we fingerprint the way the device's firmware acts to the different fingerprinting tests. This is something that not a lot of people actually understand. And what they're doing is they fingerprint or put on the signature database the brand of the device that was fingerprinted. For example, if we'll try to fingerprint a Cisco 7200-based router and a Cisco Aeronet 1100 or 1200 wireless access point, guess what, both using iOS, so they both will be identified the same. If you don't understand how to build your signatures, then at the end of the day, the signatures that you will put inside your signature database will not give you that much of information. For example, another example is Foundry Network's NetFastPig iron family. Basically, they all use the same software version, so it doesn't really matter which Foundry Network's device you are fingerprinting. At the end of the day, what you're doing is you fingerprint the firmware version, you fingerprint the software, and that's what's really important. So if the tool you guys are using has a database which, well, did put signatures according to the brand, I guess the results that you will get will be, well, maybe not accurate, but will not give you enough information for you to understand. If your tool of choice is using a strict signature matching, then if it will not find a hundred percent match between the received results and the signature database, it will not produce any kind of results. It will be extremely sensitive to different environmental effects on the probe target and on the packets that are sent to the target. As I said before, we decided to implement FuzzyLogic, which gives us the opportunity to overcome several difficulties in the process of actively scanning a host and actively determining the OS. Another interesting angle is the use of a fixed number of fingerprinting tests. In theory, if we have a fixed number of fingerprinting tests and we have a fixed number of parameters that we examine, and of course they have a fixed number of permutations, then the possible matches will be a fixed number as well. Sure, the possible matches still has a larger number than the networking devices that are out there, but there are several test cases or test models that will fail to provide us with so much needed results. Basically, what they will create is a certain group of operating systems as a result, as the best effort result, and will not be able to give you a certain operating system as one result only or two operating systems as a final result. This also means that if you want to have a better tool for active voice fingerprinting, you should use a lot of fingerprinting tests that will examine many parameter values. It should be a test that the parameter values should be different among many operating systems that you are going to test. We were going through a phase of trying to determine which other fingerprinting models do we need, and some of the fingerprinting models that we examined simply did not give us the expected results. I remember one of them just allowing us to isolate one operating system only, and it wasn't Microsoft's own. It wasn't really something that we thought that it should be implemented that would give us a certain answer or a definite answer about one group of operating systems. The use of a certain fingerprinting niche is a problem as well. If we are looking at, for example, X-Probe 2 via 1, then we are using with that particular version of the tool only ICMP-based fingerprinting tests. It means that on some tests we will fail to provide the much expected result, meaning that we'll be able to tell that this is a Sun Solaris box, but we will not be able to say which version of Solaris is the exact version on the machine. If you use NMAP, for example, using most of its TCP-based fingerprinting tests, there are several groups that you cannot differentiate between merely XP-2000 and ME comes as one group and the other Microsoft-based operating systems comes as another. If you take that into consideration and add to that the fact that newly released operating systems do not nearly change the way their TCP-IP stack is being built, then at the end of the day these tools like NMAP or X-Probe 2 via 1 will not be able to differentiate between newly released operating systems of the same manufacturer. Usually the changes that we can see in the stack would be very little, usually only in one protocol's behavior and if you're not testing for that protocol then you will not be able to differentiate between the new version of the operating system from an old one. This is an example, as I told you before, you can see here a round of XP-2000 via 1 against the Sun Solaris 8-based machine. You can see that the results that we have received, basically, the entire Sino-S based operating systems. This is an NMAP round against an NT-4 based machine, SP6A. You can see that we got a lot of other Microsoft-based operating system with the results. Another interesting angle to active operating system fingerprinting which is turning to be a very major issue for all of us, especially in a big corporate network, is the ability to determine the exact software service spec which is installed on a certain operating system. Really the traditional tools will be unable to uncover the exact service spec installed on a certain operating, on a certain box. We'll be able to tell that the machine is a Windows 2K server, but the exact service spec will not be detected. Several other issues include tests that may have bigger impact on the overall results. If they're going to fail, if you will be unable to execute them for some reason, you will be affecting the overall accuracy of the tool, of the result that you will receive, and the much effect that you would have expected. Otherwise, from that particular test will not be actually in effect. This is an example with the Export 2 running all of its fingerprinting models. You can see that the testing question here is Microsoft Windows XP Pro SP1, but you can see that we got the 2000 as well as the answer. If we omit the ICMP Echo fingerprinting test, we can see that the Microsoft Windows ME based machine is now given to us as a result as well. That's because the ICMP Echo fingerprinting test is being used to not only differentiate between Microsoft based operating systems to the rest of the operating system world, but also to differentiate between the Microsoft ME and the Microsoft 2000 and XP families. Sometimes, especially on the Internet, if we are probing a website or some machine, there might be several effects on the packets that we send. For example, on our local network, we might have different VLANs, and several VLANs might have a better quality of service. It means that when we send a packet, our switch will put a value in the type of service field and send it out. Some firewalls are able to change several field values. For example, Checkpoint NG with application intelligent can overwrite the time to leave field value and can do other little things. Basically, when you're scanning, especially on a hostile environment or against a hostile environment, your packets may get to the target a little bit different. That's also hold through when you hit proxies or load balancers. Of course, you don't expect systems to be opened and let you just scan them. A lot of systems are being firewalled and we expect them to be firewalled. When you scan or use several tests that use some weird combinations like, for example, if you use a SYNFIN scan against a Checkpoint firewall or other firewalls that are able to do stateful inspection, your packet is not going to go through the firewall. This also brings another angle to it that if you are using an OS fingerprinting tool, some of the fingerprinting tools must be legit. It means that when you will initiate the tool and you will send it away, you want to be able to go through the firewall that is guarding the target and to be able to receive the reply. And of course, several system admins, especially on a small shop, go and change several behavior on the different aborting systems they installed. There is the NDD command on the CCTL on a different BSDs. There are the registry hacks on the different Microsoft boxes. For example, several people like to change the window size of the box, if the box is being served as a web server and such and such. If you are relying on this kind of test and the particular values were changed and altered by the system admin of that box, of that corporate that you are scanning, then of course you will get problematic results that will be affected from this thing. Another very important issue and I think that even if your tool or the tool you are using is very nice, has this great functionality and at the end of the day, the signature database is corrupt, then there is absolutely nothing that can help the tool. It is extremely important to get the fingerprints out of a lab environment to get them right the first time and then it will save you the hassles of thinking, well, what were the exact environment that a certain test that was submitted was performed against? I think that if you do not allow a tight control on the signature database, then at the end of the day what you will have is a lot of signatures that not only you will not be able to trust, but also your users of the tool will not be able to trust. That is a very problematic issue when you want to propagate the signature database. If you want people to submit signatures and have a larger database of signatures, at the end of the day if you cannot trust the signatures that the users are being producing or you will introduce some lame signatures into the signature database and basically the signature database will be corrupt. There is an example with the end map with the TCP options, end of line basically should be on the end of the TCP option list. There are several signatures there with the end of line in the middle of the option list for TCP. Another important problem, especially for vulnerability assessment tools, is the inability to identify the underlying platform of the operating system. If you want to explore a certain operating system and it has multiple platforms it can be installed on, it is extremely important for one to understand what is the underlying platform because your exploit may or may not work on the platform you are targeting. So for example if you are running a certain vulnerability assessment tool and that tool is relying on a certain active OS fingerprinting tool and the platform is not being given then first of all the vulnerability assessment process will be longer and it might be giving you false results. On a large network when you want to scan for example class B networks it is very important to understand what is the limit of the network. It is important to understand that if you will use too many packets per second or too many packets in a certain amount of time, not only the networking devices on your network can suffer from a denial of service condition but also the target operating systems that you are scanning. So it is important for such an active operating system fingerprinting tool to have the ability to scan large network and still do not put those network under a denial of service condition. One of the issues that we have talked about for the past two years is the ability to control whatever fingerprinting models to use or the ability to control whatever option a tool has. We have actually implemented that with the newer version of the tool. Sometimes you are on a different situation for example targeting a certain topology from a certain topology and you can only use certain fingerprinting models. For example if you target the websites it is more likely that port 80 will be open and port 443 will be open rather than the ability to send a time stamp or a netmask request to that website. So instead of triggering too many alarms if they are there or if you care about them then you can just use the different models you know that will work and just spare you the lack of the added value of the other models. Another thing that you would like to have is the ability to switch scanning tactics. If you know that a certain tactic you are using will be blocked by a firewall or by another device guarding the operating system or the box that you are scanning you will like the tool to have the ability to affect the other parts of the scanning or to switch the tactics. If I know that I am scanning a website it is much more likely that again port 80 and port 443 will be open so I would like to direct my tool or whatever tool I am using to use those ports and if I know that all the UDP ports will be covered then why initiating at the first place the models that use UDP. So we have decided on adding several functionalities to export too. We have added several new discovery models. We added the ability to totally control the tools, models operation. We added more finger printing models. We have now a port scanner. We also have an automatic mechanism to assess the received timeouts for the different models and we have also rebuilt our database of signatures from scratch. We use discovery models for several things. First of all we use them as hosted for host detection. We use them for firewall detection and we use them to provide information for the automatic receive timeout mechanism that we have. I will talk about it in a couple minutes. We have added two new discovery models things that you already are familiar with basically TCP ping and UDP ping what we did here or what we sent. We sent a packet, a syn packet to the target host who we expect to receive a syn act or a reset or no answer at all. And when you send the UDP packet you either get no answer or get the ICMP port unreachable back. We have added actually using our minus lower P command line option where one can specify which ports to use with the different models. These two new models will not run by default if the minus P option will not be specified. Again, they are being used also for automatic receive timeout calculation if you did not know. When you prob the host the TCP answers and the UDP answers that you will get from that host will be much slower than the answer you will get for ICMP. If you scan for example on a local network your favorite Microsoft based machine then just specify an open TCP port just get one of the most likely to be open and use the TCP discovery model. That model will help you after with the automatic receive timeout calculation. Since we did want to allow the users of the tool to have a complete control over the tool we have added two command line options to control which models to use. First the uppercase D command line option which control which models not to use and the minus M command line options which one can use in order to specify the models to use. If you look at the diagram here you can see the different models that the tool has and their execution order. As I said before the TCP ping the UDP ping and the port scanner will not be executed by default all the other models will. Not a lot of people do use our TTL distance information gathering model it actually can do trace routes if you are interested in that. The first example is for the usage of the minus D command line option. For those of you who are afraid that they will not see live examples I have targeted several sites in France for the demo. I love them. Here you can see that I have specified a numeric value as well as the finger printing model name for the minus D command line option. You can use whatever you like. If you like numbers if you like to use the model name whatever and here we have targeted the Microsoft Windows 2000 SP3 base machine and yes we can uniquely identify 2000 SP3 as well as 2000 SP4. The second example is for the usage of the minus M command line option. Here we have used only three models the ICMP echo discovery model the ICMP echo finger printing model and the ICMP port unreachable finger printing model. You can see that the tool got 100% success of identifying the Cisco 11.2 software that we were finger printing. Since we have a lot of command line options now to allow you to totally control whatever you are doing with the tool I was thinking that it's good to tell you how you list them. If you want to list the different models that we are using and the different options and what they can do for you you can use the upper case L command line which is the different finger printing and other models the tool has and will show you the different switches that you can use as the command line options. There is another command line option which I don't show an example for the lower case M command line option which you can specify which or the number of matches to print. Not a lot of people like to have ten lines of scan so you can specify whatever you like here as well. One of the other enhancements we introduced is a TCP based finger printing model. Again we didn't invent the wheel here but we do several things differently. We decided after looking at several TCP based models to use a TCP model based on the TCP three way handshake. You all know what is expected to be sent back. Again we wanted to use a model that we will be able to use against whatever site and the firewalls will not drop it. We wanted to use legitimate information inside a prop and we want to maximize the results that we produce with the model. So we are sending a request which absolutely resembles a Linux telnet request to a certain site to a certain open port and we examine the parameters received with the CNAC from that machine. Basically currently we are looking for nine different parameters with the TCP handshake model. Several of them are part of the IP header and several are part of the TCP header. There is a little twist here for example the time stamp value is the only parameter we are currently not examining. But we are about to support that with ODA2. Not a lot of people know and I doubt if too many know about that. You can able to detect a Microsoft based operating system according to the time stamp value the machine will send you back. Basically you look for the 00 combo with the CNAC and that is going to give you the best based operating systems. So if you are looking on the web and you want to differentiate between Windows boxes and Unix based boxes on a very easy manner what you have to do is to send one packet and get the CNAC back. Look at the time stamp values of 00 then even before trying to get to the application layer you can have the conclusion that this is a Microsoft based box. The following example shows how the TCP handshake model is integrated inside the tool and what is the effect of the model on the overall results the tool produces. We have used here the minus D command line option not to use the model and you can see that the results that we have produced are all the Sun Solaris machines without no differentiation. When we did use the fingerprinting the TCP handshake fingerprinting model you can see that the Solaris 8 as well as a target was 100% identified and the other Solaris machines got their own probability. So to sum it up the TCP handshake model greatly enhanced the fingerprinting results export to producers especially on big groups of operating systems that we were unable to differentiate in the past. If you look at the signature database inside the tarble that we have released yesterday you can see that except for maybe the Linux based operating systems the results that will be produced by export to on optimal conditions will give you one or two matches for the probe that you are using and that's it. It means that in groups of operating systems no big ranges of operating systems that's one or two 100% matches and that's it. Since we are relying on several ports to be open or closed well one TCP port open and one UDP port closed we have decided to implement a port scanner with the tool. There are a lot of tool users that have asked for that functionality as well. So we have decided to add a port scanner as an independent model to the tool. It means that by default we will not run the port scanner we will only run the OS fingerprinting tests and we will still use the minimum or the minimal usage of packets in order to produce the results. The usage of the port scanner is pretty much straightforward. Use the uppercase P, uppercase T or U and specify the port range to scan and you get results of the open and closed ports and filter ports. Nothing new here but again someone wants to use that functionality for whatever reason we are allowing it. What it also does when it will identify an open TCP port and when it will identify a closed UDP port it then will use them for the TCP handshake model and for the ICMP port on which model. It means that the port scanner did got whatever port you need for a dependent model then that dependent model will get the port from the port scanner and will run with the appropriate port and of course will produce the results that you are looking for. There is a nice diagram here outlining the different relationship between the different P's. You can look at that afterwards if you want to. We have decided to not be idiots and just say we send 10,000 packets in one second and we produce the results in three because that is lame and that will not get you anywhere. We allow the users to specify whatever time interval they want between the difference in packet sense and the UDP packet sense. It means that if you want to be ultra-paranoid or whatever just use the minus S command line option define or put the different milliseconds you want as the time interval between the difference in sense or the UDP packet sense and the tool will do that for you. Basically you have option to specify it in milliseconds if you are not specifying I minus S then the default time interval between the packet sense with the port scanner will be 10 milliseconds and it means 100 packets per second. Another interesting issue to understand when I have rebuilt the signature database and use the port scanner how many of you have free BSD boxes? Great. You know that there is a nice option called rate limiting right? If you sit down at your console with free BSD and you use a fast port scanner a fast port scanner that produce a lot of good results you'll see those messages saying that the box is rate limiting the number of sent packets to the scanner. Everybody has his own issue on how to solve this. We thought that it's better to allow the users to specify whatever time interval differences they want between the different packets that the port scanner sends. And of course that's an important issue not producing a denial of service on your own machine. Here you can see an example of a scan that was too fast or was not enough time out in order to produce an accurate result. Basically it's a Linux paste OS here. We scan ports 5.6 to 5.0 and TCP ports 20 to 30 and you can see that the last port is being filtered. It doesn't mean that the port is really filtered it means that we have scan too fast. So by providing a value for the time interval here of 40 milliseconds we have basically got the problem away. It's important to understand that on a congested network the scanning conditions are different. On local network, at your home network the scanning conditions are different. On the internet the scanning conditions are different. It doesn't really matter for you to scan with 10,000 packets in two seconds because actually it will not give you the results that you are expecting. What we also did is of course used hashing for the port scanner. It's not something we have invented. It's not something that other people have invented in the last year if you know what I mean. Something that was invented back in 98 by an Israeli hackers group and we used that for the port scanner as well. Question? Someone? I guess lunch was invented for you. Another thing that we have added to the tool is the automatic receive time-out calculation that works for three different models for X-Probe 2. It makes X-Probe 2 scan an IP address at half a second to two seconds only. There are three different time-outs for the discovery model for the port scanner and for the fingerprinting models. Basically whatever discovery model you are using is the longest RTT and we will multiple it by two and that will be the receive time-out for the fingerprinting models for the discovery models themselves. We have added a minus T command and option to specify their own receive time-out and with the port scanner we basically have added a different time-out mechanism. Basically we'll take the number of ports scanned and multiple that the 10 millisecond default that we have plus any time that you have put as a time interval between the packets sent and we'll add the 2X RTT. Now with the number of packets received back equals the number of packets we have sent for the port scanner we will time-out before the other time-out will expire. Another thing that we did is we have rebuilt the entire signature database of export 2 from scratch. It means that I had to go and install too many operating systems that do not like Pentium 4 or Pentium 3 or whatever. We got back until, well, NetBSD13 was tough to install. The signatures as I said before are tightly controlled. We are introducing new signatures only and if only we can be assured that the signatures were produced in a correct manner. It means that maybe we'll have a smaller signature database but it also means that our database will be much more accurate than any other database for any other active operating system finger-printing tool. Yes. I'm going to talk about it later. As I said before, it's very easy to install a signature database. Our new signature database and the tool is able to uniquely identify 2003 standard, 2003 enterprise, 2000 SP4 and SP3 which currently no other tool does. The signature database includes the entire 2.4 branches, 2.2 branches. That was really fun to install. FreeBSD from 2.7, OpenBSD from 2.4 as I said before, NetBSD from 1.3 and of course many other signatures such as for Cisco-AX, IIX and other operating systems such as the Software Foundry and such and such. As with the previous years if you don't have any other questions and there is another part after the demo I've decided to target a nice country that we all love and respect and no, they did not they invited, invented the fries the Belgians did and no, they do not use American technology so first site that I have decided to look at is the Radio France I wanted to hear that wonderful language that we I guess really all of us understand fluently and speak fluently. Radio France is using Linux, good for them 2.4 actually the group of operating systems or the kernels that actually match the operating system Radio France is using is 2.45 to 2.16 then I decided that I'm bored with the radio, maybe I'll get higher education and I went to do the Sorbonne University which is well, a university in Paris here I decided that I would like to use only several models with my fingerprinting attempt I did not use several fingerprinting models as you can see here the usage of the minus D command line option and unfortunately for them I don't know there are no French operating systems right so they're using the Sorbonne main website after finishing my higher education Sorbonne I decided that I need to search for a nice interesting thing to do so I decided I'll look for a biotech company found one and that biotech company is using Windows 2000 as their servers because this is a good example for the inability to differentiate between 2000 until 2000 SP2 and XP but if there is a web server there I mean what the hell it can be it's common sense sometimes after working for several years for that company I decided I need to move on I decided I need to love my environment so I decided I'll check out the environment the government environmental site here is again no American technology used and they are using Microsoft Windows 2000 SP3 I guess they need to upgrade so after doing all those wonderful websites I decided that I need to know who is the Prime Minister of France and again they are not using no American technology and they are just being hosted by Akamai Networks and Akamai Networks use a proprietary version of yeah they have their own Linux 2.2 version which they are using you can see that by playing with the different options which fingerprint models to use common sense what do I need to use in order to scan a website I can get my results more accurate since of course there will be several probes that will be blocked so why using them in the first place so what we actually are looking forward to implement with O2 release and what is really the future of things although I do think that X-Probe 202 RC1 is a very good tool to use after two years of development a lot of lot of research you can download it and try it for yourself and see for yourself how fast and accurate the tool is most of the problems that we have with active voice fingerprinting tools and with tools of such magnitude is the inability to assess the terrain that we are in scanning if we are unable to understand both then our scanning will be affected and we will not get the maximum results from the scan so if you look at this diagram it can summarize what we really need to implement the things that are currently being developed first of all we need to add model dependency if one model depend on the execution of another and the first model fails there is no need to execute the other one I mean the port will not open for himself man it's not a magical mystery so what we are going to do and what we are actually working on now is adding intelligence into the tool because the tool will not be intelligent enough or will not have any AI programming to do that what we are going to do is to add dependencies to assess our scan in each and every stage if we do discovery models and we get the understanding that there is a firewall there we will be able to change different tactics of the tool we will be able to automatically flip to another tactic if we do fingerprinting models and the amount of received results the probed matches will be a big whole what we will do is we will look for the common thing with all of those operating system and then we will use a niche targeted operating system fingerprinting test to differentiate between the operating system that we have as the result for the first stage of the OS fingerprinting scan there are a lot of things that we are going to implement at that stage and at the end of the day it will give us the ability to assemble the whole operating system and give you an accurate result I would like to credit the following people that helped us develop several things for the tool you can get further reading from my website and if someone have any kind of question I can answer then that's the time you talked about the beginning are you mostly just talking about routers and those types of devices or are you also talking about server board we are going to add several tests that will be able to allow us to tell you the exact platform for several operating systems not only about the networking devices sorry JetDirect, actually there is support for a lot of the JetDirect version HP is a good example for how you do not have signatures inside the database we are fingerprinting HP according to the JetDirect EEP ROM version and we have like 10 different signatures according to the EEP ROM any other question X-Probe can be built on Linux and FreeBSD and I guess on Solaris as well but we haven't tried Solaris yet yes, Reddit 9 works yes currently no but we will be able to do that okay, yes last question there is a document inside the towerball describing how we can add your own signatures and we are going to automate that as well yes the different tests are not currently weighted but that will be changed with O2 release so I'd like to thank you for coming here I enjoyed, thank you