Hack by Numbers

30 November -0001
By: Mad Irish
Last updated: Feb 7, 2007

Hacking, How's it Done?

I get a lot of questions via email from people that want to know if I can hack into a website for them, or break into someone's Hotmail account. At first I didn't really understand why people would be asking me these sorts of questions (other than the obvious that they couldn't do it but wanted someone else to break the law on their behalf), but as I pondered the cause for these emails I began to realize that most people's understanding of hackers is generated purely by the mass media. I suppose this fact is true for many occupations and hobbies, but with hacking it is particularly disturbing. I know a lot of systems administrators who don't have a deeper understanding of network security than the evening news' depiction of it. I also get a lot of requests asking me to teach people how to hack, like its some dark magical art that you have to be mentored in. The truth is, I don't think many people outside of the security community understand very well how most system crackers work.

For those of you trying to learn how to break into systems let me pose a question: why? The only reason I ask is because if you really want to learn your answer to that simple question will often determine your success. It will also help define the course you wish to pursue. I'll dispense with the B.S. about being a smart person, or knowing programming, or all the other requirements that were thrown in my face when I began to learn about hacking and system cracking. None of it is true. I am a firm believer that even the densest moron can break into systems. All it takes is dedication, not necessarily intelligence. Now, don't get me wrong, being smart is a huge advantage, its just not a requirement.

Methods

How do you hack? Well, to understand hacking we first have to understand the motives of system crackers. This isn't an easy task by any stretch of the imagination. People crack systems for all sorts of reasons. Some people (I am convinced they are the minority) break into systems to learn, some do it for the glory, some do it for truly pathetic and selfish reasons like to find a place to store their excess MP3 files or to use the computer as a zombie to dDos an IRC server. Despite their goals, most crackers will follow a specific pattern (although this is just a generalization and I realize that with every generalization there are gross divergences).

Step 0. Know What You're Doing

This is perhaps the most obvious but most overlooked step. If you want to learn to break into other computers it's a good idea to understand how they work, or at least what you're doing. I'm a big advocate of people learning how computer break-ins occur so they can help to prevent them. The best way to 'know what you're doing' is to set up a test environment and practice. With virtualization technology, it's now possible to set up a virtual server on your own machine with VMWare, assign it an internal IP address and attempt to break into it, all with just the machine you're working on. If you can afford to, get a spare computer and install Linux, FreeBSD or even Solaris and try to break into it. These 'server' operating systems are some of the most common on the internet. If you understand how they work you'll be much better equipped to assess their security.

Step 1. Find a Vulnerability

While this seems fairly obvious you'd be surprised by the number of people that don't even make it this far. Finding a vulnerability is the way in. There are vulnerabilities for tons of different operating systems out there. The target you choose may make your search for a vulnerability much more difficult. Most crackers look for a working vulnerability first, then look for a target (this way at least they know if they find a computer with the target OS/service, they'll get in). Check out Security Focus for a pretty comprehensive list of system vulnerabilities.

Finding a vulnerability can be as easy as finding the open services and brute forcing them, or as hard as tracking down a buffer overflow exploit. Most people are convinced they need the remote r00t exploit though, so I'll explore how those are developed. If you follow Bugtraq (for those of you that don't know, you can follow Bugtraq via NNTP if you want, or sign up for one of the many Bugtraq mailing lists, just Google for it) you'll notice that system vulnerabilities crop up every day. Most of the postings to Bugtraq are responsible, however, and rarely include exploit code (or if they do you have to be fairly knowledgeable to get it to work). Simply take a look at the number of postings to Bugtraq in a day, its staggering, and almost every posting describes a possible way to crack a system. All you need to do is figure out how. Why people post to Bugtraq is a bit of a mystery. Its probably the same motivation that drives people to write Linux device drivers, although it could land you on national TV (w00w00, et. al.) so theres a little more ego draw.

Each Bugtraq posting is the source of a possible exploit code, although some of the exploits might not need any code. Finding exploit code is difficult, however, since its hard to write and most people don't want it floating around the internet for others to misuse. Most exploit code writers hold onto their code out of moral stamina, greed, or other motivation. You can find a lot of exploit code on various websites like Packet Storm. I've heard that IRC is a great place to find exploit code, but I don't have the patience to chat with the legions of script kiddies lurking there to find some. The easiest way to get exploit code is to write it yourself :)

Now, most exploit code that most people are going to be able to find looks pretty worthless, it's usually old and poorly documented. You would be surprised, however, to find out just how many old vulnerable systems are still lingering on the internet. The trick is simply finding them. Don't necessarily think that just because an exploit or attack technique (called an 'attack vector' in computer science jargon) is old it is no longer applicable. Given the amazing explosion of the internet and the number of systems that come online each day, even older attack techniques are viable.

Step 2. Find a target

Ok, so lets say we've managed to find a really old copy of code that exploits, say for example, fooCode's telnet server. The exploit overflows the telnet server, crashes it, fires some arbitrary commands and creates a back door for us (the likelihood of finding code that cool and being able to use it are slim to none). Now all we have to do is find a computer running fooCode telnet. This is going to be a bit of a problem. Step one is to get a scanner. I've noticed a lot of hype about some GUI scanners recently and their ability to show you CGI vulnerabilities in pretty color with point-and-click hacking, but for our purposes we need something fast and accurate (we're going to have to scan a LOT of IP's to find fooCode telnet). So we might decide on NMAP or Nessus. NMAP is available with a very complete manual with descriptions of all its different operations and the reasons it works. Thankfully NMAP is a little more difficult to use than most programs so it keeps the truly inept at bay. What we would want to do is either fire up NMAP and begin scanning a large number of systems and logging their characteristics for later use, or better, begin scans for open port 23's. Using a simple shell command we can easily compile a text file of IP addresses with telnet servers running. Simply getting to this stage can take a long time, which is why the most popular exploits target widespread operating systems or services. The next step is to find one running fooCode telnet. We could run our exploit code against every target system we have found with an open port 23, but this would take a long time, so what is better is to write a little simple code (or find some) to log banners and run it against our list of servers to scan them for the service they're running. If we can find something distinctive about fooCode telnet it will be easier to locate a server. Once you've located a server you need to run the exploit code. Just doing this is often very difficult. A lot of exploit code is provided as raw C or Perl. While Perl isn't too difficult to get running since it isn't compiled, a lot of exploit code can take days just to get working. Exploit code usually isn't documented very well, or even if it is assumes a certain level of skill with programing or at least systems operation. Most likely what will happen, however, especially with older code, is that most of the servers we find will be immune to the vulnerability (they'll be patched in one way or another). The trick is to keep looking, eventually an unpatched server will present itself.

