 Alright, good evening, folks. Sorry about the delay, a little bit of a technical issue here, but no worries. So, first of all, I'd like to welcome you to this particular brief, and what you're going to hear for the next 50 minutes is the first proof of concept tool for IPv6 and ICMPv6 covert channels, and its name is VoodooNet. But before I do that, I have to say happy anniversary to my wife. Today is our anniversary, and God almighty, she put up with the anniversary day coming to the con, right? So, thank you, honey. And for those of you that are married, you know as well as I do, I'll be paying for this for a long time. Alright, no worries. So let's kick this off. Here's the agenda. Just kind of overview what we're going to talk about today. I'm going to give you a quick snapshot of what VoodooNet is, and that way, if you decide you don't like it, you want to leave and do something else. We're going to talk very briefly about IPv4 and IPv6. How many of you went to the IPv6 brief this morning? Show of hands? Hey, that was a good brief, and I'll tell you, it's good because it kind of bridges the gap from what I'm going to talk about and what they talked about, and it's kind of, you know, where do you make the match point? How did you get from A to B? They gave how you got from A. I'm going to give you how you're getting to get to B. I'm going to talk a little bit about the RFCs. I'll talk to you about some of the assumptions that I made while I was developing this software. I'll talk to you about the test network that I used, and then all the slew of capabilities for VoodooNet, and you'll be able to see those through a live demo, even though I had all this technical issue up here, I'm still going to do a live demo, or try it anyway. And then, time pending, we'll have some questions. So here's a quick snapshot. It's a proof of concept covert channel tool that allows data to be passed in IP and ICMPv6 packets, specifically using the echo request and reply payload in the ICMP portion, and then in the IP portion, it actually uses flow label. It can be used as a relay. You can use it for a whole slew of good stuff. But the nice part about this tool, one of the cool features about it, is that you would never identify the route who's sending the information or who the information is actually going to. You're only sending it to a prefix in the subnet. You're sending it to a network, and you're going to let the router and everything do the rest of the work for you. And I'll explain and show you how all that's going to happen. So here's a quick snapshot of how I got from point A to point B. I had to identify the problem, and the problem is some of you heard this morning and some of you may know is IPv4, right? We're running out of address space. Identify a need for IPv6. Who needs it? DoD wants it, and they're mandating it. Read some RFCs. You know, I read through some of the RFCs that talked about this, kind of saw where maybe some holes may be. And then build the IPv6 test network so that I can figure out whether my stuff is actually going to work or not. And then design VoodooNet and design it to be RFC compliant. I don't want it to get mailed by anything along the way. So IPv4. As most of you know, and especially those who saw the brief this morning, there's a limited address space and it's running out. Conservative estimations are somewhere between 2009 and 2016. Things like fiber to the home, all this cool stuff, always on IP. You know, it's depleting these addresses at a quick rate. Now, network address translation was kind of the answer to that. And it said, wow, this will kind of slow the rate. You know, and as was brief this morning, if you're in India, you know, you're nine, that level's deep. But it lacks specific security standards. There's no embedded security. All the security issues were added on top of that. There's a push to move to IPv6 and it's been mandated by the DoD to move to IPv6 by 2008. Pretty close. Cool thing about IPv4, there was covert channel capabilities. IPv6 or IP next generation. Proposed standard happened way back in November 17, 1994. And there's this huge address space, right? Your address is now 128 bits long. It's huge address space. There's security, not only in the numbers, like, you know, to scan for an address is going to take you about, like, 500 million years, right? Who's got that much time? There's inherent security standards right down at the packet level. We're talking about packet level authentication, things like IPsec, if you choose to implement them. There's stateless auto configuration, which is cool. It gets rid of all the DHCP stuff. And, you know, you just have this router kicking out these advertisements and say, hey, here's your prefix and subnet, configure yourself. Hey, that's good for me because that means covert channel capability. And as the last bullet states, it still has covert channel capabilities, mainly this tool, VoodooNet. Okay, so, as you know, you got to go through the RFCs if you want to develop tools to kind of circumvent some things. And one of the first things that I looked at was this 2119 back in March 1997. And it says, hey, here's the terminology that we're going to use when we put together these RFCs. What did I key in on? The word must. Okay, so keep that in mind. Must, you know, has a few other definitions, required, shall. Basically, it says it must be there, right? The RFC right here, 2119, tells you what must means. What does that mean for me? RFC 2460, December 1998, talks about IPv6 specification. Now, one of the fields I thought I might be able to use is the traffic class. Okay? However, the RFC tells me it must not be assumed that what came out of one end is what's going to show up at the other. That means that piece of the covert channel goes away. What it does tell me, though, is in RFC 3697, the flow label. It must be passed by all routers, whether you, you know, want to do anything with flow label or not. To me, that means covert channel. So then we look at RFC 4443, relatively recent, March 2006. And it talks all about ICMPv6, echo request, replies, error messages, all sorts of good stuff. And what does it say? Every node must implement an echo responder function. What does that mean to me? Potential covert channel. And I'm going to show you how that's going to work here in a little bit. Okay, so here's some assumptions that I made before I started developing this tool. The very first assumption was that IPv6 traffic was going to be allowed because RFC 4443 told me it was going to be. It must be there. I must have cooperating endpoints. So my sender and my receiver, they've got to have some things in common, all right? And so they both need to be cooperating. They've got to pass keys. They've got to do all sorts of good stuff. It takes advantage of the dual stack. And I want to take advantage of the dual stack so that I could perform IPv6 over four tunneling. And what this allowed me to do was to get away from, here's a router, here's a router. Not only do I control them, but I control the traffic that passes back and forth, right? How realistic is that? But if I can extend my tunnel all the way over, say, to the UK and let it pass on some six bone routers over there, if it doesn't pass that kind of test, well, then there's some things that are going to be changed along the way. Maybe it's mutable. Maybe my fields and my assumptions weren't correct to begin with. But first and foremost, one of the other things that I looked at was this still maturing IPv6 protection technology. It's just not there yet. It's not fully developed. So here we're talking about intrusion detection systems, intrusion prevention systems, firewalls for filtering things like that. Right now you can kind of get away from this tunneling because you need to have this protocol 41 enabled so that you can get these packets to come through that are IPv6 over IPv4 encapsulated. So here's the test networks. There were two of them that were developed. The very first one was a reflash SOHO, links this router, WRT-54G. Some of you may be familiar with that. I have one sitting up here on the table today. And that allowed me to do IPv6 over four tunneling. That way I didn't need to take a computer and make it a router or use any kind of tunneling on a computer itself. I now have a mobile network. I can pick it up and go and plug in. I also used a slick IPv6 network. Now this obviously is a controlled environment. So, you know, you can talk about whether that was really test worthy or not. No worries. All right, so this is kind of what it looked like. Here's a graphical depiction of what the IPv6 over four tunneling looks like. So you see the two laptops, those are the two endpoints, cooperating no doubt. And the router that's sitting right ahead of them, those are the links, it's WRT-54G. It's got two of them. And they've been reflashed with open WRT. All the IPv6 packages put in there, and now they can handle my dual stack traffic form in and it'll encapsulate and send it out. So that means on the inside, from that router in, I'm talking IPv6 only. I don't need IPv4 anymore. And what that's going to do is it's going to create a tunnel over to BTX Act over in the UK. You know, it does some magic over there, passes through the six bone, comes out on the other side, the hurricane electric over in California, and then goes out to my buddy's house, who's the other end node. So, here's an eye chart for you if you can decipher it, good on you. This depicts the controlled IPv6 network. And so I got three autonomous sites up here. I've got border gateway protocol running. I've got IGRP running for the internal stuff. I've got RIP v6, all sorts of good stuff here going on. And this is a Windows and a Linux using Linux as a router, using Windows 2003 servers as a router. We've got Cisco routers in there, got all sorts of good stuff. So now we get into the actual development. So VoodooNet was written in C using C libraries. Didn't want to use anything else because I want it to be portable from system to system that can handle it. Or if I statically compile it, then I can take it off from another system. The development and the test system, those are updated weekly kernel included because again I don't want to be tied to a specific Fedora version or a specific kernel version. No, I want this to be able to live long and prosper. And it was tested on Fedora Core 4, 5, backtrack live CD and a WAC CD. So the bottom line is it's been tested on a couple different implementations and it worked successfully. And so now we have some more technical problems here. All right, there we go. So this is an ethereal screenshot capture. I'm sure most of you know what this is. And every field that you see that has an arrow next to it is what VoodooNet can manipulate. And specifically where you see the purple, pink depending on your icon, that particular arrow deals with the specific storage channel that's being used. So you'll see that the flow label up in the IP header is being used for one. And down at the very bottom is the data portion of this particular ICMP packet that's being used for the other. Now you also see highlighted down below the little square. And this is what it's supposed to look like Microsoft Windows ping packet. So if you were to ping a Windows, it sends out this nice cool, you know, A through W and then starts over. And so one of the things, one of the cool features about VoodooNet is that it replicates this for every packet. So if you're only sending one byte at a time, it's going to put it in the front and it's going to shift everything over one. And so when this starts going through things that say, well, I'm going to look at payload and I want to see what it looks like. Statistical analysis will say, oh, this is an incrementing ASCII. Don't worry about this packet. So that's how that particular piece works. VoodooNet capabilities, flags, flags and more flags, got more flags and you can read about because every new idea became a new flag. So you put a minus D on there. That's going to be the destination address. And again, you only need to send it to a prefix, a subnet, and a junk host. It doesn't matter what it is. And it's going to get there. It can receive and it can relay. So not only can you have two cooperating endpoints, but you can have a third, a fourth, a fifth, whatever the case is, and your packet will just continue to bounce through all of these relays until it finally gets to its destination. You can send an echo reply as your, whatever you want to send your data out in. Or you can send an echo request. It doesn't matter which one you send. It'll still go out in flow label. It'll still go out in data portion. It doesn't matter. So you can toggle between which one you really want to do. You can send a keyboard. So you just type stuff on a keyboard, almost like a poor man's chat. Type it on a keyboard, hit enter, off it goes to your neighbor's house, and that way you're passing data. You can also send a file. Now the file is going to be a text file, and it's going to break this thing apart, and it's going to ship it out in the packets, however many bytes you decide at a time. The minus i option gives you the interface. As with most Linux tools, you decide if you've got multiple interfaces on the system, I only want to send it out of a certain one. There you go, minus i option. And if you don't put the minus i in there, VoodooNet will kick back and it'll say, hey, you need to enter an interface, exactly what the available IPv6 interfaces are. The minus g for the gateway MAC address. Now this is optional. You don't need it. If you just let VoodooNet run on its own, and you've got router advertisers coming out, it'll withdraw the gateway address out of that. But if you happen to know what it is, it'll expedite your process a little bit, and then you can just go ahead and feed it in there. But it is an optional flag. The minus b flag is also optional, and it says, how many bytes do I want to send in this packet? Now, if you're sending a flow label, you're only going to send one byte at a time. But you're going to use the echo request or reply. You can say, I want to send one byte at a time. I want to send all 32. It's locked at 32 bytes right now, although we've sent up to 1440 in one packet with no problem. So the minus b flag, again, being optional. Now the minus t flag is also optional, and it says, how much delay between my packets do I want to implement here? So I want to send 10 bytes out, and then I want to wait two minutes before I send my next packet. So now you can throttle by bytes and by time. Again, it slips you underneath the radar. Now you just got this random packet going out of the wire. It's kind of hard to track down. And you have a minus x flag. Now this is a four digit key that both the receiver and the sender must have, and what this allows you to do is the guy who's receiving all the data on it, or Gal, I don't want to. Okay, so either way, whoever's receiving the data on their computer can have multiple windows open. VoodooNet requires multiple windows, and if you're receiving, you can say, well, I want to receive in this window with a key of one, two, three, four, and I want to receive in this window the key of 99.99, and I want to receive with key 69.69 in this window, and what that allows you to do is multiple sources can now pour into one receiver, or you can have multiple streams coming off of one sender. They're all going to get to one receiver, and what'll happen is they'll just parse between the windows. It'll decide which one it needs to go to, and that way all your data coming into the computer doesn't just flow into one window only. So you can specify that. It doesn't have anything to do with the way it's encrypted or anything like that. Now the minus O is a Spongebob mode. It answers everything. Now Spongebob, I'll tell you, is a product of too many Mountain Dews and staying up too late programming at night. And essentially what it does is it will answer every ping request that comes into the network. So you want to, of course, this is for the ethical folks in the crowd. You can part this out in your DMZ and actually stop this tool in its tracks because any request that it gets, it will kick back a reply. So essentially any IPv6 address that gets pinged on your network exists, whether it does or not. And I'll show you how that works in a minute. You have the minus D flag. Now that's a verbose flag, and you can use that with the minus O and it'll tell you who the requests are coming from and who, what address they were going to on the inside. So if you wanted to run, you don't have to run, that's an optional flag. And you can also use this in relay mode. So if you're in relay mode, right, your computer's just going to keep passing packets along whether it's a request or a reply, and you never see what's actually being passed. So if you want to see what's being passed, you put a minus V on the end of it, and now you can read all the text that's coming across your computer that's being forwarded to some other party. And then finally, last is the minus H, which is the help menu, which basically just describes everything I just said. Okay, so moving right along, booted net capabilities again. Now this is kind of what it looks like if you were to send, receive, or relay data. This is basically what your command line options would look like. You have that minus D flag that's going to say, here's the destination subnet prefix and then junk host that I'm going to send to. Minus I again, you know, the ETH0 or ETH1, whatever happens to be your interface on the Linux system at the moment. The minus X is the key that's going to be used, and that needs to be again on the sender and the receiver side. And the minus K for the first option simply says, I'm going to type some text on the keyboard and want to hit enter. That's going to get packed up in a packet, shipped forward. To receive data, it'll say, it'll receive either request or reply. It doesn't matter which one. And it's just very blanket, you know, minus ETH0, and then you say what flag or what key it is that's supposed to be coming into that particular window. So again, you can open up multiple system, multiple windows and say, you know, here's five receivers I have going and they're all going to receive data in a different window. And then to relay data, you know, it's almost like sending data, except you're going to relay either an echo request or an echo reply right now. They're split apart. It doesn't do them both in one single deal. So you can decide whether you're going to be a request relay or reply relay, either one of those two. And again, you're sending to a prefix and a subnet. So throughput versus covertness, right? So this is always one of these questions. How much data can you actually push out there? Well, you know, the more data you push out, the less covert you are. And that's kind of the point behind a covert channel is, you know, slipping some data in there so it's under the wires not being seen or heard. So right now, as I stated before, this is locked at sending 32 bytes. So you can send anywhere between one and 32 and so if you're only sending one byte at a time, well, you're pretty covert, right? The chances of that getting caught somewhere are pretty slim, possibly none. But if you're sending 32 at a time and you're sending them real fast, you know, your chances of getting caught have increased significantly. Now, again, every packet that leaves your computer leaves with a different address, okay? So it definitely belongs to this network, right? But good luck filtering that address out and saying, no, this address is not going to communicate on my network. Good luck with that because every single packet that leaves that single host all comes out with a different last 64 and you'll be able to see that when I run this in ethereal. So sending data and receiving data. So what you see on this slide is kind of what the sender and receiver have to have matched up in order for this to work successfully. So to send data, you're actually going to push data out of the network, either through text on the keyboard or file, and it's got this very, very sophisticated encryption scheme called ROT13, for those of you who are familiar with it, right? Okay, so this is really nothing more than just to obscure plain packet analysis, right? If I just happen to grab this thing out of ethereal and I start reading, this is secret data, right? That's probably an issue. However, ROT13, you know, it just kind of skips by, you know, may not draw too much attention to you. You can send it again out and request a payload or reply payload, doesn't matter, and you can throw out a byte by time. Now the receiver on the other end, that's that minus R0 option, and they're going to listen for neighbor solicitations. Now it won't answer every neighbor solicitation that comes in, and for those of you who don't know for a second, address resolution protocol in IPv6 has gone away, and what's taken its place is neighbor solicitation and advertisement. You can no longer actively do, you know, art poisoning, if you will, where you're constantly sending out, hey, this is me over here, this is me over here. If you send out a neighbor advertisement and nobody asks for it, it just gets discarded, nobody cares. So this neighbor solicitation has to come out and it says, hey, who owns this address? If it's a packet that VoodooNet sent, then VoodooNet will answer and say, oh, yeah, that's me over here. So if you're on a switch, it doesn't matter because that goes out to, you know, every port says, hey, who's got this address? VoodooNet pulls it off the wire. The other guy never receives an ICMP host destination or reachable or anything along those lines because the packet's now gone, it's been sucked up, and it's being deciphered onto a host somewhere. So again, this gets away from having to send to a specific host on one end or the other. The network does all the work for you. Now if it doesn't belong to VoodooNet, if it's not something that VoodooNet put together and parsed out, then it's not going to answer it and it's just going to flow on by. Nobody answers it, maybe somebody else answers it. It doesn't really matter. Again, it receives the inbound request or replies and it parses data to separate windows depending on what your key is. Now here's kind of an interesting twist on this, is that you can actually pull data into or out of a network with what looks like a legitimate ping session. And so what'll happen is you send this request into the network and if that means something VoodooNet on the inside, it'll say, oh, that's my packet. I will take this and I will send you in return one byte of data in flow label. Now the echo request and reply, you read the RFC and it says, if I send you a request, your reply needs to be identical or I'm not going to accept it. And so you start getting all sorts of weird errors. And this is where the IP layer for IPv6 comes into play for this particular covert channel. It tucks it up into flow label and the rest of the packet is identical. The ID number, the sequence number, the payload, everything is identical. And again, so this is how this particular thing, and it does some weird stuff on the other side to decipher it. It mucks with the last part of the 64 with the actual address itself and it says, hey, if I take this part of the address and this part and I add my key to it and it actually equals this piece over here, then that's my packet and I need to respond to it or I need to decipher it. So you're not just going to get every packet that flies on by. You can use this as a relay. So you can get multiple parties involved, three, four parties, whatever the case is. And again, it listens for this neighbor solicitation comes in. It will spoof the neighbor advertisement and it will, you know, it will relay whether it is a request or reply depending on what mode it's in. So to test this thing, to validate the packets or survive on a Slick6 network, that's where the Slick6 piece came in. We need to see if anything was going to get mutated along the way and if it was, we need to package or survive in a while, basically in an uncontrolled environment. Some of the initial first testing I did done in this, it passed through 17 hops. 15 of those which were from the UK back into the United States. The packet survive line, that tells me, hey, this thing is going to work. That's a pretty uncontrolled environment. I have no idea what's happened in between the UK and California, out on the 6th mode, whatever the case is. It still has not been tested for survivability in the IPv6 production environment. By this IPv6 production environment, I'm looking for something that's got firewall rules, some sort of IDS setup, IPS, things like that. Don't know how it's going to survive in that kind of a network yet, and once I figure that out, you go through and modify the tool accordingly. So this is just kind of the result that I talked to you about earlier. Use a couple of different tunnel brokers for testing in order to further push the packet out of a controlled way. If it's too large, it will start breaking it up and push it out in different packets. Send it as small as one byte per packet every five minutes, everything survives fine. Now it's demo time, and what I'm going to show you on this particular piece right here, this is what the demo network looks like. It's a single WRT-54G router. It's been flashed with open WRT, and it's routing router advertisements both out of the way and out of the way, just to kind of replicate a very small network right here. You can read through that right there to show you what IP address is what. So barring any questions before I jump into the demo, we'll go ahead and jump in there. Yes, we're way in the back. The SLIC IPv6 network, that was some Cisco routers, some 2610s, 2650s flashed with the firmware that would allow it to be able to pass IPv6. IPv6 enabled basically and pass the IPv6 traffic. And so essentially what I'm running right here is it's not quite a SLIC IPv6 network, but we're not using the IPv, I'm not using any IPv4, it's still pushing out DHCP, it's just not being used in this instance. Does that answer your question? Oh right, right, so SLIC as opposed to what? So SLIC as opposed to IPv6 over 4 tunneling. Okay, perfect. Anything else? No hands, no hands, okay good. So I'm going to jump into the demo and Murphy and Murphy's Law is alive and well, trust me. And so you get the software through all the typos and things that I'm going to make along the way, but we'll get through it all. Okay, so the first thing that you're going to see here is a very loud microphone. And so I'm running Fedorkor 5 inside of VM and we'll come up here and show you this right here. So this is basically just pinging to the other side of the network and that's this box over here on this side. And this is the Linux that's running Fedorkor 4 and you're not going to see very much happening in there right now, right yet. And so that's all that this is doing right now just basically showing you survivability back and forth between the networks. And this is what it's going to look like. It does have an IPv4 address but again it's not being used. So what you see is the 2003, 1972, so on and so on. That's the actual IPv6 address. Now when I first started programming this it became very painful to type these addresses in which is why I went ahead and went into the whole let's truncate this thing and get it where it's a little more livable. So I'm just sending it again to a prefix in the subnet and then a junk host. Alright, so we'll get rid of this window. Okay, so the first thing that we're going to do now what you'll see on this is that my sender windows are white and my receiver windows are going to be a green, a black and green window. Okay, so that's going to happen between both hosts just so you know for a little bit of continuity. So you'll see that on both sides. And so what we're going to do right now is I'll show you this SpongeBob function if you will. So first I'll show you, if you don't enter this minus I in here, it'll come through and it'll say hey, you need to select something from the interface below and it'll tell you interface E0 and here's the IP address for it. So just a little handy guide to help you out there. And so this all it says right now is hey, I'm going to try to find a MAC address for the gateway and then once that is successful it'll say hey, I want to answer everything. So it takes your card, whatever it is, it puts it in your mischievous mode and it listens for everything that's going to come inbound. All right, here's some chuckles out there. All right, good. Okay, so we're going to come over here onto this side. And so now all I'm going to do is just ping over here. We'll have to do a ping six for Linux. And we're just going to ping over here to this other network and we're just going to give a junk host. Right, so it doesn't matter. This thing is going to get a reply. It doesn't matter what host you ping to, we can change this to password. It's going to get a reply. It changes to 8878. It doesn't matter. It's going to get a reply. And so this is what that SpongeBob function does for you. So you can park this thing again for the ethical folks in the crowd. You can park something like this out in your DMZ and it's going to answer everything for you. And it doesn't matter what host is being pinged, it's going to get a reply. Now if I come back over here to this side and I say I want to see who it is that's pinging me and all I'm going to do is just implement the same ping over here on this side. And so this is going to tell you who the request from replies is going to say hey, the request was from and that's this host over here. And it'll tell you who it was to, who it happened to be on the network. So you can get an idea maybe if you got a host that's being pinged or something along those lines maybe something was planted inside your network. So you don't have to implement that function again if you decide you don't want that you can just throw it into this mode and it'll just answer silently and then on this side you're going to get a reply, no worries. Okay, so the first thing we're going to do we're going to go ahead and send a file. We'll send some text first to see if you can get an idea what this is going to look like as soon as I pull up an address from this side over here. So we're going to send this to the other side. This is going to the Dell laptop over here. I see how long it takes to start typing these addresses and maybe you can appreciate why I decided to truncate this a little bit. So I'm going to send this to 99. I already know that I'm going to go out of E0. I'm going to use a key of 99.99 and I'm not going to use any sort of a gateway and so I'm just going to drop in a keyboard mode at this point. So it's going to attempt to find the gateway. It's got it. It'll just tell you're in console mode go ahead and type your message and press enter to send it. So on this side over here I'm going to open up a receiver window which is going to be the screen one on the bottom and the minus R0 flag again is going to say pull in everything whether it's a request or a reply as long as it belongs to me go ahead and pull it in. It doesn't matter. And specifically I'm going to look for things coming in for key 99.99. I'm going to attempt to find a gateway MAC address eventually. There it is and then it'll tell you hey you're now in receive mode and it'll let you know whether your card was in promiscuous mode or if it's still there if it had to been put into promiscuous mode it doesn't matter. It'll tell you whether it's there already. So if I come back to this window press enter on 14 press enter on that and of course as the law would have it there we go. So the message will come across and again this is just keyboard mode you know kind of like the poor man's chat and you can run you can run these back and forth to each window it doesn't really matter. Now if I come in here and open up a couple of these this is where this parsing of the keys comes into play okay so we'll just give this one a key of 1, 2, 3, 4 and come back over to this side and we'll open up another sender we'll drop this guy down here and again it doesn't need to go anywhere specific well this doesn't only matter what this ends with it's going to get there attempt to find a gateway MAC address and when I come back over to this side so I can send window 1, 2, 3, 4 come up into this guy send a window 99.99 so now you can parse different streams coming in from either multiple sources whatever the case is you can have these things opened up and it's only going to get deciphered in the window that it happens to belong to so that's how this particular piece works alright so I'm going to open up a ethereal here for a second so you can get an idea of what some of these packets look like that are coming across here now the filter that I have on here says I'm going to pull in everything that's ICMP v6 but I don't want to look at the router advertisements coming out because they're pouring out and my whole screen will start filling up with router advertisements in a minute so we'll come back over here and we'll just send this packet and this is what it's going to look like one single echo request going out and you'll see here's your 32 bytes of data and so when you start pulling this apart you say oh okay I see this isn't quite what it's supposed to be maybe if you're a ping packet analyzer and you know what all ping packets look like and I'll put you back on the screen so you can actually see what's going on so you'll see the payload section right there that looks maybe like what a Windows ping packet would look like and again this gets into the covert versus throughput right so the more you send at a time the less it's going to look like an actual real ping packet again if you're a ping packet analyzer and you know what all ping packets look like some of the things that you will see on here is the fact that it does have so it's got its checks on, that's good it's ID, it's sequence number all of this stuff is all RFC compliant it says if I'm going to send a 128 my code needs to be zero and no problem there everything's good up here in the ICMP layer but what you'll notice is that the source address right this is obviously not my source address and I can show you that again so here's my source address here you know ends in 62 Charlie Alpha whatever we can bring this window down and if you can read I don't know if you guys can read that thing in the back but you'll see that this is definitely not my source address and the destination I'm going to was definitely not the destination address of this machine and this is where the network does that work for you sends out that neighbor solicitation and if it's something that VoodooNet can decipher and it says that packet is definitely mine it'll send out that neighbor advertisement it'll answer it and pull that packet off the wire okay so the next thing I'll show you here is going to be the ability to pull data out of the network using what looks like a legitimate ping request and for that option this guy is going to drop into what's called an R3 mode and that simply means he's an auto responder at this point and all he's going to do is load data into a buffer and he's going to ship it off as he gets these ping packets coming in that's when the data will actually be shipped off okay so we got all the pieces and parts in there it's going to attempt to find a gateway and what it's doing right now is it's going to pull in that router advertisement figure out what its MAC address is and once it does that it's going to load everything into a buffer and it's just going to sit there and wait and you'll see that sending and it will just sit there all day if your other end gets interrupted for some reason and you can't continue to pull the data off this thing will sit there and when you resume your session it'll just continue sending data from where it left off the first time okay so we'll come back over here to this window we'll do this in a sender mode doesn't really matter what order your flags are in just as long as it knows where it's going okay I think we got everything in here and what's going to happen is pre-autically it will send out an echo request and what happens is if you don't put the minus T flag on here it will vary its time between 5 and 20 seconds between packets and so what's going to happen is one packet at a time and you'll see the whole evolution of events it'll just pull things over one byte at a time one packet at a time and so what happens is this host is sent out let me go ahead and stop this capture so it doesn't keep rolling and I'll explain the sequence of events to you so starting with this echo request right here that's what this particular host sent out and then the router did this neighbor solicitation now say who owns this thing the neighbor advertisement is being answered and the reply comes over the wire and the request comes back and says okay here's your stuff there's an extra request that went out the reply comes back and says hey here's your one byte of data in the flow label so the request and the reply ping packets if we look at them they look identical the only thing that you're going to see different there is your checks on because of your addressing scheme so everything by RFC that's supposed to look the same looks the same now on this side what you're going to see is this thing is just sending data it's just sending sending sending that's coming out of the top window here it's got to send 25 bytes and when it's done sending everything it'll take the card off of promiscuous mode you'll take it out of promiscuous mode and then it'll just end the program and that's it so that's what happened on this side you know 1600 you can set this thing up to run you go home you start pinging into your network you pull information out of it when everything is done wherever you're trying to pull information from the program ends it's gone it's done is history you're not sending packets in or out of the network anymore so that's how this particular piece works and that's what it was meant for so when we come back here and we look at the terminal we'll see it's just coming across one packet at a time and that's the information that you see and it'll just keep doing this one packet at a time and in order to say hey I don't want to trigger any alarms with an IDS or something like that again it varies that packet between 5 and 20 seconds for each packet that it sends out so it doesn't look like it's coming from a machine it just variably sends out this packet to a random IPv6 address inside of your network and then this thing will reply to the random IPv6 address going out so that's how that function works alright so we'll end this and we'll go ahead and send this guy the whole file now and if you're going to send a file again you just use the minus D option because you need to go to a destination we're going to send this to 2003, 1972 a good set of numbers there and again it doesn't matter where you send it it's going to go and on this side we'll need to open up a receiver and we'll open this up in a black window just for continuity and it's going to sit here and wait for this file and so from this side over here once I send this now I can also once I've done sending the file over here just drop into keyboard mode so I can continue typing after that so I'm going to send this file it says the file has been sent and if I come back over to this machine I see my file has indeed been received and because I'm in keyboard mode over here I can continue to type so I'll send this guy on its way and over here is where it's going to show up alright so that's how that piece of the Pi works right there so you can send a file and drop it into keyboard mode and continue sending text and it shows either direction so I think that pretty much wraps up everything that's going to have to do with this tool and I'd be more than happy to either demonstrate or answer questions at this point for anybody who might be curious that particular function has not been implemented yet and the question was can you write directly into a file basically as it's coming in is that your question? so if I'm in receive mode can I just direct that input into something else and right now that has not been implemented yet it's just going to come in and it's just going to dump it right to standard out so again being the proof of concept that functionality hasn't been implemented that's been thought of I just didn't do it yet so any other questions? the source code is not available yet yet we'll sit down here so yeah the source code is not available as of yet eventually once I get everything squared away and it becomes a little more than a proof of concept that may go ahead and find its way out to source words you know there's some some ethical issues and all that stuff behind that I'm sure most of you know but yeah eventually it'll find its way out there it's just a matter of time and getting this thing cleaned up any other questions comments, issues or concerns? yeah are you? yeah right so the question is can we use the program to or change the program so that it can pour a tunnel session and right now that hasn't been implemented or thought of because it's been used mostly just as a covert channel passing and not along the lines of tunneling other protocols inside of that yet so again it's in development and it will remain in development for quite some time so it's definitely an idea and an option that may be implemented down the road but right now it's just pushing data out through text or file one more time right so the package sanitization and it hasn't been tested against that as of yet now what I can tell you is that it's RFC compliant and so it really depends on what free BSD or whatever BSD does to that particular packet when it comes in in order to scrub it if it takes it it makes it its own changes the ID the sequence the payload and all those kind of things then it may not survive that particular hill if it only looks to see if maybe is this thing definitely RFC compliant are the fields zero that are supposed to be zero like say code for instance if that's not zero I'm going to change it to zero and then send it in send it out if that's all it's doing at the point then it will survive that particular scrubber so it hasn't been run against anything like that yet just you know still testing it out and creating the proof of concept a little more firm perfect any other questions comments perfect enjoy your time at DefCon 14 thank you very much