Forum Replies Created
-
AuthorPosts
-
The site appears to be clean now. Maybe you just needed to refresh the scan on that sucuri results page, because they will cache the original results and not show that your site is actually clean even after you have cleaned it.
Well no (you need WordPress for any plugin to run), but you could manually remove the files through FTP that siteground wants you to remove and then get them to restore access to your site so that you can clean the rest of the infection using my WordPress. Or you could ask them to restore your access specifically so that you can use my plugin to clean up the whole infection.
Otherwise, you might want to move your site to a more secure and cooperative hosting provider that will work with you to get the site cleaned up.
I have updated the definition with a fix for this new variant. Now the whole threat will be removed without leaving any syntax errors behind. Please download the latest definition updates and then run the complete scan again to remove the last of this threat from your site.
There is an emergency restore link on the “fixing” screen that gives you the option to revert the changes if it comes back with broken test results. Since you have probably missed that option I went ahead and restored that last file that was only partially fixed.
Just to let you know exactly what went wrong here, the file …/wp-content/plugins/fooboxV2/includes/foolic_class.php was only partially fixed, leaving behind some remnant scrap of the infection in that file and that is what was causing the error. I am working on the definition for that particular threat so that it will be completely removed in future scans.
I see that he secured URL for your site is not registered, as you said only the unsecured URL is currently registered.
If you go back to the Anti-Malware Setting page in your wp-admin using HTTPS then you should see the registration form pre-filled with a new key for your secured URL. If it says that your key is not registered but it does not show you the form then you need to clear your cache and check your browser’s error console for blocked script or other JavaScript error that might be interrupting the form presentation.
Ah, yes, I have seen this before. The problem is that they are using the include function to render the contents of a CSS file. This improper techniques will actually result in the execution of any PHP code found in the CSS file. Hackers commonly exploit this oversight to execute malicious code. If there is no PHP code in that CSS file then you can ignore this threat or whitelist the file if you feel that this plugin is safe for now, but they really need to change that code and use “echo file_get_content” instead of include.
A stylesheets should never be loaded with the PHP “include” statement. WordPress even has a built-in method called wp_enqueue_style, which is used to safely render CSS content dynamically.
The recovery link is generated on the during the fix process and has in it a nonce key that will display the quarantined file for you to recover if WordPressu have any sesitive breaks, but your site looks to be more broken than just a PHP error in WordPress. Do you remember what files were fixed (it might be something wrong with your .htaccess file)?
The absolute solution here and the best way to proceed at this point is for you to find out exactly what the error is. This will be found in the error_log files on your server. Ask your host how you can view the error logs (this differs from server to server, defending on how it has been configured).
If you have any ses=nsitive datato share with me or if you would like my direct help with resolving this issue then please email me directly (this public forum is not the best place to post site specific details).
You’ll need to ask you hosting provider how you can modify your php.ini file. I depends on how the have PHP setup o n the server.
This is probably due to a memory_limit on your servere that is too small to scan these files successfully. Try increasing the memory_limit value in your php.ini file.
I am not aware of any conflicts between my plugin and any other plugin. If you find anything that does not seem to work right then please let me know and I can help you troubleshoot.
Thanks for posting this helpful code. As a shortcut you could just apply the patch, which would insert the whole Files tag, then you would just need to add the Allow lines for any domains and IPs you want to allow.
Right, so that False Positive was already corrected on the 5th of this month (after you ran that scan last month). It is now fixed so that if you restore that file from the quarantine and then run the scan again it will not flag it as a Known Threat.
Thanks for the entire file. I can see that this use of the eval function is not malicious but I also still don’t see this file detected as a known threat in my current definitions. Can you please click on the file name on the scan results page and then hover over the numbered link above the file contents so that you can see the name on the threat?
Then can you please send me this info or a screenshot of it, and also your definition version and your php version (found on the right-hand side)?
Two things: First, that line looks to be rem’d out and not used anyway, so it should probably just be removed; And second, this code by itself is not even detected as a Known Threat, so there must have been more code around this line that was a contribution factor in the identification of this threat.
Can you please send me this file in it’s entirety so that I can examine what caused it to be detected and update the definition if needed?
Please try deactivating my plugin for a few minutes while you test the theme compatibility. Once my plugin is ruled out as the source of the conflict then you can re-activate it and try others. Your site shouldn’t be too vulnerable if it is only turned off for a few minutes, it takes a long time for the Brute-Force attacks to have an affect on a server.
-
AuthorPosts