CHAPTER 6

Hackers' Techniques

The time has now come to sit at the keyboard, phone and modems at

the ready, relevant research materials convenient to hand and see

what you can access. In keeping with the 'handbook' nature of this

publication, I have put my most solid advice in the form of a

trouble-shooting appendix (I), so this chapter talks around the

techniques rather than spelling them out in great detail.

Hunting instincts Good hacking, like birdwatching and many other

pursuits, depends ultimately on raising your intellectual knowledge

almost to instinctive levels. The novice twitcher will, on being told

'There's a kingfisher!', roam all over the skies looking for the

little bird and probably miss it. The experienced ornithologist will

immediately look low over a patch of water, possibly a section shaded

by trees, because kingfishers are known to gulp the sort of flies

that hover over streams and ponds. Similarly, a good deal of skilful

hacking depends on knowing what to expect and how to react. The

instinct takes time to grow, but the first step is understanding that

you need to develop it in the first place.

Tricks with phones

If you don't have a complete phone number for a target computer,

then you can get an auto-dialler and a little utility program to

locate it for you. You will find a flow-chart for a program in

Appendix VII. An examination of the phone numbers in the vicinity of

the target machine should give you a range within which to search.

The program then accesses the auto-dial mechanism of the modem and

'listens' for any whistles. The program should enable the phone line

to be disconnected after two or three 'rings' as auto-anSwer modems

have usually picked up by then.

Such programs and their associated hardware are a little more

Complicated than the popularised portrayals suggest: you must have

software to run sequences of calls through your auto-dialler, the

hardware must tell you whether you have scored a 'hit' with a modem

or merely dialled a human being, and, since the whole point of the

exercise is that it works unattended, the process must generate a

list of numbers to try.

** Page 57

Logging on

You dial up, hear a whistle...and the VDU stays blank. What's gone

wrong? Assuming your equipment is not at fault, the answer must lie

either in wrong speed setting or wrong assumed protocol. Experienced

hackers listen to a whistle from an unknown computer before throwing

the data button on the modem or plunging the phone handset into the

rubber cups of an acoustic coupler. Different tones indicate

different speeds and the trained ear can easily detect the

difference--appendix III gives the common variants.

Some modems, particularly those on mainframes, can operate at more

than one speed; the user sets it by sending the appropriate number of

carriage returns. In a typical situation, the mainframe answers at

110 baud (for teletypewriters), and two carriage returns take it up

to 300 baud, the normal default for asynchronous working.

Some hosts will not respond until they receive a character from

the user. Try sending a space or a carriage return.

If these obvious things don't work and you continue to get no

response, try altering the protocol settings (see chapters 2 and 3).

Straightforward asynchronous protocols with 7-bit ASCII, odd or even

parity and surrounded by one stop and one start bit is the norm, but

almost any variant is possible.

Once you start getting a stream from the host, you must evaluate

it to work out what to do next. Are all the lines over-writing each

other and not scrolling down the screen? Get your terminal software

to insert carriage returns. Are you getting a lot of corruption?

Check your phone connections and your protocols. The more familiar

you are with your terminal software at this point, the more rapidly

you will get results.

Passwords

Everyone thinks they know how to invent plausible and acceptable

passwords; here are the ones that seem to come up over and over

again:

HELP - TEST - TESTER - SYSTEM - SYSTEM - MANAGER - SYSMAN - SYSOP -

ENGINEER - OPS - OPERATIONS - CENTRAL - DEMO - DEMONSTRATION - AID -

DISPLAY - CALL - TERMINAL - EXTERNAL - REMOTE - CHECK - NET - NETWORK

- PHONE - FRED

** Page 58

Are you puzzled by the special inclusion of FRED? Look at your

computer keyboard sometime and see how easily the one-fingered typist

can find those four letters!

If you know of individuals likely to have legitimate access to a

system, find out what you can about them to see if you can

second-guess their choice of personal password. Own names, or those

of loved ones, or initials are the top favourites. Sometimes there is

some slight anagramming and other forms of obvious jumbling. If the

password is numeric, the obvious things to try are birthdays, home

phone numbers, vehicle numbers, bank account numbers (as displayed on

cheques) and so on.

Sometimes numeric passwords are even easier to guess: I have found

myself system manager of a private viewdata system simply by offering

it the password 1234567890 and other hackers have been astonished at

the results obtained from 11111111, 22222222 etc or 1010101, 2020202.

It is a good idea to see if you can work on the mentality and known

pre-occupations of the legitimate password holder: if he's keen on

