 are going through them in a particular order, I would prefer to hear your ideas and your questions because much of what you see up here derives from all the good ideas that have been discussed throughout this conference in the talks and in the conversations. In fact, a lot of what you see up here is a result of those things happening at this conference because I rewrote the slides this morning. So we're going to talk about a couple of things related to host-based intrusion prevention on Windows and Unix. And I'm not going to try and define what those are. I think the community, by developing the intellectual property, will define what those are as we make advances. And I want to recognize several people for the contributions that they've made. Neal's Provost is at the University of Michigan, he's a graduate student, and he's published several tools, one of them CIS Trace that we're going to look at closely. And those are currently in OpenBSD and NetBSD. And there's code on your conference CD to support FreeBSD 5.1. And there's more code on his website to support FreeBSD 4.8. And we'll look closer at that. T7 with the Razor Team has a similar components for Windows that provide intrusion prevention. Slightly different approach in terms of the way it integrates with the system, but very similar functionality. I'd like to thank DT for suggesting this thread last year in his call for papers. There was a call for a talks on how to harden FreeBSD. Last year I gave that, and the gap analysis of that showed a real need for something that increases the integrity of the system that all of the rest of the security architecture depends on. I'd like to thank Greg Hoglund for many insights about application security and looking at application state and the code at the binary level. MD5 at the Ghetto Hackers reviewed a lot of this material about how intrusion prevention looks like firewalls in some ways. That was a great metaphor. Gotroot.net helped me find exploits such as SHH for the demo and finally FreeBSD Mall for all the free stuff that we just gave away. More about Neal's provost. He's written a tool called SysTrace. What it does is it catches system calls and alters their behavior. It supports OpenBSD and NetBSD. He's also written something called HoneyNet that supports the HoneyPipe project. And all these tools you can find on his homepage is listed right there. Okay, so in the abstract for the talk I mentioned a couple of things. Why should we care about intrusion prevention? What does it do for us? And we'll look at how it works and how it is consistent across the platform because of architectural constraints of the way kernels are put together. We'll look at some common features and talk about what's missing. So why should we care about intrusion prevention? One way to think about this is to look at an analogy of the layers of network security. So if you look at layered network security you'll find rules and routers and firewalls and services at the router level, firewall and INIT-D or TCP wrappers. And each has a distinctive performance advantage because of the kind of objects it's dealing with at the router level dealing with lower layers of the protocols and doing a lot of filtering at the firewall. If you have those rules in the router you're dealing with higher layers things that are more specific to individual sessions and at INIT-D you're looking at services that have successfully connected and the context of where they're coming from and who they're coming from. So each of those has a different specificity in terms of the context information and each has something that contributes to the performance of the next layer. So if we look at the host side there's a parallel structure there of information flowing through the app through the kernel to disk and applications explicitly use authentication methods have rules for when to allow access and when not to the kernel does the same thing enforcing permissions and the file system does as well at each layer you have different performance advantages depending on the kind of messages that are coming through and each has a distinctive advantage at the disk at the file system layer you've got access to individual objects and permissions specific to the object so in terms of specificity specificity of rules at the application you have rules that can be specific to the session or the connection or the kernel rules that are specific per system call and the file system per file or other object each of these layers depends on in a lot of cases the integrity of the other layers the file system permission assumes integrity of the application and kernel the granularity of system call permissions affects what you can do in an application so you depend on the granularity of the semantics of system calls to decide how you're going to enforce security in your application the problem is all of this depends on the integrity of the layers around a particular layer and it's very often that applications or services run as root and if that integrity is not held the architecture doesn't do you that much and this is this is compounded by advances in the various layers encryption fragmentation re-encoding all of these can prevent application layer filtering on the wire and that's why we're going to look at this in terms of the kernel being a gap and the ability to preserve integrity of the system and the application why would we do that there it's through the application that your data is going to reside there in memory and exploits are going to go through there to get to the disk so visibility in the application layer also provides the ability for better contextual discrimination when you have an incoming connection you have IP address of the client maybe a domain name once you're inside the application the application is likely going to be collecting other kinds of information about the session about what permissions have been authenticated and you can leverage that contextual information about what the application has established to enhance what you can do to block exploits so why would we need another tool to do this when we have all the other layers already we can think about this kernel level system call filtering as like we do about firewalls as an application level firewall that enhances what you do at the router and downstream what you do in TCP wrappers a lot of exploits are going to attack through service and demons and without enhancing the protection against buffer overflows and everything you do inside applications the system is going to look crunchy on the outside soft on the inside the problem is application state is very complex the state of memory disk, clients on the other hand all that contextual information allows you to write signatures that are application state specific specific to the state of the US you know within the context of a process there's all sorts of system information that you can rely on that perhaps should be consistent each time an application runs or for each session and these contextual clues that if they are consistent from run to run allows you can allow you to block from the inside of the system inside the application so let's look let's look at a specific example on free BSD how it works and what's the motivation for doing this we're going to look at an SSH exploit it's an off by one channel lookup an SSH 2.9 and it was current and all the BSDs at the time the exploit occurred and the gap analysis for this was that if we can't rely on something a hard, relatively hard application like SSH what can we rely on and what can we do to prevent exploits on something we would usually trust so the stuff being done by root is at the top of the screen the stuff being done by a client user is at the bottom so this is an example of setting up SysTrace to filter system calls for the SSH team and at the very top you see a directory that SysTrace looks in to find all the rules the rules that specify whether to permit or deny system calls the second panel we've invoked SysTrace with a capital A in order to gather all the system calls and it'll watch watch those system calls and spit out a list of what's what the application does so here on the bottom we're logged in as a user we've got SSH demon running and we run an exploit here the exploit uses exploits this channel lookup the exploit payload listens on port 11520 for a connection so that's what the payload is doing then the client side connects to that port and the payload folks say root shell and there's a message from the authors that's part of the source for the exploit so just to make sure what our context is we have a root ID and we see we're root oil group and PWD shows us we're in the root of the file system so what can we do to modify this to block that exploit well here we stop SSHD and when it exits SysTrace generates a file containing all the rules so there's the file right there user bin SSHD and we'll look at what it contains here what we'll see is a list of system calls these are all the system calls that SSHD invoked you see all names of all libraries so it gives you all the file names that it needs access to to run and down at the bottom of all the permissions you see something interesting it's invoke bin SH so that's something that SSHD you know fundamentally normally does but we can tune it a little bit by adding a condition let's change it so that it can fork a shell only if it's not root so what happens when we change that rule we'll invoke SSHD again with a minus little a that means apply these rules with a default deny policy a system call that it hadn't made the first time is going to return an error so invoke the exploit again the client side binds to port I'm sorry the payload binds to port 11.5.20 a client side connects to it it tries to fork a shell as root and a system call returns an error and they close the connection so that's the model that's the fundamental motivation for doing something like this to add another layer to the security inside the host that does a couple of things in this context we're looking at SSHD that's normally one of the most trusted applications in this instance it's an off by one error in channel lookup that's buffer overflowed and elevates the user to root it was in all the BSDs as we just mentioned before the demo what can we do if we can't rely on something as trusted as SSH what can we do to prevent this as we see and saw in the example we're doing something there specific to the payload not the injection method and that's slightly different than what's happening at other layers it's a unique way to recognize what's going on in the exploit rather than being unique to aspects of the injection but for each of those if there's contextual information that's usually consistent we can use that to form rules that narrow the footprint of the exposure of the system what kind of contextual information do we have inside the application we've got network identity of the client the IP address of the source of the connection a lot of times we have user identity either on the client system or user identity inside the application we've got application state we've got information about what was done to authenticate the connection we've got information about workflow we're in the we're in the state of the processing we are and we've got the advantage of being orthogonal to methods that are applied in other layers so MD5 suggested a look at firewall wizards discussion and they were saying that intrusive prevention basically looks like a firewall at first I thought this looked like a kid with a hammer everything looks like a nail but they have a good point you've got messages come in messages that go out and rules that decide what gets discarded in a firewall that's packets and sessions and the host by side is analogous to that you can look at it as API calls but even more fundamentally when you make a system trap when the trap occurs you've just got data sitting there this is called a number you've got a bunch of arguments there in memory so you've got a packet of information so where for the network you have packets IP packets and signatures on those host-based side when you have a trap you've got packets of syscall information so you probably wouldn't consider running on this network without a firewall would you and it's not that firewalls are the only essential thing it's that they allow you together with the other parts of the security architecture to mount an effective defense so I would look at intrusion prevention in the same way that it's not a it's not a solution in itself but it's a way to tune all the layers together to provide something effective so where is intrusion prevention going and how is it different the firewall wizards distinguish intrusion prevention from other kinds of firewalls and that they use signatures rather than rules take a lot of more state information but these aren't the same kind of rules that you might run an intrusion detection system they're more in more cases they're signatures as forms of access control so consider snort with hogwash that's the sort of signature-based firewall they're talking about and the ID&S vendors call this and gateway IDS and again that's why I don't necessarily want to try and give you a definition there's a lot of creativity going on out there and I think it's up to the community to decide what the effective boundaries between the layers are and what the effective architecture is so firewalls are complementary to routers and identity intrusion prevention can be a firewall system layer the intrusion prevention filters messages basically data, sting, and stack or memory when you just a trap interrupt and the intrusion prevention can use signatures to recognize rather than the injection method the payload the behavior of the payload so how does this work some architectural layering in windows and in unix so here's windows kernel architecture, user land it's a little bit different from unix in that they have micro kernel architecture and a few more layers at the top you've got executive services that's where most of the sys calls land first takes the traps routes the messages and you've got an NTDLL in some ways kind of like libc that takes an API call turns it into a trap that's basically what I just said in the bottom half executive services at the top a bunch of top level services that abstract away the hardware for various objects at the bottom from hardware abstraction layers end in homer right next to page up and page down okay so this is a example of linux system architecture it's similar in some ways especially the boundary between the user land and kernel they've got libc up there between the applications and the trap which is represented by the dotted line below that you've got the system call interface that interprets the information associated with the trap turns it into access to the various modules there you've got some layers but most of the layers are specific to certain kinds of resources in the case of linux and this is simply a fact of the architectural decision to use a macro kernel architecture so what are the common abstractions here we've got a common abstraction and a layer between applications in the kernel and between most of the kernel and the upper side above the trap each of these layers provides some unique contextual information while we're going to look closer at this particular boundary you can apply this principle to all the other layers this just happens to be a convenient place to do it because it's a because the method is very consistent across the various OSs so comparing this highlights the similarities you get a C library on top and something on bottom that interprets the traps and turns them back into calls to services in the kernel so even if we consider the application a black box even if we don't look at contextual information specific to an application we still have contextual information at these various levels contextual information API calls in libc where we can trap contextual information when the system calls invoked and we have trap into the system call interface and lastly at the instruction level and all of these are all these have distinct advantages so what's being done today is really something that's the tip of the iceberg we're looking at the most convenient place to apply these principles so as X points are advancing in terms of capabilities there's a lot of focus on escaping IDS or using exceptional behavior to get in and I'm somewhat delusion with IDS and this provides a way to take an entirely different approach and so you can make an approach because it's independent of the transport can be independent of the transport and independent method of ejection and it can be specific to the state or behavior of the application and the behavior of the exploit payload so in terms of gap analysis when you implement layered security a lot of the host security depends on the integrity of the OS and this assumption is made even when you have very complex or vulnerable or untrusted applications things like Netscape by E, Binds and Mail even SSH exploits are advancing just as rapidly as the defense is and those advances are often gaining capabilities to circumvent existing layers using encryption, fragmentation, re-encoding so added layers is common way to enhance protection the system call rules have a distinct advantage in terms of being specific to individual system calls and you can use them to enforce permissions but you can also use rules to alter alter system call semantics alter what the system call does and how it does it so what we saw in the example was we first invoked the SSH team to generate a set of rules to allow or disallow individual system calls so by default we invoked it once and got a list of what it normally invokes and this narrows the footprint of interaction with the system so that later on if we invoke it again and does something different that's outside of that footprint it's blocked and we can refine that in consideration with the other layers reduce the dependence of the other layers in fact we can reduce the dependence of other layers on the permissions they need for example you can rewrite bind call bind to a socket so that you can open a low low numbered port without being root and then perhaps not have to run a service as root so being out changing the semantics so that the application needs less resources is one way to move the specificity of the rules to the layer that best supports it we can also rewrite system call arguments we'll talk about that a bit more some of the implementations use pop-up dialogs similar to what a firewall does and this is a big advantage in terms of being able to generate a first draft of your rules and not have to close all the gaps immediately and it takes advantage of a default ask policy so rather than just permit, deny you've got default and ask I mean you've got to ask this allows gaps in the rules allows you to incrementally delve out the rules as you observe the behavior and allows you to interactively iteratively tune the specificity furthermore in addition to permit and deny and ask you can log exceptions exceptional calls or interesting calls divine rules for interesting calls like fork been a s H as root and this permits improved reporting also permits logging interesting contextual information so when fork been a s H occurs as root grab the client user IP domain and application state so the next couple of slides talk about how this works in practice for a lot of applications things like LS find a lot of other a lot of them use around 25 system calls really relatively heavyweight applications like browsers email clients with a rich interaction they can use up to 60 and this is out of a total of say 250 for Unix and I don't even know how many there are in windows couple thousand and as it stands most the implicate most of the current implementations are generating and using rules for filenames and in some way this duplicates file system permissions and what this suggests is that there needs to be more consideration of cross layer architecture interaction of the file system productions and assist call but it also means in terms of performance impact that is that typically there's a high performance impact on applications that make a lot of open system calls in terms of using rules that do a string match or rules that use regular expressions and with the current implementations you see relatively low impact on anything that's CPU bound what this means in term well let's look at how this fits into the rest of the system one advantage of this is that the system call filtering is completely transparent to the application so the application doesn't have to know anything about or recognize anything about the system call filtering so you can use third party applications untrusted applications caveat that is that rule creation isn't fully automated yet it's not completely transparent to the user and that's where it's really important for things to be transparent and lastly that as it stands most of the tools generate rules by observing application behavior and general large part of the advantage is being able to reduce the dependence of in other layers so zero day code there's patches for free bsd 5.1 on the conference CD neil's provost has all these they are differences between this is trace and net bsd and open bsd current for kernel and user land and free bsd 5.1 it's on the conference cd it's on neil's provost homepage and hopefully will be in free bsd current soon so here's what I believe are the current advantages of these tools you got things like chrute and jail for sandboxing system call filtering does some of the same kind of thing in terms of being able to sand reduce the footprint of an application's interaction with the system and can be tuned for the footprint of each application the current tools allow iterative and interactive rule generation a lot very similar to what firewalls do it's got some limited automated rule generation in terms of tracing past invocation as the application it's transparent to the application and allows you to tune system call permissions but more importantly system call semantics you can change the system call semantics to reduce the dependency of other layers on the security architecture on their ability to enforce permissions so it's available for free bsd 4.8 5.1 right now and you can find updated versions on my website on neil's provost website hopefully in free bsd soon the slides that you're looking at now are slightly different than what's on the cd and they will the updated slides will be on the def con sites archives and on my sites and if you like you can contact me at this email address I think that's about it wow we're way early so there's a couple other things I can talk about before the questions let me make a couple more comments we looked at the system architecture there's a common architecture of the layer between user land and kernel and this is similar at the source code level for the bsd's and similar at the binary level for windows so for for these tools in general across all these platforms there's a lot of commonality in the architecture of how you implement system call filtering you've got to have a device that allows you to set rules so something a slash dev that'll you can write rules to you've got to get the module into the kernel somehow and when the module is invoked on a particular application it's got to got to have hooks to start up grab the rules wait for an application to be invoked and it's got to catch the application as it starts up between when fork is called and when the application starts up do things like fill out the system call table and there are a couple of methods of how you do the hooking but it's always going to occur between when you create the process and when it begins to execute and there are a couple of different implementations out there are we close? okay I'm told the award ceremony is going to be held in the Apollo room rather than here and that's at four o'clock it's about 340 345 35 okay so the similarities here across all these platforms are those those junction points I just mentioned between startup of the application or between creating the application filling out the process structure and starting the application something that happens when the modules loaded and some kind of architecture for a device that applications can read or write rules to there's a couple different instances or implementations of system called tracing we looked at one sys trace there is another for free BST called serve NG serve next next generation they that varies from sys trace in a couple of ways it's a loadable kernel module but they both have to do the same kinds of things in terms of where they hook in whether it's module load or if it's a static statically compiled in the case of sys trace there's a start up routine that gets called so for each of these implementations they may plug in differently but they're basically going to plug in in the same same place same place startup of the module startup of the application and something that happens at the sys call at the time of the sys call and because we've got a couple of implementations out there I have a feeling that these things are going to evolve a lot like the way the firewalls are evolving and other tools and that there's a statement by Linux Linus Torvalds recently about people lobbying to put in other firewall implementations and he's basically said I'm not convinced which one is the best or where are we going to go so what I want to do is creating API and let them all sort it out so I think that's what I'm going to try to pursue next is create a first draft of an API get sys trace and serve next generation to plug in and then hopefully let them fight it out how we doing on time okay why don't we take questions right here oh wait Mark is there a port for this for windows or yes yeah that was there's a reference to it and the acknowledgments and it was written by one of the guys at bind view with the razor team I'm sorry to there's there's two implementations for BSD there aren't any yet for for Linux but if we use same current abstraction these modules there's no reason we can't use the same implementations in Linux windows we don't have the opportunity to implement those interfaces at source level but the windows it plugs in at the same places but it's got to muck with the kernel directly to hook in I mean muck with the binary so T7 with the razor team at bind view has a tool called SysTrace again I think the current version is 0.3 so same name but it's four windows and it's on bind views bind you to site I believe it's more or less open source license I was going to ask you in the next version of windows in Longhorn they have something called next generation windows protection services which is Palladium which is actually exactly this actually Microsoft is trapping all API calls and generating rules for them based on whether they have like a signature or something like that unique processor ID or something of that nature but what happens when a version of the software changes and they change the API calls that they do how does the BSD tools react to that do you have to regenerate all the rules if you're extremely paranoid you probably would because you'd want to close reduce as much the footprint as possible but with windows you know in practice I would imagine you would do exactly what you do with a firewall if you upgrade a client or a service you continue applying the same rules and you catch any exceptions and decide on the per exception basis whether to add rules so with the windows tool does it plug into the NTDLL.DLL or does it sit above it or it no it plugs into system trap any more questions now the Microsoft research has a detour's library which allows you to insert trampoline functions into syscalls cool for the system and the the latest messaging vulnerabilities everybody's talking about I think one guy had approved a concept using McAfee and how he could send you know this window and then you know does this take care of that problem a lot of the windowing is in the kernel and windows but it that's not the case in Unix so imagine that would be very different implemented very differently on Unix so maybe they're trying to fix it with this long horn implementation so I would imagine a lot of that would be rather than assist call filtering and library call filtering for X windows any other questions we're good alright have fun at the awards ceremony