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 20 Issue 31

Sunday 18 April 1999

Contents

o BART ghost train snarls morning commute
PGN
o EMI from USS Carl Vinson opens garage doors in Hobart
Norbert Thumb
o ASerbic cyberattacks and counterattacks
PGN
o Fake ATM front panel copies cards and PINs
Ulf Lindqvist
o Overzealous applications
Ian Cargill
o Outlook '98 not Y4.501K Compatible
Eric Zago
o favicon.ico
Robert David Graham
o Leap year 2000 and C
Mark Brader
o Risks of April foolery
Pete Mellor
o GUIDs and Melissa
Robert David Graham
o Phone company says keep your PIN on your calling card
David Graf
o Re: Mainframe viruses
Julian Thomas
o E-mail and communications history
Dennis Ritchie
o REVIEW: "Hacker Proof", Lars Klander
Rob Slade
o Info on RISKS (comp.risks)

BART ghost train snarls morning commute

"Peter G. Neumann" <neumann@csl.sri.com>
Sat, 17 Apr 99 13:16:33 PDT
On 16 Apr 1999, a ghost train appeared in the BART computers on a section of
track between the Montgomery and Embarcadero stations in San Francisco.
BART continued to operate manually on that stretch of track for about 4 and
one-half hours through the morning rush-hour.  Although this is not news to
commuters, what seems startling was a recent consultant's report, which
documents 567 such incidents in a two-year period.  (We also reported
repeated appearances of ghost trains in the Muni Metro system about 15 years
ago.)


EMI from USS Carl Vinson opens garage doors in Hobart

Norbert Thumb <thumb@ict.tuwien.ac.at>
Sat, 17 Apr 1999 23:37:50 +0200
As the aircraft carrier USS Carl Vinson approached port in Hobart,
Australia, last week, its communications at 310-320 MHz jammed most
garage-door openers within 6 miles.  (The same thing happened on the
Vinson's previous visit.  Most garage doors have manual overrides.)  The EMI
also immobilized the "shielded" car security system of a resident near the
docks, whose car could not be started -- no manual backup there.  [Source:
US Navy Closes Doors Down Under, by Stewart Taggart, 16 Apr 1999,
Anonymously contributed to cypherpunks; PGN-ed]

Dipl.Ing. Norbert Thumb, Institut f.Computertechnik, Vienna University of
Technology; Austria  +43/1/58801-3704 thumb@ict.tuwien.ac.at


ASerbic cyberattacks and counterattacks

"Peter G. Neumann" <neumann@csl.sri.com>
Fri, 16 Apr 1999 10:34:44 +0000
NATO announced that its Web server in Brussels had been under a
PING-of-death (Packet INternet Groper) attack from somewhere within Serbia.
John Pike labeled it "a textbook example that will be cited from now on as a
low-cost, high-value attack."  [Source: Serbia launches cyberattack on NATO,
*Federal Computer Week*, 31 Mar 1999, by Daniel Verton (dan_verton@fcw.com);
PGN-ed] The ease with which such attacks and other denials of service can be
perpetrated is one more reminder of the general flakiness of our information
infrastructures, but then RISKS readers are probably the last to be
surprised.

In a spy-vs-spy-style retaliation, various Internet denizens sent half a
million e-mail bombs to www.gov.yu, the main Yugoslav Web site, before it
shut down on 3 Apr 1999.  There were also reports *The Boston Globe* of a
U.S. group called Team Spl0it and European and Albanian penetrators changing
Web sites.  On the other hand, there are also reports of Russian hackers
going after U.S. Navy Web sites.  [Source: E-Strikes and Cyber-Sabotage:
Civilian Hackers Go Online to Fight.  15 Apr 1999, by Patrick Riley,
http://www.foxnews.com/stage11.sml; PGN-ed from a cypherpunks item courtesy
of Dave Farber <farber@cis.upenn.edu>]

Riley cited some concerns that vigilante hacktivism might be misinterpreted
as sanctioned government action.  On the other hand, given the existing
system and network flakiness, there might also be concern that what might
seem to be vigilante hacktivism might actually be government sponsored!
Perhaps future wars will be fought by our-hackers-vs-their-hackers in purely
electronic warfare.  It would save a lot in armaments, and would inspire
greater system robustness that otherwise seems impossible to attain!


Fake ATM front panel copies cards and PINs

