If you have a stand-alone Linux system, or one that is connected on an internal network
with no connection to the outside world, then security
is much less an issue. (It does not
go away) However, if you connect to the Internet, such as for a HTTP
or FTP server, then security
is a primary consideration.
One way of avoiding compromising your system is to have your WWW
server connected to the Internet, but not to your internal network.
Should someone be able to break
into the WWW
server, the worst that can happen is that your WWW server is down for a day or so as
you reload from backups. If the intruder had access to the internal network,
your livelihood could
By it's very nature, UNIX
is not very security
oriented. When it was
first designed and implemented, UNIX
was by programmers for programmers. The environment
was of cooperation, not privacy. As UNIX
moved into universities and businesses, that changed. Security was
an issue. Because security
was not built into the ordinal concept, it had to be included "after
the fact." Therefore, security
solutions were not as far reaching as for later
The severity of this problem can
be demonstrated by what I found at one company I was working for. In preparation for connecting the
company to the Internet, I conducted a security
check of the internal network.
I wanted to see just
how far I could get. One of the first steps that a burglar does before he breaks in is to case the
joint. He may observe it for several days or weeks before making his move. To make his presence less
conspicuous, he may watch several scattered locations and then choose the easiest target. (Or may
choose all of them in turn.) A computer break in is basically the same. The only difference is the
tools the burglar uses and the information that is collection. However, in both cases the more
careless you are as the potential victim, the easier time the burglar has in gathering the
information and breaking in.
Since we are not trying to keep someone from breaking into our
house, let's talk about the tools that a hacker would use to break into your computer system. One of
the most innocuous and most dangerous is finger. In the many papers and books that have been
written recently about computer security
and break-ins, finger is always mentioned. I have used it
myself on our internal network
and have collected a great amount of information. What information is
provided is dependant on the operating system
and the version of finger. However, at the very least
it can provide information about who is logged in, where they logged in from and so on.
One common tactic used is going on the belief that an account
that is not used that often will have a easy to guess password. Based on my personal
experience, this seems to be true. Usually people that
don't use their computer accounts are not as aware of the security
issues and are more than likely
to choose a password that is easy to remember and therefore easy to guess. What are good passwords
and what are not is something we'll get into in a minute.
Finger often delivers information
stored in the .plan file in a user's home directory.
This may contain personal information that a
hacker can use to try and guess the password. If the password is not easy to guess, the information
obtained from finger can be combined with other information that may be useful. However, one thing
that finger quite often delivers is a user's home directory.
If that home directory is exported
an attacker may be able to mount
that directory, copy an .rhosts file into the
directory and can access to the system without even supplying a password.
At the same company,
there was a very arrogant system administrator
who would simply not accept the fact that
"his" system was insecure. However, one of the home directories that was exported via NFS
was his. Since I had root access on my machine, I could import his
home directory. His .rhosts file
was writable so I could give myself permission to use rlogin to his account
from any machine as any user on the network. Once in, I planted a Trojan horse version of su, since I knew he would eventually use it to get access to the root account. Even if I wasn't root, having a writable
.rhosts file allowed me to gain access.
One very common attack is the dictionary attack. Here
the hacker uses common words, encrypts them using the same as the password taken from the password
file and then the two are compared. Remember that the /etc/passwd file is readable by everyone and
the seed is contained within the encrypted password
is always the first two characters. Once I have access to the system, I can
bring a copy of this to another system and using that seed I can encrypt
the words from my "dictionary." In addition to just words in a dictionary, using place names and other proper nouns related to the target.
With just my first attempt at cracking passwords I was able to crack
almost 200 on one system alone. In fact, this was the first time I tried to hack a
system at all. Among the passwords I was able to gather was the one used by the head of
purchasing, the head of sales and the company president! This list only contained about
30 words including the name of the town and state
we were in, the days of the week, the months and a few words related to the company. Plus the
program only had to run about half an hour. What kind of luck would a serious hacker have with
30,000 words running the program for a week?
Although this seems to be a major security
it is very effective if you use passwords that are not easy to guess. The reason is that the
encryption goes only one way. You take a word, use the seed to encrypt
it and then compare it to
the encrypted password.
However, there is no way to take the encrypted password and use the seed to
figure out the un-encrypted password.
Keep in mind that snatching the /etc/passwd file does
not necessary mean you have to break into the system to begin with. I was able to get it on one
system using the "guest" account
that had a very easy password. With just a single password I
could then log into the system. Once in, the potential for more serious and directed attack is much greater. I could continue to use these accounts or edit the .rhost files in various home directories to continue to gain access even after the passwords get changed. Remember, here I got almost 200 hundred on my first attempt!
It was once common to find UNIX
machines that had an account
guest. This stems from the time when people were not so worried about security
resources were freely shared. Often the password for such accounts is very easy to guess. Thinking
about it for a minute, I though about the first word one might say to a guest: welcome. Sure enough,
that's what the password was. So, on my very first try as a computer hacker I was able to
When exporting filesystems or directories there are several things to
watch. First, I recommend against ever exporting a filesystem
to the whole world, especially
one that is writable. There is generally no need to make this information available outside of your company and if so, there are probably just a few trusted hosts. Try to see if the same result can be
reached by making the information available via ftp
or the Web.
If there is a + in the
/etc/hosts.equiv file, this is a wildcard
that says any non-root user can login
without a password.
If an attacker gets into a machine as root that has an entry in the hosts.equiv, they could do an su
to the user bin or sys,. Then they could use rlogin to gain access to the other system and then have
access to many key files and directories. Permissions could then be changed to set the user id on
executables to root and once the program is started, the user is root.
One way I got the
/etc/passwd file was through ftp.
Anonymous ftp was disabled on this system, but I simply used the
which had a password that was easy to guess. The most obvious solution is to disable
ftp. However, if it is a necessary service, you can limit the potential for damage. You need a
passwd file when using ftp,
but it doesn't have to be the same one that you use when logging in
normally. In fact, there are many things you can do to configure ftp
to allow people access to your
system without open it up for them. We'll get into configuring anonymous ftp
I could copy the password file to my home machine and begin to crack it. Not just try to crack it. I
knew going in that the odds were in my favor. Once I had the passwd file, I was statistically
guaranteed that I would crack at least one password. People are people and will tend to choose
passwords that are easy to guess.
Within about 20 minutes I was able to create a password
cracking program on my own. Since I had never done this before, it took that long. Since, the
program was only a couple of dozens lines (without the enhancements I later made) it was easy to do.
I discovered subsequently that there are already password cracking programs available on the
Internet that are much more powerful.
I then created a "dictionary" of words to try.
I encrypted each using the seed/salt that was in the password file and then compared this encrypted
word with what was in the password file. If they matched, I had found a password.
dictionary that I had created contained only about 50 words, including the name of the company, the
city and state where it was located, the generic term for the product that the company produced and
a few other words related to the company and the area where we were at.
Since there were only
50 words to compare, the program ran relatively quickly. Within half an hour, I had found almost 200
passwords out of about 850 users! Most of these still had the original, start-up password
I then went back to the original system and did a search of the word
"phone" in any file or directory name.
Soon, I had a copy of the company's telephone
book that I used to crack more password. In the end, I had 235 passwords.
An analysis of the
passwords showed some interesting things. One person chose as a password the geographic area he was responsible for. His girlfriend, the personal secretary of the company president, chose his name as her password. Other people chose their first name, their spouse's first name and other
easy-to-guess password. One even chose 123456.
One thing bothered me about the system in general. Of all the passwords on the system, over 400 (almost half) had the same seed. I could have sped things up by encrypting all the words in the dictionary with this one seed and I would have still cracked over 100 passwords within about five minutes!
Since I used the same password on many different machines, I went on the assumption that other people did the same. As you
might expect, several people used the same password elsewhere. The reason I only cracked about 10
passwords on other machines was that very few people actually had accounts on other
I then tried some of these passwords in our bookkeeping and management software.
Here too I was able to crack "only" about 20 passwords including the head of the
purchasing department and the head of sales.
For a real hacker, the speeds of machines have
become an advantage. Whereas checking a single password on a Microvax several years ago would have
taken hours, the same password can now be cracked within a matter of minutes. It has been estimated
that in order to encrypt
a dictionary with 250,000 words using all 4096 seeds and several machines
networked together, you would need just a few hours.
On several machines I was able to list
what filesystems were being exported. Also using finger information, I could tell what filesystems
were used for home directories. I mounted one of these filesystems and discovered that since I had root access on my machine, I had root access on the mounted filesystem. I could now write my own
.rhost files to give me complete access to any of these users accounts.
The first thing was to
checked to see which machines were "personal workstations." Often there is an entry in the
/etc/hosts or HINFO DNS-record to describe who this machine belongs to. If there are a lot of PCs
and only a few "workstations", these probably belong to the system administration group.
However, if everyone has a workstation, this trick doesn't work.
Since I could now look
in the /etc/passwd file, I found out who were the system administrators as this was written in clear
text in the GEOS field. I then found out what filesystem
their home directory
was on and mounted
that via NFS.
I could then edit their .rhosts file to give me access to their account.
the same information this told me who the system administrators were and what areas they were
responsible for. I could then concentrate by attacks on their accounts. As the system administrator
you should know who the other admins are. There is no need for the users to know this. In my
opinion, there should be nothing in the password to identify the user. If you need this information
regularly, put it in a file somewhere that is not world readable.
Having access to their
account doesn't necessarily mean I have root access. However, it does mean that I have access
to an account
that sooner or later will want to get root access. More than likely this will be with
the su command. With write permission to that user's directory, I could trick them into giving
me the root password. I could create a "Trojan Horse" version of su that comes first in
the user's path (maybe changing the path if necessary). The next time he uses su I have the