classic rock'n'roll, you could try ELVIS; a gardener might choose

CLEMATIS; Tolkien readers almost invariably select FRODO or BILBO;

those who read Greek and Roman Literature at ancient universities

often assume that no one would ever guess a password like EURIPIDES;

it is a definitive rule that radio amateurs never use anything other

than their call-signs.

Military users like words like FEARLESS and VALIANT or TOPDOG;

universities, large companies and public corporations whose various

departments are known by acronyms (like the BBC) can find those

initials reappearing as passwords.

One less-publicised trick is to track down the name of the top

person in the organisation and guess a computer identity for them;

the hypothesis is that they were invited to try the computer when it

was first opened and were given an 'easy' password which has neither

been used since nor wiped from the user files. A related trick is to

identify passwords associated with the hardware or software

installer; usually the first job of a system manager on taking over a

computer is to remove such IDs, but often they neglect to do so.

Alternatively, a service engineer may have a permanent ID so that, if

the system falls over, it can be returned to full activity with the

minimum delay.

Nowadays there is little difficulty in devising theoretically

secure password systems, and bolstering them by allowing each user

only three false attempts before the disconnecting the line, as

Prestel does, for example. The real difficulty lies in getting humans

to follow the appropriate procedures. Most of us can only hold a

limited quantity of character and number sequences reliably in our

heads.

** Page 59

Make a log-on sequence too complicated, and users will feel compelled

to write little notes to themselves, even if expressly forbidden to

do so. After a while the complicated process becomes

counter-productive. I have a encrypting/decrypting software pack- age

for the IBM PC. It is undoubtedly many times more secure than the

famous Enigma codes of World War II and after. The trouble is that

that you need up to 25 different 14-digit numbers of your

specification, which you and your correspondent must share if

successful recovery of the original text is to take place.

Unfortunately the most convenient way to store these sequences is

in a separate disk file (get one character wrong and decryption is

impossible) and it is all too easy to save the key file either with

the enciphered stream, or with the software master, in both of which

locations they are vulnerable.

Nowadays many ordinary users of remote computer services use

terminal emulator software to store their passwords. It is all too

easy for the hacker to make a quick copy of a 'proper' user's disk,

take it away, and then examine the contents of the various log-on

files--usually by going into an 'amend password' option. The way for

the legitimate user to obtain protection, other than the obvious one

of keeping such disks secure, is to have the terminal software itself

password protected, and all files encrypted until the correct

password is input. But then that new password has to be committed to

the owner's memory....

Passwords can also be embedded in the firmware of a terminal.

This is the approach used in many Prestel viewdata sets when the user

can, sometimes with the help of the Prestel computer, program his or

her set into an EAROM (Electrically Alterable Read Only Memory). If,

in the case of Prestel, the entire 14-digit sequence is permanently

programmed in the set, that identity (and the user bill associated

with it) is vulnerable to the first person who hits the 'viewdata'

button on the keypad. Most users only program in the first 10 digits

and key in the last four manually. A skilful hacker can make a

terminal disgorge its programmed ID by sticking a modem in

answer-mode on its back (reversing tones and, in the case of

viewdata, speeds also) and sending the ASCII ENQ (ctrl-E) character,

which will often cause the user's terminal to send its identity.

A more devious trick with a conventional terminal is to write a

little program which overlays the usual sign-on sequence. The program

captures the password as it is tapped out by the legitimate user and

saves it to a file where the hacker can retrieve it later.

** Page 60

People reuse their passwords. The chances are that, if you obtain

someone's password on one system, the same one will appear on another

system to which that individual also has access.

Programming tricks

In most longish magazine articles about electronic crime, the

writer includes a list of 'techniques' with names like Salami, Trap

Door and Trojan Horse. Most of these are not applicable to pure

hacking, but refer to activities carried out by programmers

interested in fraud.

The Salami technique, for example, consists of extracting tiny

sums of money from a large number of bank accounts and dumping the

proceeds into an account owned by the frauds man. Typically there's

an algorithm which monitors deposits which have as their last digit

'8'; it then deducts '1' from that and then £1 or $1 is siphoned off.

The Trojan Horse is a more generalised technique which consists of

hiding away a bit of unorthodox active code in a standard legitimate

routine. The code could, for example, call a special larger routine

under certain conditions and that routine could carry out a rapid

fraud before wiping itself out and disappearing from the system for

good.

The Trap Door is perhaps the only one of these techniques that

pure hackers use. A typical case is when a hacker enters a system

with a legitimate identity but is able to access and alter the user

