Thursday 15 December 2011

Hacking At Home: Scrutinize The Login Environment

The login environment is the area of the remote computer which you are allowed to access before identifying yourself as a valid user of the system. The login environment of most computers is limited to a username and password prompt. Some environments are more expansive, giving a general command prompt, at which you can type any number of instructions. Those instructions won't necessarily be carried out (you probably have to log in first) but they can be helpful.

There are a number of common commands that one can type at a board command prompt, and a list of these is given in Appendix C. Try typing "help" or "T' first, and see if that does anything. A command like "users," "show users," or "who" will be helpful, in that you can see the names of people who are on the system and try to guess their pass-words. The advantage of having certain other conunands may not be as apparent, nor will there necessarily be any advantage at all to the hacker. One good thing about general command prompts is that often one is reverted back to them after failing a login. Thus if three incorrect user-name/passwords are
entered, instead of discon-necting you, the computer will bring you back to the command prompt for another go-round.

When you find yourself at a general command prompt with no help available, try doing different things, paying attention to the error messages you receive. Try entering commands in all upper or all lower case, then mixed cases. Look at the maximum and minimum lengths of commands. See which characters are recognized. All of this is helpful in that it narrows down the number of unknowns. It helps you more easily figure out what you should be doing to get things moving.
If every time you
type "HELP" you get a "Line too long" error, then you know the system is probably looking for three-letter commands. That is useful information.
If you type "CONNECT," and the system re-sponds, "The verb CONNE is not available" it im-plies that only the first five characters of input are examined.
If, on the other hand, your entire entry is examined, advanced help may be available. For ex-ample, if by typing "HELP" you get a list of com-mands, typing "HELP COMMANDNAME" may give you help with that one particular command. Such help systems are common.

Let's look at the actual entering of usemarne and password. Some terminals tell you you're wrong when you enter a bad name, others wait until you've given both name and password to in-form you. The first way is preferable, as it is less se-cure and requires substantially fewer guesses to crack than the latter. The IBM VM/370 was inse-cure in this regard; it immediately informed you that the username was no good with a "userid not in cp directory" error message. One system that I know of (Dynix) follows the same format. First it helpfully prompts for your "Nine digit ID code" (hint, hint, what could that be? A social security number perhaps?) and when the correct one is en-tered, it will say, "Good morning Samantha. Now type your
password." This particular computer allows you to easily break into one of several command languages and reprogram the menu inter-face. It also comes equipped with dial-in ports. Dynix is a joy to hack.

If you get a computer of the second type (one which asks you for name and password before saying if your login is accepted), then time how long it takes to display the password prompt on the screen. This can help you decide if a usemame you're entering is valid or not. Let's say you try the name "Jim," and it takes two
seconds for the computer to respond with the password prompt. Every time you type "Jim," it takes that long. Now try the usemame "Zzzzzzz." This is obviously a madeup name that the computer won't be able to find in its files. If it consistently takes longer for the password prompt to appear after typing the name "Zzzzzzz,"
you know that "Jim" is a valid usemarne, and you .;hould continue guessing passwords for him. That is, on systems where sequential search is in effect, it takes longer for the computer to search for a nonex-istent entry in its data files than an existent entry.

In any case, source codes are often available, espe-cially for UNIX files, and so you can look them up to see how the inner workings of the login prompts function. If you have no idea what kind of username and/or password is required on a particular system, do the same kind of checking you would do at a general
command prompt, checking for which characters and lengths are recognized.

A completely different way you might like to research the login prompt is by control codes. Pressing certain keys, or combinations of keys, delivers codes to a remote computer which may force it to act in ways that it was not meant to behave. For example, you can send an ASCII code to command the remote computer to stop reading a password file. Sometimes it is then possible to quickly retype the password you entered, and make the computer believe it has found your input as part of the password file, thus letting you into the system. Sometimes pressing Control-Z (the end-of-file command) at the right time will bring strange results too. Look up all abbreviations, weird letters and other things that appear on the screen. Any decent library will have an encyclopedia of acronyms. (Any indecent library will have this book.) Very often you will call up a packet switching network, find a valid address, then get something like "Welcome to VHMSD! Password?" on the screen.

So, you do your research and find out that VHMSD stands for Viking Horn Manufacturers of South Dakota, and the whole task of hacking the place be-comes infinitely simpler. Remember, when you are hacking a computer, you are really hacking the people that run the computer. Thus, if you can find out who is running
the show, you have a multitude of resources at your disposal, including all the research tools mentioned earlier. Otherwise you're just taking random stabs at a computer identified only by some strange abbreviation.