From: “Peter Trei” <trei@process.com>
To: cypherpunks@toad.com
Message Hash: a530ef710376e4c017e7d70ea009b942ff3d48517e79815f8191c359769f70b8
Message ID: <199606251952.MAA13356@toad.com>
Reply To: N/A
UTC Datetime: 1996-06-26 02:48:56 UTC
Raw Date: Wed, 26 Jun 1996 10:48:56 +0800
From: "Peter Trei" <trei@process.com>
Date: Wed, 26 Jun 1996 10:48:56 +0800
To: cypherpunks@toad.com
Subject: Re: Tales from the UK: Basel Part IV
Message-ID: <199606251952.MAA13356@toad.com>
MIME-Version: 1.0
Content-Type: text/plain
> Received: from toad.com [140.174.2.1] by alcor.process.com
> with SMTP-OpenVMS via TCP/IP; Tue, 25 Jun 1996 11:11 -0400
> Received: (from majordom@localhost) by toad.com (8.7.5/8.7.3) id HAA10621 for cypherpunks-outgoing; Tue, 25 Jun 1996 07:04:53 -0700 (PDT)
> Received: from mailhost.IntNet.net (mercury.IntNet.net [198.252.32.180]) by toad.com (8.7.5/8.7.3) with SMTP id HAA10616 for <cypherpunks@toad.com>; Tue, 25 Jun 1996 07:04:46 -0700 (PDT)
> From: winn@Infowar.Com
> Received: from 198.252.40.157 by mailhost.IntNet.net (SMI-8.6/SMI-SVR4)
> id KAA24757; Tue, 25 Jun 1996 10:06:02 -0400
> Date: Tue, 25 Jun 1996 10:06:02 -0400
> Message-Id: <199606251406.KAA24757@mailhost.IntNet.net>
> MIME-Version: 1.0
> Content-Type: text/plain
> Content-Transfer-Encoding: 7bit
> Subject: Tales from the UK: Basel Part IV
> To: Nmunro@access.digex.net
> X-Mailer: SPRY Mail Version: 04.00.06.17
> Sender: owner-cypherpunks@toad.com
> Precedence: bulk
>
> June, 1996: Basel, Switzerland
> More on the London Attacks: Part IV
winn writes:
[...]
> The perpetrator(s) would first place a call to the upper management of the
> intended victim announcing his/her intention. "We will take down your bank (or
> financial organization) unless you pay us a lot of money not to."
>
> The intended victims each sluffed off the threats. Shortly thereafter (within a
> day or two) their financial systems would seemingly collapse for no reason at
> the prescribed time and as promised by the caller. Banking services and/or
> trading would come to a halt, for about an hour or so, and then the affected
> systems would come back on line. Backups were ineffective; typical disaster
> recovery methods, I was told, just didn't work.
[...]
> I was told unequivocally that all of the four attacks used the same methodology:
> malicious software was somehow injected into the systems but neither was either
> forthcoming or knowledgeable about the specifics. They specifically denied that
> HERF techniques were used. But many questions remained, and I was unsuccessful
> at getting what I would call good answers to these and more queries:
>
> - Which systems were affected exactly?
> - How were the backup/redundancies disconnected?
> - Exactly what do you mean by remote control?
> - Did you ever find the offending software?
> - Was it an insider job?
> - Was it pure hacking?
> - Was is mission critical application software gone awry?
> - And so on . . . .
[...]
> Winn Schwartau - Interpact, Inc.
> Information Warfare and InfoSec
> V: 813.393.6600 / F: 813.393.6361
> Winn@InfoWar.Com
I used to work in a major money center bank (late, lamented Irving Trust). I find this
account highly improbable, considering the precautions I've seen used in these
situations.
The only possibility seems to be an inside job, inserting a logic bomb into some
crucial piece of software, and then setting it off either through an inside collaborator,
or by sending an appropriate message through the system from outside: "if you
see a transfer from acct 346769 to 56789 of $3,141,592.65, shut down for an
hour".
Inserting a bomb like this would have been extremely difficult, if not impossible, at IT.
Code modifications were always checked by more than one programmer, and an
extensive 'backout' mechanism existed which permitted us to go back to older versions
of the software in a matter of minutes.
Cracking the system from outside is also unlikely - the operational machines had
no internet connection, dial in, or connection to our development or administrative
lans, nor did they run any of the usual demons
through which attacks are made. They were connected only to other parts of the
operational system. Even the developers did not have direct access to them -
putting on new software involved writing it to a removable HD which was then
physically transfered to the operational systems. Only the operators were permitted
to touch the consoles of the operational systems.
Finally, we maintained a 'hot site' duplicating most of our capability, at a location
about 100 miles away, in case of catastrophe. Switching to that would have taken
a few hours, but was certainly doable.
>Thereafter, a second call would be made to senior executives of the victim
>firms, and the extortion demands for payment made again. In these cases,
>electronic payments to Switzerland were made, and the monies were then
>secreted from their temporary Swiss home within seconds - destined for
>places unknown or unannounced.
I also find the claim improbable - the Swiss authorities are quite cooperative when
there is good reason to beleive a crime is being committed.
If it's an inside job, then it's not much of a threat, since each financial institution
would need to be penetrated separately.
The only way in which this might NOT be an inside job would be if a logic bomb
was inserted into some piece of commercial software used by all of the targets,
such as a message database. If so, then there is no reason not to identify the
package.
Until names get named, I'm going to view this story with extreme skepticism.
Finally, people may wish to look at the source of the posting. Mr Schwartau
is a consultant who makes his living by advising institutions on how to protect
themselves against attacks of the type claimed in this story.
Peter Trei
Senior Software Engineer
Purveyor Development Team
Process Software Corporation
http://www.process.com
trei@process.com
Return to June 1996
Return to “Reg Harbeck <rharbeck@freenet.calgary.ab.ca>”