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…
tagesschau.de has an in-depth update on the software failure at http://www.tagesschau.de/aktuell/meldungen/0,1185,OID3328786_REF1_NAVSPM1,00.html (in German), here my synopsis/translation: NATS (National Air Traffic Control Service) was supposed to move from West Drayton to Swanwick near Heathrow in 1996 and 1997 with a completely modernized technology for air traffic control. The system cost 623 million Pounds Sterling (940 million Euros) and was not delivered by Lockheed Martin until 2002. It will take until 2007 for the move to be completed. Four months after the system was initiated, there was a large breakdown in May 2002 that caused an air traffic outage over England. "Experts" decided that the problem was the technical communication between the ancient computers in West Drayton and the new ones at Swanwick. The current misfortune is attributed to an attempt on the night of 2 Jun 2004 to update the system. The update did not work, and the mainframe could not be restarted. Two hours were needed to get the backup system functional. In the course of the day, it was disclosed that the computer in question is 30 years old. [actually, sometimes I trust older systems more than I do these modern WinTel boxes... -dww] The update that was to have been installed was ordered after an incident in Jan 2004 in which there was almost an in-air collision in British airspace. The air traffic controller had told two large passenger machines to move apart. The data came into the system reversed, so that the machines actually moved closer to each other. The error was recognized in time by pilots and by the air traffic controller. Prof. Dr. Debora Weber-Wulff, FHTW Berlin, FB 4, Treskowallee 8, 10313 Berlin Tel: +49-30-5019-2320 http://www.f4.fhtw-berlin.de/people/weberwu/
PRIVACY Forum Digest Friday, 28 May 2004 Volume 13 : Issue 03
( http://www.vortex.com/privacy/priv.13.03 )
Greetings. There's been a lot of publicity over the last few days about
Rampell Software's DidTheyReadIt.com service. There have been other
software tracking systems introduced before, but this one, by including
features that attempt to determine how long a message is kept open (as well
as whether it was received, who you forwarded it to, etc.) is worthy of
particular disdain and concern.
There's more than just basic privacy issues involved. Many individuals,
businesses, and particularly government entities may have serious security
issues regarding capabilities that can expose information about when a
particular person has read a message, and perhaps potentially even if they
are still actually sitting there reading the message right now. The
possible dangers are fairly obvious — knowledge of the hours a person
works, when they tend to be in their office, etc. can be easily abused in
sensitive environments.
Some of these features not only depend upon invisible image "Web bugs" used
in a "conventionally invasive" manner, but also reportedly feed a slow
stream of data to your system during the entire interval you're reading a
message (that's how their "how long were you reading the message" function
apparently operates).
Luckily, there are several ways to protect yourself not only from Rampell
and their customers but also from other mail tracking services:
- Use a text-based e-mail reader, not an html mail reader, for most mail.
Do you really need to see all the fonts and associated frills in most
e-mail? What kind of mail is most likely to be full of such stuff?
Spam of course! When you need to display image or document attachments
they can still be processed externally. Text-based e-mail systems also
can provide essentially complete protection against all virus, worm, and
related attacks that use e-mail as their vectors. I use a text-based
e-mail system for 99.9% of all my mail quite successfully. And I get a
lot of e-mail.
- Turn off image display in your html mail reader. E-mail tracking
systems that claim to work regardless of where mail is sent typically
depend upon the recipient retrieving images (often invisible images)
from central servers. One way to stop that process is of course to read
your e-mail offline, though that isn't practical for most of us. But
various html mail reading systems allow you to turn off image display
(and typically retrieval as well) for e-mail messages (you can turn it
back on when you really need it for particular items). If you don't
retrieve the images or Web bugs, e-mail tracking systems that need them
won't work. And of course, you should never allow javascript in e-mail
messages to be processed, nor allow attachments to be executed.
- Server blocking. System administrators and others may choose
to determine (from viewing e-mail raw source data) the names and/or
IP numbers related to the servers used by Rampell or others to
serve the tracking images. If these servers are blocked at firewalls
or other filters the tracking systems will be rendered impotent.
Until legislation and the legal system recognize the risks in such e-mail
tracking and provide appropriate restrictions and remedies, you need to
protect yourself.
Lauren Weinstein lauren@pfir.org lauren@vortex.com lauren@privacyforum.org
1-818-225-2800 http://www.pfir.org/lauren
PFIR, Fact Squad - http://www.factsquad.org
Moderator, PRIVACY Forum - http://www.vortex.com
France Telecom, by far the largest phone company in France, offers its customers a free voice mail service called Top Message. Users of the service can sign up to receive an e-mail letting them know when they have new voice mail — useful for people with dial-up Internet connections. You activate this feature by sending an e-mail to a designated address with your phone number in the subject line. I've found that France Telecom makes no apparent effort to determine whether a particular person has the right to be receiving these alerts, which include the phone number of the caller and the time they called. I was able to activate alerts for the phone in my apartment in Paris even though the phone bills are in the name of a previous tenant. It also worked when I used the phone number of some friends here who also use the voice mail service. The online instructions for the service say you're supposed to receive confirmation by voice mail and e-mail when the alert service is activated. When I signed up I found that this was not the case — the alerts just started arriving. There are no doubt thousands of jealous ex-lovers in France who would love to know who has been leaving voice mail for the objects of their obsession. Perhaps France Telecom should start charging stalkers for this service? (Following through on the promise to notify users when the alerts are turned on would provide a minimal level of protection against this potential creepiness.) Top Message online help (in French): http://www.agence.francetelecom.com/vfrance/esav/fixe/pages/services/3103/etre_averti_du_depot.shtml#3 SPLIT: http://www.agence.francetelecom.com/ vfrance/esav/fixe/pages/services/3103/etre_averti_du_depot.shtml#3
I got the idea of writing about this from a recent pen-test mailing list
thread I replied to.
In that thread, someone asked about the risks of using USB. The guy
described how he plugged in a USB device and was surprised to see it
auto-run. He was particularly worried about the potential theft of
information that can be caused by the malicious usage of USB devices.
Indeed.
This has been covered and demonstrated on several occasions, on TV shows
(Threat Matrix), Sci-Fi TV shows (Jake 2.0) and in actual _real_ security
discussions. I believe this was brought up before in both Slashdot and
Full-Disclosure, but only with actual solutions. I haven't personally seen
anyone discuss the risks.
Disabling auto-run might not be the solution for USB (although that is
always a good idea when hardening a Windows system). USB auto-run installs a
driver for itself on plug-in. A driver which is essential for the device to
operate. Auto-run on CD drives for example is not necessary, one can always
access the CD and execute whatever program is there (or even the auto-run),
manually.
On USB, there are a few concerns when it comes to drivers. The driver
can be:
1. Messed with, i.e. made to do things it shouldn't (Reverse
Engineering, manipulation).
2. Built from scratch with one of *many* SDK's out there.
USB brings the threat of any user, maid, cleaner or hostile "whoever" to
plug it in, covertly gather whatever information/perform whatever action
they wish, and leave. They might not even have to be covert about their
actions as USB devices are more than legitimate in many organizations
and aside to not being notices for using a USB device one could alter
the driver for any USB device they usually use.
This brings up the issue of what hardware should be allowed in an
organization and whether users can bring their home hardware to work, but
that is beyond the scope of this write-up.
USB technology is both fast and convenient. More and more computer services
and devices move to work over USB as a fast-growing trend. It has been this
way for several years, and the technology usage is still showing signs of
growth.
I feel threatened enough by the fact that such small devices with such a
huge data capacity exist and can be smuggled into a building in so many
ways, automatic operations done "on-plug-in" or "on-connect" are just a
plus. You don't really need many tools other than copy, but I suppose tools
can be created.
There are many ways in which the exploitation of this technology can
progress, from simply connecting a USB drive and copying information as I've
mentioned above, through PDA's which would allow you to chose what you want
to steal and map the network, all the way to wireless devices which can be
remotely controlled by a laptop or through, say, a cellular device, whether
temporary for the sake of one illegal operation, or permanently, providing
an hidden backdoor to a network.
Disabling USB all-together, virtually, by domain policy or removing the USB
devices themselves, maybe even just filling the plugs with silicon or glue
physically are some more drastic options which some organizations *might*
take, but I don't see it as a very viable option for most.
As always when it comes to security, it all depends on your risk analysis.
Cost vs. benefit. Is it worth it?
Do you have an opponent that could threaten you in this way? Do you have
anything to hide and how much do you care about hiding it?
There exist several tools to monitor a domain for when and if a USB device
is connected to any remote machine, and of what kind. A simple web search
should help you find some examples.
I suppose simple tools could be easily created, but as there are several
commercial options it might be worth a look.
The security risks of USB are more than this short email can convey, but I
think I gave you enough to get started and to think about. This issue is of
paramount importance and I don't see much *noise* about it.
Thoughts, anyone?
ge@linuxbox.org gadie@cbs.gov.il +972-50-428610 (Cell).
I've had two telephone annoyances over the past year that are RISKS related. First, a major home improvement chain came to town about a year ago. While the store was still under construction, I started receiving telephone calls at my home number, with the caller asking for this particular store. Upon questioning the callers, I found that someone in the construction trailer was giving out my number. I called up the construction trailer and had a "Did, too!", "Did not!" type of conversation with the person who answered. Even after construction finished, the calls continued. Now the callers claimed to be getting my telephone number from the store's web site. I confirmed this. The telephone book shows that the first 5 digits of the correct number are the same as mine. The last two digits are completely different. This is not a case of transposition or accidentally repeated digits. Someone got the last 2 digits completely wrong. This should be easy to fix, right? I sent e-mail to the webmaster. No response. I called up the store. "We don't manage the web site. Our corporate office does that." Nobody knows how to fix the problem. A year later, I am still receiving calls for this store. I have taken to telling callers that this store is so badly managed that they can't even figure out how to fix a wrong telephone number. We'll see if that gets any action. Second, something is amiss with my telephone company's software. I have two pieces of evidence to support this claim. - Two or three times a week, when I dial a number I know is good, I get the message that I am calling a disconnected number. When that happens, I just hang up, then hit redial, and the call usually goes right through. - I get a lot more wrong numbers than I did at my last place of residence. When I ask the callers what number they were attempting to call, I get the usual transpositions and repeated digits, but I also get a fair number of answers that have no obvious connection with my telephone number. I usually suggest to these callers that they try hitting redial, and I've never had any of them ring back. (Oddly enough, I don't seem to be calling wrong numbers myself, unless that is what is causing the "disconnected number" messages. But then why am I not hitting valid, but wrong, numbers as well?) So I called the operator and told her about it. She had absolutely no idea what to do. "Surely there is some way to report problems of this nature?" I asked. She didn't know. She didn't even know who to ask. The telephone book yielded no clues. In both cases I, a member of the public, knew about a problem, tried to report it, and found that those responsible either have no problem reporting mechanism in place, or have successfully hid its existence from their own employees. Jerry James http://people.eecs.ku.edu/~james/ james@eecs.ku.edu jamesj@acm.org
How my PGP signature ripped off, and for what purpose
On May first I e-mailed a couple of mailing lists, announcing a new spam
research related mailing list.
Due to knowing that many viruses and kiddies spoof my e-mail address on a
regular bases, I signed the post.
So far I received about one e-mail a day from people who Googled the PGP
signature that was in a SPAM they got (right through their filters).
That signature was my signature from the spam mailing list.
Irony? Attempted Pay-back? Oh well.
As the e-mails don't stop and as it happens with Joe Jobs, you must reply
and be nice while you do it.. I decided I'd put this in a short write-up
describing:
1. What happened (the story).
2. A few of my opinions on the subject.
3. A full analysis of the SPAM message. Quite interesting, although
there is nothing completely new there.
PGP is used exactly for this purpose. Even if my signature was ripped,
it should be pretty obvious it wasn't made by me. Still, this is a risk
(which isn't completely new either
What _is_ new is the very targeted nature of this PGP Joe Job.
Here is the write-up that was supposed to be sent as e-mail. I figured that
with all the spam elements quoted in it though - it might get caught in
filters:
"An anatomy of a PGP Joe Job"
http://www.math.org.il/PGP-JoeJob.txt
ge@linuxbox.org gadie@cbs.gov.il +972-50-428610 (Cell).
There is a category of bugs that can be summed up as (re)try too hard. They are much more interesting when they involve positive feedback. Suppose some networking code works fine normally but an environmental problem causes retransmissions. If those retransmissions make the problem worse they will cause more retransmissions which will... Last summer, Netgear demonstrated a spectacular example of this type of bug. I'm surprised it hasn't been covered here yet. Dave Plonka has an excellent writeup at: http://www.cs.wisc.edu/~plonka/netgear-sntp/ He has links to several media web pages at the end. Here is a highly abridged summary: Netgear added an NTP client to some of their routers so log entries would have the correct time. They hardwired the IP address of the NTP server at UWisc into their code. They shipped many many thousands of those routers. The total load was too much for the NTP server and/or network at UWisc so packets started getting lost. The code had a bug. If it didn't get an answer, it retransmited once per second. (One request per hour would be reasonable.) The UWisc network collapsed on May 14th, 2003. In early June, they were discarding 250K packets/second, 150 megabits of NTP traffic! That's an impressive load for such a simple protocol. A similar bug in SMC routers knocked the NTP server at CSIRO (Australia) off the net. http://mailman.anu.edu.au/pipermail/link/2003-April/049684.html I know of a few other examples of try-too-hard bugs: Consider a UDP request/response protocol running over a slow phone line. Suppose that requests are tiny, the response takes a 1/2 second on the phone line, and the retransmit timer is 1 second. If there is no other traffic, things work cleanly. Suppose some other traffic causes an additional 1/2 second of delay. The retransmit timer goes off and that puts a second copy of the response in the queue. The client will continue when it receives the first (delayed) response. If the client generates more work for the server, that response will be delayed by the retransmission that is still in progress. A little more shared traffic can cause things to snowball. Note that once a few retransmissions are in the pipeline the system doesn't need any more outside traffic to cause troubles. It's own queued up retransmissions will keep causing more retransmissions. That's just a simple example of a retransmit/retry timer being set too short. Variations involve the server having to do a lot of work and not being smart enough to cache the answer. The next two examples don't involve any positive feedback. Consider the typical client-server setup that uses several servers for reliability. What happens if a particular data pattern issued by a client finds a software bug that crashes a server? If the client retries again using another server, that one will crash too. If the client keeps retrying it can kill all of the servers - embarrassing if you thought you were building a reliable system. When forwarding mail, some servers retry right-away on a temporary error. That turns into a denial-of-service attack if the receiving server returns a temporary error. Anti-spam defenses sometimes return temporary errors because that gives the operator of a mis-configured server a chance to fix things without any bounced mail. RISKs related issues: * Why didn't Netgear learn from the SMC/CSIRO event? Why didn't that event get more publicity? (I can't find any reference in RISKS.) * If you are outsourcing work or hiring contractors/consultants, how can you tell if they are good enough to avoid problems like this? How would you write a contract to avoid bugs like this? Is requiring "good engineering practices" good enough? * Could you explain this issue to your management? What would they do if this bug was discovered when the product was about to ship? How much would it cost your company to recover from a bug like this? (Looks to me like Netgear got off lightly on the bad-PR area.) * Should specifications mention this problem? Or would that just be clutter and distract from the main purpose of the spec? Note that "specifications" includes RFCs, product specifications, and contracts. Does the answer change if the protocol/product is widely deployed, or likely to be widely deployed? * How do you update implementations out in the field when problems like this are discovered? You can't even contact most of the owners because people don't fill out product registration cards. (Probably because they get too much junk mail when they do.) In this case, the ISPs should know which of their customers are using these routers. Even if you could contact the owners, would they bother to update their firmware? They don't see the symptoms of any problem. * How can we uncover bugs like this? The Netgear bug is somewhere between very hard and impossible to find by traditional testing. The lab gear required is too extensive/expensive. You could probably provoke it in a lab, if you already knew about it so you could build an artificial environment that would be more sensitive. Would that type of testing be cost effective? (Or should that testing effort be devoted to other areas?) * How can schools teach students about this type of problem? Is repeating this war story in a lecture good enough for somebody to get it? Where should this come on the priorities? [I hope this event becomes required reading for a CS degree, but I'm a network geek.] * Hardwiring some parameters is asking for troubles. How can we recognize (and teach) which parameters are OK to hardwire and which ones require configuration? Is there a middle ground where a parameter has a sensible default as long as configuration is possible? * What responsibility do corporations have to the Internet community as a whole? How can we encourage them to do the right thing when it costs a little more? Corporations includes hardware manufacturers, software vendors, ISPs/ASPs, web site operators... (Maybe we should include home users too, but I think it makes sense for their ISP to be responsible for their actions.) For example, why didn't somebody at Netgear do the back-of-envelope calculations and figure out how many routers their customers (ISPs) could install before they should install NTP servers too? * ISPs should be running time servers for their customers rather than freeloading off the net. The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.
The latest LWN security section (http://lwn.net/Articles/86022/) discusses a service called DidTheyReadIt.com. In short, the service adds web bugs to e-mail to try to determine whether the e-mail has been read. (NOTE: that link is currently subscription only. It will probably become freely available when the next edition is published on Thursday. Ed Felten also comments at http://www.freedom-to-tinker.com/archives/000607.html) To me the key excerpt is "This, of course, has some not-so-pleasant implications for personal privacy. While the company assures its potential customers that it respects their privacy, nothing is said about the privacy of the recipient who may not wish to divulge whether or not they've read a particular e-mail or where they've read it from. On the company's About Us page, they identify what kinds of people might want to find out whether an e-mail has been read — including some that make DidTheyReadIt sound like a must-have for potential stalkers: Users of online dating services such as match.com who want to know if their potential dates are reading their messages...or ignoring them." The articles do a good job of identifying the RISKS.
"Spim" is nothing new, but it is indeed a growing concern. In recent years we have seen more and more security issues that we've encountered before repeat themselves on different mediums and technologies. Spam is no different. In this case, though, it is much simpler. As asked by many people in the past: Would you stay with a service that you get 40 SMS spam messages every day with? No. You'd switch a provider. I am much more concerned with other security issues regarding cell phones, which are rapidly changing from privacy and eavesdropping concerns to Trojan horses and buffer overflows. That is an issue to be discussed in a different post, though. As to spam, there is no danger of it disappearing. In fact MessageLabs came out with some interesting statistics this week saying that 70% of all e-mail is spam: http://news.bbc.co.uk/1/hi/technology/3746023.stm.
Please report problems with the web pages to the maintainer