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…
- - Begin Forwarded Message - - From: "Paul Ferguson" <firstname.lastname@example.org> Date: Thu, 21 Feb 2008 07:08:58 GMT Excerpt from techdirt.com. A brand new Japanese warship that apparently has the country's latest and greatest radar system, was unable to spot a fishing boat in its path, leading to a collision and two missing fishermen. This is raising all sorts of questions about the quality of the radar system, but some are saying that the collision was really due to human error and that the radar system is designed more to watch out for missiles in the air, rather than ships below it. That's a fair enough response, but does point out that vulnerabilities come from all directions—and you can make the best system in the world, but if it's looking for the wrong thing, it won't stop something bad from getting through. It does seem rather ironic to set this ship up to be the best in the world at spotting threats from the sky—and forget to include a decent system to find threats right next to it in the sea. Link: http://techdirt.com/articles/20080219/021718291.shtml There is a great security lesson to be learned here—if you're focused on securing only a subset of the entire threat landscape, the insecurities will generally occur in the places you're not focusing on. Focus on the Big Picture. "Fergie", a.k.a. Paul Ferguson, Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ [Gregory Hicks, Cadence Design Systems, 555 River Oaks Pkwy, San Jose, CA 95134 408.576.3609]
On 19 Feb 2008, the British Airports Authority (BAA) warned passengers via its website that a software problem was causing a reduction in baggage handling capacity. http://www.heathrowairport.com/ (According to the same website, the system is now fully operational.) British Airways (BA) went one better and warned passengers via its website that long-haul passengers who turned up with check-in bags would not be allowed to fly! This ban affected economy class only. (Of course. What did you expect?) http://www.britishairways.com/travel/home/public/en_gb (An update on BA's website dated 21st February also announces that the system has been reinstated.) BA's ban extended to transfer passengers. Precisely what a long-haul passenger who transferred to a BA flight at T4 already laden with hold baggage was supposed to do, was not explained. Source of story: http://www.theregister.co.uk/2008/02/20/heathrow_software_glitch/ Peter Mellor; Mobile: 07914 045072; email: MellorPeter@aol.com Telephone and Fax: +44 (0)20 8459 7669
Pakistan's attempts to block access to YouTube have been blamed for a near global blackout of the site on Sunday. Full story at: http://news.bbc.co.uk/1/hi/technology/7262071.stm (This looks like a misguided attempt to change DNS routing).
Democrats Abroad, the US Democratic Party's organization for its members living outside the USA, sends delegates to the party's nominating convention. This year Democrats Abroad held a "Global Primary" to select the delegation's candidate. People could vote in person in a few places, but the intention was for most of the voting to be over the Internet. Howard Dean, Democratic Party chair, said that the party would be observing the process closely, because it would be significant if Democrats Abroad held a secure, well-run election over the Internet. But the "Global Primary" wasn't secure or well-run. To begin with, registration to vote over the Internet was managed on unsecured web pages, an extraordinarily basic error. I brought this to the attention of a party official immediately; to her credit, she brought the objection up to the national organization, which responded that it didn't matter, because the actual voting would be secure. That's a serious lack of understanding: if registration isn't secure, then voting isn't secure because the registree's information can be hijacked. That information is also the kind that's used for identity theft. Voting was supposed to be secure because it required a "ballot number" and PIN. These were distributed by email. Oops! Someone who could capture or eavesdrop the outgoing mail stream delivering that information could own the vote in its entirety. Someone who could eavesdrop the mail coming to a particular address could steal that vote. Then there was the actual process of voting, which was handled (on secured Web pages) by a third-party company. I observed a vote. After supplying the "ballot number" and PIN, the voter was informed that his browser lacked an essential plugin which would have to be installed before the process could continue. The "plugin" was Java. The voter was on a slow, expensive dialup line which would have made it very painful to find and download the software, but luckily I happened to have the Java installer with me, and I started it up. Oops! The voter was using a Windows account without the privilege to install that software. The sketchy voting instructions indicated nothing about what would happen if the voter had to interrupt the process. Was the signin for one time only? If the user stopped the browser, would the process time out and give him another chance to vote later? There was no way to know: it was certain only that the process couldn't continue until the browser could use Java, and the user hadn't the privilege to install the software. In the event, I used Windows "run as" to install Java from the administrative account, and the voter was able to carry the voting process to the end. Could most users have done this? I doubt it. The vote itself was interesting, because along with the legitimate candidates it presented some who had formally withdrawn their candidature -- e.g., John Edwards, and there was no indication what to do about that. What happened to votes for non-candidates? No way to know. And why can't an Internet vote be kept current as of when it begins by simply not presenting non-candidates? Near the end of the process, after submitting his vote, the voter was given the choice of quitting or printing out a page showing his vote. Democrats Abroad had encouraged people to print out their votes, but it's hard to imagine why, since the special vote-printing popup page indicated clearly that it wasn't binding. So why bother? There are well-known risks at every stage of the episode, so I repeat: that whole process was neither secure nor well-run; moreover, its collection of personal information using unsecured Web pages exposed participants to the risk of information theft, and delivering notionally secure information by email is painfully bad judgment. The episode proves nothing except that well-intentioned people continue to make elementary but serious errors in designing and setting up processes that must be safe at every step if they are to be meaningful. Perhaps someone will bring this up to Mr Dean. My mail to the Democratic National Committee hasn't been answered.
That item reminds me of something that happened many years ago. I had two colleagues who I'd rather not name, as you'd surely recognize them. One of them had the habit of letting (paper) mail pile up in his inbox for a week or two, then dealing with it all at once. The other was a bit of a practical joker, who one day took all of the mail piled up in the inbox, wrote "DECEASED" on each piece, and put in the outbox. I am told that it took many months to sort out the resulting mess.
Brisbane has deployed an RFID based ticketless smartcard bus system its calling the 'go' card. The integrated travel system is described at http://en.wikipedia.org/wiki/TransLink_%28South_East_Queensland%29 And the ticketing system provider is Cubic http://en.wikipedia.org/wiki/Cubic_Transportation_Systems%2C_Inc. The system has been under test in the northern part of the network, and will be deployed citywide on Monday the 25th. Its actually already live, its just the card supply/distribution issue which is formally released next week. The system demands you cardswipe on and off, and computes journey values, and inter-system transfers. It uses GPS in buses and ferries, and station boundaries. From my observations, the system uses GPS quite heavily, and the drivers have a low level of engagement (at this time at least) in the system, concentrating on the (hopefully fewer) cash paying fares. I got myself and my son a card, and we found it was live on friday, so used it. From one days use, I had one problem, for 2 journeys. One was that because the bus uses GPS, and bus drivers in extremis stop at non-scheduled stops, but the readers are designed to not enable card operations except either when commanded by the driver, or at scheduled stops, it was not able to cardswipe me off. (presumably, after driver training, they will know how to enable this). The second was that having not been recorded off, yet getting on another bus inside 5 minutes, while I was carded off the first bus by the system, it refused to consider it a legal transfer, and recorded two journeys, one for the maximum fare. Refund pending, 10 day turnaround, after I rang in. There is a third fault, recorded in local newspapers: the system doesn't work in underground stations without driver overrride, presumably because the GPS can't work. Again, resolved after training, if they command/override. The system already had a 'upgrade day' failure when an attempted test at a few locations accidentally took down a major portion of the network for railway stations. My observation: Any new system is going to have glitches, but from my experience, failure for a random singleton is a bit of a worry. At least my son had a perfect score on his one. Operator training would have resolved my problem, if its still lacking 2 days before official launch, you have to worry that the refund phone desk is going to melt down next week. So if I take the best case, from 2 sample individuals for 4 journey instances on 8 buses, thats still 12% failure. On a lightly loaded system (both of us were the only card users for our journeys) I could complain that the system uses simply AWFUL warning messages such as "card reader not in service" when the bus is moving, rather than something human-centric such as "bus in motion: swipe off disabled" (or something) -the system as a whole is quite obviously working, the readers should not be implying they are dysfunctional. But more worryingly, the systems designers seem to be making some system design mistakes here. Humans and Human systems ARE NOT BLACK BOXES. So by designing a system with GPS, which attempts to forbid fare dodges by refusing to card off except at scheduled stops, they have taken two very useful 'side effect' behaviours out of the bus system: getting off the bus at non-scheduled stops, and getting off the bus between stops. Both are very common, both are until now entirely normal for many users of the system but both are apparently outside their system design plan and both have a strong financial penalty if the driver now doesn't (or can't) command/override the system. And designing a system with GPS, but which can't work in underground stations, when the system has at least two, with several more in planning, seems odd. Thirdly, it seems unfortunate that they can card me off the first bus when I card on the second, but can't short-circuit the excess fare reclaim. I'm trying to understand the likelihood that what that represents is an attempted gaming of the system, vs a legitimate user who is continuing their trip. I would have expected that it was within the system loss tolerances to at least try to start it preferencing the good case. Instead of which, if you don't register online, and audit your card, you can wind up loosing quite significant amounts of money if the journey you don't card 'off' on has a high maximum value. For instance, the stop I did get off on, and the stop I did get on the next bus were within 150m of each other. I wonder if the GPS precision has been dialed up too high? (nobody should care about bus journeys under 150m, and the same card being used inside 30min inside 150m distance looks to ME like a valid event) I still laud Brisbane Transport for doing this. Integrated ticketing is wonderful, as anyone who has used the Hong Kong system, or any of the worldwide 'Oyster' card deployments which I believe followed on from it. By comparison Sydney transport has just imploded on a smartcard contract, and their bus operator is buying up surplus ex-Brisbane driver-operated ticket consoles, to expand the pre-RFID/smartcard system. On the more security-conscious level, bus passengers who use the system, and register the card (you have to, to claim refunds or ensure against cardloss, which can hold up to $AU 200 in value) are now positionally accurate when on a bus to within 10m, which presumably has some Philip-K-Dick manifestation for the (police)man amongst us.
The US Treasury offers www.TreasuryDirect.gov for purchasing and managing a portfolio of securities issued by the Federal government. They've made some effort over time to make the site secure, and they've recently been beefing up security. I'd like to share details about two of their new security features. When you log into the site, it asks you for your account number and your password. However, you can't type your password. Instead, you are presented with a "virtual keyboard" whose keys have been scrambled, such that you have to hunt around for the characters in your password and click them one by one in order to enter it. Above the keyboard, it says, "A virtual keyboard, with keys that display in random order, is available to deter others from learning your password." The words "virtual keyboard" are a link, which pops up the following text (from <http://www.treasurydirect.gov/indiv/help/TDHelp/help_ug_274-SecFeaturesProt ectAcctLearnMore.htm> <http://www.treasurydirect.gov/indiv/help/TDHelp/help_ug_274-SecFeaturesProt ectAcctLearnMore.htm>) when you click on it: Virtual Keyboard: The virtual keyboard is one of many new security features introduced in TreasuryDirect as part of our on-going commitment to heightened password and account security to protect our customers' investments. The advantage of using the virtual keyboard, with keys that display in random order each time you log in, is that others are deterred from learning your password and Access Card information. When Java-Script is enabled, each time you arrive at the "Access your TreasuryDirect Account" page to log in, you will be presented with this virtual keyboard to enter your password. You'll use your mouse with the virtual keyboard to enter the letters, numbers, and special characters that are contained in your password. If you have received your Access Card, you'll also use the virtual keyboard to enter your Access Card values. (More about the Access Card in a minute.) To enter my password with this new keyboard, I must move my mouse slowly over it, search for each of the characters in my password, and pause over each one while I click it and then look at and count the number of characters in the password field to confirm that the last one was entered correctly. Then I have to do it all over again because I made at least one mistake the first time. All this on a "keyboard" in full view of anyone who can see my screen. It is unfathomable to me how the people who designed this feature could possibly think that it is more secure than typing a password on a keyboard. Now, about those "Access Cards". A few weeks ago, I got email from the Treasury notifying me that they were going to be sending me an access card which would be required in the future for accessing my account. About a week ago, they sent me a separate email message notifying me that the card would be arriving very soon, and I should contact them if I did not receive it within ten days. They also said that shortly after I received the card, I would no longer be able to log into the site without it. The card itself has a bar code, a nine-digit decimal serial number, and a grid with ten columns labeled A through J and five rows labeled 1 through 5. At the intersection of each row and column is a random letter or number, for a total of fifty. Once the access card is enabled for my account, after I enter my username and password, the site will display a drop-down list with several serial numbers, only one of which is actually mine, and with three grid coordinates (e.g., "C2"). To finish logging in, I will have to select the correct serial number and then enter (using the virtual keyboard) the three characters corresponding to the displayed grid coordinates. A demonstration of how this works can be viewed at <http://www.treasurydirect.gov/indiv/help/TDTutorial/tutorial.htm> <http://www.treasurydirect.gov/indiv/help/TDTutorial/tutorial.htm>. I don't know whether this technology was purchased from a third party or invented by the Treasury. It's an interesting attempt to implement inexpensive two-factor authentication. It's better than nothing, but it's obviously useless at preventing illicit access by people who are in physical proximity to the account owner, since they can simply sneak a photocopy of the card when the owner isn't looking.
http://www.enisa.europa.eu/pages/micro_enterprises_pilot.htm Building information confidence with micro enterprises Pilots for the introduction of Risk Management process ENISA issues a call to identify potential pilots to participate in a Risk Management promotion activity. The selected pilots will be financially supported by ENISA with maximum 20000 euros to install Risk Management within their IT infrastructure and perform an initial Risk Assessment. The selection criteria are stated below (see Background). Potential pilots are requested to use the attached form to send information relevant to their organisation and to the scope of a possible Risk Management introduction project. Proposals can be sent to ENISA until 29 Feb 2008. Main criteria for the pilots are their size, sector and geographical spread among different areas of Europe. In order to select potential pilots ENISA will use the following selection criteria: With the pilot ENISA wants to support small and micro enterprises in the introduction of Risk Management The potential pilot can be performed in cooperation with a multiplier organisation that guarantees the inclusion of multiple small/micro enterprises (i.e., small SMEs) The benefits from the pilot for the participating enterprises must be evident The pilot will maximise inclusion of multiple stakeholders (e.g. dissemination potential) The pilot consists of a group of small/micro organisations building up a network (e.g. part of a supply chain, independent members of a distributed structure etc.) The subject of the pilot must be the available ENISA material or alternatively an existing good practice in the area of Risk Management in Europe The pilot activity will be defined in some detail (plans, participants). Patrick O'Beirne, Systems Modelling Ltd. http://www.sysmod.com/ (+353)(0) 5394 22294
With all of the discussions that take place daily about laptop seizures, data breech laws and how crypto can often come to the rescue, I thought the readers of IP might be interested in a research project that was released today. We've been working on this for quite some time and are quite proud of the results. Ed Felten wrote about it on Freedom To Tinker this morning: http://www.freedom-to-tinker.com/?p=1257 "Today eight colleagues and I are releasing a significant new research result. We show that disk encryption, the standard approach to protecting sensitive data on laptops, can be defeated by relatively simple methods. We demonstrate our methods by using them to defeat three popular disk encryption products: BitLocker, which comes with Windows Vista; FileVault, which comes with MacOS X; and dm-crypt, which is used with Linux. The research team includes J. Alex Halderman, Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, and Edward W. Felten." "Our site has links to the paper, an explanatory video, and other materials." "The root of the problem lies in an unexpected property of today's DRAM memories. DRAMs are the main memory chips used to store data while the system is running. Virtually everybody, including experts, will tell you that DRAM contents are lost when you turn off the power. But this isn't so. Our research shows that data in DRAM actually fades out gradually over a period of seconds to minutes, enabling an attacker to read the full contents of memory by cutting power and then rebooting into a malicious operating system." Our full paper with videos and photos can be found on the Princeton website: http://citp.princeton.edu/memory/
The paper published today makes some pretty strong claims about the vulnerabilities of Microsoft's BitLocker, Apple's FileVault, TrueCrypt, Linux's dm-crypt subsystem, and similar products. So I put the folks behind it to a test. I gave them my MacBook laptop with FileVault turned on, powered up, encrypted swap enabled, and the screen saver locked. They were in fact able to extract the 128-bit AES key; I've put screen snapshots of their FileVault bypass process here: http://www.news.com/2300-1029_3-6230933-1.html And my article with responses from Microsoft, Apple, and PGP is here: http://www.news.com/8301-13578_3-9876060-38.html Bottom line? This is a very nicely done attack. It's going to make us rethink how we handle laptops in sleep mode and servers that use encrypted filesystems (a mail server, for instance). Archives: http://www.listbox.com/member/archive/247/=now RSS Feed: http://www.listbox.com/member/archive/rss/247/
Last weekend an illegal drag race in the Washington, DC suburbs ended in tragedy when a car (not involved in the race) plowed into a crowd of people who had gathered to watch the race. This column from the *Baltimore Sun* puts an interesting light on the idea of risks for those who routinely take part in something like the race. The writer spoke to a scientist who specializes in risk perception. The key remark from the piece: "Peters is a research scientist who specializes in risk perception, a psychologist who works for a think tank called Decision Research that studies, basically, why people do what they do. I had called seeking wisdom on why someone - or many someones, as it turns out - would gather on a dark, desolate highway in the middle of the night and wander onto it to watch people drive like maniacs. Peters had seen news reports of the crash, and was struck by the seemingly festive nature of the gathering, until it turned fatal, that is. "Everyone's out there, it seems like it's good old-fashioned fun, it's a very party-like atmosphere," she said. "There's the familiarity of it - people had done this before, and it had never been a problem before." Peters said it's that familiarity that makes even the obviously risky - walking onto a thoroughfare, after two fast and furious cars have screamed past you - seem like perfectly normal behavior." http://www.baltimoresun.com/news/local/bal-md.marbella19feb19,0,2107578.column John Curran, OMM Program IT Security Manager, CISSP, CISM, IAM 703-787-1712 [See also The Psychology of Risks, Dr. Leonard S. Zegans, in the December 2007 Inside Risks column in the *Communications of the ACM*. http://www.csl.sri.com/neumann/insiderisks07.html#211]
If this is as good as it purports to be, let's hope that only the white-hats use it! RainbowCrack is a general propose implementation of Philippe Oechslin's faster time-memory trade-off technique. In short, the RainbowCrack tool is a hash cracker. A traditional brute force cracker try all possible plaintexts one by one in cracking time. It is time consuming to break complex password in this way. The idea of time-memory trade-off is to do all cracking time computation in advance and store the result in files so called "rainbow table". It does take a long time to precompute the tables. But once the one time precomputation is finished, a time-memory trade-off cracker can be hundreds of times faster than a brute force cracker, with the help of precomputed tables. http://www.antsight.com/zsl/rainbowcrack/index.php Peter Mellor; +44 (0)20 8459 7669 MellorPeter@aol.com
I'm glad it's worked for you. I find that it *usually* works well for me. However, mine—purchased just 2.5 months ago—tried to steer me through dead-end streets twice on a single drive within 20 miles of my house in New Jersey... The first time, I decided to see if the Dead End sign was wrong. It wasn't; the GPS was. The other thing I noticed—from getting it wrong a couple of times—is that at complex intersections or where two possible turns are very close to each other, it's very easy to misunderstand which turn it wants you to make. I doubt there's any good technical solution to that short of a heads-up display showing the route it wants you to take, overlaid on reality. It is great, and I still use it. But I'm much less sanguine about the correctness of its database. Steve Bellovin, http://www.cs.columbia.edu/~smb
Please report problems with the web pages to the maintainer