52 replies to this topic

[chiraag6]

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

[sucuri]

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

Edited by Jan Zonjee, 24 March 2011, 22:28.

[Taipo]

chiraag6, on 24 March 2011, 11:46, said:

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.

[marcusdesign]

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

[riven1128]

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

[marcusdesign]

Hi all,

For now the following files are affected everytime the hack-script has been run:

languages/dutch/index.php
languages/dutch/checkout_success.php
languages/dutch/expected_products.php
languages/dutch/cursus_lijst.php (my own page)
languages/dutch/tell_my_friends_success.php (my own page)
languages/dutch/recently_viewed.php
languages/dutch/help_shipping.php (my own page)
and
languages/dutch/activities.php (my own page)

It just happened again: all these eight files were changed and rewritten with the code in it !

It must be something which has been installed on the website or so, because I'm working on the file permissions the whole afternoon, trying to set everthing right.

Marcus

[Taipo]

riven1128, on 25 March 2011, 14:27, said:

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

I wrote a little speel about the two tiered attack people have been experiencing

http://forums.oscommerce.com/topic/372970-malware-cookie-usagephp-explained/

Might help.

[altoid]

Taipo, on 24 March 2011, 06:52, said:

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.

And with this, while still a novice, I am a bit more educated in this topic. After testing I am apparently on the type 2 set up. Thanks again Taipo for sharing this info.

[Taipo]

Here is a slightly improved version of the test:

<?php

  // change the file name to whatever file you are testing
  $testfile = "testchmod.php";

  error_reporting(0);
  $i=0;
  $content = NULL;
  $writeperms = substr( decoct( fileperms( $testfile ) ),3 );

  if ($writeperms <= 665) {
    if ( !chmod( $testfile, 0666 ) ) {
      $i++;
    } else {
      $msg .= "able to chmod<br>";
    }
  } else {
    $msg .= $testfile . " is already chmod to " . $writeperms . "<br>";
  }
   if (!$fp = fopen($testfile, 'r')) {
    $i++;
  } else {
    $content = stream_get_contents($fp, -1, 0);
    fclose($fp);
    $msg .= "able to read content of " . $testfile . "<br>";
  }
  if ( !$fp = @fopen( $testfile, "w" ) ) {
    $i++;
  } else {
    $msg .= "able to open " . $testfile . "<br>";
  } 
  if ( fwrite( $fp, $content ) === FALSE ) {
    $i++;
  } else {
    $msg .= "able to write to file " . $testfile . "<br>";
  } 
  if ( !fclose( $fp ) ) {
    $i++;
  } else {
    $msg .= "able to close file " . $testfile . "<br>";
  } 
  if( $i > 0 ) { 
    echo $testfile . " is Write-Protected ";
  } else {
    echo $msg;
  } 
?>

[Backcountry_Surfer]

Right ... I have spent the last couple of days searching through my backups to find one I am sure (99%) is clean. Found one that is months old and has several addons/contributions less than my current one so, have started from scratch by implementing these addons plus new security measures in a copy of that clean version and will finish them off with the online part of the instructions once uploaded.

My question is do I completely remove my store by deleting everything via ftp then uploading my backup as, when I innitially suggested this way back in January to my host they said it might not be a good idea to completely remove every file? But didn't explain why! Useless (Netcetera)

But by the looks of whats going on at the moment I don't see any alternative as I don't really know what Im looking for and where, this seems to me to be the quicker and more efficient way rather than sifting through countless pages and folders looking for malicious code?

What do you guys think?

Cheers!

[Backcountry_Surfer]

Also, I am on a windows server IIS so as far as I am aware .htaccess has no effect at keeping the little @!%£#/&(Tykes) out? What else is as effective or do I need to change hosts? I have installed the following

Security Pro 2.0 (r7)
SiteMonitor V 2.9
IP Trap V 5.1

Changed admin folder name, passwords etc etc ... disabled product reviews and renamed the associated php files. Anything else?

Danny

[altoid]

Backcountry_Surfer, on 26 March 2011, 13:18, said:

My question is do I completely remove my store by deleting everything via ftp then uploading my backup as, when I innitially suggested this way back in January to my host they said it might not be a good idea to completely remove every file? But didn't explain why! Useless (Netcetera)

Danny, just addressing the part of your post about deleting everything and restoring with a clean backup....I don't know why that wouldn't work. I have been with a couple hosts over the past couple years and due to non-security related screw ups that I did, I had to completely reinstall from a back up. No problem for me what-so-ever as long as the database is consistent with the back up file. Maybe there's something host specific that would effect such action but I don't see what that would be.

[Backcountry_Surfer]

altoid, thanks for the reply didn't think so and have started that procedure. Fingers crossed!
Cheers

[altoid]

Backcountry_Surfer, on 26 March 2011, 15:05, said:

altoid, thanks for the reply didn't think so and have started that procedure. Fingers crossed!
Cheers

If after reinstall you get a "can write to your configure.php" message on your webpage...you need to go back in and change the permissions to both configure.php file. On my server they need to be 444, yours may differ.

[chiraag6]

hey guys,

i don't know if it helps but..

i found this in the includes/modules/payment/paypal

</style><script charset="utf-8" id="injection_graph_func" src="wpp_files/injection_graph_func.js"></script><script type="text/javascript">


may be something to scan for?

[marcusdesign]

Hi all,

I've chmod'ed every file in includes/languages/dutch to 644 and I've not been hacked again !

for me this does the trick !

marcus

[Taipo]

Backcountry_Surfer, on 26 March 2011, 13:18, said:

My question is do I completely remove my store by deleting everything via ftp then uploading my backup as, when I innitially suggested this way back in January to my host they said it might not be a good idea to completely remove every file? But didn't explain why! Useless (Netcetera)

Make a backup of your current store either on the site itself or download it to a backup directory, also take a backup of your database as well. Then delete the files and proceed with uploading the older version. That way if it all 'turns to custard' you can at least restore your site back to where it is now.

Backcountry_Surfer, on 26 March 2011, 13:18, said:

Also, I am on a windows server IIS so as far as I am aware .htaccess has no effect at keeping the little @!%£#/&(Tykes) out? What else is as effective or do I need to change hosts? I have installed the following

Security Pro 2.0 (r7)
SiteMonitor V 2.9
IP Trap V 5.1

Changed admin folder name, passwords etc etc ... disabled product reviews and renamed the associated php files. Anything else?

If there are files in the main directory that have the types of file upload and file injection code in them similar to the one mentioned above in my earlier post then as stated, the only thing you can do to combat that is remove the offending code. That goes for any operating system as well.

As for addons, you might want to give the contribution in my signature a go as well.

[Taipo]

marcusdesign, on 26 March 2011, 19:17, said:

Hi all,

I've chmod'ed every file in includes/languages/dutch to 644 and I've not been hacked again !

for me this does the trick !

marcus

Marcus, this is a good example of my earlier discussion of a site hosted on a server that employs the first method, where file and directory security fall to their permissions. On this configuration, it was quite possible for an attacker to exploit the admin bypass as with any site that was not patched, but also to use that to either attack other websites on your server, or, other websites on that server with the same security vulnerabilities could be used to infect yours. So patching your site and making all files read only and directories to be entry and view only (for the method 1 configuration that would be 644 for files, and 755 for directories) would solve your problems.

The problem is that many oscommerce users do not have their sites on servers with the same configuration as yours. On theirs 644 is still writable. While 444 is read only on their configurations (method 2), the fact that PHP has owner privaleges under method 2 configuration, means its possible for an attacker via hacked files such as the cookie_usage.php to change the permissions back from 444 to 644 or higher, then write to the files, and even change the permissions back to 444.

One a server with the first method employed (the one your host uses), files should be read only by default, because 644 is the default upload file permission. Same goes for directories because the default created or uploaded directory permission is 755 which is not writable in method 1 configuration.

Where we run into problems is where the server is configured as in method 2, and the default directory and file permissions are still the same, therefore every file is writable by default, and every directory is too.

So once upon a time it was good advice to give, to change file permissions to 644, and directories to 755, but now with this new method being employed (and variations of it), file and directory permissions in a method 2 configuration do not enhance the sercurity of the site by setting them to read only (although it doesnt hurt to). The best settings in method 2 configuration is to make sure they are NOT world writable, for files, world writable would be 666 and for directories 777 but this will not save your site from exploitation (nothing will), if there are files still resident on there that have dangerous exploit code in them.

Edited by Taipo, 26 March 2011, 21:37.

[satish]

I agree to Taipo comment.

The suggestion of 444 will atleast make you know that something internally still resides if your file or folder permissions get changed.

A cleaned up pages(site) and then an upload followed by 444 for files if still results in some hacking and permission changes means you need to call a security expert to look in further.







Satish

[Backcountry_Surfer]

So far so good ... I have gone right back to an Oct 10 backup of my site and as yet no problems. I had to re upload a couple of hundred photos and re install some addons but, as I thought it was quicker to do.

Don't know if I have enough security so, I am making backups after every little change I make. I've locked my image folders renamed other folders these pesky little hackers are attracted too but, still looking for an alternative to htaccess? My hosts say I need my permissions set to 777 and I even asked them whether a htaccess file was worth having with a vague answer that I translated as being NO! I am on a windows server IIS and there are soooo many conflicting arguments about whether its even worth putting a htaccess file in any of my folders because of my setup that I don't know what to do?

Sitemonitor seems to be working fine with the exception of a warning to do with having NO htaccess file in my images folder ...

Hope everyones getting on top of this now? Good luck and any ideas/suggestions about the above mentioned, please throw em my way.

Danny