Step 3. Breaking in

Once a vulnerability and target have been found the next step is to break in. At this point very few system crackers stop to consider the legality or repercussions of their actions, but this step is the precipice. Up until this point most of what has been covered has been legal or at least falls in the gray hazy area of legality. System break ins are where crackers cross the line. Once you've broken into a system you can get in big trouble, even if you don't do anything malicious. Unauthorized computer use is a crime, meaning that even if you log in using a default username and password, or one easily guessed, you've already broken the law. In our above example we've found some exploit code for fooCode telnet server. Exploit code is usually spread as C code or Perl code, and isn't usually compiled. This means, in the case of C, we have to get a working C compiler and put together the code. In the case of Perl, it isn't a compiled language so all you need is a working Perl interpreter. If you need help compiling code, you can usually go to IRC or email to find answers. Once the code is compiled we'll probably have to fire the program at a shell with some optional flags to specify targets, etc. Check out documentation for the exploit or examine the code to find out what to do. Lets say that the fooCode exploit comes as fooCode.c, we compile it into fooCode.exe and fire it at the command line with

fooCode -192.168.0.1 -8080

For purposes of our example we'll say that the first argument ('-192.168.0.1') is the IP address of the target and the second argument ('-8080') is the remote backdoor port we want to spawn. Assuming our exploit works we should be able to telnet to 192.168.0.1:8080 and get a root shell (in our dreams). What happens at this point? We've got access, what to do with it?

Step 4. Covering your tracks

Ok, now that you're on the machine you're going to want to make sure you don't get caught. There are several variants of 'rootkits' out there that you can use to clean up your tracks, but the basic idea is to get tools onto the target machine so that you can clean up log files and bash histories of your activities. YOu can of course do this by hand, but its tedious work. The problem with putting new programs on a machine is that it increases the likelihood of notice. Also, if you run the wrong rootkit (say one developed for a Linux Redhat server on a Solaris server) you might end up damaging the server. Needless to say at this point you need to do some checking to make sure what type of server you're on. You could also grab a list of usernames and begin reading e-mail. Perhaps the most damaging thing to do is to compile and install a sniffer to log passwords traversing the machine's Ethernet card. All of this really depends on why you broke into the server. You could simply 'cd' into the web root and replace the index page, thereby defacing the website. The point is that once you've gotten this far you're pretty much free to do anything. The thing to remember though is that every keystroke sent to the target is getting used by the target (and possibly logged somewhere), so your IP is flying all over the internet in packets destined for the target.

Step 5. Practicing

The best way to get experience doing this sort of thing is to set up your own LAN. Depending on the available budget you will have to customize this setup. The easiest thing to do is purchase a refurbished computer or two for pretty cheap and download any of the various Linux or Solaris operating systems, burn copies and install them on your test bed computers. Refurbished computers can run anywhere from about $150-$400 for an acceptable machine. You'll want to get at least one hub so you can link the two or more computers, and some Ethernet cable (which is pretty cheap). Simply use reserved IP address space (10.0.0.1-255, 192.168.0.1-255, etc.). The disadvantage to doing this is that you'll have to shell out some money. The big advantage is that you can get some hands on experience with system cracking without breaking the law. If you've got any old computers laying around you can use those as well. The thing you're going to want to do though is get at least one computer with a server operating system. There is only so much you can do with client computers (Windows 95/98/Me/XP Home) but you can try and hack into those as well.

As I mentioned before you can also use virtualization to run another operating system on top of the one you already have. VMWare Player is now available for free and will allow you to basically run two machines in one piece of hardware. The nice thing about virtualization is that you can save a complete "image" of your virtual machine. This way if you totally trash your virtual machine you can simply wipe it out and quickly replace it with the saved image, restoring it to working order in seconds.

If you can't do this and you're determined to practice on live computers online be sure to realize that if you don't know what you are doing and fire the wrong exploit or compile and run the wrong code, you run a high risk of breaking the target computer. Fixing this sort of damage is time consuming and may be costly in terms of lost data, so be careful. Breaking someone else's server is bound to get their attention and may get you in a lot of trouble.