Now we come to the third We of Public Access Computer from that list I gave several pages back: the General Purpose Micro. I'm going to be talking here about IBMs and MS-DOS machines, although nowadays we're seeing more and more Macs out in the open for public use. Of course, all techniques I discuss can be translated to any computing envirorunent.
Let's say you call up your local library and make an appointment to use a computer there, for word processing or business or whatever. Ordinar-ily these are nonnetwork machines, although if there's more than one they may be connected to the same printer, or to some other peripheral. At col-leges, the word processing software may be on a non-writable disk - on some sort of mainframe or minicomputer. There are also businesses set up now where people can go to rent time on a com-puter to type up their r6sum6s or reports, and have them printed out on a good quality printer. Set-ups such these can be exploited to the hacker's benefit.
Showing posts with label Chapter 7. Show all posts
Showing posts with label Chapter 7. Show all posts
Tuesday, 15 January 2013
Thursday, 8 December 2011
Things To Watch Out For
I'm going to list a few things to be careful of when you implement a program of this kind. My remarks will be directed toward this program in particular, but they are far-ranging enough to be applicable to just about any program like this that you hide on a system.
First, make sure EDLIN is there, as well as DE-BUG, TREE and other external DOS commands. They may not be available on the computer you are using, and you can end up with a mess on your hands, and discovery of your intentions. When you attempt to copy these files you may find that the DOS directory has been write protected. In that case you may have to put the necessary commands in an alternative directory. This might expose them to the ravages of the clean-up program. If the cleaner does delete these external commands you will have to figure out some solution to get them onto the disk and protect them from the
cleaner. This batch only works on text files - EDLIN will mess up binary files. Second, you will have to make sure beforehand that the DOS directory is in the PATH. What that means is, for a particular file to be executable, it must either be located in the current directory, or in a directory that has been predefined (usually
by AUTOEXEC.BAT) as a place for the operating sys-tem to look for files to execute.
This is no problem of course - just add a PATH or CD statement be-fore the first EDLIN - but it is something you could easily overlook, especially if you had to add the special commands yourself to an unusual or unfamiliar directory.
Also notice before installing any programs: will there be enough space on the disk? Enough mem-ory? Does the program try to create the temp file in a locked directory? (If so, open temp in a USERS di-rectory, or some other writable one.) Does a file named "temp" already exist? How about "Corrunandl," "Command2" and "Command3"? There are alternate ways to use this program. In-stead of having the date-changer execute before the clean-up program, it could be run every time the password file gets updated. Though it takes a few seconds to run and that time might be enough to noticeably slow down the user's application pro-gram. Recall
that this program is meant to be used in conjunction with some sort of Trojan horse you've installed; the horse itself will slow down the computer somewhat already, the combination of the two programs might be too much to go unnoticed. The clean-up program might use some other criteria which helps it decide which files to save and which to throw away. You will have to use similar programming techniques to thwart its ad-vances accordingly.
If there is no special clean-up program, the hard drive will be cleaned by an actual human being. That human being might not be clever enough to look outside the designated USERS directory for files, but you have to act as if that person is as clever as you. Anyhow, you never know who else is using a public computer, so
you will have to take measures to hide your precious password files from view.
Here are a few suggestions:
Change the hidden-file attribute so that it is not listed in the directory. Place it in an obscure directory or in an unreach-able one. Try this experiment. Put the following commands into a batch file:
:Start
mkdir dir
cd dir
goto Start
and then execute it from the root directory. After sixteen nestled directories named "dir" are created you will get an error message. Press Control-C and look at what has been created. You will find that within the innermost directory it is impossible to make any more directories - there's a limit to what the computer has been programmed to handle. However, you can use a disk management utility or your own system calls to prune and graft many more directories inside the deepest one.
Those grafted directories will be impossible to see or ac-cess from the DOS shell. If the clean-up program uses the DOS command TREE to scan all the direc-tories, it will crash or freeze once it gets to those il-legally nestled directories you put there. You don't want that to happen: that would lead to discovery of your secret files hidden within that directory. Accordingly, this trick requires that you have the programming prowess to write prune-and-graft programs on your own. Your Trojan horse would have to be able to move the data file from its pro-tected position, then back again afterward.
One thing you are certainly DOS-sophisticated enough to handle is to camouflage the files you want to protect within their directories. DON'T use filenames like SECRET.PSW or HACKER.HA! Use a bit of creativity when naming them. Go into one of the applications directories and see if there are any patterns to file namings. If you see for example, that a spreadsheet has files named AFGRABL.OVL, AFGRAB2.OVL, AFGRAB3.OVL, then name your files AFGRAB4.OVL, AFGRAB5.OVL, etc. Do you think anyone will bother to look at them then? You might want to split up the files, putting each in a separate directory; don't forget to specify the proper drive paths in the batch file that uses these files.
Trojan horses on public access computers can be an excellent way to slowly-butsurely collect passwords for your enjoyment. However, all will be for naught if, when you come back the next day to see what you've reaped, all of your files are gone. Protect yourself, and your handiwork.
Keep in mind as you read about these special programming tricks, that I'm not implying you should actually sit out in the open and edit menus or sift through files looking for passwords. Never do that! You must always first make a preliminary examination of the computer as I described earlier. You will have already copied
over the important and unusual files - in this initial exploration of the computer - and you should have the entire menu program at your disposal. At home and at your Iei-sure, you can write the programs necessary for this kind of hacker attack. Then, once you've finished the programming and editing required, you can go back
for a second session at the public computer, this time secretly installing your mutated versions of their programs onto the system. This reduces the amount of time you will have to spend in a public place doing questionable things to somebody else's computer. It also reduces the chance of error in the things you do.
You must be especially careful with computers that are meant to be used only for short periods of time. Guest registers, as described earlier, are used for the few moments it takes for a person to enter his or her name and identification number. You will look extremely suspicious fiddling around there for forty minutes, taking
notes and inserting disks.
It is not the other users you have to be wary of: they couldn't care less about you, and if anything, will probably mistake you for someone who works in the building. Depending on where you are, you might not even have to worry about being caught by the office or lab managers, computer aides, or whatever the official designation is for the people in charge. If it's a college computer lab being moni-tored by one or two students, they might be curi-ous, but won't pry as long as you don't stay longer than you're supposed to at the computers. It is al-most never a good idea to come right out and admit you are snooping around for the express purpose of gathering data to be used in hacking. A comment such as, "Oh, I just wanted to see how they did this batch file," or some other appropriate explanation, is a good enough excuse for most such people. Some computers are public; many more are private. That is the topic of the next chapter.
First, make sure EDLIN is there, as well as DE-BUG, TREE and other external DOS commands. They may not be available on the computer you are using, and you can end up with a mess on your hands, and discovery of your intentions. When you attempt to copy these files you may find that the DOS directory has been write protected. In that case you may have to put the necessary commands in an alternative directory. This might expose them to the ravages of the clean-up program. If the cleaner does delete these external commands you will have to figure out some solution to get them onto the disk and protect them from the
cleaner. This batch only works on text files - EDLIN will mess up binary files. Second, you will have to make sure beforehand that the DOS directory is in the PATH. What that means is, for a particular file to be executable, it must either be located in the current directory, or in a directory that has been predefined (usually
by AUTOEXEC.BAT) as a place for the operating sys-tem to look for files to execute.
This is no problem of course - just add a PATH or CD statement be-fore the first EDLIN - but it is something you could easily overlook, especially if you had to add the special commands yourself to an unusual or unfamiliar directory.
Also notice before installing any programs: will there be enough space on the disk? Enough mem-ory? Does the program try to create the temp file in a locked directory? (If so, open temp in a USERS di-rectory, or some other writable one.) Does a file named "temp" already exist? How about "Corrunandl," "Command2" and "Command3"? There are alternate ways to use this program. In-stead of having the date-changer execute before the clean-up program, it could be run every time the password file gets updated. Though it takes a few seconds to run and that time might be enough to noticeably slow down the user's application pro-gram. Recall
that this program is meant to be used in conjunction with some sort of Trojan horse you've installed; the horse itself will slow down the computer somewhat already, the combination of the two programs might be too much to go unnoticed. The clean-up program might use some other criteria which helps it decide which files to save and which to throw away. You will have to use similar programming techniques to thwart its ad-vances accordingly.
If there is no special clean-up program, the hard drive will be cleaned by an actual human being. That human being might not be clever enough to look outside the designated USERS directory for files, but you have to act as if that person is as clever as you. Anyhow, you never know who else is using a public computer, so
you will have to take measures to hide your precious password files from view.
Here are a few suggestions:
Change the hidden-file attribute so that it is not listed in the directory. Place it in an obscure directory or in an unreach-able one. Try this experiment. Put the following commands into a batch file:
:Start
mkdir dir
cd dir
goto Start
and then execute it from the root directory. After sixteen nestled directories named "dir" are created you will get an error message. Press Control-C and look at what has been created. You will find that within the innermost directory it is impossible to make any more directories - there's a limit to what the computer has been programmed to handle. However, you can use a disk management utility or your own system calls to prune and graft many more directories inside the deepest one.
Those grafted directories will be impossible to see or ac-cess from the DOS shell. If the clean-up program uses the DOS command TREE to scan all the direc-tories, it will crash or freeze once it gets to those il-legally nestled directories you put there. You don't want that to happen: that would lead to discovery of your secret files hidden within that directory. Accordingly, this trick requires that you have the programming prowess to write prune-and-graft programs on your own. Your Trojan horse would have to be able to move the data file from its pro-tected position, then back again afterward.
One thing you are certainly DOS-sophisticated enough to handle is to camouflage the files you want to protect within their directories. DON'T use filenames like SECRET.PSW or HACKER.HA! Use a bit of creativity when naming them. Go into one of the applications directories and see if there are any patterns to file namings. If you see for example, that a spreadsheet has files named AFGRABL.OVL, AFGRAB2.OVL, AFGRAB3.OVL, then name your files AFGRAB4.OVL, AFGRAB5.OVL, etc. Do you think anyone will bother to look at them then? You might want to split up the files, putting each in a separate directory; don't forget to specify the proper drive paths in the batch file that uses these files.
Trojan horses on public access computers can be an excellent way to slowly-butsurely collect passwords for your enjoyment. However, all will be for naught if, when you come back the next day to see what you've reaped, all of your files are gone. Protect yourself, and your handiwork.
Keep in mind as you read about these special programming tricks, that I'm not implying you should actually sit out in the open and edit menus or sift through files looking for passwords. Never do that! You must always first make a preliminary examination of the computer as I described earlier. You will have already copied
over the important and unusual files - in this initial exploration of the computer - and you should have the entire menu program at your disposal. At home and at your Iei-sure, you can write the programs necessary for this kind of hacker attack. Then, once you've finished the programming and editing required, you can go back
for a second session at the public computer, this time secretly installing your mutated versions of their programs onto the system. This reduces the amount of time you will have to spend in a public place doing questionable things to somebody else's computer. It also reduces the chance of error in the things you do.
You must be especially careful with computers that are meant to be used only for short periods of time. Guest registers, as described earlier, are used for the few moments it takes for a person to enter his or her name and identification number. You will look extremely suspicious fiddling around there for forty minutes, taking
notes and inserting disks.
It is not the other users you have to be wary of: they couldn't care less about you, and if anything, will probably mistake you for someone who works in the building. Depending on where you are, you might not even have to worry about being caught by the office or lab managers, computer aides, or whatever the official designation is for the people in charge. If it's a college computer lab being moni-tored by one or two students, they might be curi-ous, but won't pry as long as you don't stay longer than you're supposed to at the computers. It is al-most never a good idea to come right out and admit you are snooping around for the express purpose of gathering data to be used in hacking. A comment such as, "Oh, I just wanted to see how they did this batch file," or some other appropriate explanation, is a good enough excuse for most such people. Some computers are public; many more are private. That is the topic of the next chapter.
Hiding Your Goody Basket
All of the above menu methods, as well as many of the techniques explained earlier regarding simulating network login sequences and capturing keystrokes, result in a file being saved to disk. There are two things you have to worry about: That your file will be discovered, and that your file will be read. Let's look at how we can prevent both of these from occurring.
The thing is, since most of this takes place on public computers, anyone at all may locate your precious files. This includes the people who run the computer labs, those who fix the computers, other hackers, and the oh-so-curious general public. It also includes the computer itself.
Most public computers you encounter will have a self-cleaning routine installed. Weekly, monthly, or perhaps every night, the computers will have all their old data files erased, to keep room on the drives for new material.
Most public word processing computers have notes attached that beg people to bring their own disks on which to save their work, but there usually is a special USERS directory, or some other area where anyone can save files. The cleaning program is used to clear away old files from this directory. The program will often scan the rest of the drive, clearing away files that users have stored in other directories. Often on public computers you will see dozens of empty di-rectories scattered about; usually these directories have human names to them. These are private di-rectories that people made for themselves in the hopes that other users wouldn't read or delete their files - never realizing that their files would be de-leted by the computer. Often the cleaning program is too dumb to recognize that the directory, too, should be deleted.
Before you put your altered menu program or whatever onto a public computer, you must do some experimenting to see what kind of cleaning system it has, if any. There's no sense in spending hours on a project only to have it erased soon after it's implemented.
If a cleaning program does exist on the computer, you should have it copied over, along with everything else, from your initial investigation of the computer. Take a look at the program; there will be plenty of ways to defeat it. The cleaner probably has a data file that holds information on which directories it should examine, what should be done with the outdated files it detects, what cal-endar date constitutes "oldness," and other perti-nent variables. You may be able to use this file to your advantage by adjusting it so that your own special directory or program will be ignored by the cleaner.
If the computer activates the cleaning program automatically, your explorations might lead you to find the trigger that sets it off and causes it to delete certain files and not others. For example, the cleaning program could be connected with a logoff function, so that before the computers are shut down for the night, the drives are scanned and un-wanted files are removed. The cleaner could also be activated as part of a start-up routine, or a regu-larlyperformed maintenance check. In any case, a careful exploration of the files on the
system will reveal the pattern they follow. Once you find the program that sets the cleaner off, you will be able to make alterations to your own file so that it is ignored, rather than deleted.
Often the cleaning program is an all-or-nothing monster that wipes out everything in its path as it crosses the hard drive. However, there are consid-erate versions that only delete old files. You can get around these gentler kinds by writing a simple program. Here is an example of an MS-DOS batch file that changes the date
of your hidden goody basket in the example (a text file called "filename") to one far in the future. Append this batch file to the end of the AUTOEXEC.BAT, or to the point in the system's maintenance routines directly before the cleaner is activated.
Your file will never be erased.
@echo off
ctty nul
date < commandl > temp edlin temp < cornmand2 date 12-31-1999 edlin filename
< command3 edlin commandl < command3 edlin command.2 < command3 edlin
command3 < command3 date < temp, del *.bak
del temp.* ctty con
For this to work, you need to make up three auxiliary files. Here we are calling them commandl," "command.2," and "command3," but you would want to name them something more in-nocuous. "Commandl" contains a single carriage return (Control-M). "Cornmand3" is a file containing only the letter e. "Command2" is a bit longer:
2d
I rCurrent date is
1rSun
Irmon
IrTue
IrWed
IrThu
1rFri
IrSat
e
The batch file works by using the "date" command to change the date to December 31, 1999. EDLIN is invoked to save the password file (containing the goods), and the three auxiliary files, under this new date to protect them. a y, the date is returned to normal. Note that MS-DOS can be set up to display the date under
various formats. You might have to alter the batch file and "Command2" if your target computer is set up in an irregular way. Also, realize that "temp" is a common filename. You would do best to use something exotic in your own program.
AUTOEXEC.BAT files get changed often, and a batch file like this sample is bound to be noticed by the maintenance staff. To keep your coding discreet you may want to keep this and similar batches in a separate file far away on the hard drive from the AUTOEXEC. BAT. At the point in the AUTOEXEC where your Trojan batch would have been executed, you can use the DOS "call" command ("call BATCH.BAT" will
execute your Trojan and, once it's done, return to the ALJTOEXEC batch file). Your batch file can be suitably camouflaged as described below, and there is now only one imposter line in the AUTOEXEC batch for a maintenance worker to notice. Also remember that under certain operating systems, such as MS-DOS, the "ATTRIB" command can be used to make filenames invisible in the directory listing ("attrib FILENAME +h" turns on the hide factor). ATTRIBing a filename is not really secure, as there are many ways someone can either accidentally or purposely find out about invisible files on a hard drive. But eliminating the name the from the directory certainly does much to halt casual discovery of your Trojan files.
The thing is, since most of this takes place on public computers, anyone at all may locate your precious files. This includes the people who run the computer labs, those who fix the computers, other hackers, and the oh-so-curious general public. It also includes the computer itself.
Most public computers you encounter will have a self-cleaning routine installed. Weekly, monthly, or perhaps every night, the computers will have all their old data files erased, to keep room on the drives for new material.
Most public word processing computers have notes attached that beg people to bring their own disks on which to save their work, but there usually is a special USERS directory, or some other area where anyone can save files. The cleaning program is used to clear away old files from this directory. The program will often scan the rest of the drive, clearing away files that users have stored in other directories. Often on public computers you will see dozens of empty di-rectories scattered about; usually these directories have human names to them. These are private di-rectories that people made for themselves in the hopes that other users wouldn't read or delete their files - never realizing that their files would be de-leted by the computer. Often the cleaning program is too dumb to recognize that the directory, too, should be deleted.
Before you put your altered menu program or whatever onto a public computer, you must do some experimenting to see what kind of cleaning system it has, if any. There's no sense in spending hours on a project only to have it erased soon after it's implemented.
If a cleaning program does exist on the computer, you should have it copied over, along with everything else, from your initial investigation of the computer. Take a look at the program; there will be plenty of ways to defeat it. The cleaner probably has a data file that holds information on which directories it should examine, what should be done with the outdated files it detects, what cal-endar date constitutes "oldness," and other perti-nent variables. You may be able to use this file to your advantage by adjusting it so that your own special directory or program will be ignored by the cleaner.
If the computer activates the cleaning program automatically, your explorations might lead you to find the trigger that sets it off and causes it to delete certain files and not others. For example, the cleaning program could be connected with a logoff function, so that before the computers are shut down for the night, the drives are scanned and un-wanted files are removed. The cleaner could also be activated as part of a start-up routine, or a regu-larlyperformed maintenance check. In any case, a careful exploration of the files on the
system will reveal the pattern they follow. Once you find the program that sets the cleaner off, you will be able to make alterations to your own file so that it is ignored, rather than deleted.
Often the cleaning program is an all-or-nothing monster that wipes out everything in its path as it crosses the hard drive. However, there are consid-erate versions that only delete old files. You can get around these gentler kinds by writing a simple program. Here is an example of an MS-DOS batch file that changes the date
of your hidden goody basket in the example (a text file called "filename") to one far in the future. Append this batch file to the end of the AUTOEXEC.BAT, or to the point in the system's maintenance routines directly before the cleaner is activated.
Your file will never be erased.
@echo off
ctty nul
date < commandl > temp edlin temp < cornmand2 date 12-31-1999 edlin filename
< command3 edlin commandl < command3 edlin command.2 < command3 edlin
command3 < command3 date < temp, del *.bak
del temp.* ctty con
For this to work, you need to make up three auxiliary files. Here we are calling them commandl," "command.2," and "command3," but you would want to name them something more in-nocuous. "Commandl" contains a single carriage return (Control-M). "Cornmand3" is a file containing only the letter e. "Command2" is a bit longer:
2d
I rCurrent date is
1rSun
Irmon
IrTue
IrWed
IrThu
1rFri
IrSat
e
The batch file works by using the "date" command to change the date to December 31, 1999. EDLIN is invoked to save the password file (containing the goods), and the three auxiliary files, under this new date to protect them. a y, the date is returned to normal. Note that MS-DOS can be set up to display the date under
various formats. You might have to alter the batch file and "Command2" if your target computer is set up in an irregular way. Also, realize that "temp" is a common filename. You would do best to use something exotic in your own program.
AUTOEXEC.BAT files get changed often, and a batch file like this sample is bound to be noticed by the maintenance staff. To keep your coding discreet you may want to keep this and similar batches in a separate file far away on the hard drive from the AUTOEXEC. BAT. At the point in the AUTOEXEC where your Trojan batch would have been executed, you can use the DOS "call" command ("call BATCH.BAT" will
execute your Trojan and, once it's done, return to the ALJTOEXEC batch file). Your batch file can be suitably camouflaged as described below, and there is now only one imposter line in the AUTOEXEC batch for a maintenance worker to notice. Also remember that under certain operating systems, such as MS-DOS, the "ATTRIB" command can be used to make filenames invisible in the directory listing ("attrib FILENAME +h" turns on the hide factor). ATTRIBing a filename is not really secure, as there are many ways someone can either accidentally or purposely find out about invisible files on a hard drive. But eliminating the name the from the directory certainly does much to halt casual discovery of your Trojan files.
Menu Simulation And Other Sneakiness
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.
• 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.
PACK
When you go out on a public hacking expedi-tion, you'll want to be prepared by taking along your PACK: Public-Accessible Computer (hacking) Kit. This kit should include:
Plenty of blank, formatted disks, in both 3%" and 51/4" sizes, so you can quickly copy the menu's security programs. Make sure these disks are the proper density for the drives you will be using.
Auxiliary programs, such as superzappers and other utilities. You will also want to bring any special programs you have written (such as menu simulations, as discussed in the next sec-tion). Public domain programs are available to shut off the internal speaker. This can be useful if you're hacking a computer that lets out a loud and suspicious beep every time a wrong pass-word is entered.
Other tools: A Swiss Army knife is good, or at least bring a little screwdriver. Very often, es-pecially on CD-ROM workstations, you will find locks or covers placed over the disk drives to limit access. A large, unbent paper clip is handy for hacking Macs. If you have to leave in a hurry, you can slip the end of the paper clip into the hole next to the disk drive, and your disk will pop out. That's often the fastest way to eject a disk.
Plenty of blank, formatted disks, in both 3%" and 51/4" sizes, so you can quickly copy the menu's security programs. Make sure these disks are the proper density for the drives you will be using.
Auxiliary programs, such as superzappers and other utilities. You will also want to bring any special programs you have written (such as menu simulations, as discussed in the next sec-tion). Public domain programs are available to shut off the internal speaker. This can be useful if you're hacking a computer that lets out a loud and suspicious beep every time a wrong pass-word is entered.
Other tools: A Swiss Army knife is good, or at least bring a little screwdriver. Very often, es-pecially on CD-ROM workstations, you will find locks or covers placed over the disk drives to limit access. A large, unbent paper clip is handy for hacking Macs. If you have to leave in a hurry, you can slip the end of the paper clip into the hole next to the disk drive, and your disk will pop out. That's often the fastest way to eject a disk.
Freedom Means Free Roaming
Once you are able to exit the menu system you will be able to explore the computer.
If there are lots of computer-wise people around, or people looking over your shoulder, or people in charge running all over the place, then you'll want to get back to authorized sections of the computer ASAP so you're not discovered in the private parts and thrown out of the building.
My recommendation is to copy everything relevant to your cause onto floppies, then take them home to examine them at your leisure. This is akin to the burglar who steals the entire unopenable safe so he can work on it in his basement with noisy power tools and blow torches.
Copy the AUTOEXEC.BAT file and the menu system first of all, and any directories you find containing files with BAT, DOC or TXT extensions; miscellaneous disk utilities (especially public domain-type programs); security, maintenance, or updating programs; anything having to do with telecommunications; memory
resident programs; other explanatory text files.
Especially if the computer's on a LAN, there may be a D: drive, F: or H: or an L: drive, or some higher-lettered drive that you wouldn't ordinarily even think of looking for.
Check for hidden files and directories. Copy them, too, if you find any. Also see if any files have been deleted, and try to recover them if they appear applicable to your needs.
Depending on the situation - the computer, the place of business, other relevant factors - you may or may not find anything on the computer. Often it's worth hacking a public computer like this just for the thrill of getting by security measures. However, the computers are often so poorly pro-tected that even this thrill is a minor one.
Many times I've found public domain and shareware utilities that I'd never seen before, so it's worth doing this just to see if you can pick up any-thing new along these lines. You may even pick up some valuable programming hints or ideas - some of the batch and script files you'll find can be im-pressively complex.
Another thing that's common is to find in-house programs on the system - things like employee schedulers, databases, or other programs that are not available for public use, and are reserved for use by the managers of the business or library.
If the computer has telecommunications or networking abilities, there may be handy phone numbers or sign-in protocols you will be able to use.
If you have encountered prompts for passwords in your exploration of the computer, try to find out where the master list of passwords is stored on the disk. One time I broke out of a public menu program in a special library, and after looking around awhile, found a carefully hidden file called PASSWDS. I typed it to the screen and was surprised to find a list of about six user names, along with passwords, addresses and other
personal information for each name. Naturally I was overjoyed, but to this day I haven't figured out why they were there. I tried those names on all the systems in the area without success. I tried fingering the people ("finger" is a UNIX command that allows you to look up information about system users) on the major
computers, to no avail. The people listed in the file seemed to not exist anywhere I looked for them! Perhaps someone was just using the file as a test or demo, or on some private computer system... but then why was the file hidden away so well? Sometimes you will discover red-herring clues of this kind, trails that seem to lead nowhere. It's all part of the nature of being what you are. Hacking is frequently a matter of intense research, with the goal being to establish a hypothesis, a question that needs answering. Once you have decided on a question ("Will this password list work on the Raamses 3?" "Does the President of Moroll Corporation have a secretary with system access?"), then you can do higher level research and try to answer
it.
If there are lots of computer-wise people around, or people looking over your shoulder, or people in charge running all over the place, then you'll want to get back to authorized sections of the computer ASAP so you're not discovered in the private parts and thrown out of the building.
My recommendation is to copy everything relevant to your cause onto floppies, then take them home to examine them at your leisure. This is akin to the burglar who steals the entire unopenable safe so he can work on it in his basement with noisy power tools and blow torches.
Copy the AUTOEXEC.BAT file and the menu system first of all, and any directories you find containing files with BAT, DOC or TXT extensions; miscellaneous disk utilities (especially public domain-type programs); security, maintenance, or updating programs; anything having to do with telecommunications; memory
resident programs; other explanatory text files.
Especially if the computer's on a LAN, there may be a D: drive, F: or H: or an L: drive, or some higher-lettered drive that you wouldn't ordinarily even think of looking for.
Check for hidden files and directories. Copy them, too, if you find any. Also see if any files have been deleted, and try to recover them if they appear applicable to your needs.
Depending on the situation - the computer, the place of business, other relevant factors - you may or may not find anything on the computer. Often it's worth hacking a public computer like this just for the thrill of getting by security measures. However, the computers are often so poorly pro-tected that even this thrill is a minor one.
Many times I've found public domain and shareware utilities that I'd never seen before, so it's worth doing this just to see if you can pick up any-thing new along these lines. You may even pick up some valuable programming hints or ideas - some of the batch and script files you'll find can be im-pressively complex.
Another thing that's common is to find in-house programs on the system - things like employee schedulers, databases, or other programs that are not available for public use, and are reserved for use by the managers of the business or library.
If the computer has telecommunications or networking abilities, there may be handy phone numbers or sign-in protocols you will be able to use.
If you have encountered prompts for passwords in your exploration of the computer, try to find out where the master list of passwords is stored on the disk. One time I broke out of a public menu program in a special library, and after looking around awhile, found a carefully hidden file called PASSWDS. I typed it to the screen and was surprised to find a list of about six user names, along with passwords, addresses and other
personal information for each name. Naturally I was overjoyed, but to this day I haven't figured out why they were there. I tried those names on all the systems in the area without success. I tried fingering the people ("finger" is a UNIX command that allows you to look up information about system users) on the major
computers, to no avail. The people listed in the file seemed to not exist anywhere I looked for them! Perhaps someone was just using the file as a test or demo, or on some private computer system... but then why was the file hidden away so well? Sometimes you will discover red-herring clues of this kind, trails that seem to lead nowhere. It's all part of the nature of being what you are. Hacking is frequently a matter of intense research, with the goal being to establish a hypothesis, a question that needs answering. Once you have decided on a question ("Will this password list work on the Raamses 3?" "Does the President of Moroll Corporation have a secretary with system access?"), then you can do higher level research and try to answer
it.
Saturday, 3 December 2011
Breaking Free
The first thing you'll notice is there's some kind of menu system on these micros. The people who run the joint don't need some snot-nose kid coming along and formatting their hard drives or leaving behind obscene messages, so certain protective de-vices are used to guard against such activities. It is generally a trivial
matter to get out of the menu program, even though its very existence - at least partially - is to keep you from doing just that. If the computer is turned on already and at the main menu, look on the screen for any indications of commands that shouldn't be there, such as "Alt-X to Quit." Try it - does it work? You might exit the menu, only to get a message like this: "Error! Press any key to return to Menu." What happened is this: when the computer was first turned on in the morning, the menu system was called up by the ALJTOEXEC.BAT file. By typing Alt-X, you have been returned to the AUTOEXEC.BAT shell, and are experiencing the next line of that BAT file. Simply Ctrl-C your way out of there. Even if it doesn't say on the screen how to leave the menu, you will want to try various function keys, the Ctrl-Break key, the Escape key, and differ-ent combinations of Alt and Ctrl with C, X, and Q. Often menu systems will have you enter a password before allowing you to exit to the operat-ing system. If this is the case with the one you're hacking, by all means try various passwords -starting with blank lines, the name of the building or company, and other obvious work-related and business-like words. Computer systems are at their weakest when they're moving from one program to another, so try choosing a menu item and using Ctrl-C as soon as it's selected.
Actually, for best results you should repeatedly tap Ctrl-C and the Ctrl-Break key simul-taneously.
If none of this works, turn the computer off, then turn it on again and see if you can Ctrl-C or Ct4-Break your way out of the ALJTOEXEC.BAT startup procedures. Alternately, you should have your own program disk ready to boot. If both of these tactics fail, use the menu system to run the various programs listed and see if any of them have an escape to the operating system.
For WordPerfect, you can shell out with Ctrl-F1. Wordstar allows shelling or single commands to be entered with Ctrl-K, F.
matter to get out of the menu program, even though its very existence - at least partially - is to keep you from doing just that. If the computer is turned on already and at the main menu, look on the screen for any indications of commands that shouldn't be there, such as "Alt-X to Quit." Try it - does it work? You might exit the menu, only to get a message like this: "Error! Press any key to return to Menu." What happened is this: when the computer was first turned on in the morning, the menu system was called up by the ALJTOEXEC.BAT file. By typing Alt-X, you have been returned to the AUTOEXEC.BAT shell, and are experiencing the next line of that BAT file. Simply Ctrl-C your way out of there. Even if it doesn't say on the screen how to leave the menu, you will want to try various function keys, the Ctrl-Break key, the Escape key, and differ-ent combinations of Alt and Ctrl with C, X, and Q. Often menu systems will have you enter a password before allowing you to exit to the operat-ing system. If this is the case with the one you're hacking, by all means try various passwords -starting with blank lines, the name of the building or company, and other obvious work-related and business-like words. Computer systems are at their weakest when they're moving from one program to another, so try choosing a menu item and using Ctrl-C as soon as it's selected.
Actually, for best results you should repeatedly tap Ctrl-C and the Ctrl-Break key simul-taneously.
If none of this works, turn the computer off, then turn it on again and see if you can Ctrl-C or Ct4-Break your way out of the ALJTOEXEC.BAT startup procedures. Alternately, you should have your own program disk ready to boot. If both of these tactics fail, use the menu system to run the various programs listed and see if any of them have an escape to the operating system.
For WordPerfect, you can shell out with Ctrl-F1. Wordstar allows shelling or single commands to be entered with Ctrl-K, F.
General Purpose Microcomputers
Now we come to the third We of Public Access Computer from that list I gave several pages back: the General Purpose Micro. I'm going to be talking here about IBMs and MS-DOS machines, although nowadays we're seeing more and more Macs out in the open for public use. Of course, all techniques I discuss can be translated to any computing envirorunent.
Let's say you call up your local library and make an appointment to use a computer there, for word processing or business or whatever. Ordinar-ily these are nonnetwork machines, although if there's more than one they may be connected to the same printer, or to some other peripheral. At col-leges, the word processing software may be on a non-writable disk - on some sort of mainframe or minicomputer. There are also businesses set up now where people can go to rent time on a com-puter to type up their r6sum6s or reports, and have them printed out on a good quality printer. Set-ups such these can be exploited to the hacker's benefit.
Let's say you call up your local library and make an appointment to use a computer there, for word processing or business or whatever. Ordinar-ily these are nonnetwork machines, although if there's more than one they may be connected to the same printer, or to some other peripheral. At col-leges, the word processing software may be on a non-writable disk - on some sort of mainframe or minicomputer. There are also businesses set up now where people can go to rent time on a com-puter to type up their r6sum6s or reports, and have them printed out on a good quality printer. Set-ups such these can be exploited to the hacker's benefit.
Hardware Methods
One thing I've done is to take an old, unused terminal I found hiding in a basement storage facil-ity, and wire it up to a portable computer. At about four in the morning I smuggled the thing into the computer lab, and replaced a terminal that was already there with my own, connecting the cable to the portable.
I hid the portable under the table. It was a wooden table with an overhang. I used an electric stapler to make an old pair of cut-off jeans into a pouch that hung down from the underside of the table, and I enclosed the portable within it. I had the portable programmed to save on disk the first ten characters that appeared after
"Usernarne:" and "Password:". Basically, the portable acted as a rnonitoring device, working between the terminal and the mainframe. It worked well.
The only thing that didn't work out was when I replaced the computer room's original terminal a week later. The guy thought I was trying to steal it.
There have been hackers who've taken old terminals, opened up the plastic casings, and hidden little computers inside the terminals! There was not enough room in the terminals I was using to do that, but in certain situations that would be a preferable thing to do. Make sure the computer you put in and any wiring
associated with it stays sepa-rated from the internal goings-on of the dumb terminal. When hackers hide portables in this way, they are generally putting their computer inside an otherwise hollow, bulky base of the terminal.
I hid the portable under the table. It was a wooden table with an overhang. I used an electric stapler to make an old pair of cut-off jeans into a pouch that hung down from the underside of the table, and I enclosed the portable within it. I had the portable programmed to save on disk the first ten characters that appeared after
"Usernarne:" and "Password:". Basically, the portable acted as a rnonitoring device, working between the terminal and the mainframe. It worked well.
The only thing that didn't work out was when I replaced the computer room's original terminal a week later. The guy thought I was trying to steal it.
There have been hackers who've taken old terminals, opened up the plastic casings, and hidden little computers inside the terminals! There was not enough room in the terminals I was using to do that, but in certain situations that would be a preferable thing to do. Make sure the computer you put in and any wiring
associated with it stays sepa-rated from the internal goings-on of the dumb terminal. When hackers hide portables in this way, they are generally putting their computer inside an otherwise hollow, bulky base of the terminal.
Doing It BASICally
If you have an account - or if you go into the computer lab and find someone else's account logged in and abandoned - you can write a simple BASIC program to simulate the login procedures, then leave it running. Here is a very simple example:
10 PRINT "Welcome to Y University Cornputer Network!"
20 PRINT
30 INPUT "Name? "; N$
40 INPUT "Pass? 10; P$
50 REM Now store these two variables in a file
60 REM and logoff from the account, giving an error
70 REM message. Or, use the inputted data to have
80 REM the program login to the system.
90 REM Finally, delete this program.
Remember to program in necessary time de-lays, if it usually takes a few seconds for commands to register. Also remember to have the program print asterisks (or periods, or dashes, or whatever's appropriate) on the screen instead of the user's password.
Sometimes commands are available to users be-fore logging on, like allowing them to see who else is currently logged on. You may or may not be able to program phony responses to a user's queries. The program doesn't have to be extremely elabo-rate, however, as most users will probably just sit down and login right away. You might want to sit around in the computer room awhile and look to see what
commands get used the most, so you will be able to program simulations of them. After the user is done typing his name and password, the program should store the information, and exit out of your account. If you wrote the program in another person's account (like the ones I mentioned finding logged in already) then the
program will have to transmit the data to you somehow < Methods to covertly transmit data are discussed in the chapter "What To Do When Inside.". > After all, once you log out of that account, you won't be able to get back in again. On the other hand, the operating system might allow you to save the file in your own directory if given the right access codes, or if you can make your own account temporarily less secure, allowing others to write to your directory.
Hacker security is very important - you never know what superuser is spying on your activities. Therefore, it would be wise to encode volatile in-formation like other people's passwords before they get stored in a file in your personal directory. I use a simple code, such as storing 13 + ASCII code of each character, with every
other number stored being random. So for the name/password combi-nation SM=RS/RANGERS my program would store 96 90 86 97 85 82 95 96 / 95 78 91 84 82 95 96, with random numbers between each of these num-bers. An expansion of these ideas is found in an up-coming chapter.
10 PRINT "Welcome to Y University Cornputer Network!"
20 PRINT
30 INPUT "Name? "; N$
40 INPUT "Pass? 10; P$
50 REM Now store these two variables in a file
60 REM and logoff from the account, giving an error
70 REM message. Or, use the inputted data to have
80 REM the program login to the system.
90 REM Finally, delete this program.
Remember to program in necessary time de-lays, if it usually takes a few seconds for commands to register. Also remember to have the program print asterisks (or periods, or dashes, or whatever's appropriate) on the screen instead of the user's password.
Sometimes commands are available to users be-fore logging on, like allowing them to see who else is currently logged on. You may or may not be able to program phony responses to a user's queries. The program doesn't have to be extremely elabo-rate, however, as most users will probably just sit down and login right away. You might want to sit around in the computer room awhile and look to see what
commands get used the most, so you will be able to program simulations of them. After the user is done typing his name and password, the program should store the information, and exit out of your account. If you wrote the program in another person's account (like the ones I mentioned finding logged in already) then the
program will have to transmit the data to you somehow < Methods to covertly transmit data are discussed in the chapter "What To Do When Inside.". > After all, once you log out of that account, you won't be able to get back in again. On the other hand, the operating system might allow you to save the file in your own directory if given the right access codes, or if you can make your own account temporarily less secure, allowing others to write to your directory.
Hacker security is very important - you never know what superuser is spying on your activities. Therefore, it would be wise to encode volatile in-formation like other people's passwords before they get stored in a file in your personal directory. I use a simple code, such as storing 13 + ASCII code of each character, with every
other number stored being random. So for the name/password combi-nation SM=RS/RANGERS my program would store 96 90 86 97 85 82 95 96 / 95 78 91 84 82 95 96, with random numbers between each of these num-bers. An expansion of these ideas is found in an up-coming chapter.
Shoulder Surfing
The above two methods are slightly involved examples of what's called "shoulder surfing." Shoulder surfing is when a hacker looms over the shoulder of a legitimate user as that user logs onto a computer system. While the user types, the hacker watches the keyboard to pick up the pass-word as it is entered. Remember, most
login rou-tines will not display the password on the screen, so you must look at the keyboard to get any useful information.
Pure shoulder surfing can only be done under certain circumstances, such as if you are legiti-mately helping the user with a problem and you have to stand there for the user to show you what's wrong. Most of the time you will not be able to just stand behind a person without drawing suspicion to yourself; you will have to rely
on more crafty inventions.
A strategically placed mirror, in the upper cor-ner between wall and ceiling, can do the trick. It must be small enough to stay put with duct tape, but big enough to be read from a distance. Binoculars are frequently used by calling-card number thieves to illegally obtain people's code numbers, thus enabling the thieves to make free long distance phone calls. You can do the same to read passwords off keyboards. It might be necessary to tilt the keyboard to a specific orientation to better enable you to see what is typed. If the key-boards have kickstands to prop them up, make sure you use them before you take your stalking posi-tion.
You might have to do your watching outside, through a window. Before you do, make sure you won't be visible to those inside. Even at night you will be easily seen through the glass if the building has outside lights. Do some detective work before hacking; go into the computer room and see how visible someone outside
the room would be. Per-haps you can partially close the blinds or drapes, to further shield yourself from view.
login rou-tines will not display the password on the screen, so you must look at the keyboard to get any useful information.
Pure shoulder surfing can only be done under certain circumstances, such as if you are legiti-mately helping the user with a problem and you have to stand there for the user to show you what's wrong. Most of the time you will not be able to just stand behind a person without drawing suspicion to yourself; you will have to rely
on more crafty inventions.
A strategically placed mirror, in the upper cor-ner between wall and ceiling, can do the trick. It must be small enough to stay put with duct tape, but big enough to be read from a distance. Binoculars are frequently used by calling-card number thieves to illegally obtain people's code numbers, thus enabling the thieves to make free long distance phone calls. You can do the same to read passwords off keyboards. It might be necessary to tilt the keyboard to a specific orientation to better enable you to see what is typed. If the key-boards have kickstands to prop them up, make sure you use them before you take your stalking posi-tion.
You might have to do your watching outside, through a window. Before you do, make sure you won't be visible to those inside. Even at night you will be easily seen through the glass if the building has outside lights. Do some detective work before hacking; go into the computer room and see how visible someone outside
the room would be. Per-haps you can partially close the blinds or drapes, to further shield yourself from view.
Figure 8
An example of a menu on a public computer. Tricks
can be used to breakfreefrom the menu, then either
alter the menu or the application programs
to collect private user data.
An example of a menu on a public computer. Tricks
can be used to breakfreefrom the menu, then either
alter the menu or the application programs
to collect private user data.
Finally, think about this. Perhaps you don't need any of this advice at all. Over the past two weeks, every day that I've visited a certain school's computer rooms, there was at least one instance where I would switch on a terminal and find it stuck inside somebody's account. Apparently the account owners didn't know that
shutting off the terminal does not log them out of their account. Occasionally I would find more than one terminal left in a logged-in state. It was a hacker's paradise!
shutting off the terminal does not log them out of their account. Occasionally I would find more than one terminal left in a logged-in state. It was a hacker's paradise!
Doing It The E-Z Way
Barry, a computer enthusiast from Las Vegas, Nevada, used a quite easy way of finding out info without any programming skills or special equipment. At the university Barry attended, there was a computer lab that had Macintoshs set up in the center of the room and terminals around the perimeter. He had his own account on the system, but he wanted to do some serious hacking. He knew if he tried anything logged in under his own name he might end up in trouble. All he needed was some measly low-level account from which he could hack without risk.
The public terminals at his school worked like this. Available commands or menus were dis-played on the screen with an underline of appropriate size placed at the bottom, where the user would input his choice. You could move around on the screen with arrow keys and type elsewhere, but when you pressed Send, only the
characters written in the space where the underline had been would be acknowledged.
Barry went to the main menu of the information system. He used the arrow keys and space bar to erase all the text on the screen, then proceeded to reproduce the login screen that was used to access the mainframe. At the bottom, he put the appropri-ate prompt...
ENTER NAME/PASS IN FORM nnnnnnnn,pppppppp
... and positioned the cursor at the beginning of the underline. He switched the Caps Lock key on, and he shut off all the other terminals. Then Barry took a seat at a Mac near his prepared terminal, and waited.
Everyone seemed to want to use a Mac that day. He had to wait more than an hour until a per-son finally came in to use a terminal. As Barry had hoped, that person walked straight for the one that was already powered-up. From Barry's position at the Mac he could easily see what the person typed in.
As you can imagine, when someone uses the ac-tual login screen, the computer covers up pass-words with asterisks. The woman who was using the terminal did not seem to realize that anything unusual was going on as she typed her vital data. When she pressed Send after her password, she got the usual beep of disapproval
(because she had pressed Send without entering anything in the space that was supposed to be used for commands, which Barry had erased). The computer redrew the information system main menu, and the woman, surprised, logged in again and went about her business.
Another computer user, who had sat down be-side her shortly after she entered the room com-mented, "They've been acting weird all day." Barry was elated; on his first try, with almost no effort on his part, he had a name and password and could do all the hacking he wanted to without having it being traced back to him. Plus, the bit of strange-ness he had caused was being blamed on unrelated system malfunctions.
There are many variations of this tactic that should also be considered, depending on the nature of the command system, the terminals used, layout of the room, etc. You will want to adjust your strat-egy accordingly.
Some terminals allow you to change screen color. I've worked a ploy similar to Barry's on one such terminal. First I erased the screen and typed up a fabrication of the login screen. But it wasn't an exact reproduction - I put my underline one line below where it normally would be.
I then moved the cursor over to the place on the screen where commands were supposed to be en-tered (above my fake underline). I used a color-change function key to make the characters I entered next appear in the same color as the background. I typed "log-on." It was black letters on a black background, so only I and the computer knew it was there.
Then I repositioned the cursor at the beginning of the underline, used the function key to change the text color back to bright white, and took a seat on a nearby armchair.
I didn't have to wait long. About twenty min-utes later a group of people came in, and one sat down at my terminal. Unfortunately, he saw the screen, thought someone else was using the termi-nal, and he got up to leave. I told him, "No, no one's using that one." So he reset the terminal and pro-ceeded to log onto a totally
different system!
A couple hours later I got luckier. I set up the terminal again and took my position on the chair, pretending to study a numerical analysis book. Af-ter a long while a guy sat down, typed in his name/password combination and pressed Enter. All this I was easily able to see.
But the computer couldn't see what he was typing because he hadn't entered it in the special input space. The computer only recognized my hidden (black-on-black) "logon". The computer then connected to the ungradx machine, and asked for the user's identity. The user, thinking he had made a typing mistake, entered them again. I was already out of there, as I had the information I needed. This will only work with systems that allow you to enter all login codes on a single line, or on machines with certain appropriate capabilities and setups.
Another way is to use a text editor to simulate the login screen. If you don't have an account on the system, and therefore do not have access to the e-mail text editor, there is probably a "Send Com-ments to Sysop" section in the public information system that you are able to access. You would probably want to use a
public editor anyway, to avoid having this evil-doing being traced back to your ID. One way of using a text editor to simulate the login screen is to write up a document such as this:
>login
Enter Name:
Enter Password:
Above this you may want to have the tail end of a commonly seen menu, list of commands, or a body of text one normally sees when turning on the terminal. You position the document so the last line vis-ible on the screen is "Enter Name:". You put the cursor right after the colon, and turn off the Insert key, if there is one.
A person sitting down at the terminal will think someone else before him typed in the "login" com-mand. He will type in his name and press Enter. Pressing Enter scrolls the document up a line, making it look as though the computer is asking him to enter a password, which he then does to your utter bliss, because you are sitting
there watching this unfold.
There are some problems with this method (and all these E-Z methods, actually). What if the first person to sit down doesn't want to log onto his ac-count? Or what if he makes a typing mistake which goes unnoticed until after he presses Enter? In both cases your little deviltry may be found out. There's always the possibility that
some guardian of the computer room will switch off any terminals he sees left on needlessly, and then all your work might be lost. Additionally, if you're doing this on a university terminal that has access to lots of differ-ent computers, there might not be a reasonable way to set up the screen.
There are plenty of things that can go wrong with this ruse, but for the small investment of time to set it up, then who-knows-how-long of waiting, it's worth it. If you try this, remember these tips: Do what you can to make reading the screen from a distance easier. Switch on the Caps Lock key if it helps. Brighten up the
screen if you're able. Tilt the moni-tor a bit to reduce glare from your viewing angle. And if possible, select large fonts. Before you choose your waiting spot, make sure that when a person sits down in the chair, his or her body won't be blocking your view. While you're waiting, keep yourself busy to avert suspicion, but
don't get so involved that you miss your quarry.
The public terminals at his school worked like this. Available commands or menus were dis-played on the screen with an underline of appropriate size placed at the bottom, where the user would input his choice. You could move around on the screen with arrow keys and type elsewhere, but when you pressed Send, only the
characters written in the space where the underline had been would be acknowledged.
Barry went to the main menu of the information system. He used the arrow keys and space bar to erase all the text on the screen, then proceeded to reproduce the login screen that was used to access the mainframe. At the bottom, he put the appropri-ate prompt...
ENTER NAME/PASS IN FORM nnnnnnnn,pppppppp
... and positioned the cursor at the beginning of the underline. He switched the Caps Lock key on, and he shut off all the other terminals. Then Barry took a seat at a Mac near his prepared terminal, and waited.
Everyone seemed to want to use a Mac that day. He had to wait more than an hour until a per-son finally came in to use a terminal. As Barry had hoped, that person walked straight for the one that was already powered-up. From Barry's position at the Mac he could easily see what the person typed in.
As you can imagine, when someone uses the ac-tual login screen, the computer covers up pass-words with asterisks. The woman who was using the terminal did not seem to realize that anything unusual was going on as she typed her vital data. When she pressed Send after her password, she got the usual beep of disapproval
(because she had pressed Send without entering anything in the space that was supposed to be used for commands, which Barry had erased). The computer redrew the information system main menu, and the woman, surprised, logged in again and went about her business.
Another computer user, who had sat down be-side her shortly after she entered the room com-mented, "They've been acting weird all day." Barry was elated; on his first try, with almost no effort on his part, he had a name and password and could do all the hacking he wanted to without having it being traced back to him. Plus, the bit of strange-ness he had caused was being blamed on unrelated system malfunctions.
There are many variations of this tactic that should also be considered, depending on the nature of the command system, the terminals used, layout of the room, etc. You will want to adjust your strat-egy accordingly.
Some terminals allow you to change screen color. I've worked a ploy similar to Barry's on one such terminal. First I erased the screen and typed up a fabrication of the login screen. But it wasn't an exact reproduction - I put my underline one line below where it normally would be.
I then moved the cursor over to the place on the screen where commands were supposed to be en-tered (above my fake underline). I used a color-change function key to make the characters I entered next appear in the same color as the background. I typed "log-on." It was black letters on a black background, so only I and the computer knew it was there.
Then I repositioned the cursor at the beginning of the underline, used the function key to change the text color back to bright white, and took a seat on a nearby armchair.
I didn't have to wait long. About twenty min-utes later a group of people came in, and one sat down at my terminal. Unfortunately, he saw the screen, thought someone else was using the termi-nal, and he got up to leave. I told him, "No, no one's using that one." So he reset the terminal and pro-ceeded to log onto a totally
different system!
A couple hours later I got luckier. I set up the terminal again and took my position on the chair, pretending to study a numerical analysis book. Af-ter a long while a guy sat down, typed in his name/password combination and pressed Enter. All this I was easily able to see.
But the computer couldn't see what he was typing because he hadn't entered it in the special input space. The computer only recognized my hidden (black-on-black) "logon". The computer then connected to the ungradx machine, and asked for the user's identity. The user, thinking he had made a typing mistake, entered them again. I was already out of there, as I had the information I needed. This will only work with systems that allow you to enter all login codes on a single line, or on machines with certain appropriate capabilities and setups.
Another way is to use a text editor to simulate the login screen. If you don't have an account on the system, and therefore do not have access to the e-mail text editor, there is probably a "Send Com-ments to Sysop" section in the public information system that you are able to access. You would probably want to use a
public editor anyway, to avoid having this evil-doing being traced back to your ID. One way of using a text editor to simulate the login screen is to write up a document such as this:
>login
Enter Name:
Enter Password:
Above this you may want to have the tail end of a commonly seen menu, list of commands, or a body of text one normally sees when turning on the terminal. You position the document so the last line vis-ible on the screen is "Enter Name:". You put the cursor right after the colon, and turn off the Insert key, if there is one.
A person sitting down at the terminal will think someone else before him typed in the "login" com-mand. He will type in his name and press Enter. Pressing Enter scrolls the document up a line, making it look as though the computer is asking him to enter a password, which he then does to your utter bliss, because you are sitting
there watching this unfold.
There are some problems with this method (and all these E-Z methods, actually). What if the first person to sit down doesn't want to log onto his ac-count? Or what if he makes a typing mistake which goes unnoticed until after he presses Enter? In both cases your little deviltry may be found out. There's always the possibility that
some guardian of the computer room will switch off any terminals he sees left on needlessly, and then all your work might be lost. Additionally, if you're doing this on a university terminal that has access to lots of differ-ent computers, there might not be a reasonable way to set up the screen.
There are plenty of things that can go wrong with this ruse, but for the small investment of time to set it up, then who-knows-how-long of waiting, it's worth it. If you try this, remember these tips: Do what you can to make reading the screen from a distance easier. Switch on the Caps Lock key if it helps. Brighten up the
screen if you're able. Tilt the moni-tor a bit to reduce glare from your viewing angle. And if possible, select large fonts. Before you choose your waiting spot, make sure that when a person sits down in the chair, his or her body won't be blocking your view. While you're waiting, keep yourself busy to avert suspicion, but
don't get so involved that you miss your quarry.
College PATs
There is also another kind of publicly accessible terminal, one easily found in the computer rooms of any college. These are different from the infor-mationdispensing ones found in libraries in that these are meant to be used solely by authorized us-ers - people with accounts and passwords on the system.
You should try the different function and con-trol keys on these terminals, too. This isn't likely to get you anywhere, but often you can use various control codes to access parameter menus or change screen colors.
Press ? or type HELP and see what commands are available to you. Most colleges run an infor-mation system, possibly connected with the library system, which gives you information on such things as student activities, phone numbers, office hours, campus news, and might also allow you to connect with other college information systems around the country, or possibly federal or state sys-tems. It should be a trivial matter to find out if a public information system is present on the system you're using, and if so, how to access it. If you don't know, call up the computing department and ask. (Remember to ask for the dial-in phone numbers, too!) Generally you will be able to use telnet or other networking protocols to connect with computers all over the campus, country, and possibly, the world. However to do so will more than likely require you to login as a registered user first. This section deals with some techniques hackers have used to un-cover passwords and lDs through the use of public access terminals at colleges.
Here's story #1.
You should try the different function and con-trol keys on these terminals, too. This isn't likely to get you anywhere, but often you can use various control codes to access parameter menus or change screen colors.
Press ? or type HELP and see what commands are available to you. Most colleges run an infor-mation system, possibly connected with the library system, which gives you information on such things as student activities, phone numbers, office hours, campus news, and might also allow you to connect with other college information systems around the country, or possibly federal or state sys-tems. It should be a trivial matter to find out if a public information system is present on the system you're using, and if so, how to access it. If you don't know, call up the computing department and ask. (Remember to ask for the dial-in phone numbers, too!) Generally you will be able to use telnet or other networking protocols to connect with computers all over the campus, country, and possibly, the world. However to do so will more than likely require you to login as a registered user first. This section deals with some techniques hackers have used to un-cover passwords and lDs through the use of public access terminals at colleges.
Here's story #1.
Hidden Commands
Whenever you're hacking any public terminal of this type you have to remember that it's common to have different levels of security for potential us-ers of the system. With each level, the various commands may or may not appear listed in the menu - although you may still be able to activate them via an inadequacy in the
program. If a menu is given with options ranging from one to four -try five! And six... and zero too. Always try Z, Q, X, and other "weird" letters - anything else that has a possibility of working. It may not be enough to try these unlisted commands just once; sometimes you can have the program display an error message once or twice, and then suddenly crash out of the system or enter private territory. I grant you, usu-ally you won't find that programs have been so badly coded as to allow misuse, but you'd be sur-prised at the number of bugs that do go unnoticed by the authors and testers. This is especially true of early program editions.
Also, remember this: There are many functions you may not think would be on a library computer (or whatever computer it is you're working on). There may be mnemonics used which, on your own, you would never think of trying. So you must therefore try everything you can. What I mean is, let's say a library's PATs allow you to enter these three-letter commands to do different things: INQ (to make an inquiry on a book), NEW (to get new user information), and PAT (patron information, to find out about yourself). Naturally the system doesn't only support those three commands. There are dozens of other commands that you simply don't know about.
Try things like CON, ILL, CHG, DIS and other three-letter combinations (or whatever number of characters is appropriate). On some systems, all commands are three characters except for one called NEW USER or RECALL or something. If that's the case, then you know the computer will support commands of more than
three characters. Consequently, you should try longer commands as well. The commands I've chosen above are abbre-viations for CONversion, InterLibrary Loan, CHarGe and DIScharge, respectively. Before I told you what ILL stood for, you may have been won-dering how the word "ILLness" or "I Love Lucy" could have anything to do with a library. But ILL happens to be a very commonly used abbreviation.
If you're trying to break into a system you know nothing about, it's more than likely they'll use codes and abbreviations that are related to their field. Consequently, ongoing research is a must.
One United Kingdom system uses things like LCO and LIN for Library Check Out and Library INquiry. Also, due to certain overseas privacy laws, staff members are not supposed to access patron accounts to see personal information like addresses and phone numbers, and what books are checked out to patrons. This poses an obvious problem to the librarians who MUST know how to contact people who refuse to return borrowed items (and for countless others reasons, must know what items people have borrowed), so the people who wrote this library program installed a command that is invisible to EVERYBODY - even library employ-ees. Pressing "X" at the book inquiry screen will ac-cess a patron inquiry mode. This is something that
the library staff obviously knows about and uses, but is not supposed to have even heard of.
Anyway, the point is this: dumb terminals often include exits to controlling programs. You can ac-cess these secret parts by either issuing an exit command (a "trap door") and entering a password, or by entering a hidden menu item or command statement. Access may also be unintentional and due to an error, as with a program that lets you in even though you are not situated at a valid terminal, or have not entered the password.
It is also advisable to turn off the terminal, wait ten seconds, then turn it on again to see what hap pens. Some terminals respond to various combina-tions of Ctrl, Shift, and Alt. (Sometimes Alt is la-beled "Compose Character" because if you keep it pressed down while typing out a number 0-255 on the numeric keypad on the right side of the key-board, the corresponding ASCII character will be produced.)
Also look at the function keys, and combina-tions of Shift, Ctrl, etc., with the function keys. Try various other control codes like Escape, Ctrl-C, Ctrl-X, Ctrl-Q, Ctrl-G, Ctrl-Break, etc. You can never tell what's going to do something, or if anything unusual will happen at all. But sometimes you can get pleasantly surprised.
program. If a menu is given with options ranging from one to four -try five! And six... and zero too. Always try Z, Q, X, and other "weird" letters - anything else that has a possibility of working. It may not be enough to try these unlisted commands just once; sometimes you can have the program display an error message once or twice, and then suddenly crash out of the system or enter private territory. I grant you, usu-ally you won't find that programs have been so badly coded as to allow misuse, but you'd be sur-prised at the number of bugs that do go unnoticed by the authors and testers. This is especially true of early program editions.
Also, remember this: There are many functions you may not think would be on a library computer (or whatever computer it is you're working on). There may be mnemonics used which, on your own, you would never think of trying. So you must therefore try everything you can. What I mean is, let's say a library's PATs allow you to enter these three-letter commands to do different things: INQ (to make an inquiry on a book), NEW (to get new user information), and PAT (patron information, to find out about yourself). Naturally the system doesn't only support those three commands. There are dozens of other commands that you simply don't know about.
Try things like CON, ILL, CHG, DIS and other three-letter combinations (or whatever number of characters is appropriate). On some systems, all commands are three characters except for one called NEW USER or RECALL or something. If that's the case, then you know the computer will support commands of more than
three characters. Consequently, you should try longer commands as well. The commands I've chosen above are abbre-viations for CONversion, InterLibrary Loan, CHarGe and DIScharge, respectively. Before I told you what ILL stood for, you may have been won-dering how the word "ILLness" or "I Love Lucy" could have anything to do with a library. But ILL happens to be a very commonly used abbreviation.
To fool the PAT into believing you are feeding it bar codes,first (a) remove the light
penfrom the computer.
Then (b) plug the jack into a receiver that is connected to your laptop via the
communication port.
You can then output bar codes through the comm port, straight into the PAT.
penfrom the computer.
Then (b) plug the jack into a receiver that is connected to your laptop via the
communication port.
You can then output bar codes through the comm port, straight into the PAT.
One United Kingdom system uses things like LCO and LIN for Library Check Out and Library INquiry. Also, due to certain overseas privacy laws, staff members are not supposed to access patron accounts to see personal information like addresses and phone numbers, and what books are checked out to patrons. This poses an obvious problem to the librarians who MUST know how to contact people who refuse to return borrowed items (and for countless others reasons, must know what items people have borrowed), so the people who wrote this library program installed a command that is invisible to EVERYBODY - even library employ-ees. Pressing "X" at the book inquiry screen will ac-cess a patron inquiry mode. This is something that
the library staff obviously knows about and uses, but is not supposed to have even heard of.
Anyway, the point is this: dumb terminals often include exits to controlling programs. You can ac-cess these secret parts by either issuing an exit command (a "trap door") and entering a password, or by entering a hidden menu item or command statement. Access may also be unintentional and due to an error, as with a program that lets you in even though you are not situated at a valid terminal, or have not entered the password.
It is also advisable to turn off the terminal, wait ten seconds, then turn it on again to see what hap pens. Some terminals respond to various combina-tions of Ctrl, Shift, and Alt. (Sometimes Alt is la-beled "Compose Character" because if you keep it pressed down while typing out a number 0-255 on the numeric keypad on the right side of the key-board, the corresponding ASCII character will be produced.)
Also look at the function keys, and combina-tions of Shift, Ctrl, etc., with the function keys. Try various other control codes like Escape, Ctrl-C, Ctrl-X, Ctrl-Q, Ctrl-G, Ctrl-Break, etc. You can never tell what's going to do something, or if anything unusual will happen at all. But sometimes you can get pleasantly surprised.
The Bar Code Hack
A certain academic library, close to my house, has dumb terminals and IBM compatible micros set up throughout the building for the public to use. The IBMs also have light pens attached. On those computers, patrons can access and change infor-mation about themselves, using the bar codes on their library cards for
security.
One fine day I decided I wanted to hack the sys-tern. I knew from random trying that BYE from the Main Menu brought me to a screen that asked for my bar code number. Naturally, I was not allowed staff access, so scanning my library card did noth-ing. I needed a staff card - preferably one with high access levels, like the library card of the li-brary director, or some supervisor or someone like that. I was not about to become a pickpocket to get a card. There was a better, more flexible, more hacker-like way of solving the problem. I would use computer technology to defeat the computer.
When you look at a bar code, you will generally see little numerals printed below the stripes. This is the number that the bar code is encoding. On a h-brary card (or the bar code put on library books), the number is about sixteen digits long. There is an initial grouping which identifies the bar code as belonging to that
particular library, followed by some zeros, and then a concluding seven or eight digits. This kind of numerical arrangement applies to your checkbook account number, and many other numbers used to identify you.
Now, the only part of the number that really matters is the last group of eight digits, following the zeros, since the library identification portion doesn't change from one person to the next. This meant that if I wanted to try a brute force entry of every bar code number until I found one with high access levels, I wouldn't have to try trillions and trillions of numbers - only a hundred million or SO.
Naturally I wouldn't be able to type in those bar code numbers from the keyboard (and who would want to, anyway?). You see, the computers do not allow people to walk over and type in bar code numbers. If they did, then anyone who knew anyone else's code number could easily access the pri-vate records of anyone else.
That meant, even if I found out the bar code nuniber of the library direc-tor, I still wouldn't be allowed into the backstage areas of the library program. I would still need the director's library card.
A way you might be able to get around this is to scan your bar code, and look at what happens. Did the computer put a carriage return at the end of the number? If not, see if you can back up and alter digits.
If a carriage return was added, try scanning your bar code again, this time sending a break or pause signal as soon as you do. You might be able to make the computer think it's receiving the entire bar code, although you will be able to change and add numbers to suit your needs. If you pushed con-trol-S to pause the bar code - and it worked - try pressing control-C and see if this stops it from reading in more digits from the scanner.
The bar code will be read in and placed on the screen rather quickly, so it may be difficult to stop it halfway through. If there's a printer attached to the computer, try sending output to it. This might slow down the bar code enough to let you break it at the right time. Also, if it is a computer you're working on (not just a terminal) there might be a "Turbo" button that you can press to take it out of turbo mode. If there is no button (but you know it's in turbo mode because there is a "Turbo" light lit up), there will be some way of disabling turbo mode through either the software (break into the DOS shell and see if there's a SPEED command
or something similar), or through the keyboard (often something like Ctrl-Alt-Minus sign will take it out of Turbo).
Another difficult thing to do is to try giving the scanner only a partial or erroneous code. Occa-sionally bar code readers can be duped into think-ing a bar code of a kind it's not supposed to be able to read is the correct type. Then it may read that code and stop halfway through, to wait for the rest of the input. Lastly, if there is a way of accessing terminal parameter menus, by all means do so:
often there is some sort of switch which toggles automatic send-ing of input, or the key code used to send input. By disabling the automatic send, you can manually input the bar-coded information.
All of these above suggestions imply that you have managed to get ahold of the bar code number of someone important in the library hierarchy -someone whose ID number you can use to access the rear end of the system. If you do happen to know the number, then you can try to print up a bar code for it, either by using bar code generating software, or by carefully examining bar codes until you have determined what thickness and pattern of lines are used to represent the different digits.
But I didn't have anyone's number. The pur-pose of my hack was tofind one. So I had to find a way of using the light pen to scan in a hundred million bar codes that I didn't have, until one was discovered that could access the library program's secret side.
I could've used a bar code program to print out all of those different combinations of digits but that would have been a huge waste of time and effort. The light pen (also known as a "wand," "bar code reader," or "scanner") works like this. Light is emitted from an LED inside the pen, focused through a sapphire sphere (which acts as a lens) onto the bar code. The light is then reflected off the page, and now focused through the sphere onto a photo-sensor, which converts the reflected light into bursts of voltage. The electrical output of the photo-sensor is amplified, thus generating a signal proportional to the series of black and white lines of the bar code label.
The pen is attached to the computer either via some external box, or an internal card. This box/card decodes the on-off firing pattern of the voltage into usable ASCII characters. At the time of decoding, voltage corresponding to white lines is approximately 0.11 volts, and 0 volts for the black lines. My plan was to send
voltages into the scan-ner, making it think it was reading a bar code, when really all it was doing was being victimized by a clever hacker's brute force attack.
If you are programming a computer or signal generator to create fake codes for you, some fidget-ing around might be necessary before you arrive at the correct numbers for that particular system. Also, the time it takes to generate a complete code will have to be adjusted accordingly: usually scan-ners will accept bar codes at
up to 45 inches per second. Perhaps you can manage to locate appro-priate technical manuals or some source code list-ings, or call up the company and ask to speak to a technician about what ideal values are for voltages and timing. If it is a computer you are working with, rather than a dumb terminal, it is possible the bar code decoding program is memory resident. You might be able to circumvent that program, or trick it into reading input from a disk file you supply. A good idea would be to copy the contents of the fixed drive, then at home see if there's a way of making the scanner decoder think the keyboard is the cor-rect RS232 serial interface to look at for input data.
Finally, remember that there will be a check digit at one end of the bar code, or both ends, al-though it will almost never be printed on the label itself. If the check digit is printed on the bar code label, study some sample bar codes and try to work out the method used to generate the check digit. You don't need to look at only bar codes on library cards - which you would probably have difficulty finding enough of - you can examine bar codes on books and come up with the same result.
For example, the check digit formula used by the Universal Product Code found on supermarket food packages is the following: 210 minus three times the sum of the alternating digits (starting with the separated digit to the left of the bar code), minus the sum of the remaining digits. The check digit is the last digit in your answer.
The UPC check digit formula is:
210 - 3 (a + c + e + g + i + k) - (b + d + f + h +j)
For this sample bar code, theformula is:
210 - 3 (O + 2 + 4 + 6 + 8 + 0) - (I + 3 + 5 + 7 + 9) = 125
The last digit of the answer is 5.
Thus 5 is the check digit.
Back to the target of my attack, that academic library near my home. The light pen at one of the computers was attached with a telephone-style modular clip. It could easily be removed. I bought a receiving jack of appropriate size and used a cable to connect it to the modem port of one of my smaller portable computers. Then I modified an auto-dialer program to spit out bar code numbers in the range I needed. I was all set.
A few days later it was Saturday, and it was a gorgeous day. I had expected to pull off this stunt on a Sunday because I'd seen the results of a user survey which indicated that less people came into that particular library on Sunday than any other day of the week - the last thing I needed was a bunch of onlookers. But it was such a beautiful day I figured everyone would be at the beach. I was right; practically no one was there.
I detached the light pen from the library's com-puter and connected the plug into my portable's jack. I typed BYE, which brought me to a prompt which asked for my bar code before it would allow me to go backstage. Then I started the program running. It worked fine - the program was send-ing bar code numbers through the
modem port and into the light pen cable. The library's computer had no way of knowing that the data it was receiving was not coming from an actual bar code. I closed the cover of my little portable, and hid the whole thing under a newspaper. Then I sat there and read a magazine while it went through the numbers. After a while I did find a bar code number as-sociated with a privileged account, and I was able to use it to change the status of my own library card to a virtual superuser.
That was great in and of itself, but having superuser status allowed me to go one step further. Since I now had access to patron records, I could find out the addresses, phone numbers, student 113s, social security numbers and birth dates of eve-ryone with a card at that library. This meant I had background information
on virtually every student at the school, and every professor and staff mem-ber. I could also find out what books were checked out to people, and therefore the subjects and hob-bies that interested them. Using all this information it was a simple task getting into many network accounts I should not have been able to get
into otherwise.
security.
One fine day I decided I wanted to hack the sys-tern. I knew from random trying that BYE from the Main Menu brought me to a screen that asked for my bar code number. Naturally, I was not allowed staff access, so scanning my library card did noth-ing. I needed a staff card - preferably one with high access levels, like the library card of the li-brary director, or some supervisor or someone like that. I was not about to become a pickpocket to get a card. There was a better, more flexible, more hacker-like way of solving the problem. I would use computer technology to defeat the computer.
When you look at a bar code, you will generally see little numerals printed below the stripes. This is the number that the bar code is encoding. On a h-brary card (or the bar code put on library books), the number is about sixteen digits long. There is an initial grouping which identifies the bar code as belonging to that
particular library, followed by some zeros, and then a concluding seven or eight digits. This kind of numerical arrangement applies to your checkbook account number, and many other numbers used to identify you.
Now, the only part of the number that really matters is the last group of eight digits, following the zeros, since the library identification portion doesn't change from one person to the next. This meant that if I wanted to try a brute force entry of every bar code number until I found one with high access levels, I wouldn't have to try trillions and trillions of numbers - only a hundred million or SO.
Naturally I wouldn't be able to type in those bar code numbers from the keyboard (and who would want to, anyway?). You see, the computers do not allow people to walk over and type in bar code numbers. If they did, then anyone who knew anyone else's code number could easily access the pri-vate records of anyone else.
That meant, even if I found out the bar code nuniber of the library direc-tor, I still wouldn't be allowed into the backstage areas of the library program. I would still need the director's library card.
A way you might be able to get around this is to scan your bar code, and look at what happens. Did the computer put a carriage return at the end of the number? If not, see if you can back up and alter digits.
If a carriage return was added, try scanning your bar code again, this time sending a break or pause signal as soon as you do. You might be able to make the computer think it's receiving the entire bar code, although you will be able to change and add numbers to suit your needs. If you pushed con-trol-S to pause the bar code - and it worked - try pressing control-C and see if this stops it from reading in more digits from the scanner.
The bar code will be read in and placed on the screen rather quickly, so it may be difficult to stop it halfway through. If there's a printer attached to the computer, try sending output to it. This might slow down the bar code enough to let you break it at the right time. Also, if it is a computer you're working on (not just a terminal) there might be a "Turbo" button that you can press to take it out of turbo mode. If there is no button (but you know it's in turbo mode because there is a "Turbo" light lit up), there will be some way of disabling turbo mode through either the software (break into the DOS shell and see if there's a SPEED command
or something similar), or through the keyboard (often something like Ctrl-Alt-Minus sign will take it out of Turbo).
Another difficult thing to do is to try giving the scanner only a partial or erroneous code. Occa-sionally bar code readers can be duped into think-ing a bar code of a kind it's not supposed to be able to read is the correct type. Then it may read that code and stop halfway through, to wait for the rest of the input. Lastly, if there is a way of accessing terminal parameter menus, by all means do so:
often there is some sort of switch which toggles automatic send-ing of input, or the key code used to send input. By disabling the automatic send, you can manually input the bar-coded information.
All of these above suggestions imply that you have managed to get ahold of the bar code number of someone important in the library hierarchy -someone whose ID number you can use to access the rear end of the system. If you do happen to know the number, then you can try to print up a bar code for it, either by using bar code generating software, or by carefully examining bar codes until you have determined what thickness and pattern of lines are used to represent the different digits.
But I didn't have anyone's number. The pur-pose of my hack was tofind one. So I had to find a way of using the light pen to scan in a hundred million bar codes that I didn't have, until one was discovered that could access the library program's secret side.
I could've used a bar code program to print out all of those different combinations of digits but that would have been a huge waste of time and effort. The light pen (also known as a "wand," "bar code reader," or "scanner") works like this. Light is emitted from an LED inside the pen, focused through a sapphire sphere (which acts as a lens) onto the bar code. The light is then reflected off the page, and now focused through the sphere onto a photo-sensor, which converts the reflected light into bursts of voltage. The electrical output of the photo-sensor is amplified, thus generating a signal proportional to the series of black and white lines of the bar code label.
The pen is attached to the computer either via some external box, or an internal card. This box/card decodes the on-off firing pattern of the voltage into usable ASCII characters. At the time of decoding, voltage corresponding to white lines is approximately 0.11 volts, and 0 volts for the black lines. My plan was to send
voltages into the scan-ner, making it think it was reading a bar code, when really all it was doing was being victimized by a clever hacker's brute force attack.
If you are programming a computer or signal generator to create fake codes for you, some fidget-ing around might be necessary before you arrive at the correct numbers for that particular system. Also, the time it takes to generate a complete code will have to be adjusted accordingly: usually scan-ners will accept bar codes at
up to 45 inches per second. Perhaps you can manage to locate appro-priate technical manuals or some source code list-ings, or call up the company and ask to speak to a technician about what ideal values are for voltages and timing. If it is a computer you are working with, rather than a dumb terminal, it is possible the bar code decoding program is memory resident. You might be able to circumvent that program, or trick it into reading input from a disk file you supply. A good idea would be to copy the contents of the fixed drive, then at home see if there's a way of making the scanner decoder think the keyboard is the cor-rect RS232 serial interface to look at for input data.
Finally, remember that there will be a check digit at one end of the bar code, or both ends, al-though it will almost never be printed on the label itself. If the check digit is printed on the bar code label, study some sample bar codes and try to work out the method used to generate the check digit. You don't need to look at only bar codes on library cards - which you would probably have difficulty finding enough of - you can examine bar codes on books and come up with the same result.
For example, the check digit formula used by the Universal Product Code found on supermarket food packages is the following: 210 minus three times the sum of the alternating digits (starting with the separated digit to the left of the bar code), minus the sum of the remaining digits. The check digit is the last digit in your answer.
Figure 6
The UPC check digit system. The initial digit may appear in either of the spots
marked with a 0. The subsequent digits are placed under the bar code, with the
check digit appearing in either of the two
places marked with a check mark.
The UPC check digit system. The initial digit may appear in either of the spots
marked with a 0. The subsequent digits are placed under the bar code, with the
check digit appearing in either of the two
places marked with a check mark.
The UPC check digit formula is:
210 - 3 (a + c + e + g + i + k) - (b + d + f + h +j)
For this sample bar code, theformula is:
210 - 3 (O + 2 + 4 + 6 + 8 + 0) - (I + 3 + 5 + 7 + 9) = 125
The last digit of the answer is 5.
Thus 5 is the check digit.
Back to the target of my attack, that academic library near my home. The light pen at one of the computers was attached with a telephone-style modular clip. It could easily be removed. I bought a receiving jack of appropriate size and used a cable to connect it to the modem port of one of my smaller portable computers. Then I modified an auto-dialer program to spit out bar code numbers in the range I needed. I was all set.
A few days later it was Saturday, and it was a gorgeous day. I had expected to pull off this stunt on a Sunday because I'd seen the results of a user survey which indicated that less people came into that particular library on Sunday than any other day of the week - the last thing I needed was a bunch of onlookers. But it was such a beautiful day I figured everyone would be at the beach. I was right; practically no one was there.
I detached the light pen from the library's com-puter and connected the plug into my portable's jack. I typed BYE, which brought me to a prompt which asked for my bar code before it would allow me to go backstage. Then I started the program running. It worked fine - the program was send-ing bar code numbers through the
modem port and into the light pen cable. The library's computer had no way of knowing that the data it was receiving was not coming from an actual bar code. I closed the cover of my little portable, and hid the whole thing under a newspaper. Then I sat there and read a magazine while it went through the numbers. After a while I did find a bar code number as-sociated with a privileged account, and I was able to use it to change the status of my own library card to a virtual superuser.
That was great in and of itself, but having superuser status allowed me to go one step further. Since I now had access to patron records, I could find out the addresses, phone numbers, student 113s, social security numbers and birth dates of eve-ryone with a card at that library. This meant I had background information
on virtually every student at the school, and every professor and staff mem-ber. I could also find out what books were checked out to people, and therefore the subjects and hob-bies that interested them. Using all this information it was a simple task getting into many network accounts I should not have been able to get
into otherwise.
Thursday, 1 December 2011
Public Access Terminals (PATs)
These are usually dumb terminals (although sometimes you see IBM compatibles) set up in fi-braries as electronic card catalogs. They have names like MS and GEAC. These systems allow h-brary patrons to search for materials (books, magazines, videos) by various search restrictions; to see the current status of materials (On the shelf? Charged out? Overdue? Missing?); place holds on items; get library news, and other library-related functions. Often dial-in lines are available, especially at university libraries.
The challenge to the hacker is this: He knows there is a secret side to every library computer. How can he get into it?
Every library computer system is divided into two parts. There is the publiclyaccessible catalog, and the private stuff. The private stuff (the secret side) includes procedures to discharge materials, get confidential patron information, add or alter fines, block library cards, etc. These private func-tions, used by library staff, must rely on the same database of information as is found on the PATs. (If the librarian checks out a book to somebody, the fact that the book is not present in the library must be shown on the public terminals.) Therefore, the functions that are available to the public are a sub-set of the entire library program. That is, the pro-gram the public uses to make inquiries on books is part of a larger program which includes higher managerial functions.
The two program parts are obviously separated, otherwise anyone could walk into the library and erase all the fines off their library card, or put $100 worth of lost items on an enemy's card. So, how is the public side separated from the private side? Take a guess.
Yup, a password.
Actually, it's usually a combination of two things: first, a hidden menu command, and then the password to authorize usage. Go to the main or earliest menu on the library system and try various commands like BYE, END, EXIT, X, XXX, SYS, SYSTEM, LATER, and OFF. Usually this kind of system will accept either threecharacter corn-mands or single-character commands, but of course things vary widely as you go from one system to another, so vary your tactics accordingly. If some-thing like BYE works, and you are exited from the public portion of the system, you will probably be asked to supply a password. Well, you know how to get passwords! On the other hand, it may not ask for a password at all...
Several library systems use bar code identifica-tion to detern-dne who gets to go backstage. If your library card has a bar code on it, then it is possible - but not certain - that achieving system operator status relies not on uncovering a password, but finding out some sequence of little black stripes. I have a story about this.
The challenge to the hacker is this: He knows there is a secret side to every library computer. How can he get into it?
Every library computer system is divided into two parts. There is the publiclyaccessible catalog, and the private stuff. The private stuff (the secret side) includes procedures to discharge materials, get confidential patron information, add or alter fines, block library cards, etc. These private func-tions, used by library staff, must rely on the same database of information as is found on the PATs. (If the librarian checks out a book to somebody, the fact that the book is not present in the library must be shown on the public terminals.) Therefore, the functions that are available to the public are a sub-set of the entire library program. That is, the pro-gram the public uses to make inquiries on books is part of a larger program which includes higher managerial functions.
The two program parts are obviously separated, otherwise anyone could walk into the library and erase all the fines off their library card, or put $100 worth of lost items on an enemy's card. So, how is the public side separated from the private side? Take a guess.
Yup, a password.
Actually, it's usually a combination of two things: first, a hidden menu command, and then the password to authorize usage. Go to the main or earliest menu on the library system and try various commands like BYE, END, EXIT, X, XXX, SYS, SYSTEM, LATER, and OFF. Usually this kind of system will accept either threecharacter corn-mands or single-character commands, but of course things vary widely as you go from one system to another, so vary your tactics accordingly. If some-thing like BYE works, and you are exited from the public portion of the system, you will probably be asked to supply a password. Well, you know how to get passwords! On the other hand, it may not ask for a password at all...
Several library systems use bar code identifica-tion to detern-dne who gets to go backstage. If your library card has a bar code on it, then it is possible - but not certain - that achieving system operator status relies not on uncovering a password, but finding out some sequence of little black stripes. I have a story about this.
CD-ROM Databases And Information Computers
CD-ROM databases, like InfoTrac and News-Net, are computerized listings of periodical articles, updated monthly. Other databases are available with slants toward business news, census data and the like. Some libraries have CD-ROM encyclope-dias, and many government depository libraries will have databases
listing government publica-tions available.
In a similar vein, I've seen libraries with com-puters (usually Macintoshes) set up with user-friendly programs designed to teach patrons how to use the library and to dispense other helpful advice. All of these computers are useful to the hacker only for the information they carry, due to the fact that they are set up on independent
ma-chines, without modems, and without access to telephone lines. They usually serve the single pur-pose of dispensing information on their specific topic.
Finally - this is rare and a bit odd - but occa-sionally you will see a computer being used as a register". As people walk into the computer room, office, or wherever, they sign into the computer with a name and ID number, and perhaps answer a few questions about themselves. The purpose of this sort of computer setup is to keep a timed and dated record of who uses the public facilities. Of course, unless a light pen or graphics tablet is used, signatures can not be collected and so their use for security purposes is lost.
Unlike databases and tutorials, there is a bit more you can do hacker-wise with a guest record computer, though not much more. One application might be to use the computer to see who else has been using the facilities. This information could be helpful if the facility in question is a computer room. You might be able to find exploitable patterns in computer usage by certain individuals, or an overall tendency for less people to be in the room at certain times, both of which are helpful to know, as we will see.
If the guest register program itself doesn't let you see who was there before you, try exiting out to the operating system and checking for relevant data files. This will be discussed in the upcoming section on general-purpose micros.
Access to CD-ROM databases and information computers is not usually of much use to the hacker. There are exceptions of course, and it's well worth investigating any computer of this kind that you find.
listing government publica-tions available.
In a similar vein, I've seen libraries with com-puters (usually Macintoshes) set up with user-friendly programs designed to teach patrons how to use the library and to dispense other helpful advice. All of these computers are useful to the hacker only for the information they carry, due to the fact that they are set up on independent
ma-chines, without modems, and without access to telephone lines. They usually serve the single pur-pose of dispensing information on their specific topic.
Finally - this is rare and a bit odd - but occa-sionally you will see a computer being used as a register". As people walk into the computer room, office, or wherever, they sign into the computer with a name and ID number, and perhaps answer a few questions about themselves. The purpose of this sort of computer setup is to keep a timed and dated record of who uses the public facilities. Of course, unless a light pen or graphics tablet is used, signatures can not be collected and so their use for security purposes is lost.
Unlike databases and tutorials, there is a bit more you can do hacker-wise with a guest record computer, though not much more. One application might be to use the computer to see who else has been using the facilities. This information could be helpful if the facility in question is a computer room. You might be able to find exploitable patterns in computer usage by certain individuals, or an overall tendency for less people to be in the room at certain times, both of which are helpful to know, as we will see.
If the guest register program itself doesn't let you see who was there before you, try exiting out to the operating system and checking for relevant data files. This will be discussed in the upcoming section on general-purpose micros.
Access to CD-ROM databases and information computers is not usually of much use to the hacker. There are exceptions of course, and it's well worth investigating any computer of this kind that you find.
Public Access Computers And Terminals
Introduction To The Three Kinds
Have you been to a mall lately? I mean one of those huge, sprawling malls that not only have clothing stores, electronics shops and food courts, but miniature golf courses, arcades, banks, post of-fices, and anything else you can or can not think of?
Instead of the large "You are here - >` maps they used to have, you now often find computers set up with touch-sensitive screens that help you find your way around the mall and inform you about mall happenings.
Personally, I've never hacked a mall computer - but the potential is there - and the motivation to do so is there as well. Hackers hack because they are in love with the idea that any accessible com-puter has a secret side that can be broken into. The computers at the mall have a secret side - the gen-eral public is not supposed to be able to change around the names of the stores on the computer-ized map of the building - but there is a way of doing just that. Similarly, when you go to Ellis Island and look up your ancestors in the computers, there is obviously some rear end to the system that you are not being allowed to see. All public computers have a secret side. A hacker is a person who wants to get at it.
This chapter addresses two aspects of publicly accessible computers:
• How to get into the behind-the-scenes parts, and
• using public computers to collect information you're not supposed to know about the people who use
them.
The computers and dumb terminals that are publicly available are a great boon to anyone inter-ested in hacking. Even if a general-access computer doesn't have a modem hanging off the back, or does not allow out-dialing, hackers can benefit by using the computer to gather information about legitimate users of on-line
databases, school net-works and other computing systems.
Computers are publicly available in lots of places - lobbies of office buildings, malls, muse-ums, airport club lounges, public fax machines, public and private schools, and in stores. However, the place they are most often seen is at libraries; consequently, the following discussion is based mostly on the computers found
there. Computers for the use of the general public are available now at most public and academic librar-ies. They fall into three groups:
• CD-ROM databases and information computers,
• public access terminals, and
• general purpose microcomputers.
Let's look at each one of these in turn, and see how these can help the hacker help
himself.
Subscribe to:
Posts (Atom)