 Hi, everybody. Welcome to DEF CON, the DEF CON 10. We're here today talking about the DC front-end project, something we've been working on. My name's Chris Davis. I'm with Red Siren. I'm a CISP. My focus mainly is penetration testing, vulnerability assessments, and this is the presentation screen. That one's going to be for demos, so look over here. I don't know who's running that show, but... We will if we could. Can anyone turn off that light? The plug's over there behind the curtains, so... Maybe? Please? Excellent. All right. Thank you, man, and purple shirt. Like I said, my name's Chris Davis. I do pen testing, vulnerability assessments. I've been working in InfoSec for about five years now. I've been doing computers in general quite since I was born, pretty much. My name's Aaron Higbee. I'm a consultant with Foundstone. I'm out of the Washington DC office, and most of the time I do attack and penetration testing for our clients. Chris Davis and I actually met while working at Lucent as part of their professional services organization, and Lucent isn't doing so well, so we've both kind of part of the race, but we've continued to hang out and work on security related projects together. Like I said earlier, my main focus is attack and penetration testing. A lot of times I've been called in to do an insider pen test, where the client wants me to be inside with just an ethernet jack and see exactly which information I can get to, and one time in particular, the client was interested in finding out if I could get physical access into the data center. So I was supposed to be posing myself as a normal employee, but they wanted to see if I could get into the data center while I didn't have access. So I've heard about the old crawling over the ceiling tile, so I said, hey, that sounds like a good idea. I'm going to try that. Well, I was able to find an adjoining office area that had a row that was right next to the data center, so I decided to try this out. When I looked in this office, I saw a table, desk, and a rowing chair, and I needed to get up to the ceiling. I didn't be a ladder with me, so I decided to put the rowing chair on the table, and I did not recommend that to anybody. But for the most part, it worked. I was able to remove the first ceiling tile on my side, and then I said, okay, well, it's time to jump down to the other side, and that's when it hit me. That's a lot easier said than done. So I removed one of the other tiles. I slide it over, and then in the process of actually heating my body over the row, I break two of the client's ceiling tiles. So I'm not going to be able to pass the ceiling. They know that I was in there. It was quite a chore to actually get in there, but I was in. I didn't have a laptop with me or anything. It was hard enough just to get inside. So my next step was to find some solar that they would think valuable that I could get access to. So I walked through this data center for a while, and I'm not familiar with it, but I think I find what's the payroll and accounting server. And then I took me about five or 10 minutes to find that, and then I decided, okay, well, I'm going to try to log into it or do something to it. It took me another five or 10 minutes just to figure out the KVM. Finally, I was in there long enough to say, you know what? They're going to know that I'm in here. I broke the ceiling tile. There's stuff all over the floor. So what I ended up doing was just leaving a business card so I can put my final report, yes, it's possible to gain physical access to the data center. But what I really wished I had was my laptop or something that I could have done or something that I could left there to get me access later. I actually had a similar situation. I didn't leave a business card though. I took that and a couple other personal items that I don't think they wish I could have taken. I was doing a pen test for a physical pen for a bank a while back, and they had four levels of access control just to get into their data center. We're talking the data watch cards and some biometrics to get back there. And so I was thinking, geez, am I going to get in? If I'm going to get in, it's not. I'm not going to be there for long. So fortunately, I was able to listen to this guy's voicemail at the company for a while, pick up his voice imprint. I called the secretary, said, hey, yeah, let this guy through. And then she let me in. I'm like, great, this is awesome. Unfortunately, she also called an escort down for me. I had to use a bathroom, obviously. And in that, in the meantime, went around, had some fun, went through their knock. But unfortunately, I only had about five minutes there. You know, even though I sat down and read this guy's email, you know, modified his presentation he was working on for some client. You know, it still didn't work out that well because I didn't really do that much while I was there. If I had something I could have dropped off, left there, had it do the work for me and just go home and wait for something to happen, that would have been a lot better. And that's the stuff we're going to be talking about today is a concept we've deemed 180 degree hacking, also known as phone home. We've done it on a few different platforms right now. It's not limited to these platforms, but these are the ones we've done it for so far. Use your imagination. I'm sure you guys can think of tons of different ways that you could use this. We're also going to demonstrate it for you and we're going to tell you what you might be able to do to stop it. Throughout the presentation, we're going to throw out some names of tools that we're using and maybe some links. We're going to try to collect all of that information for you on our website, dcphonehome.com. It's a slash dotter and it's running off of our DSL line. So if anyone would like to help host it, we would appreciate it. Then you can actually go and check out the content. But we have collected for you the links that we're using, some documentation and also the the x86 bootable CD for you to download. There's some basic assumptions that we hope everyone here is familiar with Linux, networking, VPNs, firewalls, proxies and other hacking tools like Nmap, port scanners, and other things. Even though this is the 101 class, it's not really a 101 topic. But you guys can be able to get it. It's not a hard concept. The thing we're attacking is the conventional enterprise security model where you have your firewall, you have your DMZ, you've got your private addressing internet, netting. Some companies, some organizations are starting to go towards higher levels of security. They're watching their networks with their IDSs. They're only allowing in authenticated with tokens for remote access. They've got proxies up so they can filter URLs, mainly porn sites. They're doing content checking on their email, permit viruses. They're hiring people to watch these things and also hiring consultants slash experts to help them fix their problem. But all of this is, in our experience and as the years that we've been doing this, the same thing we've been seeing over and over again is that networks really have this hard crunchy outside and it's really soft to each other. So all this focus seems to be on the perimeter, the intrusion to Texas system, the DMZ, the private net. You know the data that's valuable, that's worth protecting is on the inside. And so as a side effect of putting all of our efforts in protecting their perimeter and keeping bad guys out, networks generally in our experience have been very vulnerable on the inside. So we want to get to the inside. The problem with building a soft chewy inside and a hard crunchy outside is that we're figuring that networks go both ways. They go in and out. Traffic can pass. When you have a company, you need your employees to be able to access the internet. They need to do research. They need to send email out. So they do have a data path in order to get the information out and to exchange information. Another thing that even hackers are focusing primarily on the security with the latest vulnerabilities. How can we get into the perimeter? How can we export the next zero day F overflow and set up a BNC for IRC? So what are companies using to help protect their perimeter? What are they using firewalls for? Mostly to enforce inbound traffic rules. We only have these ports into our organization. We only have these ports into our web servers, into our DMZ. A lot of people are using the firewalls for NAT, which does help out for security. People just can't contact their internal hosts directly. People are using the firewalls for authentication, VPN gateways, lots of different uses. Another thing people are using are proxies. A lot of times it's used for performance enhancement, web caching proxy. If everybody's going to Yahoo every day, you don't want to send that many requests over and over again. Proxies, unfortunately, they don't have much in the way of protection, except with URL filtering, are some dirty word searching. Also, at the same time, these proxies, if a company makes an attempt to make a proxy, or if somebody out here wants to code a proxy that actually checks the content, we're talking XML or HTTP content, they have to check a crapload of stuff. The W3C has a lot of protocols that they're already enforcing, or they're already recommending you use. They're also developing a lot more, and so proxy manufacturers, developers, actually trying to keep up with this pace, it's a hard thing to do. Another thing that we're attacking is the network intrusion detection piece. Again, in our experience, it's focused on the perimeter. Some companies do set it up so that they've got multi-layered, multi-points of presence on their network on every segment, but a lot of places don't want to spend the money to put these up all over the place. They want to set one right next to their firewall, listen to all the traffic, and be aware of all the incoming attacks. Another problem with NIDS, though, is that it's based on signatures. It's based on a predefined attack, and so it leaves out things that are unknown. Some companies are trying to, or saying that they've developed anomaly detection technology, but by definition, an anomaly is undefined, so how do you define that? Okay, so we're attacking the soft-cheese center. Most people believe that outbound connections they're initiated from the internal organization are trusted. They're sent from employees who are trying to do work, and there's a general notion that outside traffic coming in is bad, and anything reading the network is good. So we want to somehow be able to take advantage of that to get to the data inside. Another problem with internal security these days is most of it is directed toward network devices, to servers, to the NT farm, to the domain, and the problem with that is there are a lot more than just computers on your network. There's many things that are capable of being very powerful computers that can launch attacks. I don't know if you caught FX's talk, but he showed some really cool tricks with a printer just to prove the point that these systems are capable of more than just what they were designed to do, and so when we're looking at internal security, we want to be aware that other things on our network can be used as an attack point. One thing that I learned two or three weeks ago, I think it was on security focus, was about there was a security paper about the Xbox, and how the Xbox can potentially cause a threat to the internet, because millions of Xboxes will be deployed on people's broadband connections, and someone may figure out a way to use those as a denial of service attack tool. After I got done reading that advisory, I thought, wow, that's got to be the most boring, unimaginative thing I've ever read. You've got a computer on someone's network, and the best thing that we can come up with is to take down eBay. I think there's something else missing here. We could probably do a lot more of that. One of the things that folks on slash dot fail to understand when they were going on on their comments about what we're doing is that we're really attacking an idea of what computers are. Our definition of a computer is a general purpose architecture. Anything that has a chip in it that's general purpose can run malicious code, can run attacks, can be made to do anything you want pretty much because, well, it's general purpose. So the 180 degree hacking, the crux of the biscuit, our main question is why even hack the network? Just bring it home. Make it easy on yourself. It's based on a couple things. One, firewalls are pointless. I'll come back to that in a minute because somebody might disagree. Two, it's based on a delivery mechanism, whether it's physical delivery of a system, whether it's a zero day exploit or some vulnerability of a system that you can exploit and deliver some code on. It's based on the internet. Tunneling, VPNing has to flow over the internet. It's a beautiful thing. It's also based on getting people to do things that they don't think they're doing, con jobs. Now, I did say firewalls are pointless. I fully believe that in this attack firewalls are. What we do is the attack is based on using an authorized protocol that your organization or your firewall is configured to use to figure allowed to pass through. We're using that to get data through. Some people talk about covert channels in this type of context, but we're getting a lot of bandwidth. We're not just getting a couple bytes here and there. It's firewalls two-way, let data in and out so we can take advantage of that. The one thing Chris mentioned was physical access as being a delivery mechanism. Where we want to get across is physical access is pretty easy to obtain, especially for short amounts of time. If you think about where you work or where you've been in, it's probably not all that hard to get into an organization for one or two minutes. If we were able to get that access for a short amount of time, maybe if we had something to drop off, we would have a data path back into the network. What you're really limited in getting physical access into an organization is your creativity. Those are your limiting factors on getting inside. We have some slides for you to show us just how simple it is. Walk you through the process. Just so you can get a clear picture. It is pretty complicated here. Now, what we have here, we like to call the super stealth method. Here, this is where the black cat lives. He's got his black cat on. Interesting enough, it comes through his window. We're not quite sure how he did that, but he did. What he is intending to do is he's going to read his room. He's walking into the front door of your company, and he's going to walk by your intrusion detection system, by your DMZ, by your firewall, and onto your internal network, and he's going to put this thing there, and he's going to go home. We actually tested this against the neds, and it never showed a single alert. Now, the single packet is used. Very stealth. Okay. In this example, our black cat is a little more timid. He doesn't actually want to go in, and maybe he looks funny, and maybe he'll stick out. What he decides to do is he leaves his home and he goes to the mailbox, and he has things that he's going to mail. Here's the postman. He's coming, and he's delivering to Bob, and Marketing, and CERNHR, something for anyone to put on their PC. Of course, everyone's going to put the Elvis CD in their PC, because it looks like Elvis. That's pretty cool, right? Everyone loves Elvis. So they're going to put the Elvis CD into their PC. So that's another way to deliver something into the network without using a single packet. Another way, and this is somewhat of a little bit better known method, something we call the smoke screen. I'm a smoker. I don't know how many of you are smokers, and I bet probably a good 90% given the audience today. We're trampled on. We're told to get out of places. They were killing people. We're told not to come close to me. People in L.A. will come up to us and cough in our face, just to show, I don't know, because they're probably sick. Because of this, you can form a really quick bond merely through the presence of a little stick of tobacco. You walk up to the back door where the smokers are hanging out. They're having a good time. You strike up a conversation. They give you a light. They give you a smoke, and they let you in the door. It's very effective. Another way to do it is to pray on people's kindness, pray on compassion. If you're carrying a big box, you're stressing under the way of this thing, even though all you've got inside is, well, a dreamcast. You're just straining under the weight. Somebody will open the door for you. Somebody will hold the door for you, even if there is access control on it. Most times, people will be nice enough to do that. Another way, some organizations do have a policy where their employees, they encourage their employees to confront and to ask people that they don't know, that they've never seen before. Who are you? What's your badge? What do you do here? Well, a really easy way to get around that is just talking to your cell phone. It would be extremely rude of that person to interrupt you and to actually ask you who you are. And since you're holding the phone, they generally open the door for you, because that's the nice thing to do. Okay, so assuming you don't want to do any of the physical access hacks, which are generally easier and more stealthy than you can imagine, you can always rely on the zero-day exploit. There will be another one that will come out that will allow you to get some type of data in a treasure horse, or something like we've developed today with the 180-degree hacking, that would allow that software to establish tunnels back. The other guys are familiar with zero-day exploits, so be creative. So after you deliver this thing, after you deliver this device, what's it going to do? It's going to discover your network, it's going to cover what's on it, it's going to enumerate what traffic you can get out, it's going to see what ports you're allowing through your firewall, and then it's going to create a total home and establish the connection. Similar things, not as comprehensive as what we're doing, but they use some of the same ideas, peer-to-peer file sharing. That is pretty much a virtual network between two endpoints that allows you to share files, chat, you know, stream content, chat applications, such as AOL as a Messenger. Can you guys hear me better now? Sorry about that. Chat applications such as AOL as a Messenger, it will try. First, it will try to get out $51.90 if it can't. It tries Port 80 with HTTP. If it can't do that, it will try your proxy. Same thing. Also, there are remote desktop apps. Go to mypc.com. It's pretty much VNC with a bow on it. You know, you go up to a site, you register, you download some software, install it on a client PC, you connect, you go home, you log into the site, and there's your desktop. And it's free for the first month. Okay, so a little bit more about what our devices do and the process that they go through. We mentioned that we did it on the iPad, an X86 bootable CD, and the CD ROM, but they all do the same thing. What they first start off doing is they automatically get a network address via DHCP. So that would be one way to stop this. Turn off DHCP or at least have some type of port-based access control. We'll take questions afterwards. The next thing it does is it figures out what outbound traffic it can get out onto the internet. Now, we're assuming that not all outbound traffic is let out. So what we do is generally, we're even on a lot of networks. And for the most part, we check the ports that are allowed out. AD is usually allowed out if it's not proxied, SSL, UDP 53 is sometimes allowed out. Sometimes the port 20, the FTP data port is allowed out. Certain types of ICMP are occasionally allowed out. So what happens after lending things boots and gets an IP address is it goes out and it checks Google on port 80. And if it can go to Google, it writes into the info file. Yes, I can get out on port 80. And it basically builds a configuration file of all the protocols and the access points that it can get out of the network. Okay, so then another process gets kicked off where that is analyzed. And basically, if it can find a TCP port out already that's available, it will start a VTUN session back home. And it will build a fully transparent VPN back to our home system that will allow us to get back on that internal network. So let's turn it up a notch a little bit and say 80 is not allowed out. Okay, 443. It'll try that. And if it can get out, it'll build a tunnel there. If I can get out on those TCP ports, let's see if it can get out on DNS via UDP 53. If it can get out on that, it uses Cype to build a VPN tunnel over UDP back to our home system. If it can get out on that, it tries ICMP. And if ICMP is allowed out, then we use ICMP tunnel to build a VPN back to our home system. Now, let's assume that this network has done some due diligence and they're walking on other data paths except through a proxy server. So we go to the next phase, which is the proxy finder. And what will happen at this point is it'll try to do a zone transfer internally on the internal DNS that the DHCP gave and they'll write all the names to a file. But maybe that won't work. Maybe zone transfers are locked down. So they're going to go ahead and do a reverse lookup on all the IPs on the segment on the network that it's on. And they'll write that to a file. Then it basically grips for things that we like to name our proxy like proxy, square, cash flow, pretty much what we gateway, something that we use as a proxy. A lot of people named their proxy servers that then they'll go ahead and port scan those proxies to try to find the proxy port, whether it's a square port or 8080. And if it can do that and it can find the proxy, it'll then start HTTP tunnel. And inside of that, it'll wrap SSH and PPP and build a full VPN back through the proxy server. And if it can do that, then it's sad face and it didn't work. So what types of delivery we're talking about? We've talked about drop and go hardware. We mentioned that earlier at the beginning of the presentation, the Dreamcast. We've done it on the Compact iPad. We've got a bootable CD-ROM. We can slip into an unused system or maybe it's after hours on a Friday afternoon. And there are a couple people wandering around. They're not going to be back for the weekend. There's always the remote exploit. But a question that we've been asked and that we've asked ourselves many times is, why did we pick a Dreamcast? We really wish we did not, but we did. It's a pain to work with, but one of the big reasons we picked it is that it's innocuous. It's a toy. It looks like a toy. People that, if you bring it into a company and some head honcho VP comes up and says, hey, look at the Dreamcast. My son plays with that. It's fun. They don't think it's going to hack. Another reason is that it's cheap. You can get, or used to be able to get one of your Ritha slides, everything for under 100 bucks. Right now, since the slash dot article, you're going to have a hard time finding the broadband adapter because everybody else is. It has 10100 ethernet. That's the broadband adapter I'm talking about. It's got a really powerful processor, believe it or not. We heard Linux was running on it and we wanted to try it out. What a good use. Dreamcast is based on the Hidachi SH architecture. Similar things that used that are the HP Jernada series. We could probably port a lot of this stuff to the Jernada fairly easily. It's added pretty fast speed for this type of stuff. We're not dealing with a 5 megahertz processor. It's limited to 16 mega-vran, which made things really difficult. It has no writeable storage. It does have a real tech ethernet adapter for Linux compatibility. The keyboard is helpful for typing stuff sometimes. Imagine developing this and moving off that one back tick in the shell script that makes it not work. But guess what? You get to burn another CD and fix that error. That can make a pretty painful development process. I think Chris must have gone through over 150 CDs to get this thing going. Easily. Just last week. Building the distro, there was a group, SHLinks.org, where they had a lot of RPMs that we could take and throw on there, build the whole file system from a ground up. We had to add a lot of our own things, though, because they just weren't compiled for it yet. Actually, getting things compiled for that, we had to put together a cross compiler. We had to make sure that the versions of the compilers were compatible with the GLIBC version that's on the Dreamcast. It turned into a big headache, but we got it working, thankfully. We had to patch the kernel. The 2.4 series does have SH support, but it doesn't have everything you need. It's not the most up to date. If you're going to do this, I recommend using the latest. There hasn't been a lot of development either, except from SHLinks.org, which they release stuff every six months to a year, because, well, you can't really get it at the store anymore. Another thing we did this on was the Compaq IPaq, as we like to call it, the iHack. We used the Model 3765. You can use it on any model, pretty much. It's got a strong-arm core proc that's been supported in the Linux kernel ever since 2.2, possibly at the patch level before that. It's got quite a bit of RAM, much more than the Dreamcast did. It does have Flash ROM, so you got writeable storage. We could get the dual-slot PCM-SATA expansion pack that also has a battery, so we got extended battery time as well as expansion capabilities and interfaces that make development a lot easier. Go ahead. As I mentioned, it's been in the kernel since 2.2. If you go to handhelds.org, there's a lot of people actually developing for handhelds because they're sick and tired of having pocket PC on their handhelds. There are a couple distributions for the iPack in particular. We used Familiar. The release at the time was version 052. We were able to get a native compiler on the system to actually work with code on the system and test it right then. Development went a lot faster on this than it did on the Dreamcast. Okay. We realized that everyone's got a spare Dreamcast laying around or an iPack to play around with. We thought we could use any computer really. Trinix is a really cool Linux bootable floppy distribution, but they also do have an ISO. We basically ripped apart Trinix, put our scripts on it so we could run on any PC. We wanted to make sure that we included the PCMCIA core, so we run on laptops as well. It's about a 20 meg ISO. It should be included on the Defcon CD. We encourage anyone in this room to burn that ISO and put it in their systems and try it out. Please use it. We want to see what your networks look like. It doesn't actually phone home, we promise. What it does do, I'm going to give you a little fair warning, is when you boot it, it's going to try to contact Google. It's going to try to contact EarthLynx SMTP. Thank you, EarthLynx. It's going to try to contact CSC's DNS server. It's going to try to ping Google. It's going to write all that to an info file for you. Then it's going to try to find your internal proxy server. We'll do a zone transfer attempt on your internal DNS. If your DHCP is handing out an external DNS, be fair warned. Then it's going to write all that information and it's basically going to tell you, hey, yeah, this will work. We're able to get out on these protocols. We're also able to find your proxy server. Here it is. That's a handy little thing. If it's not on a Defcon CD, we're told that it is. We will have that available for everyone to download so they can test out their networks. TRINX was nice to develop on. It uses a 245 kernel, so IP tables and all that that we needed to use worked fine. It was easily modified with the help of VMware. I didn't have to burn an ISO every time. VMware has got a nice feature where you can point it to a CD, an ISO to boot off of. That's how I did all the development with it. I took the ISO apart with some software, pointed VMware to the ISO to test it when it didn't work. We built the ISO. It didn't take that long, but VMware was a big help in building this. Didn't you only burn like one CD? I only burned it once. Some of the tools that all the platforms have on to do their immigration and the DCP, of course, there's NETCAT, there's NMAP. We also put a lot of security tools on the platforms for you. If you want to do SSH back into your device that phone home, all of these are fully capable of running DSNAF and FOS and are all capable of redirecting and sniffing switches. If you wanted to do that, the idea was if the proxy was authenticating, we would have some tools there that would help us figure out passwords to use the proxy. We also put tunneling apps on all of these CDs. We really got to put our hats off to the developers of these software suites. They did an excellent job. We then started using proxy tunnel, which is another similar concept at proxytunnel.sourceforge, ICMP tunnel, STunnel, PPP and SSH. Another thing that really helped us out was the building Linux VPNs book, much better than the how-tos. That's actually one of the reasons this whole thing started because I was working on a couple of chapters of that book while Aaron was doing a PIN test. It was like, wait a second, we can tunnel out of their network. The evil FOS started running. Some other basic tools are on the CD. If any home is simplified, you deliver it somehow, exploit, you walk in, you do something. It boots, it figures out the network, figures out which traffic it can get out on, starts a tunnel home, and then allows your home system to get back to the internal network that it lives on. So now we have some demos for you, probably one of the things you guys want to see. I'm going to just run down the line for everyone. It's pretty complicated. This system in the middle here is our firewall and there's different network scripts that we have on it to simulate networks that are more open than less open and the ones that were restricted only via proxy. All of these things do basically the same thing, the Dreamcast and all the other distributions. So what we're going to start off with is booting the Dreamcast and tunneling home. Now the idea is it can find a TCP port and the Dreamcast will be able to tunnel through the firewall back to the attacker system. Chris is the attacker system. Now we're kind of limited on projectors here, so we wanted to put the Dreamcast screen up here and then he'll switch over so you can see that the tunnel was created. We're going to show you one side of the attack, namely the inside on the Dreamcast and then for the other two we're going to actually switch to my system where we can see the tunnel being received. So I'm going to go and just as a preface really quick, like we were talking about earlier with delivery, you pick it up, you put it down, you plug it in, and you turn it on. Which is pretty cool, a VPN that works automatically and only has one button. Yeah, we're hired sometimes for like two months to get VPNs up and running, so we're not going to tell them about this. Let's pull it better that way. So this should be familiar to you all? This is the Eco's Bootloader Red Hat Puts out. I think they've stopped development on some of their good new Pro Tools, but as you can see it's using BootP right now to grab an address. It's going to be loading the kernel and the in-it RD image from different segments on the disk. It's all scripted right now so it boots automatically. There'll be stuff flying by there sometime fairly soon. It's not fast, I'll tell you that much. It's like a two-time CD-ROM. There's our little penguin. Okay, so the Dreamcast is right now it's a basic network configuration that's natted. Some outbound traffic is blocked, but it's going to find a TCP port that it can speak out on. You can probably get in and out before it's done booting. Yeah, there's a typical boot up sequence. I think it's enumerating the network. No, no, no. It's looking for networks now. That's where it's find and open. It's starting the tunnel sometime soon. As you notice it's saying you can't find device ton zero. VTUN uses the ton tab driver built into the kernel and what I did is because the Dreamcast isn't necessarily the most reliable mechanism. I sit in a loop trying to establish the connection over and over again until it finally is established. Now, as you see, it's established right then. We have IP addresses of the 10.0.1.network on this side. Now that you guys can see and that's established, I'm going to unplug and put it in my laptop. Okay. I'm the victim on the corporate network. I have an internal 172 address, but now that this tunnel is up, Chris can route through it back and get any of the hosts that are on the internal network. In the smack dab of the chewy center. You want to ping or... We're up yet? Okay. Sorry. It's a little bit hard to read, but right now I'm going to be pinging. First, I'm going to ping over the tunnel. I'm going to ping over the tunnel. As you can see, we're scrolling up those your ICMP packets. So the internal network is now joined with ours. Now I'm going to set up a route over that to the other side to ping a host on the 172.16.101.0 network. What happens once it is able to establish the tunnel? It takes all the network information that it was got during the initial enumeration phase and it spits it back through the tunnel. So that way you know the IP address scheme of the internal network that it's sitting on. So we can set up the routes easily. There's my route. I'm being accepted. Now I'm going to ping 172.16.101.51. As you can see, we have packets scrolling on the bottom. So we have connectivity now. Firewall, our rule sets are based on what we want to define would circumvent their network devices. Okay. So that was a pretty basic network. Hopefully our networks are just letting out random TCP ports. Chris is going to move over to this fire to the firewall now. He's going to turn up a notch. He's going to block all TCP traffic. He's going to make it so the devices can get out of a single TCP port. And the idea is we're going to use the IPAC on this demo. And what it's going to do, because it won't be able to get out on any TCP ports like the Dreamcast was, is it going to figure out that it can get out on a UDP port and it's going to build a site VPN back home? Now as you can see up on the screen, I've got a script that will run my, let's say run a Cype Demon on the mothership here to listen for the IPAC's Cype Tunnel over UDP 53. Okay. The IPAC boots a lot faster than the Dreamcast? I'll hold this up for you guys. You're not going to be able to see a damn thing on here except when the screen lights up after it's booted. Little black and light. It's reading from memory. So that takes a few seconds and we're on to boot. Unfortunately, a couple days before the conference, I plugged this Nick card into a voiceover IP port and fried it, I think. It's been a little bit flaky here and there, but I'm pretty sure I got it working for you guys. We had to bash it earlier. Yeah. We had to smash it. The lights on. There's my little penguin. You guys can see that. I'm going to put this down now. We'll have all this stuff up here if you want to come check it out afterwards. Now, if you watch the Cype window up top right up here, I'll blow it up a little bit. The type's not going to be any bigger. It's waiting for the tunnel right now. As you can see, it's pinging the internal side of the network. It's pinging the 172 right now. The tunnel's up. It's ready to go. All happens automatically within, how long is that? Two minutes? Yeah. So just like the Dreamcast, full access from the attacker system onto the internal network with a UDP-based VPN that this initiated. Okay. So one other thing really quick, the nice part about this, if I turn this off, like it's not even on right now, and I turn it back on, the nice thing about Cype is that it's a stateless tunnel since it's running over UDP. I can turn it back on, and I can ping 172.16101.61, and there's my ping. So I can even turn the thing off and turn it back on, and it's still up. That's one of the really nice parts about it. Okay. So we want to bring this up a notch. We've tunneled over TCP. We've tunneled over UDP. So Chris is going to change the firewall reset here to say, there's no way of getting out of this network unless you get out on our proxy server. And that's what we're going to demo the x86 Trinix bootable disk. And I'm going to get ready to do that here. I'm going to do it on my system in VMware because we didn't want to cut down another laptop. I'm actually, I actually turned off routing altogether on this box. All this thing is right now is a proxy server. It takes in one side, puts out the other. You want to set? One second. Yeah, I'm ready to go. Okay. I'm going to power this on, and I'm going to put it in full screen mode. Hopefully the projector will not eject. It's going to be on this screen. So the idea is here, maybe there's a kiosk or a scanner station that's neglected, or maybe you can drop this CD off at night. This would make any box capable of phoning home. So it'll boot just like Trinix does. It will unload some standard packages and NMAP, NetCat, some other tools that we're using, SSH. Unpackage the package that we built that has all the network enumeration scripts. Once they do that, they'll try to get out on TCP ports, and it just failed. It wasn't able to get out on any TCP ports. So now it's going to try UDP ports. It failed there. It wasn't able to get out on any UDP ports. Now it's going to try ICMP. No, not our ICMP. So it's starting the proxy finder script. Well, it does work kind of fast over this local network here. Now, the way we had to set this up, since there was... When you run in PPP, you have to run it in a pseudo terminal. We have to run it in a pseudo terminal. So we actually had to set it up to run... We couldn't set it up to run through a script because it's not attached to a terminal. So we had to set it as attached directly to one of the TTYs. Remove the getty, remove the login prompt, just run it straight out of there. All right, the tunnel's up. Now this tunnel is going over the proxy server. So it's going through the proxy that's running SSH over the proxy server, and inside of the SSH it's running PPP to build a full tunnel back home. Does anybody want to see a pink flood over this connection? It gets a little hairy, but it works. This will work against any proxy server that uses connect. And so most any proxy that you're sitting behind that lets you go to an SSH website uses that feature. I want to show you guys, I've been pink flaring it for the past five, six seconds. We've lost about 20 packets out of 16,000. It's a very stable connection. Okay, another nice thing about running it on the pseudo terminal is if it dies, you know, HTTP sessions do time out. We want to make sure we can get back on our tunnel in the event that either SSH times out, the firewall times out, or HTTP times out. So because it's on the tunnel, it will restart itself every time it times out. So those are our demos. Hope you enjoyed them. We're going to wrap this up sometime soon. So we're going to go on to remedies, possible remedies, and then some questions. As a general conclusion, I mean, the best way to defend against this type of attack is to constrict the data pass in your network. Don't try to prevent it. Don't try to turn everything off. It's not a business function. You can't turn things off. But you can constrict your data path to single paths. Your web obviously going through a proxy, sure of attack that you can add other measures, such a strong authentication to that, to prevent against that. DNS, move it in house. Let the DNS server in house forward out. Your email, same thing. Have it in house. Don't outsource that type of service. You could try, and some of these recommendations that were given, nothing really exists for them yet, but would love to see them exist someday. So we kind of recommend them. Full mesh internet VPN technology, PGP net was trying to do it. You could make possibly do bulk encryption. That would only prevent against drop and go hardware though. We would not prevent against somebody exploiting a vulnerability in your system, shoving some code on there until in home. Swiss port security, again, only against drop and go hardware. A lot of places aren't doing this. A lot of places just letting anybody plug in. We'd love to see an IDS that knows our network better than we do. We'd love to know that the IDS is able to know what data is allowed to be there, what data isn't allowed to be there, down to the byte level. We don't want an IDS to search and for signatures. We want our IDS to search for or to know when there's a problem in our network. We also need proxies that can really analyze the protocols. Again, earlier we discussed 30 plus protocols that W3C has in development that how are you going to write a proxy that can filter all those? Well, time's got to be spent. We have to invest the money to actually get those things working. One of the things we didn't really talk about is that but the IPAC, we have a fallback mechanism. If you can't find a route out or a proxy out or anything like that, what if you've got an air gap in your network? We can throw a wireless card in here, have it act as an access point, you know, fall back to that capability. It's interesting about that. A lot of the slash doc crowd is saying, well, if you're going to go into a building, why not just put an access point there? I would think, you know, since a lot of the topics this year have been about finding access points, we thought, well, yeah, that's kind of an okay idea. So we're just tinkering around. We figured out a way to make this into an access point, but we put the actual card services on a timer. So the crowd doesn't actually start the radio until about 2 a.m. or on the weekends when the company's not looking for access points. So yeah, it is possible. We also have a great idea of throwing a GSM cellular modem card into one of these things. That way you could actually phone home or phone into this system without having to sit in the parking lot. So I mean, what's going to stop that? Wireless jamming maybe? Or how about firing people that put up their access points? If you don't want to have an access point in your network, just jam the thing. What the bottom note sits right now is covert channels. There's always a possibility that they can exist. If data has to leave the network, if people inside of your organization have to get out to get data, there is a possibility that someone may potentially build a covert channel over that. The way we have to tackle that is to restrict our data pass and be able to granularly look inside and notice, hey, this guy's got a proxy connection for three days. He's constantly sending traffic. There's probably a problem there. Another problem with this type of attack here is most average person off the street isn't going to try to sneak a dream cast in an organization. But the people that are doing this are people that are targeting the organization specifically. So they may have a lot more information on the company that would help them or aid them in getting in. One of the last things before we wrap up, one of the other reasons we pick the dream cast as opposed to other hardware is if somebody does get hacked with a dream cast, it's going to be the funniest damn thing I've ever heard of. You know it is hacked by the same dream cast. It is the new access removal. Okay, time for some questions. This guy had one. We definitely considered that. The thing we wanted to really show, the question was, instead of using DHCP, we tried to do traffic analysis locally on the network to figure out the address so you can assign one yourself. We did think about doing that, but it was trying to move away from the focus. The focus we wanted to do was building tunnels out. It would be very possible to do that. There's a fine gateway tool that comes with the older decener suites that would only look that easy to do. That's definitely a possibility. That's something that we could have coded in here, but for the most part, networks have DHCP as far as that we've seen. Question.