Forum Replies Created
-
AuthorPosts
-
It looks like both of your registered sites are up-to-date. Did you get it working or is this issue you are having on a different site?
Clicking the “Download new definitions!” button is the manual way to update them and it simply POSTS a form with the update values encoded in that page of your wp-admin. How would your host be blocking that? Do you get an error message? Do they have a post size limit maybe?
If you use the “Automatic Update” method that is available as premium feature then the update will be downloaded directly from my server. I’m not sure how your server could block that either without disabling all remote_get methods in your PHP version.
Yeah, I just moved somebody else from TSOHOST to my own Super Secure Hosting and the database injections that they were getting every 5 minutes stopped immediately. When they contacted TSOHOST about this continual threat to their TSO BD the support person responded saying only that the vulnerability has already been patched and there in no more danger on their server but the clients old DB on the TSO server continues to be reinfected even though their site was no longer hosted there.
Is that script being injected directly into your database, because if it is then this might not be a vulnerability that can even be stopped by a plugin. If the server has a root vulnerability then there is really nothing you can do to your site or your account to secure it. Your not hosting on TSOHOST by any chance are you? They still seem to be having repeated database injections across many of their DB servers that have nothing to do the user’s security.
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.
-
AuthorPosts