 right now. Wasn't that fun? An anonymity. If you were supposed to be in something else, you probably should leave. My name is Khan and I'll be talking about stealth data dispersion. And I think after me will come Len Sassman, Tracing Anonymous E-mail. Okay. Okay. The whole concept here is that it started with the concept of what if you could have data that was mobile and could survive if nodes started getting removed from some sort of a network. So it could move around the network and be survivable. But this is a part of that research which is still ongoing, which has come up, which has some interesting uses for privacy-related issues. So you can talk about what if you wanted to hide data securely without having it on any local physical device. More importantly, the data wasn't in any one place at any given time. So it's moving. And more importantly, what if you could use existing protocols to do it so that it doesn't seem like something strange is going on to IDSs or otherwise snooping folks. I'm sure some of you are aware that sometimes you have a piece of data that is possibly shouldn't be in your possession or even if it is in your possession, you don't want anyone else to ever know that you had it. I'm sure you can come up with what that might be, such as keys, et cetera. And the concept was it is my understanding that most forensic experts when they appear or some sort of legal action or what have you takes place, people usually walk in, grab everything you own and take it to their local federal office or what have they. And how do you defeat that? Just to add one of our projectors to go out guys, DEF CON people. Anybody? Yeah, maybe the plug thing that came in. Sorry, I just put it back in. Probably. Yeah, it's broken. Is it broken? Yeah, the wall jack's broken. Can you switch it? Well, I mean you might have to turn it on. That's what happens when you're the first speaker. Quality testing here. The new guys always get the first. We'll let them work that out. Sorry. We'll let them work that out. So let's move on. So the goal was to recite small amounts of data. I think that's sort of crucial to understand. You can't have megs of data flying around. We want small amounts. And I'll get into that. What it comes into when we start looking at actual protocols, it has to do with your empty use in your protocols such as Ethernet or usually around 1,472 bytes after the header. So that's about what each packet we're going to talk about. I'll explain it a little bit later, but small means small. It doesn't mean thousands of megs or even one meg even. I'm sure you could do a meg, but we'll talk about it later. The simplest way to describe it is it's a drop safe. Like you go to 7-Eleven and they've got a $20 bill. And what do these guys do? They don't want anybody to come in and rob them. So they have a safe there that they stick the $20 bill in. And it's a very safe safe. And only the guy who needs to come and get this $20 bill later such as an armored car or what have you can retrieve that money. I think the main crux of this is an anti forensic tactic. Somebody had mentioned to me when I submitted my abstract, isn't this just another covert channel? I mean, you could consider it an asynchronous covert channel. The goal is not to communicate. The goal is to hide data. So I'll leave it to you guys to figure out. What's the main benefit? The main benefit is that the data will disappear. If the hosts, the seeding hosts, and I'll get into that are removed. So that can be useful in some cases. After looking at, I mean obviously we're going to use the internet to do some of this. Small amounts of data at this case is less than 1,500 bytes, which is based on a PPP and to you my understanding is that the Ethernet is almost the same. The actual, as I said, it's 1,472 bytes that you can keep per packet. And it'll become obvious why. So the data will stay alive on the wire versus a storage device as long as possible. Data is never stored on a host. The concept as I said again is you don't want it anywhere, anybody can reach it. And data is retrieved or refreshed before data expires on the wire. If you look at TCPIP implementation, the biggest issue is that you can't have data around longer than 255 hops. Because the TTL, as soon as it gets to zero, the packet gets dropped. So that's something you have to be aware of, but to be perfectly honest with you after playing around and I was trying to bounce data off Australia, Japan, Fiji, Mongolia even, I got in there doing trace routes. I was getting to most places in 30 hops or less. So I don't think you're going to have an issue of getting close to 255 hops on a single packet. Okay, so what are existing protocols we can talk about? One of the more obvious ones is ECOService. It's on Windows. If you load the internet server, the thing that they have, it's available on TCP, it's available on UDB. That's pretty good. I'll talk about each one of these a little bit more. It's good enough to start off with, but it's not very good because port seven, ECHO, it's sort of obvious for anybody who's looking at your traffic. You can use ICMP ECHO requests. Those are far more interesting and far more useful, I think. The third I would have liked to have more data on I don't yet is multi-casting or somehow tricking IGMP into working for you. Multi-casting is great because then you could send one piece of data out and it goes out to, I don't know, 100,000 hosts over the world. There's a lot of that data going around. I'm sure people are listening to real audio streams and all that business. It's all multi-casted. So that's very useful and these are the three main candidates I came up with. I tried looking for more. I really haven't found anything that'll natively echo back data that you push out. The point is that I only want one host that I control and I want to somehow use all the rest of the hosts on the Internet to comply with me in bouncing my data back. It's pretty easy to say, okay, well, I have 100 hosts dispersed over the planet and we'll all talk to each other encrypted. Well, there's not much to talk about there. You can do that if you have that. But we want to use native protocols to do the echoing. Okay, let's talk about the INID Echo Service. The pros and cons. It's implemented mostly on all UNIX machines. The UDP implementation will be better because we don't need a TCP handshake. Only difference is most people who do follow, you know, on somewhat some security or other guidelines almost always turn these services off. So it's not usually active. Also, it's rather obvious. Port seven, as I said before. My preferred candidate right now is the ICMP Echo Mechanism. The greatest thing about it is the ICMP is required on all TCP IP stacks. Every printer needs it. They have to have it. We're about to put in the RFCs that actually require it. It's part of a, I think there are two RFCs that clearly define that you must have ICMP on all TCP IP stacks. You must also have it echo back pieces of data as required. And almost every ready stack has it. I haven't found a stack that doesn't have it yet. So that's extremely useful. They are required to echo back the original data. You know, how many folks actually play with ICMP more than doing the ping and doing a trace route. But within the pings you can actually put your pieces of data and check it, make it bounce back. And it's actually quite useful if you're having problems, if data is getting dropped or down the stream or something, what you do is you can put a specific piece of data that you think is getting dropped. And that's why they have this mechanism. So you can send it down, you know, down your route and see where it might possibly not get forwarded properly or get cut off or fragmented or what have you. It's universally available and there's a huge amount of ICMP traffic always present on the wire. So it could be very stealthy as long as, you know, somebody doesn't know exactly what you're doing. I might mention, you know, I mean, there's a lot of network management products out there that actually use ICMP echo requests to just check the status of the machine if it's up or not. I mean, you know, obviously that's not the best way to check it. I remember a couple of versions back. Big brother used to do it and I mean, you name it and everybody's using it. So you should be able to submerge your data within that traffic very easily. Okay. What would be even nicer is if I could get the equivalent of that in a multicast or an IGMP-based protocol. Try researching it. I really didn't find anything. Somebody said, hey, why don't you try sending a multicast message to the echo service? That should work. Well, it's not supposed to work because those of you are familiar with multicasting. You can't. Regular TCP services are not supposed to be registered to receive multicast messages. So this is something worth looking into. I don't know the answer yet. That could be really cool if you could do it. This way, instead of having separate pieces of data being dropped to different hosts, target hosts that echo them back, you could have one stream of data go out and get bounced off every real audio server or a real audio client that would be even cooler. There's a lot of people out there, you know, all the time listening to something or the other. So still working on it needs a little bit more research. Okay. So which one is it? It's ICMP. Again, it's available. More importantly than that, it is required and can be bounced. The bouncing case is where you... I'll get into the details of that later, but that'll double your hops if you have more than one seating host where you want to have some sort of redundancy and the data that you keep on the wire. Okay, let's talk about more theory of operation, et cetera. There are two phases to it, a seating phase and a bounce phase. You have a seating host. You start these two processes on it, and here we'll show it a little bit better. Okay, so you've got this red piece of data that you want to hide and you're on your host. The seed injects data onto the network and then quits. Data size has to be 1,472 bytes in this case with a 1,500 byte MTU. So you put these two processes, you seed them, bounce on there. Seed grabs the data, pushes out ICMP echo request. It proceeds by removing itself and all associated data from your machine permanently. Now, obviously permanently doesn't mean you necessarily just do an RM on the file in Unix or Windows or whatever. You better make sure your data has gone zero at the file storage. I'll leave that up to you how you're going to do it. That's really not something I'm going to get into. There's a lot of products, et cetera. Just don't delink it and think your data is still there, obviously. If those are you, I'm sure you'll have this kind of data know this. Okay, now the bounce phase begins. So again, seed's gone, data's gone. All you've got is a process left that's called bounce. So at this point, there is no data on your local machines of any sort. Bounce will provide and keep this data bouncing back and forth between this host and another host. Now, let's make sure we understand this. Bounce has to be written well. You do not want a machine that's swapping a lot or otherwise. With small amounts of traffic, we don't expect it to go to disk or swap to disk at any time. Obviously, it'll be in the RAM. It is my understanding that with some cards and their drivers, it's even possible to have the ICMP business take place right on the cards or it bounces right back. But I'm sure there are other people who know better about this. I don't have the details yet. Point is, please make sure your code is written well. You don't want it somehow ending up on your disk, even in a temporary file of some sort. It shouldn't. I mean, it's too small a amount of the data in Linux or otherwise. But I don't know what the hell Windows does. So it's anything's possible. Okay, so this guy keeps replying. Boom, it comes in, it calls out. But there's no data, it's no longer left on there. How do you get the data back out? Well, you harvest it. But you don't have a process that does the harvesting and it sits there and it's quite obvious because if they do get it, then they have an idea of something was going on. It's strongly recommended that you sniff the data back out on the segment while it's bouncing back and forth. You could have a harvest process, but that's a bad idea. That in itself, sitting on the machine, if the machine is in someone else's power, they'll be able to see it and figure out what that was. What happens if your seeding host disappears? That is, somebody comes, grabs the machine, goes away. Well, the response to the ICMP will come back and won't have anybody to echo it back. So therefore, the data will auto-destruct. Therefore, it won't be no longer there. This will make it a little bit more obvious now when I start looking. The happy faces are all targeted machines that you're going to find on the internet somewhere. Try to find less than 255 hops, although I'd love to know if somebody can even find 200 hops. I haven't been able to. So as I said, you'll get 30 hops. Just to give you a very quick example, so you identify your hosts that you want to bounce off. So get an ISP. Don't get, you know, Josh Moore down the road with the cable modem or dial PPP. All the PPP is useful because he slows down his response time. So if it's a very fast link, you're going to get very fast responses. You actually want to find people with slow links if you can. What that'll do is it'll keep the data away from your machine for a long time. That's what you want. A long time here means one second maximum. Usually I was bouncing off Australia, New Zealand and Fiji and even India, Pakistan, 0.5 seconds for one single 1,500-byte packet. So half a second is the best I was getting. Let's say in this case we have four hosts that we've targeted. So we'll have four ICMP. What we'll do is we'll seed it and send it to four different hosts situated wherever you might. And they'll continue to echo it back and you'll bounce or grab this data and immediately echo it right back to these hosts. I want to mention something interesting. The CSS scramble.c, the first piece of code written for the DCSS code compressed with zip is 2704 bytes, which is in this case two packets. Because each packet is 1,472 data payload on it. So that's just a simple example. If you had that you could actually keep it bouncing around with just two packets echoing back and forth between different machines. I think what happens is at least I do over time and I hope somebody else does as well. You keep thinking you need a lot of packets to do a lot of stuff. You really don't. I mean text files and such are really, really small if you compress them well. So you don't need a lot of data to do this. This sort of shows you, you know, boom, you're echoing to one host, you request this, you request that guy. Then they reply back to you and add infinity and it keeps going on and on. Data stays on the wire. And then you can get a little bit more interesting. In this case, let's say I have two machines of my own and I want them to echo all the data back and forth without talking to each other. I can have them each have four hosts. This is for redundancy purposes. Let's say one machine goes with the other doesn't go. Well, I could have both of these machines echoing this one piece of data back and forth and if one fails and they're both on the local LAN, obviously the other can pick up the data and also continue making sure it exists on there. A more interesting scenario appears if you talk about bounce mechanisms in the TCPIP protocol. I shouldn't say bounce mechanisms but an issue where you can screw around and make things bounce. This has been seen in many different things, no rocket science here. If you wanted to transfer data from A to B, you could grab a host, V in this case, and send a spoofed packet from A with the data in it with the source saying that I am B really. And what that will do is, and the destination is of course the victim host, the packet goes, hits the victim host, the victim host says, Oh, my destination should be B because that was a source and therefore it turns around and bounces the data back to B. So you have indirectly transferred data from A to B. This is actually, excuse me, there's some covert channel related issues also on this stuff. It's quite useful to do something like this. Let's say you have source filters of destination filters in the network you're in and they say, well, you can't go to B. Well, you know, as long as they don't check that you're doing this, you can go to B as long as you find the victim host who implements the ICMP protocol which would be any TCP IP machine. So that in itself is a very interesting scenario but if you read covert channel stuff, it's been discussed before and it's very useful. But we can put it to use here as well to make our data live longer and to provide more redundancy. Looks like I'm going really fast here. But in any case, the moon bounds multi-dispersal. In this case, we don't have hosts that are on the same land. Imagine if you will, and if I can get my mouse here. If I'm bouncing between from A to this guy, this guy, this guy and this guy and I'm doing the same thing with B to these four guys. You'll notice that the four victim hosts are shared between your seating hosts. I can get A to send a packet to the victim host and have it bounced back down to B and B to do exactly the same thing and keep doing that. Now, you can put, these are no longer on the same land yet the data is now on two different networks bouncing around between back and forth. And either of those networks would pick it up when they needed to. This is actually also extremely useful if you're thinking in terms of IDS, et cetera. IDS is unless they make a filter to specifically look for this, won't find it or wouldn't care most of the time. Somebody has to be looking at raw traffic to grab this stuff. More importantly, even if you're not allowed to go directly from A to B, you're not using the victim host not only directly to your data for you. It's echoing down to some other, you know, your friend's computer or what have you where there's another bounce process running. You know, use your imagination a little bit if you take five of these machines located over the internet. Let's say one's in Australia, you know, I don't know, somewhere in Mongolia, USA, South America. You now have data that will remain alive between all five continents using this. And you could take out most of the sites and as long as one is left, this guy can recover, or at least two. They will recover the data. I mean, that's a big interesting concept. I mean, I don't think I'm describing rocket science here, but the issue to understand is what we're really talking about. We're not really talking about, oh, wow, what kind of a really cool thing that everybody else has done a million times. I think the point to understand here is law enforcement can go to five different continents simultaneously. Well, not yet. I think that would be interesting to see if they can. But since they cannot, and I'm not saying it's just a law enforcement issue. I mean, I understand France won't allow you to keep, you know, encrypted communications and all the rest. And I don't know the rest of the government laws and regarding privacy, et cetera, in other countries. And either way, the point is that you will have, try not to look at it so much as a technical advancement. It's not that big a technical big deal, but the concept is to start thinking, well, hey, I can get this data to be all over the world at any given point. I don't need a lot of machines to do it. I don't have to write some hardcore code to do it. Let's say I encrypt some key, put it out there, which is sort of silly to encrypt a key, sorry, but let's say it's an image or something. I don't know. And you start bouncing it around. Well, you know what, if they get me and three of my friends, there's still two of my friends that could recover this in somewhere else on the planet. And I think that's really what I'm trying to talk about here. So again, just give me some very quick examples. I wish I'd gotten more apologized. I didn't. I had the DCSS codes and compressed it and checked it out. It was 2704 bytes. It only required two ICMP ECHO request packets. I mean, that's minimal. I don't know if those of you who saw that shall source code to the patchy worm.c, which is not a really good example. But still, I wanted to give an example. I'm sure it's linked with binaries and all that would be a lot better. In this case, the compressed text C file is 15446 bytes, which would require 10-point-something packets, which is 11 ICMP packets to keep this code. Let's say I was developing this code, which I would never do. And I strongly urge you all to stop. But maybe you don't want to keep it on your machine. I'm sure there are people here who can tell you better about that. Well, 11 ICMP ECHO packets is not a bad way to keep this code out there while you're editing and bringing it on to Emacs every now and then. Possible uses. Well, you can save keys if you have some key of some sort for encryption purposes or decryption purposes more hopefully. You have some sort of source code or otherwise. Emails. I don't know if you snagged somebody's email. It's got some sort of information that you can use later. And you probably shouldn't have it. Well, emails are notoriously small files most of the time. Usually, being text files, you can compress them. Images. That's another story. I think those would be pretty large. And I guess you guys can tell me better than what other things you could save. I think one interesting thing I wanted to mention was if, theoretically, we could reach the 255 hops limit, which again I'll mention for the 50th time, I haven't been able to do, using the bounce you could double it. You could have 510 hops. Because you put it on a victim host, let's say, theoretically, 255 hops one way, 255 hops to the other machine. Theoretically, you could get 510 hops, which is useful because the longer you keep the packet on the wire before bouncing, the longer you don't have it and therefore it's autonomous someone. You can have delayed packet releases on the multiple routes. What I showed was a very simple way of bouncing between two machines, but imagine you're doing delayed releases over multiple routes. Therefore, you can work out some very simple protocol to make sure intermediary hosts are capable of detecting failure and responding accordingly. I'm already at conclusions. That was fast. Felt data disperser. So we can do it using current TCPIP protocol manipulation. It can be achieved very efficiently. I think that's somewhat crucial. I just have to write one seeding host and have it. I don't need a cooperating host to have this thing happen. It is very stealthy unless people are grabbing raw traffic. I don't think they're going to see it or the shit anyway. The ICMP moonbound has been used as a covert channel by dark government agencies. That's what I read. I think it was Security Monday or something. One of the first time they discussed it. I don't know what that means. What I put it there for those who do. I'll be looking at IGMP stuff in the future and here's the URL and all that. And by the way, I just want to mention, I'll give you one second please. I substantially changed the presentation from what it was on the CD-ROM. Or at least what they've put on the CD-ROM. So if you need the latest one, it's substantially different. That one was talking about something more limiting. But I was able to get something else done. Okay, thank you. Yeah, go ahead. So you're going to be using a lossy print color or a lossless print color. If you're using a lossless print color, there's going to be a copy of the data kept on your machine. That's extra. That will happen. And if you're using a lossy print color, you're going to lose your data the first time a packet's dropped. Or a copy of your data. And if you've got to use it, you're going to see the four places. If they all come back at once and you have a network, you can use all your data. So how do you get around that? Well, that's why I was talking about multiple seeding hosts. I don't think if you have something really critical, you should be putting it on just one machine and hoping it's the same old issue if you have redundancy. I mean, if you have one hard drive and it fails, you better have a backup, right? Because I have more than one host doing it. So to catch your hosting, you've got the location where the other hosts are. I'm sorry, I can't hear you. Well, they wouldn't have the other hosts. The processes, the minute you turn it on, bounces code is not sitting on your host, right? The process running and you remove the executable. What I'm saying is that it's only running in memory at the time. And once it's running in memory, I think he has a very valid point that he would have the destination of the host. Sure. Actually, he would be in the ICMP source packet that goes out, right? If you're using a bounce. Sure, that's great. Right. I'm trying to understand your question. Tell me what your exact concern is that we know what the other host is or... If you don't know what the other host is and why it's been like storing the data on the other host. So when you're comparing this to what existing people do, why is this what you're comparing? What they do right now is they're worried about their host being stored on a traffic light, right? Right. So if you don't know what the other host is, why now is the data in your schema and if you have the data stored on the other host? Let's say you have two seating hosts that are apart in two different networks, okay? And you go ahead and start bouncing the data on those hosts and they are bouncing it off two totally separate sets of victims, okay? If I get rid of one host, the other one's still functioning and has nothing to do with this host unless they're cooperating. If you're cooperating, obviously, then you're opening up a can of worms, but that's up to you. But if I take this one out and I take it home, there's no way I know that there's a B machine out there doing the same thing. What's the connection between the two? How would there be a connection between the two? That's true, but more interestingly enough, let's say they do get to the other machine also. Again, they won't find anything, right? I mean, these guys can get anywhere they want. Most of them don't usually watch the ICMP packets with the whole point. After our little discussion here today, that's a different story, right? I mean, they could even watch you, dude. I mean, you can keep taking this to the nth level. They got to watch you type it in or get it in the first place. The point is to have a vault that you can put this data away and have some security. There is no such thing as 100% security. We can only get more and more secure, right? That's a very good question. I don't know exactly... When I'm forging the packets, I was putting an ID in there, like 666 or something, and that's the way for my bounds to be able to identify. I actually haven't done that exact test, but my guess is I'm hoping. I don't know how codes on all ICMP stacks are written, but I think that's a good point. One would have to be careful, but I am already using a different ID on my request packets. I don't remember the exact where the ID field goes or whatever, and all the other packets, unless you're sending your own data in your case, usually have that from 66 character onwards, sort of a string of characters. But I haven't done it simultaneously. That's a very good point. I don't know what it will do. I'm using a LibNet to make the packets and PCAP to capture it. I don't know exactly what it will do if there's two packets coming in. I'm hoping that the session of some sort is held. I can't say for a fact. This seems like anyone who had access to the monitor or the traffic, anyone who seems to be able to monitor it for a few seconds, can get a copy of any data that needs to be stored. Yes, they would. They're going to take the whole thing and capture it. Yeah, sure. The gentleman here said all anybody would need to do is then grab all your raw traffic and watch it and then grab the data. That is absolutely correct. It's such a short amount of time though. You only need 10 seconds of traffic. Well, the issue is which time? I'm sorry. The gentleman said, well, you know, it won't even take but 10 seconds. You're completely right. But the point is, if you give them so much raw traffic, they can't capture it. Let's not think in terms of just one person they're trying to watch, okay? Usually, you know, supposedly the NSA captures all raw traffic. I mean, Jesus Christ, raw traffic is going through the roof. And that's what you want. You want everything submerged in raw traffic and encrypted possibly in some way. So that at least if he's running a sniff or he goes, oh, you know, that looks like something strange going on. I'm going to capture that whole stream in some way. There's no doubt that if you're looking for the specific thing, you will find it. The point is to submerge it in so much data that it becomes difficult. I mean, if I know what I'm looking for, I'm going to find it most of the time. There's no such thing as I can't put it in space, you know? Right. Again, a safe is not a 100% protected thing. If I come in with, you know, all my equipment from the CIA or what have you, but it certainly makes it safer. And this is if unknown to the people who are monitoring you will submerge the traffic. That's just the whole concept. I mean, I'm not trying to say I've come up with some way. It appears forever only you can somehow bring it back. Right. Gentlemen said just camouflage it. You know, some sort, exactly. Some sort of a coding scheme or encryption or what have you. Or make it look just like, I don't know, windows or something. Any other question? You got all the time you want. Feel free to grill.