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…
The U.K. Home Office ruled that all new passport photos must show an
unsmiling face with closed mouth because open mouths can confuse facial
recognition systems. The new guidelines require good contrast between the
face and background; the full face looking straight at the camera; no
shadows; and a neutral facial expression. The rules will apply immediately
to new and replacement passports. U.K. prohibits smiling faces on passports,
*The Register*, 6 Aug 2004
http://www.theregister.co.uk/2004/08/06/passport_scanners/
[When Lauren Weinstein saw this, he commented:
"But what if people keep smiling at the airport?" PGN]
Estefan Enterprises and Clear Channel Entertainment announced (on 9 Aug 2004) that Gloria Estefan's 9 Aug performance at the American Airlines Center in Dallas, Texas has been canceled. After performing to a packed house in Houston, the touring company experienced a computer crash that affected the production and its special effects, forcing the cancellation of the performance. Engineers guarantee that the system will be repaired by in time for the next performance in Phoenix, Arizona on 12 Aug. [PGN-ed] http://www.gloriaestefan.com/news/press.php?id=20040810
Jon "DVD Jon" Johansen has cracked the Apple Lossless encryption used by the Airport Express to communicate with iTunes, so that programmers can write tools that use any application and any operating system to send audio to an Airport Express. I've released JustePort, a tool which lets you stream MPEG4 Apple Lossless files to your AirPort Express. The stream is encrypted with AES and the AES key is encrypted with RSA. ... http://www.boingboing.net/2004/08/12/airport_express_cryp.html http://nanocrew.net/blog/apple/revairtunes.html
An 9 Aug 2004 *Infoworld* article href=http://www.infoworld.com/article/04/08/09/HNaolimflaw_1.html notes that there is a bug in AOL Instant Messenger allowing an attacker to send a message that can cause a buffer overflow and possibly execute code on the attacked machine. Apparently this will only occur if the attacker sends a url - like the one in this message - as a hyperlink and the victim clicks on it, which makes the probability of attack much lower than a "standard buffer overflow attack" upon a program.
I happened to stumble upon the most recent issue of the hacker e-zine Phrack, Issue #62, of July 10, 2004, and looking over the table of contents I found article #5, "Bypassing 3rd Party Windows Buffer Overflow Protection" which can be read at the following url: http://www.phrack.org/show.php?p=62&a=5 I found the article fascinating in that it shows exactly why several major commercial anti-buffer overflow exploit programs are inadequate for their advertised purposes. The article even points out what you are going to end up with: a false sense of security. For those who are not so technically inclined, a buffer overflow exploit is one in which someone sends too much data to a program (such as a web server application), sending far more data than the program would expect, in order to force arbitrary data into a storage area (a "buffer") so the amount of data forced into the buffer goes beyond the expected limits, causing the data to overflow the buffer and makes it possible for that data to be executed as arbitrary program code. Since the attacker forces code of his choosing into the execution stream, he now 0wns your box, because as the saying goes, if I can run code on your machine - especially if it's a Windows machine where there is not much protection - I can pretty much do anything I please there. These anti-buffer overflow exploit protection programs then try to prevent this by watching for attempts to execute calls to the operating system, in places where only data should occur as opposed to program code. The article shows why these programs are inadequate both from a standpoint of how they fail to provide full protection, and how to get around the limited protection they do provide. This sort of article is an excellent example of why full disclosure of a serious problem is necessary in order to solve it. The type of response to an anti-buffer overflow exploit protection program by an attacker would, as a matter of necessity, be somewhat complicated and technical in nature, and the only way one could explain why there is a problem, what the problem is, and then allow someone to be able to solve it, is to describle how to exploit the flaw. Nothing less will do because nothing less will explain how the flaw is exploited. It is reports such as these that are important even to those that are not interested in breaking into a place, and in fact are probably of crucial interest to security people in order that (1) they not be given a false sense of security by these products that only solve part of the problem; (2) explain exactly why the products are ineffective; and (3) explain exactly what the issues are. An explanation such as the one given shows why these products are ineffective, shows what those who have to defend themselves need to look for, and can show those trying to build safety systems in the future how to better secure them. Does this mean someone can create an attack using the information shown? Absolutely. This does not make the exposure of such information any less valid. Telling someone that it is still possible to trigger a buffer overflow exploit even if a buffer overflow exploit security program is in place is probably not going to convince them without some proof. Explaining that these systems don't block everything and mentioning why will not give someone enough information to reliably check what is happening or understand how the problem affects them. Only a clear explanation of how the process is done is going to show someone how to guard against it. Digging one's head in the sand does not hide a danger, nor does making it illegal to publicize such information help, as those who will use such information for criminal purposes, since they are already breaking the law, any penalties for selling such information to other crackers (or trading it for other information) simply keeps it out of the hands of the good guys who would need it to figure out how to work around it. Additionally, by making such information available, third parties, who are neither selling security software, nor trying to crack other people's boxes in order to 0wn them, can read this information and give an objective validation as to whether they are valid or not, and perhaps can supply solutions not requiring multi-thousand-dollar support contracts from some vendor who is more interested in what they can sell than in security, who just happen to sell this particular type of product because there is a market for it and who might not be interested in giving away information that they can sell to others. There's nothing particularly wrong with charging whatever the traffic will bear for what you know, but it creates a strong disadvantage for those kept in the dark. Which is the only thing that security by obscurity - trying to hide problems in the hope someone doesn't discover them - does, it keeps the people who most need to know how to solve the problem in the dark.
Obion County in Tennesee had to revise its preliminary election results after they discovered that early votes weren't counted. Seems that the DRE vendor changed how the system counted the early votes, which wasn't initially noted. They're now confident they got it right. One preliminary victor will now be defeated. Note that the problem here wasn't in the voting machines themselves (which is where most of the historical problems have been), but rather in how the results are tallied at the end of the election. http://www.ucmessenger.com/cgi-bin/LiveIQue.acgi$rec=29188?frontnews
In two new tests, car owners will be able to let insurance companies monitor their driving via new technology in exchange for lower rates. The technology will track some combination of when, where, how far and how fast they drive, giving insurers a way to reward low-risk driving. Now just experiments, the technology might be a glimpse of the future of car insurance. The trials will begin this year. [Source: Kevin Maney, *USA TODAY*, 9 Aug 2004] http://www.usatoday.com/tech/news/surveillance/2004-08-08-insure_x.htm
DidTheyReadIt is a new service on the Net. It has garnered some attention from the privacy community already: I will deal with some of that later. I would like to examine the actual operations of the service. The discussion surrounding it has been marked by assumptions and lack of knowledge. Some assertions have been made that are at odds with the actual operations. DidTheyReadIt is both less, and more, dangerous than has been made out. As the name implies, it provides a kind of "return receipt" for e-mail. It does this, of course, using Web bugs. A "single pixel" image file is called from the central host, using a hash that presumably corresponds to the sender, subject, and receiver, looking like the following: img src="http://didtheyreadit.com/b906148b2edfdab9e7de03a23f59687eworker.jpg" width="1" height="1" / (I have removed the surrounding angle brackets: hopefully this will prevent any mailers from trying to render the HTML.) Having obtained an account from DidTheyReadIt (and paid for the privilege), there are two ways to use the service. RISK 1 If you have WinXP or W2K (and a "standard" mailer) you can run a background program on your computer. I have downloaded the installation program and made a cursory examination of it, but I have strong reservations about actually running it on my system. One can assume that the process runs in the background, adds the Web bugs to outgoing e-mail traffic, and sends information to the central computer. However, even a brief analysis of the code indicates it can do more than that. Among other things it calls the kernel, uses the Registry, and obtains information on privileges within your system. These may be valid activities within the context of the operation of the program, but, given what the program must be doing, what else is it doing? There is a significant possibility for information leakage here. RISK 2 You can use the program without running the background process. To do this, you append "didtheyreadit.com" to the e-mail address. If I wanted to send a message to my rslade@isc2.org address, I would send it to rslade@isc2.org.didtheyreadit.com. The central computer then reformats the e-mail in HTML and adds the Web bug. In this way, obviously, DidTheyReadIt gets to read all the e-mail I send. When e-mail is opened using a mailer that automatically calls for information from the Web, the URL is requested, and the central computer has confirmation that the individual actually read the e-mail. DidTheyReadIt promises that they can tell you how long the e-mail remained open. (In the tests that I've done so far this information has been available in slightly under half of the cases.) (When the URL is requested, a series of packets each containing a single byte is sent. Lauren Weinstein [see below] has noted that this may be the way the Rampell measures how long the message remains open. In tests the file transfer time seems to vary, but has always been shorter than the longest time that I've been "informed" a message has remained open. Others have theorized that the material transferred may be scripting that remains active as long as the message is open, passing information back to Rampell. This does not seem to be the case. When downloaded manually, the file is 302 bytes, has the internal structure of a JPEG file, and displays as a one [or possibly two] pixel black dot. A refresh tag could be used, but this has been observed neither in the coding seen nor the activity of browsers. At this point I don't know what the basis of the "read duration" is.) RISK 3 The central computer actually has rather a lot of information from that URL request. There is information about the time it was opened. There is purported information about the location and organization, but this is obviously obtained from a whois lookup from the IP address. There is information about the browser application, and the language used. In the case of Windows software running under emulation on a non-Windows system, there was enough information to indicate that this was so. RISK 4 The amount of information that DidTheyReadIt could build up is quite staggering. As well as simple lists of valid e-mail addresses, they can tie address information to browsers and other applications, and the language of the user. They can, of course, build maps of connections between correspondents. The hash seems to also be linked to the subject line, so that even if e-mail is not being sent through the central computer itself a database of topics and interests can be built. I'm rather surprised that Rampell Software (the company behind DidTheyReadIt) is even trying to sell their service: make it free, get the masses on board, and they have a gold mine of marketing information. Rampell is presumably well aware of the marketing possibilities. Each and every confirmation message from them carries at least two marketing messages: one pushing you to buy an upgrade to the version you have, and another promoting some other Rampell product. The system is not perfect, of course: send a message to me and you will probably not get acknowledgement that I read it, since my mailer does not (automatically) render HTML and go to the Web. However, prevailing upon some friends with more "standard" mailers, such as Outlook and Eudora, the system does seem to work (at least partially) with a wide variety of systems, including Macs, and Macs running Outlook under PC emulation. Cookie filters that prevent you from going to an "outside" site might limit the susceptibility of Web based mail systems, but otherwise these should all return the tracking URL. The system has interesting limitations with regard to mailing lists, and copies. When sent to a mailing list, and even to a number of people copied on the "To:" and "Cc:" lines, only one hash is generated. Although the confirmation message from Rampell mentions the possibility of further confirmations whenever someone subsequently reads the message, in testing that does not appear to happen. Each hash appears to be good for one use, and one use only. Sending a message to a mailing list gets you a response from the first person (or the first *susceptible* person) to read it. As noted at the beginning, there has already been some interest in the system and the privacy considerations. There have been two mentions of the system in the RISKS-FORUM Digest, beginning with http://catless.ncl.ac.uk/Risks/23.41.html#subj2 In the first, Lauren Weinstein gave a reasonable account of the system and the potential problems, noting the possible solutions. The use of text-only e-mail is the best solution, and blocking the Rampell server would work as well. Turning off image display may alleviate privacy problems, but that does depend upon how different applications handle that option. Some may submit the URL to the Rampell server, and simply not display the image. http://catless.ncl.ac.uk/Risks/23.44.html#subj11 A second posting noted that DidTheyReadIt is illegal in France, and speculated that travelers to France might find themselves in legal trouble if they were subscribers. In practical terms, having the Rampell software installed on your system could be evidence against you. In which case, using the modified e-mail addresses would leave you free and clear, so long as you didn't send any modified mail while in France. France might, of course, want to block Rampell's IP addresses. A marketing consultant did an article on the errors that Rampell made in promoting the service. He suggested that an opt-out approach or option would have avoided the bad press. Unfortunately, this demonstrates that he doesn't understand how the system or the technology works. As Weinstein's analysis indicated, you have to change your software, or have some backend support, in order to prevent detection. It is, of course, quite possible that Rampell has only the purest of motives in providing the service, and would never consider using the information obtained by providing it. I would not dare to impugn the integrity of the company or its principles and principals. However, I would note that historically: - A certain delivery company stated that it would never sell the database of digitized signatures collected when it started using electronic pads--and then, some years later, did exactly that. - Companies with very rigorous privacy policies, having collected significant amounts of personal customer data, have gone bankrupt, and the files have been offered for sale. - It has, sadly, been known to happen that evil intruders have broken into companies and stolen personal information from computerized files--or even planted backdoors and logging/reporting software in their systems. 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
Ah, yes. I don't know how many times I could potentially have sent private or even confidential information to someone inadvertently because that person decided to send me an instant message, which of course would preemptively pop up directly in front of whatever I happened to be working on at the time. The good news is that I've managed to catch myself before ever sending anything potentially risky... still, I *have* confused people with a few stray words or even a snippet of computer code that I just happened to have been in the midst of typing when they sent me an IM. For that matter, there's already an exploit for Mozilla's XPInstall that takes advantage of this particular race condition, as demonstrated by Jesse Ruderman of squarefree.com: http://www.squarefree.com/archives/000487.html Basically, Ruderman came up with a deceptive page that causes the installer dialog to appear at just the right moment to trap your keystroke of 'Y', which of course it then interprets as 'Yes'. If you've wondered why Mozilla grays out the buttons in its install dialog for five seconds after you choose to install an extension, this is why-- it's to prevent an inadvertent installation through a stray keystroke or mouse click! Cody "codeman38" Boisclair cody@zone38.net http://www.zone38.net/
BKSTNHOC.RVW 20040721 "Stealing the Network: How to Own a Continent", Ryan Russell, 2004, 1-931836-05-1, U$49.95/C$69.95 %E Ryan Russell BlueBoar@thievco.com %C 800 Hingham Street, Rockland, MA 02370 %D 2004 %G 1-931836-05-1 %I Syngress Media, Inc. %O U$49.95/C$69.95 781-681-5151 fax: 781-681-3585 www.syngress.com %O http://www.amazon.com/exec/obidos/ASIN/1931836051/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/1931836051/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/1931836051/robsladesin03-20 %P 402 p. %T "Stealing the Network: How to Own a Continent" This book is fiction (more a series of short stories or scenarios than a novel), but, like Winn Schwartau's "Pearl Harbor Dot Com" (cf. BKPRHRDC.RVW, and "Terminal Compromise" before it, BKTRMCMP.RVW), the authors intend the book to be taken as a serious addition to security literature. Chapter one is basically about hiding and paranoia. The central character seems to be using a considerable amount of money to hide while setting up some kind of crime, and then abandons everything. The points in regard to ensuring computers and data are unrecoverable are interesting, and probably workable. The more important aspects of the plot which involve creating a team, employing cutouts, and disappearing are left almost completely undetailed. If, therefore, we are supposed to learn anything either about crime, or how to detect or prevent it, the content and information simply aren't there. The claim that the "technology" is real, and would work, is unverifiable because we haven't had any technology yet. (The writing is edgy, interesting, and mostly readable. However, it's also difficult and confused in places.) The story continues, via another character (two, actually) in chapter two. This time the technical aspects are more detailed (and fairly realistic) although the community factors are questionable (and the story has some important gaps). (I can personally vouch for the fact that the description of the physical attributes of that specific hotel are bang on, although the ... umm ... social amenities are not.) An "Aftermath" section is at the end of every chapter. In some instances the segment provides a little advice on detecting the attacks described in the story, but this is by no means true in all cases. Nothing much is added in chapter three: a wireless network is penetrated for a second time. Man-in-the-middle attacks, some IP, and UNIX cracking are added in chapter four, phone phreaking in five, and sniffing and rootkits in six. Chapters seven and eight describe software analysis and exploits. Malware is used in chapter nine, although there are the usual unresolved problems with directing attacks and limiting spread. The lack of particulars on the intent of the attack makes the chapter quite perplexing. As with any volume where multiple authors work on separate chapters, the quality of the writing varies. (That the authors did strive together on the overall plot is evident from a few subtle ties between different stories. An appendix lists some of the discussion in this regard: for those interested in the process of writing and collaboration it is an interesting piece in its own right.) One specific point is that a few sections have very stilted dialogue. Overall, most of the book is readable as fiction, although it is hardly thriller level plotting. Since it is fiction, the story has to be a story, and interesting, and therefore contain elements that are not related to the technology under examination. It is difficult to draw the line between not enough and too much, but the authors do seem to have included an awful lot of material that is unimportant either to the security functions or to the plot. A number of these digressions are simply confusing. The characters used in the stories are frequently stereotypes, although not always of the same type. (I was very amused by the note that the book attempted to remain true to geek culture, including "swearing, boorishness, and allusions to sex without there being any actual sex.") If you watch a lot of movies with somewhat technical themes you can recognize where quite a number of personae come from. Basic editing is the province of the publisher rather than the author(s), but it must be noted that spelling, grammatical, and typographical errors are surprisingly common. Not enough to be a real annoyance, but a proper copy edit would have improved the book quite a bit. This book is certainly interesting enough (albeit rather disjointed) as fiction, and technical enough for everyone tired of the usual Hollywood view of computers. The security risks noted are real, and therefore a read through the book could be used to alert non- specialists to a number of security issues and vulnerabilities (although you'd hardly want to use it for training). I enjoyed it and I think it's got a place, although I'm having difficulty in defining where that place is. copyright Robert M. Slade, 2004 BKSTNHOC.RVW 20040721 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