HIR Issue 3: Fun With UNIX I
Fun With UNIX I, The First of a series dealing with neat UNIX tricks by Axon
This is the first article in a series of god knows how many that will be dealing with some fun, but usually harmless (and always just pure evil) tricks that can be performed under various flavors of the UNIX operating system. These tricks may not work on all flavors, and may not even work the same with 2 different machines running the same operating system. It has a lot to do with how the administrator has configured things. Enough with the small talk, I think it's time to go out and have fun with UNIX!
This Article, of course assumes that you have a shell account on a unix box, somewhere in the world. It's also nice if many other people have accounts on that box, too, otherwise some of these unix fun tricks wont seem very fun, because you'll have no one to screw with or spy on.
Compatibility note: I really do not know what flavors these work on. I tested and discovered these fun tricks on an IBM (Incontinent Bowel Movement?) RS/6000 Running AiX 4. The last trick will work on any system on which users either by default have terminal writeability enabled, or can turn it on. (some systems have it set up so users can't turn their writeability on (or can't do it very easily.)) In theory, the second trick should work on almost ANY unix machine, unless the admin has the audacity to disallow execution of things such as chmod or vi.
Trick #1: Read other people's sent-mail.
This can be a fun trick. It relies on the fact that the system admin guy has NO clue what he's doing. Actually, this little nasty has been overlooked on many a system, even a few that i have access to, and I know there are more of them out there.
Pine, a wonderful text mode e-mail program that is still widely used, likes to keep things in "folders". When a user writes an e-mail, a copy is sent to the recipient of the e-mail, and a copy is stored in the "sent-mail" folder under pine. Typically, this "folder" is in the /mail subdirectory under the user's home directory. There are numerous ways of finding out usernames that are on that system. One way is just to run finger. Jot down all the usernames you see, and keep that as a reference. If you do this enough times, you might end up with a few hundred account names. This is all you really need.
Another way to get account names is by trying to list all subdirectories sprouting from your parent directory. Do the following from your home directory:
cd
cd ..
ls That might list all usernames. If the system admin knows what he's doing, it may not work. Stick with things like the who and finger commmands to find usernames.
To read their outgoign e-mail, get to your home directory by typing cd alone on a line. Type pwd ,which will tell you what directory you are in. My account on my main distro site is called "axon2017". when i type pwd from my home directory i get:
/homea/axon2017 Let's say that you want to read the sent e-mail from a person with the username "bjones". His sent-mail folder will be in the path of:
/homea/bjones/mail ( Just a note: Chances are your system won't have a "homea" directory, it may be something like "home", or "usr", something like that possibly.)
The interesting thing about pine's e-mail "folders", is that the folder is just all the messages put directly into one file all in a row. So, you can easily use vi, pico (blah), or cat to read the email. Here is how i would read bjones' sent-mail:
cd 'gets me back to my home directory
vi /homea/bjones/mail/sent-mail 'opens his sent-mail folder in vi if you wanted to use cat, you could substitute the vi line with:
cat /homea/bjones/mail/sent-mail | more the | more on the end informs cat that you want the screen to pause when it scrolls one screen. To move to the next screen, just hit the space bar, or hit q if you want to quit viewing it.
This bug is made possible because while the permissions on the mail sub-directory are usually set to where normal users can't access it, the perms on the actual files are not set to restrict viewing. In most cases, the file can't be altered, but you can download it via FTP, or save it to your home directory. of course this may be slightly suspicious. If your system admin likes to view history files, that might be a problem as well. This makes a perfect introduction to my next fun trick.
Trick #2: Changing the past!
Changing the past? What in the world does that mean? Well everything you type under the shell in unix is logged (i DO so hope you know this much, but if you didn't, it's time you not only learn, but time you learn how to change what that log shows. This really is a job for the VI editor. Pico does not work on the history file usually. The file is called .sh_history, in each user's home directory. Since it starts with a dot, it will be hidden from the LS command unless you use the -a flag. I would venture a guess that this file began as some sort of security measure, to monitor what people were doing on the system, and keeping it somewhat hidden from prying eyes. The only problem with this is the fact that any efforts to edit it will end up being appended to the end of the log file once your editor closes the file. Talk about "begging for attention"...that's a way to get it from your admin.
I've always thought shell scripts were useful. A Shell script is exactly the same as a DOS Batch File. Each command you want to execute in the script is put on its own line. When the script is executed, it will run each line sequentially. We'll make a simple shell script in order to edit our history file. The thing is, we need to name this script the same as a normal unix command. I chose cls, which is not really a normal unix command, but some UNIX's have a shell script that does the same thing. CLEAR is the command typically used to clear a screen. Cls might seem like a typical error, when an admin sees it in the logs. This is the source code you need to store in the file. Use vi, Pico, or echo >> to do this. I just used echo >> here's my example.
source code:
#!/bin/ksh
#This Script Clears The Screen
vi .sh_history This is all I did to make the file using echo >>:
echo "#!/bin/ksh" >> cls
echo "#This Script Clears The Screen" >> cls
echo "vi .sh_history" >> cls the >> redirects the results of echo out to a file, in this case CLS, adding the text to the end of the file.
If you are not very well-versed in UNiX yet, you may not realize that the script you just made has to bbe made an executable. In DOS, if a file has a .COM, .EXE, or .BAT extension, it refers to it as executable. In UNIX, there really are no file extensions. A period can be used in a filename, or several periods. You have to use the change mode command, called CHMOD to make this file executable.
chmod 700 cls No, 700 is not some magic code for "make it executable". The first digit is what access you have to the file, the second and third, you don't need to worry about, because those are what access other people have to your file. We set these to 0, which means you are denying them any access. 7 makes the file readable, writeable, and executable.
Now, when you type cls, your history file will appear on screen with the vi editor. I will NOT go over the whole vi editor command set with you, but I will tell you enough to take lines out of your .sh_history file.
When in vi, use the arrow keys to get to the line(s) you wish to take out. to delete a whole line, hit <d> <d> yes, that's right...hit the "D" key twice. make sure caps and shift are turned OFF! Poof! the line is gone. you can move to another line and use <d> <d> again and again. To save the file hit <:> <w> <!> <enter>. Once the file is saved, hit <:> <q> and you are back to the prompt. Easy, huh?
Trick #3: Let's mess with someone's terminal!
This is a little more involved, and does not work at all unless someone else is on the same system as you are, and has their terminal writeability enabled. To see who is writeable, type "who -w" You will see a few fields, the only ones we care about will be the login-name field, the terminal field, and the field containing only + or - symbols. If there are any + symbols, you are in luck, for now you have someone to mess with.
If you want to just test this, then go to a computer lab or library where you can use telnet on 2 computers side by side, and log in to the same host 2 times, once on either machine. type mesg y at both of the unix prompts, then find out which virtual terminals you are on (using the terminal field of the who -w command) You will be interested mostly in the other one, the one that you are next to, not the one that you are sitting and typing at. once you find that virtual terminal, you are ready to go. You will from now on refer to that virtual terminal as /dev/pts/2 or whatever it is, even though the terminal field only says pts/2, you need to refer to it with the /dev/ in front of it.
Try clearing the other screen. This is fairly simple.
clear > termpath termpath will be the /dev/pts/2 or whatnot. See, the output of any program can be sent to any other virtual terminal that is writeable. the greater-than sign is used to REDIRECT the output. You can run anything, and make the other screen look exactly like yours would. Things to try: redirecting a pine session, redirecting output from various unix commands such as finger, who, and even telnet. Another possibility if you want to annoy, use cat to read a binary file, then redirect the output to the terminal (cat /bin/ksh > /dev/pts/2). Oh the evil deeds you can persue...
Using this little ability to annoy someone to the point where they will close their telnet connection to the host can open up other security holes, for instance with proper timing and a lot of hard work, you can capture a log-in session and snag passwords, however this is detailed in far too many cookbook hacks that are available elsewhere, and begin to stray from the informative nature of this publication, as its usage really can not be used for purposes aside from obtaining passwords and logins (cool stuff but far outside the scope that i wish to cover here)
Look for more Unix fun in future releases of HiR.
