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…
21-year-old Jason Mewhiney was arrested by the Canadian RCMP on 27 charges related to using a computer in his home to access computer systems of the U.S. government (including NASA and NOAA, the National Oceanic and Atmospheric Administration), as well as Canadian and U.S. universities. In one case he allegedly caused "extensive damages". [Source: Canadian news sources, 13 May 1998, PGN Abstracting]
NASA to be "Hacked" by DoD
What Macro Virus infected communications with Mir?
As a follow-up to the "Eligible Receiver" DoD Joint Staff Tiger Team
penetration tests done in June 1997, the National Aeronautics and Space
Administration (NASA) has asked the US Department of Defense (DoD) to
perform a penetration study of its computer networks using "known security
vulnerabilities" to "determine whether the space agency can fend off
cyber-intruders who could threaten launch-control and other critical
operations," as reported in this week's Defense Week newsletter, and AP
report, "Agency will try to 'hack' into NASA computers", 09-May-1998.
The "penetration study" of the unclassified computer networks is an effort
to determine how easy it is to access sensitive sites or data and whether
they can be accessed through the Internet. A classified report will be
issued with the results of these tests, and suggestions for improvements in
NASA's information-technology security.
[It might seem less expensive to hire Jason Mewhiney, especially if
the judge requires him to do lots of hours of free public service.
Although that would be considered a bad security practice by many folks,
it seems to me to be an even worse practice to use systems that are so
easy to break in the first place. Same old story for RISKS readers. PGN]
NASA has had problems with Computer Virus contamination in the past. In
October 1997 NASA spread a Macro Virus (which infects MS Office products
such as MS Word wordprocessor) from Houston to Moscow, and infected the
workstations that are used for Mir spacestation ground control including
daily communications with the Mir Crew. While the on-board computers on the
Mir spacestation were not infected, the laptop used by the American
astronaut was.
Most Macro viruses are not harmful or destructive, yet this one seems to
have been causing problems. Both IBM PC's, and Mac "ground units" were
disrupted, while the high-end DEC Alpha workstations were not affected.
"The Russians often have outdated anti-virus software or none at all, while
NASA was busy upgrading to the latest version of Norton Anti-Virus." The
Virus was eliminated from all machines by October 17th. To avoid
re-spreading the virus, communications between Houston and Moscow were
affected, e-mail attachments could not be used, forcing Fax use. "This may
be one of the first example of a non-Russian problem, a mishap of American
origin, associated with the Mir spacecraft."
If anyone knows what specific Macro virus this was, its name, please post
here or send me that information?
Virus contamination makes up about 26% of all Information Technology
Security problems, and with outside system penetration somewheres around 7%
to 13% but rising. To prevent problems, Computer/Network Security must have
"Defense-in-Depth" which should include:
+ "Tiger Team", penetration testing.
+ Use of "Current" Anti-Virus detection software.
+ Use of Intrusion Detection Software (IDS).
+ Use of Firewalls, and Secure Gateways.
+ Use of effective Access Control.
+ Use of Cryptographic technology for confidentiality - encryption,
non-repudiation - Digital Signatures, and Authentication.
+ Use of secure and hardened Operating Systems with all
current security patches loaded.
+ Risk Analysis.
+ Auditing, Audit Trail.
+ Management awareness, Good Security policies, practices,
procedures, and controls in place.
Reference: Federal Computer Week (FCW), October 20, 1997,
"NASA, Virus infects communications with Mir",
Heather Harreld.
Robert Perillo, CCP, CNE Richmond, VA perillo@dockmaster.ncsc.mil
Staff Computer Scientist perillo@gibraltar.ncsc.mil
from the Australian (online e-mail newsletter) Net News 11 May 1998 (farrelly@newscorp.com.au) Newsbytes today reports an e-mail version of the Sorcerer's Apprentice: Tim Durkin, deputy prosecutor of Spokane County, was out of the office a few days last week, so he programmed his PC to auto reply to any e-mails. But he inadvertently flagged each reply to be sent to all 2,000 users on the network - and worse, requested confirmation for each message. Within four hours of Durkin walking out the door, 150,000 e-mails had blitzed the system. Even though technicians disable the commands, Durkin returned to work to find 48,000 messages sitting in his e-mail and has been receiving 1,500 a day since. Martin Howard, iGM Design, Australia, South Brisbane, PO Box 267, Mt Ommaney Q. 4074 martin@thehub.com.au +61 7 3846 7880 www.igm.aust.com/~igmnet [Not to mention the hate mail from annoyed people... PGN]
The risk here is that an e-mail that was intended to be sent encrypted is instead sent as cleartext, thanks to a completely avoidable bug in the interface. Obviously the interface testers dropped the ball here in a big way. http://www.wired.com/news/news/technology/story/12249.html Security Bugaboo in MS Outlook? by Michael Stutz, 12 May 1998 The user interface of Microsoft's Outlook 98 e-mail application is the cause of a new security-related bug, where users could be fooled into thinking that an unencrypted communication is actually encrypted — thus sending potentially sensitive information in plaintext over the wires. "The problem manifests itself two ways," said Scott Gode, Microsoft product manager for Outlook. "One is that the message is not digitally signed, and the second is that the message is not encrypted." VeriSign Inc. makes the digital certificates that are used with the S/MIME encryption in Outlook 98; these certificates are used to encrypt and create digital signatures for messages sent with the program. The bug arises when a user creates an encrypted message and then tries to cancel it — the message is not cancelled, but is sent, sans encryption. When a recipient replies to the message, thinking that it was an encrypted communication, the reply email is also sent with no encryption. "All further messages sent in reply from either party are sent as unencrypted plaintext messages. And there's no notification to anybody along the way at any time," said Russ Cooper, consultant and moderator of the NT Bugtraq and NT Security mailing lists. Cooper discovered the bug while testing the S/MIME crypto features of Outlook 98. The flaw is not in VeriSign's crypto implementation, rather it's in Outlook 98's user interface. "This is mainly a user interface issue," said Gode. "The architecture and integrity of what we're doing is not flawed — it's just the way that the software responds to the dialog box." "It looks to me that this is very specific to this implementation," said Glenn Langford, group manager for desktop applications at security and crypto software company Entrust Technologies. "This kind of thing wouldn't happen in our scenario, because in an Entrust environment, what we're doing is not just issuing certificates -- we're doing the certificates, the key management, toolkits, and the email plug-in implementation all at the same time," he said. The weakness of the VeriSign situation, he said, is that it's up to the implementor of the email package — in this case, Microsoft — to do the security properly, because there's no toolkit running on the client platform. So if there's a bug involving the email package, even though the VeriSign application functions perfectly, there's a security hole. Bruce Schneier, crypto expert and president of Counterpane Systems, is fascinated by the bug. "It's yet another example of cryptography broken by bad user design," he said. "This works counter-intuitively." "They've gotta fix it — they can't wait for the next version, in my opinion," Cooper said. Microsoft, however, is unable to reproduce the bug. "We've been able to reproduce the problem of [a message] not being digitally signed," Gode said, "but have not been able to reproduce the problem of [a message] not being encrypted, which is obviously the more potentially damaging of the two." Gode said that the company had been aware of the bug from other sources since late April, about a month after Outlook 98 was released. He said that the company has contacted Cooper — who made his description of the bug public on Friday -- with the hope of getting more data so that they could reproduce it. As to what causes the second part of the bug, where the message is sent unencrypted, Gode said that any number of possibilities could be involved, including how Cooper configured his machine — or an error on Microsoft's part. "It could be a legitimate thing that we messed up on," he said. "I'm not ruling that out, but because we can't reproduce it and because we're not hearing this from other people, it's hard to say at this point." How could such a simple bug have slipped through development testing? "People don't notice, because code is complicated," said Schneier. "This is the big problem with the Net. Look at Netscape Navigator: It comes out, bugs are found, bugs are fixed; more bugs are found, more bugs are fixed — you'd think it gets better, but then a newer version of Navigator is released, with 80 percent more source code, more lines of code," he said. "There's absolutely no substitute for public scrutiny," Schneier said. "But you only get scrutiny to the level of what's public." And so if any portion of the code is unavailable for scrutiny, the security risk is increased. "Not just the security portion of a code can compromise security," Schneier said. "Just because the digital signature and key management [portions of the source code] are correct, doesn't mean that you can't write a user interface that breaks the security." Not everyone thinks this bug is so catastrophic. "It would be a bug of a different magnitude if the user who sent the original message had every reason to believe that it were sent encrypted," said Ted Julian, an analyst at Forrester Research. As for when the bug will be fixed, Microsoft said it will play it by ear. "If [the problem] is severe and if it's something that it turns out we're able to reproduce — and we think it could cause problems to other users — that might necessitate some sort of little patch that we could make available on the Web," said Gode. "If it remains just the digital signing problem, that would be something we'll probably just have people live with for now until an interim release — if there is one — or until the next version comes out." Check on other Web coverage of this story with NewsBot James Glave, Senior Technology Writer Wired News http://www.wired.com (415) 276-8430
In reply to the RISKS-19.71 note on GPS jamming, there are two known cases, both apparently of military origin. See our self-explanatory article below. As for iris scanning in 19.71, I witnessed a real life test at a recent security fair. The boss, Mr. X, told his secretary to look at the scanner and say: "I'm Mr. X". She did and, Bing, the scanner opened the door lock. Before using iris scanner, get some independent quantitative statistics on error rates. Olivier Schmidt, Editor, "Intelligence", adi@ursula.blythe.org www.blythe.org/Intelligence Intelligence, N. 79, 4 May 1998, p. 6 GPS - "Chief, Where Have All the Dials Gone?" By debunking a supposed threat to civil aviation by a four-watt signal jammer developed by a Moscow-based company, Aviaconversia, which was displayed last August and supposedly has a range of 200 km (see "GPS - Jammers Too Good for Their Own Good", INT, n. 76 6), "Intelligence" raised a few eyebrows and a few questions. In fact, airliners navigate with at least three systems, of which a maximum of two are L-band GPS navigation aids which the Russian jammer could possibly attack. However, not long ago, a British Airways (BA) flight over central France lost all three of its GPS navigation systems. But in this case it wasn't civilians. The French military were secretly experimenting with new GPS jammers and "forgot" to tell BA (INT, n. 77 3). We have now learned of a similar incident in upstate New York where the US Air Force Research Laboratory Information Directorate (Rome Lab) was apparently testing a five-watt GPS "transmitter" on the ground. On 30 December 1997, a Continental DC-10 flying over the area lost all GPS signals. The press reports apparently got things wrong: the GPS transmitters are in the sky, on satellites! What are on planes and on the ground are "receivers" and if Rome Lab was playing with anything, it, like the French military, were testing GPS jammers.
Cellular phones are not permitted in the hospitals I frequent due to fear of interference with critical support systems. Wouldn't it be safe to say that a transmitting device that would block cellular phones would be transmitting in the same band that the phones use, hence posing the same threat to the critical systems?
The CNN Interactive site has a pointer today to a news report about how
"teenagers are more likely to admit to risky behavior when answering
questionnaires in a computer than when filling out a written survey":
http://www.cnn.com/TECH/science/9805/14/t_t/teen.survey.technique/
Possible risks:
(1) The article doesn't say what assurances the surveyors used
to accurately measure demographics and prevent duplicate
submissions; hopefully the surveys weren't of the "vote
anonymously as often as you like" type.
(2) If the data is accurate, it shows that people believe that
online surveys protect their anonymity more than on paper,
an assumption whose flaws will be apparent to RISKS readers.
Brent J. Nordquist / bjn@visi.com / W: +1 612 905-7806
[Courtesy of Martin Minow. PGN] The MS CryptoAPI mailing list recently carried an example of how an actual "You are now in France" attack might work. It turns out that if you switch the system-wide locale of an NT system to French, the encryption functionality of CryptoAPI disables itself (signing and hashing still works). Conversely, switching the locale from French to something French-related (Belgian, Swiss, or Canadian French) re-enables the crypto. Since NT allows per-thread locales, it'd be interesting to see if you can selectively enable/disable the crypto for a particular application without needing to change your system-wide locale setting (set the system locale to French Canadian, then set the thread locale to French so you get the UI acting as "French" French but the crypto acting as Canadian French). Peter [Added note from Peter Gutmann:] France does not allow the use of strong crypto. Thus, a proposed attack on systems that take this into account is to fool them into believing they're operating in France, whereupon they quietly disable their crypto. What NT is doing is a fairly reasonable way to comply with a silly restriction, but it does provide a good example of how a "You are now in France" attack might be performed.
Perhaps you can explain to me what sort of sudden neurological condition went
through the brains of the folks at ZDNet? I received this tonight (a Friday
night, of course, so my response is likely to sit around all weekend):
> From: announce@zdnetmail.com
> Date: Fri, 15 May 1998 21:35:27 -0700
> Reply-To: support@zdnetmail.com
> To: [an obsolete address]
> Subject: Announcing ZDNet Mail !!
> Announcing ZDNet Mail - the best free email on the Web!
> ZDNet is pleased to announce the launch of ZDNet Mail, the best free email
> on the Web. Because you're a valued member of the ZDNet community, we're
> providing you with a free, secure, e-mail account, that you can access from
> any Internet connection, anytime or anywhere.
> As a current ZDNet member, your e-mail account is already set up — you can
> start using it today! Just log on to ZDNet Mail at:
> http://www.zdnetmail.com
> and enter your current ZDNet user name and password as shown below:
> User Name: [deleted]
> Password: [sent in plaintext!]
> [...rest of message deleted...]
Now, first of all, I didn't ask for this. I haven't even accessed the ZDNet
site with my username and password for months. But they've apparently sent
out at least thousands of these, some of which are bound to be intercepted
and read---and immediately taken advantage of.
Now, ZDNet *does* have a privacy statement, which reads in part:
ZDNet uses reasonable precautions to keep the personal information
disclosed to us secure and to disclose such information only to third
parties we believe to be responsible.
but somehow, sending out thousands of plaintext passwords along with account
names doesn't exactly strike me as a "reasonable precaution."
Of course, I've asked that they remove both my "best new free e-mail" account
immediately, along with my ZDNet account. But they probably aren't even going
to see my message until Monday.
Lessons learned:
* Just because a website has a privacy statement doesn't necessarily
imply that they know what it means.
* Even a website that you might assume has a clue (after all, ZDNet is a
computer-magazine publishing company, right?) may have a big empty spot
where their brains are supposed to be.
* It pays to have a different password for *every* site you visit.
Those idiots.
Ken McGlothlen <mcglk@serv.net>
NTK now is, as it says, "*the* weekly high-tech sarcastic update for the UK,"
and rather a hoot for others as well. However, something from this week's
issue sounded like it was right up the RISKS alley:
------- Forwarded Message Follows -------
Date: Fri, 15 May 1998 12:34:09 +0100
From: "Danny O'Brien" <danny@flirble.org>
[...]
Remember when NORTEL announced the IP-down-the-power-lines hack, and
everyone racked their brains to work out the killer flaw? Was it, perhaps,
the isolation equipment you'd have to install into every house that used it?
Or the fibre lines Nortel would have to spool out from each substation?
Well, here's a likely contender: Nick Long from the Low Power Radio
Association reports that streetlamps in the Nortel trial region have been
acting as highly efficient antennae, merrily broadcasting packets across
much of the shortwave radio bands. Bad for radio hams, not brilliant for
personal privacy - but what a great solution for multicasting Web events!
http://www.gcd.co.uk/comment.htm
- see, we told you it was the new CB radio
http://www.lpra.org/
- get IE4.0 to play "Daisy, Daisy" on your radio
[...]
Need to Know is a useful and interesting UK digest of things that happened
last week or might happen next week. You can read it on Friday afternoon or
print it out then take it home if you have nothing better to do. It is
compiled by NTK from stuff they get sent. t is registered at the Post
Office as "the Treat of Versailles".
NEED TO KNOW: THEY STOLE OUR REVOLUTION. NOW WE'RE STEALING IT BACK.
Archive - http://www.ntk.net/ Excuses - http://www.spesh.com/ntk/
Subscribe? Mail majordomo@unfortu.net with 'subscribe ntknow'.
Apart from the usual Y2K problems that are common throughout the world, Sweden has another major problem to tackle - personal numbers. In Sweden each individual has a so called personal number. This number consists of: date of birth (6 digits), region in which the individual was born (2 digits), gender information (1 digit which is also used to count the number of births each day, odd numbers for males and even numbers for females) and a simple checksum (1 digit). This personal number is used _extensively_ in both private and governmental databases. Experienced RISKS readers should have no problem identifying at least two major problems with the above scheme: 1. DOB is only 6 digits making it Y2K-incompatible. We already see a fair amount of press about elderly people being treated as new- borns. This will surely sky-rocket unless the thousands of databases that use the personal number as identifier are updated. 2. The potential for criminals wanting to impersonate someone or collect information about someone. "Banks and Y2K - those that owe you money will go bankrupt, and those you owe money will demand a gazillion in penalties for 100 years of unpaid interest." Daniel Eriksson, Software Engineer, Ericsson Radio Systems AB Daniel.Eriksson@ericsson.com
Embedded systems are finally getting noticed.
http://www.iee.org.uk/2000risk/
recommended for embedded systems.
<L.Wood@surrey.ac.uk>PGP<http://www.sat-net.com/L.Wood/>+44-1483-300800x3641
---------- Forwarded message ----------
Date: Fri, 8 May 1998 21:26:44 -0400 (EDT)
From: "Robert S. Thau" <rst@ai.mit.edu>
Cc: FoRK <FoRK@xent.ics.uci.edu>
Subject: GAO Report on Y2K problem
Jim Whitehead writes:
> This report reminds me of those Star Trek episodes where the computer calmly
> announces, "the ship will self-destruct in five minutes". "The country will
> experience significant economic disruption in 1.5 years."
Personally, I'd be thrilled with significant economic disruption. The
feasible alternatives are rather worse. A useful reality check is the
article on Y2K issues in industry in the Fortune 500 issue (I believe)
of Fortune magazine. This goes through problems which such outfits as
G.M. are finding in audits of their factory floor embedded systems ---
it's not a pretty picture. See
http://www.pathfinder.com/fortune/1998/980427/imt.html
(Of course, there are industrial embedded systems, like those in power
plants and the distribution grids, on which just about everything else
in the country depends. If those go down, and stay down for more than
a few days --- say, several weeks --- we can stop counting dollars and
start counting dead. Sigh...).
rst
Recently I saw a credit card valid till 21 (it means 2021). I suppose the 2 is coming from the first digit of 2001 and the 1 from the last digit of 2001. A very creative error. The story of Y2K is not finished. Jean-Jacques Quisquater
> "Every few hundred years, throughout Western history, a sharp > transformation has occurred. Oh, humph. You want a sharp transformation, look at the period from 1840 to 1860. In 1840, if you wanted to send a message or a package to someone else, you gave it to a guy on a horse or in a sailboat who would proceed at a walking pace in the direction of the recipient. Getting news or goods between New York and San Francisco or London took weeks and was subject to large unpredictable delays. By 1860, there were telegraphs, railroads, and steamships, so messages could go anywhere in the developed world in a few minutes, and goods were delivered on predictable schedules. These were at least as wrenching changes as anything in this century, and we're still getting used to them. John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 387 6869 johnl@iecc.com, Village Trustee and Sewer Commissioner, http://iecc.com/johnl,
The *Guardian* (13 Apr 1998) has a report from the Associated Press newswire that according to officials in Dhaka, a cat shorted a circuit in the control room of a power station, plunging much of Bangladesh's capital into darkness at the weekend. The RISKS? The cat was obviously patrolling the wrong part of the plant looking for power-cable-gnawing rats, but how a circuit had become bare enough that an unauthorised feline, let alone personnel, managed to short the circuit, is anyone's guess. There is no mention, alas, whether or not the cat had used up its full quota of nine lives, or if it had relinquished any for any subsequent reincarnation... Mark Corcoran, VMS Systems Manager, Teletext Dept.,Softel Ltd. +44 (0)118 984 2151
RISKS readers may be interested in hearing about Developing Software for Safety Critical Systems, a new video from the IEEE, presented by Mike DeWalt, FAA, National Resource Specialist; John F. Besnard, Raytheon Systems Company; and Dr. Jeffrey Voas, Reliable Software Technologies; Dr. Samuel J. Keene, IEEE Reliability Society Past President, served as program moderator and technical editor, and sponsored by the IEEE Reliability Society and IEEE Educational Activities [Truncated for RISKS. Contact Gary for further information.]
Please report problems with the web pages to the maintainer