 jury rigged up here so anyways I'm Dan Burroughs just a little bit about myself I'm a professor at the University of Central Florida in the engineering technology department specifically I work in the information systems technology program which is a it's a very applied approach to engineering and specifically information technology systems we're currently at the University of Central Florida developing a undergraduate security program that I'm also I'm the one that's mainly involved in developing that and that's actually what my second talk a little bit later is on today but this is the more maybe more interesting more technical one my past research includes the correlation of distributed distributed network sensors if you have a if you on a net we have a large-scale network you have intrusion detection systems you have firewalls you have other things that are recording information saying what's going on on the network trying to correlate that information together to bring it all together and trying to see the big picture of what's going on rather than getting these little kind of half views of what's really occurring out on the network and also I'm working on some projects and involve combined data sharing networks for law enforcement in the state of Florida you know this little blurb at about the University Central Florida it's down in Orlando Florida it's about we've got about 42,000 students there about 5500 of which are in engineering we're located about 13 miles east of Orlando Florida as I said the information system technology program this is a really innocent applied engineering degree it's very hands-on very real-world very current tools not so much the traditional theoretical approach to engineering heavy concentration of hands-on learning in the program a little bit about the a little bit about the background of what led me to this current idea is there is a previous research that I worked on I give a couple presentations back at DEF CON 9 and 10 and this was on using Bayesian multiple hypothesis to try and analyze reports from these distributed intrusion detection systems and other types of network sensors with the idea of trying to determine if what you were seeing were correlated events if this was a an initial attack and a follow-up or if the two events you were seeing in two different places might be two systems communicating who shouldn't be communicating together and to try and use multiple sensors to distribute over large distributed networks to try and do this the basic idea behind what I was doing with that was taking target tracking methods that came out of actually out of radar target tracking systems trying to track real objects in the sky with various radar systems and taking that same approach and treating our all of our sensors that we have on our network whether it's an IDS a firewall a router even a human sat there making observations about what's going on and trying to automate the correlation of that together and this was intended to totally throw the human analyst out of the loop but just to kind of act as a sort of a first level filtering system to throw away a lot of the not a lot of the information that you don't need in order to come to a conclusion about what's going on with the idea that we were going to kind of move this more towards a point of view instead of looking at this one section of the network or this one part of what was going on that's visible to this one sensor like you know you've got your firewall sat at the so you got a sat at the border of your network it sees everything that's coming in and out of the border but it doesn't see stuff that's entirely internal to the network you might have an intrusion detection system sat on one segment of the network that sees what's going on there but it doesn't see what's going on on another segment of the network and to take all these little pictures of pieces of information and to put them together to get a more complete view of what someone was doing while they were attacking the the network and did this through using radar tracking algorithm specifically Bayesian multiple hypothesis tracking and making an analogy to the world of computer security where our firewalls are ideas are humans looking at what's going on the network anything that records information is a sensor that's like a radar system the actions that the person out there trying to break into the network are doing that's the target and that's the trace they leave behind we're trying to put these traces to together and we're working in a situation where we've got to do this in real time we've got incomplete data we've got inaccurate data potentially about what's going on depending on how your sensors are operating just just a little bit more about the system the the idea how this works this idea of this multiple hypothesis tracking is as events occur on the network as an event is when a sensor recognizes that something's occurring when something actually pops up on the sensor when it gives a report when you've got an IDS it tells you hey I think I see something when you've got a firewall that decides it's not going to allow this packet or it sees something unusual when you've got your sysadmin on your network saying hey you know something weird's going on here as these events arrive they're analyzed and say for example we're sat there and one of our system sees a port scan happening out there we build a hypothesis about what we think's going on in this case if we've got a single scan coming in from the outside world hey you know that's all the information we have that's the only hypothesis we can come to is that's what's going on we're seeing a port scan right now really I guess actually technically you can make two hypotheses at this point you can say hey there's a port scan going on or alternatively my IDS isn't working properly and this is a false positive then as other events occur say you see a buffer overflow attacked against a machine following that well what could be going on now we could make the assumption that the port scan is being followed up by a buffer overflow someone scanned a machine for a vulnerability then they attacked that particular vulnerability on it or potentially these could be two unrelated events that the port scan could be part of one attack the buffer overflow could be part of a different attack on the system and what we were trying to do with this system was trying to automate the process of figuring these out now this is a this is a simple example this is a pretty trivial case I mean in this particular case if the port scan is a scan against you know I don't know against port 80 and the buffer overflow is a buffer overflow against an IIS server chances are those two things are related if they're not if the port scan doesn't match up with what the buffer overflow was chances are they're not related but you can extrapolate from this idea into much more complicated systems and much more complicated series of events of trying to piece together the pieces and figure out whether or not all of these events and all of these things that we see occurring across the network are related together are they not related together are they likely to be something real are they likely to be a false positive caused by a imperfect sensor or imperfect ideas or firewall or or human in the loop actually one of when I was working on this one of the most interesting sources of data that I had to work with came from the capture the flag games here at DEF CON luckily the shmoo group captures all of that data that goes on during the capture the flag game to capture all that network traffic and that provided a great playground to to work in to try and see if that information could be correlated together and this little graph I got up here I mean this is kind of just pulled right out of context these are some slides I grabbed just to give a bit of background about the previous research in this basically what this was showing is as you let the number of hypotheses that you consider increase in that previous example I said excuse me I said that we had the two hypotheses either these two events are unrelated or these two events are part of a chain of a single attack well we let those we we say these are our two hypotheses and then we look at the evidence that's going on and we evaluate them and we find out which hypotheses we think is currently the best one we have available then we wait for more information to come in we'll have a certain confidence level and how confident do we believe that in this hypothesis as more information comes in we'll build more hypotheses and will we reevaluate the likelihood of our existing hypotheses eventually in the at least in theory this will eventually converge to a point where one hypothesis is clearly the winning hypothesis now the problem with I said that's in theory the problem with that is you have to consider every possible hypotheses in order to do that and the number of hypotheses grows at a super exponential rate so it's practically impossible to do that there's a lot of work on the pruning of of them deciding which ones you want to keep which ones you want to throw away and what this graph is just showing here was along the bottom is a number of hypotheses that were allowed to remain in the system going from well at the bottom one all the way up to a thousand and the accuracy of how well it correlated the different attacks together and it never quite got up to a hundred percent but it got up into about ninety three ninety four percent accuracy on the capture the flag data being able to piece together what were related attacks and now of course this was actually correlated against the baseline was done by hand taking we I am a few others that help me took the data over the the capture the flag game over about a I think it was about an eight hour period and by hand figured out what was related information what were related attacks and then built the system that could do to automate that process so this thing it worked this is a pretty decent idea it worked it didn't necessarily work as well as we had hoped initially if you've got everything on a same network or related network where you're likely to see lots of related events it works well if you've got this distributed over large networks where you're likely to see many more unrelated events than related events it goes the accuracy goes down a bit or at least the amount of work you have to do to get good accuracy goes way up it is more accurate this more accurate so that's what it done in the past and this got me thinking about so this was a system that it developed to try and detect related information on a network and then of course you know once you can do that you always think about the next step and once the next step once you can detect something you figure out how to hide it even better right you know it's always kind of that one upmanship game they were playing so you got me thinking how do we defeat a system that works like that how could you avoid detection on a network that was well observed well monitored and where the information was well correlated where you couldn't rely on the guy sat over on this part of the network not knowing what the guy sat over on this other part of the network was doing or seeing or knew about what was going on if you assume that there was complete coverage of the network how could you hide what was going on there and I'm not this is I'm not talking about so much the detection of a specific attack like someone does a buffer overflow against a web server they do you know whatever other type of initial attack to gain access to the system but assuming they're already on there they've got onto the system and they want to keep communicating back and forth you they've got their remote machine they're sat at they've got access to machine on the network they want to communicate back and forth but they don't want to be detected while doing it how could you go about how could you go about that and avoid detection on a well monitored network so you have to look at this from the point of view of where do we have the choices about what we do when you're talking about the initial attack you don't have a whole lot of choices if you've got a you know I guess I mean I guess unless you get lucky you see a system out there that's got a ton of vulnerabilities on it then you got some choice about what to do but assume that you have limited choices of how a system is broken into there's limited ways into the system to begin with you don't have many choices there so any tool that's written to to initially gain access to a system usually has a fairly limited lifespan at least it's limited limited lifespan in the realm of people who actually care about security you always find some bozo out there who never updates anything never puts any security on their system you can always get into them but talking about the people who are serious about it you have a limited lifespan with any sort of tool for initially getting in there however once you have access to a machine and all you're worried about doing is communicating with that machine you've got a lot of choices you know we're not stuck with one type of communication protocol we're not stuck with any traditional communication protocol that's out there whatsoever the trick to this is figuring out which ones work and which ones won't be seen so here's here's the question how do you communicate on a network without letting anyone know you're doing it first things first how do they detect what's going on how does someone see what you're doing on a network you've got IDS you've got firewalls you've got observers all of these things are sat there looking at what's going on on the network in general I picked the IDS and I say software human because you know whatever is looking at your network whether it's automated or whether it's a person they're trying to determine if someone's intruding on your network you get two basic forms of this and this this applies I think the IDS system in at least one sense is the most general case and you can kind of find derivative cases that cover this the same concept for firewalls and routers and everything else out there there's basically two forms of detection out there anomaly and signature detection signature detection works on known attacks known events you know if you if you know exactly what you're looking for you know when you see this packet go by it's something bad you want to throw up an alert about it hey that's great you can catch it every time it'll never get by you know you've got that one nailed the only way to avoid that type of detection is to use either an unknown method or something perhaps that changes constantly never use the same method twice the anomaly detection it doesn't detect misuse of the system it doesn't detect something malicious it just detects something unusual so it's it's not necessarily really great at trying to pick up something bad happening on your network but it'll pick up something unusual and it's really if the signature detection doesn't work that's the only chance you have left is looking for something unusual if you don't know what to look for you got to look for things that stand out so we can't really avoid the signature detection if you've got a way of communicating or way of doing anything on the network and someone can write a signature to detect that that's it you can't you can't do anything with it it's got a limited lifespan eventually it's going to be seen so the only alternative is to use something that you can't write a signature for something that changes constantly something that is quote unquote random or at least appears random to anything that's observing the network and we have to be able to do this without looking unusual and that's the key not only do we have to do something it's kind of it's kind of a catch 22 in a way because we got to do something that's very unusual you know this kind of random changing community communication protocol but we got to do it without looking unusual you can't stand out on there so the first stage of this is to detect the baseline of the network what does the traffic on the network look like to begin with what does what is occurring on the network what happens out there all the time and this can be done passively you can sit back and discover what type of traffic is allowed on the network what does normal traffic look like and kind of build yourself a map of both what is going on on the network what the structure of the network is and what's allowed in and out of this network this is not a new concept that's just this general idea of doing this this is done all the time this is how many tools and and other fun little things are written and developed but the key thing is is that this is what generally this is what people people do this process someone looks at a network or you think about what's going on on the network you know good example this is a verse w w w shell that's an old tool the idea of this was that you've got a computer inside the network it's you're not allowed to make connections from the outside to it you know the firewall is going to drop any connection in inbound connections to it they put a piece of software on that computer inside the network that at certain intervals perhaps at random intervals it looks like it's going out to a web browser it goes makes a web request except that what that web request is doing is coming to your computer on the outside getting the next command that you've told told it to do it carries it back as the HTTP response to the to the target computer to the one that one that you got access to and then it carries out that particular command it's masqueraded looking like the the computer on the inside is just surfing the web that's a great way of hiding it unless someone knows to look for it once someone knows to look for it if you stick with it too long they're going to look for it they're going to see it it's going to stand out similarly carrying data commands and ICMP echo echo response packets same sort of by same sort of idea what I'm trying to do with this project is to automate this process and make it run on the fly and may and have it adapt itself to whatever network it's currently working on look at what's going on network decide what to do on the network decide what will work there and then carry it out so some aspects of network traffic are going to have a low entropy meaning a very low randomness they're going to be very kind of the same things always going to happen certain communication protocols are only going to go to certain computers DNS requests are only going to go to your DNS servers are not going to be jumping around every computer on your network incoming web requests are probably only going to come to your web server they're not going to come to every computer on your network other things are going to look much more random maybe outgoing web requests you know people different people surfing the web outgoing FTP all sorts of things other things are going to be very random there's going to be a lot more entropy in that and entropy is the key to hiding information the the more entropy you have on the system the more information you can hide in that this is like if you look at if you look at steganography for example you know you're trying to hide information in something else if you've got a bitmap a bitmap has lots and lots of redundant information in it versus a JPEG image a JPEG has taken a lot of that redundant information out that's why JPEG smaller than a bitmap you can hide a lot more information in a bitmap than you can in a JPEG higher entropy you can hide more information inside it so if we find what has the highest info entropy on that network what communication channels have the highest degree of randomness we can then pick what we want to work in and we've got all sorts of all sorts of things that we can work with here we can work with the timing of the packets we can work with packets sending out packets that have bad check sums malformed check sums all sorts of different things that we can play with we don't have to use a SSH or T or telnet or some other standard type of communication format we can send crafted packets where the information is carried in all sorts of the different little pieces and information inside that packet the key is we just have to make sure it doesn't look unusual when that packet goes out so the overall concept here is we detect what the network baseline condition is on the specific network that we're looking at what does normal look like what doesn't look unusual and then select from that the potential communication channels determine which ones are highly have highly random information on the network put it down figure we've got initially we can select from anything we can do and craft a packet that does anything we want we're going to look at what happens on the network figure out what's allowed limit it to that and then limit it to what is it has a lot of entropy within that and then we have to somehow communicate this method to the receiver on the outside we have to get the information of how we're going what communication scheme we're going to use we have to get that to the receiver outside and then maintain a you know I put almost undetectable presence on the network is you never should think you're undetectable you should never think anything's absolute because it never is that's how you always get yourself into trouble but we can monitor and update the network conditions to stay hidden if network conditions change we can change the scheme we're using to communicate on the network if we just sit there and listen what can we learn by listening on the network there's all sorts of all sorts of things that can be that we can find out by just sitting there and listening not doing anything active not doing anything to be discovered can figure out what types of packets are allowed inside the network what types of packets are allowed outside the network we can figure out the architecture of the network where are the switches where are the routers where are other machines on this network and then look at what types of packets are flying around what types of packets as a machine that I'm on send and receive what types of packets do other machines out there send and receive and from this get an idea of what is allowed to move around this network what is moving around this network and what we can inject into the data flowing around without being sticking out like a sore thumb and being immediately identified so if we narrow down these choices we start with the ability to send any type of packet you know send it to any port whatsoever we start pairing it down based on what's available figure out what has the highest entropy look at this look at the type of packets based on the protocol the ports are using etc and look at the entropy based on how often do these packets fly how different is the data in these packets whenever they go by what different machines do these types of packets go to and then pick a channel that we know we can get from point A to point B we can get from inside the network we've got access to the machine on out of that network over to the place where we want to get the information to or back and forth vice versa either way we can figure out what can get into one out of one network into another and then back the other way doesn't necessarily have to be a symmetric communication channel the packets that you send out the packets that you send going out one way don't have to look a heck of a lot like the packets coming back in the other way as long as they're getting to the right segment on the network as long as they're getting down to the right branch off of your switch so that it can be picked up by a by a network card in promiscuous mode as long as you can get down that far and you know what to look for each guy on each end knows what to look for you don't have to have to even be a symmetric communication channel between them you can have essentially two different channels going back and forth one of the big challenges with the system is starting the conversation if you've got a piece of software running on the inside of this network and it's going to start communicating with you on the outside and you don't know what particular communication scheme is going to be using there's some difficulties in getting in getting that first packet out of there that first piece of information to the outside without having it be something that can easily be written as a signature because it's hard to it's hard to change things or inject randomness into the first bit of communication there's some there's some ways that we can limit how signature vulnerable that first bit of communication is but that's one of that is that's one of the points that needs to present some challenge and need some work on in this having the communication software itself remain undetected on the remote machine not talking about what the software is doing but actually having the software itself avoid detection of course that's another challenge but that's a that's a completely different story that's whether it's something that's using a polymorphic code that is that changes from one installation to another or even changes itself constantly there are ways around that but it is a different that but it is a another challenge in there that the third one that's actually I think a fairly interesting one is the problem on a low entropy network what do you do when there's not a whole lot of randomness going on on the network you know if there's a lot of randomness in the back it's how do we stay hidden in it we have to ensure that every packet that we send out doesn't significantly affect the statistical baseline of the network so that an anomaly detection system sat on the network will not recognize this as something unusual it will not stand out it won't push the statistical analysis of network beyond the limits beyond the thresholds that we currently have and it will avoid becoming an anomaly this is actually the area right now that I'm doing that I'm concentrating on trying to figure out the best methods for communicating and picking channels and picking well hidden channels on a low entropy network so just as a summary of like in the system you know what's real what's not real so far the allowed protocols discovery the network architecture discovery the statistical pro filing of the of the network those are those are working prototypes those modules those parts of the system are working prototypes next stages that we're moving towards the selection of the communication scheme implementation of the communication and the adaptation to a changing network to changing network conditions I hope that by this time next year this will actually be a working package that I can give maybe a bit better presentation and demonstration of what it's actually doing but this is the current idea anybody that has any interest in this or any ideas or feedback or wants to tell me why I'm crazy for thinking this feel free there's my contact information and that's it for a about a 25 minute presentation there's one question that that's a that is a great question I'll take that just I'll try and ask her one more real quick he asked is there any concept of trying to actually change the baseline of the network so that you can do something that used to look unusual make it not look unusual anymore that is it's not one of the first level items on there that's a pretty advanced way of working it but actually changing injecting stuff in slow enough that the system the anomaly detection system adapts to it and thinks that's normal that that is one of the long term ideas on there that's a that's a great idea to put into this thank you