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…
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.)
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
NATO announced that its Web server in Brussels had been under a PING-of-death (Packet INternet Groper) attack from somewhere within Serbia. John Pike labeled it "a textbook example that will be cited from now on as a low-cost, high-value attack." [Source: Serbia launches cyberattack on NATO, *Federal Computer Week*, 31 Mar 1999, by Daniel Verton (dan_verton@fcw.com); PGN-ed] The ease with which such attacks and other denials of service can be perpetrated is one more reminder of the general flakiness of our information infrastructures, but then RISKS readers are probably the last to be surprised. In a spy-vs-spy-style retaliation, various Internet denizens sent half a million e-mail bombs to www.gov.yu, the main Yugoslav Web site, before it shut down on 3 Apr 1999. There were also reports *The Boston Globe* of a U.S. group called Team Spl0it and European and Albanian penetrators changing Web sites. On the other hand, there are also reports of Russian hackers going after U.S. Navy Web sites. [Source: E-Strikes and Cyber-Sabotage: Civilian Hackers Go Online to Fight. 15 Apr 1999, by Patrick Riley, http://www.foxnews.com/stage11.sml; PGN-ed from a cypherpunks item courtesy of Dave Farber <farber@cis.upenn.edu>] Riley cited some concerns that vigilante hacktivism might be misinterpreted as sanctioned government action. On the other hand, given the existing system and network flakiness, there might also be concern that what might seem to be vigilante hacktivism might actually be government sponsored! Perhaps future wars will be fought by our-hackers-vs-their-hackers in purely electronic warfare. It would save a lot in armaments, and would inspire greater system robustness that otherwise seems impossible to attain!
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
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.
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
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
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
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
> 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
As readers are well aware, it is simply good sense to not keep passwords where someone could take advantage of them. Imagine my surprise when a major U.S. telephone company sent us a new calling card along with stickers which listed our calling card and PIN numbers. We were to place these small stickers on the back of the card to make sure that we did not forget either number. How helpful--not just for us, but for any thief who might pick my pocket. Plus, imagine the fun someone could have if they had stolen this letter from our mailbox. Dave Graf <DavidG3276@AOL.COM>
>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
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
BKHKRPRF.RVW 990228 "Hacker Proof", Lars Klander, 1997, 1-884133-55-X, U$54.95/C$74.95 %A Lars Klander lklander@jamsa.com %C 2975 S. Rainbow Blvd., Suite 1, Las Vegas, NV 89102 %D 1997 %G 1-884133-55-X %I Jamsa Press/Gulf Publishing Co. %O U$54.95/C$74.95 800-432-4112 fax 713-525-4670 starksm@gulfpub.com %P 660 p. + CD-ROM %T "Hacker Proof: The Ultimate Guide to Network Security" There is a great deal of information on security contained within this book. Unfortunately, it is presented without a cohesive framework. The overall impression is good. A lot of the forms that would make up a useful work are followed, such as a summary (rather ironically, in view of the scattered nature of the text, called "Putting It All Together") and a set of resources at the end of every chapter. The author seems to be easily distracted, continually jumping to the next, more sensational, topic. Although not divided into parts, the contents do have some logical divisions. Initially, we are presented with what seems to be intended as background material, although the scattergun approach leaves all of the synthesis up to the reader. Chapter one is a rather unfocussed introduction, talking as much about Internet technologies as about security. Errors are rather common, ranging from chunks missing out of sentences to figures with no cutlines to security weaknesses that are essentially duplicates of each other to mailing lists that haven't distributed material for years (with contact addresses that are even older). Theoretically the networking concepts and details in chapter two might aid in understanding system vulnerabilities, but in the fact of the book they do not seem to be used effectively. The discussion of firewalls does not provide sufficient information about either the needs, weaknesses, or possible inconveniences of the different types in chapter three. The material on encryption, in chapter four, mentions a number of the currently important standards, but the explanations are so flawed that the chapter could not be used to inform a decision on the strength or use of a cryptographic system. Material on the use of digital signatures is fairly short, and the remainder of chapter five rehashes, with really expanding, old ground. Another section tries to delve into more networking protocols. Chapter six, on HTTP (HyperText Transfer Protocol), is somewhat disjointed, and, again, fails to seriously examine the security implications. S-HTTP (Secure HyperText Transfer Protocol), in chapter seven, deals mostly with packets and commands, although it does have some limited discussion of function. The Secure Socket Layer (SSL) seems to look primarily at arcana rather than use. Chapter nine looks at a few common forms of attack, but presents information somewhat at random. Kerberos is reasonably well described in chapter ten. Some types of electronic commerce technology are mentioned in chapter eleven. There is an extremely limited look at auditing in chapter twelve, first for UNIX and then for NT. A very rough look at security issues within the Java programming language makes up chapter thirteen. Chapter fourteen's look at viruses has good basic explanations, but is unreliable in practice. The remaining chapters generally look at security for specific systems. Chapters fifteen to seventeen very quickly talk about individual security functions in NT, NetWare, and UNIX, but fail to analyze, for example, the effective rights granted by combinations of the different privilege granting mechanisms. SATAN (System Administrator's Tool for Analyzing Networks) for UNIX and Kane Security Analyst for NT get quick overviews in chapter eighteen. Chapter nineteen presents a number of security vulnerabilities with the Netscape and particularly the Internet Explorer Web browsers. CGI (Common Gateway Interface) form weaknesses are discussed in chapter twenty, but with so many different languages that the ultimate advice is simply don't make a mistake when programming. The final chapter is a reasonable look at security policies. However, with some many items missing from the background provided, the chance of producing a good policy at this point is relatively small. As with "Maximum Security" (cf. BKMAXSEC.RVW), this book attempts to cover the enormous field of security by throwing out as many bits as possible. Therefore large holes are apparent in the coverage. In addition, the book lacks an overall framework that could be used to build a security structure and point the way to vulnerabilities that were not addressed. For those who already are well comfortable with security as a concept, this volume does have a lot of references that might be of use. For those new to the topic, it is not reliable enough to start with. copyright Robert M. Slade, 1999 BKHKRPRF.RVW 990228 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer