bear Posted January 29, 2007 Share Posted January 29, 2007 How is it you disabled the upload feature, removed all extensions from the allowed list? 0 Quote Link to comment Share on other sites More sharing options...
jdwalte3 Posted January 29, 2007 Share Posted January 29, 2007 Yes, I removed the all allowed extensions and change the permissions of the directory. However, I just did a test and it looks like if someone go to submit a ticket and tries to attach a file it sends it to the tmp directory...not sure how that affects the security. I have a ticket open with Matt right now and will report back. 0 Quote Link to comment Share on other sites More sharing options...
bear Posted January 29, 2007 Share Posted January 29, 2007 If all extensions are disallowed, why would it try to use /tmp? 0 Quote Link to comment Share on other sites More sharing options...
bodhisattva Posted January 29, 2007 Share Posted January 29, 2007 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. 0 Quote Link to comment Share on other sites More sharing options...
MACscr Posted January 29, 2007 Share Posted January 29, 2007 RemoveType .phtml .php ,php4 .php3 .phps .php5 .cgi .pl Save that in a file called '.htaccess' and upload it to the downloads directory, and it'll stop PHP execution. Example / proof: http://www.twobeds.com/nice/ - has the above .htaccess file in. Both scripts should give you a plain text '<?php echo 'Hello World!'; ?>'. http://www.twobeds.com/evil/ - no .htaccess file. Both scripts should give you a 'Hello world!' lol, am i missing something? it looks like it works at both links. =P 0 Quote Link to comment Share on other sites More sharing options...
Dominic Posted January 29, 2007 Share Posted January 29, 2007 RemoveType .phtml .php ,php4 .php3 .phps .php5 .cgi .pl Save that in a file called '.htaccess' and upload it to the downloads directory, and it'll stop PHP execution. Example / proof: http://www.twobeds.com/nice/ - has the above .htaccess file in. Both scripts should give you a plain text '<?php echo 'Hello World!'; ?>'. http://www.twobeds.com/evil/ - no .htaccess file. Both scripts should give you a 'Hello world!' lol, am i missing something? it looks like it works at both links. =P lynx --dump [url]http://www.twobeds.com/nice/info.php.gi3[/url] <? echo 'Hello World!'; ?> 0 Quote Link to comment Share on other sites More sharing options...
bear Posted January 29, 2007 Share Posted January 29, 2007 lol, am i missing something? it looks like it works at both links. =PYup, you did. One is executing the PHP and the other is showing you the code instead...however gi3 is not the same as giF so this doesn't prove the exploit 0 Quote Link to comment Share on other sites More sharing options...
Harrison Posted January 29, 2007 Share Posted January 29, 2007 Anyone know what this "file" does when someone visits it, or how it affects your server? I have the IP from the person who made the ticket. He's from Eygpt. 0 Quote Link to comment Share on other sites More sharing options...
WHMCS CEO Matt Posted January 29, 2007 WHMCS CEO Share Posted January 29, 2007 It seems to be that there is an initial file that is uploaded called "2.php.gif". ".gif" in the allowed file types list is currently allowed by upload for WHMCS so the attachment gets uploaded. The user then accesses the file and for some reason it is allowed to run as a PHP file. It then appears to download a secondary file called "user_function.php". This secondary file contains a nasty PHP shell script which you really don't want on your server. V3 will be released within the next 24 hours to try and plug this security hole as soon as possible. 0 Quote Link to comment Share on other sites More sharing options...
bear Posted January 29, 2007 Share Posted January 29, 2007 What about those still running v2? With v3 not yet fully released, I'm sure there are lots still using that, myself included. Will it break anything if I'm not using the desk and I just remove the submitticket file? 0 Quote Link to comment Share on other sites More sharing options...
WHMCS CEO Matt Posted January 29, 2007 WHMCS CEO Share Posted January 29, 2007 Yep, like I said, V3 will be released within the next 24 hours. That means released as stable so everyone can upgrade and begin using it. There will also be an update for those who don't want to upgrade to V3 yet but want to patch the file upload issue. Removing the file is another option and will not break anything. 0 Quote Link to comment Share on other sites More sharing options...
bodhisattva Posted January 29, 2007 Share Posted January 29, 2007 is the patch already available? 0 Quote Link to comment Share on other sites More sharing options...
MACscr Posted January 29, 2007 Share Posted January 29, 2007 Yep, like I said, V3 will be released within the next 24 hours. That means released as stable so everyone can upgrade and being using it. There will also be an update for those who don't want to upgrade to V3 yet but want to patch the file upload issue. Removing the file is another option and will not break anything. Great to hear Matt, glad your on the ball. I had the user attempt the this just today as well, but luckily my system was already setup to not allow php files to run, plus the folder is owned by a different user. I also used a robot.txt and setup a meta tag for no follow for whmcs. I have no need for whmcs to be indexed by engines. You might want to add this to the header of the admin area as well. <meta name="robots" content="noindex,nofollow" /> 0 Quote Link to comment Share on other sites More sharing options...
bear Posted January 29, 2007 Share Posted January 29, 2007 luckily my system was already setup to not allow php files to runSame here, nothing I tried would allow it to run. Tried on several servers, too. Go us, eh? Thanks for fixing this so quick, Matt. Well done. 0 Quote Link to comment Share on other sites More sharing options...
Dominic Posted January 30, 2007 Share Posted January 30, 2007 lol, am i missing something? it looks like it works at both links. =PYup, you did. One is executing the PHP and the other is showing you the code instead...however gi3 is not the same as giF so this doesn't prove the exploit Ah but it shows the trouble with double-extensions and mod_mime's dangerous behaviour (gi3 is a nonsense extension, so the file is executed as .php would be) 0 Quote Link to comment Share on other sites More sharing options...
bear Posted January 30, 2007 Share Posted January 30, 2007 Yes, but I thought this was a problem that a file uploaded as PHP would have the .GIF extension appended (why it didn't just disallow it altogether is interesting...why then have the "allowed files" if it just renames and allows it through?) and not a nonsense extension. When it has .GIF, it shows a broken link, when it shows a bad extension it was my understanding that the server would deliver raw code and not attempt to parse it. This was the whole issue behind not using the extension "inc" for include files as the server would happily deliver the raw text. No longer the case? Obviously I'm not that good with PHP, so perhaps I'm missing something. 0 Quote Link to comment Share on other sites More sharing options...
Dominic Posted January 30, 2007 Share Posted January 30, 2007 Yes, but I thought this was a problem that a file uploaded as PHP would have the .GIF extension appended (why it didn't just disallow it altogether is interesting...why then have the "allowed files" if it just renames and allows it through?) and not a nonsense extension. When it has .GIF, it shows a broken link, when it shows a bad extension it was my understanding that the server would deliver raw code and not attempt to parse it. This was the whole issue behind not using the extension "inc" for include files as the server would happily deliver the raw text.No longer the case? Obviously I'm not that good with PHP, so perhaps I'm missing something. The issue is where the uploaded file has *two* file extensions - so '.inc' is fine, it'll be served as plain text - but '.php.random' will be served as PHP since Apache will try and match any extension. If the file uploaded was '.php.gif' I must be missing something (it's been a while ) since that is served as a plain text (un-parsed) image/gif to me 0 Quote Link to comment Share on other sites More sharing options...
WHMCS CEO Matt Posted January 30, 2007 WHMCS CEO Share Posted January 30, 2007 The issue is a file named ".php.gif" which WHMCS matches ".gif" as the extension so allows the upload to happen is being run by web servers as a PHP file. I'm not sure why, maybe a bug in PHP, but unfortunately it's happening and is what has caused the issue. The measures which are now in place to prevent any security vulnerabilties are as follows: 1. Block any file containing ".php", ".cgi", ".pl" anywhere in the filename 2. Append a random 6 digit number to the beginning of all uploaded filenames so simply going to attachments/filename will not work 3. Configurable attachments folder location 0 Quote Link to comment Share on other sites More sharing options...
bear Posted January 30, 2007 Share Posted January 30, 2007 Interesting. Couldn't get this to run on my boxes at all...maybe PHP version? Anyway, fix is in the works. 0 Quote Link to comment Share on other sites More sharing options...
Dominic Posted January 30, 2007 Share Posted January 30, 2007 Excellent .phtml is commonly configured to parse PHP too - I think that's it 0 Quote Link to comment Share on other sites More sharing options...
bodhisattva Posted January 30, 2007 Share Posted January 30, 2007 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. 0 Quote Link to comment Share on other sites More sharing options...
Dominic Posted January 30, 2007 Share Posted January 30, 2007 It's mod_mime choosing how to handle files, and choosing to pass it to PHP. Not a PHP bug - nothing to do with PHP 'php_admin_flag engine 0' in a .htaccess will also disable PHP in a directory 0 Quote Link to comment Share on other sites More sharing options...
WHMCS CEO Matt Posted January 30, 2007 WHMCS CEO Share Posted January 30, 2007 The V2.5.8 patch and V3.0.0 release are now available for download from the client area. The official release announcement about V3.0 will be made tomorrow. Matt 0 Quote Link to comment Share on other sites More sharing options...
bodhisattva Posted January 30, 2007 Share Posted January 30, 2007 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! 0 Quote Link to comment Share on other sites More sharing options...
WHMCS CEO Matt Posted January 30, 2007 WHMCS CEO Share Posted January 30, 2007 If the file can't be run on the server, there shouldn't be an issue. With this patch, it is impossible for the uploader to know where to find the file, as it is assigned a random filename and you can also move the attachments folder so is that really an issue? 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.