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 long running saga of the Patriot missile continues. Spacedaily reports (http://spacedaily.com/news/020217211535.6h8kn7ih.html) that two of three missiles fired recently at White Sands under "battlefield conditions" with three targets failed to intercept them. ... and someone wants to build a missile defence system ... (and if you still think it is a good idea, check back through the RISKS archives) John, SCS Global Services, GlaxoSmithKline, Medicines Research Centre, Gunnels Wood Road, Stevenage SG1 2NY UK +44 1628 482 634 http://www.gsk.com/
Ephraim Schwartz, InfoWorld, Thursday, February 14, 2002 Researchers Claim to Crack Wi-Fi Security; Proponents deny wireless networking spec is vulnerable to hijack, authentication attacks. http://www.pcworld.com/news/article/0,aid,84424,00.asp A University of Maryland professor and his graduate student have apparently uncovered serious weaknesses in the next-generation Wireless Fidelity security protocol known as 802.1x. In a paper, "An Initial Security Analysis of the IEEE 802.1X Standard" funded by the National Institute of Standards, Professor William Arbaugh and his graduate assistant Arunesh Mishra outline two separate scenarios that nullify the benefits of the new standard and leave Wi-Fi networks wide open to attacks. The use of public access "hot spots" are particularly vulnerable to session hijacking because these locations do not even deploy the rudimentary Wired Equivalent Privacy protocol. "This problem exists whether you use WEP or not, but it is trivial to exploit if not using WEP," said Arbaugh. Flaws Described Dubbed "session hijacking" and "man-in-the-middle," both attacks basically exploit inherent problems in Wi-Fi as well as exploiting how the new 802.1x standard is designed. "Here's how session hijacking works. The hacker waits for someone to finish successfully the authentication process. Then you as the attacker send a disassociate message, forging it to make it look like it came from the AP [access point]. The client [user] thinks they have been kicked off, but the AP thinks the client is still out there. As long as WEP is not involved you can start using that connection up until the next time out, usually about 60 minutes," said Arbaugh. [...] [Fine article. Well worth reading The Rest of the Story. PGN]
The aggressive indexing of the Google search engine combined with the on-line caching of the pages in the form they had when they were indexed, is resulting in some perverse situations. A number of RISKS articles have already described how sensitive data or supposedly non-accessible pages leaked from an organization's intranet or web-site to the world by getting indexed by Google or other search engines. Such problems can be avoided by not placing private information on a publicly accessible web site, or by employing metadata such as the robot exclusion standard to inform the various web-crawling spiders that specific contents are not to be indexed. Of course, adherence to the robot exclusion standard is left to the discretion of the individual spiders, so the second option should only be used for advisory purposes and not to protect sensitive data. Today I came across a web page <http://www.rietta.com/sqlconnect/> with metadata addressing the humans reading a page rather than the spiders. The page was apparently inadvertently, from the company's point of view indexed by Google: "NOTE: This page has been picked up by Google before we intended for it to become visible. The SQL Connect software is completed, but we still have to finalize the documentation and this website in order to release it. Please check back soon for the download, or if you have questions, you can e-mail firstname.lastname@example.org." Worryingly, the same company also markets RoboGen, a product to manage the robot exclusion specification file: "RoboGen allows you to easily manage a robot exclusion file to control search engines indexing your website. Featured in magazines and books, RoboGen is the most popular and easy to use program for managing search engines that visit your website." The moral? The web has a long (and growing, see <http://www.archive.org>) memory. Information leaks due to incorrect spider metadata and other errors can only be partially contained by addressing new metadata to humans. Diomidis Spinellis - http://www.dmst.aueb.gr/dds/ Athens University of Economics and Business (AUEB)
Unwitting Cell Calls Swamp 911 Systems, By JILL LEOVY, Los Angeles Times, 19 Feb 2002 Frustrated by the large volume of 911 calls caused by people accidentally hitting programmed buttons on their cell phones, police and emergency response authorities are seeking new ways to keep systems from becoming overloaded. Nearly two-thirds of all the 911 calls from wireless phones in California, and even higher proportions elsewhere in the country, involve people pushing emergency buttons on their cell phone keypads without knowing it, authorities say. http://www.latimes.com/technology/la-000012715feb19.story
Last year, shortly before a federal election, the ship 'Tampa' made Australian headlines when it rescued a boatload of about 400 refugees off the Australian coast. A controversy followed on whether Australia would be obliged to give the 'Tampa' harbour and accept said refugees. It has recently been alleged that Australia's Defence Signals Directorate (DSD) intercepted communications between the skipper of the 'Tampa' and the Maritime Union of Australia and passed this information on to government. By law the DSD is banned from intercepting Australian communications (with certain exceptions not relevant here). The Defence Minister, Robert Hill, has issued a very carefully-worded response: there were "no significant breaches" of these rules, and guidelines designed to protect privacy were adhered to "in the broad". While denying that MUA communications were intercepted, Hill conceded that the DSD had broken its rules relating to spying on Australians. Hill has given assurances that the breach was not a major one, but without any information on the nature of the breach confirming that is another matter... http://www.theaustralian.news.com.au/common/story_page/0,5744,3766399%255E601,00.html http://www.abc.net.au/am/s480125.htm http://www.smh.com.au/news/0202/14/national/national3.html et al. Since the Tampa crisis played a very major role in the resurrection of the Howard government's political fortunes, quite likely altering the outcome of last year's federal election, the possibility of illegally-obtained intercepts being used for political ends is not being taken lightly by anybody (except, perhaps, that government...) Geoffrey Brent
PayPal is much in the news after their NASDAQ IPO was further delayed due to a lawsuit filed by CertCo concerning patent infringement. (the risk of frivolous software patents had been discussed before in RISKS). More damning in my eyes are the problems PayPal had to reveal in their prospectus and the lack of discussion I've seen about the failures: Their prospectus is found at: http://www.edgar-online.com/bin/edgardoc/finSys_main.asp?dcn=0000912057-01-543278 It's interesting reading: they admit that they've never made any profit, might never make a profit, and all the ways they might be squeezed out of business. > AMENDMENT NO. 2 TO FORM S-1 REGISTRATION STATEMENT > UNDER THE SECURITIES ACT OF 1933 PAYPAL, INC. > We have not reached profitability to date. > We have accumulated net losses of $264.7 million > from our inception, March 8, 1999, through September 30, 2001, > and net losses of $90.6 million during the nine months > ended September 30, 2001. > During the four months between July and October 2000, > we experienced a significant fraud episode and, as a result, > we incurred gross losses due to unauthorized charge-backs totaling > $5.7 million. This amount represented 64.0% of total charge-backs > due to unauthorized transactions for the year ended December 31, 2000. Ummm, what was done to prevent this fraud from recurring? Anyone caught? Anything learned? > For the year ended December 31, 2000, the amount of losses > with respect to unauthorized use of bank accounts totaled $0.3 million. > The gross amount of charge-backs received through September 30, 2001 > with respect to unauthorized use of credit cards for transactions > that occurred during the nine months ended September 30, 2001 > totaled $3.2 million. For the nine months ended September 30, 2001, > the amount of our losses with respect to unauthorized use of > bank accounts totaled $0.9 million. Gee, where do I get my share? > We may experience breakdowns in our payment processing system > that could damage customer relations and expose us to liability, > which could affect adversely our ability to become profitable. So why not act proactively with better failsafes such as having 2 active/active sites, automatic load balancing to shift the load in case of failure, etc. All things available to buy and implement NOW! > A system outage or data loss could have a material adverse effect on our > business, financial condition and results of operations. > To operate our business successfully, we must protect our payment processing > and other systems from interruption by events beyond our control. > Events that could cause system interruptions include: > * fire; > * earthquake; > * terrorist attacks; > * natural disasters; > * computer viruses; > * unauthorized entry; > * telecommunications failure; > * computer denial of service attacks; and > * power loss and California rolling blackouts. > We depend on two third parties for co-location of our data servers > and rely upon these third parties for the physical security of our servers. > Our servers currently reside in facilities in Santa Clara, California. All your eggs in one basket: power failure, telecom failure, etc are all totally fatal. > Currently we are not able to switch instantly to another back-up site > in the event of failure of the main server site. > This means that an outage at one facility could result in our system being > unavailable for at least several hours. This downtime could result in > increased costs and lost revenues which would be detrimental to our business. I see no excuse for that since quality of service load balancing routers exist specifically for such protection. > Our primary Internet hosting provider, Exodus, recently filed for protection > under Chapter 11 of the U.S. Bankruptcy Code. > Subject to court approval, Britain's Cable and Wireless plc has agreed to > purchase Exodus's data center assets. We cannot predict the effect this may > have on its ability to continue to provide reliable service. > We have engaged Equinix, which is located in the same geographical area, > to replace Exodus as our primary Internet hosting provider and intend to > complete this transition in the first quarter of 2002. So how's the transition going? > Our infrastructure could prove unable to handle a larger volume of > customer transactions. Any failure to accommodate transaction growth > could impair customer satisfaction, lead to a loss of customers, impair > our ability to add customers or increase our costs, > all of which would harm our business. With their inability to handle cutovers from emergencies, I don't see how that's making things scalable.
What a marvelous solution to the problem exposed by the Olympics ice-skate judging brouhaha: use computers and random numbers, and-- most important -- remove the process from public view! [The algorithm reported: 14 judges, reporting anonymously, with the computer program randomly and without accountability throwing out a handful of votes. Sounds like we are once again back to the wonders of nonaudited electronic voting systems that have received so much discussion in RISKS, such as the following item. PGN]
The risks for vote-rigging on COTS systems [include]: a) Someone tweaks the BIOS of the voting machines. b) Someone tweaks the OS of the voting machines. c) Someone tweaks the applications code d) Someone tweaks the compiler. a) Can best be dealt with via physical security only - have non-flashable BIOSes, and disallow unauthorised access. The rest require both a publicly available Open Source codebase, and physical security to make sure that what you think is on the machine, actually is. And that the right OS has been installed, and the right compiler used. Well, it's not a touchscreen system per se, but close enough. Have a look at http://www.elections.act.gov.au/EVACS.html. The source code's available at http://www.elections.act.gov.au/evacs.tar.gz Compile with a gcc compiler, run on FreeBSD or Linux. Conversely, if the voting is being done with machines where the OS, Applications Sourcecode and Compiler aren't Open Source, then security is problematic.
Audrie Krause's submission on non-profit's security brought up the problem of not locking a workstation when walking away from it. If you don't understand why locking your system is so important, try the following exercise. (Don't worry — if you hit "Cancel" in the final step** as instructed, it won't actually do anything. This sequence would be slightly different on Windows 95/98/ME boxes, which can't be effectively locked, anyway.) On an unlocked system (preferably yours!): Hit Windows Key-E to bring up an Explorer window. Select the "C:" drive in the right pane (tab,down arrow, or click on it). Hit Alt-Enter to bring up the Properties dialog for that drive. Click on the "Sharing" tab. Click "Share this Folder" if it is not selected. Only if "Share this Folder" was already selected, click the "New Share" button, enter a share name, and hit "OK". ** Hit "Cancel" to dismiss the dialog safely. DON'T HIT OK. Close the Explorer window. If you had hit "Ok" instead of "Cancel" above, this sequence would give EVERYBODY TOTAL ACCESS to the C: drive. This means that anyone on the local net could read and write any file or directory on your drive, and you wouldn't know it. A malicious person with physical access to the machine only cares about being able to freely access your machine from the privacy of another workstation. They don't care that everybody else has access, as well. So, how long did the exercise above take you? It would only take less than 10 seconds for an experienced Windows user, and there is no visible evidence that the system was tampered with. How long does it take for you to walk to the coffee machine and back? Lock your systems when you walk away. This exact thing actually happened to an employee at the company I work for. Eventually she realized that her system was wide open to the network. Worse, some damage had been done by a remote user. They never found out who did it. If you're worried that I'm giving away some secret information, don't. This can be accomplished in many ways, and the information is public knowledge. This particular sequence would usually be selected as the fastest way to get in, make the change, and get out. I'm just attempting to impress how quickly a Windows system can be compromised. (If you really hit "Ok" instead of "Cancel", you will want to remove the new share, quickly.)
Many of us are familiar with web sites that, because of inadequate checking of user-supplied data, are vulnerable to attack. Careful filtering of data can prevent such attacks. Waitrose, a well-respected chain of UK shops, took this a little too far on their on-line shopping site. It appears that they decided that the humble apostrophe was too dangerous to appear in user input. I noticed this because it changed the message I had asked to be sent with some flowers for my wife. As today is St Valentine's day, I imagine a large number of customers had their messages changed.
In RISKS-21.91 Toby Gottfried notes potential problems with the name of Microsoft's new project ".Net" violating common rules of English sentence structure. Robert Marshall advises that Google may be stripping self-defined "extraneous" punctuation from email addresses. I used to live on a street called "Oak Crest Way". One day my address was OCR scanned by some mailing list company and the "O" was resolved as a period. I then began to receive junk mail addressed to: ".Ak Crest Way" Notice how the "intelligent" software automatically capitalized the "A". I received several pieces from different junk mailers as the address was resold. Then one day a new junk mail piece arrived addressed to: "Ak Crest Way" Another "intelligent" program had automatically stripped out the leading period. I don't have high hopes for ".Net". David R. Piper, Administrative Analyst, Los Angeles Unified School District Maintenance&Operations, District I, 1500 E. 14th Street, Los Angeles, CA 90021
Merlyn Kline mentions homograph problems with lowercase L, uppercase I, and the number 1. I had the misfortune to encounter a net access program that gave me a randomly-generated password with three of these in it... and wouldn't allow font changes. With 27 possibilities to try, I was glad it didn't lock-out after three failed attempts. Geoffrey Brent
Something about being doomed to repeat history: > Software: Telnet Service in Microsoft Windows 2000; Telnet > Daemon in Microsoft Interix 2.2 > http://www.microsoft.com/technet/security/bulletin/MS02-004.asp. [...] > The implementations [...] contain unchecked buffers in the > code that handles the processing of telnet protocol options. and > Software: Microsoft Windows 95, 98, 98SE, NT 4.0, NT 4.0 Terminal > Server Edition, 2000, XP > http://www.microsoft.com/technet/security/bulletin/MS02-006.asp. [...] > A buffer overrun is present in all implementations [of SNMP]. It's nice that they are closing holes, but with all the Navy shipboard networks that are apparently running Windoze, 'overflow' is going to take on a brand new meaning. 8*} William Smith email@example.com N1JBJ@amsat.org ComputerSmiths Consulting, Inc. www.compusmiths.com
Long ago, I configured the router for our center to reject packets coming from nonsensical addresses. These include packets coming from the outside with addresses of inside hosts, with the loopback address as source, and with any unassigned IP addresses. The latter were taken from the IANA list of "reserved" IP ranges. Blocking these packets helps keep away packets employing address spoofing and DOS attacks with falsified "from" addresses. Needless to say, this is a desirable outcome! Because our router config is complicated, it is something I try to avoid changing (or even looking at) unless something breaks. Usually, that is obvious — we install something new, or add a new subnet, and things need to be adjusted. About 3 months back, my email to a long-time friend started bouncing. Well, to be specific, it would sit in our queue and timeout — it couldn't seem to get delivered to the destination. I didn't think much about it because hosts sometimes go down. Plus, her company was undergoing some expansion and moving offices. But the problem persisted. A mutal friend reported no such problems, which really seemed odd. Then, I tried sending email from a separate account I have outside the university. It got through! But email to my account at CERIAS failed. How odd.... Further investigation revealed that I could do a traceroute right up to her company's firewall, but no further. Meanwhile, the admin at her firm reported he could traceroute to our router, but no further. Really odd! An inquiry to their ISP revealed no filter rules that blocked traffic. And I could reach their machine from other campus hosts. It must be our router. It took me nearly a full day to find the offending line buried deep within the router config. This was complicated because I generate part of the config using a macro preprocessor (saves some of the tedium of typing the almost-same line over and over). It appears that sometime in 2001, the 69.x.x.x IP range (plus others) went from "reserved" to "assigned". However, if there was some place this was announced, I never saw it (or it never registered to me). Meanwhile, my router was happily blocking all the traffic from my friend's site. There must be a moral to this story, but I am unsure what it might be. I can say that I am still blocking address ranges, but now I have a reminder in my mailer to check the assigned number list every 6 months.
This is a very old problem. Road & Track did an article 25+ years ago about Italian drivers who would take their cars out on the Autostrada tollroad and keep and frame the stamped toll receipt which proved that they achieved 200 kilometers per hour (or whatever) for a particular Autostrada segment. I think that the Italian government got wise and started automatically printing out speeding tickets along with the toll receipts! [typo 91 corrected in archive. PGN]
Gee, a new federal law prohibits federal agencies from doing this - but it doesn't kick in until November 2004!, according to Privacy Journal's new Compilation of State and Federal Privacy Laws. Robert Ellis Smith, Publisher, Privacy Journal, Providence RI firstname.lastname@example.org http://www.privacyjournal.net
I've just completed an article addressing some risks of programs that update themselves: Rather than a bona-fide update, the auto-update feature could be used to send programs with undesired features. The activity of these updaters would not be detected by firewall tools, as they are expected to be periodically checking for updates and downloading them. Further, the most careful reverse-engineering of the updater would not reveal anything unexpected. http://schram.net/articles/updaterisk.html Comments are welcome! Thanks, Scott Schram <email@example.com> http://schram.net
[Jack is seeking participant ideas, not completed works, by 23 Feb. PGN] As the program develops, information will be posted on http://www.govsecinfo.com GOVSEC 2002 is the only conference dedicated to enterprise security for the government. GOVSEC offers two powerful conferences in one. GOVSEC will address physical security issues and information security issues. If you have any questions on submitting a Call for Presentations for GOVSEC 2002, please contact Sharon Patterson, CMP, at firstname.lastname@example.org or call 703.941.5896. GOVSEC is produced by National Trade Productions, Inc. 313 S. Patrick Street, Alexandria, VA 22314. Phone 703.683.8500
Please report problems with the web pages to the maintainer