The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 21 Issue 86

Thursday 10 January 2002

Contents

Credit-card cloners' $1B scam
Monty Solomon via David Farber
Mag-stripes on retail gift cards
Tim Christman
Luton schoolboy profits from Euro chaos
Clive Page
Another Euro surprise
Otto Stolz
A Web site about PC security asking to lower PC/browser security
Koos van den Hout
Other blunders on "secure" Web sites
Skip La Fetra
Re: Harvard admissions e-mail bounced by AOL spam filters
Fredric L. Rice
User Web habits tracked by some music-swapping programs
NewsScan
Kaiser Permanente exposes medical record numbers
J Debert
ATT ignores it's own privacy policy?
J Debert
Peoples Federal Savings Bank explains their interest calculations
Jonathan Kamens
Re: "Buffer Overflow" security problems
Stephen Steel
Re: "Buffer Overflow" security problems and PL/I
Kelly Bert Manning
Buffer overflows aren't the only issue
Rex Black
Separate I and D spaces
Mike Albaugh
Info on RISKS (comp.risks)

Credit-card cloners' $1B scam

<David Farber <dave@farber.net>>
Mon, 07 Jan 2002 20:07:25 -0500

Homemade machines costing about $50 are being used to read credit-card
mag-stripes, without having to steal the cards.  The information is then
e-mailed abroad, where cloned cards are fabricated.  This has become a
billion-dollar-a-year enterprise.