files. The hacker than creates a new identity with extra privileges

to roam over the system, and is thus able to enter it at any time as

a 'super-user' or 'system manager'.

Hardware tricks

For the hacker with some knowledge of computer hardware and

general electronics, and who is prepared to mess about with circuit

diagrams, a soldering iron and perhaps a voltmeter, logic probe or

oscilloscope, still further possibilities open up. One of the most

useful bits of kit consists of a small cheap radio receiver (MW/AM

band), a microphone and a tape recorder. Radios in the vicinity of

computers, modems and telephone lines can readily pick up the chirp

chirp of digital communications without the need of carrying out a

physical phone 'tap'.

Alternatively, an inductive loop with a small low-gain amplifier in

the vicinity of a telephone or line will give you a recording you can

analyse later at your leisure.

** Page 61

By identifying the pairs of tones being used, you can separate the

caller and the host. By feeding the recorded tones onto an

oscilloscope display you can freeze bits, 'characters' and 'words';

you can strip off the start and stop bits and, with the aid of an

ASCII-to-binary table, examine what is happening. With experience it

is entirely possible to identify a wide range of protocols simply

from the 'look' of an oscilloscope. A cruder technique is simply to

record and playback sign-on sequences; the limitation is that, even

if you manage to log on, you may not know what to do afterwards.

Listening on phone lines is of course a technique also used by

some sophisticated robbers. In 1982 the Lloyds Bank Holborn branch

was raided; the alarm did not ring because the thieves had previously

recorded the 'all-clear' signal from the phone line and then, during

the break-in, stuffed the recording up the line to the alarm

monitoring apparatus.

Sometimes the hacker must devise ad hoc bits of hardware trickery

in order to achieve his ends. Access has been obtained to a

well-known financial prices service largely by stringing together a

series of simple hardware skills. The service is available mostly on

leased lines, as the normal vagaries of dial-up would be too

unreliable for the City folk who are the principal customers.

However, each terminal also has an associated dial-up facility, in

case the leased line should go down; and in addition, the same

terminals can have access to Prestel. Thus the hacker thought that it

should be possible to access the service with ordinary viewdata

equipment instead of the special units supplied along with the annual

subscription. Obtaining the phone number was relatively easy: it was

simply a matter of selecting manual dial-up from the appropriate

menu, and listening to the pulses as they went through the regular

phone.

The next step was to obtain a password. The owners of the terminal

to which the hacker had access did not know their ID; they had no

need to know it because it was programmed into the terminal and sent

automatically. The hacker could have put a micro 'back-to-front'

across the line and sent a ENQ to see if an ID would be sent back.

Instead he tried something less obvious.

The terminal was known to be programmable, provided one knew how

and had the right type of keyboard. Engineers belonging to the

service had been seen doing just that. How could the hacker acquire

'engineer' status? He produced the following hypothesis: the keyboard

used by the service's customers was a simple affair, lacking many of

the obvious keys used by normal terminals; the terminal itself was

manufactured by the same company that produced a range of editing

terminals for viewdata operators and publishers. Perhaps if one

obtained a manual for the editing terminal, important clues might

appear. A suitable photocopy was obtained and, lo and behold, there

were instructions for altering terminal IDs, setting auto-diallers

and so on.

** Page 62

Now to obtain a suitable keyboard. Perhaps a viewdata editing

keyboard or a general purpose ASCII keyboard with switchable baud

rates? So far, no hardware difficulties. An examination of the back

of the terminal revealed that the supplied keypads used rather

unusual connectors, not the 270° 6-pin DIN which is the Prestel

standard. The hacker looked in another of his old files and

discovered some literature relating to viewdata terminals. Now he

knew what sort of things to expect from the strange socket at the

back of the special terminal: he pushed in an unterminated plug and

proceeded to test the free leads with a volt-meter against what he

expected; eight minutes and some cursing later he had it worked out;

five minutes after that he had built himself a little patch cord

between an ASCII keyboard, set initially to 75 baud and then to 1200

baud as the most likely speeds; one minute later he found the

terminal was responding as he had hoped...

Now to see if there were similarities between the programming

commands in the equipment for which he had a manual and the equipment

he wished to hack. Indeed there were: on the screen before him was

the menu and ID and phone data he had hoped to see. The final test

was to move over to a conventional Prestel set, dial up the number

for the financial service and send the ID.

The hacker himself was remarkably uninterested in the financial

world and, after describing to me how he worked his trick, has now

gone in search of other targets.

Operating Systems

The majority of simple home micros operate only in two modes--

Basic or machine code. Nearly all computers of a size greater than

this use operating systems which are essentially housekeeping

routines and which tell the processor where to expect instructions

from, how to identify and manipulate both active and stored memory,

how to keep track of drives and serial ports (and Joy-sticks and

mice), how to accept data from a keyboard and locate it on a screen,

how to dump results to screen or printer or disc drive, and so on.

Familiar micro-based operating systems lnclude CP/M, MS-DOS, CP/M-86

and so on, but more advanced operating systems have more

facilities--capacity to allow several users all accessing the same

data and programs without colliding with each other, enlarged

standard utilities to make fast file creation, fast sorting and fast

calculation much easier. Under Simple operating systems, the

programmer has comparatively few tools to help him; often there is

just the Basic language, which elf contains no standard

procedures--almost everything must be written from scratch each time.

** Page 63

But most computer programs rely, in essence, on a small set of

standard modules: forms to accept data to a program, files to keep

the data in, calculations to transform that data, techniques to sort

the data, forms to present the data to the user upon demand, the

ability to present results in various graphics, and so on. So

programs written under more advanced operating systems tend to be

comparatively briefer for the same end-result than those with Basic

acting not only as a language, but also as the computer's

housekeeper.

When you enter a mainframe computer as an ordinary customer, you

will almost certainly be located in an applications program, perhaps

with the capacity to call up a limited range of other applications

programs, whilst staying in the one which has logged you on as user

and is watching your connect-time and central processor usage.

One of the immediate aims of a serious hacker is to get out of

this environment and see what other facilities might be located on

the mainframe. For example, if access can be had to the user-log it

becomes possible for the hacker to create a whole new status for

himself, as a system manager, engineer, whatever. The new status,

together with a unique new password, can have all sorts o f

privileges not granted to ordinary users. The hacker, having acquired

the new status, logs out in his original identity and then logs back

with his new one.

There is no single way to break out of an applications program

into the operating system environment; people who do so seldom manage

it by chance: they tend to have had some experience of a similar

mainframe. One of the corny ways is to issue a BREAK or ctrl-C

command and see what happens; but most applications programs

concerned with logging users on to systems tend to filter out

'disturbing' commands of that sort. Sometimes it easier to go beyond

the logging-in program into an another 'authorised' program and try

to crash out of that. The usual evidence for success is that the

nature of the prompts will change. Thus, on a well-known mini family

OS, the usual user prompt is

COMMAND ?

or simply

>

** Page 64

Once you have crashed out the prompt may change to a simple

.

or

*

or even

:

it all depends.

To establish where you are in the system, you should ask for a

directory; DIR or its obvious variants often give results. Directories

may be hierarchical, as in MS-DOS version 2 and above, so that at

the bottom level you simply get directories of other directories.

Unix machines are very likely to exhibit this trait. And once you get

a list of files and programs...well, that's where the exploration

really begins.

In 1982, two Los Angeles hackers, still in their teens, devised

one of the most sensational hacks so far, running all over the

Pentagon's ARPA data exchange network. ARPAnet was and is the

definitive packet-switched network (more about these in the next

chapter). It has been running for twenty years, cost more than $500m

and links together over 300 computers across the United States and

beyond. Reputedly it has 5,000 legitimate customers, among them

NORAD, North American Air Defence Headquarters at Omaha, Nebraska.

Ron Austin and Kevin Poulsen were determined to explore it.

Their weapons were an old TRS-80 and a VIC-20, nothing

complicated, and their first attempts relied on password-guessing.

The fourth try, 'UCB', the obvious initials of the University of

California at Berkeley, got them in. The password in fact was little

used by its legitimate owner and in the end, it was to be their

downfall.

Aspects of ARPAnet have been extensively written up in the

text-books simply because it has so many features which were first

tried there and have since become 'standard' on all data networks.

From the bookshop at UCLA, the hackers purchased the manual for UNIX,

the multi-tasking, multi-user operating system devised by Bell

Laboratories, the experimental arm of AT&T, the USA's biggest

telephone company.

** Page 65

At the heart of Unix is a small kernel containing system primitives;

Unix instructions are enclosed in a series of shells, and very

complicated procedures can be called in a small number of text lines

simply by defining a few pipes linking shells. Unix also contains a

large library of routines which are what you tend to find inside the

shells. Directories of files are arranged in a tree-like fashion,

with master or root directories leading to other directories, and so

on.

Ron and Kevin needed to become system 'super-users' with extra

privileges, if they were to explore the system properly; 'UCB' was

