The Sun Observer, Volume 10 No.1
Peter V. Radatti
radatti@cyber.com
CyberSoft
January 05 1996
Notice: Copyright December 20, 1995 by Peter V. Radatti, All rights reserved.
I am sitting here in early November writing this article with thoughts of all the holiday presents you, my faithful readers will be sending me next month. Just to let you know, I cleaned out the spare room and I now have room for all the goodies that you will be sending.
Lets continue our exploration of the Unix system by looking at a few common problems and their solutions. Some of these problems really belong to the System Administration and some administrators will become angry and complain if they caught you checking on the system. My attitude is that if they get angry or object to your checking then they have something to hide. If they come by to see why you are running these tests without being belligerent then buy them a cup of coffee, they are doing their job well. The real lesson here is don't get caught running these tests.
The itsey bitsy sticky bitty test
The sticky bit show up with the permissions bit settings when you execute the command "ls -l". The function of the sticky bit is to make sure a program is execute using the userid and full privileges of the file owner instead of the person executing the program. This is sometimes useful because programs may need limited privileged access or a user may wish to make part of their filesystem available to other users but only though a filter program. The problem is that if the file with the sticky bit allows others to write to it then they can overwrite the contents of the file with one of the Unix shells such as "/bin/sh" or "/bin/csh" and they will then have full control of your account. In addition, if anyone every has access to your account for a few minutes, like when you went to refill your coffee cup they can just execute the command "cp /bin/sh someplace-hidden;chmod 4777 someplace-hidden" and take full control of your files anytime they want as long as they still have access to the file created by that command. The only defense against attacks and laziness of this type is to scour the system for all files with sticky bit files. If you find any owned by you that are not in your home directory then someone is attacking you. If you find any owned by the "root" user make sure you tell your System Administrator as soon as possible or at least remove the file, if possible.
The test is as follows, "find / -perm 4000 |mail myuserid &". This test uses the find command to look for all files with the sticky bit set. Every file on the system and every file remotely mounted onto your system will be examined. The resulting report will be mailed to your account. Notice that the command is running in background. That is because on a large system this test can take hours. Be aware that this test is one of the first things that a beginner hacker will try on your system so if you find anything unusual it needs to be taken care of immediately.
The Trojans Do Not Come From Drug Stores Test
I have no idea why, but people seem to think that Trojan Horse programs come from Drug Stores. They don't. A Trojan Horse program is any program that has a hidden payload and does not infect other files. If it infects other files then it is a virus or worm but not a Trojan. (Yes, there are viruses on Unix systems.) Anyone can make a Trojan Horse program by adding a payload program to some other popular program. The Trojanized program may look like a calculator program but it's doing some besides calculating.
Another way of creating a Trojan program is to rename a payload program so that it has the same name as some command you are likely to execute then place the program so it is before the real program in your path statement. If I had write execute to a directory in your path statement that was prior to the "/bin" directory then many of the basic system commands such as "ls" can be attacked in this way. In addition, once the hidden payload was execute the Trojan can call the real command in order to not raise your suspicion.
One of the most popular payloads for Trojans is a recursive bin remove of all files on the system. You may be surprised to know that many people leave all or a substantial part of their files unprotected. An attack of this type typically will remove thousands of files from a large system. Trojans are a real problem for Unix systems. They are very common but rarely recognized by end users and System Administrators. Many Administrators think the effect of Trojan attacks are hacker attacks or hardware/software failures. They often are not.
You have three ways to protect yourself from this type of attack.. The first is to search your command path for files with duplicate filenames. If any of the duplicates are commands that you execute then you should see your System Administrator to find out if this is significant. A few commands such as "mail" exist in multiple versions in different places. The command is "find `echo $path` |mail myuserid". Look at the resulting mail message and see if the filenames are the same. Ignore the full filename and only concentrate on the final part. For example, you will be looking at the "myfile" portion of the following example extended filename, "/home/joe/myfile".
The second thing you can do is make sure that your home directory is locked down tight and examine your "path" statement to make sure there is nothing contained therein that should not be. Never allow the "." or ".." paths to be near the front of your statement. That is half the job completed for a Trojan attack. A little trick that I do is to add the command "chmod -Rf 700 *" to my ".logout" script. Every time that I logout of the system all of my file permissions are reset to "700" which only allows me access. If I have a file that I want to share I add an additional "chmod" after the blanket reset that resets the values for the specific file.
Finally, you can buy a virus scanner that also searches for Unix Trojans such as is manufactured by my company, CyberSoft. The CyberSoft product is called VFind and searches for known contents of Trojans and also searches the system for duplicate files.
Passwords Are Not Passed Words
Why do people share passwords? I don't and I can't think of any reason to do so. Even if you never shared your password with anyone you may be inadvertently doing so. Lots of users never set or reset their password from the default. If you have never reset your password from the default when it was first given to you then every person on your system knows your password since it is very likely probable that they had the same default password when their account was first activated. Take the time and reset it now. Use the "passwd" command.
Many novice users put their user id and password on paper and keep it somewhere in their office, usually within easy reach of the terminal. Anyplace that you can think of hiding your password, I can find. So can anyone else who thinks about it. If you must write your password down then keep in your wallet or purse. Your wouldn't leave money lying around yet your password is similar.
Finally, an easy to guess password is not a password. Your name, your spouse's name, children, dog, etc are not candidates for passwords. Names of things in your office, hobbies, cars and real words are also not good passwords. I suggest that you glue two unrelated words together with a number and use that as a password. For example "fish9apple" is a good password. It is easy to remember, does not need to be written down and almost no one will ever be able to guess it with the exception of everyone who read this article. Do not use "fish9apple" for a password.
With all of that said, I wish you and your family a good holiday and a happy new year. See you in the papers, next month.
Pete Radatti is the founder and CEO of CyberSoft, Inc. CyberSoft manufactures, VFind the an antivirus software product that executes under Unix and simultaneously scans for Unix, MS-DOS, Macintosh and Amiga destructive software. You can reach Pete at radatti@cyber.com. Thanks for all the nice letters!
