precedence: bulk Subject: Risks Digest 20.31 RISKS-LIST: Risks-Forum Digest Sunday 18 April 1999 Volume 20 : Issue 31 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at and at ftp.sri.com/risks/ . Contents: BART ghost train snarls morning commute (PGN) EMI from USS Carl Vinson opens garage doors in Hobart (Norbert Thumb) ASerbic cyberattacks and counterattacks (PGN) Fake ATM front panel copies cards and PINs (Ulf Lindqvist) Overzealous applications (Ian Cargill) Outlook '98 not Y4.501K Compatible (Eric Zago) favicon.ico (Robert David Graham) Leap year 2000 and C (Mark Brader) Risks of April foolery (Pete Mellor) GUIDs and Melissa (Robert David Graham) Phone company says keep your PIN on your calling card (David Graf) Re: Mainframe viruses (Julian Thomas) E-mail and communications history (Dennis Ritchie) REVIEW: "Hacker Proof", Lars Klander (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Sat, 17 Apr 99 13:16:33 PDT From: "Peter G. Neumann" Subject: BART ghost train snarls morning commute 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.) ------------------------------ Date: Sat, 17 Apr 1999 23:37:50 +0200 From: Norbert Thumb Subject: EMI from USS Carl Vinson opens garage doors in Hobart 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 ------------------------------ Date: Fri, 16 Apr 1999 10:34:44 +0000 From: "Peter G. Neumann" Subject: ASerbic cyberattacks and counterattacks 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 ] 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! ------------------------------ Date: Fri, 16 Apr 1999 16:47:20 +0200 (MET DST) From: Ulf Lindqvist Subject: Fake ATM front panel copies cards and PINs 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 ------------------------------ Date: Sat, 17 Apr 1999 14:34:34 +0100 From: Ian Cargill Subject: Overzealous applications 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. ------------------------------ Date: Fri, 16 Apr 1999 21:54:24 -0400 (EDT) From: Eric Zago Subject: Outlook '98 not Y4.501K Compatible 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 ------------------------------ Date: Fri, 16 Apr 1999 22:11:22 -0700 From: "Robert David Graham" Subject: favicon.ico 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 ------------------------------ Date: Sat, 17 Apr 1999 02:03:08 -0400 (EDT) From: msbrader@interlog.com (Mark Brader) Subject: Leap year 2000 and C 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 ------------------------------ Date: Sat, 17 Apr 1999 23:43:24 +0100 (BST) From: Pete Mellor Subject: Risks of April foolery 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 ------------------------------ Date: Fri, 16 Apr 1999 20:21:06 -0700 From: "Robert David Graham" Subject: GUIDs and Melissa > 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 ------------------------------ Date: Sun, 18 Apr 1999 18:45:38 EDT From: DavidG3276@aol.com Subject: Phone company says keep your PIN on your calling card 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 ------------------------------ Date: Fri, 16 Apr 1999 19:01:25 -0400 From: jt5555@epix.net (Julian Thomas) Subject: Re: Mainframe viruses (Schaffer, RISKS-20.30) >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 ------------------------------ Date: Fri, 2 Apr 1999 01:18:09 -0500 From: dmr@plan9.bell-labs.com Subject: E-mail and communications history (Re: RISKS-25,28) 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 ------------------------------ Date: Tue, 6 Apr 1999 08:33:42 -0800 From: "Rob Slade" Subject: REVIEW: "Hacker Proof", Lars Klander 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 ------------------------------ Date: 23 Sep 1998 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact (Dennis Rears). .UK users should contact . => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 19" for volume 19] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks . ------------------------------ End of RISKS-FORUM Digest 20.31 ************************