bodhisattva

support says its on my end so I'll investigate further and see if I can figure out what caused the handshake with paypal to go awry. good luck everyone.

any luck for anyone? mod security is not blocking and there are no typos. never had a prob before a couple weeks ago. also was suggested by Matt that it could be a firewall blocking it but same results even with it off. I haven't heard back from WHCMS support since so I am hoping a client knows whats wrong.

I am also experiencing this. started happening on/around the 16th. IPN is set but no invoice or subscription transmissions are connecting with the accounts. they show in the log with an error.

i think you need to enter a return url, like its explained to do with the paypal ipn, but with the 2checkout link. i could be wrong. is this how its done, or should i open a support ticket to be assured that its setup right? kind of wondering why this wasn't answered. i'd think having people search the forums to find an answer is better than having to answer support tickets, but thats just me i guess.

I agree. It would be nice to have a field in the administrators account table to dictate if they want this on or off by default.

yeah, can confirm DA rejects non-email addresses now in the initial setup of a forwarder, but it will let you edit one once its in. edit: etc/virtual/yourdomain/aliases add: support: "| /usr/local/bin/php -q /home/admin/domains/yourdomain.com/public_html/cms/pipe/pipe.php"

probably is not. i am just be reactionary/paranoid.

ok cool. what about to block dynamic content in trojan image files, (<script> cookie.stealer(blah blah blah) </script>) ? i am still of the mindset that if you are going to have image uploads there needs to be some image parsing, through GD or AJAX along those lines, that checks for dynamic content, or that the file is in fact a valid image file and not something else with that extension. btw, not trying to be a pain. just wanting to make sure things are as secure as can be, for everyone. i had attachment uploads off by default, but thats just because i hadn't seen the code to know how secure it was, and i guess i went into wait and see what happens with others mode. i appreciate the quick fixes and solutions and the new release. good job Matt!

i think only some servers are vulnerable. probably a setting in php.ini or how it was compiled. on the servers that are effected what it comes down to is dynamic content within the files executes, running a callback to another script, that from whats been said here than plants yet another script, i guess after retrieving the servers vitals. i didn't see this in full action, so i can only speculate. but i have seen this happen with peoples imagebucket scripts. its a known exploit. it would be nice to know 100% what makes some servers vulnerable, and what causes the code to just display as raw output, instead of executing on others. there might be a possibility of XSS and a script on another server somehow executing the code. but i think thats more complex than this. maybe its as simple as server wide .htaccess settings.

is the patch already available?

i don't think it actually goes to the tmp directory. i think thats just a broken link, but i could be wrong. most important thing is it doesn't goto the attachments folder, which the exploiter uses to load their script directly. likely this is a shell script they are uploading if they are trying to call it directly. (at least thats how it went on my site) now if it were a link they were waiting for you to open it could likely have javascript embedded in the image that grabs the cookie info from your home system and relays it to a remote script that records all your pw and other info. but i don't think that is the case here.

funny, someone just uploaded something to my site. method used to upload, looks like its some sort've way to get all the valid support dept urls to use?: xx.xx.xx.xx - - [28/Jan/2007:16:45:23 -0500] "GET /submitticket.php HTTP/1.1" 200 2296 "http://www.google.com/search?q=allinurl:submitticket.php&hl=sq&lr=&newwindow=1&start=80&sa=N" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" than they attempt to execute by going directly to that folder (not that this is a huge prob, but might be nice to allow us to make the attachment folder any name we want): xx.xx.xx.xx - - [28/Jan/2007:16:50:36 -0500] "GET /attachments/2.php.gif HTTP/1.1" 404 - "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

thanks for sharing.

yes, but if you remove upload permissions in chmod it'll stop any attachment from being uploaded. so if they can't get it on the server, they can't execute. But what if you want stuff to be uploaded Alternatively a .htaccess file with RemoveType might also work, to disable PHP/etc handling in the directory (just thought of that one now - /goes to add it to upload site ) than by all means do something else, like you've suggested. lol btw, if you test and that works, post the fix for everyone.

yes, but if you remove upload permissions with chmod it'll stop any attachment from being uploaded. so if they can't get it on the server, they can't execute.

we dealt with this on some of our sites a few months back. doesn't seem like it should output the code, but php will read it and execute it. on one of the sites we cleaned up they were using some cookie stealing scripts that they embedded in avatar uploads. but really, they can just upload any of the readily available shell scripts and take total control if they can find a way to get it executed, maybe by calling upon it within their own area of the support panel. i'm not positive exactly how the ins and outs of it being executed in WHMCS, but i've seen it done with other scripts, and its very possible. there needs to be more scanning of the files, maybe for certain preg matches, things like <? or <?php, etc.. can also use AJAX for all this. but essentially any site that allows image uploads that doesn't scan or scour the file is prone to being attacked this way if its all within a php environment. granted they don't have other mod_security rules blocking this, but thats only a backup, its not a solution to wide open exploits. btw not saying WHMCS is vulnerable. i haven't tested this.

55 22 * * * /usr/local/bin/php -q /home/path/to/admin/cron.php > /dev/null

i am having the same issue. but i went through the order process for the client, and there was never any dialog to pay the domain subscription. the return to merchant button was clicked, and there was no more dialog for payments. edit: i think maybe I was doing something wrong or somehow there may have been a small glitch on the first order. matt helped me test and all is working well. thanks matt!