Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Monebookers giving away information?


Crazypilot

Recommended Posts

Hi all,

 

Now to something I discovered when installing Moneybookers Credit-card payment.

It seems the payment gateway (skril/moneybookers) is sending back a log.txt file to the Cataloge folder.

 

This information contains detailed transaction information such as customer/shop email addresses, Shop Moneybookers customer No and secret word etc.

 

To me it looks totally crazy that this information is stored at the 755 (open) Catalog directory.

 

As this question is Security related, I posted it here.

 

Anyone with same experience or advice on how to secure the log.txt file?

 

Best regards

 

CrazyP

Link to comment
Share on other sites

Perhaps you could try something like...

 

In .htaccess add the following:

 

 
<FilesMatch "^(log\.txt)">
Deny from all
</FilesMatch>

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

Hi Taipo,

 

As far as I understand, the log.txt file is in fact generated by the Moneybookers-Oscommerce module.

What I do not like is getting sensitive information as a readable file in the "catalogue" folder.

 

Do you mean that by inserting ;

 

 

<FilesMatch "^(log\.txt)">

Deny from all

</FilesMatch>

 

Then the log.txt file will be protected?

 

I was thinking of altering the script generating the log.txt so it would be stored in the protected "admin" folder instead..

 

Copy of the generating script below.

 

I am however not good enough to re-write the code myself.

 

What would be best solution according to you? (re-write or code in .htacces)

 

Brgds CrazyP

 

mb_handler.php:

 

 

<?php

 

require('includes/application_top.php');

 

if ($_SERVER['HTTP_USER_AGENT'] != 'Moneybookers Merchant Payment Agent') {

die();

}

 

$a = $_POST;

 

$fp = fopen(dirname(__FILE__) . DIRECTORY_SEPARATOR . 'log.txt', 'a+');

 

flock($fp, LOCK_EX);

 

fwrite($fp, "START(" . strftime("%Y-%m-%d %H:%M") . ")\nPOST");

foreach ($a as $k => $v) {

fwrite($fp, "'$k' => '$v'\n");

}

fwrite($fp, "POSTEND\n");

 

 

$sql = "SELECT id_order, plugin FROM moneybookers WHERE id_moneybookers=" . $a['transaction_id'] . " LIMIT 1";

 

$m = tep_db_query($sql);

$e = tep_db_fetch_array($m);

 

include(DIR_WS_MODULES . 'payment' . DIRECTORY_SEPARATOR . $e['plugin'] . '.php');

 

$payMethod = new $e['plugin']();

 

$sql = "SELECT configuration_value FROM " . TABLE_CONFIGURATION . " WHERE configuration_key = '" . tep_db_prepare_input($payMethod->_mainPrefix . 'SECRET_WORD') . "' LIMIT 1;";

$m = tep_db_query($sql);

$r = tep_db_fetch_array($m);

 

$sc = $r['configuration_value'];

 

fwrite($fp, "SecretWord = $sc\n SQL = $sql\n");

 

$checksum = strtoupper(md5($a['merchant_id'] . $a['transaction_id'] . strtoupper(md5($sc)) . $a['mb_amount'] . $a['mb_currency'] . $a['status']));

 

fwrite($fp, "CheckSum = $checksum\n");

 

if ($checksum != $a['md5sig']) {

fwrite($fp, "BÅ?Ä„D\nSTOP\n\n");

flock($fp, LOCK_UN);

fclose($fp);

die();

}

 

$key = $payMethod->_prefix . 'PROCESSING_ORDER_STATUS_ID';

 

if ($e['id_order'] != 0) {

$sql = "UPDATE orders SET orders_status=(SELECT configuration_value FROM " . TABLE_CONFIGURATION . " WHERE configuration_key = '$key' LIMIT 1) WHERE orders_id=" . $e['id_order'] .";";

} else {

$sql = "UPDATE moneybookers SET status='" . $a['status'] . "' WHERE id_moneybookers='" . $a['transaction_id'] . "';";

}

 

fwrite($fp, "SQL = $sql\n");

 

fwrite($fp, "STOP\n\n");

 

flock($fp, LOCK_UN);

fclose($fp);

 

tep_db_query($sql);

 

 

?>

Link to comment
Share on other sites

You could try moving the log.txt into your protected admin then replace

 

$fp = fopen(dirname(__FILE__) . DIRECTORY_SEPARATOR . 'log.txt', 'a+');

 

with:

$fp = fopen( DIR_FS_CATALOG . 'admin/log.txt', 'a+');

 

Where admin is the name of your admin directory. Change admin in that line if that is not the name of your admin directory. Depending on 'how' your admin directory is protected, then that may work, or not.

 

Adding that first code though to the htaccess file in catalog would ban anyone viewing the log file.

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

But before going through all that just check if there is a simple on/off switch for the log in the payment module admin. (Many modules have an on/off log/debug setting which is supposed to be used only under testing)

Link to comment
Share on other sites

Great!

 

I changed the script so now the log.txt is created in the protected and renamed admin folder and it works! smile.png

 

Thank you Taipo!

 

You are very helpful in all security related matters in this Forum.

 

Are you doing this free and as a hobby, or do you also do some paid work?

 

Brgds CrazyP

Link to comment
Share on other sites

A note that the "Deny from all" command will (at best) only protect the file from being read via a Web browser. Another user sharing your server should be able to read that file without going through the server and .htaccess controls. Therefore it would be best (if you can't shut off creation of the file in the first place) to either change permissions to 600 (assuming Moneybookers can still do whatever it needs to do with that file) or move the file to some inaccessible (to others) password-protected folder.

Link to comment
Share on other sites

On many of the shared webservices available now, PHP has owner level privaleges. On those server configurations, a file permission of 600 will not prevent an attacker from reading a file just as much as a file perm of 444 will not prevent an attacker - if an attacker can execute code then they can simply change file perms to something more friendly, read/write what they need then if they want to be nice, change the file perms back to 444.

 

On these same server configurations, the virtualhost setup is hedged in so there is no remote reading (world readable/writable) across virtual hosts as used to be the case in the older configurations (PHP as DSO). In most of these newer configurations every file permission setting is at least readable by PHP, and any setting other than 444 is writable by PHP.

 

On these configurations, if an attacker had access, there would be no directories that you could hide files in that could not be read. Password protected directories (apache basic authentication) are still protected by apache directives protecting directories from browser access the same way Deny All works.

 

To read more about these configurations, check out:

- http://forums.oscomm...le-permissions/

 

I guess my point is the days of the default setttings of 777 being writable and viewable for directories, 666 being writable for files, shared hosts where one virtualhost user can bleed info from another, and 0644 and lower for file permissions being read-only, those are almost over.

 

An example of this is the amount of users that have to chanmod the configure.php files to 444 before PHP reports the files as read only gives you some indication just how much those older configurations are fast becoming non-applicable now. This method pretty much removes that cross server exploiting that plagued shared hosts, but it also opens up file and directory permissions to any attacker that can get their files included into your site. You win some, you lose some.

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...