[PGN-ed from Monty Solomon's e-mail to Dave's IP, subtitled Terrorists,
mobsters in on hacking racket, by William Sherman, *NY Daily News*
  http://www.nydailynews.com/today/News_and_Views/City_Beat/a-137421.asp]

  [The gadget was first demonstrated in maybe 1960s at Caltech as part of a
  demo on how poor the mag-striped credit cards were. In spite of that, they
  won.  Dave]


Mag-stripes on retail gift cards

<Tim Christman <tjc@wavetech.net>>
Sat, 29 Dec 2001 09:59:00 -0600

Here's a link to an article on MSNBC that I found interesting --
  http://www.msnbc.com/news/598102.asp?0dm=C216T&cp1=1

Many retailers are replacing paper gift certificates with small plastic
cards containing magnetic stripes, similar to credit cards.  Ideally, the
purchase of a gift card would result in a database being updated to reflect
the balance associated with the card's unique account number.

Some retailers are using sequential account numbers and have no provisions
to protect against a thief using a mag-stripe reader/writer to re-program a
stolen card or small denomination card so that it matches the account number
of a larger valued card purchased by someone else.  Many retailers even
provide a convenient 1-800 number so that the thief, knowing many valid
account numbers, can "shop" for a card of significantly greater value.

The RISK: A form of fraud, difficult to trace, involving a minimal
investment in equipment by the thief.  Also note that the thief only
requires the ability to query the back-end database (through the toll-free
number), not the ability to manipulate the records.  Perhaps more ominously,
the risk is angry family members who find a zero balance on their gift
cards!

Solutions: One retailer, mentioned in the article, uses optical bar-coding
which can't be re-encoded without defacing the card.  Another follows a
technique used by many credit card companies -- extra check digits are
included in the mag-stripe that are not visible on the face of the card.  It
seems astounding that this isn't being done by all.


Luton schoolboy profits from Euro chaos

<Clive Page <Clive@page.demon.co.uk>>
Sun, 6 Jan 2002 19:11:02 +0000

I hope you won't mind another Euro-related story, but this one is rather
charming.  The facts are taken from my local newspaper, the *Luton on
Sunday*, but the story made a brief appearance in some national papers.

Although the UK is one of the three European Union countries not to have
adopted the Euro, many large retailers in the UK announced that they would
accept them, but would give change in pounds sterling.  Among these was the
Debenhams chain of department stores.  (Incidentally, I'm told that
officially the plural of Euro is Euro, presumably to prevent language wars.)

Robert Sheilds, a 15-years old Luton schoolboy, decided he would like
experience of using Euro, so he changed 10 pounds to Euro at a bank, and
went on to his local branch of Debenhams to spend them.  He found that they
had programmed their tills as if there were 1.6 pounds to the Euro rather
than 1.6 Euro to the pound, but none of the sales assistants was experienced
enough to notice the error.  So after his initial purchase, he still had
more than 10 pounds in change.  He tried to tell the store staff of their
mistake, but they said the rate was programmed into the computer, and nobody
had the authority to change it.  So he carried on spending, and after two
hours, ended up with 130 pounds of goods, and 20 pounds in cash.  At this
point the store manager asked him to leave, saying "I think you've had your
fun".  Richard then took a train to Bedford (about 20 miles away) to try his
luck at another branch, but by this time staff had been alerted, and refused
all Euro transactions.


Another Euro surprise

<Otto Stolz <Otto.Stolz@lh-iplanet.rz.uni-konstanz.de>>
Tue, 08 Jan 2002 17:34:11 +0100

Here is one more example of the unexpected implications a large project
(such as the introduction of a new currency) can have.  It is not a
murderous risk, but you may find the story instructive, and perhaps amusing.

Today, I received an assessment from the local tax office.  The amount due
was the former amount converted from DM to EUR -- almost, but not exactly:
it was rounded up to the nearest multiple of 0,1 EUR.

Thus, the new annual amount was no more a multiple of 4. As the amount is
due by quarterly installments, the assessment told my to pay three equal
amounts (at certain dates every year) and another amount, which is 0.02 EUR
larger, at some other date.

Of course, my bank had already converted my standing remittance order from
DM to EUR. However, this being not adequate, I tried to adapt it to the new
tax assessment. (I dare not risk the trouble of owing anything to the tax
office, not even 0,02 EUR, would you?)

It turned out that the bank is not prepared to handle a standing order of
this type. I could have four annual orders instead, one per quarter. I
preferred to do it the other way: I left my original order as it was, and
placed a new order for 0,02 EUR (roughly 0,02 US$) per year. I hope well
that somebody at the tax office will be irritated with this extra paying.

The lesson to be learned: any change in a large, working system will have
unexpected, possibly undesired, results. Be on your guard!


A Web site about PC security asking to lower PC/browser security

<Koos van den Hout <koos@kzdoos.xs4all.nl>>
Mon, 7 Jan 2002 10:08:24 +0100

I received an e-mail this morning with an unknown .exe attachment which on
inspection seemed to do something with registry keys. Since it doesn't look
like any of the viruses I heard about recently I tried to look for it on
<http://www.mcafee.com/>.

Therefor, I visited <http://www.mcafee.com/> first using Netscape 4.72 for
Solaris (I use a Solaris workstation). The site shows a pop-up asking me to
enable an ActiveX plug-in, but I might be able to use the site without
it. The fact that I am using a different operating system for which an
ActiveX plug-in isn't available at all has never crossed the mind of whoever
designed that.

To top that, when I visit the site using Lynx 2.8.2 (a text-mode browser for
Unix, quite popular with blind or near-blind Internet users) I just get a
page asking me to enable scripting by LOWERING the 'Internet security'
setting on my Web browser. Never mind the fact that there are browsers for
which there is no scripting and that it can be a decision made for security
reasons. Literal text:

    3. In the Internet Control Panel, Select the Security tab
    4. Select the "Internet" zone
    5. If the security level is set to "High"
         a. Change the setting to "Medium" or click the "Reset" button
            for the Internet Zone

If McAfee wants to look like a company that sells products for 'Securing
your PC' they might want to set up their Web site so I don't have to LOWER
the security of my browser.

The security history of Javascript and ActiveX do not suggest to me that
they are welcome on a 'Securing your PC' site.

[Genuine virus investigators interested in the mail with 'ASD.EXE'
attachment should contact me privately]

Koos van den Hout  koos@kzdoos.xs4all.nl  http://idefix.net/~koos/


Other blunders on "secure" Web sites

<"Skip La Fetra" <Skip@LaFetra.com>>
Sat, 5 Jan 2002 14:15:07 -0800

In RISKS-21.84, Jeffrey Mogul ("When a 'secure site' isn't") points to some
"secure" sites which fail to properly implement https secure protocols.

In an incident from two years ago, my employer required use of an online
form which required credit-card info for cards which were billed to
employees.  This "secure site" was provided by an external supplier.
Naturally I checked for https use and browser "lock" icons.

All went well until the final confirmation screen.  In addition to the
"you have ordered zzzzz with credit card yyyyyy" expected, imagine my
surprise when I noticed that the URL of the page contained ALL of my
information:
"https://securesite.com/verification.htm?name=3Dyyyyyy,CardNumber=3D12345=
6789,ExpirationDate=3D12/31/2001" etc.
Being part of the URL "address", this information (including my name,
address, credit card number, and expiration date) was not protected,
even though the page was sent using "https".

A discreet call to the webmaster for this site provided a quick reply --
that all was okay, and all pages were sent using "https".

A second call (and a CC to a very-high-ranking IT manager) explaining
the difference between "PUT" and "GET" in forms processing produced a
fix -- and an apology.

Moral:  Even when the technology is secure, people can still blunder
around it.  The analogy which was effective in this case was talking to
their IT engineers about the US postal system -- and pointing out that
writing information on the outside of an envelope isn't secure even if
the envelope itself is protected.


Re: Harvard admissions e-mail bounced by AOL spam filters (R-21.84)

<"Fredric L. Rice" <frice@skeptictank.org>>
Tue, 08 Jan 2002 13:14:02

I'll doubtlessly draw a lot of flack in my inbound e-mail for this comment
yet what the hell: Harvard sent a lot of e-mail out to people who submitted
entrance requests with an AOL return e-mail address and then AOL filtered
them out as bulk spam.  As much as many people hate to admit it -- whether
it's deserved or not -- AOL users have a reputation in newsgroups
approximately one step above that of WebTV users.  "Get a real ISP and
people will talk to you" is something I see in newsgroups from time to time.

I doubt that Harvard's admissions department looks at an AOL address and
decides the applicant should be rejected based solely upon that fact but
what about prospective employees?  People in IT departments might wonder
whether someone's using AOL because they're not Internet savy enough to
figure out how to install, set up, configure and use a real ISP with real
client software packages.

AOL is marketed toward the average smuck with a plug-it-
in-and-it-will-just-work requirement.  It doesn't take a genius to figure
out how to use a real ISP with real servers and slients but AOL _is_
targeted to people who don't want to read "Internet For Dummies."


User Web habits tracked by some music-swapping programs

<"NewsScan" <newsscan@newsscan.com>>
Mon, 07 Jan 2002 09:23:26 -0700

The Web surfing habits of people who used the LimeWire, Grokster and KaZaA
music-sharing programs were surreptitiously tracked because those programs
were linked to an online sweepstakes game called ClickTillUWin, in which
players pick numbers and win cash prizes. The company that operates the
sweepstakes game says it told outside distributors to get users' permission
before installing the software, but in these cases that action was not
taken. The three companies have posted new versions of their software
without the tracking component, and LimeWire has issued an apology. (AP/*USA
Today*, 4 Jan 2002; NewsScan Daily, 7 January 2002)
  http://www.usatoday.com/life/cyber/tech/2002/01/04/limewire-tracking.htm


Kaiser Permanente exposes medical record numbers

<j debert <jdebert@garlic.com>>
Sat, 05 Jan 2002 23:52:37 -0800

Here's yet another example of how an organization fails to
abide by it's own security policies:

Kaiser Permanente has a Web site for members at http://www.kponline.org/ .

The first page here is the signon page, where one enters a medical record
number and their region to enter the site.

A statement concerning online security can be seen at:
"http://www.kponline.org/ns/signon/signonmember?view=Security"
<http://www.kponline.org/ns/signon/signonmember?view=Security> .
This statement indicates in the first paragraph that the medical
record number will be sent via SSL:

  Signing On
  You need to sign on using your Kaiser Medical Number.
  This number will be transmitted using secure technology (SSL).
  We need your Kaiser Medical Number before you get into the site
  for two main reasons:

(Note that this is the statement still in effect as of 1 Jan 2002.)

However no SSL connection is possible. Every attempt to obtain a secure
connection gets redirected to the non-secure page.

The people in Kaiser's kponline service center seem to have no clue and no
concern about this lapse. They say to disregard the security statement
because it applies only to those already signed up for access which is not
indicated in the security statement and cannot understand what the problem
is. Pointing out that that is not what is stated just annoys them.

The service reps say that no one can use the medical record number to access
personal information online. Seems like that's all they are concerned
with. They also claim that there is no way a medical record number can be
associated with a patient. I am fairly certain that these claims are easily
proven false.

The RISKS are quite obvious but Kaiser seems oblivious to the obvious even
when pointed out in detail.


ATT ignores it's own privacy policy?

<j debert <jdebert@garlic.com>>
Sat, 05 Jan 2002 23:23:56 -0800

Yet another example of how an organization ignores its own published
privacy policy:

ATT allows customers to send form mail using SSL on their Web site.  This is
to keep their customer's info and the message private.

But their people include the entire message in plaintext e-mail messages
sent in response defeating the purpose of the secure form.

Their privacy policy as published online essentially says that they will
keep customer info private.

RISKS? What RISKS? TO customers? So? What's the problem???


Peoples Federal Savings Bank explains their interest calculations

<Jonathan Kamens <jik@kamens.brookline.ma.us>>
Sun, 23 Dec 2001 21:43:41 -0500

Well, it took five months of letters and contacting the local news media and
several regulatory agencies, but I finally got Peoples to explain why their
interest calculations for June 2001 differed from mine.  So this message is
the retraction I promised I would submit if Peoples proved to me that their
interest calculations were correct.

(This, of course, does not change the fact that they stonewalled me for five
months and caused me all sorts of other grief when they "upgraded" their
computer systems in June.)

The technical explanation, for those of you who are interested.... In their
old computer system, they calculated interest for the month on the
second-to-last day of the month, using the ending balance for that day as
the ending balance for the last day of the month as well.  If in fact the
ending balance changed on the last day of the month, a credit or debit was
applied to the interest payment for the *next* month.  My calculations of
what my interest payment should have been did not include this credit, and
indeed *could* not include this credit because the bank never explained this
part of their algorithm to me (despite my multiple requests for a precise
explanation of how they were calculating interest).

On the bright side, their new computer system pays interest at the beginning
of the month for the entire previous month, so this particular bit of
brain-damage is gone.  But I won't be staying with this bank for long enough
to enjoy that particular "perk" -- would you stay with a bank whose officers
either were incapable of explaining to you how they calculate interest, or
simply refused to take the time to do so, until you pressured them about it
for five months?

See <URL:http://www.mit.edu/~jik/pfsb_problem/> for the whole story,
including this latest installment.

Jonathan Kamens


Re: "Buffer Overflow" security problems (Leichter, RISKS-21.85)

<Stephen Steel <steve.steel@kvs.com>>
Mon, 7 Jan 2002 19:12:39 -0500

The primary problem here is not the C language, but the associated standard
library, because the library is responsible for a lot of the C/C++
programming culture.  Almost every book on C programming had lots of
examples using sprintf(), strcpy() and other buffer overflow prone
functions. And programmers took these examples to heart, duplicating them in
the programming interfaces they wrote.

If the topic of buffer overflows came up, then strncpy() would probably be
mentioned. What a fine example this was for the beginning programmer: it
wouldn't overwrite the destination buffer if called correctly, but the copy
of the original string in the buffer had an unbounded length!  (since the
copy would not be properly NUL terminated if the source string was as long
or longer than the buffer size).

Its a great pity the first C standards didn't provide two variants of the
standard library and a standard means of selecting which variant would be
used. Safe versions of the problematic functions would be include in both
variants, and the recommended variant library would have omitted the unsafe
functions completely (for completely new code).

Stephen C. Steel <stephen.steel@kvs.com>


Re: "Buffer Overflow" security problems and PL/I

<bo774@freenet.carleton.ca (Kelly Bert Manning)>
Mon, 7 Jan 2002 21:54:47 -0500 (EST)

PL/I also supports string subscript range checking, in addition to Array
Bounds checking, but in working with PL/I since 1973 I've never seen a site
that had them as the site default. The site I currently work with runs at
100% processing capacity from 07:00 to 23:00 every day. OTOH, they feel that
DB2 is the way to go even though IMS still beats DB2 by at least 2:1, so
perhaps it would be worth giving this a try as the site

At the moment I can't recall whether a protection exception or a data
exception is the most common symptom, but I've got it down to the point
where I can quote the PL/I manual section advice about adding a Subscript
and Array bound Check prefix in my sleep for "unidentified routine
malfunction" types of errors when on call programmers give up and ask for DB
Admin advice.

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea1110/2.4.1.7?ACTION=MATCHES&REQUEST=subscriptrange&TYPE=FUZZY&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT

It rarely shows up in that overt form. I'm more concerned about it happening
quietly without ringing alarm bells. BTW, in the only major program where I
ever had to worry about array overflow(why not use a DB instead) I made the
array CONTROLLED with a REFER clause and checked the array size explicitly,
allocating a new larger array and printing and warning message if I reached
the array size limit.

It is always interesting to compare the confidence with which programmers
state that they don't feel they have an Array bound problem with their quite
manner when they get back to me with confirmation that adding the
stringrange and subscriptrange checks zeroed in on the problem.


Buffer overflows aren't the only issue

<Rex Black <rexblack@ix.netcom.com>>
Mon, 07 Jan 2002 21:35:35 -0600

As a long-time practitioner of software testing, let me mention that, while
buffer overflows are commonly exploited for security breaches, plenty of
software quality problems--some of which are quite risky to the users--arise
from other causes. Just off the top of my head, I can spout off the
following unforgivable "buggy software" stories, none of which have anything
to do with buffer overflows as far as I can tell:

* An expense reporting program, QuickXPense, that didn't have any data
quality bugs at all...at least until the operating system crashed. (Gee,
what are the odds of that?) Once the OS did crash, the file was randomly
corrupted, and the corruption cascaded with subsequent use, so ultimately
the entire expense report file was garbage. The vendor's technical support
staff was aware of the problem, but rather than a patch or a file report
utility, they suggested that I "e-mail your file and we'll fix it." Well,
sure, there's nothing private or personal in that file.

* The fact that some PowerPoint presentation files, if corrupted--by, say,
the computer going into power-saving hibernation at just the wrong time--in
as much as a single bit in some cases, can become totally unreadable by the
program. (See the first and last bullet for ways this might happen.)
Microsoft knows about this bug, but they choose not to include recovery
utilities in their applications. Instead, after a $100 paid support call,
they send you to a software developer--who would be called a "highwayman" a
couple centuries ago--who charges $400 for his recovery tool. Talk about
turning the incompetence of others into a business opportunity!

* The Windows NT network driver that came with a 3Com network card which, on
two out of three boots, is unable to see the network. No diagnostic messages
come up. Cold booting the system until communications are re-established is
the only cure.

* The automatic update software in my Toshiba laptop that recently
"upgraded" the drivers for the built-in Xircom MPCI modem--without prompting
me--which resulted in the loss of all modem definitions in my Windows
"Device Manager". (Device mismanager?) I wasted an entire day trying to get
the drivers reloaded. Toshiba's technical support was worse than clueless,
having me try the same thing over and over until the batteries on my cell
phone died, ending the call. Ultimately I had to go out and buy a new modem,
which also turned out to solve a bunch of connection problems I had,
indicating that the buggy setup problem was only the tip of the iceberg,
quality-wise, with this modem.

* The Lexmark printer I bought that didn't say anything in the manuals or
installation process about the fact that you couldn't install it on a
networked PC and access it from other systems on the network. After a few
hours of trying, I e-mailed tech support, only to get response that boiled
down to, "Oh, yeah, you can't do that." Oh, really? Why can't I do that? I
have a twelve-year-old Epson dot matrix printer that was built before anyone
had a small office network. I can share that printer just fine with every
computer on my network. This whiz-bang color printer-scanner-copier that I
bought in the day of ubiquitous small office/home office/home computer
networking can't be shared with other computers? Pshaw!

* The daily (or more often) crash that my Windows Me laptop computer
subjects me to, generally without warning, usually losing a good fifteen
minutes worth of work. I guess I should learn to save every thirty seconds?

If experienced people like me have problems like this, imagine the average
computer user who has no idea whatsoever about what is going on when her
system screws up. And why should they have to understand a computer to use
them? (Don Norman, in his book *The Invisible Computer*, discusses this
situation at length.) Ultimately, a computer is a tool, nothing more,
nothing less. I think we have a long way to go before we can claim levels
of quality consistent with what the makers of almost any other tool could
claim.

Rex Black, Principal, Rex Black Consulting Services, Inc., 31520 Beck Road
Bulverde, TX 78163 USA   +1 (830) 438-4830  www.rexblackconsulting.com


Separate I and D spaces (Re: Buffer overflows, Baker, RISKS-21.85)

<Mike Albaugh <albaugh@spies.com>>
Mon, 7 Jan 2002 15:22:45 -0800 (PST)

  [This feels like my days reading comp.programming (Been "clean and sober"
  off Usenet for over a year now :-) MEA ]

... As someone who, until very recently, wrote primarily code that was
executed from ROM, I need to point out that "corrupting running code" is not
needed.  If one can corrupt the subroutine return-address (normally _part_
of a buffer-overflow attack), one can point it wherever one wishes.  If a
sufficiently dangerous set of instructions (or bytes that could be
interpreted as instructions) already exists in the "instruction memory", one
can do the intended mischief.

As for Henry's assertion that such devices are "more vulnerable" because
"nobody bothers to run virus-checking software on them", I think this
exhibits touching faith in anti-virus authors and a mis-understanding of the
most common recent viruses.  Outlook could be in ROM and "Execute Only"
(No-Read) and I still would have gotten a mailbox full of mail whose subject
I won't include so this copy of RISKS will get through :-) Buffer-overflows
are indeed examples of shoddy programming practices, but they are hardly the
most popular vulnerability.  People who leave their doors open need not fret
overly about the quality of their locks.

Please report problems with the web pages to the maintainer

Top