The RISKS Digest
Volume 21 Issue 92

Wednesday, 20th February 2002

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

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…

Contents

Patriot misses again
Lord Wodehouse
Researchers claim to crack Wi-Fi security
Monty Solomon
When machine metadata fails, address humans
Diomidis Spinellis
Unwitting cell calls swamp 911 systems
Monty Solomon
Abuse of intercept capabilities: 'Tampa' affair
Geoffrey Brent
PayPal's tenuous situation
Jeff Jonas
Ice-skating judging solution
Ken Knowlton
Re: Miami-Dade OKs touchscreen voting
Alan Brain
An unlocked system can be compromised quickly
Greg Searle
Dangerous characters
Mark Lomas
Computerized assistance with non-standard punctuation
David Piper
Re: Homograph problems
Geoffrey Brent
What's a buffer overrun problem?
William P. N. Smith
Sorry, that number is now in service
Gene Spafford
Re: Officer calls for refund of 'speeding' fines
Henry Baker
Re: Social Security numbers on tax envelopes
Robert Ellis Smith
The Security Risks of Programs That Automatically Update
Scott Schram
New Security Conference - GOVSEC, Call for Presentations
Jack Holleran
Info on RISKS (comp.risks)

Patriot misses again

<Lord Wodehouse <w0400@ggr.co.uk>>
Tue, 19 Feb 2002 11:06:49 +0000 (GMT Standard Time)

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/


Researchers claim to crack Wi-Fi security

<"monty solomon" <monty@roscom.com>>
Fri, 15 Feb 2002 12:24:10 -0500

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]


When machine metadata fails, address humans

<Diomidis Spinellis <dds@aueb.gr>>
Tue, 19 Feb 2002 15:16:20 +0300

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
products@rietta.com."

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

<Monty Solomon <monty@roscom.com>>
Wed, 20 Feb 2002 18:46:02 -0500

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


Abuse of intercept capabilities: 'Tampa' affair

<Geoffrey Brent <g.brent@student.unsw.edu.au>>
Thu, 14 Feb 2002 15:25:01 +1100

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's tenuous situation

<"Jeff Jonas" <jeffj@panix.com>>
Sun, 10 Feb 2002 06:38:08 -0500 (EST)

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.


Ice-skating judging solution

<Ken Knowlton <KCKnowlton@aol.com>>
Tue, 19 Feb 2002 13:59:10 EST

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]


Re: Miami-Dade OKs touchscreen voting (Price/PGN, RISKS-21.90)

<Alan Brain <ab@softimp.com.au>>
Fri, 15 Feb 2002 16:38:49 +1100

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.


An unlocked system can be compromised quickly

<"Greg Searle" <greg_searle@hotmail.com>>
Fri, 15 Feb 2002 12:41:06 -0500

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.)


Dangerous characters

<"Mark Lomas" <mark.lomas@tmalomas.com>>
Fri, 15 Feb 2002 00:06:57 -0000

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.


Computerized assistance with non-standard punctuation

<"David Piper" <dxp7949@lausd.k12.ca.us>>
Thu, 14 Feb 2002 08:33:11 -0800

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


Re: Homograph problems (Kline, RISKS 21.91)

<Geoffrey Brent <g.brent@student.unsw.edu.au>>
Sun, 17 Feb 2002 17:12:24 +1100

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


What's a buffer overrun problem?

<"William P. N. Smith" <wpns@compusmiths.com>>
Wed, 13 Feb 2002 10:46:41 -0500

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    wpns@compusmiths.com    N1JBJ@amsat.org
ComputerSmiths Consulting, Inc.    www.compusmiths.com


Sorry, that number is now in service

<Gene Spafford <spaf@cerias.purdue.edu>>
Mon, 18 Feb 2002 09:03:23 -0500

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.


Re: Officer calls for refund of 'speeding' fines (Solomon, R 21 91)

<Henry Baker <hbaker1@pipeline.com>>
Fri, 15 Feb 2002 13:31:26 -0800

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]


Re: Social Security numbers on tax envelopes (Klein, RISKS-21.91)

<"Robert Ellis Smith" <ellis84@ma.ultranet.com>>
Thu, 14 Feb 2002 12:45:57 -0500

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
privacyjournal@prodigy.net  http://www.privacyjournal.net


The Security Risks of Programs That Automatically Update

<Scott Schram <scott@schram.net>>
Fri, 15 Feb 2002 09:31:47 -0600

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 <scott@schram.net>  http://schram.net


New Security Conference - GOVSEC, Call for Presentations

<Jack Holleran <Holleran@severnapark.com>>
Thu, 14 Feb 2002 00:22:20 -0500

  [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 spatterson@ntpshow.com 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

x
Top