The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 9 Issue 13

Friday 18 August 1989


o Phony IRS refunds by computer
Rob Gross
o Cellular phones in stings
David Wittenberg
o Aircrew acceptance of flight automation
Robert Dorsett
o Unauthorized Internet activity
CERT Internet Advisory -- Kenneth R. van Wyk
o Re: Marijuana virus wreaks havoc in Australian Defence Department
Anthony John Apted
o More on the Wily Hackers
Rob Gross
o Training and Software Engineers
Tim Shimeall
o Computer-based airline ticket scam
Jordan Brown
o Info on RISKS (comp.risks)

Phony IRS refunds by computer

Thu, 17 Aug 89 20:59 EST
         Computer filer got $325,000 in phony refunds, IRS claims
                          John King, Globe Staff
                   (Boston Globe of Thursday, August 17)

Clever tax preparers are one thing, but a clever bookkeeper who allegedly
pried 325,000 dollars from the Internal Revenue Service found himself on
the wrong side of the law yesterday.

In what may be the nation's first charge of electronic tax fraud, IRS
special agents yesterday arrested Alan N. Scott of West Roxbury [a part of
Boston], saying he claimed 45 fraudulent income tax refunds for amounts
ranging from 3,000 dollars to 23,000 dollars.

The IRS charges that Scott, 37, used the service's new electronic filing
system -- open only to tax preparers -- to submit phony claims with assumed
names and Social Security numbers.  In some cases, the names used were of
people in prison, according to Chief Kenneth Claunch, IRS Criminal
Investigation Division.

``The computer age has spawned a new breed of criminal,'' Claunch said in a

New in tools, perhaps.  As for the basic idea -- filing a false return in
order to snare an unwarranted refund -- that's old hat, admitted IRS
spokeswoman Marti Melecio.

``I can't say that it's a new trick.  We've had fraud cases with paper
returns,'' Melecio said.  ``The time frame is different, though.  With
electronic filings, the returns come back in two or three weeks.''

According to the IRS, Scott received electronic filing status on Jan. 31.
He did this by using a false Social Security number, and making false
statements on his application.  However, the IRS also says Scott
electronically filed 10 returns where he used his own name as a preparer,
and these returns appear to be legitimate.

The scheme was uncovered by the a [sic] ``questionable refund detection
team,'' at the IRS service center in Andover [Massachusetts].  Also, the
IRS credited a tip from an unnamed boston bank ``which reported a
suspicious electronic transfer of funds to an individual,'' presumably
Lewis [sic].

If conviced, Lewis [sic] faces a possible prison sentence and up to 250,000
dollars in fines on each of the counts of fraud.

Cellular phones in stings

David 'Witt' DTN 293-5071 <>
Wed, 16 Aug 89 07:03:24 PDT
In Friday's (11 Aug) Wall Street Journal, there was an article on cellular
telephones.  Of particular interest was the discussion of using cellular phones
to replace two way radio in police departments in "sting" operations.  It seems
that the people they were chasing listened to police band scanners and were
evading the police, so the police switched to celluar telephones to maintain

I'm not sure if I'm more touched or scared by such misplaced faith in a new
technology.  (The lack of secrecy in cellular phones has been discussed at
length in this forum.)
                                        --David Wittenberg

Aircrew acceptance of flight automation

Robert Dorsett <rdd@rascal.ics.UTEXAS.EDU>
Thu, 17 Aug 89 22:25:03 CDT
The August 7 issue of _Aviation Week and Space Technology_ has a feature story
on how well flight automation has been received by aircrews.  Earl Wiener
(co-editor of _Human Factors in Aviation_, in which similar stats were
revealed) has released the results of a survey of some 200 757 pilots.  The
data shows strikingly opposed opinions--either the pilots love the automated
systems, or they hate them.

The article mentions one problem, which hasn't gotten much press attention, is
that the automated systems encourage a "heads-down" atmosphere under 10,000'.
The UI's are apparently so bad that a single pilot must devote all his
attention to updating and manipulating information in their flight management
and control control systems (FMCS), in effect reducing the cockpit to
single-pilot operation for substantial periods.

