Returning To The Scene

The prudent hacker will build himself or herself a trap door to allow easy entry if further penetrations are required. Mainly this means setting up a dummy account to use in successive hacks. After all, there is no guarantee that the account you used the first time will still be valid the next time you login, or that the password or some other critical item won't have been changed, barring your entrance. If you have gained access not through a password, but through some fluke hidden command or technical means, you will definitely want to add a trap door just so you don't have to go through all that rigmarole the next time you want to get in.

On many operating systems, programs can be set to run even after the user has logged off. Sometimes the program can be put on a timer, to begin execution at a specified future time. Writing a suitable program and then running it under one of these commands can make your return easier to accomplish.

Mission Accomplished... Almost!

Hey! Look at what you've done!

You've done your research, found your computer, broken in, and now, you've dabbled around inside. These four components are what hacking is all about. This is what it means to be a hacker.

But there is also a fifth level of hacking to consider.

These first four parts had to be done in linear order, one following the other. The final part is really not final at all. It is something you should be doing from the very beginning, thinking about every step of the way.

Because you see, this thing you've done, this hacking, is illegal. And so you must protect yourself.

So now let's look at what exactly it is about hacking that our society considers wrong. Then we will see how we can keep on hacking forever unscathed. Finally, we will tie up loose ends and look ahead to your future as a hacker.

Get Out Of jail Free

Okay, all of that is fine if you've broken in by discovering someone's username and password but what if the only access you've found to a machine is that of a command account or information setup? Then you have to see what can be done to break out of this jail of a program and get down to the level of the operating
system. Probably this will be difficult to do. It will be less so if you've done any serious programming in the past.

As a programmer, you know what kind of bugs and errors crop up, and what kinds of things to look for to make them appear. If you're stuck in an account that runs an info program, let's say, you will want to try every unconventional, unexpected thing you can think of, in the hopes that you'll find something the programmer
didn't think to guard against. Then hopefully you'll get an error in . essage and crash out to the OS prompt.

Things to try:
Give bad, inappropriate, unrequested, or extremely long input to prompts, especially alphabetic answers to numeric questions. Or when asked to supply a number, that will be analyzed by a function, try an incredibly small or large one. Try responding with break signals, either Control-Z, Control-C, or possibly Control-
P. Try executing "Find" commands that will search out of bounds of available resources, or that will look beyond the alphabet. See if it's possible to set up programs for nonexistent hardware or memory capabilities.

If there is any sort of text editing facility, such as a program to send mail to sysops, do what you can to compose a batch file, and see if it's possible to send your message as a command that must be executed. Also with text editors, try to compose excessively long letters. If the editor has special text revision functions,
write up a huge paragraph then cut and paste a copy underneath it. Then cut and paste those two paragraphs underneath, etc., until the program either crashes or doesn't allow you to continue. If the latter, see what happens when you try saving or sending the whole mess.

You may be in a program that is made to look like a simple operating system or control program, essentially a menu with the list of options either unavailable, or callable with a HELP command. Thus, you're given a prompt and asked to enter a command. Some application commands allow appending to them the name of a file on which you intend to work. For instance, to edit STORY.DOC with a word processor, you might type the cornmand "WORD PROC STORY.DOC,` to run the word processor with STORY.DOC already loaded in it. On an on-line system, try to crash a program that allows such execution by giving it too much data, ("WORDPROC STORY.DOC FILEONE FILETWO...") or by giving it inappropriate data. Some
examples:

WORD PROC WORD PROC WORD - PROC \directoryname WORD - PROC
nonexistent-filename
WORD-PROC /etc/date [or other command]

The "inappropriate data" tactic has been used successfully in the recent past.

Another bug that's been exploited is excess command stacking. Command stacking is the placing of multiple commands on one line. Commands may be separated with spaces, semicolons, slashes, or a number of other punctuation symbols. The parser which interprets the stacked commands may break down if too many
commands are given it. The line editor may not allow you to enter so many lines that this occurs, but through programming tricks you can probably get an unwieldy stack of commands sent as though from the keyboard.

If there is a language or compiler available, then it should be possible to POKE some values into places that would be better left unprodded. Alternatively, you might find yourself able to compile code into specific areas of memory, overwriting the code which is impeding your progress. Or your code might cause the program
to jump to a new location, where further instructions can be carried out.

Finally, see if you can load a program into a mail writer or other editor, or into a superzap program, and alter it so that when it rum, it will crash.

Bugs in software are most likely to occur if the software in question:
• Is new (i.e., version one or thereabouts, or being Beta tested).
• Was hastily slapped together to make some fast money or to comply with the advertisements or demands.
• Has remained the same for years despite hardware or other changes.
• Is being renovated.
• Is not commercially available.

When you're hopping around on the networks you encounter, stop and read the notes that accompany new versions of old software. These will generally list, not just the improvements made, but sometimes the reasons for the improvements (i.e., if there was an exploitable bug in the earlier version). By the time you read the upgrade note, most sites will probably have already upgraded to the new version, but given the tremendous number of computers running today, more than a few won't have heard that a new version of their software has been released.

Viruses

A virus is born from the cross breeding of three other families of programs: the Trojan horse, the worm, and the logic bomb.

A logic bomb is a piece of code hidden within a larger program. Usually it is no more than a simple IF/THEN statement. IF such-and-such is true, THEN do something. Judging by the name, logic bomb, you can guess what that "something" usually entails.

