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 7 Issue 2

Thursday 2 June 1988

Contents

o Happenstance and $70 Million
Patrick A. Townson
o Re: Optimisers too tacit, perhaps?
Tim McDaniel
o Re: Optimisers; Telecommunications Redundancy
Michael Wagner
o Major security hole in some sun systems
Pete Cottrell and Steve Miller and Jim Purtilo and Chris Torek
o Info on RISKS (comp.risks)

Happenstance and $70 Million

<Patrick_A_Townson@cup.portal.com>
Wed Jun 1 23:28:30 1988
On May 13, 1988, the day they allegedly embezzled $70 million from First
National Bank of Chicago, two key players met in the waiting room at the
Chicago & Northwestern Railroad Suburban Station.

Armand Moore, convicted swindler said by prosecutors to have masterminded
the crime, was quick to assure bank employee Gabriel Taylor that the plan
had gone off without a hitch.

"You did fine. Everything went great," Moore told Taylor. "Just sit tight.
I won't forget to give you your share of the loot." Confident that all was
well, Moore and the other co-schemers went out to look at new Jaguars and
Cadillacs the next day.

But by Monday morning, May 16, the scheme had begun to unravel. Gabriel
Taylor decided it best to begin cooperating with the government, and seven
men, including Moore and another employee of First National Bank were
indicted by a federal grand jury in the case two days later.

First National has said it anticipates no loss to itself or its customers
in the case. Although $19.8 million remained at large for several days
following the exposure of the scheme, the bank has now retrieved it after
filing suit against Citibank, which at first had refused to return it.

The effort failed 'only by the merest happenstance. This was a big near-miss,'
according to Robert Edwards, a Hagerstown, MD consultant on money transfer
security.

In the case at hand, about $70 million was sent out of the bank in just 64
minutes by wire transfer that Friday morning. Several trillion dollars per
week is moved around the country by wire transfer, in which funds are moved
from one bank to another by electronic debits and credits to interbank account
at the institutions involved.

First National has been busily telling everyone who would listen that the
attempt was foiled because of 'the effeciency of our system, and the many
controls we use....'.  Cynical insiders at the bank and members of the
financial community in Chicago say that is nonsense. The scheme was a
relatively simple minded one which failed because of the perpetrators'
greed and apparent lack of sophistication.

"It's not the hackers and phreakers who are making trouble in most cases,"
said Edwards. "It's the employees who are working us over. When you have
collusion between an employee and somebody on the outside, it is almost
impossible to prevent fraud like this." He added, "The wire transfer business
is extremely risky at best. This is one of the nightmares you live with."

In the First National case, the plot allegedly centered on Moore, known by
his street name of 'The Chairman'. Moore came from his home in Detroit about
the first of May to meet with his cousin Herschel Bailey of Chicago, one
of those charged in the scheme.

Bailey knew Otis Wilson, who had worked at First National for six years
in the wire room. He was also aquainted with Gabriel Taylor, another wire
room employee. Both Taylor and Moore were low-level employees at First
National. Both were young guys from the south side of Chicago who had gotten
jobs at the bank as older teenagers a few years before.

There were several planning meetings at the downtown Quality Inn hotel,
according to federal prosecutors. To entice the two bank employees, Moore
flashed photographs of Rolls-Royce automobiles and luxury yachts, according
to Assistant United States Attorneys Jeffrey Stone and Scott Mendeloff.

Moore allegedly promised Taylor and Wilson he would give them $28 million of
the loot in exchange for their cooperation. At first, Moore wanted to steal
$232 million, but Taylor convinced him that was just too greedy and risky.

Taylor and Bailey allegedly provided the others with confidential information
regarding wire transfers, including the words and phrases bank employees
would say to one another on the phone. They allegedly provided confidential
information about the accounts of several large corporate customers of First
National. They studied computer printouts to determine which of these various
customers had the highest amount of protection against overdrafts, and which
had the highest volume of transactions in their account, meaning that missing
funds would be difficult to immediatly reconcile. They rejected several of
the accounts they reviewed, including Hilton Hotels Corp., for which the
limits were too low.

