For protection and simplification purposes, just about all general-purpose public computers will boot up to a menu program. There are three fruitful programming ideas the hacker can employ with these:
• altering the menu,
• altering the menu program, or
• creating your own simulation of the menuing system
.
Menu programs will have a menu-editing op-tion. This allows the people who maintain the computers to create menu categories such as "Business Programs," "Word Processing," and the like, and to add and edit the programs available for public use. The way to work menus to your advan-tage is to use the editing feature
to add or change an option that will appear to be taking the user into an area where a password is required. However, what the menu will really do is take that user to a program that you wrote, that simulates an envi-ronment the user is familiar with. The user inno-cently enters his user ID and password (which your program stores), then an error message is given and the user is returned to the menu. Later, you can go to where the computer hid the passwords and lDs, and retrieve them for your personal use.
The first question is, how does one edit the menu?
The menu-editing feature may be part of a sec-ondary program, such as INSTALL.EXE or SETUP.EXE. You may also be able to do editing di-rectly from the menu program itself, by pushing a function key or control code. Problems start arising because you were not meant to be able to change the menu setup on pub-licly available computers. The menu-editing feature may have been eliminated once the menu was set up, or a password might be required to do any-thing.
Maybe you can re-install the program, recreat-ing the present menu from scratch, while putting in your own additions (to be discussed soon, hold your horses!). Alternately, you might be able to use a text editor or superzap program to change the file where menu information is stored. If you start get-ting error messages
when you try to change the file, the ATTRIB command might have been used to "lock" the file. Just type "attrib filename -r" to un-lock it (on MS-DOS systems). The way these menu programs work is, the per-son doing the editing must supply a short phrase that will be displayed on the screen. He then must choose a file to be executed when that phrase is se-lected, possibly providing a drive path, and other information.
Suppose you want to infiltrate a university computer system. Your initial target is a public computer with word processing, spreadsheet and telecommunications abilities. When someone sits down and selects "Telecommunications" from the menu, he or she is either connected to a host server, or asked which computer he or she would like to connect to. Then the connection is made.
That's what it's going to look like is happening. What actually happened was that when the user pressed "T" for "Telecommunications," the menu ran a program that you snuck onto the system, instead of actually connecting to the network. The program you put on should look like it's doing whatever normally happens
when someone selects "Telecommunications." For example, it might prompt for which computer the user wants to connect with, and then pretend to connect to that computer. Your program then presents the name and password prompts, and saves those lovely words to disk!
Next, you can have the program give an error message and return the user to the main menu, but that looks suspicious and will cause the people in charge to take a closer look at their computer setup.
You'll be better off having your little simulation program being called from a batch file. When it's through executing, have the next step in the batch make a real connection to the system. It might be possible to have the batch file feed in the name and password the user entered, thus eliminating any trace of weirdness.
Otherwise, have it print the standard "password not valid" message, and then connect to the network.
In other situations, the "Telecommunications" option will bring the user to a commercial terminal package such as ProComm Plus or SmartCom. Again, it is easy to make your own fake version of one of these programs. But there is a catch.
When the user enters your fake terminal program, he will select a phone number from the list, and attempt to dial it. He will be awfully suspicious and confused if the speaker is on and yet no dialing sounds come out of it! (Remember, you somehow have to make the program appear to dial out, so you can then simulate the network that is called. Then the user will enter his password thinking he has actually ac-cessed the network.)
The most reasonable way to solve this dilemma is to have the program give an exotic error message like:
Operating Error 2130: Line Noise Interference.
Shut off your speaker and try again.
Of course, this message should closely conform to the other error messages that the terminal pro-gram actually puts out. Once the user shuts off the speaker, the pro-gram can then pretend to dial out, and give the standard login screen for that network. The name and password is taken and quietly stored to disk, and then an error message is given and the user is logged off.
You may want to have the computer just put a lot of garbage and random characters on the screen after the name and password are entered. Make it look realistic - like the kind of line noise that we've all gotten at one time or another - but make it excessive. The user will be forced to log off al-most immediately. If he doesn't, or if he tries doing anything, just have the computer display the stan-dard "Logged off. Good-bye!" message. It may be possible at that point to have the computer load the real terminal program, so it will look like nothing very unusual has occurred.
It is unusual to find commercial terminal pack-ages on public computers, mostly because that would lead to people coming in and placing calls to halfway around the world. But offices and businesses might have them, so consider these ideas when you think about hacking onsite.
Let's go back to the menu program.
The menu program might not be a commer-cially available one. It might have been designed in-house, or in an interpreted language such as BA-SIC, or for some other reason the source might be readily adjustable. The program might be just a batch file.
If any of these are the case, you will be able to effortlessly change the menu program itself, either by building subroutines that store names and pass-words, or by adding a telecommunications option if one is lacking.
The final variation on the menu ploy is to com-pose a simulation of the menu. That is, if you are not able to change the already-existing menu, you will have to write a program that looks like the es-tablished menu, but with your own embellish-ments on it.
It can take a while to replicate the menu pro-gram. If the menu uses pop-up windows you will have to write routines for screen dissolves, or pro-gram-in windows that explode open and implode to a close. You will have to carefully take note of screen colors and special characters displayed, how the actual program handles invalid data, and other peculiarities of the menu. While the programming may be difficult, you are better off using your own menu because that will make it easier to hide the captured passwords and other goodies that are the goals of this project in the first place.
