Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
The Gazette in Cedar Rapids reported on Fri Aug. 21, 1992 that: "Spurious radio signals may again be the culprit in an automatic shutdown of the Palo nuclear power plant" The shutdown occurred on Monday. The Gazette also reported that "A similar incident occurred in June 1989." They believe a security guard walking by a control panel with his walkie-talkie caused the control panel to trigger a shutdown. I am glad that it did not tell the system to pull the control rods. Why think about microwave ovens being turned on via radio signals when you can talk about nuclear plants being effected by radio signals. sam@iberia.cca.cr.rockwell.com (S. A. McConnell) Yes, we have more in Iowa than just corn.
>From Les Hatton, <lesh@prl0> Programming Research Ltd., U.K. Software produces legally inadmissible reports: Computer weekly, Thursday, 30 July, 1992. "Thousands of pounds in poll tax arrears are being left uncollected because of a "design fault" in ICL's Comcis software package. Cash-stricken London councils, including Lambeth and Southwark, have had to delay debt collection after magistrates rejected their computer printouts as evidence. ..... (the bench) ruled that defaulter's debts had to be broken down into individual years and not the single sum given by Comcis, which, as the market leader, is used by about 400 councils. ... Bob Hoskins, head of IT at Southwark commented "Instead of sending out 1,500 summonses per week, we're limited to issuing only 1,000 because of the time it takes to amend the documents manually". ... An ICL spokesman said the authorities affected had only themselves to blame ... "We are not turning our back on these customers and are doing are best to help", he added". What an extraordinary response by the supplier !
Computer weekly, Thursday 6 Aug, 1992. "A financial fiasco involving the loss of 5.5m pounds of taxpayer's money has prompted the CCTA, Whitehall's computer adviser, to toughen its contracts with suppliers. ... Last year the roads service of the Dept. of the Environment for Northern Ireland found that although it had paid services company SD-Scicon 5.5m pounds for an IBM 3090 mainframe and software, it did not own the system, and was legally not entitled to use it. The anomaly came to light following a legal dispute between users and SD-Scicon in which solicitors said ownership of the system did not pass to the department until it had been accepted and paid for in full. SD-Scicon's development was never completed and the system did not undergo acceptance tests, but users in Northern Ireland had paid SD-Scicon 5.5m pounds for the first phases of work - money which was completely wasted. A Northern Ireland Audit Office report says users had to pay SD-Scicon a further 1.8m pounds on top of the 5.5m pounds to enable the department to own the IBM mainframe they had already paid for. But the IBM software was later scrapped. The department said this week it has now devised a new computing strategy to minimise risk." A most interesting story. Sell a contract based on hardware and software, don't complete the software and charge extra for use of the hardware the customer had already bought !! Dr Les Hatton, Director of Research, Programming Research Ltd, England lesh@prl0.co.uk (44) 372-462130
Markets * High Tech * Economy San Jose Mercury News, Saturday, August 15, 1992 Business section, Pages 9E and 14E Scientists cry foul over NASA security raid at Ames By Michelle Levander, Mercury News Staff Writer A security raid that one scientist likened to a "KGB attack" at NASA/Ames Research Center two weeks ago has pitted scientists who depend on the free international exchange of ideas against government bureaucrats afraid of losing economically valuable technology. On the weekend of July 31, a security force from NASA headquarters in Washington, D.C., descended on research facilities at Ames in Mountain View, changing locks, sending scientists home without explanations, searching through papers on desks and reading people's electronic mail and computer files. The security team, sent by NASA's new administrator, Daniel Goldin, then interrogated some of the most distinguished experts in the country in aeronautics research and temporarily denied about 10 researchers access to offices and computer files. Harvey Lomax, chief of the Computational Fluid Dynamics Branch at NASA/Ames, said the search — conducted by men without badges who sent people home or interrogated them without any explanation — violated the university-like atmosphere he tries to create among his staff. Lomax said he understood the need need to protect security, but, he said, in his 48 years at Ames, "I have never seen an instance of such insulting contempt." The NASA search was aimed at reviewing the center's handling of classified material and to "review our safeguarding of technologies that are important to national competitiveness," NASA/ Ames director Dale Compton said in a letter to employees this week. Compton apologized in an open letter to NASA scientists for an event that "disrupted" a work culture that "promotes an open exchange of scientific information." A center spokesman said he knew of no specific incident or security breach that prompted the search but said it was legal for the government to search employees' desks and files. Now that fears of Cold War enemies have died down, government officials are try to prevent information-sharing between government scientists and their colleagues in other countries that compete with ours. But some critics say such policies could isolate the U.S. scientific community and stymie basic scientific research normally conducted in the international community. [...] NASA/Ames scientists said they have also recently face increasingly tight restrictions on what information they can share with others and often have to submit work to a government official in Washington for approval. Scientists agree that some research shouldn't be shared but complain that Washington bureaucrats can't tell the difference between basic research and a sensitive technology transfer. In a meeting with staff this week, Compton said top NASA officials were concerned that ideas on fluid dynamics or other topics could end up in the hands of aerospace or auto companies abroad rather than U.S. firms. "He said we are funded by the United States and one of our missions is to do basic research for industry and not give a competitive edge to others," said one scientist at a meeting held by Compton on the raid. One irony apparently unnoticed by search team investigators, however, was that while they were taking action against staffers who sent computer transmissions of information abroad, scientists from Germany, France, Spain, Israel and Japan were working on Ames computers and sharing research ideas with their U.S. counterparts as the invited guests of the research center. The theoretical research done at Ames often involves international collaboration. In fact a good deal of the center's research is published in a British journal. The research units apparently targeted by the search use supercomputers to solve complex equations governing how a fluid moves, which scientists said is far removed from immediate practical applications. In such theoretical research, involving a single equation can take as much as 500 hours of supercomputer time. [The article also notes allegations of racism from the Asian-American Pacific Islander Advisory Group at Ames, and strong denials from Ames. PGN]
Well, it's worse than I thought it would be. Unix experiments through last
night showed that viruses succeeded in infecting files that didn't have read or
write access. I could even run programs with no read, write, or execute
privileges! It seems that the Unix networking allows far more than the access
controls permit to the local Unix user. Directory protection seemed to work
right, but then, I was able to load and execute files from directories with
only Execute permission - not a good sign.
I got a lot of mail about the last posting. I don't think I'm a moron, and if
someone can break Novell in 2 days, I don't think the situation gets better by
spending more time. Novell version 3.11 - I used the default installation with
no 3rd party software - I do know the difference between file attributes and
directory rights, and the inheritence does indeed work the opposite of the way
the manual describes it. I am replacing the renowned virus marketing expert
John McAfee at the Vbull conference - first speaker on the first day - I think.
Full details of the experiments will be published at that conference, and after
we get some more experiments done, I hope to submit to Computers and Security.
Perhaps some of you should read the paper before making assumptions and calling
me names. In anticipation of more questions about Unix, System V3.2 with Sun's
PC/NFS on the PCs. Default installation - I still don't think I'm a moron - No
I haven't tried setting the file system to Read-Only, I am only looking at how
an average network might be installed by an average administrator, not at how
the world's leading expert on Novell might do it after spending a year to get
it right. Want to repeat the experiment? I think the paper provides adequate
documentation to allow a thorough repetition, and we repeated the test with
independent people watching to make sure we weren't doing something wrong. By
the way, the peron installing the Novell has done a number of commercial
installations before, and to claim that they know nothing about how to make
Novell safe is confirmation of the fact that it is hard to understand the way
inheritance, rights, and attributes work together, and that many Novell
installations may be unsafe. I doubt if any legitimate and knowledgeable
people from Novell will disagree with my findings once they come to the
conference and/or read the paper.
Which brings me to one last point. I got a lot of complaints, but only
one person wanted to perform similar experiments to confirm our results. There
is a big risk associated with unconfirmed (or refuted) results. I don't
believe all I read either, but if I really want to know, I repeat the
experiment or ask for more details.
FC
In Risk Forum Vol.13, Nr.74, Adrian Howard summarizes a report in UKs (quality)
newspaper Independent about a hacker attack on Barlays (Hamburg) Credit Card
Service. The original article to report the fact (which was also mentioned in
German TV, 1st channel, on Sunday August 16, 1992) appeared in the weekly
magazine "Der SPIEGEL" (also regarded as quality press product) which had
issued a press release on Sunday (marketing).
Having been asked on Sunday (immediately after returning from a sailing trip)
for some comment (for another publication), I preferred to analysed the case
myself in more detail. My findings regarding the facts are less spectacular
(though some information holes may never be filled), but now I understand why
"Der SPIEGEL" blew up this story (see background).
The facts: Barclays Credit Card Service offers advice via a published
130-number (tool-free, equivalent to 800 in USA). During non-office hours, to
record questions and messages of customers, Barclays has a computerized
telephone call recorder, using a Meridian system of Northern Telecom.
Incoming calls are recorded on the system's store in sequential
order. According to "Der SPIEGEL", messages of the following kind
were recorded:
message #3 (date/time recorded): person NN1 asks to increase the
credit limit from 3.5 kDM to 8 kDM;
message #7 (date/time recorded): person NN2 reports that his new
card with given number and account had arrived.
The Meridian system enables remote invocation of the stored invocation of the
stored information, as many telephone call recorders do. In this case, a
special combination of telephone keys plus a 3-digit code enables to listen to
the recorded voice mail from any telephone (but using the same technique which
hand-held devices for remote operation of telephone recorders use).
According to Der SPIEGEL, "888" was used as secret code; Barclays responsible
manager (a marketing expert) denied that but admitted that only a 3-digit key
was used.
Der SPIEGEL describes the potential misuse of credit cards in some detail.
Indeed, knowledge of credit card numbers, accounts and expiration dates allow
misuse in telephone trade etc.
Analysis: A1)Without doubt, Meridian is computerized equipment which moreover
can be directly connected to work stations and mainframes for automatic
processing. Barclays regarded this as "merely a telephone recorder" even when I
spoke to them (they argued that this is not a Computer Security problem so I
should not be interested!) Unfortunately, as no personal data files in the
normal sense are stored, the German national and the Hamburg state Data
Protection legislation do not apply; therefore, Hamburg Data Protection
ombudsman Dr.Schrader's reaction ("unresponsible") behaviour as mentioned by
Adrian Howard was not justified by legal evidence.
A2) As the Meridian system allows for significantly longer
authentication code (at least 6 digits, while Barclays used only 3), and as the
feature to automatically enforce a new code after a given period was not used
by Barclays, they used the digital message recorder not in the safe way which
the nature of the customer information deserved. Only after the journalist's
recherche, they are now reconsidering this problem.
A3) The responsible manager said that NO connection to their mainframe
was installed. After some discussion with him and some contradicting
information, some doubts remain. He told me that a major revision of the
system's use is underway (and that his experts do not have time to answer my
few questions) but when merely used as telephone recorder, improvements are
easy and fast to install (as Northern Telecom specialists worked there).
In the SPIEGEL report, there is no evidence for a break-in into Barclays
mainframe but their denial to allow me to see the system with several,
partially contradicting reasons given at times leaves some doubt (background: I
supervise the largest European backup center for banks, insurances etc, with a
300 MIpS/1.0 TByte machine and inspect large computer centers on a regular
basis).
A4) In the last part of SPIEGEL's article, there are several references
to Kimble's case (see my corresponding report in July) who demonstrated a new
phreaking technique to the German economic monthly "CAPITAL" (and a German TV
station). Presently, some research "from a Cologne as well as from a
Californian security advisory enterprise" are underway, according to Der
SPIEGEL, and in these cases, "computer kids .. received significant
honoraries". There is indeed evidence that competing hacker and phreak groups
(esp. Kimble with CAPITAL versus Chaos Club which was cited as information
source by Der SPIEGEL) seem to entertain a showdown for honoraries. Kimble, in
several (paid) interviews, made some negative comments on Chaos Club. As CCC
explicitly (citations) and implicitly (some undocumented role in the phreak
action) is connected with this case, it is not improbable (to be cautious) that
this phreak attack was one reaction to the Kimble case. It is interesting to
remember that several Hamburg journalists (then at a TV station, one of which
works since some time for SPIEGEL) first reported Chaos Club's NASA and KGB
activities.
Summary: The report of SPIEGEL (and those derived from it) concerned a phreak
attack on a digital telephone recorder; the presentation of the facts
and esp. implications for a bank computer attack were inadequate.
The attacked bank demonstrated a shockingly insufficient knowledge of
security demands and procedures related to a new digitized service.
Klaus Brunnstein, University of Hamburg (August 20, 1992 8:15 pm)
Update of Barclay Hamburg Credit Card Service's Voice Mail insecurity: The evident contradiction between Meridian Mail's minimum keynumber length (4..16 digits) and the fact that a 3-digit code was used found a surprising explanation: Northern Telecom requires for the US/Canada product *at least 4 digits code*, whereas the German version was reduced to require *at least 3 digits*. This has possibly to do with the fact that most European customers have smaller telephone systems with less than 999 lines connected. After this incident, Northern Telecom Europe decided to improve European applications to US/Canada standards, requiring 4..16 Bytes. Moreover, they will put more emphasis on enfording regular changes of keynumbers. According to Northern Telecom experts, Barclay connected a WYSE terminal for service purposes via RS 232 port; the general software needed to connect the Meridian Mail system to another computer (sw Meridian Link) was not installed, said NT officials. This implies that the surprisingly long time needed for security improvement (more than one week of several experts, including NT personnel) was needed to upgrade the knowledge of the "experts". As security improvements are really simple (about 1 hour), serious doubts remain (even assuming maximum incompetence of Barclay Hamburg "experts"). The Hamburg Data Protection Ombudsman presently examines the case; he assumes that the digitized system has a file of personal data which entries may be individually retrieved, such that Data Protection laws apply. There is some doubt that the legal definition may apply to a flat file of characters without any ordering structure and no retrieval functions available in the system. Klaus Brunnstein (Univ of Hamburg, August 27, 1992)
I discovered a situation very similar to the Barclays voice-mail incident,
right here in the US.
Sometime a couple years ago my roommate received a letter from a company called
TeleCredit regarding his Visa charge card that was issued to him by a small
local bank. Apparently, TeleCredit was contracted by the small local bank to
handle the issuing and billing matters of the credit cards that the local bank
was offering.
The letter requested that my roommate call a 800 number and with a touch-tone
phone enter a certain extension and leave his account number and name and a
short statement that they did receive their card in a recording. I found this
very interesting and gave their voice-mail system a call.
Since I am a hacker, I instinctively pressed the # key followed by the voice
mail box number to enter the mail box, and found to my surprise that there was
no password protecting the messages people were leaving! I wasn't as surprised
as others might be since as a seasoned hacker I knew this kind of situation was
all too common.
For [a?] month I called the voice mail box and listened to about 30 messages a
day of people leaving their names and credit card numbers and SSN numbers and
daytime phone numbers. Unlike the letter, the greeting to the voice mail box
requested they leave such info. Being inside the voice mail box could have
even allowed me to change the greeting to ask for other sensitive info, and
common folks not knowing any better would have left it with no hesitation. Of
course, I did no such thing. If I were malicious, I might even change the
password and TeleCredit, not knowing how to set a password, would have taken a
few weeks to figure out how to change it back and thus would have a major
interruption in their card accounting procedure.
I suspect a similar thing happened with the CCC and Barclays, and all Barclays
need do is read their voice mail system manuals. No need to hire CCC to come
in and explain it for them. All CCC has to say is rtm (read the [...]
manual). I wonder if I had broken my little discovery to the press it would
have become the media circus the CCC is always striving for. I can see the
headlines now: "Hacker Cracks Credit Card Database; Privacy of Thousands of
Accounts In His Hands!"
Luckily, TeleCredit wised up after about six months and has apparently
discontinued the practice of having customers report their account numbers to a
voice mail-box, for the mail-box was discontinued. However, other less
sensitive mailboxes still lie wide open.
I still have recordings on tape of the messages people were leaving on that
TeleCredit mailbox that I forgot about, the Barclay article made me remember
that I had still had them.
Amadeus
[ADDED NOTE: The system flex.com has cut its UUCP feed do to financial
considerations, so any mail to that account would have bounced (as it
would now). You can reach me at indaleci@uhunix.uhcc.hawaii.edu,
courtesy of a friend. Thank You, Amadeus]
An article in the July 1992 Siam News by Robert Skeel contains more information
on the Patriot missile bug. Apparently the program contained representations of
.1 as both 24-bit and 48-bit fixed point binary numbers. If either had been
used consistently there would have been no problem. However using both proved
disastrous as it introduced errors of the form (.1d-.1e)*t (where .1d is the
48 bit representation, .1e is the 24 bit representation and t is the time
elapsed since the clock was zeroed). I got the impression that the software
was written in a pretty slipshod way.
James B. Shearer
Readers of risks may be interested in a one-page article in the August issue of
BYTE magazine by Richard Stein entitled "Safety by Formal Design" (p157). This
article cites the Therac 25 accident and the possibility of using formal
methods to help prevent such accidents in the future.
I first learned about this article when our librarian started to receive many
requests for a Technical Report on "Safety-Critical Systems, Formal Methods and
Standards" (PRG-TR-5-92) by me and Victoria Stavridou which is referenced in
the article. This report was compiled from a wide range of sources, including
a request for information on RISKS. Because there seems to be considerable
interest in the report, I am making it available via FTP to save some of our
mailing costs to those on Internet with FTP access and a PostScript printer. If
you wish to obtain the report, use anonymous FTP to "ftp.comlab.ox.ac.uk"
(192.76.25.2), change directory to "Documents/techreports" and get the
PostScript file "TR-5-92.ps". If you do not have FTP access, you can obtain a
paper copy by sending your name and address to our librarian on
<library@comlab.ox.ac.uk>.
<Jonathan.Bowen@comlab.ox.ac.uk>
Jonathan Bowen, Oxford University Computing Laboratory
I thought I'd mention that the IEEE Spectrum Magazine, August 1992 issue, is all about Data Security. And one of the articles, `A security roundtable' includes an artist's view of our moderator, Peter G. Neumann ! A bonus article is concerned with reliability and MIL-HDBK-217, long the bible of the U.S. defense industry. All in all, pretty interesting reading, recommended to all RISKS readers ! Olivier M.J. Crepin-Leblond, Digital Comms. Section, Elec. Eng. Department Imperial College of Science, Technology and Medicine, London SW7 2BT, UK
In fact, this is an appropriate subject for a geography course. But I still
find the placement in that department as an interesting development.
From: abw@bucrsb.bu.edu @ uucp
Date: 08-26-92 14:56:10 EDT (08-26-92 15:16:29 EDT)
Subject: Internet courses
Is there any place around here where an actual COURSE on the Internet is
taught? At MIT, or any of the other schools, or anywhere?
Boston University is offering the following this Fall. ---Al
>From sam@bu-it.bu.edu Mon Apr 1 05:05:46 1992
Subject: New Geography course offered this fall.
COMPUTER NETWORKS AND SOCIAL NETWORKS
IN DEVELOPING COUNTRIES (GG 792)
Prof. Sheldon Annis Fall 1992
Geography Department Thursday, 3:30-6:30
467 Stone Science Bldg, Classroom: TBA
3-5742 (tel); annis@bucrsb (email)
Computer networks, such as the Internet, are beginning to penetrate Eastern
Europe, the Commonwealth of Independent States, Africa, Asia, and Latin
America. As a result, students at BU have access to vast new information
resources and can now communicate electronically with researchers around the
world. This course explores the implications of this new connectivity and
teaches students to use these powerful new research tools.
Substantively, the course examines how new information and network technology
is affecting people in developing countries. The evolution of networks, their
political and economic consequences, and issues in informatics policy will be
discussed. Case material will be drawn from Central America, the Philippines,
and Africa. Special attention will be paid to World Bank lending in developing
countries. Computer networks, GIS, and satellite communication technology
(e.g., VitaSat and SatelLife) will be explored.
Students will learn to use networks based on Internet, BITNET, UUCP, and
Fidonet technology. (Fidonet is especially important in Africa.) Students can
expect to access a wide variety of overseas networks, and should be able to
contact researchers in most countries. They will learn basic skills such as
the exchange of e-mail, conferencing, and FTP (electronic transfer of
documents), as well more advanced skills such as remote searching of library
catalogs, use of electronic data bases, access to electronic journals, use of
newsgroups, and interactive ("real-time") conversation over the Internet. They
will also be introduced to a highly advanced generation of new software --
sometimes called "knowledge robots", or "knowbots" — which can search for
information _across and through_ vast, decentralized networks (also called
Wide-Area Information Servers).
_Prerequisites and limitations_: This course is intended for graduate students
with well-developed research interest in developing countries _or_ students
with strong technical backgrounds who want to explore the applications of
network technology. Some knowledge of computers is assumed, though not
necessarily of networks. Limited to 15 students.
_Texts_: _Zen and the Art of the Internet_ by Brendan P. Kehoe, and readings on
developing countries.
Note: this course is not yet listed in the current _Schedule of
Classes_, but it _is_ being offered.
Please report problems with the web pages to the maintainer