The men allegedly selected three companies -- Merrill Lynch & Co,. United
Airlines and Brown-Forman Corp. They called First National, purporting to
be with those companies, requesting wire transfers. Taylor arranged to be
the person who made confirming telephone calls, the government claims.

Under First National's procedures, the employee who receives the customer's
request for a wire transfer cannot also be the employee who makes the
confirming phone call. Furthermore, a third employee is required to actually
operate the electronics involved in passing the money.

Prosecutors said the plan called for Taylor to hang up the phone if he was
the person who received the incoming call. Calls to the wire room are
routed automatically by a call distributor-like system; no one knows who will
get which incoming phone call.

Keeping alert to the incoming calls, which were expected at certain times,
Taylor then managed to get the task of making the callbacks, but instead of
calling the actual companies involved, he called his accomplices at Bailey's
house on the south side. Although the bank keeps a computerized record of
all outgoing calls from phones in the wire room, the log was seldom checked
and in any event was never checked immediately.

The money was transferred to accounts of Austrian banks at Chase Manhattan
Bank and Citibank in New York that Friday morning between 8:30 and 9:34 AM.

Later Friday, Moore and another of his accomplices met with officials of
another Chicago bank to discuss how they could move money from an overseas
account and convert it to cash here in Chicago.

The scheme was derailed early Monday when United Airlines officials noticed
a big overdraft in one of its accounts and immediately called First
National.  Brown-Forman did the same. What the schemers did not realize was
that not only are the dialed digits recorded, *but the conversations are
also*. They also did not realize that due to the size of the Merrill Lynch
account, one employee at First National is assigned full time to handle only
that account and attend to the needs of that very large customer. On coming
to work Monday morning, the first thing that person did was review the
latest printout for the customer. The overdraft was immediately noted, and
since no other employee at the bank is ever authorized to debit or credit
the customer's account or do maintenance on the account, it stood out like
the proverbial sore thumb. A call to the responsible party at Merrill Lynch
confirmed that they had not requested a transfer either.

Bank employees who wish to remain anonymous said it was naive to assume
the large overdrafts would not be noticed in a matter of hours. "It's the
greed that killed them," said one bank executive.

It's not really clear why the money was not moved out of the United States
to the banks in Vienna on Friday rather than waiting for Monday. Although
the bank executive said the schemers were stupid about the whole thing, he
admitted there were flaws in First National's system also. He said Taylor
should not have been able to know for sure that he would be the employee
to make the 'confirming phone call'. The person in the wire room who
handles the confirmation should be selected at random just like the person
who receives the call in the first place. The person actually doing the
transfer should likewise be selected at random. By making it predictable
to either party, a scam is that much easier.

The scheme would have eventually foundered anyway. You don't just withdraw $70
million from a bank in Austria without pretty thorough feedback and checking.

ABOUT THE DEFENDANTS - Gabriel Moore and Otis Wilson apparently had no prior
criminal background. Both have elected to cooperate with the government in the
prosecution of Armand Moore, a several times convicted con man. Both are free
on recognizance bond pending their own trials. While its hard to feel sympathy
for them, I *do* feel a twinge of sympathy. Both were (probably) very poorly
paid clerks. They saw billions of dollars pass through their hands daily. When
an older man, suave and sophisticated, takes them out to dinner, hovers over
them, showers them with attention and offers to help them achieve the kind of
riches they and their families could never legitimately have, it was too much
temptation for them to resist. Wouldn't *you* find it hard? I know I would....
In all probability, based on the sentencing guidelines in federal court here,
when they are tried, based on their pleas of guilt, the court will find them
guilty. The government will make no recommendation as to appropriate
punishment, and they will receive federal probation, probably for two to four
years.

Obviously, they are blackballed from any further employment in banking/credit
card/other financial operations. They face their families and friends as
convicted felons.

If Armand Moore and his other associates -- the people who would have actually
benefitted from the scheme (you don't *really* think they planned to cut those
two kids in on it if they could help it, do you?) -- are convicted, most likely
they will face hard time.

