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…
SpamAssassin is now trapping over 1100 e-mail spam messages to me and RISKS each day. IN ADDITION to that, the recent malware activity (MyDoom, etc.) is awesome. After putting out RISKS-23.14 on 27 Jan, I did not get a chance to look at the RISKS mailbox until this morning, and there were 2528 NEW messages, of which only about 40 were legitimate postings. Note that I run absolutely *no* MS software, so don't bother to blame me for any of the bogus e-mail that seems to come from RISKS. Subject Messages ------- ------ test 407 hi 296 hello 240 status 197 mail deliv.. 188 mail trans.. 185 returned ma. 161 error ... 89 server report 85 undeliver... 77 failure not. 67 ... virus .. 44 and many many more with gibberish that I deleted on the basis of their subject lines alone. Many thanks to those of you who remember to use the helpful tag string [noted in the last message in each issue, and which will change as soon as the spammers start using it]. That tag really encourages me to look at your e-mail first — or even at all. It also enables me to scan through the thousands of items that SpamAssassin traps, and I think I have found only one legitimate message that got caught in its web. (My sincere regrets if I accidentally deleted any of your legitimate messages.) Incidentally, RISKS is hugely backlogged at the moment, with material for about three issues waiting for catching up — without even thinking about everything that this issue will generate. Side note: MyDoom hit SCO yesterday at midnight, as predicted, infecting PCs beginning in New Zealand. SCO was reportedly completely paralyzed by the denial of service attacks, which are expected to continue through 12 Feb.
For fairly obvious reasons, I just upgraded a family member's anti-virus software. She asked me to check a suspicious message; when I saw that the body said "The message contains Unicode characters and has been sent as a binary attachment," I knew what I was dealing with. Of course, the AV software did detect it, and dealt with it in an appropriately permanent fashion. But how did it notify the user of what it found? It created a .txt file — as an attachment in the e-mail message... How long, I wonder, till a virus uses that exact filename and syntax to hide behind? Recall that MyDoom is already calling itself things like "document.txt .scr" and the like, to try to hide the real extension. Why are the good guys trying to teach people to click on attachments?
Anick Jesdanun, an AP Internet Writer, wrote an article stating:
The continued spread of a cleverly engineered computer virus exposes a key
flaw in the global embrace of technology: Its users are human.
The article is available at:
http://story.news.yahoo.com/news
?tmpl=story&cid=528&e=4&u=/ap/20040128/ap_on_hi_te/e_mail_worm
The e-mail contacts an attachment marked
application/octet-stream; text.zip
or
application/octet-stream; data.zip
Unzipping the file gives you an executable, perhaps data.scr or text.pif,
again with a misleading name. Unfortunately, the mail reader knows how to
unzip and execute the file without any warning to the user.
Anick blames the user's trust for the damage. If the user were warned
before the file were executed, the problem would not be as serious.
comp.risks has covered this topic in 20:44, in June, 1999, where
Steven M. Bellovin says:
The underlying problem is that there are two different mechanisms used to
determine file type, and hence how it should be "opened". One is what is
displayed to the user; the other is what is actually used. That way lies
danger.
In one of its first actions, US-CERT issued a warning about the MyDoom.B worm. Unfortunately, US-CERT forgot to mention the operating systems which are susceptible to attack from the worm. The technical warning is available at: http://www.us-cert.gov/cas/techalerts/TA04-028A.html The warning contains hints that the OS is some form of Windows, mentioning the Windows System directory, but doesn't come out and identify any operating systems. On the other hand, CERT's (without "US") warning of Novarg.A worm: http://www.cert.org/incident_notes/IN-2004-01.html has a link titled "Steps for Recovering from a UNIX or NT System Compromise". CERT doesn't mention the susceptible operating systems, either, but one could assume that UNIX is at risk. Chew on these CERTs and you will be lucky to see a spark of light.
In a joint letter being sent to several congressional committees, Republican and Democratic party organizations for citizens living abroad are opposing the Pentagon's SERVE system for Internet voting in the forthcoming presidential election. About 100,000 ballots are currently expected to be cast using this system, in 50 counties. [Source: Bipartisan Request Seeks Halt to Internet Voting: Groups Fear Citizens Abroad Will Be Compromised, Dan Keating, *The Washington Post*, 30 Jan 2004, Page A19; PGN-ed]
Police in the Netherlands have arrested 52 people suspected of using the so-called "Nigerian e-mail scam" to defraud Internet users by sending them spam e-mails asking for their help in transferring a large sum of money out of Nigeria or some other troubled country in exchange for a generous percentage-fee. A task force of 80 officers raided 23 apartments, seizing computers, fake passports and 50,000 euros ($62,000) in cash. Most of those arrested were believed to be Nigerian. [Wired.com, 2 Feb 2004, NewsScan Daily, 2 Feb 2004] http://www.wired.com/news/ebiz/0,1272,62124,00.html?tw=wn_tophead_5 [Observing how scam e-mail has increased, I suspect that this is still just the tip of the viceberg. PGN]
The article mentioned, http://spaceflightnow.com/mars/mera/040126spirit.html contains this statement: "Spirit bogged down because it didn't have enough random access memory, or RAM, to handle the current amount of files in the flash — including data recorded during its cruise from Earth to Mars and the 18 days of operations on the red planet's surface" Does anyone reading RISKS know how they test mission software, and how rigorously? It's nearly unbelievable that "what happens when Spirit accumulates lots of files?" apparently wasn't tested.
> ... variant of the classic "fixed length buffer" error? Wouldn't this actually be a variant of the classic "failure to detect and recover sensibly from a full disk" error? Not at all the same thing.
I would have thought the reason it rebooted so many times is precisely because there isn't a sysadmin handy. Nothing terrible will happen if the rover reboots--it doesn't fall flaming from the skies or fall over a cliff, it doesn't threaten the lives of astronauts, it simply sits immobile on the (apparently lifeless and inactive) surface of mars for a minute or two while it reboots. However, if the rover software gets locked into a state it can't recover from, it is lost--there is no one there to push the reset button (except, hopefully, a deadman timer). Given those conditions, it seems like sensible RISKS engineering practice to make the best try at restoring a known system state--by rebooting--at the slightest sign of an inconsistency in the system state. It obviously also needs some sort of "safe mode" that depends on as little hardware as possible and allows mission control to intervene--and apparently that exists.
(Correction, RISKS 23.14) I am afraid that I have to make a correction to my posting in RISKS-23.14. My posting covered two particular cases, and the correction refers to case 1. 1. It has been brought to my attention that although the perpetrator's earlier home town is in North-East Lincolnshire, the local police is not in fact Lincolnshire Police but Humberside Police, and therefore Lincolnshire Police were in no way responsible for the events described. I therefore offer my apologies to all concerned at Lincolnshire Police. 2. It has also been brought to my attention that the Data Protection Registrar has been re-titled the Information Commissioner. I am also indebted to Graham Smith for pointing me at the following relevant news item from the BBC news website (which explains both cases far better than I ever could): http://news.bbc.co.uk/1/hi/uk/3395071.stm There is certainly room for debate on the conflict between (a) the presumption of an individual's innocence until proven guilty, and (b) the requirement to protect society at large (and children and the vulnerable in particular), in the case where an individual repeatedly attracts the attention of the police without ever being brought to court.
> The caretaker later murdered two of the schoolchildren (aged 9 and 10).
This implies the children went to the school where the caretaker worked.
Not so. They went to a different school, and the murderer came into contact
with them through his girlfriend (who did work at their school). It is
likely that the murders would have happened even if the caretaker was denied
his job.
You can discover more details of the case by searching on the caretaker's
name, "Ian Huntley". There is a summary at:
http://en.wikipedia.org/wiki/Ian_Huntley
The previous accusations against Huntley were unproven. The risk to the
children has to be balanced against the risk of unfounded allegations being
allowed to destroy the career of an innocent man.
> The resulting inquiry revealed that the caretaker, while in Lincolnshire, > had been the subject of multiple relevant allegations (indecent assault > and worse), none of which had ever been brought to court. ... So "Innocent until proven guilty" is now an Unintended Consequence? Remind me never to have anyone make false allegations of serious offenses against me next time I'm in England. Oh, wait, how do I do that? Not to say that what is described is not a tragedy, but if there is fault to be found with the police, it's *not* for not telling the school about the earlier cases. It's for failing to get the criminal tried and convicted back then. And even this is only true if the earlier alleged offenses were genuine. (One can imagine an unlikeable person being the subject of false allegations and later turning to actual crime.) > As a result, the various investigations in Lincolnshire never heard > about each other ... And that'd be their fault too. For police, it *is* reasonable to consider that someone previously suspected should be suspected again: this is all right precisely because a police suspect is not, ipso facto, a criminal.
Google targeted by pranksters: Web site operators, bloggers skew results Verne Kopytoff, *San Francisco Chronicle*, 26 Jan 2004 Who among the many candidates running for president is unelectable? George W. Bush — if the search results on Google can be believed. His biography is the first result to appear on Google for the Web query "unelectable." It's just one in a long list of similarly bizarre results on the search engine over the years that are the result of manipulation, not their relevance. Called Google bombs, these are pranks engineered by Web site operators and creators of Web logs. They take advantage of the way Google ranks search results to get certain Web sites listed higher for specific queries than they otherwise would be. That's why President Bush's biography also appears as the top result for the search query "miserable failure." ... http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2004/01/26/BUG3M4GVDS1.DTL
> [This is increasingly becoming a problem! We desperately need > some greater authentication and accountability. PGN] It will get worse very soon. I've received several e-mails, apparently from paypal, about a UK branch they are setting up, announcing the move of just about all european customers to that branch instead of the US one. None of the messages so far have asked me to take any action, so I haven't bothered to check if paypal is indeed moving to the UK or not. Personally I will check every move very carefully, DNS registry, https certificates, etc... This is in itself already a Risk, since paypal must now assume on every administrative mail they send that people will simply not believe them, but the bigger risk is that I'm probably almost alone in these checks. Anybody want to bet scammers will attempt to abuse potential confusion round the move to paypal.co.uk (if it is real) for their own phishing expeditions?
Not only PayPal users are being tricked into providing sensitive information. In The Netherlands an e-mail has circulated that asked Postbank clients who use electronic banking to provide user identification and password information. They used a similar approach as in the PayPal case. The e-mail contained what looked like a proper webaddress, but when looking at the source (it was an HTML message) another web address was hidden there. By clicking on the link, you got to a non-Postbank website, with ordinary http: rather than https:. I was warned by the fact that the e-mail was delivered to my work e-mail address rather than my private e-mail address. In addition, the language of the mail was more Flamisch (the Belgian variant of Dutch) than proper Dutch. The Postbank had a warning about this e-mail on the home page of their website on the same day as I received the e-mail.
On the Hertfordshire Linux User Group mailing list there is a bizarre story of a teacher disciplined for teaching a student to use the address bar (http://mailman.lug.org.uk/pipermail/herts/2004-January/000198.html) "Early last year (during her previous stint at my school) I was accused of "hacking the server" (FYI, there are at least 3 servers). Investigation, letters and phone calls by concerned parents showed that the actual concern was that I had informed a student in Year 9 how to use "about:some_HTML_here" in the address bar, to test HTML on the fly in IE. He then used it to do "about:<a href="\\server1">server1</a>". For the un-HTML-enlightened among us, this would create a blank page with a link to \\server1, which would show a normal Explorer Window with all the shared folders on server1. What else that student did I was never told." I can't see that this offers anything you couldn't get via network neighbourhood, but then I'm no Windows expert. FWIW, I tried this on IE6/W2K and got no more than an error message. RISKS here are more of technophobia than direct RISKS of technology.
For a bit of lighter relief: BKHGMNSG.RVW 20031112 "The Hanged Man's Song", John Sandford (John Camp), 2003, 0-399-15139-7, U$25.95/C$39.00 %A John Sandford (John Camp) js@johnsandford.org %C 375 Hudson Street, New York, NY 10014 %D 2003 %G 0-399-15139-7 %I Berkley %O U$25.95/C$39.00 http://www.berkley.com/berkley online@penguin.com %O http://www.amazon.com/exec/obidos/ASIN/0399151397/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0399151397/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0399151397/robsladesin03-20 %P 321 p. %T "The Hanged Man's Song" It is always a delight to find a new John Sandford/John Camp novel, a pleasure that is unalloyed by any regrets and annoyances in regard to technical goofs. As was the quality of the technical material in "The Fool's Run" (cf BKFLSRUN.RVW) and "The Devil's Code" (cf. BKDVLSCD.RVW), so it is with "The Hanged Man's Song." The technology is firmly grounded in reality. The communities, both blackhat and law enforcement, do not have the jarring quality found in all too many works where the author becomes fascinated with "hackers." (Having lugged around a number of "development" laptops in order to demonstrate company products, I was wryly glad to find that someone else knows that not *all* such machines are featherweights :-) There is an intriguing idea for distributed backup of secure-but-secret data, although I suspect that even very young computer wizards would very quickly act to close loopholes and find anomalies. I'm a bit surprised that a careful and paranoid group, such as is described in the novel, did not take more care with authentication, perhaps through a "web of trust" model, but I suppose that would have gotten in the way of the plot. Onion routing would also have been handy for these people, but, again, would not be as exciting. (I also want to get my hands on that quad track DVD-R: the best I can find for my own systems is the basic single track that only lays down 5-6 gigs.) The main complaint I would have with this particular work is that the technology seemed somehow divorced from the primary thread of the plot. This seems an odd statement to make, given the three-cornered race by technically savvy people, turning primarily on computer forensics and data recovery, but I was left feeling that this was more akin to an old-fashioned chase thriller. Albeit an interesting one. copyright Robert M. Slade, 2003 BKHGMNSG.RVW 20031112 rslade@vcn.bc.ca slade@victoria.tc.ca rslade@sun.soci.niu.edu http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Jose Nazario BKDDSAIW.RVW 20031128 "Defense and Detection Strategies Against Internet Worms", Jose Nazario, 2004, 1-58053-537-2, U$85.00/C$131.95 %A Jose Nazario jose@crimelabs.net %C 685 Canton St., Norwood, MA 02062 %D 2004 %G 1-58053-537-2 %I Artech House/Horizon %O U$85.00/C$131.95 800-225-9977 artech@artech-house.com %O http://www.amazon.com/exec/obidos/ASIN/1580535372/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/1580535372/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/1580535372/robsladesin03-20 %P 287 p. %T "Defense and Detection Strategies Against Internet Worms" The preface states that the book is intended for security professionals, security researchers, and academics in the field of computer science. It is obvious that the author has attempted to write the material in a scholastic tone, but the necessary rigour and structure of thought is missing. Chapter one, an introduction of sorts, provides random information of questionable utility, such as the table listing the discovery of vulnerabilities compared against the time that elapsed before those loopholes were first released in active worms: no particular pattern seems to be indicated. Part one is supposed to be a background and taxonomy. Chapter two provides us with a definition. Nazario has obviously taken the Cohenesque definition of viruses (as attaching to files) and then assumed that a worm is any self-replicating program that does *not* so bind. The definition therefore appears to include almost all current viruses, and yet the author also attempts to ascribe certain characteristics to worms, such as control and construction of a network, and communication with other worm nodes. His later examples of worms, however, include a number that do not contain any of these aspects. He lists a number of components of worms, and yet the communications, command, and intelligence elements are not inherently part of much of modern malware, usually existing simply as specialized payloads. A simplistic growth pattern (and the fact that worms can generate network traffic) is presented in chapter three, but the actual traffic patterns examined do not fully correspond to the projected graph. The history and taxonomy given in chapter four has numerous errors: even the fictional representative, the tapeworm from Brunner's "The Shockwave Rider," is introduced erroneously, since it didn't shut down the network in the book, but rather opened it. Workstations affected by the infamous Xerox PARC worm could be restarted, and a vaccine was not needed or produced. The Morris Worm was an enormous nuisance, but it hardly "crashed the Internet." (And Loveletter did the rounds in 2000, not 2001.) There is a quick precis of a number of lesser known worms, and this may be helpful as a reference, but the analysis is very limited. The construction of a worm is described in chapter five, but the outline is often at odds with that given in chapter two. Part two reviews worm trends. Chapter six reworks some of the material from five in a facile listing of infection patterns (and presents an artificial "Shockwave Rider" pattern that does not seem to have any correspondence to reality). "Targets of attack," in chapter seven, simply enumerates network connected devices. Nazario does attempt to bring in abstract concepts related to network topologies, but these have little practical bearing on worms in reality. The possible futures for worms, as expressed in chapter eight, deals mostly with existing and already used technologies. There is some effort made to model effects, but these are not fully analyzed. Part three turns to detection. Chapter nine looks at traffic analysis, but only in terms of network based intrusion detection with rudimentary appraisal. Honeypots and "dark networks" (ranges of unused IP addresses) are said to be ways to detect and trap worms, but the explanation and dissection of the topic in chapter ten is very narrow. Signature based detection, in chapter eleven, revisits network based intrusion detection, and adds a brief mention of file scanning. Part four looks at defences. Chapter twelve's review of host based defence deals primarily with system hardening, antivirus scanners, and the concept of throttling. Nazario seems very loath, in his discussion of firewalls in chapter thirteen, to admit that this is simply another type of signature. The use of scanning within application level proxies is examined in chapter fourteen, although there seems to be some confusion with circuit level proxies at points. Chapter fifteen, entitled "Attacking the Worm Network," outlines a number of active measures: except for the idea of "sticky" tarpits (after the LaBrea program model) all of them require extensive specific knowledge of individual worms. A concluding chapter is provided in sixteen. Nazario's work does address the often neglected topic of worms, and he does break away from the mass of virus books that are locked into the traditional "file and boot infectors" model. His examples are drawn from more recent events, and he does attempt to analyze network effects and complications, rather than simply looking at systems in isolation. While he is to be commended for all this, his definition is too broad to provide for serious new modelling of the problem, and his analysis fails to provide a basis for future work. Still, for those who need a more complete picture of the malware threat, this work should be considered. It does provide new information, and does attempt to address the difference between worms, viruses, and other forms of malware. In this regard, it is a significant improvement over such lackluster spacefillers as Skoudis "Malware" (cf. BKMLWFMC.RVW), the "E-mail Virus Protection Handbook" (cf. BKEMLVRS.RVW), Dunham's "Bigelow's Virus Troubleshooting Pocket Reference" (cf. BKBVRTPR.RVW), Schmauder's "Virus Proof" (cf. BKVRSPRF.RVW), and even Grimes' somewhat better "Malicious Mobile Code" (cf. BKMLMBCD.RVW). copyright Robert M. Slade, 2003 BKDDSAIW.RVW 20031128 rslade@vcn.bc.ca slade@victoria.tc.ca rslade@sun.soci.niu.edu http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer