 As you've just been hearing, can everybody hear me clearly? X, KSO, in-map, most recently, wing. These are examples of operating system tests, methods to detect what operating system is running on a computer over the internet or on the same LAN from another computer by testing how it looks at the network. Now, that can mean looking at its TCP IP stack or its ICMP implementation. Or maybe it's services, or it's services pattern. There's lots of ways to do that. Up to now, though, you have had to access these things in a tool, such as the X tool, X-Probe 2 tool, or in-map, OK, so, or whatever, or wing, I don't know if any. How many people have looked at wing? Scene ring, OK, cool. So now we're starting with why you should not leave me in the middle of this thing, is I'm going to show you what I've been doing. This is a program that I've written using my library. Now, right now, the library works in C in Java. You're looking at Java because Java's easy to make a GUI in. What you see in the bottom right window is loads of modified versions of the in-map database and the KSO database. Very soon, once I look at X-Probe 2 and look at its database, since it's now on a file, they'll be in there too. It's a list of all the operating systems that you find in those databases. And then over here, you'll find little checkboxes for the tests. So far, in Java, I've implemented the Manga packet tests of in-map fame and of KSO fame. In CI, I've also done the X stuff. Next, it's going to be a T-sequence test and a ring. So let's see if I can get it to work the first time. Earlier, you were mentioning somebody here, was mentioning the fact that X-Probe 1 used a tree, used a SIT1 packet, and then based on a tree that it had in its memory, would send the next packet based on the result for the first packet. And as a result, it would send in total less packets than in-map what or I think any other tests at the time. And as a result, it could limit the number of packets it sent, reducing its IDS profile, reducing increasing speed, all these kind of things. So what if you could do the same thing with in-map? What if you could run in-map one step at a time and then use the results that you've got back since in-map runs? In-map alone has the seven Manga packet tests that you see there and a T-sequence test, which initial sequence numbers, and a four-enreachable UDP test. What if you could use those one at a time? Well, this program right here shows what happens if you do that. If I run the in-map four and the case of two tests, the source board of 10,000, I hope this is open, I hope this is closed. Now, a lot of the values in the test are based on starting sequence number and this allows you to play with that. Now, who? Those suitable devices found. Damn, that's what you get from playing your network cable core. I'm not gonna belay you. I'm not gonna play with this too long. The fact that I'm gonna move on now anyways, I'll come back to that. But that's the kind of thing that you can do. I'll just keep that up since I think it's cool. That's the kind of thing you can do when you're able to access the tests in a systematic way. So hopefully now you should be convinced that you might want to hear the rest of the presentation. Then again, easily don't feel free to leave. Especially since I know that some of you who dream and pull could be very upset with the fact that you're not getting pulled though by now. I understand, I feel your pain. Okay, another thing? The TGZ Young, the CD is useless, go to my website. All right, who is this code for? Well, the answer is kind of everybody. If you're a hacker, you'll be able to write a script that says don't run my exploits on anything except an exploitable box. If you were able to detect that you could sort out Windows 2000, version this, rev this with this service running and this version before you ran your tests, what you'd be able to do is have a mini vulnerability test right before you actually ran your exploit, which means that instead of running a system where you scan the host, you forget about operating system, it's running, you forget about what's open, you research what hacks are there, but you can just run a hack and it would stop if it wasn't the right operating system. It would just not run. On the other hand, if you're writing a worm, not only can you write a worm, but if you're writing a worm, you might not want to scan Linux hosts over and over and over and over again like you've all seen in your logs. You might just want to scan Windows 2000 boxes. Well, by including all a portion of an operating system thing to bring library in your code, you can do that. White hacks. The same reason that Black Hat is interested in what operating system is running on your network, you should be interested in what operating system is running on your network. All abilities are based on operating system and service version. Not all versions of all of this, sometimes it's all PSD, sometimes it's just 3DSD, sometimes it's just Linux, sometimes it's just Linux 2.2. You care because you're gonna be able to get broken into based on what you're running on your network. Now, on the other hand, besides from a security perspective, it would be nice for administrators to know what it's running on the network. So these are just the reasons that you are interested in operating system fingerprinting. As I was talking so deep that he just kind of goes into it and he doesn't realize, I'm sorry, he doesn't talk to why people are enjoying his code. Most of the people who enjoy his code don't actually do bad things with it, I hope. Okay, this is a deep knowledge track about beta code. If you are expecting something you can go and then program in your application tomorrow, again, with a pair of people, sorry. Not gonna happen. Okay, why a library as opposed to a tool? Well, this way you can write things for yourself that are operating system sensitive. Let's say you don't wanna write a app. Maybe you want your webpage to just be displayed for Windows 98. Or maybe you want your webpage just to be displayed for Windows, all of them. Maybe you just want to be able to display one administrative homepage for Windows, one for Linux, one for this. And you want that webpage, hopefully we'll be talking about like the Apache module of planning. You want that webpage to be able to say, hey, I'm gonna give you this content based on what you are. That would be a very, very convenient way to hand out patches. You could hand out exactly the patch that needs to be handed out to exactly the person that needs that patch. It means less clicks, which administers of thousands of users left. So let's talk about the problems with tools, the problems with programs right now. There's a bunch of tests, right? Some of them are in that test, some of them are case of test, some of them are Xcode tests, some of them are, you know, ring, some of them are service tests. Well, you have different algorithms that are using these things different ways. Algorithm A by A4 and Fyodor is now using Fuzzy. So it's the most sensitive and advanced algorithm out there. And that just uses it very force. It runs all the tests, all the time. And it can come back with pretty good results usually. So you've got some more advanced algorithms. But at the same time, you want to be able to have more control over your algorithm. If you're programming, say, Nessus, you might want to do different things and test differently than you are if you're doing another scanner. If you're doing a web page princess, you might want to scan another way. If you're on a friendly network and you're responsible for a network and you're scanning it, you definitely don't want to do tests that are going to possibly hang up any operating systems. There are other operating systems, older ones, that will hang up on different versions of in-maps tests. It's just a version of a dog. So you run in a map line and it turns it off. This is a bad thing. So you can have polite, you can have stealthy, things that don't get detected. All these algorithms, though, are meta tests. They're above the test level. They're not actually involved with the tests themselves. They're above the test. And these kinds of algorithms have the problems that Hazel was just talking about. He was saying, how do you deal with the results if you're talking about a load balance test? How do you deal with the results if you're talking about this situation? How do you deal with the results in this situation, this situation? All that's dealing with interpreting the results with tests, which is a metal-level algorithm issue. So what I'm trying to do is provide a way for you to get very easy access to the tests themselves so that you can do whatever you want on top with an algorithm. Okay, why not a library? Well, I'm always gonna be playing catch-up. I'm not gonna be able to write new tests. I'm not gonna be able to write, you know, Zippy-do-that-things. Maybe someday I'll be able to come up with something new. But in general, people like Hazel, Fyodor, Fyodor, these are the people who are gonna be writing the new tests. They're gonna be coming up with new code. They're gonna be coming up with new algorithms. They're gonna be doing the new crew stuff. What's in the library is gonna be the yesterday old stuff, but just in a way that you can access. Right, and this is not gonna be a tool. Like, I'm never gonna hand out something that's gonna be particularly useful to you right now. If you're a script kitty, you're not gonna get anything that you can run on a command line. Okay, let's talk about a little bit about the background of operating system fingerprinting. The first grandfather of all fingerprinting is Caso. How many people have used a horn of Caso? And when you like Caso, okay. Less. That's first generation. Why was it first generation? It was the first operating system fingerprinting code, and I'll talk about this in a later, to pull the database outside of the program itself, so that the database of fingerprints and the logic to fingerprint them were separate. We have to that, we have the passive side, PLF side, and stuff that's looking at traffic doing fingerprinting. Right now, I'm not implementing these tests and these are probably the last tests that I use. And the reason is that they're not particularly useful for administrators. If you're interested in doing passive fingerprinting, usually you're going to be a person who's interested in not being seen. The other case is when you're interested in seeing what traffic is going out of your network. In that case, I think the fingerprinting passive fingerprinting stuff that's gonna become available at Snort is gonna be far better than what I could do real quick, so I'm gonna focus on the left side of the map here. So we have in-map. In-map is the seminal operating system fingerprinting. And the reason is, is it's the first to treat as a real science. Fido used a statistical test, he used mangle packet tests, he used UDP tests. That's a pretty broad spectrum of ways to guess at operating systems to use a test. And the other thing that he did that's very significant is that he tested lots and lots and lots of operating systems. If you've got open VSD running on a little Macintosh like they had last year here, you might be able to get in-maps to pick it up. You never know what's gonna be in the database though, and that's a complaint that people like A4 have been pointing out, because that database is so huge that it really is becoming unmanageable and kind of useless, like what he was talking about for the printers. I mean, it's very difficult when you've got 20 signatures, 10 signatures for HP printers, and they all come up. That's just not useful. Okay, second generation is X. X was the first test to use to not send all the packets at once. It made decisions based on previous tests about what tests to do next. The problem with that is it was static. That means that the tree was hard-coded. So you had the tests, and then you had the tree, but just like the early versions of the thing you're putting software had both tests and algorithm inside the code, the tree and the tests both need to be outside the code. So the algorithm for choosing what tests to do when and the tests themselves need to be configurable. So that makes it a second generation. Now third generation is like third too, which I didn't know a whole lot about until today. So that code is addressing a lot of the problems with X, which is making it the most advanced fingerprinting. Now once he does all the things that he's planning to do, it will probably be cramming the crop. It will be the tool you want to use, because it'll probably incorporate a lot of the tests that in-map is using, the T-sequence test, these kinds of things. Hopefully what I'll be able to do is look at the API, the one that he was just describing, and use my library to code tests for his API, which means the fact that I have finished the KISO and in-map tests and made them separate and pulled them out and done all that work, will mean that he's kind of handed that out of a silver platter, but we haven't talked about it, so that's up in the air. Okay, the other thing is the wing. Now the one new thing about T-sequence tests and in-map was that it was totally normal traffic. What it did is it sent, send packet, send packet. How many people understand the TCP handshake? If you don't understand the TCP handshake, what I'm gonna say right now is going to be just like gobbledoom, they're gobbledoom since it's a gobbledoom, right? So just forget it if you don't understand that. You send the send packet with a sequence number, it's gonna respond back with a SINAC with a certain value in its packet that corresponds in some way to the value that you sent. Now by doing that over and over and over again, you can get a statistical relationship between what you've sent and what you get back. So you can find out if they're generating the sequence numbers to ones that come in response randomly or they're adding something to your sequence number. Very common is to add 100 bytes or add the value of 800 or some other constant. But there's no way to detect that. That was simply a firewall. So long as you've got a website running, that said, all firewalls, you'll be able to get that test through. So the T-sequence test is unique because it's extremely stealthy. It uses normal traffic. It's not doing anything illegal at all. If you stop T-sequence test, you stop your web server. That's the only way to stop that test. It's normal TCB traffic. Now the other thing that's normal TCB traffic is a wing. And the way the wing works is that when you send out a SIN packet and then they send back a response and then you do nothing, they're gonna try to repair that connection. Like it's supposed to be you talk, I talk, you talk, I talk, okay, we're talking. That kind of thing. Well, I said I go, I talk and they go, we talk and then you go. And then you say, they're gonna say, we talk, we talk, we talk. And the periods between the we talks is something that's constant for T-C-V-I-B stack implementation, which means you can test for it, which means you can determine which operating system is running. Now what's the significant thing about that? It's very much like it, FIDOL is FIDOL M-MAP, FIDOL M-MAP's TCB test in that it uses totally normal traffic. It's not something you can detect with an IDS system. It's the same from an IDS perspective as someone unplugging their Ethernet cord or a host scoring down. The number of false positives you get by writing an IDS signature for that kind of a test would be phenomenal. So both the T-Sequence test and the Ring test represent methods for getting an operating system in a very stealthy way. We'll talk about case again. If you want to know that case, so read FIDOL's paper. In fact, if you want to know about operating system fingerprinting, read FIDOL or M-MAP FIDOL's paper. That's the seminal work in the field. It's the first real scientific look at it. Now if you really want to know about operating system, then read Ather's X paper. It's that thick and you'll know a lot more. But if you want to start out, if you want to review these concepts, FIDOL's paper is a great place to start. M-MAP, exactly what I just said. It's a robust database, really big, and it's the first to be really scientific and really systematic about the way you think of things. X. For a seasoned intelligence, it's all signed P, but it's got a hard-coded algorithm for determining what trade is. Ring, we just talked about it. X2, you know, as much as me. All of a sudden you said, that's what X2 is. Can everybody hear me still? Yeah. Cool. Okay, let's talk about the structure of my library. All the tests right now are actually written in C. The reason that that's the case is that C has the best and most documented method for accessing law icon sockets. Most of the tests, many of the tests, involve writing packets in very specific and non-usual ways. So you need to have access to that law, those law libraries. The other thing is that I use LibNet, the beta version, because it's cool and does things for me that I don't have to sort things out because I use it. Okay, it's got a lot of functionality, it's really cool. So that's in C2. The other thing is that actually running the tests is irrelevant. People don't even have that information from somewhere. So the easiest way to write the tests in C, so that's how I do it. Okay, C applications, Java applications, C++ applications across the top there. And then beneath those, you have the C library and Java library, C++ library and Pro library. The Java library is the one that's most robust, obviously because that's the one that I just showed you. So right now I'm going for implementing X, KSEL, in-map and weighing and all these different tests and having them move up in between these different programming languages. So wouldn't it be cool if you could write a Perl script that says if Windows do this or if some function returns as Windows do this or if some function returns as Windows 2000, you do this. This would be a good thing. The other thing with Perl, and this is something that actually I'd love to get this functionality from Perl into other languages once I get done, is you can take a look at Rainforest Puppy's libwisker. Libwisker is capable of doing very, very accurate fingerprinting of the web port. It can sort out what server, what web server is running on a particular computer. I was doing it pentastritionally and they were using it at a free BSD, it was a product, it was based on a free BSD and they were using it to proxy an NT2000 web server. Well, when Risco first went into it and said, oh it's reporting back and saying it's Windows 2000. So that's what it is initially. And then it runs a bunch of other tests and finds that the actual behavior of the server is more like free BSD. So it comes back and says actually, no, this is Apache. This is Apache. It looked like Windows 2000 at the beginning but it's really Apache. Wouldn't it be neat if you could get the, this isn't what the web server really is from libwisker and move it over and make decisions based on that and other programming languages. So you could say, because Apache, for instance, runs on Windows 2000. Rarely do people do that. But it does, it runs. So you can get that legitimate header back from that web server. And then if you're running IIS hacks against that box. So being able to say, for instance, run a T-sequence test against port 80. Get a sequence number, run a wing test against port 80. Those are both totally stealthy. And then just ask what do a service test to find out what web server's running. You'd be able to think of a host with absolutely no IDS detectable stuff. All that stuff is totally legitimate traffic. And it would tell you a lot of information. So every language here has different advantages. The reason I did Java first is because most of what I wanna focus on is how OOP, an object-oriented programming really affects the thing you're putting science in. Java is very easy to get threads in and out of Java. So I started there and I'll use what I've learned there to do the elements. So we kinda understand what I'm talking about here. Have I lost everyone? Have I not lost everyone? Okay, okay, right now for my .c files, each test is written as a listen function and as a send function. Now, for instance, the sending portion of in that T1 through T7 are very different. But the fingerprinting portion are all identical. So you can collapse the listening file on the one. So basically, from a C perspective, it's functional programming. By using my C library, you should be able to just call functions with the white stuff and run whatever test you want. Let's take a look at the C code. Talk amongst two sides. Okay. As you'll be seeing in a moment, all my code is released in, now, you know, that's it. Okay, it's back on. Can you hear me now? So you have a function call. It takes a source IP, destination IP, source port, destination port, and initial sequence number. Now, in C++ or Java, what you can do is overload these functions so that you don't actually have to give it a sequence number. You're gonna have to give it a source port number. Basically, the source port in the in-map, meta-level algorithm is chosen for you. It's just randomly. But you don't have to do it that way. If you want to, you can configure just about everything. On the other hand, the overloaded functions will allow you to run it the same way that in-map does. So if you just wanna have a destination IP, assuming you're using your own IP so you don't need a source IP, assuming that you're gonna generate a source port randomly so you don't need a source port and you need a destination port. You don't need a sequence number because you're gonna choose that randomly. Then that function will just have destination port, destination IP. You need to build the options. In-map TCP tests use crazy options. It's one of the IDS signatures of the tests. Anytime you see this particular set of options all together in one case, in a packet, it's usually an in-map test. Then you set up the build TCP port of it, portion of it, I don't know how many of you are familiar with that. And you use the SIN port and the bogus port here. There are so many flags in that a TCP packet can have. There is one that is not defined, that's a bogus. In-map sets that flag. Most TCP IP implementations have no idea what to do with it. So they can, they'll respond back. Sometimes an operating system will read, it will take the packet that it's reading in, change it into the response. Which means they don't actually write a new packet. If they do that, then the bogus flag in the packet that comes back will also be set. So depending on how you implement it, the results are different. You make enough space in the IP and then you send the test. All right, moving back to my PowerPoint, talk amongst yourselves. Okay, here is something that I would actually like some feedback from people at this conference about. And the question is, how do you classify an operating system? For instance, the way I'm doing it right now is with a less family name, major version, minor version, other information, and architecture. I know for a fact that this is not a good way to do it. And the reason is, is think about how many BSD variants there are. If you have a family and you want to be able to write a test that's for all BSD or you want to be able to write an exploit that's for all BSD boxes. If you're doing that, you want to say if the family name, if this top level group is BSD, then run the test. If not, then don't run the test or the exploit. Okay, if you do that, then what goes in major versions? Since that's the next step down would be free BSD. And then under that would be four point something. Well, the problem is it just doesn't split up very well. Like for instance, Windows. Windows is a family name, then you have 98 and all of the other things. So when you're using Windows and the major version is 98, that's comparable to the entire operating system of free BSD probably shouldn't be. So how do you classify an operating system? How do you group them? That's a difficult question and it really takes some knowledge of operating system history of which I unfortunately know only a lot of part. So I'd like some discussion perhaps if you'd like to come talk to me about this afterwards, please do. But every class JLS test, which every test is a subclass of has this information in it. Not only that, it has, again, if you don't know Java, then this is gonna sound irrelevant to you, so just ignore it. I've redone the equivalency stuff so that it does the equivalency in such a way that it won't order any given set of these operating systems by their actual classification. So we're gonna take OS family name into account first, then major version, then minor version, then something like this, so that you can do, you can use the actual Java compare to function and it'll actually return a negative or positive number based on the relationship between two operating systems, which means you can, you can, for a given operating system, you can run tests based on less or more stuff. If you know Java, then perhaps you know what I mean. If not, perhaps you know what I mean. Okay, okay, threading. Operating system fingerprinting should be threaded. And the reason is, is that there are some tests that are related to each other, for instance, that tree that X did, but there are other tests that are totally irrelevant. So you could be running the X tree, all of IC and P tests, at the same time, you're running in-map tests, at the same time, you're running service tests, and then the whole time, you could be using, race, condition, safe data objects to move information about what tests should be run. So if you can have, basically what this allows you to do is write testing algorithms that will turn on its head based on the results of one test. It means that you can write dynamic trees. So you can say, well, let's start running these four tests and then get those four tests back and then as a result run totally different other set of tests. And the reason that's important is that one of the problems with in-maps fingerprinting and just vulnerability assessment in general is that it tends to be slow. It takes a long time to do this. So if you can do stuff in parallel, if you can get information in different directions at the same time, that gives you a huge advantage. Okay, you've already looked at the code. Let's see. Pro module and C++ module will happen someday. If you're a pro guy and you love writing modules that access C libraries and move like large amounts of data back and forth, please come talk to me. I'd love to have your help. C++, I think I'll be able to handle just because it's easy. Okay, what's the future of my fingerprinting library? Well, obviously it's to implement all the tests. Like when you're able to access all the tests in my library in one place, even if that's all I give you, that means that it's an easy place for you to start, assuming you want to write operating system fingerprinting code. The other thing is service fingerprinting. There's a program called WinFingerprint that does nothing but fingerprint. All those dangerous, turn them off please, 130X Windows ports that you should never be using ever. So you can run an entire sequence of service testing on a fingerprint, what net bios, what SMB, all those things, what they're doing, what they mean. The stuff that they can return, I haven't looked at the code carefully, looks like it's pretty impressive, very much like the Whiskers HTTP ability. And as a result, if you can get that service information, then what you can do is you can have associations between service generations like send mail version this, goes with Solaris version this and IIS version this goes with Windows version this. Like some of these things you happen off the top of your head. Some of them on the other hand are a little more complicated. But since vulnerabilities are based on service member and operating system member, it would be nice to be able to use service to get operating system member guesses and use operating system guesses to get service member guesses. So hopefully we'll be developing a database about what services go with what operating systems. I'm sure somebody's done that. So it wouldn't be hard. The other thing is what you can get if you have all of this stuff is a CDE database, kind of a Nessus light. Nessus actually tests to figure out whether or not you're vulnerable. What if you don't care? What if you really care if you're vulnerable or not? What if you're running a version of Windows blah blah blah or a FreeBSD blah blah blah that's vulnerable to five things. Maybe all you care about is that you need to upgrade the next version. Maybe you're on FreeBSD 4.0 and you need to be on 4.1. Maybe you're on Windows 2000 and you really should be on Windows XP. If that's all you care about and you're an administrator, you don't need to have a full-blown vulnerability test to make sure you are, in fact, vulnerable to something. All you need to know is not current version, please batch. That's it. So if you can be very aware of operating system fingerprints and service fingerprints, you get a very, very cheap, very, very fast vulnerability scanner. The other thing is to develop a simple scanner. Something that does, I don't know, a core of what in-map does. I don't know if you guys have looked at in-map three. It's up on insecure.award. You definitely ought to go take a look. The Windows versions of in-map and the Linux versions are merged. It's pretty cool. But that's, I definitely don't want to write stuff that competes with these tools that are out there because they're so good that it's very unlikely that I'll be able to generate something that's going to be able to keep pace with those technological developments. Rather, I prefer to kind of imitate what they did last week. I think the coolest thing would be a little less Apache module so that you could give different information to different web, to different users based on their operating system. So you set your proxy up so that, let's say, you combine your CDE database scanner and your little less approximate model, you scan your network, you come up with 192.168.1.5 is a vulnerable version of FreeBSD. You associate, you put the patch up on a web server and you say, if FreeBSD version missed, show this page. And then you write into your proxy for your web surfing that they have to go to the patch version update page first. But that means that you scan your network for all the vulnerable things. You put the patches that they need up on the website and then those servers or work stations that are vulnerable will automatically be forced to go down on the patches before they can continue surfing. I might not install the patches, but at least they downloaded and that's a start. You cannot lead, you cannot make a whole string. Okay, that's everything. Thank you and do you have any questions? Yes, oh, and actually I'm gonna have to do microphone switching since nobody can hear. So if you'll just come up. Oh, I'm sorry, that's a very good question. And it's on the HTML documentation that's inside the CDE. It's www.sinsear.net. S-Y-N-S-E-E-R, good point. Next question, next question. Can't hear a word you're saying. That would be a good idea. Yes, but yes, T-C-L and I said yes. Anybody else? Okay, I officially am relinquishing the microphone. Please feel free to come up and do the 101 questions if you feel like it, bye bye now.