The Computer Science and Telecommunications Board (CSTB) of the National Research Council (NRC) has completed a congressionally mandated study of national cryptography policy. The final report, Cryptography's Role in Securing the Information Society, will be released to the public on May 30, 1996 at a public briefing. Many of the authoring committee members will attend. The public briefing will take place in the Main Lounge of the National Press Club, 14th and F Streets, N.W., Washington, D.C., from 1:00 PM to 3:00 PM, on Thursday, May 30, 1996. Committee members will respond to questions from attendees, and a limited number of pre-publication copies of the report will be available at that time. By the close of business on May 30, a summary of the report will be made available through http://www2.nas.edu/cstbweb; the full publication will be made available when final printed copies of the book are available (probably around the beginning of August). The committee also intends to conduct a second public briefing on the report in Menlo Park, California at SRI International. The briefing will be held in the Auditorium of the International Building from 10 to 11 am on Wednesday, June.5. The address is 333 Ravenswood Avenue, Menlo Park, California, 94025. For more information about the briefing at SRI, contact Alice Galloway at 415-859-2711 (email@example.com). If you have suggestions about other places that the committee should offer a public briefing, please let me know (firstname.lastname@example.org or 202-334-2605). If you wish to be kept informed of various other public activities regarding dissemination of this report, you can sign up for an e-mail list by visiting the web page ttp://www2.nas.edu/cstbweb/notifyme.html. I apologize to you for the short notice on this invitation, but hope that you will be able to attend. Herb Lin Senior Staff Officer Study Director CSTB/NRC Study of National Cryptography Policy
The *Wall Street Journal* of 22 May 1996 (A18) reports that two Japanese firms lost about 55 billion yen when criminals counterfeited the stored money cards that they manufactured. These cards are used to pay for pachinko games, but you can get refunds wired to an account if you cash in a card. If my memory serves me correctly, there is a certain amount of skill involved. If you play well or are lucky, you might even add money to the cards. But I'm not sure about this detail. In any case, the people with the counterfeit cards could get refunds when they didn't pay for the original card. The Journal mentions three interesting details. First, the cards were pushed by the police as a means to track the flow of cash and stop money laundering. Obviously, there wouldn't be these losses if they could really track the flow. Second, the convenience of the new cards initially boosted profits because it was so much easier to play with the cards that automatically kept track of your money. Finally, the Journal reported that there are 18,244 pachinko parlors in Japan.
I serve on the Iowa Board of Examiners for Voting Machines and Electronic Voting Systems, and last Monday, we met to examine a new modem feature added to the already approved BRC Eagle mark-sense voting machine. One question that came up immediately is that, given the fact that Iowa's current voting law bases the official canvass of votes on hand-delivered reports from each precinct, what value does a modem serve? The answer is trivial -- unofficial counts phoned in from the precincts are routinely used to compute unofficial totals that are then released to the public and press soon after the polls close. Right now, these totals are usually phoned in manually (or should I say, orally), but a modem in the voting machine can easily serve the same purpose. An aside: Why the big push for instant results? Sure, the press wants fast access to the totals, and counties compete to see who can get their totals in first, but we'd probably be better off as a nation if there was a news blackout on vote totals until the day after! It seems likely that electronic reports will soon be used to formulate the official canvass. Currently, the canvass is done by reading the tapes printed out by computerized voting machines and manually (or with the aid of calculators and computers) tallying the votes; this introduces a needless source of error. Because of this, we decided to examine BRC's new modem feature with an eye towards the possible incorporation of direct electronic vote total reporting into the official canvass. An obvious question that comes up in this context is, how secure is the system. BRC's written answer to this question (one I submitted in writing in advance) boiled down to: 1) BRC uses a proprietary protocol 2) The central host, on receiving a report by modem, gives no feedback until it receives the whole packet of vote totals. 3) The central host demands that each voting machine present the correct 8 digit ID code before it accepts a record of votes cast. 4) Each voting machine has a 4 digit ID code that is padded to 8 digits to make the required ID code. 4) Failed connection attempts are logged and flagged on screen at the central site. Needless to say, the idea of a 4 digit PIN being sufficient didn't impress me, nor did the idea of security through obscurity. The lack of feedback helps security, but in a jurisdiction with hundreds of voting machines, the 4-digit code space will be pretty full. As a result, we had an interesting discussion of the security issue; this ended when Herb Deutsch from BRC, said the following, almost in passing (quoted from memory): "Oh, by the way, we also include a timestamp in the data and verify that it is right. It's the time the PROM customizing that particular voting machine for that particular election was burned, and it's accurate to the IBM PC clock precision. I didn't even think of it as a security feature, but I guess it is." Not only hadn't he thought of this feature as being part of the security of modem-based vote reporting, but he then went on to explain why the software included a feature to allow a total with the wrong timestamp to be accepted despite a timestamp mismatch error. There was no similar way to override a 4-digit PIN mismatch. We approved the machine (Of course, we also tested other things, for example, by injecting line noise on the phone line while totals from a test election were being reported). We also made the administrative recommendation that, despite the fact that vote totals delivered by modem are currently not official, central election workers should not override timestamp mismatches or other overridable error conditions without explaining why in the presence of witness from at least two political parties (this is the usual precaution required for all manual vote processing steps). If electronically reported vote totals become part of the official canvass, we concluded that we'd like to see some of the time spent manually tallying the canvass spent auditing the machine computed results. Right now, in Iowa, no recounting of votes is allowed unless there is a call for a recount. As currently set up, this prevents reasonable auditing steps such as recounting randomly selected precincts or post-vote testing of randomly selected voting machines. We concluded that these kinds of tests should be routine and should be completed prior to the certification of an automatically computed purely electronic canvass. We also concluded that, someday soon, we'd like to see standards for electronic vote reporting from machine to central counting location. Security through obscurity isn't desirable, and cross-vendor compatability is important! Voting machines are expensive, and a standard would significantly simplfy incremental replacement of old voting machines. Doug Jones email@example.com
1) Election results. The BBC operates a magnificently indulgent set of computer graphics for predicting the various results of elections. In an interview on BBC News Extra on 3 May 1996, its presenter, Peter Snow, was asked if there were ever problems. "Oh yes", he replied. "For example, in the Dudley (a Midlands town) bye-election, the swing away from the (ruling) Conservative government was so large that the entire screen went blank because the programmers had not allowed for the Conservatives having no seats (i.e. elected representatives)". 2) Airline entertainment systems. During a single flight from Singapore to London experienced by myself in April 1996, the Singapore Airlines inflight entertainment system, "Krisworld", was rebooted twice in the first two hours, numbered its video channels with the rather eccentric numbering system, 1,2,3,4,5,6,48,8,... and then lost the numbers completely for a while so the video channel had to be guessed. This is a regular occurrence according to my colleagues. 3) Taxation. It was recently reported in the UK (April 1996 on www.netaccountants.com) that "A VAT Tribunal has shown the Customs & Excise VAT computer was incorrectly calculating VAT surcharges for late filing of returns. Customs have estimated that about 90,000 default surcharges were too high and have said that the way that the computer was programmed means that Customs cannot identify the businesses that have been overcharged !" Les Hatton, Ph.D. C.Eng, Director of Research & Engineering, Programming Research Ltd, England firstname.lastname@example.org +44 (0) 1 932 888 080
This is about a discovery I made with Alta Vista the WWW search engine, and its robot "scooter". The system I hit on had a high port of 8000 and I accessed it via Netscape 1.1N for the PC, through Alta Vista... I can not believe what happened to me, and it has elicited a bit of interest around the place. I hope I never see it again! Here is the article I posted: Hello everyone. I thought I might share with you an experience I had today while searching the Internet for information on some programming topics. I used Alta Vista to do a search on some programmers' libraries, for my home UNIX network. The software I wanted is actually commercial, and not freeware, and is unavailable except by purchasing it. Imagine my surprise when Alta Vista returned in its little search screen: "Directory of /lib" Hmmmm..... I proceeded to follow this link, hoping I might have hit on a public archive of software made available on the public domain, as the OS I wanted it for is basically obsolete. I was even more interested when I saw several system libraries scroll by on my screen... A quick check of the root home page of the system (i.e. just the domain name without a path to files) brought back the following: > Index of / > Name Last modified Size Description > > bin/ 15-May-96 14:20 - > boot 17-Nov-93 00:12 101K [...] >33 files To the uninitiated, this is the *root filesystem* of the UNIX host I was visiting via netscape. I changed directory to /etc and was amazed to see everything available to me. I clicked on /etc/motd and that was enough to tell me I could have had the password file had I wanted to. I mailed the site's admin and postmaster telling them of the security breach. The site is now offline since I checked tonight. Now, people - that is what Alta Vista can do on an unsecured UNIX server. Their whole machine - user private directories and everything - even files made read by the system only were publically available for anyone to download. Had I been malicious, I could have downloaded the password file, cracked it with crack, logged in as root, and deleted the syslogs and no one would have been the wiser to my presence, at least for a while anyway. There is no moral to this story - if there was one it would be something like: "You Are Being Indexed" - if you do not take care. Be careful of what you put on your computers. If there is a hole, Alta Vista will find it. And it is damn good at indexing Hard Disks. The site was indexed by Alta Vista's robot more than a week ago... Rachel Polanskis, Kingswood, Greater Western Sydney, Australia email@example.com firstname.lastname@example.org
Courtesy of Associate Press via CompuServe's Executive News Service Copyright 1996 The Associated Press. All rights reserved. Computer Security By JIM ABRAMS, Associated Press Writer <> WASHINGTON (AP) -- Hackers infiltrate Pentagon computers <>more than 160,000 times a year, threatening "catastrophic <>damage," but the military rarely detects and seldom <>investigates the interlopers, government investigators said <>Wednesday. "At a minimum, these attacks are a <>multimillion-dollar nuisance to Defense. At worst, they are a <>serious threat to national security," the General Accounting <>Office said. o GAO repeated the DoD estimate of 250K attempts last year. Testimony highlighted it was an estimate, but also that in GAO's opinion it was probably more accurate of an estimate than anyone else's. [DMK: The article states 65% of these were successful, but that was not what was in the testimony before the Senate. I watched the testimony on CSPAN last night (yes I do too have a life) and the testimony was that DoD estimates 250K attempts, and _DoD's_own_testing_ had a success rate of about 65%.] <> The report, presented to the Senate Governmental Affairs <>subcommittee on investigations, dealt with the more than 90 <>percent of Pentagon data that is unclassified. It nevertheless <>could contain highly sensitive information on troop movements, <>procurement and maintenance of weapons systems. o Testimony included 120 countries (identity classified) have or are developing computer attack capabilities. <> The report quoted the Pentagon as accepting that the <>document fairly represented the increasing threat of Internet <>attacks. Officers attributed some of the problems to poorly <>designed systems or to the use of off-the-shelf computer <>products without inherent security safeguards. o Both the Senate testimony and the Pentagon spokeperson highlighted the issue is unclassified information and that classified information was secure. [Well, not quite... PGN] <> Pentagon spokeswoman Susan Hansen also stressed that the <>report focused only on unclassified transmissions between the <>department and the outside world. Information on weapons <>systems and other classified material was secure, she said. "We <>have invested in those systems so they are not subject to those <>attacks," she said, "but we are not taking lightly the <>repetitive and constant attacks" on unclassified Pentagon <>networks. o Testimony include the Griffiths AFB penetration by the hacker Datastream Cowboy in early 1994: <> To avoid detection, the hackers went through international <>telephone lines, passing ports in South America, Seattle and <>New York to reach the Air Force computer. From there, they <>broke into computer systems of NASA, Wright-Patterson Air Force <>Base, defense contractors around the country and South Korea's <>atomic energy center. ... <> The report noted that the Defense Information Systems Agency <>has conducted 38,000 attacks on Defense computer systems via <>the Internet to see how well they are protected. The agency <>gained access 65 percent of the time. <> Of these successes, only 4 percent were detected by target <>organizations, and in only 27 percent of those cases was the <>detection reported to the systems agency. Dave Kennedy [CISSP] Information Security Analyst, National Computer Security Assoc. [The report is available from the Government Accounting Office, GAO/AIMD-96-84, Information Security: Computer Attacks at Department of Defense Pose Increasing Risks. Cliff Stoll, Bob Anderson of RAND, and I were at the hearing, having been invited to testify. However, our testimony has been postponed because the Senate decided to do a blitz voting on 40 issues at 10 minute intervals, so the hearing was cut short. PGN]
... I have three questions: a) how did they go about collecting such statistics, b) if the systems had software good enough to notice that they had been penetrated, why couldn't they have stopped the penetration, and c) how many successful or unsuccessful attempts were not detected? (Not that I have any idea how one would go about getting that number.) I will grant, for instance, that if the attack is a password attack where the search was done on another system on a copy of the password file one might not detect it until considerably after the fact, but unless the penetrators actually caused damage I would suspect any such successful attacks wouldn't be noticed at all (who bothers to look at the "last login time" notice, if there even is one?) -- the impression I have (but one must also question here how one would validate this) is that most hackers don't damage data, just look at it. I will also grant that intrusion detection systems (which can detect mosquito bites but not technically competent attacks) might work slowly enough as not to be able to stop an attack in progress, but I suspect that most of the systems involved (the stories said something about mass-marketed computers) don't have any intrusion detection installed. I don't doubt the message (things are bad and getting worse); what I do doubt is whether there is any scientific validity to the numbers. The RISKs? a) an unecessary amount of money will be spent on solving a non-problem, or b) the problem actually is real, but the flawed nature of the statistics will be questioned and the opposite will happen. Dr. Theodore M.P. Lee Consultant in Computer Security PO Box 1718 MN 55345 tmplee@MR.Net Minnetonka, 612-934-4532
... The part that I found interesting was this quote (from the Pittsburgh Post-Gazette, by Nolan Walters of the Knight-Ridder News Service): "A 16-year-old kid from the United Kingdom, with the computer nickname `Datastream Cowboy,' used a common 486 SX desktop computer, with *only a 170-megabyte hard drive,* to break into the Rome Laboratory sytem..." (my asterisks for emphasis - AT) Is it just me?? "Only a 170-megabyte hard drive??" Good thing he didn't have one of those fancy-schmancy 2-Gig drives - think of what kind of systems he could have broken into!!!! Yet another example of the uninformed writing for the uninformed. Alan Tignanelli
RISKS readers are well aware the RISKS of frequently used (and thus easy to guess) passwords. For the record (and for those of you who run sites where German speakers have passwords), here is the "most popular passwords" list for German, as obtained by a computer magazine's (PC Welt Extra) survey and reproduced by AP in Sueddeutsche Zeitung, May 22nd 1996, p.12: 1. Passwort ("password", could also be spelled <HTML>Paßwort</HTML>) 2. Pass (no translation) 3. Liebe ("love") 4. Sex (same) 5. Gott ("God") 6. Genie ("genius") 7. Hacker (same) 8. Geheim ("secret") Next are names, of the users themselves as well as names of spouses and children. I wonder if there is anybody willing to comment something on "German character" due to the passwords Germans are choosing, or any similar lists for other languages leaving room for (risky) "national character" studies :-) Martin Virtel PS. Any occurrences of this message being held up by mail filters because of the fourth most popular password welcome.
There are risks associated with assuming you're smarter than the spammers. Here the tactic is simple, regardless of whether auto-billing to originating callers is possible: spam this number from pay phones. They all dial 800 numbers (isn't it a regulatory requirement, like 911?), their users are completely anonymous, and their operators would almost certainly not be held liable for charge-backs under this scheme. Bob Blakley, IBM Austin, 11400 Burnet Rd. Bldg 903 Rm 7b-01 (email@example.com) FON 512 838-8133 t/l 678, FAX 838-0156 t/l 678
In Risks 18.13 (May 17, 1996) Simson L. Garfinkel said of his small ISP: > > ... we specifically block the alt.binaries groups. The principle reason > that we do this is to conserve our bandwidth: receiving alt.binaries > would require that we triple our off-island throughput. ^^^^^^ Now, skipping the moral and legal points noted by Mr. Garfinkel, with which I mostly agree, my main observation was this: is this what the internet =really= is all about? This and other stories, some on RISKS suggest that the search for soft and hard core porn make up the majority of internet traffic. This is a very disheartening to those of us who wish the net to thrive and realize its potential. The net will not thrive if its main purpose is the exchange of pornography. Eventually society will recognize its non-productive nature and abandon it. Indeed the predictions of the collapse of the net, widely reported recently, addressed this perception that few real uses for the net had been found. The risk? As more and more =quantitative= stories like Mr. Garfinkel's come to light, the size and scope of the net's "dirty secret" becomes apparent, commercial, scientific, and other interests will decide the net is a bad neighborhood to hang out in. If more ISP's took Mr. Garfinkel's stance, the =long term= interests of the net would be better served. Bob Morrell firstname.lastname@example.org http://pandoras-box.bgsm.edu/micro/tech.html
There is another risk here, partly computer-related, which is that of using names for symbols which are not universally recognised. There was has recently been a long discussion on comp.fonts about the proper name for the '#' symbol. The concensus seemed to be that while US readers recognised the name 'pounds' for this symbol, UK readers did not. They tended to know the symbol by the names 'hash', 'square', or 'sharp'. This name by which this symbol is known appears to be related to the context in which it is encountered; other names included 'nittle' (apparently used in the building trade) and 'octothorpe' (used by some phone companies). We use symbols in computing which are not part of normal everyday life; the risks are that as more non-technical people use computers, there will be more mistakes and confusion stemming from the wrong symbols being used, or symbols being used inappropriately. Angus Duggan, Harlequin Ltd., Barrington Hall, | INET: email@example.com Barrington, Cambridge CB2 5RG, U.K. | FAX: +44(0)1223 873873
Society and the Future of Computing '96 June 16-19, 1996, Snowbird, Utah, USA http://www.lanl.gov/SFC All conference information and the registration form are available through the Web site (http://www.lanl.gov/SFC/96/). Any questions or comments you might have may be addressed to firstname.lastname@example.org. [See RISKS-18.07 for earlier announcement. PGN]
Please report problems with the web pages to the maintainer