The classic example of a logic bomb being put to use is when a system programmer is fired for in-adequate job performance, or for some other hu-miliating reason. A few days after he walks away, the head honchos at the firm get a message from the programmer: "Pay me X thousand dollars be-fore July 31st and I'll tell you how to save your software and records from total annihilation." The programmer has, you see, implanted a logic bomb that will detonate at that certain date. A worm is a program with one purpose: to rep-licate itself. All it does is look at its environment, see where it can make a copy of itself, and it does so. Then there are
two copies of the worm. Each of those reproduces, and there are four. Four quickly become eight, and so on. Soon an entire computer or network is clogged with hundreds or even thou-sands of unstoppable reproduction machines.

Then there's the virus. A virus comes from the mating of these two other breeds. When a worm takes on a logic bomb aspect to it, you get a pro-gram that will replicate as much as it can, and then explode when "something" happens. The whole thing hides itself within an application program, as a Trojan horse.
Logic bombs are dangerous, but at least they are contained. Worms and viruses on the other hand, are unpredictable. Therefore, I say a true hacker will never release a worm, because they are too destructive with no purpose. A true hacker may release a virus if it can move harmlessly throughout a system, erasing itself as it goes, mak-ing sure it never backtracks to where it's been be-fore.
A virus can be programmed to e-mail pass-words to a specific address, or it can be used as a battering ram to brute force new passageways into computer systems. There are lots of ways in which hackers can use viruses, but it is difficult to use them safely.

There have been rumors of a microcomputer virus which, if it exists, would gladden the heart of many a hacker. The virus is called the AT&Tack Virus. Once it copies itself onto a computer, it tries to find a Hayes brand or compatible modem. If one exists, it silences the modem's speaker and dials a Preprogrammed number.

Apparently then whoever is at the telephone number it calls has remote access to your computer.

To me, this seems like nothing more than a rumor. Indeed, as of this writing none of the commercially available virus detection software makes any mention of an AT&Tack Virus. Besides, it seems to me this sort of thing would work better as a Trojan horse in a graphics display program, rather than as a virus.



Covert Channels

One of the fun things about using Trojan horses and viruses is the designing of covert channels to get the data they collect back to you in some read-able form. Consider a virus that attaches itself to the login program and thus collects passwords. It does no good to have this virus halfway across the world with no way to get back that list of pass-words it is reaping. One method has already been mentioned: the virus can periodically e-mail you a list of passwords. Take heed not to have that e-mail sent to any account where you can be identified.
It would also be a good idea to encrypt the mail before it is sent. One problem with encryption is that a key is required. Anyone finding your virus or Trojan horse will easily figure out what the key is and be able to interpret e-mail or temporary files that the virus/Trojan horse produces. So you have to encrypt the key... which requires another key... which means more hiding needs to be done... an-other key.... Well, this could go on forever. Make the best of the situation. If you're going to be encrypting anyway it may be easier to have your virus or Trojan horse send the encoded data to an unmoderated newsgroup. Disadvantage:
You have to spoof the post, or some-one may notice that this user (who is unknowingly activating your virus or Trojan horse) is posting a lot of "garbage" to the group.

You may also have the encrypted file uploaded to the incoming directory of an anonymous FIT site somewhere. Make certain files can be downloaded from that directory, because as mentioned earlier, often the ability to download from such directories is turned off for security reasons.

