 Alright now, isn't that fun? First of all, I want to welcome you to DefCon 10. If you don't know, you're on the Necricon and ADS track. Okay, I did that part. My name is Afir Arkan. I'm the founder of the security group. I'm here to talk about Expert 2. Last year I've been talking about Expert 1. This year, we're releasing the second version. I'm here to show you the tool, explain you what the tool does, and show you what it does. So, we're going to speak about some release information. Of course, everybody wants to get the right paper on the tool. Here's the two problems with strict signature matching. There's fingerprinted tools. The need for a better fingerprinted tool. Our approach, or the way that we play with our fuzzy approach with the burden system fingerprinting. The particle implementation. The country that they pick to them on. And the questions. Something about myself. As I said before, I'm the founder of the security group. I do some security research. And of my radio job. I'm a computer security architect. Just to pay tribute to the guy who couldn't be here, it actually is a part of Expert 2 Fiora. This is actually a different Fiora from the Fiora that you know from NMAP. This guy actually lives in Taiwan. The SNP developers. SNP Mellon List. So, this is the Fiora that I'm building with. Today, and actually it's already on my website. They're going to call Expert 2 Fiora. The process of fingerprinting has been released. As well as the eCast, which is half a version of Expert 2. That's one remark. If you're using Linux, you must use VPcap071 in order to run this. We had some weird problems with VPcap071. So, if you want to avoid these, use VPcap071. There is a value from systemsecurity.com. Expert.org and Expert.org just forward to that website. So, as I said before, the first version of Expert was released last year at the back of Prefix. In August 2001. Which is based on my research about the ICMP usage and scanning. That's his answer. From my website. The two places are an alternative to other remote-active operating system fingerprinting tools that rely heavily on the usage of TCP to do their job. If you didn't know this before, they are not able to differentiate between certain groups of Microsoft operating systems because the TCP stack on these are really similar or even the same. I can name, for example, Microsoft Mi 2000 and XP, which share a lot of similarities on their TCP stack. And on the other hand, all the windows, NT4, 98, 98, and C95, which is another group of operating system, we share TCP similarities. The first versions of export combine some of the methods that are discovered in my research into a very simple, fast, efficient and powerful way to detect the target host underlying operating system. One of the problems of that too was that it uses only ICMP related operating system fingerprinting tests, and it was not available for people who wanted to integrate other tests into that too. They couldn't do that. One of the major drawbacks of the tool was that we didn't introduce a signature database, and basically we relied upon a static decision tree to produce our signatures. That actually limited the way that the tool works. It limited our ability to introduce more fingerprints, and it made it really hard to introduce new fingerprints into the tool. Although it's disadvantages, the techniques used by export one were adapted by a lot of commercial-based tools, and if you're going to download export one, which the current published version is OO2, and the unpublished one is OO2P1, you will see that it works. In most cases, you get good results and very accurate results. Just to give you a reminder of what I did last year, one of the sites that I visited last year, my store through the Chinese suburb space in my first annual Chinese cybersecurity survey, was the Ministry of Foreign Affairs of the People's Republic of China, and that was actually running at the time, window 2000. Unfortunately, when I tried to do the second annual Chinese cybersecurity survey, I found out that this site is already far-willed and everything is nearly blocked. But just to show you as an example what was here last year. So we basically looked at our disadvantages, we kind of understood where the tool is being limited, and we wanted to integrate signature support to export. But before doing that, as the usual tools that are available today, we did some analysis and we came to the conclusion that those tools suffers from several design flaws and accuracy problems. First of all, because of the conditions that the tool operates against and the nature of how the street tool that you're matching is being done. This stuff will be concentrating on how we aggregate different remote-active reporting systems for different methods to identify the remote or else with high precision using our fuzzy approach towards fingerprinting. Now, first of all, what we'll do is to start talking about what we have today and the different tools that you're using, tools like InMap and Quazio. I don't know if anybody is using Quazio these times, but more like InMap and other derivatives. And then we'll see what we can enhance or what we want to do better. And then I'll show you what we've done with the tool. So, all of these tools that are basically available out there today, they use some kind of a signature database to perform remote operating system recognition. And of course, they're using street signature matching and a fixed number of fingerprinting tests. That in order to identify the remote machine, the target operating system. This method is not perfect. It's affected from several issues. First of all, the typology of the system that we're scanning, the nature of fingerprinting itself. These two major issues lead us to actually guess the type of operating system rather than accurately understand what we are operating against. If we look at the packet way, we can look at several obstacles that the packet might go through when we send a packet towards the target system and we don't really know what's going on. So, on the way to the target, the packet might be affected by several different ways. First of all, several foods within that packet might be changed by a networking device or by a filtering device for the following reasons. For example, if we have a packet-chaping device on our network, that packet-chaping device might go, look at several fields on the side. I need to do some work on those fields and we'll change the values that we've put on the end of those fields. That might be inbound or that might be also outbound. We can name, for example, type of service values or quality of service values as a good example. Another issue is that routers or firewalls might spoof some responses for the targeted system they protect. If you know a checkpoint file or one, it's able to send ICP-ACO replies from systems it is defending or even initiate the three-way TCP handshake with an initiating system and only when the TCP three-way handshake is finished, only then you will forward the information to the targeted system which is protected by the file. And, of course, if your target network is using a scrubber, that scrubber will basically go through several fields within the IP header and the application that you are using. Basically, scrub those to use certain types of values that it was decided before to use. So if you are relying on those, you will not be able to fingerprint the target-deporting system. So that family of problems, you can see a scrubber using a package-hooking device, filtering files, the fingerprinting devices that are very smart, will potentially affect your fingerprinting, it will affect your results. Basically, you get false results or inaccurate results if you are relying on that ability. Now, if your fingerprinting tool relies on those particular fields which were changed by the either a fingerprint device, scrubber, package-hooking or other devices like this, you will fail. Sometimes we can remedy this thing if we will try to put some appropriate signatures into our database with the signature that will match the situation. But sometimes those devices are dynamic nature, and for example, scrubber might have different values introduced or it basically depends on the site that it works on, and you will not be able to guess all the things that someone might do to you. Potentially doing that, we might even be able to recognize some type of pocket filtering device, for example, OpenBSD NAT or Linux IP Masquerading, but if we are going to try to do that and the current signature matching abilities will fail, and probably we will not get that accurate results. Usually we are relying also on several types of messages to be answered by target host mode producer or fingerprinting. One of the things that we have is sending, for example, a sim packet, a TCP sim packet to a host to a high-pour then what we will get, a TCP app or a CNAC or a reset depends on what we are getting. Usually we will try to get a reset back so it will be an indication that that host is up and running. But if you are being firewalling your system now correctly, then if we are relying on that particular test, of course we will fail. If a tool that is able to do that active fingerprinting relies on this type of packets, and those will drop by firewall, everything will fail. Another major issue is using a load balancing in the way to the target. If there is a load balancing device in the way to the target, that load balancing device might send us to different web servers. We might hit different web servers, not initially our official target, so we will get different results, different tests if those web servers are operating on different machines and not the same operating system. Some characteristics of the TCP app stack might be altered by a user. I can name for example the CCTL command of the first piece, the NDD on Solaris and etc. There are also a number of kernel patches that are open source, like the IP personality patch for Linux kernels, that will alter the behavior of the TCP stack of your system. If again, a remote active important system fingerprinting tool would rely on getting some answers to in looking at those particular fields that were altered by those tools or by those tunable kernel parameters, our speech signature matching will fail. Also, if the remote active important system fingerprinting tool that we're using would rely on network packets to produce its results, those network packets will be able to be detected by an network intrusion detection system if it's properly configured. If one does not want to utilize network packets in order to produce its fingerprinting, and basically he wants to avoid the detection by an network intrusion detection system, most of the tools that are out there today will not give him the opportunity not to use these tests or even if he wants to use those network packets. Some of the firewalls out there are able to actually examine different IP header fields and decide that they want to drop the packets because they are not legal. I can name, for example, Sidewinder, I believe Secure Competing, do that program that basically that firewall you can play with every IP header you want and you can decide if you want to drop packets according to things like that. Secure2 relies on sending network packets and there is an intelligent device of the way to the target. Those packets getting dropped will not get any results. Questions? Somebody has any questions until now? No, okay. So, a lot of problems that actually results in bad fingerprinting or even with the total loss of whatever you did or whatever efforts you put into scanning. Most or the leading remote-active reporting system fingerprinting today use those kind of methods and all of them produce fail and inaccurate results when you test them against more hard anthropologists or actually networks that people understand what they're doing. So, with all those problems, what we want to have with the remote-active reporting system fingerprinting tool? Well, first of all, we want to have precision. Even if some particular tests will fail or when they're ineffective, we want to still have the ability to fingerprint the target otherwise. We also want to have the ability to identify networking obstacles such as filtering devices and load balancers. We also want to detect or have the ability to take modification to the OSCon app and, of course, to detect square bar activities. We want also to have the ability to limit the number of possible gases to a fillet number. Sometimes you don't get a definite answer and you want to examine yourself the results. Sometimes you know which system you upward against. For example, if you're targeting a web server, you know that that web server is not upwarded under Windows XP. It would be most likely that it would be running under Windows 2000 server. So, although the two stats are similar, you know that this is a Windows 2000 rather than a Windows XP, for example. Now, there are other people in this world that might detect OS fingerprinting tests or their own way of doing OS fingerprinting. So, we want to have the ability to give them to integrate their tests into your tool. We want to have some kind of API for it. So, other people with other brilliant ideas will have the ability to use the tool, introduce their own methods into the tools, still use the original signatures for the tools, but introduce their own into the tool as well. We want to have the complete control on which models we are using. So, if we don't want to use any math or packets, if we don't want to be detected, we want to use whatever values to any IP headers we want to have that. So, when designing Expert 2, we were looking at those issues, we were looking at those problems, we were looking at those needs, and we attempted to resolve most of these issues. We went back to basics and we went to mathematics. We want to look for several mathematical approaches to fuzzy matching. We were looking at the Fisher discriminant functional analysis. I will not go through this. Also our recognition, matrix-based fingerprints matching based on statistical calculation of scores and other mathematical algorithms. Yes, we went to math and we tried to utilize math in order to find a solution to these problems. We decided to go with a simple matrix representation of the scan or scans and the calculation of matrix by simply summing up the scores for each test. All tests are independent of each other and each test is not affecting each other. This is basically the two-dimensional matrix that we are using with Expert 2. First of all, we can see that this vertical vector is the boarding system names. Basically when we are running the tool, the tool is looking at the Expert 2.con file which holds up the fingerprinting database. It looks for the fingerprint and OSID entries. It reads them if you remember how many entries it has, and according to that initialize that vector. The second thing that we are doing is once the test itself is being produced and we get the results back, we are scoring each and every OS according to the matching producers against its fingerprint. Now we have the ability not only to say, yes, no, we have actually some kind of a range we can assign to that score. We'll talk about it in one second. Now, when we finish all of our tests, at the end of follow one, what we do is we sum up all of the columns that we have here. We sum up all of the columns and what we are doing actually, what is the highest score on the total line will be the most probable to be our targeted boarding system. Is this understood? Should I explain this again? Everything is... Yes. Yeah. Here's the answer. Today, with our Alpha code, we're using four different values for the score. In the future, we're going to have a scale from zero to nine for the score. Today we're having zero to three. Basically, yes, which is a perfect match. With you, probably yes, get two, probably no one, and no zero. Each model for the fingerprints assigns its own scores according to the take that the model creator has on the method he is using. So basically, if you come up tomorrow and say, well, I used the API in order to produce some kind of a new remote-activating system fingerprinting test, what you have to do is just use our API and you're hooked up and you're working. So you can have your own take on that and you can assign whatever scores you like. Now this gives us probabilistic support since the highest score given for BOS or even OSS is the most likely to produce an accurate match. So we can comment say that this and that percentage is that and that OSS and the other percentage is this and that OSS. Now we can go ahead and say that the other matches that we're having or we can show the other matches that we're getting in order to say, well, it might be a slightly different TCPIP stack that we're seeing here. We might detect some kind of intermediate device that alter some values in the way to the target or even identify some modifications. As I said before, the tool comes with a full API. You can go ahead and read the computation for the tool and see how you can hook up your own tests with the tool. This also means that although the tool currently using the basic test that we have for H.2 plus 2 reachability models, we are still able to use whatever protocol and whatever test we want for fingerprinting. This means that in the future, we'll see that we're going to add TCP models to the tool and basically create one tool that we'll be able to do whatever you want with our fingerprinting. This approach overcomes failures with tests because we don't care if the test fails or not because if the test will fail, this means that the same score will be given to all the OSS. So if one test fails in the number of the test that we're using, that's fine. All of the OSS will get the same score and will not affect our judgment. One can also use no for a test fail but we'll probably don't know if the signature is unknown and things like that. This gives one the ability to have the realistic support for whatever model he's introducing. If you're using more tests, it suggests that you might have a better overall result with your fingerprinting. But sometimes, if you understand what you're doing and if some test or some model is conclusive, you can assign it in the future more weight. Today, all the tests actually get the same weight as the other tests. But in the future, what we're planning to do is adding more conclusive tests, has more weight upon other tests and gives you the ability to be more conclusive when you know that actually tests are better than producing results for you. Well, we talked about this. With the tool, you have the ability to do whatever you want in order to send and receive things. You have the full control effect security. You can introduce whatever you want with it. The big obstacle of such a tool is dealing with yes-no tests. And I think it's one of the biggest obstacles of any fingerprinting test. A yes-no test is basically a test where we send some kind of query packet and we wait to see if we get a yes or no answer. Yes or no answer, basically, if we receive or not receive an answer for our test. If the target is being filtered or a tunable parameter on that target is actually configured not to answer that particular test, we'll never know that in our way it will produce a match or not. Using our approach to use our fuzzy approach, we actually limit that effect. What we're doing is actually saying that we have a number of assigned numbers or assigned values we can assign to the score. And on those yes-no tests, we can limit the effect of those tests on the final score. What we're doing is instead of assigning a definitely yes or definitely no score, we will assign a probably yes and a probably no score. So the range of scores that we are going to assign if the test fails or not is actually not that wider. So this approach will have the ability to not affect the final score so much and still we are able to use those tests in order to put less weight on the final score we are having. Questions until at this point? Someone? No. What are you doing? We're more active reporting system fingerprinting. It's very important to understand or try to understand what is the talent that you are working against. What is the topology that you are working against? Sometimes people take the tools that are there and store them on their books and fire them away and just say oh I trust those results. That's a very good thing to do. I'm giving you two examples. I like to read the first example but the second example is even more funnier. HP printers for example. When you try to fingerprint HP printers they are not identified by their model number. So this means that LaserJet 4 is not being identified because it's LaserJet 4 or LaserJet 4100 it's not identified because it's 4100. This is actually being done looking at the EEP1 and 1 that all those printers have. So if you're using Nmap for example or Nmap where I tell you oh this is LaserJet 4, you're right. So you can type all the HP fingerprinting stuff in Nmap and you can delete them now. This is another major issue just to prove that untrusted fingerprinting databases can actually cause you more grief and more trouble. If the fingerprinting that are introduced inside those databases are not accurate, are not being verified by those results even if the test is having brilliant test conditions. So XP2 basically primarily implemented around the tests that were introduced with XP1. Five different ICP-based fingerprinting tests plus two reachability tests. If you want to read how those tests work exactly you can go and read X with more ICP-based fingerprinting techniques that I wrote along with Fyodor which is available for my website. What I'm going to show you now before I show you the other demos that I took last night against an ice country that I like is a sample run that I've produced using Winix Granel 2.480 running expert against Windows XP professional on the same land. This is the sample run. I hope that everybody is able to see it. The Windows XP machine is 192.168.1200. The tool actually initializes the two various reachability tests that I'm going to talk in a minute. It tells you how much modules were registered with the test. Here we can see there are seven. Runs the engine and tells you the guest probability of those two reachability tests. So if those two reachability tests were successfully executed, we can see that the guest probability is 100% for those two reachability tests. The other guest probability will be introduced for the other five modules that we have. So you can see here that the test run actually tells us that the primary guest is Windows 2000 but we can see that the same guest probability is also given to the Windows XP professional machine. Now I told you before that these two are sharing basically the same stats and we got to the accurate answer. We're also showing a number of other guest probability results that might be in some way helpful to people but you see here that we got the result that we were aiming to. The first reachability test is a simple ICMP echo request just to elicit an ICMP echo reply. The other reachability test is actually a time-to-leave distance test which is actually a trace flight test. We're sending a TCPC packet to some port and we're waiting to see if we get a backup or a TCP reset for our query. We're also waiting to see if we get that reply at all. If we are not getting a reply we will retransmit another TCPC packet to another port and if that fails we will send a UDP diagram of clearly eliciting ICP port unreachable. The only reachability test has one common goal to see if the host is up and running to see if there is something to talk about with that host. The second method works like a trace flight thing and eventually it will produce a list of odds it's going through in order to get to the destination. In the future we're planning to put actually some kind of a network map and actually illustrate which hops you were going through and which hops you went through in order to reach your target. The other models that we have rely on the original X-Probe architecture and tests and of course I told you that you can read all about them and the article I don't want to get into that today we simply don't have enough time. The only thing that X-Probe 2 returns is the most probable match it's taken from a son of a course and it reflects other possibilities as well which is shown here and of course we got the accurate results since Windows XP and Windows 2000 share the same stack of results. So before I go into the live demo or the demo I did last night until 3am is there any questions on the way this through works and we want to ask any question yes? Are you here? Well we will have an appropriate TCP model working we will do that as well we want to integrate appropriate TCP tests and all those tests that basically you are puking on the network and just hoping that you get some kind of an answer. We are also hoping to use some kind of more reliable TCP tests that are there today and of course this is only an alpha code working alpha code to just show you guys what we are doing. So you can we are going to put a parameter that will allow you to control which test you want to run as well. So if you still want to use that approach if you have a paper from last years you can use that approach as well. What here? Sorry? Yeah. The problem with our previous use to or to the state available is that if one of those if the initial if you are not getting a point of reach below the first the test fails what this option gives you is the ability that all the tests will fail except with one test for example if you are still being able to ping that host that you are against you still will be able to tell for example it's either Win2K or XP for example. I was actually testing the two yesterday against some interesting sites that you know I can't tell you exactly what I tested it but it's very accurate results even if I just ping the website. Any other questions? So wow I didn't hear what you were saying? I didn't get your last part. If you can go ahead and ask a question I'll answer that. Wow If you have two ICMP packets that go out for two different modules have you considered caching the responses from the first one so that they don't have to send out the same packet again for the module that comes afterwards? Very good question Since this is only an alpha code I didn't want to get in the nerves of further too much so telling him that the first which ability test can actually be a finger pinning test and actually saves us the need to send another echo request to that host but with newer versions of the tool this is exactly what we want to do. We want to chop off the first test or just do a reachability test which is also a finger pinning test which will limit the number of packets it needs to send. We also will give you the ability to control exactly what you are sending so if you say I don't want to use the reachability test you can use the other modules and you can choose whatever module you want to use exactly so if you rely on one module instead of using three or you say two modules are more than enough for me it will give you that control so if you are a more knowledgeable user it will also give you more control on whatever tools and whatever methods to use with the two in order to produce your same signatures and even same matching that answer your question so as we classed here I just got myself a nice country that they like and I decided that I want to finger pin some hosts there so this year I made a story up as well like last year in my store in China my thinking of great unbiased accurate crew broadcast service I am really thinking of only one and for me there is only one if I want to get my news fast reliably I go to this website the Islamic Republic of Iran Broadcasting where they tell you exactly the proof about the world I don't know who is worst this is the Chinese of the Iranians but it's not a discussion about this so having a simple run on the Iranian Broadcasting Association you can see that they are running Windows 2000 the way or the reason they are not using Windows XP Windows XP is not running servers so if you are getting on just the probability 68% on both Windows 2000 and Windows XP you can understand that this is Windows 2000 because we are targeting here a web server rather than targeting a host this is the thing that IIS produces you can see that this is IIS 5 you can see it's Windows 2000 so if you were to stop the regime a big nice democracy if you didn't know and you want to look for a nice comfortable dungeon in a nearby jail near your parents house so you will be able to pay a visit if you are not that bruised you go and look at the Iranian Yellow Pages well, unfortunately for them Iranian Yellow Pages running all the Windows NT servers for one above you can hear that the very gas is much higher than the other OSS due to the nature of the fingerprinting and the sensitivity we have been using you can also see this is using IIS 4 you got the idea that this is Windows NT 4 since jail is really going and after some hours of torture you need to relax you know, more reading going to read the local newspapers I don't know what frightens me more but just the jail or that picture of the man here look at these eyes well again, Tehran Times is using Windows NT 4 service pack for one above this is actually a run that I've done with Xbox we get the same result with the same fixed tree at this time you can see that they don't block anything here and the tree and the fixed tree with the original Xbox will still work so after we got beaten up and we got some papers it's about time to do some kind of out of sale activities so we like to go and register for any unfit for association unfortunately for them again there is a Windows NT 4 maybe it's the same hosting facility I don't know and you can see here that this is IIS 4 this is NT 4 SP4 and above so after the regime if you do an organized vacation on one of their elite vacation sites maybe you want to choose one for yourself for really in that case anyone that have a holiday there you can choose from a number of hotels courtesy of the government of course bug free and they are actually running Windows 2000 which got the same as Windows XP and they are running IIS 5 here you go Windows 2000 I decided actually to give some red visit to some two nice sites that I like from last year and I bet they will appreciate that as well one of them is the Wimbledon website which is so nice not to fit or anything still running Windows 2000 still not a problem to figure it out here you go this is IIS 5 very simple but the site that I liked really much last year of course not including the Foreign Office of China is the State Family Planning Commission of China I paid a visit again to see if the policy was changed if I go to China if I can have more children no a year passed nothing have been changed in China and the OSS haven't changed as well still running Windows 6000 they do learn like the foreign ministry has learned this is the other place I got this is basically what's the demo next week on what I'm going to do when I go back home a small text file tell you exactly how to produce your own fingerprints on my website the tool the paper that accompanies the tool and I strongly suggest you read the paper don't go around the tool send me an email saying the tool doesn't work you can understand how the tool does understand what the tool does understand what you can benefit from it also I want to credit Ben Der yeah thanks God he is not here with me saying his name like this which help us with programming I want to thank Captain Major for letting me on the Goon Apple Plus Act there are some further reading what you can do on the subject if you are interested all available from my website the login article that I wrote that is not mentioned here that you can use you can always send me questions or send me fingerprints if you want and I'll integrate them and we'll answer your questions this is basically it thank you for being here and if you have questions I'll be more than happy to answer