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 19 Issue 61

Tuesday 3 March 1998

Contents

o Auckland city center shut down due to lack of power
Peter Gutmann
o Cybotage Risks, Information Warfare-Defense, CyberWar
Robert J. Perillo
o Re: CyberAttack on the Pentagon
William Hugh Murray
Fred Cohen
o Another way to take down the mail system
Rob Slade
o DES-II-1 correction
Billy Harris
o Vladimir Levin sentenced for Citibank
o Y2K Problem Hits Graveyards
Dave Graf
o Re: Year 2100 compliance?
Leonard Erickson
Terje Mathisen
o COMPAQ usability problem
Edward Chernoff et al.
o Reminder on Privacy Digests
o Info on RISKS (comp.risks)

Auckland city center shut down due to lack of power

Peter Gutmann <pgut001@cs.auckland.ac.nz>
Mon, 23 Feb 1998 09:12:05 +1300 (NZDT)
  [Note: The message could not be sent from the above FROM: address,
  because of the problem described below.  I have substituted the
  proper one.  PGN]

The city of Auckland has its power provided by Mercury Energy, who have
three 110kV lines (two main ones and a backup) and a 27kV line (another
backup) feeding the central business district.  Most of these cables have
copper conductors inside a pressurized nitrogen jacket (apparently we're one
of the few countries which use these), one of them is oil-filled.  The
cables are supposedly around 40 years old with an overall life expectancy of
60 years, the suspicion is that the El Nino summer has dried out and heated
the ground so that vibration and ground movement (shrinkage) have damaged
the cables.