The article also mentions identification of various problems that need

"* Further reduction of workload in low-workload phases of flight caused by
automation (for example, long haul over water.

* Further increase in workload in high-workload phases of flight caused by
automation (for example, terminal area).

* A potential for substantially increased "head-down" time.

* Difficulty in recovering from automation failure.

* Reluctance of flight crews to take over a malfunctioning automated system.

* Deterioration of pilot/controller basic skills.

* Complacancy, lack of vigilance and boredom in workers.

* Introduction of unanticipated failure modes.

* Incompatibility between advanced automated aircraft, existing air traffic
control capability and the rest of the fleet."

The article also notes some fairly critical UI problems:

"Pilots even work around aspects of the computer program that do[es] not
provide the desired performance.  For example, crews who want to start vertical
navigation descents earlier than the computed top-of-descent point simply tell
the computer they plan to use anti-ice when, in fact, they do not, or they
program in a fictitious tail wind.  The computer then refigures a new
top-of-descent poin tto the pilot's liking.  This procedure is often needed
because the Boeing 757, considered an aerodynamically stable aircraft, does not
descend as readily as earlier models.  Pilots like to avoid using speed brakes
to conserve fuel and avoid disturbing passengers."

It's interesting to note that Wiener wishes to solve the automation problem by
imposing a greater level of automation (the article is fairly vague about what
he has in mind--my interpretation is a combination of higher-level services and
better-designed user interfaces).

The article doesn't treat cockpits utilizing unconventional control laws, such
as those the A320's fly-by-wire system utilizes (but otherwise, A320 flight
management principles are quite similar to the systems utilized elsehwere).

Some comments and opinions:

The problems at altitudes less than 10,000' are quite interesting.  Automation has generally been marketed as a "workload-saving" item.  Particularly
after the midair collision between a PSA 727 and a Cessna 172 in 1978, simplified cockpits, and consequent automation, was marketed as a means of keeping
the pilots' eyes looking out of the airplane.  In effect, however, the basic
problem is unsolved (if, indeed, it was a problem, which is another story).
Automation has done *nothing* to simplify the actual tasks of *flying* the
airplane: the older autopilots, with heading, altitude, and airspeed select,
were excellent aids to operating in control environments.  The key in the
current problems seems to be in the flight management control system, which
first started entering widespread use in 1982-83.  The idea behind the FMCS
was that it could be programmed with economical flight profiles, and then be
coupled to the autopilot, thus creating a highly economical flight.  Comments
in the Aviation Week article (which, incidentally, runs counter to the gung-ho attitudes in similar technology reviews in _Flying_ and _Flight
International_) suggest that pilots are not utilizing the system, and that
the system itself is not selecting the most optimal flight characteristics.
In effect, they appear to be reverting to manual manipulation of the autoqpilot.

Robert Dorsett            UUCP:!!rdd

CERT Internet Security Advisory -- unauthorized Internet activity

Kenneth R. van Wyk <krvw@SEI.CMU.EDU>
Wed, 16 Aug 89 11:50:22 EDT
Many computers connected to the Internet have recently experienced unauthorized
system activity.  Investigation shows that the activity has occurred for
several months and is spreading.  Several UNIX computers have had their
"telnet" programs illicitly replaced with versions of "telnet" which log
outgoing login sessions (including usernames and passwords to remote systems).
It appears that access has been gained to many of the machines which have
appeared in some of these session logs.  (As a first step, frequent telnet
users should change their passwords immediately.)  While there is no cause for
panic, there are a number of things that system administrators can do to detect
whether the security on their machines has been compromised using this approach
and to tighten security on their systems where necessary.  At a minimum, all
UNIX site administrators should do the following:

o Test telnet for unauthorized changes by using the UNIX "strings"
  command to search for path/filenames of possible log files.  Affected
  sites have noticed that their telnet programs were logging information
  in user accounts under directory names such as "..." and ".mail".

In general, we suggest that site administrators be attentive to configuration
management issues.  These include the following:

o Test authenticity of critical programs - Any program with access to
  the network (e.g., the TCP/IP suite) or with access to usernames and
  passwords should be periodically tested for unauthorized changes.
  Such a test can be done by comparing checksums of on-line copies of
  these programs to checksums of original copies.  (Checksums can be
  calculated with the UNIX "sum" command.)  Alternatively, these
  programs can be periodically reloaded from original tapes.

o Privileged programs - Programs that grant privileges to users (e.g.,
  setuid root programs/shells in UNIX) can be exploited to gain
  unrestricted access to systems.  System administrators should watch
  for such programs being placed in places such as /tmp and /usr/tmp (on
  UNIX systems).  A common malicious practice is to place a setuid shell
  (sh or csh) in the /tmp directory, thus creating a "back door" whereby
  any user can gain privileged system access.

o Monitor system logs - System access logs should be periodically
  scanned (e.g., via UNIX "last" command) for suspicious or unlikely
  system activity.

o Terminal servers - Terminal servers with unrestricted network access
  (that is, terminal servers which allow users to connect to and from
  any system on the Internet) are frequently used to camouflage network
  connections, making it difficult to track unauthorized activity.
  Most popular terminal servers can be configured to restrict network
  access to and from local hosts.

o Passwords - Guest accounts and accounts with trivial passwords
  (e.g., username=password, password=none) are common targets.  System
  administrators should make sure that all accounts are password
  protected and encourage users to use acceptable passwords as well as
  to change their passwords periodically, as a general practice.  For
  more information on passwords, see Federal Information Processing
  Standard Publication (FIPS PUB) 112, available from the National
  Technical Information Service, U.S. Department of Commerce,
  Springfield, VA 22161.

o Anonymous file transfer - Unrestricted file transfer access to a
  system can be exploited to obtain sensitive files such as the UNIX
  /etc/passwd file.  If used, TFTP (Trivial File Transfer Protocol -
  which requires no username/password authentication) should always be
  configured to run as a non-privileged user and "chroot" to a file
  structure where the remote user cannot transfer the system /etc/passwd
  file.  Anonymous FTP, too, should not allow the remote user to access
  this file, or any other critical system file.  Configuring these
  facilities to "chroot" limits file access to a localized directory

o Apply fixes - Many of the old "holes" in UNIX have been closed.
  Check with your vendor and install all of the latest fixes.

If system administrators do discover any unauthorized system activity,
they are urged to contact the Computer Emergency Response Team (CERT).

Kenneth R. van Wyk, Computer Emergency Response Team   cert@SEI.CMU.EDU
(412) 268-7090  (24 hour hotline)

Re: Marijuana virus wreaks havoc in Australian Defence Department

Anthony John Apted <Apted@DOCKMASTER.NCSC.MIL>
Tue, 15 Aug 89 14:43 EDT
I am aware of the RISKS attitude to redundancy, however I would like to
present an Australian viewpoint on this incident. (see RISKS 9.9)

First, some background. I have worked for the Australian Defence Dept.
for six and a half years: five and a half as a programmer/analyst on
real-time systems, and twelve months in Computer Security. I am currently
on a twelve-month posting with the NCSC, gaining experience in software

The following newspaper article arrived in the mail from home yesterday.
It is from the Melbourne 'Sun News-Pictorial', dated 8/8/89.

"Terminal virus rocks defence" by George Megalogenis.

   "Australia's Defence Department has been bugged by a computer virus
posing as a messenger for an illicit drug.
   Confused staff where [sic] greeted with the message: 'Your machine
has been stoned - Legalise marijuana' when they tried to operate infected
terminals last week.
   A spokesman confirmed yesterday that eight high-security terminals in
Canberra came down with the bug.
   The defence bug was reported as having destroyed sensitive departmental
   The department is remaining tight-lipped on the source of the infection
as it does not want to encourage computer hackers to pull similar stunts.
   A computer virus begins life as an innocent program on a particular
   But a hacker can use it to cause mischief by spreading the unwanted or
false information to other terminals and systems.
   The programmer can also direct the virus to destroy existing files.
   The department spokesman said the technical virus had been 'isolated
and the computers decontaminated'.
   The spokesman said he could not rule out the possibility that the virus
