 All right, and this is the network defense room in case any of you guys are lost. All right, I'll wait a couple minutes to let everyone filter on in. All right, I'll go ahead and get started. Drew Hintz. I'm going to be presenting on COVID channels and TCP and IP headers. My email address is up there. Feel free to email me with any questions. My website is up there pretty easy to remove. It's go.new, like the pronunciation for GNU. So go ahead and get started. A brief overview of what I'm going to be talking about today. First of all, who are you? Why might you have a need for COVID channels now or at some point in the future? Who are they? Who are your adversaries? Who are you trying to avoid by using them? I'm going to give a few quick definitions, talk about a couple different classifications of COVID channels. Then I'm going to go into an analysis of a few COVID channels in TCP and IP headers. Then I'm going to talk briefly about an attack against a timestamp COVID channel and how you can detect that it's being used. Then I'm going to talk briefly about detecting and preventing COVID channels, because if you're someone who didn't want this hidden path of communication in your network. And then I'm going to go ahead and talk a little bit about a tool that I'm going to be releasing today that lets you use in Linux, use some of these COVID channels to actually communicate and send data. So first of all, who are you? Why might you actually care about COVID channels? Why might you actually use them at some point? So you say, well, I need to communicate securely. I'll just encrypt everything. You just sort of apply cryptography. Everything's great. But sometimes that's not the complete solution. Maybe encryption is either outlawed or maybe there's mandatory key of screw. And if you don't know key of screw is it's where you have to give a third party to give someone a copy of your private keys so that they can encrypt your information if they have to do an investigation of some sort. There was some talk of this in the U.S. with Clipper and Fortes and all sorts of fun stuff. In the U.K., even a few years ago, voted down some mandatory key of screw stuff. But even so did this day. If, for example, the police were to capture your hardware, they could subpoena your keys from you in order to make you turn them over so that they could see what was on there. And also in other situations and other form of covert channels, you might not want to let anyone know that you're communicating with someone. For example, if you're in jail and if you're in China and you want to communicate with some known dissidents and you knew the government was watching these dissidents and looking for who they were communicating with or who they wanted to watch, then you probably wouldn't want to let them know that you wanted to communicate with them. Other things, your employer might not want you going to certain websites or might not want you talking to certain people. And also, say you're some sort of evil hacksaw and you wanted to militarily control some Trojans or some DDS tools or something like that. You wouldn't want to let people know that you were the one controlling it, so you'd want to obscure your path of communication with them somehow. And so now, what are you up against? Well, first of all, probably just a casual observer. Maybe someone who's trying to watch everyone. Someone who has some sort of IDS. Maybe this is your network admin at work. Maybe it's the government watching everyone's traffic out there who knows. But probably the system that they would use, some sort of automated system that would look for keywords, similar to maybe a signature-based intrusion detection system, something like that, looking for sort of weird behavior traffic that was easy to detect. In this sort of scenario, they would probably only be able to keep a very minimal state on what was going on. They might be able to keep state on your individual TCP connection, but not your past 1000 TCP connections and probably not even that much information on you individually. However, maybe you're up against a dedicated observer. Maybe someone is honing out on you and they're watching you specifically. Maybe as an example before, you all want to use dissidents that's being watched by a government or something and they want to see everything that you're doing according to every packet that you're sending out, every bit, and they're analyzing as much as they can that a team of people are looking at it, and you still want to be able to devade them. To devade them. In this sort of scenario, they have a lot of resources and they can watch everything. Going along with the two ideas or with the idea of what you're up against is how much protection you actually need. You could perhaps probably be semi-covert and try to fool the casual observer. You could use unusual traffic that if they looked at it, they would notice it was weird, but hopefully they're not going to look at it. Hopefully they're going to look at what's pre-dying and some real secure that they go and buy. And doing this would require just a load of moderate amount of work on the behalf of someone trying to find out if you're using this channel. And so now it's really categorically or pretty really difficult for anyone to detect that you're using it. You might be using, even if they've read all the cover channel papers out there and had implementations of all the things, it can be pretty much theoretical underlying cryptography below it. And hopefully they can't do that and say they could even break the cryptography. They would have to know where to look for the cryptography to throw it through the big cracking machines and try to crack it. So all of this, so wait, what is it? It's dropping a microphone. Alright, so... Can you guys still hear me? No. Probably because it got turned off. Is that better? No? Something like that? Does that mean better? Better? Alright. So what is the cover channel exactly? I'm talking about why you might need them, but what are they? So kind of two ways that I've kind of classified them is communicating extra information to a host when you're allowed to communicate with that host. Say you're allowed to go to... you're allowed to talk to your friend Bob, but everything has to be in plain text and people are allowed to watch you, but you want to send them something secret. Another type is hiding the fact that you're even communicating with a host. This would be examples like if you were controlling a group of distributed trojans or something like that and you didn't want anyone to be able to trace you back to that communication. So now first we'll get extra communication to a host. This is when you want to hide the fact, perhaps, that you're encrypting data, because if you're allowed to communicate with them you could just send them the encrypted data, but let's say you're not allowed to. If you don't want Kyosco to come into play or it's out water would raise them in the eyebrows. So basically what you do is you send them some sort of normal data, like you'd normally send Bob some FTP file or something, but then you subtly alter it or you subtly alter parts of it so that there's some sort of covert message going outbound in the traffic. The receiver then grabs the traffic as normal, it looks like normal traffic, you can even use it as he normally would and then analyzes the traffic and then pulls the message out of there. So in this case, if someone were looking at it, hopefully a casual observer or some sort of observer would just see a normal communication going on, some sort of daily thing you were doing anyways, so they wouldn't think anything of it. This draws a lot of ties to secondography, kind of the same sort of thing. Secondography is simply the art of hiding information or something like that. You send someone, a classic example, send someone a JPEG or something and then you would simply modulate your message in the low bits of the JPEG so that it wouldn't actually alter the picture that you were seeing, at least significantly, but your message would still be encoded in there. So how could you find a good covert channel that you actually want to use in this manner for attacking on extra information? In everything that we do, there's always some sort of randomness that's going on and you need to try to find this randomness and then replace it with your own carefully chosen randomness. For example, some random places you could find initial sequence numbers. If they're good and secure against hijacking TCP spoofing and all that stuff, then they should be generated randomly or at least pretty randomly. Also, complex timing of network transmissions. It'd be pretty hard to analyze and see exactly when your kernel's going to spew out certain packets or when it's going to do things and say you could use that as a source of randomness that you want to replace with your own data. And in this, the random data that you see, you're placing with your own quote random data. And the random data, you can call it your own random data because it's encrypted and a good property of encrypted data is that it's random. Release with typical encryption. So a simple example that I've kind of described. Say you're Alice and you want to send the secret message to Bob. Say periodically, say you just went on a vacation or something and you took a whole bunch of pictures and so you want to send them to Bob. So you hop on Bob's FTP server and you send them the pictures and Bob gets them and looks at them. That's what sort of an attacker might see. But let's say I'm also subtly in there is that for each TCP segment that you threw out there, that you threw to Bob's FTP server is that you start encoding your hidden message in the padding of the TCP header. And I observe we're looking at this, hopefully we wouldn't notice that the padding wasn't zero as it normally is in a communication but it was actually some sort of data. But Bob would know, hopefully he already communicated to him to record all this traffic and to look at it and then he would know to look for the secret message hidden in the padding. And so now let's talk a little bit about unseen path of communication, kind of untraceability if you want to. And you use this when you don't want your association with the node to be known. You don't want it to be known for example things you've already mentioned if you want to communicate with a closely scrutinized node someone that you don't really want to be associated with if you're going to be accessing forbidden material for example say you're in some country that considers certain things dissident like if you were in China during certain periods when they considered CNN.com to be dissent material and so they blocked it at their firewalls and they wouldn't want you to access it. Let's say you wanted to access it now even though they still might consider it dissident then you would want to be able to not show that there's any communication between you and CNN. And of course you could also use this for malicious activity and preventing law enforcement from tracing you back or whatever you would want. Not that I'm advocating it or anything. And in order to do this you pretty much use another node or another set of nodes to relay information for you. Perhaps these nodes know that they're relaying information for you perhaps they've been set up beforehand and purposely designed to relay information for you in a good and secure manner. So how would you look for a channel like this or what would you look for in a good channel something like this? If you're using a node to forward your traffic on you would want to make that node pretty hard to monitor for example say you were say like a real life example or something say you were someone in the US and you want to communicate with some mafia boss in the US you might send your message off to someone in Romania who would then hold on to it for a while where perhaps the police aren't as vigilant in Romania they're not watching as much stuff so they wouldn't be watching this guy's mail then he would take it and eventually send it back to some mafia boss in the US and if the US was just able to watch the US mail then they wouldn't notice that you sent some message to the mafia boss and so in this case the node would be harder to monitor and that the US government would be much harder for them to go and monitor this Romanian node another attribute you would want is that you have to kind of trust this node they've been using you trust that this person in Romania isn't going to go blab out to the US government that they were forwarding messages for you and that's something that you need to be concerned with in the electronic world also because trust is even harder to establish there and it is possible though even if all networks are being watched to actually afford yourself from protection not necessarily if all nodes are corrupt that's another story but if everything is being watched there are methods that you could do this using mixes and basically a mix is where you have a whole bunch of say middlemen or Romanian people you send it off to one of them and they forward it on to someone else but each time they get a letter from you they also provide the service to a lot of people so they receive a lot of different letters from people perhaps they build up and they wait until they have 100 letters in their hand then they take those letters they mix them up and then they send them out in a random order and if everyone were watching that node they would see that you communicated with this person this middleman, this mix and along with many other people and then eventually this mix communicated with 100 other people and so they would be able to say someone in this 100 person group communicated with someone else in this 100 target group and if you had several layers of this it would grow exponentially as to your space of different possible communications if you just had five layers you would be able to communicate with each layer and you would get pretty complex pretty fast another idea or another method that's out there by the way the mix thing this sort of thing has been implemented with re-mailers such as Mix Minion and I think Roger presented here I guess yesterday they did before talking about Mix Minion so hopefully I went to that and you know what I'm talking about already and I'm just boring you but onion writing is another method of encryption to wrap your data in multiple layers and that's where the onion term comes from and so you basically get a list say you have five nodes that you want to relay your information for the final node that's going to get the data you first encrypt it with their public key so only they can open it then you go up one node before that encrypt it with that node's public key and so on and so forth until you have sort of these five shells of encryption in there and each node can only remove the graph to that node that has the key for the outer most shell they then rip it off and then they forward it onto the next person and so on and so forth and no one can actually no one that gets it early on can tell what data you're transmitting or who your eventual target is whereas people towards the end are very far away from you as the originator of the information so they can't trace it back if they're corrupt and there's an actual project out there called the onion writing project that started at some naval research labs at some point it's going on and also on top of sort of using nodes just to forward information for you you could also use some of the earlier methods of earlier classification to obscure the fact that this node was even getting information to pass on or passing on information in any respect so an example of this we kind of talked about a few real world ones this is kind of a timing one so say Alice and Bob are allowed to make both make requests to some web server say they're in some country where they're heavily scrutinized and Alice doesn't want it to be known that she's communicating with Bob they say they're both allowed to access some local news site which doesn't have very much bandwidth the small server is not very powerful so what Alice does is whenever she wants to transmit a Wonder Bob she makes tons and tons of requests to the web server hits it really hard so that this performance will degrade that web server, he would notice that it lagged a lot or several requests would notice that it tended to have a high latency and he slowed this deployment to some information and whenever Alice wanted to transmit a zero she would simply not make heavy requests to this web server and then whenever Bob made a request to this web server it would come back much faster and of course this assumes that Alice and Bob have enough bandwidth to significantly alter the state of the web server and Alice really like doing it to CNN.com but you might do some little local server and it's close to you so now if you have a covert channel what are the sort of properties that you want to look at what do you actually want to evaluate in it first of all you probably want to look at the bandwidth because that's kind of the whole purpose of it is to transmit information in a certain amount of time in a certain amount of things unless you have a bandwidth in terms of bits per second or something like that connection or bits per packet things like that another thing you want to look at is ease of detection we've already talked about this some with how easy to detect how much prevention do you need and there's always sort of a tradeoff here between bandwidth and how covert you're going to be another thing is permissibility how often will it actually go through a network if you start sending out illegal stuff stuff that's just random and weird sometimes networks will filter it or rewrite it and destroy the covert channel another thing is how hard is it to prevent say this stuff starts becoming commonplace and everyone starts using it how hard would it be for network administrators how costly would it be for them to restrict these covert channels to limit their bandwidth significantly so that they became unusable another issue is how hard is it to implement you have all these great ideas and all these covert channels which people have known about but up until this point there haven't really been good implementations that kind of brought all of them together in a usable package except for some of the end-to-end communication where you obscure the path you're actually communicating and what special cases or restrictions are there that are out there that you have to keep in mind when you're using the channel so that you don't misuse it and get yourself killed or something so what are we going to look at today I'm going to look at extra communication covert channels because they might be useful in case encryption is restricted or outlawed and there's a key subpoena by some court somewhere I'm not going to look too much at hidden path communication because there's been a lot of good work in there with onion routing mixes and things like that and we're going to focus on TCP IP headers because they're pretty universal TCP IP is flowing out all around there and also by just using the headers you're able to piggyback onto legitimate track as an FTP example you don't have to somehow magically make up pictures to send simply use traffic that you're sending anyways and piggyback on top of that in the header so the first one to look at a very simple example is using the TCP urgent pointer and the urgent pointer is a thing is a part of the TCP header there are kind of two components to it one is the TCP urgent pointer control bit and right there next to synanac and fin and this says hey look there's an urgent pointer that you should pay attention to what the urgent pointer itself is is it's a sequence number which points to just beyond the last bit of urgent data and this isn't actually used too often anymore or maybe not at all but the urgent pointer is always supposed to be interpreted if that urgent control bit is set so what you could do is simply not set the urgent control bit yet stuffed it into the urgent pointer pretty easy to do however someone might you know one thing you could also keep in mind is to actually the point to some data so it has to be somewhere near the sequence numbers that you're using so perhaps you want to make sure that the urgent pointer could be pointing or could be near data and sequence numbers that are actually TCP session so now let's look at some of the properties of it it's going to exercise really good bandwidth for a covered channel 16 bits per TCP segment might not sound like a lot but it's quite a bit for a covered channel it could be much less if you try to restrict what the urgent pointer could be so it looks a little bit more reasonable how hard is this to detect it's pretty easy to detect the urgent pointer is rarely used and it should especially never be set or used if the control bit isn't set it's just supposed to be all zeroes and not even supposed to pay attention to and also you could start to look at and make sure the urgent pointer actually is somewhere pointing to some sequence data if you actually started setting the urgent control bit to try to make it appear a little bit more stealthy how hard would this be to prevent? moderately easy you can make it moderately easy if you just examine each urgent bit each urgent control bit whenever there was a line you write the urgent pointer so that it was all nulls if you want to just flat out and rewrite it that would just make it easier a few other things for miscibility currently this will pass through pretty much everything some firewalls and normalizers will of course look at the urgent pointer and see that the control bit isn't set see that there's something anomalous going on we'll rewrite it for you back to all zeroes and it's gone how hard is this to implement it's really easy to stuff bits in there as it's going out in a special case you of course can't use the urgent pointer when you're using the urgent pointer legitimately but this really doesn't happen too often going along with the urgent pointer similar things are starting to use the padding and observed bits similar to the urgent example and that they start to break protocol and they start to do things that no TCP stack would ever do they'll lower bandwidth simply because they're typically fewer bits but you could of course combine this with the urgent pointer to one thing and use that the padding would be easy to detect because if someone said zeroes just as reserve bits would be really easy to detect is misbehaving and some routers may start to drop packets if the bits are set because they just see them and they see that they're just bogus and they should never be like that and sometimes they also rewrite the padding for you especially if they start messing around with some of the options and adding another option is just keeping on that another code channel that you could use in the header is just using the IP type of service the IP type of service in case you're not familiar with it there's a quality of service that you're requesting from the network that your data is going to be flowing out on different things that have like precedence delay, throughput, reliability and then of course they have some reserve bits so all you do is you just set the type of service byte to your data and set it on through but if you want to be a little bit more stealthy the delay bit in the type of service is actually used by say SSH whenever you're sending over keystrokes so if someone were to shift through it they couldn't just look for delay bits being set because they're actually used legitimate so the bandwidth of this if you use the entire type of service field then it's one by pripy data gram which is pretty good if you don't and you only use the delay bit or you only maybe use the delay the reliability bit or something like that then you would get one bit or two bits or however many bits of the type of service field you actually wanted to use and it actually would be really easy because in the entire type of service field because you're never supposed to use it all especially the reserve bits and very rarely are most of them actually used especially the precedence ones however if you use the delay bit it becomes moderately difficult to actually detect because someone couldn't simply shift through and look for delay bits being set they'd have to keep track of you they'd have to look for you using a lot of delay bits in your transmissions perhaps in non-standard ports the telegrams typically didn't use the delay bits and they could also look at it and see that if you're just stuffing encrypted data directly into the delay bit that you somehow had a perfectly even distribution of delay bits being set and delay bits being not be set because in this case you're taking some not very random data and replacing it with really random data and so that'd be something that would be detectable also, permissibility it'll pass through pretty much everything especially if you just set the delay bit because that's something that is used and people pass on all the time prevention it would be pretty easy to prevent you could simply just write out all the type of service bits to zero whenever any packet came through you statically this could slightly alter how you're actually providing service but no one would probably notice no one would probably complain how hard would this be to implement it'd be really easy to get into the type of service field and you're done special cases once again could slightly alter the traffic but probably not noticeably or at least not enough to care about prototype the initial sequence number in TCP sequence numbers are used as an index into the data that TCP is transmitting there's a unique sequence number for every bit of data that's being transmitted out there and from some earlier security the initial sequence number should be randomly chosen to prevent TCP hijacking or TCP spoofing so you can't pretend that you're actually getting packets being sent back to a host and so you want to choose your initial sequence numbers to be the message that you want to transmit so normally your kernel or your TCP stack or whatever would somehow randomly choose a random value to throw and to use for the initial sequence number so all you have to do is go in there and replace that function with your function that transmits the data for you and stuff your data into that field and have the receiver get it so bandwidth, this is pretty low it's only 32 bits per TCP connection of course this is really depending on what sort of traffic your piggybacking is on if you're piggybacking it on one huge FTP transmission you're only going to get 32 bytes or maybe 64 however many if you're just in an FTP session you generally don't make that many separate TCP connections but say we piggybacked on a web server request where you hit the page and you downloaded maybe 40 images you typically make separate TCP sessions for each of those 40 images and all of a sudden you'd have 40 times 32 bits just for that one request which isn't too bad detection for something like this would be you know, quote impossible in that they would expect purely random data to be coming for initial sequence numbers and you'd be giving it purely random data so just by looking at the network they wouldn't be able to tell preventing this would be fairly difficult they'd have to start proxying all of your TCP connections and keeping state on every TCP connection which some proxies serve as old data but that's more sort of a local thing rather than permissibility typically passed on through except for some proxies like I said difficulty of implementing pretty easy you just go and grab that function replace it with the one that sends your data special cases some operating systems like Windows 95 definitely don't transmit random initial sequence numbers they do sequential ones, yay what a thought but as long as you're using a real operating system like some Unix brainer then you should be pretty fine with doing that there was even I think on stash that a couple weeks ago someone put a paper up in a study analyzing the randomness in different initial sequence number generations and ended up working on improving the ones in Linux and I think the BSD ones came out the best another technique is to modulate the TCP time stamp options a little bit and the TCP time stamp is simply just a TCP option that marks the time that this packet was sent out and this method was presented earlier this spring had privacy enhancing technologies 2002 which was right before CFP and at low bandwidth the low bit on a TCP time stamp is going to be random so if you were just communicating with someone the time stamps that were flowing out through you if you had a silicon action like sam modem or something they'd appear pretty much random if you had a high speed connection though they're definitely not going to be random because the time stamp counter is incremented every millisecond or something like that and so if you're sending a packet faster than once per millisecond then you're going to see lots of repeats so the bandwidth of this sort of transmission would be pretty low one bit per TCP segment not too bad detection for this sort of thing would be very difficult if you were on a low bandwidth connection because the bits are pretty random to begin with and granted you're placing them with really random data for the things you could do to prevent that prevention from an administrator's point of view it would be pretty easy to do this you could pretty much just disallow the TCP time stamp option and rewrite the header and just get rid of it permissibility pretty much everyone seems to allow TCP time stamps through how hard does the speed implement it doesn't sound too difficult but there are a few subtle things to keep in mind you're twiddling with the low bit the TCP time stamp and just like time so your time stamp should be monotonically increasing so in order to do this say your time stamp ended in a one but you wanted to flip it down to a zero you're kind of jumping back in time so instead of what you have to do is you have to wait until the time stamp rolls up to a zero which in Linux is referred to as one jiffy so you have to wait one jiffy for the time stamp to roll up and doing that you delay the packets you delay that one packet by one jiffy in which case if you're on a high connection the packets would build up because this packet would be delayed as would all the ones behind it they would also be delayed if you're on a slow connection you wouldn't have that problem because you probably wouldn't have any packets sort of backed up waiting to go that would actually be affected by that so how could you detect the time stamp on a fast connection when you're on a fast connection you're going to have to the covert channel will slow the transmission of the TCP segments down to a fixed rate and it's fixed or converges to a fixed rate because you're assuming that you're transmitting uniformly ones and zeros because the transmitted information which doesn't seem to have any sort of pattern to it so an algorithm you could use to detect this is to look at a host and start counting the number of different values of time stamps that he sends in a certain amount of time and while you're doing that also count the total number of time stamps so essentially counting sort of the number of times that he repeats time stamps but he doesn't repeat time stamps and you take the ratio of the total time stamps that were used over the different time stamps that were used and you get a ratio and the ratio if you're using this covert channel are modified will converge to about 1.94 that's not from any math or anything just from actually going out there and doing it so how could you actually and if you're doing on a fast connection like it's as fast pretty fast as you could get on hosting the networking it'll reach up to about a ratio of 20 or something like that however if naturally your ratio is less than 1.94 then it's not going to be slowed down at all and therefore it becomes you can't use this method to detect it so how could you prevent someone from detecting you if you're using this method on a fast network well since it's slowing it down to a sort of fixed rate how would you slow it down a little bit more and that little bit more to get a somewhat random value so now you're slowing it down by a random amount maybe every connection maybe every once in a while you change it to sort of model your computer might be busy or something so it might be being a little bit slower than normally would and doing this prevents the attack of course it would still be detectable that you are slowing it down and that you're slowing down your transmission which would be something fairly marvelous to begin with but it could happen if your server so also how could you detect the timestamp cover channel on a very slow connection so in a slow connection the low bits appear pretty much random as I said earlier however when you eject this encrypted data into the low bit it becomes more random than it normally is so what you basically have to do is look for this increase in randomness in doing this so what you could do is just get a whole bunch of TCP time just record all bunch of TCP timestamp low bits and then put it through a randomness test the test to see whether it was truly random or not truly random but really random as much as they can tell and then quite a few tests on the internet you can just go and download and throw this up and if the program comes back and spits it back and says yes these bits are really random then the cover channel is most likely being used however if it comes back and spits it back and says these bits aren't very random and you can probably guess that they're not using the cover channel based on this unmodified form and so in order to prevent this you could try looking at transmitting some data that wouldn't appear to be completely random by using some sort of encoding schemes and so now detection and prevention of cover channels in general so first of all detection for some of the semi-covered stuff try to just detect anomalous traffic so it has some of this stuff like invalid checksums and things like that sort of working a little bit on just historic preprock that would look for bad things like bad reserve bits and bad things in combination try to correlate some of them together and keep state TCP sessions how could you prevent this? you could perform normalization in your traffic if you think normalization is basically getting traffic in from somewhere taking it doing something to it to make it the way you think it should look use often when people are worried about 5-out or something evading their IDSs so they want to take it and defy and all their data, desegment all their data so they get to decide how the overlaps are handled and all that sort of stuff and you could apply this in pretty much the same way by taking it and stripping out type of service base, taking it and stripping out urgent base, things like that but you know your network doesn't really need and there's some programs out there that can do this Norm is one, I think it's written by Vern Paxson but we're not sure BSD's packet filter and then there's also a more advanced method like with the timing channel stuff if someone was attempting to communicate by using timing like there was a whole bunch of requests and then not a few not many and then a whole bunch and then not many you could use a pump method basically your router or something collects a whole bunch of data for a while and then sends it out in a burst kind of like it fills it up and then empties out the queue right away granted this costs a lot of resources but it can help to prevent that sort of stuff that's more of a theoretical type thing and one thing to keep in mind is that you can't close all covert channels if you're letting someone communicate data back and forth they can get covert data through all you can hope to do is decrease the bandwidth and increase the difficulty of actually using covert channels to the point where it becomes infeasible so now a few implementation issues if you actually were to try to go out and implement these covert channels well you need to have encryption in there at some level otherwise the covert randomness that you're stuffing back in aren't going to be very random you need to have somewhere telling whether the data is transmitted or not you need to be able to index into the data and say what data is being transmitted and then of course you have to consider the age of the issue of reliability versus bandwidth so first of all encryption is the key component you have to use good encryption to ensure that all these channels are secure if your encryption is flawed somehow say you're doing something similar like some shift cipher then you're using the initial sequence number covert channel then someone could look at this sequence numbers and tell that they weren't very random see some sort of patterns emerging in them and see if something is going on and also if you want to use a secure covert channel you need encryption because you have to assume that your covert channel is well known I mean everything I'm talking about today is well known it's been published in papers and discussed for ages and I'm just kind of presenting it here so you have to assume that your attacker or the people monitoring you also of course know about it and probably have teams of people working on it and another sort of side issue with encryption that you have to keep in mind is you have to ensure that you don't transmit the same ciphertext over and over again like say you just set up some sort of public key encryption system and you were just encrypting the data you were sending out with the recipients public key say you send out the same message repeatedly a few times message like hi do you want to go get lunch today or something like that but you send it out every couple of days and there was no time stamp or anything in there like that and so it was always the same message and if you were sending out with the sequence number method then they would see maybe they would see this repetition of initial sequence numbers happen and they would know if something was going on so one sort of thing you could do to this is use some sort of cipher maybe a stream cipher or something and in addition to using a key with that you could somehow add in a common time that you both share maybe even just the day to try to alleviate the problem of that and so now how do you tell the person that you're sending data to if the data is really being transmitted because if you're just engaging daily data conversation with this person or daily day to day community network traffic you're probably not sending covert data the entire time you probably don't have that much covert stuff to set so one thing you do is whenever you send a group of data then send a checksum at the end this also provides some reliability and things of that nature and then all the receiver would do is shift through the data look at the data and look at the next little bit of data and see if that was a valid checksum from the previous data in this case you have to make sure that the checksum is securely keyed because otherwise an attacker could do the same exact thing shift through the data look for the checksum and find out if there was some sort of covert communication going on another thing you could do there's some sort of magic flag that the receiver watches for sending encrypted and the same thing and the receiver would examine the traffic repeatedly and look for this sort of maybe it's like a sin essentially I'm going to set up a connection and everything another thing you do is just constantly transmit covert data and so they get the same data over and over again which wouldn't make much sense for binaries or things like that but her simple text messages and the receiver wouldn't know I'm getting the same message over and over again but they really just send it once so now how can you tell the receiver what data is actually being transmitted you need to have some sort of index into the data because you're probably not going to be able to send your entire covert message in one packet or one segment or one whatever so one thing you could do is just share with the data sequentially just go through and send it out bit by bit and hopefully they get all this sequence, they get everything and they start listening at the same time that you start sending however another solution you could use is take an unmodified portion of the header and send the data and use it as a nonce and take this nonce and then take a hash of it and then modulate that hash with the total size of whatever the data you're transmitting to get an index into that data and transmit data beginning at that index and that works but the problem with that is that you don't get to choose all of the bits that you're transmitting so you have to sort of transmit essentially random bits out of the data that you're sending and eventually you'll probably transmit all of the bits that will probably knock off my microphone so can you guys hear me in the back still kind of alright you could implement more advanced protocols you could have some sort of TCP over the covert channels whatever you want that provides more reliability and robustness and of course the age old debate of reliability versus bandwidth if you use a hash of the nonce you get pretty high reliability because you're sending the same data over and over again they don't have to start listening at the same time but you get much lower bandwidth because you're sending the same information over and over again however it is a pretty simple solution to implement another thing if you did the transmitting data sequentially and provide high bandwidth perhaps the highest bandwidth you could achieve but it'd be lower reliability if you're listening at the same time and get everything in the right order another thing you could do is implement a more advanced protocol that would kind of trade off some of the bandwidth for more reliability and more acknowledgement that it was actually received alright now on to the the boring stuff I guess we'll talk a little bit about the tool that I wrote this tool is just a kernel module uses proc that modifies outgoing TCP traffic by replacing the hardstar transmit function it's based off actually some code I got from the people that did the timestamp cover channel it's all GPR and everything like that the receiving component simply sniffs incoming traffic using libpcap and looks for the cover channels in the data cover channels that I've implemented in it I've implemented the initial sequence number TCP timestamp load fluctuation with high speed protection which is optional so it'll drop it down to random amounts so that you're not rid of a high speed attack the urgent pointer channel IP type of service and using TCP reserved bits and all these options you can turn them on and off but now they're just with pound defines and you have to recompile it but the interface isn't exactly the best thing and then we have to when everyone has sent data you have to cat it out to slash proc cc and it goes out there that's something I'm going to work on two different types of data indexing that I've implemented in there just straight up sequential transmission of the data takes the data encodes it in there, sends it out other type is SHA of the unmodified portions of the header and the data uses to index into the data and the SHA can be keyed and these are both options and all the options both the center and the receiver have to agree on what exact configuration you're using so they know where to look for the cover channels they know what sort of indexing you're using for things of that nature so some work that still have to be done to improve the user interface so that people might actually use it probably most people aren't willing to set up nice little shell scripts to send out their data after the device maybe make an ice gooey or something like that if anyone is looking to help with it and you know knows a bit about KD or you know programming or something just shoot me off an email I'm more than happy to get some help with that I'm going to build some encryption into it so that you can basically just send in a message and maybe give it a key or maybe you know with a symmetric key or public key whatever and then it sends it off for you so that it once again becomes actually much more usable rather than having to have your own crypto layer of it adding a few more options for more cover channels so that you can start to get even better bandwidth out of it for semi-cover communication that you might use if you're just worried about someone spotting what's going on also it would be nice to go out there and analyze how a variety of different routers and IDS's handler detect this sometimes a legal data like setting the reserved bits maybe write a little program that would go out there and send it out bad traffic like set a reserved bits and see what the other one got and then do that in sort of a manner and then report back to the user exactly what sort of cover channels they can use in that link and have a few little scripts that kind of do it but they're not very polished in any way and maybe build sort of a database of different sort of typical ones that work in typical backlands that you can pass them through in different normalizers that have to treat it and also it would be good to implement some sort of more robust protocol for the data transmission that handles indexing and reliability and all that sort of stuff something similar to TCP or something like that so you can go ahead and jump on the web as soon as I actually get an internet connection the wireless connection has been flaky have people been able to get it to work today is there something magical you have to do like some magic word or something you have to say I made a funny cap and caps I tried that and it's still taking that pity bit I'm lazy and before I let you guys all go kind of a shameless plug the open source vulnerability database is a project that's just starting up and it's going to be a vulnerability database that's run by the community that contains information on publicly known vulnerabilities right there in the wild different than CVE it will be more than just a naming system but it will also contain information on the vulnerabilities, perhaps exploits for them ways to detect the vulnerability what systems are affected, things like that and the website for that is www.openvisosvdb.org and it's not quite operational yet but it's going up there question? I had one question from back before you said implement the type of service you said isn't passed through all rather than possible will it actually disrupt SSH traffic? it won't actually disrupt it we'll still see that we'll still see this going on SSH tries to set the delay bit for keystrokes so that it goes through faster yeah I imagine it could, I have no idea I had no idea but it would be really cool if it could be maybe we've just got the source to windows you have the source right here it will be as soon as I get a net connection yeah, all the source and the tool to detect the TCP timestamp channel and the presentation let me know the 2018 presentation supposedly appears with some action stats cool