To send short messages (like a single password)(Normally a Trojan horse or virus would send back to you three pieces of information: username, password, and the address of the computer where that  usemame-/password was valid. However, if you targeted a,spe-cific individual by giving that individual sole access to your Trojan horse, then only a password would be needed.

Of course, viruses and Trojan horses don't have to be messengers for only password information. You may be a hacker, but you may also be a spy, a crasher, or whoknows- what-else. As far as I know, the informa-tion you need covertly passed back to you could be virtually anything.) you may have your rogue program rename a world-changeable file to that message. By "world-changeable," I am referring to the security protections placed on that file - set it to very low protection, so that anyone can change its attributes. Your Trojan horse/virus will come into your directory under the disguise of various users from all around the network, and attempt to rename that file to that message. You don't want your Trojan horse/virus to
generate an error message. (You can set up a process to constantly run in the back-ground, monitoring the state of that file. As the file's name changes, the background process stores the new name, then gives the file its original name, thus allowing another copy of your Trojan horse or virus the opportunity to send its
message.)

Other short messages can be sent a bit at a time. For example, the existence of file X in a certain directory means that your rogue program is sending the digit one. If the directory is empty, the file deleted, a zero bit is being transmitted. A background process is running in your home directory to monitor the appearance
and disappearance of that file. When enough zeros and ones accumulate, the program translates them into a character of the message.

The extended ASCII code uses eight bits to define a character. For instance, 01000001 represents the capital letter A. 01000010 is B ', and so forth. For your virus or Trojan horse to send an eight character password, 64 deletions and creations of file X would be needed. Those bits would be sent one at a time,
whenever the rogue program had the opportunity to do so unnoticed.

Program Employment

Most programs that are employed by hackers are of the Trojan horse variety. And the classic Trojan horse example is one which uses the faults of others to achieve its goal. Generally this means using undisciplined PATH commands.

Most modem operating systems allow you to arrange your files in an organized fashion by the use of directories and subdirectories. This makes finding where you left a file easy, but it causes problems when you get sick of typing in long pathnames to change from one directory to an-other.

The solution is in PATH commands. A PATH command says to the OS, "if you don't find that file in the current directory, look over there... Thenlook there.... And there." In other words, you specify a path which the OS can follow to find files. That way you don't have to be in a file's directory to ac-cess that file.

PATH commands are usually put into batch files which are run at login. They are especially used on big machines which contain lots of files and tons of directories. In those cases, especially if the user is a maintenance operator and needs ac-cess all over the place, there might be a lot of direc-tories specified in the PATH.

Sloppy search paths, especially ones which look at all or most of the directories on a system are of extreme importance to the hacker. The hacker starts by rewriting a program that gets used often and putting a Trojan horse into it. The program is then put into a directory that is likely to be in a super-user's path. A privileged
user or program, such as a superuser shell script, may innocently chance upon, let's say, your "date" program instead of the It official" version stored in the OS directory. It is ac-cessed, and your hidden code does its thing. Trojan horses can do a lot of things. They can collect passwords, simulate login prompts ( Also, think about Trojan horses in terms of the multi-user games discussed earlier - obtaining those pass-words, etc.) remove read/write protection from files, or fake system crashes (and when the user shuts off his terminal and
walks away, you type in the secret control code which causes the Trojan horse to uncrash back to the user's account). Trojan horses should definitely make up the majority of a hacker's tool kit. But there is another, different means of gaining higher access by employing programs, and that is with the use of computer viruses.

Bit By Bit

Let's say you find yourself in some rinky-dink little account one evening, with just about zero ac-cess to anything interesting. On this hypothetical system you are able to read the passwords file, but of course to change it is out of the question.

You can see that your account's password has been encrypted (in the file) as "fg(kk3j2." If you had the ability to load the password file into a text edi-tor, you could replace the sysadmin's encrypted password with yours ("fg(kk3j2"), then save the file. Well, naturally you can't do that. You could get as far as loading the file
into a text editor and chang-ing it: but to save like that is impossible without superuser status. Or is it?

The system security may be such that it only makes validation checks at the highest level of in-teraction. So the high level commands to delete, move, execute, or alter files are disallowed if the user does not have a certain security clearance; the actual machine level commands to move the read/write head to a particular
location, let's say, may not be halted in the least. If this were true for the whole available storage arena, every file could be completely read or rewritten bit by bit. If pro-gramming or disk maintenance software is avail-able to you on-line, you might then be able to use it to alter individual storage locations - to change the
system administrator's encrypted password to your own.

On the other hand, you might find that security prevents even low level instructions from being performed. Don't give up too soon! It may be that onl parts of the storage arena have been protected, while others - due to forgetfulness, bugs, impossibility or impracticality - have been left unsecure. If so, you may not be able to change the passwords file, but perhaps it would be possible to move files to another user's private directory, or to change files that are already there. This opens up a whole world of possible Trojan horses and back doors. If security seems to prevent all illegal access from taking place, perhaps it is possible to trick a process with superuser security clearance into doing the work for you. A simple program, such as a game, could be written, containing instructions to secretly alter passwords.

Compile and save the program, making access to it available only to superusers. Then move the file into a public directory. Eventually some superuser will come along and execute it, thus enacting the portions of your program which, if you had run them yourself, would have resulted in error messages and perhaps a few more
ticks on the security log.

Cryptography And DES

Reverting to old tricks, brute force attacks can allow you to decrypt password files on your own time, on  your own terms. Even with your meager account you should be able to copy an encrypted password file off a machine you've hacked and onto a safer one. At the very least, you should be able to view the contents of a password file, even though it is encrypted.

Then you compile a copy of the decryption software, altering it so it will read in a word from a specially-prepared dictionary file, use that as a key, and print the result. UNIX source code listings are available for every facet of the OS. Even if you can't get a decryptor of the type used by the computer to code the password (and other) files, you can still go to the manual, see which encryption algorithm is used, and write a program yourself that follows that algorithm. Brute forcing encryption keys on a password file is much faster than forcing one's way onto the system in the first place. Soon you should have found a key that unlocks the code, and soon you will have the superuser password!

Brute force may not always be a necessity. There is reportedly a well-known inversion to the encryption algorithm used on certain OSs, includ-ing older versions of VMS. Sorry to say, I don't know exactly what this inversion method is. I do know there are ways to algorithmically reverse the effects of a "crypt" command in
UNIX. That com-mand uses the World War 11 Enigma coding algo-rithm, which was devious for its time but no match for modern supercomputers. Sure, it still takes a while to do the inversion, but it is possible to do it if you have a computer with enough horsepower.

However, the crypt command isn't used all that much because everyone knows how vulnerable it is. Mostly "crypt" is left around for sentimental rea-sons. The encryptor that is most often used to en-code passwords is a version of the federal Data En-cryption Standard (DES). The UNIX variation of DES is "defective" in that
brute force attacks for en-cryption keys are close to impossible. How does it defeat brute force attacks?
As we all know, UNIX password files are openly available for anyone to read, copy, or print out, but the passwords themselves are stored in an encrypted form. Well, that's not exactly right. The password file actually does NOT contain any passwords at all. What happens is, when a user logs in for the first time and enters a password, UNIX uses the first eight characters of the pass-word as an encryption key to encode some constant (say, a long random number).

Another reason why DES was chosen to encrypt passwords is that when the DES algorithm is implemented in software form, it is slow. This means it will take more time to run a brute force attack.

Staying with this topic a bit, it's unsettling to note that the Data Encryption Standard also may not be as secure as it was once believed to be. DES was based on a security system called Lucifer, de-veloped by IBM for the National Bureau of Stan-dards in 1973. Before being released as the USA's official (standard) code,
the top-secret National Se-curity Agency had their say in the matter, reducing the complexity of the encoding algorithm and keeping certain aspects of its design under wraps. This looked mighty suspicious! Why would the NSA go out of its way to proclaim the code secure while simultaneously making it less secure? Critics
warned that a back door had probably been built into the system.

In early 1992, two Israeli scientists announced that they had found a way to beat the system. If someone knows the encoded message, certain mathematical techniques can be applied to infer the key used to encrypt the message. Then other coded texts which use the same key can be easily read. In any case, it is well known that much better codes have been produced since the 1970s.

Some systems make it difficult to brute force the plaintext out of an encrypted file, because the en-cryption key supplied by the user is not what en-codes the text. Rather, it is used to encode some random sequence of characters. Those characters encode the text.

You don't have to be smart to be a hacker, you just have to be clever. But to crack data encryption algorithms you must be clever, smart and mathematically-inclined. Lucky for us people who don't have calculators for brains, there are so many other ways to read encrypted files than by breaking the code! I'll stick with Van Eck and his cronies, thank you.

Spoofing

Spoofing usually refers to sending electronic mail in such a way that it looks like someone else was the one who sent it. Spoofing can also refer to any act whereby a hacker impersonates another user. Let's stick with the first, more common definition for a while, and look at some ways in which spoofed e-mail can benefit the
low-level hacker who wants to make good for himself.

One prototypical scam is to spoof an e-mail letter from the system operator. Susie User, a highly powerful person on the system, is on-line, going about her usual business. She checks her mailbox and is surprised to find a letter has just been mailed to her from the system administrator. The letter talks about how, because
of security breaches, they will now be issuing new passwords every six weeks. "Your new password is D4YUL," says S.U.'s e-mail. "You can change it yourself with the 'SET - PASS' command. Remember it! Don't reveal it to anybody! Computer security is an important issue that can not be taken lightly!"

A few moments later you notice that Susie has issued a SET-PASS command, and a few moments later you log on in her name, thus achieving her higher security privileges. It works every time! The trick is, you have to know how to spoof to do it.

Before you can spoof e-mail, you have to understand how such a thing is possible. Now, if you've ever used any sort of electronic mail program, whether on a mainframe or local BBS, you know that to send mail, the user enters basically three pieces of information: destination, subject and the body of the letter. Some mail
programs allow fur-ther complexities, such as the inclusion of other text files or programs, return receipts, etc., but let's just concern ourselves with the most primitive of mail-ing programs, as those are the ones that get the most usage. When you send electronic mail to another user, the computer automatically places a heading on top of the letter, which identifies it as having come from you. To spoof e-mail you will want to some-how change that heading, so it looks as though the letter was written by the person in charge of the system.

Usually one sends mail by running a mail pro-gram. The mail program includes a text editor and facilities to send mail to other users. But in many cases you don't have to use a special mailing program to send mail. There is usually a fundamental shell progran-uning command that allows you to send text or a file, into a file on
another user's direc-tory. This is what the mailing program does: it sends the text of your message into a file called MAIL.TXT or something similar, and when Susie U. executes her mail program, it will display the contents of the file MAIL.TXT.

As you can imagine, it is a simple task to open a text file, type in a header that looks like a header from a superuser's letter, then add your own text to the bottom of the file. Next you use the "send file" command to put this file into another user's direc-tory. Make sure the directory you put it in is one with higher access privileges than your own!

Sometimes the operating system itself foils this scheme. For example, one of the Internet protocols requires the two computers involved with the mail transfer to compose the letter headers. To spoof on the Internet, one would connect to a host through port 25, which is how e-mail is transferred to a site. Normally only two
computers connect in this way; there may be security safeguards in place, but if there are not, you can pretend to be a computer sending the commands to generate an e-mail mes-sage. This includes "mail from" and "rcpt" which establish who the sender and recipient are. Use "help" to get yourself through this.
Earlier I mentioned that spoofing is also con-sidered to be any form of on-line impersonation of another.

Many multi-user systems let users chat with each other by way of a command called TALK or WRITE, or something similar. When you issue a TALK command, a message appears on the recipi-ent's screen, saying that you wish to talk. If the other user wants to talk with you, he or she issues the TALK command also. Then
whatever you type appears on the other one's screen and vice versa. It may also be possible to filter the contents of a file onto another's screen by way of a TALK command. The hacking possibilities are endless!

One popular trick is to TALK a message like, "SYSTEM FAILURE. SHUT OFF YOUR TEW41-NAL WITHOUT DISCONNECTING TO PREVENT FURTHER DAMAGE. SYSADMIN," onto another person's screen. When they hang up, you piggy-back a ride on their account. As with e-mail spoofs, you can't actually use the TALK command to put text on another user's screen. You have to go into the source code of the TALK program, see how it writes to another screen, and use those commands. This bypasses the
safety features inherent in the TALK command. (If you use the actual TALK command to send this sample error message, the other party will see that it's you sending the message, not the Sysadmin. You have to emulate the TALK header which announces the name of the user sending text. You also want to go down to
the fundamental "send text" statements because you don't want the user to have the option of not talking with you.)

It's a recognized fact that spoofing accounts for a good majority of system security failings, mainly because they're so easy to do once you've gotten on-line and taken a look at the software source codes and manuals. Another trick relies on TALK-ing a message that an intelligent terminal will un-derstand. When you use a TALK command you aren't putting words into the OS prompt's mouth - the OS is simply putting what you type onto the remote terminal's screen. One way to get around that depends on the remote hardware. Some intel-ligent terminals have a Send or Enter escape se-quence that tells the terminal to send the current line to the system as if the user had typed it in from the keyboard. You can use TALK to send a message that contains a suitable escape sequence to do naughty things like email confidential documents back to you and the like.

Not only e-mail and TALK, but other com-mands are also known to be rife with ways they can be misused to a hacker's benefit. Anytime you come across a command which allows interaction with another terminal, study it closely to see how it can be manipulated.

Look at programs, too, to see if they can be used to communicate out of your own directory. The GNU-EMACS text editor (used on UNIX computers) allows you to send the file you are working on to another person's directory. If you happened to name that file ".login",(Under UNIX, "Jogin" is the name of the batch file that gets executed once a user logs into his or her account.) then whenever that user logged on, that ".login" batch would execute. And if part of that "Jogin" included mailing the user's secret stuff to your account, so much the better.

Becoming A Superuser

Breaking into a system isn't worth anything if you find yourself in an empty home directory with such a low access level that nothing fun is allowable. Men you hack into a low-level account belonging to a data entry clerk or some other restricted user, you will want to raise your access to the highest it can go. This is
accomplished by doing research from the inside, spoofing, programming tricks, or social engineering.

As far as research is concerned, you will want to look around the system you've just penetrated and see what options are available to you. Read all files; run all programs. Most technical hacks in-volve bugs in established software. Generally this software is of a kind that interacts with other users' accounts in some way. Thus mailing and "chatting" programs are susceptible, as well as text editors. If you find a programming language of any kind you should be in Hacker's Heaven, as there are hun-dreds of variations on programming tricks you can use while inside to gain better access. Let's start with spoofing.

The User Network

USENET is to local BBSs what the Taj Mahal is to anthills. USENET is an Internet BBS that encompasses thousands of discussion groups and millions of postings. On USENET, you don't just have a "computers" bulletin board, you have boards talk-ing about software, about hardware, viruses, hack-ers, individual operating systems and printers and spreadsheets and ethics and... you name it. Each topic area is called a newsgroup. There are groups engaging in talk about music, cars, sex, SCUBA diving, crime, parachuting, television, books, bestiality, flowers - it makes one dizzy to think about it all. Some newsgroups are moderated. That is, some controlling organization edits the postings or picks and chooses which messages will be given display time. Most groups are an unmoderated free-for-all. One accesses USENET by running a news pro-gram such as "readnews," "news," or "nn." You can read the posted messages, or write one of your own. Messages are sent out to all other participat-ing sites worldwide, which means if you have a question about anything, USENET offers a huge in-temational forum through which to find an answer.

Fun'N Games

You might see Xtrek or Empire, or any number of on-line, multiuser games available on the com-puters you crack, especially those at colleges. Because the games are multiuser, passwords are re-quired to access them, and it should be noted that often the password-storing mechanism on the games is not as secure as it should be; the passwords are sometimes placed in a plaintext file. We know that people tend to use the same password wherever they go. Think about it.

File Transfer Protocol (FTP)

FTP is a program that allows users to copy files back and forth between two computers, usually two computers connected via the Internet. Strictly BITNET users will need to use e-mail instead of FrP to transfer files. After typing "ftp" to start the program, one can input any computer address and try to connect with it. A username and password will be asked for. Many sites offer an anonymous FI'P directory - users can log in with the username "anonymous" and have access to all the text files and rograms that the site administrator has made available.

Often an anonymous FTP site is set up like a trading post. An incoming directory is set up with anonymous write and execute permission, but usually not read permission. Users can then upload files they want to share with others without those others knowing the files are available. The system operator can evaluate the files before making them publicly available. One common security hole with anonymous FTP is that two auxiliary directories called "etc." and 'bin" are often owned by the FTP account. If this is the case, and if they are not write protected, any user could upload their own malevolent versions of system programs and batches.

Looking Around

What should you expect to find, once you've made it onto a system or network? A whole lotta things!

There may be files to read, programs to run, or ways to move about from one computer to another, or one network to another.

Try looking for backup files and files that have been automatically saved on a timed basis. Some text editors leave behind files like this that are readable by anyone who happens to pass by. If the sysadmin has been editing the password file, or some other file containing sensitive data, you could be in luck. Electronic mail is
often not automati-cally deleted, and it accumulates in (perhaps hid-den) files on disks. Deleted files may not be deleted right away, but become hidden or moved to a spe-cial directory.

See if you can find evidence of security logs. One of the most common errors for a user to make while logging in is to type the password at the username prompt. If you can find a readable secu-rity log it will often contain records of these login errors. For example, if George Washington tries logging into his UNIX account with
his password, "cherrytree," but he types a little too fast, the following ensues:
WashingtonUs [Enter]
ername:cherrytree [Enter] Password:
George realizes he has messed up. He has typed his name before the login prompt, and he has put his password (quite visibly) on the "Usernarne:` line. He presses Enter a few times to clear every-thing, but the damage is already done.
Somewhere in the administrative directories, there is a log file that reads:
Unsuccessful login of user cherrytree @ Tue,
Mar 24,1992,14:16:03
Now you just have to go through the various users on the system until you find the one who uses this password.

Security logs may also keep track of files sent and received, errors resulting from unauthorized commands, new accounts or new users being granted superuser status.

Speaking of security, thefirst thing you should do any time you log in to an account for the first time is try to get a sense of who this person is whose account you are borrowing (assuming you don't already know). When you log on you will most likely be greeted with a message telling you the last time that account had been
active, and possibly which location or server the user had con-tacted it through.

If the message tells you that the legitimate user logged in recently then you may have a problem. Note the time of day the account was used and try to hack around it. Try logging in two times simul-taneously on two separate computers and see what happens. Do you get an error message the second time? Is it possible to
detect the presence of another person using the account with you concurrently? You want to know such things because you want to be able to deal with having the account holder co-incidentally log on at the same time as you.

Let's look at this first scenario. You are logged into the account... the actual user tries logging in but gets a "User hjones already logged in on port 116" message. You have no way of knowing that this has occurred, but you can prepare for its eventuality by sending an e-mail message to the ac-count, purportedly from the
system manager, and leave it unread. So if the legitimate account holder were to log in she would find something like this waiting for her:

Message #01
From 1513 SuperUser
To AUUSERS@calli.poo.n-til

Some faulty wiring has led to problems with several of our port connection verifier circuits in the subchart group C of the local network system. If you receive a message upon login that you are already logged on, please hang up and try again in a few minutes.

We are sorry about this problem and we are doing what we can to correct it, but this will take time. It was a matter of choosing between a bit of inconvenience for a while, or shutting down the system entirely. I hope you will agree it is better to have some bugs in the sys-tem than no system at all.

We expect the problem to be cleared up before March 3rd. Thanks for your cooperation.

Often users will have personal history logs stored in their directory. There may be history re-ports detailing command activity, newsgroup readership, file transfers or files deleted. These can show you when and how the legitimate user is us-ing the system, and also the level of competence of the user.

If your account has been used very infre-quently, then you know that the actual account owner poses very little threat to you - although it also means the system manager is now a threat, since he will suddenly see tons of activity from an account that had never before been active.

On the other hand, if the account holder is in there night and day, you will have to be more wary of him than of the sysop - after all, any hacking you do from that account will get lost in the shuffle.

Commands To Look For And To Use Most operating systems come with extensive online help. On UNIX, you can type "man com-mandname" to see the manual page for a com-mand. Also helpful is "apropos" which will display a list of commands that are related to a given word. For example, "apropos password" lists all the com-mands, programs and variables that have some-thing to do with passwords. You can then use "man
commandname" to find out what each one means.

On TOPS machines you can type "help" or "help commandname" for on-line information.

Process commands tell you what is being done on the system and, generally, who is doing it. UNIX lets you type "ps -f` ' to see how other people are using the computer. Using such commands will give you a feel for what options are available to you. Also, it will show you which users have access on other computers, if they
are logged into them from the one you are on. If you're extremely lucky you might even find an encryption key poised in the list of processes. If a person has typed some-thing like "crypt key < filename" that entire command, including the key, will appear in the listing. Unfortunately, the crypt program acts to remove the key from the listing once it is activated, but there is a brief period when the key is public data, there for all to see. A "daemon" program could search for such occurrences (See glossary).

"Telnet" is a program that allows you to connect to other computers. Earlier it was mentioned that the account you've entered is most likely a low-ac-cess account. The reason a hacker bothers with regular user accounts in the first place is to give him or her a safe place to do real hacking. From that account you can do all the
things you would never do from your legitimate account, like telnet to Pentagon computers and start a brute force attack. UNIX also has a "cu" (Call Up) command which allows the user to call up a specified phone number.

Calling one computer from another enables the hacker to avoid being traced. It also might be the most practical solution to the problem of connect-ing to a certain computer, since some computers can only be accessed through other networks.

Operating Systems

Okay, clear your mind of any thoughts you've ever had about computers. We're going to start at the very beginning.

Let's say you had a computer that only did one thing. For instance, think of a coin operated arcade game. That's a computer which plays but a single game. With a one-game computer, as soon as you push the on switch, the game can start running. Af-ter all, there's nothing else to do with the machine except play that
game.

Now let's add a second thing to our computer. Let's say, not only does the computer play a game, it also does word processing. So we now have a two-task computer.

What happens when we push the on switch? Does it go right to the game? It can't - what if we wanted to do word processing? You see, now we have to make a choice. When we turn on the com-puter, we now have to specify somehow whether we want the game or word processing. How do we let the computer know where to go?

Well, we could have two separate switches, meaning any time I press the left switch, the game goes on and when I press the right switch, the word processor goes on. That may be a good solution for a little while, but what if I want to add a third thing to my computer? Or a fourth? Do I keep adding more switches?

What I do is, instead of adding hardware switches, I add a third program, a software switch. The third program is called the operating system (or OS), and when I push the computer's switch, the computer will automatically turn on the operating system program.

The operating system is a program that lets me choose between the game or the word processor. For example, when the operating system is started it may put a prompt on the screen such as, "Which program?" to which I would reply, "Game" or "Word Processor."

As you are well aware, this is basically what happens in real-world operating systems. In the early days of computing, when computers didn't do much more than run a few select programs, the controlling software was called "the monitor." As computers became more complex, there came the need to control multiple
users, many peripherals, security, and an interlacing of program function-ings. The monitor grew to become an all-encompassing program which did a lot more than just allowing the user to choose between a few programs. And so the term "operating system" is now used to describe this complicated piece of software.
Operating systems control the functioning of the entire computer; they control how resources will be allocated to the tasks at hand, how memory is used, which programs are to be run and in what order. It is the absolute master-control program; when you understand it, you have the understand-mg necessary to master the computer.

Some operating systems you are most likely to run into are "UNIX," "MS-DOS" or "P&DOS" (on IBM compatibles), "PRIMOS," "RSTS" (on Digital Equipment Corporation's PDP-11 minicomputers), and "VMS."

It is important to understand operating systems because:

1. If you don't know the commands and syntax that control the computer, you won't be able to get the
computer to do anything.
2. When you understand how an operating sys-tem works, you will be better able to look for bugs in it. Bugs invariably lead to security loopholes, which lead to a happier you.
3. You want to be familiar with the limitations of the operating system's security, so that you can exploit those limitations.
4. When you know how an operating system works, you will know what the computer's managers can do to
trip you up, keep track of your whereabouts, and keep you from coming back.

All of this leads up to one big THEREFORE...

Therefore, if you want to be a REAL HACKER, you have to actually know something about computers. If you want to control a computer, you have to know how to tame the software which controls that com-puter - you have to understand very fundamental things about its operating system.

Sure, a hacker may be able to get bv using so-cial methods and a tidbit of programmmg here and there, but there is no escaping the fact that real hacking requires real knowledge. And I'm talking about seV-taught knowledge. You have to go out and learn this stuff on your own.

Does this sound intimidating? Then maybe you don't have what it takes to be a hacker.<Hey, I'm talking Big Manuals here - thousands of pages long, and written in the ghastliest corporate/tech-nical mumbo jumbo imaginable.>

Realistically, there is no way to make a 100% guarantee that a particular computer system is safe from intruders. It is theoretically possible to break into any system. A good hacker should be able to break into most systems. An even better one will be able to get into all of them. And the absolute finest hacker will not only be able to enter every com-puter he encounters, but will be able to do some-thing constructive once inside to make the trip worthwhile.

I mean, it's one thing to hack one's way into an on-line database. It's another thing entirely to fig-ure out how to alter records in that database, and to do so without being caught.

If you want to have the ability to enter any system that you encounter and take action once inside,
then you must become knowledgeable about its OS. At the simplest level that means knowing the basic commands that any user of the system requires on a day to day basis to interact with files, to send and receive mail, and to perform any needed action on the machine.

A hacker needs to know the obscure commands as well, and should also be familiar with any files, software and directories commonly found on ma-chines under that OS. He needs to know how the manuals are structured and the "jargon" of the OS. He needs to know who uses such an OS and how they use it. And he needs to know the meanings of error messages.

But we still haven't gotten to the hard part yet. You see, all of the above is just the tip of the ice-berg. After all, all of this information is easily avail-able from standard sources such as manuals and design specification guides. What a hacker needs to know about an OS is the secret stuff that doesn't come in the manuals, or
if it is printed there it is so technical and obscure that it is information decipherable only by a select few. Those lists of "basic things a hacker should learn" describe what the OS is and what it does. But a hacker - to effectively enter and exploit any system he or she encounters - needs to know how the OS works, and
why it works as it does.

Operating systems are so huge that they can never be adequately checked to ensure that every single bug has been worked out. They are some-times altered to include features or functions that a particular computer manager finds desirable, but those alterations open up security holes. Sometimes multiple programmers
working on different parts of the system don't communicate about vital as-pects and so distant processes may explode if forced into contact. Additionally, the software that is used may have been designed for the plain-Jane version of the OS and so incompatibilities (and hence glitches) develop. Or two or more pieces of
software being used together may open up sources of insecurity.

The casual user is oblivious to all of these pos-sible security breaches. A hacker may be oblivious to them, but if the hacker has a fundamental under-standing of the operating system which underlies all these sources of intrusion, then that hacker will, with a bit of thought, realize where the traps are and how they can be usefully manipulated.

Needless to say, this book is not going to suddenly turn into an explanation of the technical aspects of every single operating system, and a true hacker wouldn't want it to be. So, go out there and find some operating system you can get acquainted with. Learn its basic commands, but then go a Step beyond that and learn how those commands were programmed. Figure out ways you could simulate the command without typing it directly at the OS prompt. What happens to memory when the com-mand is executed? Are there ways to change memory?

These are the kinds of things that are impor-tant to a hacker who wants to accomplish big dreams.

Examples of such techno-oriented hacker meth-ods abound throughout the rest of this chapter. The reason is simple and unavoidable: the best things in life are often not free. You have to work hard if you want to do great and exciting things after invading a system. Sure, you may find it convenient to learn certain things only as the need arises, such as a particular shell programming language, or the way an application works. But when you lack knowl-edge about underlying principles of the operating system, you are hacking blindly - you are just as oblivious to the exploitable faults and flaws of the system as any other user. Let's get away from all this heady stuff for awhile and go back to the impetus for this discussion of operating systems: After you get in, what the hell comes next?

What To Do When Inside

It seems straightforward enough. You're inside? Great! Take a look around! Of course that is what you'll do in most cases, after getting into a system and patting yourself on the back. But then what? To answer this we will have to begin with a re-thinking of our goals and morals.

Hacker Motivations Revisited

The true hacker is motivated by her or his de-sire to learn, to understand, to cleverly and harm-lessly outwit.

Others who use hacker techniques might do so because they have a desire to learn about their competitor's secrets; to understand why they keep getting underbid every time; or to cleverly outwit the company or individual who they feel owes them something, and enact revenge upon them.

So let's see what we have here. There is the free-thinking, computer-enthusiast hacker, the eco-nomic espionage hacker, the politico-espionage hacker, the out for revenge cracker, and finally, the hacker for hire. Most often these assorted infiltrators will have breached security with a low-level account. This is because accounts with low security clearance are the most prevalent, and many hacker tricks focus on the naive user who is more prone to having a low-level account.

The hacker for hire and the hacker spies will have target computers, perhaps even specifically-targeted people in mind. They will want to go after either a particular username/password combina-tion, or any access big enough to allow covert entry into their target's account.

Vandals and revenge hackers obviously would love to attain higher access than what they came in on, but unless they are sufficiently skilled, they will probably opt for the quick hit-and-run. That is, they will be content to break in under any password, do whatever damage is possible, send some nasty e-mail, and leave.
Probably they will continue com-ing back over and over again until they are either arrested or shut out for good. If these "hackers" do have targets in mind (like the president of the com-pany or whomever) they will most likely settle happily into whatever lower-level role they find themselves in. If they have any skills or
computer know-how though, watch out.

The true hacker may or may not want to take the hack all the way to the top. He or she may feel it is not worth the effort for the amount of work that seems necessary to increase a low system access to a higher one. This isn't giving up, it's being practi-cal. If the knowledge to be gained seems minimal or available elsewhere, there's no point in wasting time trying to get it. Or, the hacker may not feel se-cure enough in his knowledge of the computer, its users, or operating system to feel confident in his ability to achieve higher access. This is a valid feeling, and an intelligent one; if the hacker realizes he is somehow ignorant, then he can stop and do what is necessary to learn what he does not already know. If something like this comes up it's probably only a matter of research to put the hacker back on the track toward superuser status. As the hacker BrainMan put it: I know the computer will be there for a long time to come. I like hacking, but I also like exploration. Sometimes I feel I'd rather wait for another day to do the exploration, the bookwork or social engineering, that will get me into an account, and I'd rather do some real exploration of a computer right now.

Besides increasing one's status in the system, a hacker has many options to choose from once in-side. A hacker may:

• Read the documents that are available, and run the programs.
• Download files.
• Notify the system administrator of the presence of a security problem.
• Learn about the computing environment.
• See if other computers may be contacted from this one.
• Cover his ass.

Or a hacker might simply log off and never return.

If you have managed to work your way into some data that you feel might have market value, you might consider selling that data and thereby fund your next big computer purchase. I recom-mend strongly against doing so. Becoming a spy -for anyone - becomes a serious and dangerous business. It also helps to further
degrade the image of the hacker in the public's eye, and will serve only to make matters worse for hackers in the long run - and you in the short run - if you are caught.

Although most courts and CEOs would dis-agree, I personally believe that there is no harm done in reading through whatever files are on a system, so long as no one is hurt in the process. At least, I don't think reading private files is a crime any worse than hacking one's way in, in the first place. You will have to construct your
own set of ethics to guide you; I sincerely hope those ethical constraints are based firmly on the principles of the hacker ethic that both opens and closes this book. Logging off and never returning is something the more fanatic and paranoid hackers tend to do. It is akin to B & E without the E, and I can not see how they can
morally condone the "B" (breaking in) while shunning the "E" (entering). I suppose the hackers who disconnect without system interaction do it either because all that matters to them is get-ting in, or because they are intensely seared of dis-covery.

The other options I mentioned - increasing status, helping the sysops, and the learning - all require different degrees of familiarity with the computer system you have entered. Let us think about where you might find yourself, and what should you do when there.

To begin with, the account you have hacked yourself in with can be a single user account, a group account, root account, or "special account."

If it's a root account, congratulations! You now have the ability to do whatever you want. The root account is held by the system administrator (or one of several "sysadmins"). It may also be called by different names: avatar account, god account, sysadmin, superuser, demigod account, sysop ac-count, or admin. Or you may never even know you've gotten into the root until you find you can do stuff only the Computer Gods high upon Mount Input/Output should be able to do.

A "group account" is one used by many people. It might be a departmental or store account, where everyone in a particular store or department can log in under the same name/pass combo. Depend-ing on the situation' those who are of a certain rank or job may have their own shared account. For ex-ample, many companies
like to set up limited ac-counts for secretaries, typing pool or temps. Other group accounts appear in places where terminals are available to a number of employees, but where employees have differing levels of security clear-ance. Thus, all may be able to search a database, but only those who log in with a certain password can enter new data, or can change the way the da-tabase is structured.

"Special accounts" include guest or demo ac-counts that allow one to take a sneak peek before subscribing to a service. They may be testing ac-counts put in by system programmers. Special ac-counts may also take one directly to a program, rather than logging you to an operating system prompt. Programs are set up this
way for tutorial purposes, to dispense information, or so access to a particular application may be more freely available. If the account you've managed to hack is a special account, you might have to break out of it illegally and enter the operating system if you expect to in-crease your access level.

In any case, before any action can be taken you must understand what kind of access you have, what privileges you're entitled to, and how they can be exploited to your advantage. This may mean you'll need an intimate knowledge of the machine and its software. Before we can proceed there's one teeny weeny concept
you must have full compre-hension of. I've just mentioned it twice now - the operating system.