 My handle's under. I'm one of the original founders of the ghetto hackers. I'm going to be talking today about autonomous nodes, which are basically little computer programs that you can say they have their own little artificial intelligence inside. The idea is not that they're artificially intelligent. It's just that they live by rules and die by those rules. And they don't talk to anybody else. They kind of do their own thing. I wanted to give some thanks up front. There's a lot of people who have helped me with this. Caesar, bats, all 40 ounces of the ghetto hackers. DT, dementia, absolute nick, who fixed my laptop. I'm a fast study. I sent the icky guy and Michelle, Mike, and in Lindenwood where I would sit for hours and hours all night drinking coffee with nice little Denny's there. They're pretty cool. Where there are autonomous nodes and intelligent agents, there is a distinction between the two. You'll hear a lot about intelligent agents in network software that goes out and retrieves information for you such as a news agent. You tell what type of news you actually want to read and it goes and gets it from all the different type of places that it knows about. The differentiation between an autonomous node and one of those agents is that the agent goes and gets information and it relies on your input to determine what it does and where it looks. An autonomous node, once you begin running it, it does what it wants and does what it was programmed to do and it doesn't care what anybody tells it to do from that point. It was my intention when I originally asked DT if I could speak here that I'd have a full demonstration of one of these nodes working and we were going to actually use a buffer overflow in Windows NT and do a quick demonstration. The way the development went, I ended up redesigning many portions with Caesar's help and doing a full demonstration didn't seem right because I'm making fun of it because I'm running Windows already. The demonstration would have been on a Windows box and such. The idea is I want the autonomous node project itself to be able to be run on many, many platforms operating systems and there's that. Autonomous nodes are currently being used, like I said earlier, in many network applications and other informational applications. Currently, Sandia, which is a government jobhouse, is using autonomous nodes that are creating their own to actually have a defense network which will be used to basically protect government networks from hackers. The standard hacker or hackers that are going to be attempting to penetrate any of these type of servers will be not up against a server administrator of any kind or even just Bob Joe software that is watchdogging the servers. You're going to be looking at attacking multiple, multiple nodes of machines that are running solely to watch for you and communicate between themselves and then hack you back or report that they're being hacked. Currently, Sandia did release a press release and you can see it on their page at www.sandia.gov where they said that multiple red teams of hackers from some three-letter acronym places were unable to penetrate their networks using these nodes. They also stated that they would like to convince ISPs in the future to actually run these nodes so that all of the information packets of any email, any connections, anything that is not encrypted in the United States, it is possible that many more three-letter acronym people can be reading all of that and capturing all of this using these nodes and they would also render hackers attacks on almost any ISP including the DEF CON webpage useless. Autonomous nodes can be powerful because they do not exactly rely on anyone to ever talk to them. Once you define the rules and what you want to happen, autonomous nodes perform a single task. So if you're ever performing a single task in networking, something you're going to do often, much like running in-map on a machine, running certain programs where many hackers will go and they'll script out the commonly used things. I propose that in the future what we'll see is we'll actually see many of these nodes that have a back-end or front-end where hackers can simply take a module that performs one of these actions or events and plugs it in and then runs the autonomous node. Autonomous node knows the rules by which the hackers set forth and so you can always do, say for instance, once someone writes DNS Poisoner, then they simply plug it into the autonomous node structure and then forever and ever they'll always have the ability to run this certain program. And the design itself should present the ability for an ever-expanding and ever-growing use of these tools that are developed with these modules so that some guy goes and he writes, for instance, a DNS Poisoner and then Bob Joe over here. He needs a DNS Poisoner as well and he's going to write it differently and he's going to use a different flow net and it's going to run on Linux and then this guy over here, his works on a different operating system. And there's no common goals and there's no common tools that are being, there's no common structure for the tools that are being developed today for network security as a whole. The autonomous nodes would allow that a set of rules to be defined so that specific events that happen, whether it's from a packet sniffer or an IRC channel, that there's a layer of information that will feed into the rules which are defined by the programmer or script language possibly. So that things can happen based on the data that is received and seen by the node itself. And I'm going to have the army of one. Currently the ghetto hackers have quite a few members and well, all of you have been out by the CTF table, you can see we were kind of going at a pretty hardcore. In the future, there's not going to be an army of people necessarily, there's going to be an army of nodes, there's going to be an army of programs. Sandia with their publication said, hey yeah, we're going to have 50 computers here all doing different things, talking to each other. That's the defense and no group of people can think fast enough and can act fast enough based on the information that will be seen when you are hacking to make the right choices fast enough to penetrate. The army of one will be the hacker or the freaker or someone of that nature who actually has computers that are doing all the small tasks that he wants. The structure that can be used to do that must allow, it must allow that the actions for the programs that they want to make be structured significantly the same so that an autonomous mode that's packet sniffing behind a firewall and then sending that data sneaking it outside the firewall, he sends it over to say an IRC server. There's a note on the IRC server that the same hacker who put the note behind the firewall put there and the information layer that it's using is just reading right from the IRC channel. And so in that case, he takes the data and he doesn't, neither of the nodes know that the other one exists nor do they care because they weren't on the rules internally, they don't care about anybody else. So he sees some data on the IRC channel and he sends it to, you know, via, he makes little mail packets and sends it via mail to South Africa or something. This is an example application of what multiple nodes can do and exactly how people will hack in the future. I want to talk a moment about some of the components that create a node. A hacker node would be nothing without an exploit database. This database is not some big SQL server specific thing. It's a basic ANCC implementation. You got fields, you got rules, you got columns. It's very simple. There are customizable templates so you could have anything from a database that records an IP and operating system information to user names that were sniffed off of the network. Each of these modules will be, in some cases, loadable upon runtime. In some cases, they will have to be compiled in and it really is going to depend on the operating system and the platform that are used for that specific node. The attack tree logic is something that Bruce Schneier, many of you know who Bruce is, actually documented. I believe he finally was putting the smack down on the ideas that people had talked about as far as making a logical tree and then sorting the nodes of that tree to determine the best possible way under certain circumstances to get to your goal where if you were to take a node and say that it was a bank fault and then you would have then cascading leaves off of that where one would be, you could blow it up. And then each of the nodes would have data assigned to it regarding what it would take to do that. In the case of blowing it up, you might need dynamite, in which case it might cost $25,000. And so there's data that's associated with action that can take place within an attack tree. In these fields that you would define, you would then run simple sort algorithms that would go through and say, which is the least expensive way? And so then you go through all the leaves of your entire tree and you say, well, blowing up the bank vault to get the money is not going to be the cheapest way. We're looking for the cheapest way and that might over here turn out to be just going and getting a lot of guns and stealing a van and showing up. So the attack tree logic itself is going to be a module that can be loaded by the node. If the node's purpose is aggressive or maybe even defensive, the node will have the ability to assign specific information in a tree, say, of a network map to determine the fastest way to hack something, the easiest way to hack something, or possibly the most stealthiest way. The independent decision making kind of just falls into the rules. The rules are, is the code that the developer creates for the specific node. The decisions themselves are specific of the designs and the choices that the developer makes when he writes it. This is why I shy away from saying it is artificial intelligence because it's really not. The developer has to know about the cases that will happen before he writes the code to create the rules. In many cases, when we want to instruct the node to have a certain behavior, it would be troublesome to maintain hundreds of nodes around, hence the initial suggestion. An initial suggestion is when you run your node. Because you don't want 50 nodes around one that does some packet sniffing and some decisions based on that, a node that sits over here and does some DNS poisoning, it makes more sense because if you exploit a box and you want to run a bunch of programs on it, it's probably going to be pretty obvious if you upload 100 megabytes worth of data to the machine and then take up half the CPU time as well. So generally, you can run a node and you'll incorporate more functionality in the rules than you'll need so that it is all together and then you will have an initial suggestion to the node and you will say, Hi, I want you to be aggressive for a given node that is actually intended to exploit a box. Some of the other issues about having a node that you use that you actually is a client on your machine and you use it to exploit a server. At that point, you put another node on the server naturally and that can be for reasons of packet sniffing. You might put it there simply to own the box to keep certain watchdog programs from running on the server. There's multiple reasons and in that case, you might have a hierarchy of nodes which would actually turn the autonomous nodes back into an intelligent agents because they might want to communicate. One issue that I've had while working with this is that the code for this is somewhat touchy because it's probably not a good idea to have replicating autonomous hacking nodes floating around the internet where any script kitty can decide they want to replicate 200,000 machines out there. So the status of this project is basically going to work that it is kind of a closed code. The obscure communication layer, this is basically going to be an implementation of a layer of communication where the node when he's in a situation where he doesn't want to say, hey, I'm over here, why don't you come format my hard drive or delete me. He will generally use higher level protocols and then he will do all of his communication via payloading right onto the top of the protocol. It just makes something that's valid that's going to go through a firewall and then he tags on the end some signature information and some basic information that he's trying to send such as, hey, I found a username and password such a thing and at that point he can send data via payload directly outside of a firewall or just peer to peer. Now a node that's running on another machine that's packet sniffing can say, oh, because he is packet sniffing, he sees everything and he sees the payload and he's looking for the idea or the ID of another node until he sees that and then he can immediately take that information and do whatever he wanted with it. Possibly there was a node inside of a network that didn't want to be found, hence the rules, he was being quiet because he was in a network. And at that point, perhaps he saw a username and password and so he decided, okay, I'm going to broadcast this out to an IRC channel. Now he's in the town in a snout. He doesn't care if anybody hears him. He's going to broadcast anyway. And maybe he waits till Monday morning when there's a lot of traffic on the network at work before he broadcasts so that no one can specifically see that. These are some of the ideas that come around when we start talking about the little hacker programs that are going to take over the internet. Then, let's say on this IRC channel, the information shows up. Also included in this communication layer, we'll link back to the exploit database, but there could also be a database that stores the server mappings, user names and such. The packet sniffer on the inside of the firewall, he sends a bunch of data out and says, hey, I found a password, I found a username. And actually sends some commands so that another node, if it happens to see it, stores that information into a database. The packets sniffer and input were applicable. There are certain cases on certain networks where this is not going to be working, basically. On a switched network, you're going to have problems seeing certain packets going from many of the other client machines that are on that network. And there are certain aggressive natures that a node could take. Now, depending on the initial suggestion that is given to the node upon which it can determine, hey, I'm supposed to be aggressive or I'm supposed to be quiet. In the aggressive case, if a node was sitting on a switched network, he might decide to go ahead and toss the switch and try to get it to switch into hubbed mode. And at that point, maybe sniff the network, try to get what he can, and then send that information out to an IRC server. You want me to speed it up? Just a little bit? Okay. Generally, the purpose behind this entire project is to supply common ground upon which any network security program for any operating system and platform can be developed. And also so that ghetto hackers can win CTF without slaving at the CTF tables. The first two operating systems for which I'm currently working this project on is Linux and Windows. For my entire life, I've actually worked on DOS and Windows. My current job includes working on Windows as much as a ghetto hacker. I only have Linux on one machine, and I think it's broke. And later, following and finishing the modules for the autonomous nodes, I'm hoping to have a port to open BSD and a couple other operating systems. And I'm hoping that I'm actually going to have a working version of this next year with the intention of using it actually at CTF. And I think that's about all I have. Any questions? I'm probably not that clear on stuff because I'm all nervous when I talk out in front of people. Because of the size, the speed, and the very specific nature at which a node needs to perform a single task and just do exactly what I want. He's right there, and he's going to do this. I haven't even thought about actually doing any AI work at all. Maybe later on, if all of this was incorporated into a single object, which literally was node hacker, the guy that could do anything you wanted him to do, could take down any box, could do any type of poisoning, at that point in time it may seem it would probably be such a big project that you'd have to actually move to the point where you used rules of artificial intelligence to determine importance of offense and such. They are actually using AI. They are also, to my knowledge, incorporating the ability for a server. They're actually not taking an FTP server and then writing some AI code on the side to watch what's going on. They're actually rewriting the FTP server at that point in incorporating all of the security into the service itself so that literally your FTP server will be able to talk to your web server as far as the security's concerned and say, hey, I saw this. What did you see? That type of a thing. I'm sorry? I'm sorry? Oh, the attack tree itself, each of the leafs or the actual nodes, will themselves are database. It is a database itself. So the template that's used to create those nodes can simply be used to actually store that information to a database. You could create it on the fly if you wanted to. Does that answer your question? Okay, let me see if this answers your question. Let's say I have a node and this node is supposed to map a network. That's its intention. And we'll say that it's going to map a network and then somewhere it's going to exploit or replicate itself. So it creates a database. It performs its deeds of sniffing the network and it sees very simple signs through packets and it just starts marking down and says, okay, I think that this guy is this type of an operating system over here at this IP and then I think that this guy is over here and I saw some message come through and he tries to basically map out and we'll say that there were, say, five machines there. Now, let's say that I told him that there was an actual machine behind us and he's trying to figure out the way to get there by mapping this network. In that case, his attack tree would, by the traces of the different routes through the machines, he would create himself the nodes that would exist on the tree. And then at that point, predefined sort routines that would say by operating system or different things like that based on the exploits that he had in his own database. He could sort by that and then determine which route he would want to take. Does that answer your question? Okay, you can grab me afterwards if you'd like to talk about it more. Are there any more questions? Sir, personally, I, can you say the question again? Sorry. He said, would I rather have one node that knew about four exploits and could use them rather than having four nodes with four different exploits? If the four nodes were on four different machines, the purpose being to spread out an attack, I guess there's kind of some more information that might change my decision. If I was just working for my client machine, I'd like one node that would actually know about everything. But if you're doing a range of attacks from different positions, it would make more sense to have multiple nodes. I'm not actually very familiar with library nodes, did you say? I have not done any research on library nodes. Any other questions?