TUCoPS :: General Information :: hacknum.txt

Hacking by Numbers

Hacking by Numbers
By: Madirish

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 necesarily 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 thier excess MP3 files or
to use the computer as a zombie to dDos an IRC server. Despite thier
goals, most crackers will follow a specific pattern (although this is
just a generalization and I realize that with every generalization there
are gross divergances).

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
knowledgable 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, its
usually old and poorly documented. You would be surprised, however, to
find out just how many old vulnerable systsems are still lingering on
the internet. The trick is simply finding them.

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 arbitratry commands
and creates a back door for us (the likelyhood 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 thier 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 reprocussions of thier 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 xploit 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 likelyhood 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
testbed 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. 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.


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH