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…
A malicious program called Badtrans is moving around the Internet and worming itself into vulnerable computers and using a keystroke logger to surreptitiously record passwords, credit data, and other information. A virus manager at the security firm McAfee says that the worm "does no damage to files but does drop a backdoor trojan on the machine which would allow a hacker to come back and access personal information." Badtrans spreads through Microsoft's Outlook or Outlook Express e-mail programs and arrives with an attachment that can be executed simply by reading or previewing it and doesn't need to be double-clicked or opened separately. [Reuters/*San Jose Mercury News*, 27 Nov 2001; NewsScan Daily, 27 Nov 2001] http://www.siliconvalley.com/docs/news/svfront/034639.htm [Incidentally, we received a lot of e-mail on Magic Lantern. Let me summarize a little. Rob Slade questioned whether it was a virus in RISKS-21.78. This is an old battle, because "virus" has become overloaded. Peter da Silva and PGN both insist it is a Trojan Horse. Let's get on with it, and use the terminology correctly. There was some discussion on whether or not McAfee et al. will suppress detection of an FBI-planted virus, vague denials. There were some comments about ML being used only against bad guys, so what's the problem (slippery slope there). Tony Harminc remarked that collection need not be real-time if a Trojan horse is collecting the info for later dissemination. Dave Farber wondered about the possibility of disguising a really nasty virus so that it would slip through the mechanism that intentionally failed to detect ML. Several folks resurrected the old argument that the ability to insert malware actually weakens security. PGN]
Thousands of people's financial details have been stolen in a myster burglary in Auckland. Burglars broke through 24-hour security at New Zealand Funds Management's offices in the ANZ Centre the weekend before last. They stole computer tapes with clients' names, addresses, bank account numbers, how much they had invested, as well as financial advisers' computer passwords. NZ Funds Management has about 25 000 clients throughout New Zealand, with about NZD 1.6 billion (about UDS 670 million) invested. The high-rise centre has swipe-card access, video security cameras, and security guards 24 hours a day, but the burglars got in at 4am the Saturday before last. They got away with computer taps holding the client information. Only one office was broken into and only the computer tapes stolen. Left behind were laptop computers and other equipment. ---NZPA [Source: *Otago Daily Times*, 26 Nov 2001, p. 28] Strong cryptography wouldn't have helped. Completely avoiding the use of virus-friendly software wouldn't have helped. As for physical security, they had it. And the information was stolen anyway. Without knowing anything about the people involved, or having any expertise beyond that common to all readers of detective stories, I must say that it looks uncommonly like an insider job. The distributed techniques that have been worked out in response to the Napster case, could they help to protect against loss of records like this? But wouldn't having businesses distributed their data over thousands of other business's machines create RISKS of its own?
Responding to complaints by consumers and privacy advocates who protested California's legal sale to the Web genealogy company RootsWeb.com of public information containing such personal data as people's birth dates and their mothers' maiden names, the company now says it will remove from its Web site the names of anyone who makes a specific request. A spokesman for the company said: "The mission of our company is to create places to help people reconnect with their families. We're not in any way doing anything except helping our customers and if a customer is concerned about it, it doesn't do any good to leave them up on the site." A legal council for the Electronic Privacy Information Center says that California's sale of data to the genealogy Web site "a situation where all the residents of California have now been exposed to a new risk of identity theft." [*San Jose Mercury News 30 Nov 2001*; NewsScan Daily, 30 Nov 2001] http://www.siliconvalley.com/docs/news/svfront/priv113001.htm [The birth records of more than 24 million Californians are involved. PGN]
During the recent election (November) here, a power outage occurred during voting hours. It lasted several hours and affected an estimated 10,000 people in portions of northern Allegheny and adjacent counties (north of Pittsburgh, Pennsylvania, USA). Initial news reports noted concerns that the voting machines would not work without electricity. From what I've gathered, most of the machines were lever-style machines, and had a provision for manual power (i.e., a crank) to tally the votes and reset the levers after each voter. But what would have happened if they had used computer or other electronic voting, or another machine that required electricity to work? It seems dubious that backup power systems (15+ hour capacity) would be provided for all the polling places. How would the election process be affected, and when would the "powerless" voters vote? Would the election results be held up for this? — it seems that they would have to be. [Of course, no one can predict how this might affect, or not, any election in Florida. ;-)] Coincidentally, it was a relatively "minor" election, with few major offices or issues at stake, so fewer voters than normal showed up to vote. Around here, that's called a "light turnout" of voters. But, as they read their copy describing the local voting predictions and the "light turnout," not one of the newscasters gave any sign that they understood the pun. [And yet it is not difficult to have a shocking experience even when there is no electricity! PGN]
While we know all too well about the horrific destruction of the two main towers at the World Trade Center (1 and 2 WTC), not as many people are aware of the destruction of nearby 7 WTC nearby approximately 8 hours after the initial impact. While the building sustained structural damage from falling debris and the collapse of the main towers, it was also consumed by a raging fire that seems to have caused similar catastrophic structural failure. This article in *The New York Times* <http://www.nytimes.com/2001/11/29/nyregion/29TOWE.html> (reg required) indicates that a likely cause of that fire was the approximately 42,000 gallons of diesel fuel (6K gallons on the seventh floor, 36K in the basement) stored in the building to power backup generators for the City's emergency command center located there. This fuel was apparently ignited (the fireproof tanks may have been ruptured by debris) and burned intensely in the building's core to cause the collapse. Of course, the aforementioned emergency center was unusable in this emergency, and the city was left scrambling to setup another facility for emergency coordination (City Hall was too close to the accident site). Finally, according to an earlier NY Times article, this building also housed a regional CIA office whose destruction has hindered some intelligence and investigation efforts. As has been noted previously, the 9/11 disaster has illustrated all sorts of risks that are gruesome to contemplate. In hindsight, locating the emergency coordination center at the location of a potential emergency was unfortunate, and the lack of a backup emergency coordination center compounded the problem. And it is ironic how preparedness for one common emergency (power outages) can create a vulnerability in itself. I'm sure there are a lot more sites looking more nervously at their backup fuel supplies these days.
A friend just sent me a pointer to the announcement that the Connecticut Attorney General is opposing the Microsoft settlement. The URL for the announcment is: http://www.cslib.org/attygenl/mainlinks/linkindex11.htm When I surf over there with my Opera 5.0 or Netscape 4.77 browser running on Linux, I get this error page: This site requires JavaScript to be enabled. The Web browser that you are using does not have JavaScript enabled, or is not a JavaScript-capable browser. [...] The link to "upgrade your browser", naturally, suggests that I use Microsoft Internet Explorer or Netscape. (1) I shouldn't have to enable JavaScript just to read your press releases, but more importantly, (2) both browsers that I tried, Netscape 4.77 and Opera 5.0, running under Linux, have JavaScript enabled already. Something is clearly broken here. It is ironic that the Attorney General's attempts to fight Microsoft's market dominance are undermined by a Web site that insists that its users switch to Web browser software provided by the market leaders. Talk about anti-competitive forces! Ed Ravin <eravin@panix.com>
How to crash a phone by SMS By John Leyden Posted: 28/11/2001 at 18:20 GMT So now you can send an SMS and crash a mobile phone, so that the user is locked out. Job de Haas, a security researcher at ITSX, has adapted a program called sms_client, which sends an SMS message from an Internet-connected PC, in which the User Data Header is broken. During a presentation during the Black Hat conference last week, he demonstrated how a malformed message crashes a Nokia 6210 phone on its receipt. Once the message is received it is impossible to turn on an infected phone again. ... http://www.theregister.co.uk/content/55/23080.html
The Web Never Forgets, David Colker, Los Angeles Times, 27 Nov 2001 Government agencies have tried to remove sensitive information, only to discover that copies have proliferated and they're virtually impossible to eradicate. Within days of the 11 Sep attacks, the federal Agency for Toxic Substances and Disease Registry rushed to pull a suddenly sensitive report from its Web site titled "Industrial Chemicals and Terrorism." The agency eliminated all traces of the document and its description of sources for home-brew nerve gases and improvised explosives. But on the World Wide Web, almost nothing truly dies. [...] http://www.latimes.com/news/printedition/la-000094419nov27.story
When Gary McGraw gave a talk to our Cryptology/Computer Security class at University of Virginia, one of the things he mentioned is that the "bad guys are a lot better at sharing than the good guys." On Monday we had project presentations, and a group of students told the class how to exploit a serious security vulnerability present on any of the Lab PCs on grounds. The students had not told the system administrators of the machines about the vulnerability. The RISK of educating people about computer security is nobody knows how the people getting educated are going to use their knowledge. In this case I don't think my fellow students were acting maliciously. They simply didn't expect anybody to use the knowledge to do damage. It was a case of the "good guys" not sharing. David Friedman
The general risk here is the use of software in conditions it was never designed to be run under. SMTP (*SIMPLE* Mail Transfer Protocol) is called that for a reason. It was designed to be run in a trusted environment -- i.e., for communications between researchers, professors, and military people who had sufficient security clearance to be allowed onto the ARPANET in the first place. It was never designed to thwart misdirection and forgeries by sleazy scammers, i.e. no built-in authentication. Servers were few and far between, run by a small community of administrators who probably knew each other on a first-name basis. There is a spammer sub-culture (I use the term "culture" rather loosely) and also an anti-spammer culture, which are visible on various spam-fighting forums/mailing-lists. What you see here is probably the result of a "dictionary attack". The following description is a simplification, and is not 100% technically exact. A service paid for or run by spammers will set up a script to probe an ISP's smtp server. - if the smtp server supports the EXPN and/or VRFY commands an effective procedure is to establish an smtp connection to "smtp.example.com". Then run those commands inputting addresses like aaaaaaaa@example.com, aaaaaaab@example.com, aaaaaaac@example.com, etc, etc. A smarter script will use a dictionary of common names to increase the percentage of hits. The server will obligingly tell the connecting end which addresses are for real, and which are invalid. - if the smtp server has EXPN/VRFY disabled, another approach is to run a bogus mass-mailing. Each e-mail transaction starts the process and gets as far as supplying the "To:" address. If the receiving smtp server rejects an address, it's obviously invalid. If the smtp server responds OK, then the address is valid. The script will abort and tear down the e-mail transmission in that case, and get on with testing the next e-mail address. With today's fast computers and broadband, the above is feasible. Spammers forge return addresses. This prevents the originating machine from getting e-mail-bombed if several percent of a multi-million spam run are invalid addresses, or the targets' ISPs have spam-blocking of some sort. At first spammers put in gobbledygook into the return address. Then ISP's started refusing e-mail from domains that didn't exist (this is a quick lookup against DNS). So spammers resorted to forging random email addresses at valid domains. Occasionally, the forgery will be identical to a valid e-mail address, and innocent people get the bounces. > how on earth did the spammers "harvest" my specific MyRealBox account name They probably used some "common.name@myrealmailbox.com" forgery, as mentioned above. > (And are there any steps one can take to prevent it from happening again?) Not very much. You could try a long gobbledygook-type e-mail address that is less vulnerable (nothing is invulnerable) to a dictionary attack that is biased to common names. The disadvantage is that your friends and business associates will have problems remembering your kjgrhjkfdh@example.com e-mail address. > This also brings to mind the risk of using a "free" Internet e-mail Actually, the risk is in signing up with any ISP/e-mail-service with millions of valid e-mail addresses where a dictionary attack will return a lot of hits. You're less likely to run into this on a smaller ISP. Walter Dnes <waltdnes@waltdnes.org> [SMTP EXPN also noted by Doug Sojourner, in very similar discussion. PGN]
Allan's story about all his mailboxes getting hit with spam doesn't really surprise me. I strongly suspect that he was the victim of a dictionary attack (mentioned several times before in RISKS). When I started a new job last year, my e-mail account was set up a couple of weeks before I started (I had to move several hundred miles for this job). When I did start, I found my mailbox containing several hundred spams! I had, unfortunately in this case, been assigned the e-mail address of jason@domain. It was pretty much a given that most domains would contain an address of "jason," and so I got caught in those spam dragnets. Whenever I would go on vacation, I would come back to several hundred junk messages. Lesson? An easier e-mail address is easier for everyone. Jason Bennett, jasonab@acm.org [We had a lot of e-mail on this topic. PGN]
Some of Mr. Spinellis' suggested fixes won't help when a quote character appears in a filename. This "requoting problem" has been known since before Unix even existed, at least within the Multics community. I remember encountering it myself in 1971 or 1972 in the exec_com facility of Multics. The root cause and the real source of the risk here is the attempt to use an interactive command language as a programming language. It's evidently a very seductive temptation, since the mistake has been repeated many times by many people, but in the end that approach just can't work. A programming language needs a syntax and semantics that don't confuse the data being processed with the program doing the processing.
I can't be the only RISKS reader with an MPW documentation set, can I? Apple has had a UNIX-like shell for many years. Let me quote page 3-18 of "Introduction to MPW" (that's *M*acintosh Programmer's Workshop): QUOTE PARAMETERS THAT CONTAIN SPACES In general, when a parameter contains a space, you must enclose it in quotation marks so that the MPW Shell recognizes it as a single parameter. and page 3-19: QUOTING RULE #1 Place quotation marks around parameters that contain spaces. While UNIX may (perhaps!) have been new to Apple programmers, the need for quoting parameters that contain spaces certainly wasn't.
BKHKRBWR.RVW 20010829 "Hackers Beware", Eric Cole, 2001, 0-7357-1009-0, U$45.00/C$67.95/UK#34.99 %A Eric Cole www.securityhaven.com eric@securityhaven.com %C 201 W. 103rd Street, Indianapolis, IN 46290 %D 2002 %G 0-7357-1009-0 %I Macmillan Computer Publishing (MCP) %O U$45.00/C$67.95/UK#34.99 800-858-7674 317-581-3743 info@mcp.com %P 778 p. %T "Hackers Beware: Defending Your Network from the Wiley Hacker" It is difficult to maintain confidence in a book that, within six sentences of the opening of the first chapter, misspells the word "brakes." We are told that two developmental editors, two copy editors, two proofreaders, and no less than five technical reviewers had at this work. Did any of them pay attention to what they were reading? Chapter one basically states that dangers are out there, security is bad, and companies should be concentrating on prevention, detection, and education. Cole also nudges at the "hacking for protection" theory, without ever really examining it. A brief but reasonable list of security breaking activities is given in chapter two. Various steps and tools involved in gathering information about a network connected to the Internet are described in chapter three. Unfortunately, this explanation, while helpful to a potential attacker, has no utility for the defender: almost all of the data discussed must be publicly available for the network to function, and so there are no means of blocking this level of access. Spoofing, or masquerading, is dealt with in chapter four, but again, while some protective measures are provided, much more time is spent on the disease than the cure. After twenty six pages of telling you how to hijack sessions, including the best programs to use and how to operate them, chapter five gives us two pages of simplistic advice (avoid remote connections) on protection. Chapter six lists a number of common denial of service attacks and, while it does devote a lot of ink to describing the exploits, the material is reasonably balanced, and the suggested defensive measures realistic. Chapter seven requires almost forty pages to tell us that buffer overflows are not good, and you should apply software patches. Password security is very important, but the material in chapter eight is vague, disorganized, and has relatively little to say about good password choice. (Chapters nine and ten describe some NT and UNIX password cracking programs.) The examination of background fundamentals of NT, in chapter eleven, is a terse and unfocused grab bag of information. The analysis It would be of little help in explaining the specific attack programs listed in chapter twelve, a number of which rely on particular applications. The same relation is true of chapters thirteen and fourteen, relating to UNIX. A number of backdoor and remote access trojan programs are described in chapter fifteen. Chapter sixteen discusses log files, and lists some programs for generating spurious network traffic in order to hide attacks. Some random exploits are listed in chapter seventeen, and a few more in eighteen. An attempt is made to combine various attacks into scenarios, in chapter nineteen, but these do not add anything to the material already provided. Chapter twenty is the usual vague look to the future. This book takes the all-too-common approach of assuming that teaching you how to break into systems will help you to protect them. The work also amply demonstrates the fallacy of that argument. While the harried systems administrator spends several hours coming to grips with the minutiae of the attacks described, the vast majority of the exploits listed can be countered simply by ensuring that software patches are up to date. In addition, while dozens of loopholes are listed in these pages, thousands more exist that are not covered. The material contained in these pages may be entertaining, but it is of far more use to the attacker than to the defender. This would be upsetting, were it not for the fact that most of the exploits described are old and not likely to remain unpatched if administrators are keeping up to date. (Of course, many small outfits can't commit a lot of resources to keeping up to date ...) For security specialists, this volume provides nothing that can't be found elsewhere. For non-specialists, it fails to supply a security framework and strategy within which to work. copyright Robert M. Slade, 2001 BKHKRBWR.RVW 20010829 As usual, a draft has been sent to the author. He has requested that this response be included, unedited: Robert: First allow me to say thank you for taking the time to review the book as criticisms are as crucial as praise. We take your feedback seriously. That being said, let me see if I might speak to some of your discussions on "Hackers Beware". When you buy "Hackers Beware", you buy it for the technical content. While we maintain that this faction of the book is air-tight and well- supported, we also admit that we could and should have done a better job with edits on spelling and grammar. While we admit that shortcoming, we also ask that you look at the eleven reviews posted on Amazon, praising the technical content of my book and earning it FIVE- STAR rating. The book starts opens with some introductory material but does that for a reason. Much of the security information that companies need to protect their site is straightforward. Yet companies systems are still hacked into with a growing frequency because they fail to understand how to build a proper defense. So my book aims to ensure that everyone is well, if not over-educated on DEFENSE. There are many books on hacking but what makes this book different is its emphasis on defense. Yes, you need to understand how the enemy breaks into systems, so you can build better defenses. Every section has an area on how to defend against a certain type of attack. So I am not sure how a review can say that defense is not covered when that is the thrust of this book. There are plenty of books that show you how to break in. This book clearly and explicitly explains the properties of a strong defense. Thanks for letting me write a response. Eric 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