yorman
Forum Replies Created
-
If you don’t mind sharing a copy of the code that powers the premium plugin, maybe I can find a solution, but as you say, this is such an isolated and rare case that implementing a solution may not be necessary. You can send the code to
[removed](removed to avoid spam) which is my personal email.Alternatively, I could offer a different (unrelated) solution, force the Sucuri plugin to create a Zip archive of the plugin that is being reset because the action is executed. This way, if something wrong happens, like in this case with the name collision, you can simply revert the changes back to the original state with the backup from the archive.
The plugin is already parsing those headers, you can see the code here [1].
When the URI matches the domain name of the WordPress repository, the Sucuri plugin assumes that you are using a free add-on, otherwise assumes that you are using a premium code base and disables the reset option for that specific plugin. Since you were able to reset that premium plugin in your installation, I will assume that the URI in its headers was matching the condition highlighted in the code [1].
I think it would be easier to contact the author of that premium plugin and ask him to change the name, if they know that it causes conflicts with the WordPress repository, no matter if the free plugin is already deprecated.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/13de2f4/src/api.lib.php#L909-L919
Forum: Plugins
In reply to: [Sucuri Security - Auditing, Malware Scanner and Security Hardening] API KeyPlease send the email address that you want to associate to the API key to
[removed](email removed to avoid spam) I will use a generic domain name to generate it. The email address that you send me will be used to recover the key in case that you ever lose it.I test the plugin against multiple versions of PHP including 5.3, 5.6, 7.0 and 7.1 and usually with the alpha version of WordPress from their development repository available here [1] so technically speaking I am testing the plugin against a version of WordPress and PHP newer than most of the users.
To answer your question, no, there is not a “public” procedure to check the compatibility between the Sucuri plugin and the latest version of WordPress and/or PHP, but know that I run our automated test suite almost everyday.
Feel free to install the update as soon as you want, if you encounter an error or notice any incompatibility between the plugin and WordPress/PHP then you can report it here and I will fix it as soon as I can, I usually respond fast.
Oh this is going to be difficult to fix.
The plugin has no way to know if a premium plugin is using the same name as a plugin in the free WordPress repository, I think it is the responsibility of the author of the premium plugin to avoid name collisions. On the other hand, WordPress should be in contact with the author of the free plugin to make sure that it is still compatible with the latest version of the CMS, as you mentioned, the free plugin hasn’t been updated in +2 years which makes things even worse.
I will think about this for a couple of days, maybe I can find a way to prevent name collisions from the Sucuri plugin, but be aware that there may not be a good solution for this.
Thank you for the report.
I was investigating this today in one of our customer’s websites and found that the problem is not really in the Sucuri plugin’s code but something else that people are installing, it could be a 3rd-party plugin or a theme, it’s difficult to say what is the exact origin of the problem.
The solution, at least in the case that I was investigating, was to delete the language files associated to the plugin located in this directory [1]; it seems that a plugin/theme is triggering some WordPress action that is forcing the website to copy the language files from here [2] into the other directory, the Gettext keys are staying intact but the values are being replaced with the same key, hence why you can only see the unique IDs in the interface and mail alerts.
Please use FTP or the file manager available in your hosting account, then navigate to this directory [1] and delete anything that starts with “sucuri-scanner” then try to load the Sucuri plugin’s interface once again. I hope this resolves the issue for you.
Leaving ticket as not-resolved for now, while I keep investigating.
[1] /wp-content/languages/plugins/
[2] /wp-content/plugins/sucuri-scanner/languages/I was investigating this today in one of our customer’s websites and found that the problem is not really in the Sucuri plugin’s code but something else that people are installing, it could be a 3rd-party plugin or a theme, it’s difficult to say what is the exact origin of the problem.
The solution, at least in the case that I was investigating, was to delete the language files associated to the plugin located in this directory [1]; it seems that a plugin/theme is triggering some WordPress action that is forcing the website to copy the language files from here [2] into the other directory, the Gettext keys are staying intact but the values are being replaced with the same key, hence why you can only see the unique IDs in the interface and mail alerts.
Please use FTP or the file manager available in your hosting account, then navigate to this directory [1] and delete anything that starts with “sucuri-scanner” then try to load the Sucuri plugin’s interface once again. I hope this resolves the issue for you.
Leaving ticket as not-resolved for now, while I keep investigating.
[1] /wp-content/languages/plugins/
[2] /wp-content/plugins/sucuri-scanner/languages/@mattronica — would you like to install the development version of the code from here [1] I have submitted some changes associated to the failed-login code, maybe one of them will help you resolve the issue.
These fixes will be included with the release of version 1.8.9 but it will take a couple of weeks before I make the announcement as there are other changes that have more priority. Please use the development version of the code for now.
Go to the plugin’ settings page, in the “Alerts” panel there is a section called “Security Alerts”, search for an option called “Receive email alerts for failed login attempts including the submitted password” and uncheck it. When this option is checked the plugin executes this piece of code [1] which appends the submitted password to the logs, if the option is unchecked the plugin only uses the username.
In this commit [2] submitted +24 days ago, I modified the default settings to keep the option “:notify_failed_password” disabled by default. These changes were both included with the release of version 1.8.8; let me know if this code is working differently in your environment so I can investigate.
Marking as resolved, feel free to re-open if you need more information.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/13de2f4/src/hook.lib.php#L156-L162
[2] https://github.com/Sucuri/sucuri-wordpress-plugin/commit/9c86744This sounds more like a bug in the CDN router than the plugin, consecutive forward slashes should be trimmed by the server automatically. But anyway, I went ahead and removed the additional character from the code with this commit [1]; they were actually placed by WordPress itself for compatibility reasons.
Feel free to install the development version of the code from here [2] or wait until the public release of version 1.8.9 which will happen in a couple of weeks.
Thank you for the report.
[1] https://github.com/cixtor/sucuri-wordpress-plugin/commit/bd1b249
[3] https://github.com/cixtor/sucuri-wordpress-pluginOnce the plugin is active you should see a new icon on the WordPress sidebar like this one [1] which includes the links to the dashboard, firewall, last-login and setting pages.
You could try unchecking the option that says “Use WordPress functions to send mails” under the “Security Alerts” panel in the Alerts section of the plugin’ settings page. This will force the plugin to use the built-in PHP function
mail[1] instead of the WordPress functionwp_mail[2] which is what the plugin uses by default.The rest is WordPress’ business, the plugin doesn’t do anything fancy when it tries to send a notification, it simply calls one of these two functions and leaves the rest of the job to either WordPress or PHP, so if after unchecking that option the problem persists I would contact your hosting provider to see if the messages are getting stuck in a queue.
Marking as resolved, feel free to re-open if you need more information.
[1] http://php.net/manual/en/function.mail.php
[2] https://developer.wordpress.org/reference/functions/wp_mail/Hello, “XMLRPC, Comments and Trackbacks blocked” is the name of an option inside the Sucuri Firewall, which means that you purchased one of our services. Please use this page [1] to open a ticket in our internal system so one of my colleagues in the Firewall support team can assist you with this problem.
Running a quick scan for the text “HTTP error” in a regular WordPress installation (at least with versino 4.8.1) we can find this code [2] which seems to be the placeholder for a key in a language file. Scanning for this key “http_error” returns multiple matches in the “wp-includes/js/plupload/” which is not considered at all by the Sucuri WordPress plugin, this leads me to believe that the error comes from a blocked request from the Firewall and not the plugin, please fill a ticket here [3].
[1] http://support.sucuri.net/
[2] https://github.com/WordPress/WordPress/blob/c26b735/wp-includes/script-loader.php#L298
[3] https://support.sucuri.net/support/?newcloudproxyMarking as unresolved again while I investigate this issue one more time.
There are two things to consider here, in @shklenny case the information is being stored their own web server, in this file [1] so deleting this file will immediately “hide” the sensitive information from that page. In @linnalexandra case the problem is more difficult to resolve because taking a look at the code that sends the password to the API [2] you can see that it only does it when the option “:notify_failed_password” is enabled, and this option is disabled by default as you can see here [3].
I understand that you are seeing the option uncheck in your website, I can believe that, however this only makes the investigation harder as it contradicts what the code is doing. I will keep this ticket open for a couple of days while I try to reproduce the issue in my own website and find a solution.
For now, you can modify the content of this file [4] and delete lines 158 and 159 which are the ones sending a copy of the password to both the API and the local cache. I will work on this in the next couple of weeks. Thank you for your patience.
[1] /wp-content/uploads/sucuri/sucuri-failedlogins.php
[2] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/13de2f4/src/hook.lib.php#L150-L162
[3] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/13de2f4/src/option.lib.php#L74
[4] /wp-content/plugins/sucuri-scanner/src/hook.lib.phpTo answer your question “How is this possible?” I have to explain how the plugin detects these changes. The plugin uses the checksum [1] of the files provided by the official WordPress releases and compares them with the checksum of the files in your website, if they are different the plugin flags the files are “modified”.
However, instead of downloading a fresh copy of WordPress every time you execute the integrity check, it uses a public API available here [2] that allows people to retrieve the checksum of all the files for a specific version. It seems that the API is returning outdated data because the checksum of the “license.txt” and “controls.svg” files appear to differ from the checksum detected in your installation. The plugin has no control over this information, it barely uses the data that WordPress provides.
If you want to remove the warning, go to the plugin’ settings page, click on “Scanner” then scroll down until “WordPress Integrity Diff Utility”, enable this tool then go to the dashboard again and click the filenames, the plugin will show a popup with the differences present in that file. If you consider these differences to be harmless you can select the file and mark it as fixed using the form below the table. Otherwise, select the files and execute the “Restore” action from the same form.
[1] https://api.wordpress.org/core/checksums/1.0/?version=4.8
[2] https://en.wikipedia.org/wiki/Checksum