A curious dilemma arose regarding $19.8 million transferred to Citibank that
Friday morning. *Citibank refused at first to give it back*. According to
Citibank, all regulations regarding wire transfers were followed. The proper
things were done, the proper words and phrases uttered, all was in order.
Why, they asked, should *we* have to handle security at First National? They
argued that wire transfers were intended to be immediate credits, and that
if First National was now saying in effect that under some conditions their
word on wires was not good, then why bother with a wire?

First National responded by filing suit the same day, Monday, May 16 in court
in New York City, demanding that their money be returned to them. After some
negotiations between Citibank and First National, *most* of the $19.8 million
was returned. Citibank now says apparently they had better stop accepting wire
transfers from First National altogether, or at least subject them to normal
clearing procedures, for you never know when First National might come back a
few hours -- or a weekend -- later and say it was in error.

Internal controls at First National have been so poor in recent years that in
fact a lot of smaller banks throughout the country have begun holding their
paper for clearance -- even cashier's checks and drafts -- simply because when
'errors' have occurred in the past, First National has taken what is percieved
by many banks as a very uppity attitude toward investigation and restitution.

Mr. Edwards of Hagerstown called it 'sheer happenstance that it failed.' I
think I agree.

Patrick Townson@cup.portal.com, PO Box 1003, Chicago, IL 60690-1003

(ps: Hinsdale seems to be rehabilitated - finally - as of the past few days!
Rumors of terrorist activity/arson at the switch are totally unfounded.)


Re: Optimisers too tacit, perhaps?

Tim McDaniel <mcdaniel%uicsrd.csrd.uiuc.edu%uxc.cso.uiuc.edu@uxc.cso.uiuc.edu>
Wed, 1 Jun 88 12:23:33 CDT
>Does anyone wish optimisers were more forthcoming about the changes they make?

In general, I agree with your point.  For example, some source-to-source
parallelizing compilers can simply list their output; the output language is
the input language, and often you can tell what input generated what output.

However, there are two possible pitfalls.  One RISK is that if a compiler
always puts out reams of messages, a user comes to ignore them, and may not
notice the important ones.

Another problem is that super-optimizers super-mangle code.  A change made
by a super-optimizers after many passes may have little or no relation to
the original source, and so a message may be totally inappropriate.

As one (possibly poor) example, consider the job of doing subscript checking
in Pascal.  Suppose that you already have a very good flow-analysis pass in
your compiler.  The straightforward approach would be to change
    var a, b: array [0 .. 10] of integer;
        i: 0 .. 255;
    ...
    a[i] := b[i];
into
    if (i < 0 or i > 10) then
        abort(some message about a);
    if (i < 0 or i > 10) then
        abort(some message about b);
    a[i] := b[i];

I say ``straightforward'' because these statements can be generated
mechanically, yet it can be easily improved (if you have the good pass as
above).  A super-optimizer could remove the second ``if'', knowing that
there is no return from abort and hence no path in which i is out-of-bound
can reach the second ``if''.  It could notice that ``i'' is non-negative and
remove ``i < 0 or''.  If the original statement were enclosed in
    for i := 0 to 10 do begin ... end
(a common case for arrays) then it could remove all the subscript-checking code.

The alternative would be to special-case the subscript-checking pass to
insert the checks only when necessary.  That would be far more error-prone
and more specialized.

(There are many other optimizations that introduce dead code; see your local
Dragon book.  In fact, because users rarely write dead code,
dead-code-elimination passes exist to clean up after the compiler itself.)

Alas, designing proper messages controlled by reasonable compiler options is
not an easy task.


Re: Optimisers; Telecommunications Redundancy (Risks 6.94)

Michael Wagner +49 228 8199645 <WAGNER%DBNGMD21.BITNET@CUNYVM.CUNY.EDU>
Wed, 01 Jun 88 12:20
In Risks 6.94, J M Hicks <cudat@CU.WARWICK.AC.UK> asked:
>Does anyone wish optimisers were more forthcoming about the changes they make?

Yes, and for this reason, I've always liked the IBM translators, and
particularly the PL/I optimising compiler.  PL/I told you (as a
warning-level message) when it detected and deleted unreachable code.  PL/I
also gave you a complete attribute and cross-reference list, marking the
difference between reference and assignment.  These are features I really
miss in the C compilers I use now (including the IBM one, strangely).

