On 04/14/00 04:35 PM Kragen Sitaker said...
>This is for the benefit of journalists and others who are
unable to
>read Perl.
>
>The recent email posted by Luciano Ramos, which he
claimed to be from
>"people at dansie", makes several assertions that are
directly contradicted by
>the information in the original BUGTRAQ post. There are
three
>possibilities:
Actually, 4 -- Luciano' email was taken out of context, his
server setup was secured through other means, and we're
reading a "lull the customers" message that isn't indicative of
the security or the insecurity of the shopping cart itself.
>Possibility #3 could be verified by any of Dansie's customers;
not only
>have none of them posted contradictions of the original
message to
>BUGTRAQ, but the "people at dansie" did not assert that the
code was
>inaccurate.
>
It's there.
It never made it to production at our shop, not only b/c of that,
but because of its lame handling of credit card information . I
don't believe that it's ethical to lull your customers by making
them enter their cc info via a SSL connection, and then email
the "secure and private" information around in clear text like
a couple of marketing droids with no brains.
>I am not one of Dansie's customers, so I have no direct
evidence about
>possibility #3. I would like to hear from Dansie's customers if
they
>can confirm or deny the original post.
>
Consider it confirmed.
>I'd like to see confirmation or denial of possibility #1 directly
from
>Dansie.
>
>Possibilities #1 and #2 should certainly lead to criminal
prosecution
>of the author of the software. This appears to be one of the
most
>blatant and wide-ranging acts of computer crime in history,
surpassed
>only by the 1988 Internet Worm and Microsoft's recent
"Netscape
>engineers are weenies!" backdoor.
Never underestimate the power of quotes taken out of
context.
Further, never underestimate the power of naivete. I don't
think that it is malicious -- I think that it was just a really dumb
idea.
>> There is "no" processes Craig can run on the server as this
email suggest.
>> Yes, he can wipe the vars.dat to protect his copyright and
prevent the cart
>> from working, but the only people that need to worry are
"theifs" anyway.
>> The cart "cannot" retrieve cc information or any other
information that
>> could cause a security risk.
>.. . .
ROFL
>
>If the code that was posted is the real code, and if the
backdoor
>element is indeed "immune to data validation" --- and
probably even if
>Dansie tried to validate it, given the quality of the bits of code
that
>were posted and referenced in another BUGTRAQ post ---
then this
>statement is erroneous. Not only could a person who knew
the secret
>keyword wipe your "vars.dat" --- something not mentioned
by the posted
>code --- they could also wipe your whole website, or insert a
second
>backdoor to send all of your customers' credit card numbers
to them.
>
vars.dat is the initialization file containing all of the user
defined variables. It resides in the same subdir of your cgi-bin
as the cart. If you can modify or delete it by remote control,
you can do other things as well. Like many dumb ideas, using
it as a copy protection scheme can blow up in your face(and in
fact, I believe it has). It's just as unintelligent as putting a pipe
bomb under the seat of your car to prevent "thiefs"(sic) from
driving your car off. Sooner or later, it will harm you or one of
your loved ones, and maybe will never hurt more than one or
two of the "thiefs"(sic). Further, deleting or munging it to stop
copyright violation will only seriously damage people who are
not backing up critical files. 5 minutes to fix the improper
email, half an hour to look for and fix any other issues, restore
the vars.dat, and you're back in business.
I think that this issue is probably dead, now. It was a lousy
product with a lame-o protection scheme, nobody wants it,
and now the only people who will purchase and install it are
the ones who need this sort of punishment.
