 I can actually start my talk now. And again, if I go over here and you can't hear me, just wave your hands at me and let me know. My name is Jeff Thompson, otherwise known as Mithrander for some of the people here who are my friends and know me. I'm a director at a company called Argus Systems Group, and I have a title, which is called Software Evangelist and Visionary, which essentially means that I get to stand in front of people like you, jump up and down, wave my arms, pretend like I know what I'm talking about. Every once in a while I do, most of the time probably not. I'm going to be giving a presentation on how to hack B1 trusted operating systems. And hopefully this will be fun for me and also fun for all of you. I'm going to be using the pitpole.com packed trust operating system product suite, and that's a big sentence, which is essentially our company's trusted operating system product as a reference for giving this talk. However, all the things that I will be talking about should be pretty easily translatable to other trusted operating systems. I'm trying to leave it fairly general so all you guys can break into trusted Solaris or Virtual Vault or some of the other fun little OSs out there. Just to tell you a little bit about the company, as I mentioned, it's Argus Systems Group and we build B1, commercial grade, B1 trusted operating systems. All the work that we do is at the OS level and the kernel level. We really don't do much at the application level. We leave that to other people who want to do things like encryption and SSH and fun stuff like that. So I'm going to ask three quick questions. We have to have a little interactive part so I get a little something out of this. First of all, I'm wondering if you could raise your hands, if you've ever heard of trusted operating systems before. All right, that's pretty sweet, I like that. The next one is kind of the kicker. How many people have actually used a trusted operating system? Been on a box, tried to hack one, say, this week or just kind of a system administrator or whatever. All right, so not quite as many. You guys need to change that and I'll tell you how at the end of the speech. The next thing is I'm wondering how many people are here who are actually trying to break the box that I brought in. It's a little, actually an IBM ThinkPad running Pitbull Slairs on there. One guy? All right, well, you'll learn something. Basically I should just mention that real quick. What we did is we brought in a Pitbull box for the capture of flag competition and we opened up a web server, put a cheap little messaging board system out hoping someone could hack that, threw up IRC, SSHD, Telnet, FingerD, IMAP, POP, Sendmail and I think that's it. And today I just gave away Etsy Shadow with all the passwords in it too so people should be able to crack those. And the point is really just to kind of demonstrate that you can give what would appear to be the house away on a trusted operating system. And if you configure it correctly, there's nothing that people can do to break into it because of the mechanisms that it provides. So my speech is gonna be composed of two parts. The first part I'd actually hope to do during a newbie session, but for whatever reason I didn't get that. So I'm gonna have to kind of roll it into here just to give some background on trusted operating systems. I'll try and wing through it fairly quickly and not go into too much detail, but just enough so you guys can understand what I'm talking about in the second part, which is of course methodologies for hacking trusted OS. I'm not gonna be giving away any minus one or zero day wares here so you can't go out and like hack all the Swiss banks and stuff immediately at least. And don't tell them that I taught you how to do this if you go do it. So the other thing is of course an assumption I make because it's the Uber Hacker, everybody's really smart speech. I'm not gonna go into actually how to hack box and per se what the old OS is, but a lot of the tools that you have, a lot of the methodologies that you use in old systems apply directly to hacking trusted operating systems, buffer overflows, things like that. However, the mindset that you have to approach your attack with is very different and that's gonna really be the crux of the speech is to try and get all of you into that mindset. So to understand trusted operating systems there's really four concepts which are worth understanding. The first is least privilege or something else known as capabilities, the POSIX capabilities model which many of you may be familiar with. An idea of authorizations, mandatory access control and the idea of putting security into the network layer. And by that I mean into the actual data on the network stack that passes through the system as opposed to just at the IP layer which would be filtering. For privileges there's two concepts that you need to understand. The first is least privilege. This has actually been written about quite a bit in a lot of security books when there's the little three page chapter on B1 trusted operating systems and they mention it as a sort of exotic thing. Least privilege is the idea that rather than having like on standard UNIX systems where you have UID zero or root which has complete access to the system that can override all security on the system it has access to all system calls. Rather than doing that you take all the concepts of what root can do and you break it up into privileges. So for example, root needs to mount a file system. Well mounting is a concept, it's also a system call. So what you do is you create a privilege which says now that this program or this process can actually mount a file system. And to give you kind of a real world example of that you can take a web server and if you wanna bind to port 80 you need to run it as root and then it'll switch to another user. The reason why you need to run it as root is not because it needs to have access to files on the system simply because it needs to bind to port 80 because it's a privileged port. So on a trusted operating system instead of setting it as root or giving it total access to the system you simply give it one privilege and it combines to the privileged port and that's all it needs. The next thing to get into is this is a little bit of a, in a coding topic is the idea of privilege bracketing but it also affects you when you're trying to break boxes and it's this, is that privilege bracketing is the idea that a process or program only needs to turn on its privileges or its abilities when it needs to use them and when it's done using them it can throw them away. So on standard Unix you wanna throw them away you become something else besides root and a trusted operating system you simply drop the privilege and now if somebody goes and breaks that program it's not there anymore and there's no way for them to get it back and so now you can limit the exposure in your code and also where you're really gonna need to focus your reviews of your code at least your security relevant reviews of your code where privileges are gonna be active and it allows you to start building much more secure software and spend time where it matters in review. So privileges, traditionally Unix has one privilege, root, you root, you have everything you're not root, you try to get root. And with that what we do is we take that idea of root like I said and break it up into privileges. So now we have things like a file system mounting privilege, DAC read privilege, DAC is just another word for permission bits or access control list it's just kind of an encompassing term and then you also create new privileges which are specific to trusted operating systems privileges which allow you to override mandatory access control rules or a great privilege here and this is kind of a hint if you can get this on a system PVPVPROC is a privilege that gives the process and ability to set privileges on other processes. So if you have that you just start giving yourself lots of nice privileges and then you can own the system. All right, processes, there's three types of privilege sets that you can have in a process and the first one is one really important to understand it's the limiting privilege set. The idea behind the limiting privilege set is that you can specify for a process and all of its children that they can never exceed this amount of privilege. So a great thing to do with this is if you have users logging onto your system who you don't trust, don't ever want to trust you can give them a limiting privilege set which says no privileges. Now no matter what that user does they can run programs that would normally give them privilege, they can do those kinds of things and when they run them the kernel will see that they have this limiting privilege set and will refuse to give them privileges. The program may continue to run but it will run without any kind of special ability on the system or special access. The maximum privilege set is essentially the set of privileges that a process can use over its lifetime and the effective privilege set is the set of privileges that the process is using at any given moment. So it can raise and lower these privileges in its effective set. When it doesn't want them anymore it throws them out of its maximum set and when it doesn't want its children to have any privileges anymore it throws it out of its limiting privilege set. Now files privileges work in a different way on files and particularly they really work on executables in almost all cases. What you do is you can put three types of privileges on files and the sets are innate proxy and authorized. An innate set of privileges are put onto an executable and what that means is when that program is run the privileges in the innate set will be placed into the maximum set of the new program. As long as they don't exceed the limiting privilege set so it's always placed against that. Proxy privileges are simply the set of privileges that if the process that execs the program runs it only privileges that existed in the process before will be passed on through the proxy privileges. So it's just saying these are what allow this program to pick up in addition to the innate set. And authorized privileges are a set of privileges which a program only gets if the user has an authorization. I'll explain what authorizations mean in just a minute. So there's lots of privilege stuff. How privileges move just very quickly is if you fork a process privileges carry across the fork so demons that have privileges in fork will still have privileges on their children. However if you exec then all of the rules for a privilege transference come into place the innate privileges, the proxy privileges and the authorized privilege sets. And to give another example of that and this has a large effect on buffer overflow strategies on these boxes is because you would lose your privileges when you exact if somebody buffer overflows a program that has privilege and right now what does everybody do? They use shell code. That's most of the assembly code that's available. While when you exact a shell the shell most likely will not have any innate privileges on it unless the administrator is an idiot and they won't have any proxy privileges for most likely for the same reason. So what happens is when you do that buffer overflow the person gets on the system through that process but they're not gonna have any special access to the system. Now to kind of go through authorizations. Privileges as I said are an attribute that's applied to a process and it specifies what special rights a process has. Authorizations are more of a user level concept and an authorization simply says that if a user runs this program they're allowed to and it's used in a couple ways and I'll explain that. One thing that can happen is that a program that's run can look up the user who's running it because it can look at its own new ID that will say does the user who's trying to run me have this authorization? For example is this user considered a security administrator or a system operator and if they're one of those then I wanna let them use me. If they're not then I'll exit and say there's an error or I'll only perform a limited set of functionality or I'll drop my privileges or I'll never use them and so it allows programs to decide how it should operate based on who runs them as well. Now there's actually two sets of authorizations which can be placed onto files and this violates the rule that I said that this all takes place in user space because these are two I guess counter examples of that. The first is access authorizations. You can say on a file that only a security administrator can run this program. Only a UID who has this authorization is allowed to run this program and so what happens is when in that program's run the kernel will look and see if the user who's trying to run it has the correct authorization. If he doesn't he can't run it. This brings up something else I should mention about processes. Like the limiting privilege set there's also a limiting authorization set and what this means is that you can put onto a process. You can say to that processor really to the kernel about the process that it can only have a certain set of authorizations. This is one of the things that we did on the box that we put out there. And anything that's coming in through INETD has a limiting authorization set of login which means you can log into the system. So you can come in through Telnet you can come in through FTP and you can do those sorts of things. However, once you're on there you can't obtain any other authorization. So if you change to a new UID who would normally have the security administrator authorization which would mean you could do lots of bad things in the box you won't have those authorizations even though you're that user. And then the last thing is the privilege authorization set and this goes back to what I was saying about the authorization privilege set just flip the two words. And what this is is a list of authorizations placed on a executable that says if this executable is run then it obtains these extra privileges and so it gets some special abilities. With authorizations you create a concept of and these are really important ones to know when you're going after a box. Kind of historically they're called ISSO, SA and SO and there can be other roles. Roles are simply a concept that you apply to your users to say that these users, excuse me, should have special abilities on the system. And ISSO is a security officer they should be allowed to change security on the system. Obviously this is a very very trusted account. SA system administrator can add users SO can reboot the system. But we don't need to give them the root abilities that you have on standard UNIX we just give them the specific authorizations that they require to do the tasks that they need to do. And how that works is that you put authorization checks on the administrative programs and these programs will then check to see if the right person is running them. MAC, mandatory access control. This is a very boring definition taken from TCSEC glossary. TCSEC is better known as the rainbow series if any of you have managed to get through all of the books not just the orange book congratulations. Actually I just have a question. How many people have a set of rainbow books at home? Has everybody managed to order them? No, all right. Well now you wanna read about common criteria which is equally a boring read. But it's good to know about. So mandatory access control is from a, I guess from a historical and a government perspective is the idea of looking at information and saying that this object on a system this processor, this file is protected at a certain level. And we all know this is things like this is a top secret piece of information. And then you look at processes or other objects that try to access that information and you say I don't care who that person is. It doesn't matter what their UID is. All I care about is that that process has been cleared to access this information. And what that means is that if somebody is in a MAC level that they can change UIDs and their access through MAC will not change. And that's very significant and makes everybody else's job very difficult. What happens with MAC is if you create a file whatever SL or MAC label is on your process that's how the file will be protected always. There's no way for an owner of a file to change this. This is very, very different from discretionary access control. Under DAC, if you own the file you can change its access controls. And the reason why this is useful with MAC is that you can also tie this into the network. And you can say I have an administrator who's connecting to my system. He has a username and password. He's really smart, he comes through SSH. But because we're using SSH we may let other people SSH in from the internet because we have regular users on our system. But we also have this ISO or security administrator who comes in from internally. What you can do is actually apply MAC labels as I said to the network layer and say this administrator coming in internally has one type of access, well full access because we trust people who come in from inside. Unless they're corporate insiders and we have a whole different set of problems. But somebody who just grabs this guy's password and comes in from the public internet we don't want them to have the same access. Under understander units, he does. If you're root from the inside from the outside from a VPN, you're root, it doesn't matter. Using MAC you can change that. And I'll explain what those mechanisms are. And again those will directly affect an attack onto a system. And kind of a corollary to this, something else that occurs is that the owner of a file cannot give access to his file to somebody else. He can through DAC, but if he copies it through MAC the file will be at least as well protected as it was when it was the original file. So only people who are cleared for a file can ever see a file. To briefly go through what an SL is. SL stands for sensitivity label. This is the kind of the security object that's used to decide access under mandatory access control in a model that is called the Bell-Lapagela model. There's two components. There's a classification which is things like, you know, probably as unclassified, classified, secret, top secret. And then there's compartments or categories. And they're the same thing, but depending on where you work or where you live they might be called one or the other. These are kind of like groupings where you might say I have a financial compartment that's being protected or a cryptography department if you're working for the NSA or very exciting names like Project A, Project B, and Project C. And SLs are written out with the classification first followed by a set of compartments. Now, how the different pieces relate to each other. The classifications are, as I said, in a hierarchical relationship so that they can be equal to greater than or less than each other. So top secret is greater than secret is greater and confidential is greater than unclassified. Compartments work differently. They're actually placed into sets. So you have basic set relationships. They can be subsets, supersets, disjoint, or equal to each other. And that's just basic set theory. Now a word you're gonna hear a lot if you start to play around mandatory access control is a concept of dominance, of label dominance. And in order for a label to dominate another label there's two things, two criteria that have to be met. The first is that the label that's trying to dominate the other label, label one, dominating label two, its classification has to be equal to or greater, which makes sense. In order for somebody to access a piece of information that's secret, they need to be secret or top secret. You probably wouldn't let an unclassified guy come in and read that. The next piece is that the compartment set has to be equal to or superset of the other compartment set. On trusted operating systems, essentially typically every object on a system has an SL and is protected by MAC. It's not always necessarily true, but typically it is. But most importantly, processes and files will always have SLs, where you're not gonna have a very good MAC system. And again, as I mentioned, whenever processes create files, the labels will be placed in the files, and when processes create new processes, the labels will transfer to the new processes. So what happens is when a system boots up it's gonna have to create the init process, process one, and it's gonna put a default SL onto that process. And so now when a init spawns off all of its children, all of those processes will have the same MAC label. Well, that's not very useful because now everybody's at the same level and it's not really providing too much protection. So what we do is we put privileges on processes or programs that are gonna run like login or SSHD. And what we do is we give those programs the ability to change their own SLs. So now when somebody logs onto the system like I do, it goes and says, hey, that's Jeff. I'll give him top secret all access to the system. He can do whatever he wants to to me. But when someone else comes in, they can get a different level and that allows you to put people at different levels in a system and isolate them from each other. And I'll explain how that isolation works. This is how mandatory access control works in the Bella Padula model. In order for a process to read a file, process has to have an SL that dominates the SL of the file to read. In order to write to a file, a process has to be equal to the SL of the file. Not dominate, equal to it. And now I'll give you an example of how this applies. If you have a system and you place every file in the system at implementation low, which is the lowest SL you can have on a system, that means every SL dominates it and thus has read access to it. But then you go and you put on login, you say every user that logs into the system places them at confidential. Well now every user who comes on a system has read access but they don't have write access to any files on the system. No matter what user ID they become, no matter what they do on the system, they only have read access to the system. Processes have two other SLs applied to them and there's concept of minimum and maximum clearance. And what this means is simply that the process's effective SL can go between these two ranges. And in fact, the only way for a process to change its effective SL is if it has privileges or it has access to an administrative program that will allow it to change that. Typically you don't give people the ability to do this because you want to lock them in at a specific SL so that they can't get out and change other pieces of the system. And secondarily, directories and devices have a second SL which is called a maximum SL. So they'll actually have a minimum and a maximum. Files are single level containers. So they have one SL, that's the SL that they're protected at. Directories can have lots of files in them. These files can be at different levels. Illumination low, top secret all. So you might put a range on a directory to allow people to put in more types of information in there. And devices are the same way. Some devices you may want to allow many people to connect to. Other devices you only want one person to connect to like DevKMM. Now just to show here, this is the kind of a logging example. What will happen on most trusted operating systems is they'll have database which will store its security information, like a clearance file, which will store a minimum, maximum clearance and then a default SL that someone would log in at. And under Pitbull, it's stored in SE Security Clear and other trusted operating systems it's elsewhere. Also, login and some other programs may give the ability to a user to decide a session level that they would like to connect to the system at. So here we say, set my effective SL to other SL AB. They can request that. If you want somebody to always and only log in at one SL, you make their minimum, their maximum and their default the same. And they're locked into this compartment. All right, this is the last bit on the trusted operating system part when we get to the interesting bits. This is very important because it's significantly different than any of the other mechanisms on standard Unix. And it's the idea of putting access control information in the network layer. Not just at the IP layer, but all the way down through under SLARIS it would be streams for whatever your data flow model is on the OS. And you can place rules on the system which say if data comes in from a specific interface from a specific host over a port using a protocol, basic firewalling rules, then you apply security labels to that. And then what you can do is restrict processes running on the system based on their SLs who they can talk to because of the security information. And you can also restrict how information go out and how information come in. And this is different too than under Unix because what happens is once you get, when you're in a system and you do filtering you can say either people can get in or can come out. But you can't say I want to allow this process out but I don't want to allow that process out. So you can do some pretty interesting things with that. This is a very basic example of a network rule. I've caught out a lot of some of the extra stuff that doesn't matter for this talk. You can see from the top part that it's essentially a standard firewalling rule. We specify ports, not mask. Here we're looking at 192.0.0 network and we're looking at TCP protocol. The next part that's different though from a firewalling rule is the idea of specifying a minimum and a maximum SL range on this interface or on this rule. This is the types of data that you allow to flow out of this rule. So here basically we're saying anybody can send information out through this that applies to this rule. However, a very important piece is this default SL and here it's confidential A. And what this does is it's saying that every piece of data that comes into the system will be marked at this level. So now processes have to dominate this label in order to be able to read the information to be able to access it. And here's a big blocky diagram kind of summing all of this up to show you why this actually means something. On this we have two processes running. We have a web server and an SQL server. The web server is running at confidential HDPD. HDPD is a compartment. And we also have an SQL server running at con SQL. One of the things right here is you'll notice that the SLs are disjoint from each other. And what this means is that the web server can't access the SQL server. It can't access it over the network internally and it can't access its files because here I'm assuming that the files are protected at that level. Another thing that we can do is place the web server's files, its content, its binaries, CGI programs at confidential. And what that does is it gives the web server read-only access to its files but not write access. So now if somebody comes in and breaks through CGI bin programs that are written poorly, which happens on occasion, then they're only gonna have read access to these files and they can become root, they can become ISO, they can become any user they want to, but they're locked into this Mac compartment that only has read access to the files. So very quickly you have a read-only web server and that's just a very simple application of what you can do here. And then basically what the networking rules do is it allows you to set up these data flows, for example here on port 80 to the web server that allow some people to connect in and keep other people from connecting. So for example on the main interface we have port 80 icon HTTP, which allows, it's a general rule which allows anybody to connect through that port at that level. But the interface default is confidential default, which means that anybody coming in through this interface will get marked at that if they go anywhere else besides the web server, which then means they can't talk to the SQL server. But it's not so much the filtering aspects that are important because you can do those, you can accomplish those things with firewalls. It's the fact that you can now isolate your processes and your subsystems from each other, which we did a whole lot of on the web, on our system that we're letting people hack. And you can trap people in these. All right, the fun stuff. Hacking B1 trusted operating systems. The first thing, and I mentioned this before, that you have to do is you have to change your mindset because what you're attacking is not the same. And the types of attacks that you would use while it might yield some kind of access will probably not yield the type of access that you're usually going for. Keep it in your head. Root in UID0 has no special meaning on these systems. UID0 is no different than UID1024. Access to files, anything that you're trying to get to is controlled by both DAC and Mac. So when I start talking about you need to have this type of SL or this to pass a Mac check and I don't talk about DAC, it's because I'm assuming that everybody already understands how permission bits work. You have to pass both checks, though. So now, if you get past Mac, which can only be done, excuse me, by obtaining privileges, then you're still back to the standard DAC problem. You have to become user or you have to obtain privileges in order to circumvent DAC. All right, the corollary to root access on a standard system. What root access is under a trusted operating system is essentially having access to all administrative commands. That they'll let you run them and do whatever you want to do on the system. They'll let you give you all the privileges. They'll let you change files. If you can do all of those things, then you really have complete access to the system. So now you're not so much going after a UID as you are going after authorizations or privileges and also getting yourself to a correct SL. So now we have new problems when we attack a system. You have to figure out what are the files or what is the information that you're going after? How is it protected? How can I get to the level that it's protected at so that I can access it? If I just need to read it, it's one problem. If I need to write to it, it's an entirely different problem. And then how can I get the authorizations that I need in order to run the programs that I need to run to do this? And of course, if you can figure out some great way to hack a process that happens to have all privileges on it, then you're pretty much done as well. Set UID programs aren't quite the juicy target they used to be because set UID under trusted operating systems performs one function. What changes your user ID? Well, you can become another user ID that might give you more authorizations on a system because the user ID might have them. But if the system's set up correctly, you're probably stuck in a limiting authorization set where you can't get them, like we did on the machine word, letting people try and break into you. And the thing to remember is is when you're going after a set UID, you're not gonna be changing your SL. You're still gonna be locked into this level and isolated from the rest of the system. Even though you might all of a sudden start passing DAC checks, you're not gonna be passing the MAC checks. So now what you need to do, instead of looking for set UID programs, is look for executables and daemons that are running with privilege, with special access. If you can find those, those are the programs that you need to break so that you can obtain the privileges or the authorizations that you need in order to get into the system. There's kind of two ways to go after privilege programs and obviously there's more than this, but I just wanna talk about two because they're a little bit different because of trusted operating system natures. As I mentioned, buffer overflows will create a shield, a shell, will not yield privileges because you're doing an exec and you'll lose those privileges. So now what needs to happen is is people need to go out and start writing new shell code. The shell code needs to do a little bit more creative work. It's gonna have to go out and find authorization tables, modify those, modify clearance databases so that you can log in at a level that you wanna log in at and modify network labeling rules so that if you come in over the network, you can gain access in the way that you'd like to. One of the first things to check and to be on operating system and don't bother checking on PITBOL because this is not a problem, but it's still worth mentioning because you should look for it is the idea of trusted library paths. On some systems you may have run into a little issue if you run a set UID program and you can specify a, or a program running as root and you can specify a library path to look for libraries. You can get it to use a different library than it was intended to. In other words, you can say, hey, use this great library, run slash temp instead of slash lib. Well, if you can do that, obviously you can get a program running as root to do whatever you want it to. If you can get it to run commands or anything you've written in the library. The same thing is true of privilege programs. It's the same kind of attack. It's just now you're going for privilege programs. So it's really quick and easy to check, setting the environment variable path and see if that works because if you do that, you have access to the system very easily and without a whole lot of creativity. And if you can't do that, then you need to find locations where libraries are located and try and get some in there and get people to use them, which is an obvious attack. The thing to remember now as well is because before we used to play set UID zero on programs that we needed to do special things. Now we have limited privilege sets, which means that if you're going after the mount command, it's only gonna yield the mount privilege. It's not gonna yield special file system access. So lots of programs that we may have normally went after before are not going to be yielding the type of access that we want. So now you have to be a little choosier over the programs that you're going for. Though, of course, if you can get a privilege that lets you insert curl modules, that's great and you can get everything else from there. And the last item on the last slide, which I should mention too, is probably one of the most important things to go after are processes that give you the ability to override security checks, mandatory access control and DAC checks, and also very importantly, processes which have the ability to set privileges on processes. This is clearly one of the most important privileges that exists. And if you can get that, then you can give yourself whatever you need to do the work that you want to. Getting files into system directories is a little trickier. It's not just becoming the user ID. Now you have to be the right SL to place information in there. And you can look at directories on a pit bull system, for example, with a program called SECLS. Minus S gives you the SL on the directories. Some directories are gonna be created multi-level, which means they allow a range of data to be placed into them. So if you're an attacker and you exist in a range that allows you to put information in there, like say, for example, slash live, they don't make it, it's not made a single level directory, then if you're an attacker, you can put information in there if you can pass the DAC check, which means all you have to do is guess maybe the root password or an ISO password or somebody who would have right access into that directory. Now all of a sudden you went and circumvented MAC checks. And now you can make your libraries or things in Etsy or wherever it is that you're going after, available to other people to use and break their boxes with. Single level directories are a little trickier because they force you to be specifically at that level to do this type of work. So one of the first things that you should do is search a machine for multi-level system type directories, then it becomes really just the old problem of becoming that user ID. The next thing is if you have a multi-level directory that has a range on it that you fall into and you can become the user who owns that directory, you can also remove the directory and thus get rid of the files that are underneath it. And this is significant because there can actually be files in the directory that you wouldn't have access to you, but you may want to replace. Like for example, in Etsy, there's a little file called Shadow. And that's usually protected at the highest level the system can protect it at. Well, if you can become implementation low and slash Etsy is a multi-level directory from a below to TSO, you can blow away Etsy, replace it, put a new Etsy in there with a shadow that you like. And again, now you have more access to the system or the security clearance files or things like that. And you can replace a lib. The attack applies obviously to all directories. And again, this allows you to circumvent the mandatory access control checks placed on a system. Obviously it's very important to get a new SL because chances are the SL that you log into a system is not one that you want, but one that the administrator wants you to have. So start looking for ways to change it. There's a few different ways to do this. You can set it, sometimes in systems you can set it for your session as I mentioned before or you can ask you to a new user which might change your effective SL. And you can also leverage networking connections to get to new levels. Setting your session SL can be done through a couple different ways typically. For example, we have a program we call Trusted SSH which is essentially a Trusted Operating System Aware SSH that lets you specify your effective SL. One thing though again is that your effective SL has to be within your minimum maximum clearance as specified in some sort of clearance database unless they've implemented it in a very, very broken way. Another example of something that can be used to get different access on a system. If you're able to get user passwords, this is true on a pit bull system. If you do an SU dash and you're saying I wanna change this new user, your effective SL will be changed. So if all of your system files are protected to implementation low, you get the root password you do SU dash root and his default clearance is in below, all of a sudden you have access to all the system files in the game's over. So again though, when you do an SU dash, most likely your effective SL will have to be in the range of your clearance, otherwise it won't let you do that. And that's true under pit bull and hopefully true under other systems. Now, authorizations. Because authorizations are tied to user ID, the coming in new user can still have a great effect on a system. If the administrative commands are not protected at a level that prohibits you from getting to them, which hopefully when someone's configuring a system, that's exactly what they do. For example, in the box that we have out there, we put everything at TSL, top secret all, which essentially means nobody has access to them, except for one user who comes in over SSH who uses an RSA key, a 1024 bit RSA key. Well, unless somebody guesses that key, there's really no way for them to get into the system at that level. And again, I should mention again, be aware of the limiting authorization set because now, assuming to other users, doesn't help you. RSC scripts. Obviously on any system, if you can modify the RSC scripts, even a standard Unix system, you probably have a lot of power. And on standard Unix, you've already rooted the box. On our trusted operating systems though, it's a little bit different. If you get access to an RSC script though, you have pretty much access to the whole system after a reboot. And the reason is is that our C scripts are typically either launched with lots of privileges, which means pretty much open access to the system, or they have lots of authorizations in order to run the programs that they need to to start up the system. So this is another very juicy target to go after on these boxes. Network labeling. As I showed you before, you can specify what a label is for different ports, for different services. And so now if you can find a service which is running on a box at a level that you'd like to be at, like implementation low, and you can exploit that buffer overflow, that program, you can give yourself a shell at that SL. Now the only thing you have to do is become the user that you want with the right authorizations, and you can have full access to the system. So don't ever run any services at implementation low if that's what your system files are at. That's a lesson. Kernel bugs. Kernel bugs are always good for any operating system. All the securities in the kernel inside in there. And if you can break the kernel, you on the system, you can circumvent all the security. Or at least you should be able to figure out a way to do that. So kind of where to look on trusted operating systems. Of course, first there's all the regular old kernel bugs that happen every once in a while. If you can find one of those to get in, then you can give yourself the access you need. But there's other things that you can go after too, which are kernel related. Look at devkmem. That gives you access to all of kernel memory. If it's had an SL that you can get to, and you can become a user who has access to it, then you can modify kernel memory. And you should pretty much be able to take over the box from that. And you can give yourself all the privileges you need, pick the UID that you'd like to have, and give yourself an SL that would allow you to do what you need to do. Also, access to raw devices is very useful. If you can get access to a raw device, you can modify the security structures in the files and change everything to a level that is more amenable to the level that you're at. And then again, get the access that you'd like. Also, it's interesting to look at devices. Look through IO control interfaces and different ways to communicate with devices. They typically tend to be a little less scrutinized on B1 systems. Just because a lot of times the MAC rules aren't being looked at in the IO control, simply the only time a MAC check takes place is when you're trying to open and access the device. But after that, you can communicate with the device readily, which is reasonable. But if somebody screwed up their device, then you can have access to the system. Also, it's worthwhile checking to see if IPC mechanisms on a system are actually using MAC. If they're not, you have a way to communicate with processes that are at a different level than you. And you can potentially use that as an attack path. It's important to remember that anything that you can find once you circumvent MAC is only then protected by DAC, or if there's something that isn't actually checking mandatory access control, then you're probably back to a DAC or no access check attack. And now all you need is possibly is to know a password to become a UID. You're back to the old problem. So again, as I say this a lot, really what you're trying to do is you're trying to reduce your problem set to get rid of the layers that the trust operating system puts on by meeting the access checks that it makes and bringing it back to a common attack problem. It's difficult, but it can be done if the system is misconfigured. These are real basic things which you should just always check because somebody might screw up the box. Try and log in as a highly authorized user. Can you guess the password for the security administrator? Do they let you connect to him from an external connection and then add an SL that lets you run administrator programs or access system files? It's worth trying. It's probably not the case, but it's definitely worth looking at. And also look for the security databases. They're pretty much the key to the security on the system. And if you can modify them, you're gonna own the box fairly quickly. Just to mention some of the commercial trusted operating systems that are available. There's of course the company I work for, Argus Systems Group, we make Pitbull. That's on Slayer 7, Spark and X86. We're porting to Slayer 8, Slayer 6. We have an early release on AIX. And we're porting to Linux on 32-bit and 64-bit kernels. And as I understand that's gonna be available because I'm sure some people here are interested in that by the end of the fourth quarter. And we should have a beta program available for that as well. HP makes a product called Virtual Vault, which runs an HP hardware as part of a suite called Presidium. There's also a effort underway to create a trusted operating system, an open source trusted operating system on top of free BSD. And you can find out information on that at www.trustedbsd.com. So the best way to learn how to break these boxes is of course to have your own and start securing it and breaking it. So you should get one and start doing it. And it's very easy to do actually because we're giving ours away for free for individual non-commercial use. So if you go to ArgusRevolution.com, we have ISO, I'm sorry, ISO, ISO images available. You can order the media, all those kinds of things. And you can have unlimited licenses. We make all that available. I'll be making this speech and the presentation I gave for Black Hat, which as I said was more detailed as far as trusted operating systems go available on the Argus Revolution website. There's gonna be I believe a real audio stream available on Black Hat site for the presentation that I gave. I don't know what the case is for DEF CON, what they're doing with that exactly. And white papers, documentation, and there's a discussion form available on the website as well if you have questions. And of course, please feel free to email me if you have any questions. And yes, I will definitely answer questions. Yes. Is there anything about STI members? Yes. Do you have anything to do with it? The OB1 stuff, yeah. In truth, most I know from hearsay, I tried to contact them, but I didn't get a lot of information back. What I know what they have done is they've released what is based off of the TrustedIrex code base. They did a CMW there. And basically they released that code as an example. And from what I understand is that there is an effort underway at SGI, at least with people who work there who are trying to create a Trusted Linux, which is essentially based on the TrustedIrex code base. No comment. Yeah, no comment. You can come up and talk to me about it. That's fine. Just not through the microphone. And yet, yes? Arbeck, yeah, yeah. All right, the question was what about our role-based access control? Something called Arbeck. Arbeck is essentially a discretionary access control mechanism, which is, I mentioned roles, like ISO, SOS-A. The idea there is you're creating roles and you can create an access control set around that. It's not a pure mandatory system, but it's still very useful. That's actually out on Slairs 8, as I understand it, Arbeck is being made available as well. Yeah, there is a Linux version as well. I've actually not used it on Linux yet. Oh, there are, okay. Do you know where, what website that's on? It's ARG. RSbeck, okay. DE, okay. Any other questions? I didn't look, sorry, I haven't looked over yet. Yes. He was making a comment on seeing files in a directory and there's two things I'll say about that. Is one, is that if you are looking, if you have access to a directory, to the directory file, then you can see what's in a file, but when then you go into the directory and you actually try and look at the, examine the structures of the files, you may not have access to them. The second thing is there's another concept called, now it's gonna escape my mind, partition directories. And the idea is that you can create these directory structures, kind of a virtual directory structure under directories, where depending on the level of the file that you're putting in there, it will go into one of these subdirectories, right? Which is marked at a specific single level. And so what level you're at kind of puts you into one of these subdirectories and you can't get access to the other ones. So you can completely separate files that are at different levels from users. Yes. Oh, do you want to exploit the third-party developers? Oh, always. No, the API isn't very complicated, fortunately, at least speaking for myself. But, and it's not really, well I guess even with Mac stuff. I guess kind of the advantage to it is that when you're working with the API, you're most likely working with it in very specific pieces of your code, whereas the problem with standard Unix is that you're working with those things, but you've pretty much said that you're working with it in the entire program because you've said it's UID zero. Here's my, you know, here's all I can do, and I can do change mods and things in files. But when you're working with the trusted operating system APIs, you're gonna have to be very aware of what you're using, where you're using them, because they're gonna apply specifically to the pieces of code that you're trying to work with that made a little bit of sense. I should also mention that on the site, we make our SDK available as well for the product for free, so people wanna play around with that. For example, I've made a multi-level aware LDAP server, which does security using mandatory access control as well, so you can limit access to the LDAP server based on where users are coming from in a mandatory fashion. That was just a little side project for fun. Yes? Does that mean applications have to be trusted aware? No, absolutely not. What you can do if you have what we call a commercial off-the-shelf program, which is a government way of saying just regular programs that everybody uses, like me and you, you do not need to modify those programs. However, if they would run on a system as a regular user, they're not performing security-relevant functions, so you just run them as normal. However, if they would've run as root normally, which means they probably were performing security-relevant functions, then what you need to do is look at that program and figure out what privileges it needs. Now, okay, how do you do that without code? Well, you can. For example, with Pitbull, we have a program that we created called TracePV, which essentially analyzes the binary, the libraries that it's linking against and looks at all these things and figures out what privileges it needs and will set up the program so it'll run properly in a least-privileged fashion. Trusted Slaris has a program similar to that, but it's much more limited. I don't think Virtual Vault has anything like that at all, I'm sure. Yes, please. Ladies and gentlemen, a couple things. Racial slurs against people who are here will not be tolerated. Threats against the staff, Allah, I will kick your ass, or I will kill you, will not be tolerated. Threats against other convention goers, Allah, I will kick your ass or kill you, will not be tolerated. There's a group of people out there who seem to think that IRC is real life. IRC is not real life. In real life, that is assault, and you will go to jail. I'm hoping some of their friends are in this room right now. I'm hoping these people will get to them and tell them to go away and not to come back, so I do not have to put you in jail, because if I catch you, I will make sure you go to jail. I'm sorry to have to bring this up this way, but this will not be tolerated, and this is the third or fourth incident that I've heard in the last two days with this group of people. We are supposed to be enlightened, mature adults. Good fun in pranks is fine. Threatening to hurt someone is not fine. Thank you very much for your time. All right. Are there any other questions I can answer? Yes. No comment. Actually, the pricing model and all that stuff has changed, and I am an engineer, not a salesperson, so I hate to answer those questions. I should say, and maybe I can get a round of applause for this to make me feel good. The program I mentioned before, the Argus Revolution program, was actually put together by me. I pushed it through. I wanted to make the product available to people for free, like me and you, because it's worth us using it, so that's it. All right. Thanks.