Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents
Up to --> Linux Tutorial

· Security
· Real Threats
· Restricting Access
· Passwords
· File Access
· The Root Account
· The Network
· What You Can Do About It

Glossary
MoreInfo
Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
FAQ
Copyright Info
Terms of Use
Privacy Info
Disclaimer
WorkBoard
Thanks
Donations
Advertising
Masthead / Impressum
Your Account

Communication
Feedback
Forums
Private Messages
Recommend Us
Surveys

Features
HOWTOs
News
News Archive
Submit News
Topics
User Articles
Web Links

Google
Google


The Web
linux-tutorial.info

Who's Online
There are currently, 255 guest(s) and 1 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here

  
Linux Tutorial - Security - The Network
  The Root Account ---- What You Can Do About It  


The Network

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 be threatened.

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 systems.

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 through NFS, 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 hole, 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 and computer 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 "break in."

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 "guest" account 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 shortly.

Once in 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.

The 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 welcome.

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 machines.

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.

Using 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 root password.

 Previous Page
The Root Account
  Back to Top
Table of Contents
Next Page 
What You Can Do About It


MoreInfo

Test Your Knowledge

User Comments:


You can only add comments if you are logged in.

Copyright 2002-2009 by James Mohr. Licensed under modified GNU Free Documentation License (Portions of this material originally published by Prentice Hall, Pearson Education, Inc). See here for details. All rights reserved.
  




Login
Nickname

Password

Security Code
Security Code
Type Security Code


Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!


Amazon Wish List

Did You Know?
The Linux Tutorial welcomes your suggestions and ideas.


Friends



Tell a Friend About Us

Bookmark and Share



Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.21 Seconds