Because of this, all the cables have failed, leaving the central city
without power.  So far this has affected (at various times) a number of
banking data centres (the first day the power went out was on the Thursday
when everyones pay is supposed to be processed - the data centres themselves
have generators, but the sources feeding them information don't), the stock
exchange, the Auckland central post office buildings, customs and
immigration, some sections of inland revenue, Aucklands main hospital and
medical school complex (they have generators, but one of them failed,
leaving the childrens hospital without power), the university, and God knows
what else (many of these places have generators, but there were apparently
glitches in switching over and one or two breakdowns which have caused
problems).  One comment I've heard is that the power company may not survive
the lawsuits which follow this (taking out some suburb is serious enough,
but taking out the central business district with its cluster of
multinational accounting and legal firms, banks, government departments, and
whatnot is really bad).

There's a web site http://www.mercury.co.nz/cable/index.html with updates on
the situation, this is a Mercury Energy site so be aware that it's subject
to the usual degree of spin control (there have been discrepancies to date
between their statements to the media and what's actually happening).

Various data points:

- The mayor has told businesses in the central city to either close down or
  relocate for at least a week.

- At first the estimated time to repair was a week, now the official estimate
  being fed to the media is 1-3 weeks but the estimate from power company
  workers is a month at least (these figures change constantly, they seem to be
  getting worse).

- In the last five years, Mercury Energy have followed the present economic
  wisdom of aiming for efficiency and a good return to their shareholders (the
  Mercury Trust) and have reduced their field workforce by half.  In addition
  for the last three years their energy has been poured mostly into an
  (ultimately fruitless) struggle to take over their neighbouring power
  supplier, Power NZ.

- Workers from other power companies are being brought in and working in
  civvies to hide the extent of the problem.  Workers were flown in from
  Sydney, Australia to fix the cables, the estimate is that it'll take about a
  week without power to redo these, and if the load placed on them is too high
  they'll fail again.

- Apparently the idea of moving ships from the naval base on the other side of
  the harbour across to the Auckland waterfront to act as floating generators
  was considered, but there are problems with feeding the power from the ships
  to the city.  There's also the problem that there's nothing around which can
  generate enough power to supply even a fraction of the power requirements.

- Because the central city was without power, there was a civil defence callout
  to avoid a potential crime wave.  Police were called in from other parts of
  the city to patrol the city center.  The lack of power is affecting building
  access control systems and alarms, buildings have to have doors propped open
  so people can get in or out, so there's no real protection for the building
  contents.  The services of private security firms are in great demand.

- Since water and sewage rely on electrically-driven pumps to get them into
  office blocks and towers, these services weren't supposed to be available
  either, however one cable is now repaired and, while it lasts is (barely)
  providing power which is being used by emergency and civil services as far as
  possible, with other services like traffic lights being run if there's
  anything to spare.

- In one 10-15 story office block, sprinklers were activated by the power
  outages and continued spraying water into the building for quite some time.
  A comment from someone who saw the aftermath was "They may as well demolish
  the building and start again".

- One company flew in a generator from Poland to try and keep things running.
  The lack of power is a UPS vendors dream, they're almost impossible to
  obtain.  One company asked that their order of UPS's be shipped with a full
  charge.

- From talking to people in various affected central city buildings, as soon as
  the power comes back on the affected law firms will be handling enough
  lawsuits to keep them in clover for years.  In theory the current commercial
  monopolies inherited the privileged positions of the old Power Boards from
  which they're descended, making it impossible to sue them for failing to
  provide a service, however it's not unlikely that the combined legal
  resources of everyone they've annoyed will find some way to get to them
  (there are probably armies of lawyers sitting around candles right now
  scrutinising the relevant legislation).  The Prime Minister has already made
  a plea for people not to engage in a witch-hunt against Mercury Energy.

- The power outages did bring out some good things though.  After the power had
  been out for about half an hour on the first day, someone mentioned that the
  fridges downstairs wouldn't be powered.  In the spirit of true cooperation
  and self-sacrifice, everyone immediately rushed downstairs and saved all the
  beer from getting warm.

The risks here are fairly obvious: Everything is concentrated into the central
business district, there's no way to feed in power from anywhere else even if
it were available, there's no way to allocate power based on how critical the
services are beyond a very crude level (the few buildings which have generators
or some other way to get power have air conditioning, lights, and whatever else
running full tilt as usual, while less privileged buildings have no power or
power-related services), and going for efficiency and profit rather than
reliability for an essential service like this is very risky.

The only real benefit I can see from this is that it'll serve as a great case
study for the Infowar crowd, although the fact that it's due to simple cable
faults rather than assorted Rube Goldberg devices may make it slightly less
appealing for them.

Peter


Cybotage Risks, Information Warfare-Defense, CyberWar

<Perillo@DOCKMASTER.NCSC.MIL>
Fri, 20 Feb 98 00:22 EST
Cybotage - Wilfully and/or maliciously to destroy or impede
           the automatic control processes of computers,
           and/or deliberate disruption of an
           "interconnected communications system" (Network).

Imagine the "DieHard 2" scenario, Airplanes crash, loss of life, because the
software in the maintenance system for the navigational aids of the Air
Traffic Control System malfunctioned. "The other key opening for a terrorist
act in the near future is the Sydney Olympics in 2000. While law enforcement
organizations are concentrating on physical security they have not canvassed
cybersecurity issues ... What if a 747's GPS and ILS systems were
infiltrated to cause it to crash at Sydney's already limited capacity
international airport? The political and psychological effect of an act of
that kind in the Australian context is hard to calculate.", Australia's
Vulnerability to Information Attack: Towards a National Information Policy,
Dr. Adam Cobb, Strategic and Defence Studies Centre, Australian National
University, Fall 1997.

Imagine nationwide Telephone and Power disruptions, not because of downed
lines, but because of malfunctioning software.

Financial markets shut down and bank accounts not accessible, due to
computer/network database problems.

Imagine Information Systems Technology (IST) malfunctions cause Emergency
Services (E911) Unavailability, Police/FBI phones jammed, Internet Service
Provider's (ISP's) to be out of service.  Environmental damage due to IST
problems that caused a Pipeline disruption, a Chemical Plant fire, and/or a
radioactive release from a nuclear power plant. "The U.S. is vulnerable and
currently unprepared to defend crucial parts of its digital infrastructure."
[Presidents Commission on Critical Infrastructure Protection (PCCIP),
Critical Foundations, Protecting America's Infrastructures, October 1997,
Chapter 5, Figure 5 http://www.pccip.gov ]

And DrawBridges are "taken out" by introducing a computer virus to their
microprocessors. [Information Warfare - Delphi, June 1996, Roger Dean
Thrasher, Thesis page 30, http://stl.nps.navy.mil/~c4ipro/thesis.html ]

Or the American, British, or Australian Political System manipulated by the
"Ender's Game" scenario in which fringe groups or terrorists use anonymity,
false identities, unlimited access, and the national nets to spread
disinformation and propaganda which alters the government. [Ender's Game,
Orson Scott Card, SF, 1977]

In July of 1996, Dr. John Deutch Ph.D., former CIA Director, told a Senate
Governmental Affairs subcommittee that the risks of cyber attack was one of
the top threats to U.S. national security.

Are these Threats and/or Vulnerabilities Real or Imaginary, with or without
foundation? The problem with the October 1997 President's Commission on
Critical Infrastructure Protection (PCCIP) Report, was not "the avoidance of
the strong encryption issue - and the insistence that the government have
access to corporate encryption keys." But its failure to provide a credible
and comprehensive threat and vulnerability analysis, a list of specific
problems, statistics, and detailed case histories. This information will be
needed to understand the scope of the problem, make knowledgeable
recommendations, and determine how to solve the problems and fix the
systems.

According to the 1997 InfoSecurity News Industry Survey - Deloitte & Touche
LLP, of 1225 organizations surveyed, 26-30% of the respondents blamed "the
Lack of Centralized Authority" as an obstacle to Computer and
Telecommunications Security.  And 40% blamed "Unclear Responsibilities".

This goes beyond reporting or "information sharing", or a consulting company
to analyze or assess data? What is needed is a National Focal Point for
Computer and Network Security, Information Warfare - Defense (IW-D) to set
Standards, provide Resources and Funding, Coordinate an incident response,
Help repair the damage, Help fix the security vulnerabilities, Catch and
prosecute the attacker?

While computer/communications security "defense in depth" is a good idea,
there must be funds and resources available to pay for it. In the 1997
InfoSecurity News Industry Survey, 63-68% of the respondents stated that
"Budget Constraints" were their biggest obstacle to computer and
telecommunications security. "Slim budgets still inhibit many IST
departments from protecting the security of their systems. Nearly 60% of the
U.S. respondents to the survey cite lack of money as an obstacle in
addressing security concerns.  Without money, implementing security is
difficult at best.", 5th annual InformationWeek/Ernst & Young Information
Security Survey.

If we must super-ruggedize our IST infrastructures, then increased amounts
of resources, incentives, and funding are needed to implement
Computer/Communications Security in both the Government and Private sectors?
"Computer & Communications Industry Association (CCIA) believes that
requiring American industry to bear the cost of building such super-rugged
infrastructure security upgrades would constitute an excessive burden that
would blunt the edge of American industry", CCIA congressional testimony,
6-Nov-1997.

Footnote: "defense in depth", refers to use of multiple protection tools,
           Virus detection, Access Control, Firewalls, Intrusion
           Detection software, Secure Modems, Token-based passwords,
           Cryptography, Biometrics, Security Assessment tools, etc. .

References:

* InfoSecurity News - Deloitte & Touche LLP, David S. Bernstein,
1997 Industry Survey, May 1997, cover story page 20.

* InformationWeek, "Trends, 5th annual InformationWeek/Ernst & Young
Information Security Survey", Beth Davis, 08-Sep-1997.

* RAND, "CyberWar is Coming!", John Arquilla and David Ronfeldt, 1993,
Comparative Strategy, Vol. 12, 1993, pp 141-165.
http://gopher.well.sf.ca.us:70/0/Military/cyberwar

* RAND, Richard O. Hundley and Robert H. Anderson, "Security in Cyberspace:
An Emerging Challenge for Society", RAND P-7893, December 1994.

* RAND, Roger C. Molander, Andrew S. Riddile, Peter A. Wilson, "Strategic
information warfare: a new face of war", MR-661-OSD, 1996.
http://www.rand.org/publications/electronic

Robert J. Perillo, CCP       Richmond, VA      Perillo@dockmaster.ncsc.mil

  [Usual disclaimers omitted]


Re: CyberAttack on the Pentagon (PGN, RISKS-19.60)

William Hugh Murray <whmurray@sprynet.com>
Mon, 02 Mar 98 17:45:11 -0500
There is no evidence available to me that says that the recent successful
hacker attacks were the result of a software problem.  While it may well
have been aggravated by product problems, their roots were in the continued
use of user-selected reusable passwords.  [Blaming the vendors in a world in
which government actively punishes vendors for including encryption in their
products is absurd on its face.]

There is a great deal of evidence available to me:

That not only will secure products not be favored in the market place,
they are often punished.  Security features, functions, and properties
often get on the list but they are never peer with performance and
function.  They are not as highly valued as generality and flexibility.

That legitimate controls provided to management will be used to cripple
security on many, if not most, systems.

That most of the problems result from how we use products and how we put
them together.  These are things that are outside vendor control.

That The hacker enjoys a target-rich environment in which success is
guaranteed. Security is a balancing act in which successful attacks do
not mean that we did it badly.

That the government has managed to get most of its systems off the
target of opportunity list and many off of the target of choice list.

That technology can help good management but that no amount of it can
compensate for bad management.  Security is first, last, and always a
management problem, not a product problem.

Bill

  [Bill has long been an advocate of the position that security is
  a management problem.  I have long been an advocate of the position
  that it is ALSO a technology problem.  If systems are riddled with
  security flaws, there is little incentive to use serious user
  authentication.  Management's options are limited thereby.  In addition,
  there are issues with respect to which security is ALSO a user problem,
  an education problem, and a legal problem.  It is all of those.
  Believing that it is only one of those is a huge oversimplification,
  and an enormous risk in itself.  PGN]


Re: CyberAttack on the Pentagon (PGN, RISKS-19.60)

Fred Cohen <fc@all.net>
Fri, 27 Feb 1998 17:45:18 -0800 (PST)
Indeed, it may well have been the ``the most organized and systematic the
Pentagon has SEEN to date'' - the operative word being "SEEN". Many larger
scale attacks against Pentagon systems have been widely published, but none
of them were "SEEN" until far later - and none were seen by the Pentagon at
all. They were generally detected in audits by non-Pentagon folks.

When a previously blind person sees something, it's something to stand up
and notice.

Fred Cohen & Associates: http://all.net - fc@all.net - tel/fax:510-454-0171


Another way to take down the mail system

"Rob Slade" <rslade@sprint.ca>
Fri, 27 Feb 1998 15:19:21 -0800
I got a mail bounce from a friend locally, so I called to find out what was
up.  Seems that, over the weekend, someone broke in and stole a computer.
Turns out it was the MS Exchange server.  For the whole company.

rslade@vcn.bc.ca     rslade@sprint.ca     slade@freenet.victoria.bc.ca
virus, book info at http://www.freenet.victoria.bc.ca/techrev/rms.html


DES-II-1 correction (Re: McNett, RISKS-19.60)

Billy Harris <wharris@mail.airmail.net>
Fri, 27 Feb 1998 17:10:06 -0600
  [The stats for the Power PC were wrong in the previous posting.
  Here is a follow-up posting made by Distributed net.  Billy Harris]

I need to clear up some confusion about the statistics that were posted on
Nugget's "[ADMIN]" post last night. I made the stats at the end of the post
including the "Perspectives" and "Computing Equivalents," and they seem to
have a mistake.

The keys-per-second rankings were gathered from AldE's speed page at
http://www.alde.com/speed.html. I did not realize that those pages listed
the speed for the early DES PPC clients, which were much slower than the
ones at the end.

The speed I used to create the "Computing Equivalents" was about 500kk/s for
the PPC 604e/200. The more recent and correct speed was more like 1250kk/s.
That would make the figure "27544 Macintosh PowerPC 604e/200s" instead of
"68859 Macintosh PowerPC 604e/200s."

Motorola PowerPC machines have made a significant contribution to all of the
distributed.net efforts. The previous post was not intended to upset and
Macintosh or PPC users and we mean no disrespect.

I apologize for the confusion.

Daniel Baker, distributed.net


Vladimir Levin sentenced for Citibank

<PGN>
Wed, 25 Feb 1998 09:25:46 -0800
Vladimir Levin was sentenced to three years in prison for his role in the
1994 Citibank escapade (RISKS-17.27,28,29,61), and must pay Citibank
$240,015 in restitution.  (He as already spent 30 months in a British jail
and 6 months in a U.S. jail.)  Four of his accomplices had previously
pleaded guilty to conspiracy to commit bank fraud.  [PGN Abstracting from
Internet robber sentenced, http://cnnfn.com/digitaljam/9802/24/robber/
with thanks to stevan@netscape.com (Stevan Milunovic).]


Y2K Problem Hits Graveyards

Dave Graf <DavidG3276@aol.com>
Mon, 2 Mar 1998 21:24:46 EST
Regarding Y2K projects, we often forget that other applications besides
those involving computers are also affected by the millennium change.  For
example, I saw an item in a local paper about problems involving
preinscribed tombstones.  Apparently, it is not uncommon to preinscribe the
first two digits of the year of death.  I've seen this in graveyards where
there is one tombstone for a husband and wife, but one of the spouses is
still alive.  Not surprisingly, "19" has been the popular choice, but what
are they going to do with those tombstones when the year 2000 rolls around?

  [With old COBOL programmers dying off, perhaps we will begin to see
  tombstones with HEX dates such as 199A, 199B, etc. until the supply
  dwindles.  PGN]


Re: Year 2100 compliance? (Shimomura, RISKS-19.60)

Leonard Erickson <shadow@krypton.rain.com>
Sun, 1 Mar 1998 05:37:46 PST
The MS-DOS file system's date format does support dates outside the range
1980-2107. And every MS-DOS/PC-DOS that I've ever checked it on balks at
dates past 2099-12-31 as inputs.

So there's not really a lot of point in putting in support for higher dates
until someone figures out what the OS is going to do about this "design
flaw". At least not from a profit standpoint.

I agree that they shouldn't have limited the fix this way, but given the
dominance of Microsoft OSes on the platform in question, I'm not surprised.

Leonard Erickson (aka Shadow) <shadow@krypton.rain.com>


Re: Year 2100 compliance? (Shimomura, RISKS-19.60)

Terje Mathisen <Terje.Mathisen@hda.hydro.com>
Sun, 01 Mar 1998 15:04:10 +0100
I believe 2100 is a "harder" limit than Y2K for most applications using
2-digit years.  The AMI BIOS noted in RISKS-19.60 is just one example.

The CMOS chip introduced on the 1984 model IBM AT has 2 BCD digits each
for year, month, day, hour, minute and second.

On top of this, IBM decided to store the current century in one of the
CMOS bytes not directly updated by the clock circuitry.

This will work correctly past 2000 because Y2K is a leap year, but after
2100-02-28 lots of software/hardware using two-digit years will have a
hard time figuring out that 2100-02-29 does not exist.

It is interesting to note that even Network Time Protocol (NTP), up to
the latest test releases (V4.X), will have problems at this time, due to
the way NTP handles reference clocks:

NTP ignores the (usually two-digit) year info from a reference clock,
and will instead ask the OS for the correct year number.

>From the OS-supplied year plus reference clock month/day info, the software
calculates the day number in the current year, a calculation which will of
course fail after 2100-02-28.

Terje.Mathisen@hda.hydro.com


COMPAQ usability problem (Mellor, RISKS-19.60)

Edward Chernoff <ECHERNOFF@OTIS.STATE.NJ.US>
Tue, 03 Mar 1998 07:53:36 -0500
No "Any key"?  My keyboard does not have any key identified as 'return'.
This may not solve their problem.

  [Similar comments about PC keyboards having "enter" keys, from
    grady@mdc.net (Dick Grady),
    Thomas Dzubin <dzubint@vcn.bc.ca>,
    Jay Crowley (jjc@cdrh.fda.gov), and
    "Chris Cartledge" <C.Cartledge@sheffield.ac.uk>
      who noted that "ANY KEY" is wrong: Shift and Control don't count.]


Reminder on Privacy Digests

<RISKS moderator>
17 Apr 1997
Periodically I remind you of TWO useful digests related to privacy, both of
which are siphoning off some of the material that would otherwise appear in
RISKS, but which should be read by those of you vitally interested in
privacy problems.  RISKS will continue to carry general discussions in which
risks to privacy are a concern.

* The PRIVACY Forum is run by Lauren Weinstein.  It includes a digest (which
  he moderates quite selectively), archive, and other features, such as
  PRIVACY Forum Radio interviews.  It is somewhat akin to RISKS; it spans
  the full range of both technological and nontechnological privacy-related
  issues (with an emphasis on the former).  For information regarding the
  PRIVACY Forum, please send the exact line:
     information privacy
  as the BODY of a message to "privacy-request@vortex.com"; you will receive
  a response from an automated listserv system.  To submit contributions,
  send to "privacy@vortex.com".

  PRIVACY Forum materials, including archive access/searching, additional
  information, and all other facets, are available on the Web via:
     http://www.vortex.com

* The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is
  run by Leonard P. Levine.  It is gatewayed to the USENET newsgroup
  comp.society.privacy.  It is a relatively open (i.e., less tightly moderated)
  forum, and was established to provide a forum for discussion on the
  effect of technology on privacy.  All too often technology is way ahead of
  the law and society as it presents us with new devices and applications.
  Technology can enhance and detract from privacy.  Submissions should go to
  comp-privacy@uwm.edu and administrative requests to
  comp-privacy-request@uwm.edu.

There is clearly much potential for overlap between the two digests,
although contributions tend not to appear in both places.  If you are very
short of time and can scan only one, you might want to try the former.  If
you are interested in ongoing discussions, try the latter.  Otherwise, it
may well be appropriate for you to read both, depending on the strength of
your interests and time available.
                                                  PGN

Please report problems with the web pages to the maintainer

Top