was created by accident.
   The department was working on programs designed to weed out future
intruders before they caused any damage, he said."

A few remarks on the preceding:

Ignoring (for the moment) the quality of the article: I am not
surprised "the department is remaining tight-lipped"; based on my
knowledge of the department, and of similar occurences in other government
organisations, the most likely explanation for the appearance of the virus
on Defence PCs is that someone brought into the office their own infected
floppies, probably to play games. This sort of thing is not looked on
kindly by the Department (to put it mildly).

[The RISKS 9.9 posting suggested that the office, involved in virus/anti-virus
research, might have had an internal accident: certainly possible - eight
machines  infected smacks of carelessness, but obviously someone was, somewhere
along the line, whatever the actual cause.]

Now to the quality of the article: this is (fairly obviously) an appalling
piece of reportage - lack of technical knowledge on the part of the writer
(and sub-editor) is quite evident in (among other things) the persistent use
of the word "terminal" instead of "personal computer", and the amazing
statement that "A computer virus begins life as an innocent program...".

It is acknowledeged that the 'Sun' is not the highest quality newspaper
in Australia - nevertheless it is not a typical tabloid-style either.
Therefore, I personally find the lack of quality of information in this
article disturbing (especially as the 'Sun' had given good-quality reporting
and commentary on the Internet worm).

The main RISK? the 'Sun' is the highest circulation paper in Victoria, if not
Australia [approx. 650,000 daily]; its readership is typically blue-collar
and secretarial/clerical type people - those most likely to be naive users of
personal computers, and most likely to be influenced by (i.e. believe
verbatim) the contents of this article.

Anthony J. Apted

DISCLAIMER: Any original thoughts expressed in the above are my own, and
            do not represent the views of either the Australian or American
            governments (any unoriginal thoughts are the responsibility of
            their owners).

More on the Wily Hackers

Thu, 17 Aug 89 20:59 EST
        W. German computer hackers accused of spying for Soviets
                 (Boston Globe of Thursday, August 17)

Associated Press (Frankfurt) --- Three computer hackers, suspected of giving
the Soviet Union information from military and industrial computers worldwide,
have been indicted on espionage charges, prosecutors said yesterday.  The West
German government called the breakup of the spy ring, which gave the KGB secret
data from 12 countries, including the United States, ``a major blow'' to the
Soviets.  In a four-page statement, Kurt Rebman, the chief federal prosecutor,
said it was the first time his office had prosecuted hackers for endangering
national security.

  [See RISKS-9.34 for the earlier background on the Wily Hackers.  PGN]

Training and Software Engineers (was: UK Defence Software Standards)

Tim Shimeall x2509 <>
Thu, 3 Aug 89 09:39:52 PDT
Another message in the thread of comments from my friend (replies to me for
relaying, or to RISKS).                             Tim

Douglas W. Jones states that the terms software engineering and software
engineer have gotten out of control.  He is correct, but it seems to me
that his solution, to regulate the use of the title "software engineer",
is a rather weak one.

In his comment, he gives a general outline of a set of standards that
have been suggested to restrict the use of the term engineer, and suggests
that some similar approach might be used:

>  1) People who have passed a state professional engineering examination.
>  2) People who have graduated from an accredited 4-year engineering program.
>  3) People who have graduate degrees.

The problem with regulating the term is that it does not regulate the work
that the individual does.  In my last comment, I mentioned that I have worked
with people who had A.A. degrees or were merely high school graduates who were
called "software engineers".  What I should probably have made clearer is that
it is not simply that they call themselves that; it is what they are called by
their employers.  They will be doing the same work, with or without the title,
as long as they continue to work for those employers.

Software engineering, even compared to electrical engineering is a
very young discipline.  While I would meet the second of the criteria he
lists, most of the professors I studied under to get the degree would not.
As a group, their doctorates were in areas ranging from Physics to English, with
only the younger members of the department having degrees in Computer Science.

Software engineering is still very much in its infancy.  There are several
basic rules that derive from this fact:

1)  Acceptable levels of knowledge and techniques for today will not
    be acceptable tomorrow.

2)  There are not enough "real" software engineers available to do
    the work that requires their services.

3)  There are a lot of people out there who call themselves software
    engineers who are not "real".

An engineer, as defined by the firm I happen to work for now, is someone
with a degree in an engineering discipline from a school with a recognized
engineering department.  A software engineer is an engineer who writes
software, as opposed to a computer programmer who is a non-engineer who
writes software.  The two may work side-by-side on exactly the same task,
doing exactly the same thing, but that is the only difference.  Who gets
assigned to what task is largely dictated by what the previous experience
of the person is, not job title.  This is in a large aerospace firm.

An engineer, as defined by the last place I worked for, was someone with
a certain minimum level of experience who worked overtime for free.  The
degree was accepted in lieu of that minimum level of experience, but
that was about the only difference.  The two people, one degreed, one not
may work side-by-side on exactly the same task, doing exactly the same
thing, with exactly the same job title.  Who gets assigned to what task is
largely dictated by what the previous experience of the person is, not
degree status.  This is not a large aerospace firm, but how different is
it really?

Is the fact that the software engineer got a degree 29 years ago in
electrical engineering that significant to his job function?  Many
of the professors I studied under when I got my own degree had their
degrees in areas unrelated to computer science.

One of the most reliable (in terms of safe and effective product) "software
engineers" I had the pleasure of working with in the past is not degreed.
He learned his trade by the apprenticeship method, still one of the most
reliable methods.  He spent a great deal of time and effort in understanding
the application area in which he worked, and the effort showed.  One of the
least reliable "software engineers" I worked with went to great lengths to
make sure we all know he had a MS in Software Engineering from a good technical
school.  He was ultimately laid off because of the terrible quality of the
code he produced, and because he refused to learn from people who were
academically "beneath" him.

it is unreasonable trying to regulate something that is not be possible to
regulate.  (Sure we can limit the use of the term, but can any agency
actually place that stringent a limit on who actually does the work?
When the people are simply not there to do it?  Ask the INS about illegal
aliens doing household chores and working in factories sometime.)

I feel that a far more effective solution at this time, is to attempt to
communicate with the companies involved with RISKy projects (either building
them, buying them, or using them) about the type of expertise needed for these
projects, to develop a set of livable standards that take into account the
level of expertise presently available in the general population of "software
engineers" available in the field (as the MOD has tried to do), and to attempt
to produce enough QUALIFIED people to meet the genuine need for them.  In
this way, we have a livable (albeit painful) solution for the short term,
and a reasonable hope for something better in the future.

Computer-based airline ticket scam (RISKS 9.11)

Jordan Brown <jbrown@herron.UUCP>
Thu, 17 Aug 89 09:59:37 PDT
> From: Rodney Hoffman <>
> Investigators said the individuals put together a major conspiracy
> by knowing how to access airline computers to put travel itineraries
> in the computer system.                           ++++++++++++++++++

In the interests of equal access to scammery to all, I will divulge some of the
deep secrets of how to access airline computers and insert travel itineraries.
This can be done from virtually any telephone nationwide (even a dial phone!).
The process is virtually immune to tracing if you use a public phone; your
identity is protected.

First, it is necessary to determine the secret access code for the airline
computer.  To do this it is necessary to penetrate the telephone company's
databases.  Pick up the phone and dial 1-800-555-1212.  This will connect you
to a human-assisted database of access codes.  Say (for instance) "American
Airlines Reservations".  The database system will read you a number,

Hang up and dial this number (probably prefixed by a 1).  This will connect you
to another human-assisted database which stores all of American Airlines'
itineraries.  Simply state the date, flight number, departure and destination
cities, and passenger name.  It's that easy!  You can later dial the same
access number and cancel or modify your itineraries.  The system even includes
search functions if you don't know the flight number, and an extensive help
system (just say "How do I make a reservation?").  It's almost like they tried
to make this sort of illicit use simple.                          Jordan Brown

  [Cute.  But I suspect unauthorized on-line access might also be parlayed
  into other spin-offs, such as getting tickets issued without paying. PGN]

Please report problems with the web pages to the maintainer