merely an ordinary user. Armed with their knowledge of Unix, they set

out to find the files containing legitimate users' passwords and

names. Associated with each password was a Unix shell which defined

the level of privilege. Ron wrote a routine which captured the

privilege shell associated with a known super-user at the point when

that user signed on and then dumped it into the shell associated with

a little-used identity they had decided to adopt for their own

explorations. They became 'Jim Miller'; the original super-user lost

his network status. Other IDs were added. Captured privilege shells

were hidden away in a small computer called Shasta at Stanford, at

the heart of California's Silicon Valley.

Ron and Kevin were now super-users. They dropped into SRI,

Stanford Research Institute, one of the world's great centres of

scientific research; into the Rand Corporation, known equally for its

extensive futurological forecasting and its 'thinking about the

unthinkable', the processes of escalation to nuclear war; into the

National Research Laboratory in Washington; into two private research

firms back in California and two defence contractors on the East

Coast; and across the Atlantic to the Norwegian Telecommunications

Agency which, among other things, is widely believed to have a

special role in watching Soviet Baltic activity. And, of course,

NORAD.

Their running about had not gone unnoticed; ARPAnet and its

constituent computers keep logs of activity as one form of security

(see the section below) and officials both at UCLA (where they were

puzzled to see an upsurge in activity by 'UCB') and in one of the

defence contractors sounded an alarm. The KGB were suspected, the FBI

alerted.

One person asked to act as sleuth was Brian Reid, a professor of

electrical engineering at Stanford. He and his associates set up a

series of system trips inside a Unix shell to notify them when

certain IDs entered an ARPAnet computer. His first results seemed to

indicate that the source of the hacking was Purdue, Indiana, but the

strange IDs seemed to enter ARPAnet from all over the place.

** Page 66

Eventually, his researches lead him to the Shasta computer and he had

identified 'Miller' as the identity he had to nail. He closed off

entry to Shasta from ARPanet. 'Miller' reappeared; apparently via a

gateway from another Stanford computer, Navajo. Reid, who in his

sleuthing role had extremely high privileges, sought to wipe 'Miller'

out of Navajo. A few minutes after 'Miller' had vanished from his

screen, he re- appeared from yet another local computer, Diablo. The

concentration of hacking effort in the Stanford area lead Reid to

suppose that the origin of the trouble was local. The most effective

way to catch the miscreant was by telephone trace. Accordingly, he

prepared some tantalising, apparently private, files. This was bait,

designed to keep 'Miller' online as long as possible while the FBI

organised a telephone trace. 'Miller' duly appeared, the FBI went

into action--and arrested an innocent businessman.

But back at UCLA they were still puzzling about 'UCB'. In one of

his earliest sessions, Ron had answered a registration questionnaire

with his own address, and things began to fall into place. In one of

his last computer 'chats' before arrest, Kevin, then only 17 and only

beginning to think that he and his friend might have someone on their

trail, is supposed to have signed off: 'Got to go now, the FBI is

knocking at my door.' A few hours later, that is exactly what

happened.

Computer Security Methods

Hackers have to be aware of the hazards of being caught: there is

now a new profession of computer security experts, and they have had

some successes. The first thing such consultants do is to attempt to

divide responsibility within a computer establishment as much as

possible. Only operators are allowed physical access to the

installation, only programmers can use the operating system (and

under some of these, such as VM, maybe only part of it.). Only system

managers are permitted to validate passwords, and only the various

classes of users are given access to the appropriate applications

programs.

Next, if the operating system permits (it usually does), all

accesses are logged; surveillance programs carry out an audit, which

gives a historic record, and also, sometimes, perform monitoring,

which is real-time surveillance.

In addition, separate programs may be in existence the sole

purpose of which is threat monitoring: they test the system to see if

anyone is trying repeatedly to log on without apparent success (say

by using a program to try out various likely passwords).

** Page 67

They assess if any one port or terminal is getting more than usual

usage, or if IDs other than a regular small list start using a

particular terminal--as when a hacker obtains a legitimate ID but one

that normally operates from only one terminal within close proximity

to the main installation, whereas the hacker is calling from outside.

Increasingly, in newer mainframe installations, security is built

into the operating system at hardware level. In older models this was

not done, partly because the need was not perceived, but also because

each such 'unnecessary' hardware call tended to slow the whole

machine down. (If a computer must encrypt and decrypt every process

before it is executed, regular calculations and data accesses take

much longer.) However, the largest manufacturers now seem to have

found viable solutions for this problem....