 my goodness gracious everybody take a seat as quickly as possible I'm going to introduce our next speaker Kathy Wang from Cinec Labs will today be presenting frustrating OS fingerprinting with morph before this she has worked at Compaq as well as with counterpane internet security she's presented at numerous conferences including not a con okay shameless whoring for that one yeah anyway kick as I said Kathy will presenting her presentation on morph today here you go Kathy have a good presentation I'm Kathy Wang and I'm here today to talk about more which is a tool that I've been working on since late February this year and as Faji said I did speak on this at not a con okay so let's get started we have lots of material to go through but what I'd like to start with is give you a sense of OS fingerprinting history and what's been going on there and then get to the real thing more which I'm here to talk about today more was built on certain libraries so I'd like to go into more detail about that and then the architecture that morph was built on of course is going to be very important there were some implementation problems that I had with more along the way and I'm going to share those with you as well and of course more isn't anywhere near done as I'd like to see it so there's some future considerations for more work on more and there were some people who helped me out with more than finally for questions I have a special request my hearing isn't really what it could be so and in a room this size it could be difficult to hear questions so I'm going to be asking a hearing assistant to come up here and relay the questions to me so please save them for the end that way we can make sure that I get them off okay so what is OS fingerprinting back in the days before case so came out people used to look at you know banner information that got thrown back when they would do a telnet or some connection attempt and based on that type of information they can determine what OS they're dealing with there's also manual reconnaissance which involves things like reading email lists to see what system administrators from certain companies ask questions about how do I deal with you know AIX this version so then you say oh well that's the company that uses AIX servers so based on information like that and I guess some people would do dumpster diving type things you can figure out what type of systems a place is running then active fingerprinting came along starting with case so and the point for active fingerprinting is to send packets to a certain target host and elicit for responses from them and based on the responses you can figure out who they are passive fingerprinting is a little bit different in approach because instead of sending packets to the remote host to get information back to make determinations you're simply just sniffing on the same subnet and based on the type of packet that you see coming across your interface you can determine what OS they are timing analysis fingerprinting is sort of a very subset area of active fingerprinting because it is sending out packets to the target host and looking for response as well but with timing analysis you're looking at well let's say you send out a sim packet and they send a sim app back while you're dropping that packet and then seeing how long it takes them to continually keep sending you sim app packets so you can determine based on the timing difference what OS they are okay so I talked about the different types let's talk about the tools that are out there the first tool was case so which is an active fingerprinting tool and it was based on sending packets to open ports on the target host and I'll be going into a lot more detail about these tools later and then I'm not came out and utilize some of case those techniques except instead of only sending packets to open ports it also sends packets to close ports the passive OS fingerprinting tools that came out like I mentioned in a previous slide sit on the subnet and listen for what type of packet that it gets and based on that information determine the OS X Pro 2 is a very good tool is the ICNP active fingerprinting tool which instead of just looking at like TCP header type responses it looks at ICNP and ring is actually a proof of concept tool I don't think this tool was ever released there were white papers released about how it works but not an actual tool but it's looking at timing analysis like I mentioned in a previous slide so how many people in this room have ever done a pen test okay so we have a pretty good number of people when you go and do pen test you're interested in knowing what your target host OS is that's one of the most important pieces of pieces of information that you can get about the host because based on that information you can then make determinations about you know what kind of exploits you're going to run against that host so this is very very important information now OS standards know something okay they know that like vendors you know implement OS stacks differently depending I mean everyone looks at RFC 793 for TCP implementation but everyone has kind of a different way of doing it and I'm not here to bash vendors or say that you know vendors aren't following the rules as defining RFCs but they're really all legitimate gray areas and you know for example what do you do when someone sends you a TCP header with the flags you know sinfin urge push set I mean or how do you like respond to a fin different vendors would do that differently and based on that information that's the kind of information that OS standards exploit to determine what OS the target host is so in essence I guess the OS being honest about who they are because they have to respond as they were implemented makes them a target alright so like I mentioned I've been working on more since late February and what more is is when it's compiled and installed on a certain host it runs as a usual land process and the goal for more is to be able to emulate Windows 2000 Linux 2 4 and open BST 3 3 well right now more will emulate Windows 2000 and open BST 3 3 so I haven't actually gotten the Linux 2 4 kernel stuff implemented yet now what more for do is more for all modified packet information to full the remote hosts and that packet header information can be TCP headers UDP headers ICMP no IP headers and currently more for actually compile and install on a Linux 2 4 kernel I haven't gotten it working for Windows or open BST or the other BST yet but that's in the works I definitely wouldn't take more than install it on a production quality machine just because if you do that I'm not responsible for what happens now more of this BST license so you can download it for free at CinecLab.net projects more URL so please feel free and download it it's available right now and play around with it and let me know what you think okay if it wasn't for packet purgatory I wouldn't have been able to write more nearly as easily and just to give you an idea using packet purgatory it has probably reduced the number of lines of code for more like by 4,000 or something so that's good for me so more of this built-on packet purgatory which acts as a wedge between the OS kernel and the interface and packet purgatory library was written by Todd Math Dermott who's also a Synapse lab member and sitting over there okay now packet purgatory is built on LibPcap and LibPcap libraries. Morph uses LibPcap to sniff on the interface and uses LibPcap to write raw IP and Ethernet writes. From a high level standpoint this is what Morph looks like and I'm going to be drilling down into more detail about this shortly but you can see that there's a remote host associated and then based on whether the remote host is the one initiating the connection or our host the host OS kernel is the one initiating the connection you can see that packet purgatory is that wedge between the interface and the kernel so it blocks all the packets from going directly to the kernel and instead intercepts and sends those packets along to Morph which starts this handling job and to give you an idea of the Morph architecture packet purgatory didn't just disappear it's actually part of the Morph picture here because I built Morph on packet purgatory library but Morph is consisted of three main parts an inbound handler a state table and an outbound handler so all incoming packets to our host OS come through the inbound handler okay and based on whether that packet is destined for an open port or a closed port inbound will either respond directly to the remote host in the case of closed port destination or it will pass the packet along to our host OS kernel if it's destined for an open port and I like to use the kernel to do some of the response work because it makes it a lot less work for me with Morph I mean why not it's there already so if the packet gets passed along to the host OS kernel the host OS kernel will respond accordingly depending on how it's implemented and then it will pass that packet along to outbound handler and then the outbound handler will then modify headers or you know do what it needs to take do in order to convince the remote host that this is not the OS of we don't want to be so there's also a state table involved and the state table is useful it's a hash table and right now it has four pieces of information in it it has the source IP destination IP source port and destination port and the state table is useful for when for example we initiated a sin connection with the remote host and we need to record that information in the state table so that when the remote host responds with a sin app or no that's part of a legitimate ongoing connection as opposed to you know when M-map sends a sin app packet to us and we have to say oh well this is a you know this doesn't make sense and it's not part of a connection so that's what the state table is useful for now packet purgatory this is just more information about it it's also available for download free download and it's actually not a kernel module it's a user land process and packet purgatory actually comes in a couple of modes and let me go into more detail about that there's a proxy mode and there's a loop graph firewall mode so if we look at the proxy mode first by the way you would use the proxy mode of morph if your firewall isn't supported by LibD9 so for example if it's not IPF or IP chains then you would use proxy mode okay and the advantage of using proxy mode is that your firewall rules are blocked right so you can still maintain the same rules but promise in a nutshell if you look at the proxy mode what happens is the remote host let's say for example remote host sends a packet in inbound gets the packet via packet purgatory pushing the packet over because the LibP cap sniffing on the interface and if that packet is destined for a closed port then inbound will do a raw IP right via LibD9 and respond directly to that host now if that packet is destined for an open port then morph will actually do a raw IP right via LibD9 and then send that along to the host OS kernel the host OS kernel will take the packet and respond however is going to respond to it and then that packet will make its merry way along and packet purgatory will intercept it again via LibP cap and send it to outbound which will rewrite the packet or modify the packet so that it's proper response and do a raw IP right via LibD9 send it back so that's how the proxy mode works loop back firewall mode this is the mode that you will use if you're using IPF, PF or IP chains and what happens is packet purgatory actually blocks your firewall so your firewall rules no longer apply okay now so when the remote host sends the packet, packet purgatory is there via OS firewall blocking and then send that packet along to inbound and inbound is going to either respond directly to the remote host or pass it along to the kernel depending on whether it was destined for an open or closed port and you can see that it's very similar except this time instead of we're going to do raw ethernet writes this time because if we don't and we do a raw IP right the packet's going to go back to the loop back interface and we don't want that but I'd like to note that when the packet gets sent along by the inbound handler there's information such as like the source IP address gets changed so that like we don't actually you know we actually send it to the right place okay there are certain OS scanners that are more for full TASO, MNAP and Xpro I'm still working on pulling the passive OS fingerprinting tool and of course the timing analysis tool I'm still working on that as well but hopefully we'll get that done soon. It's worth mentioning that there have been other tools in the past that defeat OS fingerprinting for example there's FPF and there's IP personality. I like IP personality quite a bit except that it's actually written as a patch for the Linux 2.4 kernel which makes it not very portable okay not portable so my aim here with more of this is to write a tool that does OS emulation and is also portable so because I figured most of the people who are running more maybe are administering Windows systems I mean you know they want to pull people into thinking they're not Windows so I think it would be very useful to have something that works for Windows. FPF I tried to use and it actually didn't compile plainly so it's pretty buggy but it's also kernel module so and I think later on they also adapted it as a kernel module for OpenPSC so it's still not portable okay so just to summarize the techniques the active fingerprinting passive fingerprinting and timing analysis they can all be defeated with morph and you know I mean if you're running morph on your system you own that system so you should have ultimate control over what that system says okay before we do the talk about more I'd like to do a demo of more for you okay so this should be big enough fun for everyone to see hold on let me get this I have this all set up now it's lost okay hide that again all right great okay so what we have here is we have our host here that is running morph and what I'm going to do is I'm gonna do an MAP scan from this host first against this host without running morph and let you see that it's a Linux 2.4 kernel host and just to make it quicker I'm going to pick one open port and one close port okay so you can see based on the scan that this is a Linux 2.4 kernel host now I'm going to run morph on this host let's make it Windows 2000 run MAP again right so now you can see it says it's Windows 2 Windows host okay so now we're gonna run this as open dsd and there we have it says open dsd so that was the demo so now you have a much better idea of what morph is doing right anyway so now I'm gonna go into a little bit more detail about the implementation of morph based on how different OS scanners behave there's case though which I chose to start with because I thought it would be the easiest case to start with and it actually sends seven different packets to the remote host to the target host and all of those packets are destined for open ports and they're all TCP header type packets here I put together a table that shows what morph does behavior wise to those different packets that are sent by case though most of the cases aren't very interesting for example I'm just going to go over a couple of them for fin packet if you're running Windows Windows will respond to a fin with a reset okay now if you're running you know Linux or open dsd or something you just won't respond to that so in this case we have to know that okay we're trying to emulate Windows so we need to have inbound you know respond directly to that packet because the underlying portal is Linux and it's not going to respond to that packet so we have to you know be able to convince the scanner and by the way just in case anyone got the idea that morph only deals with the packets sent by scanners that's not the case morph is actually designed to deal with every single packet that it receives okay so it's a total solution to behaving like the OS that you want to be and the reason why that is it's because if you plan on pulling the passive OS finger pointing tools and you only deal with the packet sent by you know scanners then you're not going to be convincing in that factor now expo to what's the next tool that I chose to work with because most of those packets sent are ICMP informational type packets and that's pretty easy you just have inbound respond to those informational type packets all the time so you don't even have to loop it through the corner or south so ICMP headers four different types one of those is really interesting is a information request packet and so of course I was like what's that so I look at TCP IP illustrated volume one read that section and it says it's obsolete okay so I'm like well what's going on how come they're sending obsolete packets who's going to you know deal with that so I look at the finger point file for Xcode 2 and found that like AIX deal with that so I'm like hmm not very modern are they you know so that was an interesting case for one of the cases and of course Xcode 2 also sends a UDP packet for ICMP on mutual and also a vanilla send pack regular send packet and here's the table again for how more feels with Xcode 2 you can see that it's not horribly interesting most things are responded to kind of like what you would expect now and map I chose to save for last in this process so far because it's actually the most complex of all of them and oh I didn't mention about Xcode 2 but you know how Xcode 2 does the fuzzy fingerprinting technique where you know it determines what percentage chance there is that your target host is this OS so it doesn't have to have like an exact match in fingerprints okay it just has to have like it does percentages and I was like hey well that's actually a joke itself because it makes it easier for me like writing more to like pull that because all I have to do is be approximate I don't have to match exactly like I do with Nmap so I like the fuzzy fingerprinting idea but from the standpoint of trying to frustrate OS standards you know makes it easier but okay so Nmap needs open ports and closed ports in order to be as successful as possible in making it determination so if you run Nmap I'm sure most of you have and you look at like the messaging and it says okay TCP sequence predictions want to be more difficult that type of message that's because you know couldn't find open port or something like that and then half of its cases doesn't work so that's why that's a problem Nmap is challenging because it has to be exact match and if it's not an exact match then it's it's out I don't know send me this fingerprint you know and I'll figure it out there's nine different types of packets five to open ports and four to close ports and here's a table for Nmap you can see on the left that I have the open port section and then the close port section and most of these cases well obviously all the close port we're going to have inbound deal directly with responding to it and the open ports know it's just none of the flags are set a simple urge push that depends on what OS you're dealing with some will respond to that and some well but that's the cases for Nmap now I mentioned the morph state table and I hadn't actually gotten into a lot of detail about it yet but the state table as I mentioned earlier is very useful for maintaining session state but it's also going to be useful for doing things like sequence number generation offsets and the reason why that is is if you're running an underlying OS like open BST or Linux where your sequence number generation is truly random and then you want to emulate Windows 2000 where the sequence number generation is not truly random it's randomly incremental and so what are you going to do in that case let's say our underlying OS initiate a connection so it's a sim packet goes out via outbound well but that sequence number was randomly generated because our underlying OS is Linux but we're trying to be Windows so what we're going to do is outbound is going to generate a random or as random as Windows can be number okay and then take the offset between that newly generated number and the number that was generated by our underlying OS and save that information in the state table so that the remote host will think so think that this is Windows and when the remote host replies with the syn app you know then we're going to take that offset information that's stored in the state table we're going to apply it to that number in the acknowledgement numbers so that we can stay consistent within the underlying OS so that's one of the useful other useful things that the state table can do and the state table will also be used to deal with timing analysis type of scanners because when you have a certain OS that you're supposed to emulate and a tool like ring is looking for how often you're retransmitting certain packets that you need to know what the timing allowance is for the OS that you're trying to emulate so you can be consistent in retransmitting those packets and I've had people ask me before so what do you do if your packets get retransmitted in X amount of time let's say and then you didn't get it retransmitted fast enough to meet that time that you're supposed to well I always tell them it's okay because packets are always getting lost anyway so what you just do is wait for the next opportunity that comes along to retransmit it so don't worry about the one that you miss opportunities okay as I mentioned I'm still working on the passive OS fingerprinting by default that is looking for sin packet information so I'm looking at that right now and the timing analysis analysis timing packet timing analysis stop or ring and also I mentioned snap time because that was a tool that I found which uses timing analysis and also some properties of passive analysis and actually implemented it so that it's downloadable and installable so it's not proof of concept now earlier this year at Kansas West there was a talk I don't know how many people here were there did you see that talk yeah okay couple people so most people haven't but I believe the guy who did this talk works at NFR or something and he was talking about new fingerprinting techniques and it's not like the new techniques are beyond you know active or passive or timing analysis they just expand on those areas more in ways that haven't been done before for example he'll use layer 7 information and how does he do that for example he'll send you know like an HTTP get packet over and then see like what kind of you know the host will respond back to that and then he'll drop that packet and the host will retransmit and apparently when application level packets get retransmitted by a certain host OS it's different timing intervals than like when it's like TCP header retransmits okay so he'll use that different information from the applications to make his determination on what OS is so that's pretty novel because that hasn't been done before so that is actually a timing analysis expansion technique and he'll also do things like measure window behavior under congested conditions and what I mean by that is every OS implementation has window sizes certain window sizes and those sizes are like buffers and when data gets transmitted over let's say you know Linux allows like 5.7k okay window size and windows is like 64k or something so then when windows transmits over and you're trying to be windows but you're underlying OS you know Linux then you have the problem with having to and that's another thing that I do with the state table is you having the problem of like telling people that your window size is this when it's in reality on the colonel side is smaller than that so there sends you all this information at one time and you'll be like well I you know I need to save the information the state table and kind of read off of that you know as it goes along because I can't handle that much data one time on the underlying OS side so what he'll do is he'll look at the buffer information stuff and like the target host will send a request for more information when it buffer gets read off and he'll look at the timing for that that gets sent and determine what OS it is now I keep talking about getting fingerprinted how can you avoid getting fingerprinted well I guess the hard way to do it is to try to push for a new RFC so that all these unspecified unspecified behavior packets can get addressed you know so how does everyone deal with this and try to make it consistent across all of the implementation but that's the hard solution now the easier solution is that you can place hardened critical high value target servers behind a proxy device right so that every time someone trying to talk to one of those machines that are your high value target it's actually talking to the proxy device and all they can do is figure out the fingerprint the OS for the proxy device and not the guys behind the proxy device and if you're really really paranoid you can do that setup and then you can like you saw something like more on the proxy device so that they'll never know what any of those OSes are now there were a lot of challenges to implementing more and one of them is the different window size than what the underlying OS is like I was just talking about so how do you deal with you know if you're underlying OS window size is smaller than what you're advertising to the remote host I'm having to maintain connection state to determine whether something normal or not it's a challenge even if you run more okay so you're running more and if someone was like a casual attacker and all they cared about was just running a mass scan out there to see what OSes are available so that they can start targeting specific hosts after that information then more can help you with that but if they've already decided that they're going to target you and they're going to run you know application scanning or you know like a poor scan against you and they see that you're advertising that you're open BST but you got not files for it's open well more physical to help you there okay so it's good for casual attackers but it's not good for you already a target a serious target also there are exploits out there like the names are warm which doesn't care who you are I mean it's just going to go around and knock on every single door and if your windows well running morph isn't going to help you there and I want to emphasize that morph is not really like a security solution a complete solution all it is it's one additional layer that you can use so don't think that this is the overall solution what would I like to do for morph in the future I really would like to support more OS simulation I first of all I'd like to get Linux in here I want to build more compiling some more fun windows the challenge with that right now is that more open close port determination implementation it's not you know it's not like windows compatible right now so what I was thinking was that I could use a positive compliant like I could use open bind and close and those are positive compliant and I'll be able to use those to determine whether a port is open or not by saying open you know a port and if it succeeds then that means that the port was closed so close it back up and now I know that the port was closed okay and if I and if it doesn't open it fails then I know that the port was actually open so based on that information I can like determine whether reports open or close now there's going to be some computational issues with that but I'm still looking around for how I'm going to do this for windows obviously I'd like to for other standards like the passive OS fingerprinting soft and timing analysis type scanning and everybody wants to add gruries to the stop side guess I'll add a gooey to more all right these are some people who help me out with more in one way or another Todd wrote packet purgatory which was immensely useful to me and some of these people looked at my slides and made suggestions and stuff and other people like call me from Kansas at West to tell me what it was like you know okay so now we have the question section and I'm going to invite Todd up here to help me out any questions the question was what type of network congestion or performance costs does more have okay I did like a SCP on my local network with more host running morph and it took like almost eight seconds to do it when it's running more than like about four seconds to do it when it's not running more but that's on a local network now if we're dealing with remote connections then we're going to have a different picture it's going to be a lot less noticeable because you know it's a remote connection this time did you program morph in such a way so it's easy to put in new OS spoofing implementations are the US implementations that you're spoofing hard-coded in right now or is it pretty easy to put in new spoofing um yes I program morph so that the different cases are hard-coded in right now but I'd like to eventually make it a reference table implementation so that it's easier to scale with all the different fingerprints and stuff the map has and things so what's the server overhead on it I actually haven't tested that so I don't know do you mean like network overhead or CPU CPU overhead yeah I haven't tested that can morph be used with a firewall at all yeah if you want the firewall rules to apply instead of getting blocked then yeah you can use morph under the proxy mode and then what are your thoughts on the feasibility of evading timing-based attacks well I think that if I'm going to be able to make more a more comprehensive tool I'm definitely going to have to evade those timing analysis attacks I talked about how I was going to use the state table to store that information between the timing of the package so that I can do that and I don't think it'll be very hard to do but I actually haven't implemented it yeah so I'll see when I ask you do when morph is running in proxy mode does it pass the packets directly to the kernel or does it make more of a local tunnel collection connection that's more of a packet purgatory question I mean to get that okay right packet purgatory when it's doing proxy mode is actually it's changing the source IP address so the packet comes in remote to the proxy gets rewritten so it's proxy IP to local response goes from local to proxy and then it goes back out from proxy to remote the question was if you've got config file that restricts connections on the local subnet what happens fundamentally yes if you're running if you're running packet purgatory in proxy mode it's going to look to your local machine like it's coming from a local machine and so you got to think about that that could impact your security policy yeah the question was since we're going to the trouble of emulating certain OS packet based behavior how difficult would it be to add in additional stub services so it appears that we're listening on that bios even when we're not actually okay I don't know if you saw on the slide but I had in parentheses after the application scanning stuff polymorph which is a project that I'm looking at working on max which will deal with them and maps application scanning capabilities so I haven't started that yet so I'm still thinking about that but I think it's definitely worth looking at possibly implementing something to full application scanning that that's honeyd in a nutshell I don't want to re-implement honeyd this more also emulate the time to live on the packets of the operating system oh yeah the time to live is some in the TC in the header so yeah more for actually modify that if it needs to depending on what OS you want to emulate you talked before about implementing morph on Windows what are your plans for that well as soon as I can figure out like writing the code for doing the open close port implementation determining whether the port is open or closed I'd like to do this under like a sig win environment but I have to spend some time doing that first what's the commercial motivation for implementing morph well I don't know that I was thinking about the commercial motivation it's been a wonderful learning project for me and I really like working on it because I think it's really cool now commercially it's PSD license so people can do whatever they want with it that they you know feel like doing so I guess that's the most commercial aspect of it okay well I gotta go so thank you very much