I have had a number of philosophical discussions with people who feel that
such functionality (a) does not belong in a timesharing or micro environment
(because it produces long 'listings') and (b) does not belong in the
compiler.  While there might be a use for a tool that reads the defined
reference language and produces such information (like LINT and XREF), I
find it very useful when the compiler itself tells me.  Amongst other
things, it is reassuring me that it has the same understanding of the source
code as I (and perhaps the reference language) have.

In the same issue, Klaus Brunnstein wrote:
> When analysing the missing redundancy in the ... `Deutsche
> Bundes-Post', ...
> our DATEX-P network has only one central communications controller
> per area. ... Despite many discussions and arguments ...  the Post
> office managers argue that today, redundancy does not pay

To make this a little more concrete, here in Bonn, the central switch is in
a little building on the banks of the Rhine.  For a variety of reasons, the
Rhine floods every year.  The last two years have been particularly bad.
Both Datex-P traffic and voice traffic in Bonn was badly hampered for days
this year because of minimal redundancy.  Nothing was done after last years
flood, and I sincerely doubt that anything is being done about it now.

Michael


Major security hole in some sun systems

Jim Purtilo <purtilo@flubber.cs.umd.edu>
Wed, 1 Jun 88 13:07:19 EDT
We at UMCP have just discovered (the hard way) that there is a major
security hole in a program called "rpc.rexd" on sun workstations.  This
program is intended to facilitate a form of remote execution between
appropriate workstations; the front-end program which is used to request the
remote execution is called simply "on".  Unfortunately, "rpc.rexd" fails
(miserably) in its check of whether the requesters should have the
permission to do what they ask for.

Because of the way on/rexd works, anyone who wishes can, given root access
to his own machine, become any uid he wants on any other machine running rex
*anywhere on the Internet*.  (Luckily, root appears to be the only exception
to this rule, if that is some small consolation.)  The authentication test
in the Sun3.2 rex daemon appears to proceed as:

    get the remote user id out of Unix-flavored authentication
    if it's zero, then deny access
    if getpwuid(remoteuid) is not NULL
        then grant access
        else deny access

In other words, any non-zero user identifier which happens to correspond to
a valid user on the target machine can be used to gain the privileges of
that user.  There is no check to see whether that user has granted "trusted"
status to the originating user and host (normally done via a file called
".rhosts" in many networked Unix systems), nor is there any check to see
whether a system administrator has generically granted such a trusted status
to the originating machine.

If you're running rexd and you're connected to a network, and if there are
people or places on your net whom you don't trust, then we suggest not
running rexd.  To see if you are running it now, look in your /etc/servers
table.  If the "rpc.rexd" line is missing or commented out, you're OK.  Sun
does not enable this daemon in the /etc/servers you read off the
installation tapes.

There are several ways that this problem seems relevent to the risks forum.
The most obvious is the risk of blindly trusting a vendor to ship you
software that performs at least `reasonable' security checks.  We will not
belabor that point here.  Instead, we provide yet another testimony to how
closely we must all watch what goes on our machines:  innocent intentions
can still lead to big headaches.  Most of the Suns in our network ran
version 3.0 of the Sun OS, served by a large central fileserver.  Rex
daemons were not readily available for this version, and there was no hole.
However, many individual research groups have suns of their own.  One day, a
guru running one of these individual Suns decided to be the first on his
block to upgrade to release 3.2.  He was not a staff member in our
department, but was in fact trusted with superuser access to the fileserver.
A well-intentioned chap, as he upgraded his owner's machine, he also
installed the new, cute looking goodies from the distribution on the
department fileserver so that all might benefit from his efforts.  Hence,
the normal scrutiny we would subject a new piece of software to was
bypassed.  Whether or not we would have found the hole when doing our normal
installation of this software is unclear, to be sure, but we would at least
liked to have had a shot at finding it.  You can only speculate at where we
have hidden the body of the late, otherwise well-intentioned, guru who
installed the rex daemon.

    Pete Cottrell,  Steve Miller,   Jim Purtilo,    Chris Torek

Please report problems with the web pages to the maintainer

Top