Ulf Lindqvist <ulfl@ce.chalmers.se>
Fri, 16 Apr 1999 16:47:20 +0200 (MET DST)
On the Swedish TV program *Efterlyst* (similar to "America's most wanted"
and "Crimewatch UK") 15 Apr 1999, a police officer showed a fake ATM front
panel that had been confiscated by Swedish Customs. The two Estonians that
tried to bring the equipment into Sweden are in custody. From Finland and
Denmark, there are reports of hundreds of cases of ATM fraud in which the
police suspect that this equipment was used.

The equipment showed on TV consists of a metal panel with a built-in
keyboard and hidden electronics, and a metal frame containing a magnetic
card reader. The panel is placed on top of the existing keyboard panel of
the ATM and the frame is placed around the card slot. The panel and the
frame are connected with cables that are hidden behind a strip of
metal. When a customer puts his or her card into the ATM slot, the card also
passes through the added metal frame which reads the magnetic strip and
stores the information in the hidden memory in the panel. Then, when the
customer enters his PIN code on the fake keyboard, the code is of course
also recorded, but pins underneath the panel push the real ATM keys, so the
ATM operates normally.

From the description, it may appear that it would be very easy for anyone to
discover the extra gadgets placed on the ATM. However, the TV program also
showed the equipment mounted on an ATM, and it looked strikingly genuine -
the colors of the panel were identical to those of the original panels
etc. It should also be noted that cameras are not standard in ATMs in this
part of the world, making it harder for the victims to prove their cases.

The risk is one we have seen so many times before: You should not give away
your secrets to something that might not be what it claims to be.

Ulf Lindqvist, Department of Computer Eng., Chalmers University of Technology
SE-412 96  Goteborg, SWEDEN  +46 31 772 17 60 ulfl@ce.chalmers.se


Overzealous applications

Ian Cargill <ian@soliton.demon.co.uk>
Sat, 17 Apr 1999 14:34:34 +0100
In RISKS-20.30, Ben Bederson described a problem caused by a space character
in numeric fields in Excel.  The problem was a particular risk because Excel
makes a silent 'best guess' which may be wrong.  I recently came across a
similar risk with MS apps trying too hard to guess what you might have meant
and silently getting it wrong.

My problem was in Access, but I suspect it is a general VB/VBA problem,
not Access-specific.

When you enter a date, Access *FIRST* tries to interpret it according to
the locale that you have set in control panel.  Thus if you enter 2/4/99,
it will be interpreted as 2 April 99 in the UK, 4 Feb 99 in the US, etc.
Fine so far, but what if you enter an invalid date, such as 29/2/02?

You would expect this to be rejected in any locale, but in fact, Access
quietly accepts this as a valid date - 29 Feb 2002!!  The trouble seems
to be that Access tries too zealously to find a 'correct' interpretation,
so if dd/mm/yy (or mm/dd/yy) doesn't work, then it tries yy/mm/dd.

Of course, the problem goes away if you require users to enter four-digit
years, but it is still unwarrantedly aggressive behaviour.

Ian Cargill  CEng MBCS MIEE, Soliton Software Ltd.


Outlook '98 not Y4.501K Compatible

Eric Zago <zippy@WPI.EDU>
Fri, 16 Apr 1999 21:54:24 -0400 (EDT)
Not only does Outlook reschedule holidays (as mentioned in a previous
risks), it also brings the old problem of how to identify data as null.
While in the past 9/9/99 might have been used to identify a 'null' date
(making that date one of our famous y2k warning dates - now we have a new
problem.  In Outlook '98, the default date value is 1/1/4501 8:00 AM.
Obviously Microsoft has not learned he lesson.  While it is not likely that
anyone will be using Outlook '98 in the year 4501, that is not the point.
This is documented in a several books, but no mention is made as to any
potential risks in using arbitrary dates as flags

So can I be the first to coin the Y4.501K Standard?

Eric Zago, Management Information Systems Major
Worcester Polytechnic Institute, Worcester, MA  zippy@wpi.edu


favicon.ico

"Robert David Graham" <rob@netice.com>
Fri, 16 Apr 1999 22:11:22 -0700
In case you haven't heard, Microsoft has a new feature in IE 5.0 web
browser. When you add a website to you "Favorites" (aka. Bookmarks for you
Netscape users), the browser attempts to download a graphic called
"favicon.ico", then show that icon along with the title of the webpage.

This has two risks.

First of all, the website owner is notified when you the page to your
favorites, revealing information about yourself. A discussion of this can be
found at http://msdn.microsoft.com/workshop/essentials/versions/ICPIE5.asp
This privacy risk is probably minor, but I've seen several press articles on
the subject.

The second RISK is much more severe. Go to AltaVista (or any search engine)
and search for "favicon.ico". You now have a list of 500 websites that
expose their access logs. In the logs, you can find several websites that
expose the URLs of CGI scripts, including passwords. Through manual
searching, I found 2 sites that exposed logon information; I'm sure I can
write a program that would scan those logs to look for CGI programs and get
even more. This also exposes even more privacy information because these
logs often contain the Referer field as well.

This isn't unique to "favicon.ico". The RISK is really:

* people are unintentionally exposing access logs on their web sites,
  exposing user information and possible passwords.
* hackers can easily find vulnerable systems not by scanning the site itself
  (which can be detected by intrusion detection systems), but by searching a
  3rd party like AltaVista.

Robert Graham
CTO, Network ICE
http://www.networkice.com/advice


Leap year 2000 and C

Mark Brader <msbrader@interlog.com>
Sat, 17 Apr 1999 02:03:08 -0400 (EDT)
I missed the following when it came up in comp.lang.c.moderated three
months ago, but I think it's worth repeating here.  In C, a time and
date represented by a single number (called a time_t) can be split into
components (year, month, day, hour, etc.) by either of a pair of library
functions, gmtime() and localtime(), which differ only as to the time
zone they use (if that information is available).

Two of the components have unusual representations, for convenience in
particular uses.  The month goes from January = 0 to December = 11, which
is handy for indexing an array of month names.  And the year is represented
with 1900 subtracted from it, a system which in pre-Y2K-conscious days
must have seemed as though it gave a convenient way of obtaining a
"printable form" of a year.  Note that it is does NOT simply reduce the
year to two digits: 1999 is 99, but 2000 is 100, not 0.

Okay, now the bug.  Dennis Ritchie posted this:
#  Until some months ago Plan 9 had an amusing bug: its gmtime routine
#  did not believe that 2000 was a leap year.  The code in the routine
#  had the correct test with 4, 100, 400 (we looked very hard at it).
#
#  It turns out that the "year number" being tested was year-1900,
#  not year!

And Peter Seebach added this follow-up:
|  Curiously, BSD/OS had exactly the same problem earlier this year.
|  It's probably going to pop up all over - because no one's Unix-like
|  implementations were adequately tested in 1900, when they would
|  have incorrectly identified the year as a leap year.

Since all C implementations since the standard came out are required
to include gmtime() and localtime(), they could also be subject to the
same bug, whether on UNIX or not.  Note that such a bug could affect
dates for some considerable time after 2000-02-29 itself, depending
on exactly how the functions are implemented.

Of course, if the implementation got it right, this is a non-issue.
But we see above that there are two that didn't...

Mark Brader, Toronto  msbrader@interlog.com


Risks of April foolery

Pete Mellor <pm@csr.city.ac.uk>
Sat, 17 Apr 1999 23:43:24 +0100 (BST)
This is not really computer related, but have a laugh!

Having had experience of two computer April 1st jokes that were
taken seriously, I was amused to hear an item on the "Today"
programme on BBC Radio 4 on the morning of April the 1st.
This concerned a new Euro-anthem which would replace all of the
European national anthems. It had been written in German and was sung
(very well) by a choir from a German school in London. The tune was
the "Ode to Joy" theme from Beethoven's 9th.

The following day, the newsreaders came clean. Yes, it was a joke
(although the EU gets up to such daft stuff that the listeners could
have been forgiven for believing it).

One particularly eminent listener was apparently impressed by it.
The programme received a request for further information from
Buckingham Palace, allegedly originating from Prince Charles' staff!

Pete Mellor, Centre for Software Reliability, City University, London
p.mellor@csr.city.ac.uk


GUIDs and Melissa

"Robert David Graham" <rob_ni99@netice.com>
Fri, 16 Apr 1999 20:21:06 -0700
>  Incidentally, there is confusion among the various news reports of
>  Melissa as to exactly when and how the GUID entered into the
>  identification of the perpetrator.  Can anyone who really knows
>  enlighten us?  PGN

If you open the Melissa document in BINARY mode (not in Word!), you can see
the following string:

PID_GUID {572858EA-36DD-11D2-885F-004033E0078E}

The underlying issue is very complex. Microsoft assigns a "Globally Unique
Identifier" to every object it can get its hands on, including your local
machine and user account. They are all over Windows; you see them overwhere.

Well, how do you create a GUID? How do you ensure that it is truly unique
in all the word? Microsoft combines timestamp, random number generator, and
other unique identifiers in order to come up with the GUID. In particular,
all Ethernet adapters come with a unique 48 bit serial number. The first
24-bits are assigned to each company that sells adapters, and the second
24-bits are assigned by the company itself. This prevents two adapters from
having the same Ethernet address on the same LAN (RISK note: some vendors
assign duplicate addresses either because of mistakes or just because they
don't care, but for this purpose, we can assume it to be unique).

The Ethernet address is the last 48 bit of the GUID. The creator the Melissa
document has the Ethernet address 004033E0078E. Look that up in a database,
and you see the manufacturer was "Addtron Technologies" owns the address
block "004033xxxxxx". In theory, you might be able to look at Addtron's
records, and pin point things like which distributor the card was shipped
to, then get those records and see who might have bought an Addtron card
with credit cards.

Moreover, there is more fun. You can ask for a Windows-machine's MAC address
using a "NetBIOS NodeStatus Query". This means that you can scan the
Internet looking for this MAC address. You need to send around 4-billion
packets, but it might work.

Many companies maintain virus databases; you simply look through those
databases and see which viruses have the same GUID. You build up a profile
of the virus writer, because they tend to put their names in them. In this
manner, they found the GUID matched up with many viruses created by somebody
named "VicodinES".

The problem is that all of this is circumstantial. Virus writers tend to
grab existing viruses, then modify them to do new things. That was clearly
done in the Melissa case, as it is similar to many other viruses with the
one change that it e-mails itself around.

The real way they caught the guy is that AOL keeps records, and found a
certain IP-address/timestamp combination. The feds then tracked that down to
the ISP, which keeps user-accounts/caller-id/IP-address/timestamp
combinations in its database. They then put it together and find the guy.
The found the guy's computer in the dumpster, it is unclear whether they've
checked the Ethernet card.

Robert Graham, CTO, Network ICE


Phone company says keep your PIN on your calling card

<DavidG3276@aol.com>
Sun, 18 Apr 1999 18:45:38 EDT
As readers are well aware, it is simply good sense to not keep passwords
where someone could take advantage of them.  Imagine my surprise when a major
U.S. telephone company sent us a new calling card along with stickers which
listed our calling card and PIN numbers.  We were to place these small
stickers on the back of the card to make sure that we did not forget either
number.  How helpful--not just for us, but for any thief who might pick my
pocket.  Plus, imagine the fun someone could have if they had stolen this
letter from our mailbox.

Dave Graf <DavidG3276@AOL.COM>


Re: Mainframe viruses (Schaffer, RISKS-20.30)

Julian Thomas <jt5555@epix.net>
Fri, 16 Apr 1999 19:01:25 -0400
>If a computer has an integrated word processor in its mail software, then
>it very well might not take supervisor privileges for a word processor
>macro to send mail.  I think this was the source of the PROFS vulnerability.

Not exactly.  IIRC the program was called CHRISTMA EXEC that came in a
message that said something to the effect of "Don't worry, just run this".
It then proceeded to send itself to everyone in the recipient's address
list.  It wasn't exclusive to PROFS - also affected users of NOTE.

No integrated word processor, and none of those on VM had anything like
the startup macros of word, excel, etc.

Julian Thomas: jt 5555 at epix dot net  http://home.epix.net/~jt
remove numerics for e-mail


E-mail and communications history (Re: RISKS-25,28)

<dmr@plan9.bell-labs.com>
Fri, 2 Apr 1999 01:18:09 -0500
The recently published "The Victorian Internet" by Standage (Walker, 1998)
is not technically deep but has interesting parts, and in particular does
discuss the fraternity of telegraphers (earliest chat groups?) and has some
discussion of security issues that arose even in the 1800s.  No computers
involved, but some of today's issues arose then.

The older "The Early History of Data Networks" by Holzmann and Pehrson (IEEE
Computer Society Press, 1995) is more scholarly and includes much more of
the earlier history, in particular about the remarkable story of the optical
telegraph networks that developed in Europe during the early 19th century.
Link-layer protocols and encoding were important even in 1800.  Disclaimer:
Holzmann is a close colleague, so this is a plug. Anti-disclaimer: the
on-line booksellers differ about its availability.

Dennis Ritchie


REVIEW: "Hacker Proof", Lars Klander

"Rob Slade" <rslade@sprint.ca>
Tue, 6 Apr 1999 08:33:42 -0800
BKHKRPRF.RVW   990228

"Hacker Proof", Lars Klander, 1997, 1-884133-55-X, U$54.95/C$74.95
%A   Lars Klander lklander@jamsa.com
%C   2975 S. Rainbow Blvd., Suite 1, Las Vegas, NV   89102
%D   1997
%G   1-884133-55-X
%I   Jamsa Press/Gulf Publishing Co.
%O   U$54.95/C$74.95 800-432-4112 fax 713-525-4670 starksm@gulfpub.com
%P   660 p. + CD-ROM
%T   "Hacker Proof: The Ultimate Guide to Network Security"

There is a great deal of information on security contained within this
book.  Unfortunately, it is presented without a cohesive framework.
The overall impression is good.  A lot of the forms that would make up
a useful work are followed, such as a summary (rather ironically, in
view of the scattered nature of the text, called "Putting It All
Together") and a set of resources at the end of every chapter.  The
author seems to be easily distracted, continually jumping to the next,
more sensational, topic.

Although not divided into parts, the contents do have some logical
divisions.  Initially, we are presented with what seems to be intended
as background material, although the scattergun approach leaves all of
the synthesis up to the reader.  Chapter one is a rather unfocussed
introduction, talking as much about Internet technologies as about
security.  Errors are rather common, ranging from chunks missing out
of sentences to figures with no cutlines to security weaknesses that
are essentially duplicates of each other to mailing lists that haven't
distributed material for years (with contact addresses that are even
older).  Theoretically the networking concepts and details in chapter
two might aid in understanding system vulnerabilities, but in the fact
of the book they do not seem to be used effectively.  The discussion
of firewalls does not provide sufficient information about either the
needs, weaknesses, or possible inconveniences of the different types
in chapter three.  The material on encryption, in chapter four,
mentions a number of the currently important standards, but the
explanations are so flawed that the chapter could not be used to
inform a decision on the strength or use of a cryptographic system.
Material on the use of digital signatures is fairly short, and the
remainder of chapter five rehashes, with really expanding, old ground.

Another section tries to delve into more networking protocols.
Chapter six, on HTTP (HyperText Transfer Protocol), is somewhat
disjointed, and, again, fails to seriously examine the security
implications.  S-HTTP (Secure HyperText Transfer Protocol), in chapter
seven, deals mostly with packets and commands, although it does have
some limited discussion of function.  The Secure Socket Layer (SSL)
seems to look primarily at arcana rather than use.

Chapter nine looks at a few common forms of attack, but presents
information somewhat at random.  Kerberos is reasonably well described
in chapter ten.  Some types of electronic commerce technology are
mentioned in chapter eleven.  There is an extremely limited look at
auditing in chapter twelve, first for UNIX and then for NT.  A very
rough look at security issues within the Java programming language
makes up chapter thirteen.  Chapter fourteen's look at viruses has
good basic explanations, but is unreliable in practice.

The remaining chapters generally look at security for specific
systems.  Chapters fifteen to seventeen very quickly talk about
individual security functions in NT, NetWare, and UNIX, but fail to
analyze, for example, the effective rights granted by combinations of
the different privilege granting mechanisms.  SATAN (System
Administrator's Tool for Analyzing Networks) for UNIX and Kane
Security Analyst for NT get quick overviews in chapter eighteen.
Chapter nineteen presents a number of security vulnerabilities with
the Netscape and particularly the Internet Explorer Web browsers.  CGI
(Common Gateway Interface) form weaknesses are discussed in chapter
twenty, but with so many different languages that the ultimate advice
is simply don't make a mistake when programming.

The final chapter is a reasonable look at security policies.  However,
with some many items missing from the background provided, the chance
of producing a good policy at this point is relatively small.

As with "Maximum Security" (cf. BKMAXSEC.RVW), this book attempts to
cover the enormous field of security by throwing out as many bits as
possible.  Therefore large holes are apparent in the coverage.  In
addition, the book lacks an overall framework that could be used to
build a security structure and point the way to vulnerabilities that
were not addressed.  For those who already are well comfortable with
security as a concept, this volume does have a lot of references that
might be of use.  For those new to the topic, it is not reliable
enough to start with.

copyright Robert M. Slade, 1999   BKHKRPRF.RVW   990228
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

Please report problems with the web pages to the maintainer

Top