yorman
Forum Replies Created
-
1. Do I need a unique email each time I generate an API key for a new website? We have 20 websites. Does that mean we need 20 different emails OR can we use the same company email for each website’s API key?
You can generate the API keys with the same email address. As long as the combination “email + domain” are unique in the system, the request will be accepted.
2. We are using Google Cloud Platform (Hosting) with Kinsta.com. I noticed that the WordPress Integrity will not fully load in Sucuri (it says Loading…). Is there a server setting that could be preventing this from fully loading?
There is no server setting that needs to be switched on to activate the WordPress Integrity tool. I believe there is an incompatibility between the code that powers this utility and the way Kinsta configured their servers. The “Loading…” text stays there infinitely because there was a server error that prevented the Ajax request to load the result of the scan.
I have a contact at Kinsta, I will check with them to see if they can troubleshoot the issue for me, because I have no account with them so I cannot do it myself. Once they reply back, I will send a patch to our development repository to include the fix with the next update of the plugin.
[…] the free version […] is meant to demonstrate Sucuri’s capabilities.
As far as I know, this is not true.
Since I took the development of the Sucuri plugin +3 years ago, the code has been written pretty much independently to the other products that Sucuri provides as a subscription (Firewall, Backups, Monitoring, Support). Originally, the plugin was simply a client that allowed the execution of SiteCheck [1] from the commodity of the WordPress admin dashboard. Later, when the Sucuri Firewall was built, I integrated the plugin with the Firewall API to allow the users to change the settings of their Firewall account and monitor their security logs, also from the commodity of their WordPress admin dashboard.
Never during the last +3 years I have been asked to demonstrate the capabilities of our systems nor services through the Sucuri WordPress plugin. This is why I wanted to clarify the purpose of the plugin in my previous comment. The “Server Side Scanner” is a component that is part of the Sucuri Platform, and more specifically, part of the Monitoring system.
The plugin is not connected to the Sucuri Monitoring system, it cannot detect an internal infection, only the effects if — and only if — the infection shows itself in the form of malicious code in the HTML, CSS, JavaScript or HTTP headers. The back-door that is being injected in your website is not part of these categories, that’s why the plugin missed it.
Is the premium version any more likely to find the malicious code if the free version can’t?
Indeed, you can read more about what features are provided by our premium services (Monitoring, Firewall, Backups, Support) visiting this link [2]. Also, feel free to chat with one of my co-workers via the chat available at the bottom-right corner of the Sucuri website.
The site is on a shared server, so I can’t use grep as far as I know.
This is only true in servers owned by very restrictive hosting providers. In the majority of cases, you can execute any Unix command via SSH or even through a script uploaded to your own account. You may need to contact the support team of your hosting provider to confirm the availability of the
grepcommand.The suggested database queries produce errors: #1064 – You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ‘[table] WHERE [column] LIKE ‘%adelia%'’ at line 1
Both
[TABLE]and[COLUMN]are examples. Because I don’t have access to your web server, I cannot mention the real names for the tables that you have created in your database, nor the columns in these tables. The rest of the SQL statements are correct, the important part is theLIKE '%[QUERY]%'but you have to modify the rest to make it work in your own database since you are the only one who knows the names of the tables.[1] https://sitecheck.sucuri.net/
[2] https://sucuri.net/website-security-platform/Hello, first of all it’s important to understand that the Sucuri WordPress plugin DOES NOT contains a proactive (server-side) malware detection system. This is only provided by our premium services [1]. The plugin is offered as a complementary tool for our paying clients and some of the features can be used for free.
Because I have no access to your web server to conduct a proper investigation, I cannot answer the question “How was the hacker able to inject the backdoor in the first place?” but with the information that you currently have I have some suggestions that could help you track down the infection itself.
- Search “adelia” across your entire project [2],
- Search “file-manager” across your entire project [3],
- Search “business-proposal” across your entire project [4],
- Search “adelia” across your entire database [5],
- Search “file-manager” across your entire database [6],
- Search “business-proposal” across your entire database [7],
Marking as resolved, let me know if you need more information, good luck!
[1] https://sucuri.net/website-security-platform/
[2]grep -rni "adelia" -- ~/public_html/
[3]grep -rni "file-manager" -- ~/public_html/
[4]grep -rni "business-proposal" -- ~/public_html/
[5]SELECT * FROM [table] WHERE [column] LIKE '%adelia%';
[6]SELECT * FROM [table] WHERE [column] LIKE '%file-manager%';
[7]SELECT * FROM [table] WHERE [column] LIKE '%business-proposal%';Let’s try to answer this question taking a look at the code:
First of all, we need to understand how does the plugin determines the state of the options in the settings page, for this we will take a look at the code that is executed when the security alert options are displayed in the dashboard. This function “sucuriscan_settings_alerts_events” [1] is used to render the HTML of all those checkboxes, and using an iterator we go through all the available options and retrieve the current value from the database [2] (actually, from the settings file, the plugin doesn’t stores the settings in the database).
If we take a look a the definition of this function “SucuriScanOption::getOption()” [3] the first thing that it does is to load all the data contained in the settings file located here [4] and checks if the requested option is contained in this file, if yes then the function returns that value, otherwise it returns the default value.
Considering this information, we can assume that the failure point is with the “read the settings file” step, because according to what you are saying, the plugin is randomly “resetting” the settings to their default values. For some reason, in your web server, this file [4] is not being readable by the PHP interpreter at certain moment — we don’t know when yet.
Since this seems to be an edge case involving specific details about the structure of your hosting account, I cannot do much to investigate. Right now I am unable to reproduce the problem in my server, so I cannot provide a fix. What I suggest you, is to monitor the permissions and content of the settings file, something in your server is either removing the read access or completely deleting the file, that’s why the plugin falls-back to show the default settings.
Let me know if you can find the reason for this, I will be happy to help if you provide more information so I can reproduce the issue in my server.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/cf06eee/src/settings-alerts.php#L386-L392
[2] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/cf06eee/src/settings-alerts.php#L483-L525
[3] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/cf06eee/src/option.lib.php#L229-L305
[4]/wp-content/uploads/sucuri/sucuri-settings.php@jarledb — I apologize for the delay on the release of the new version of the plugin. Unfortunately, I have no power over the decision to release an update. Without the authorization of my project manager it’s impossible for me to release the patches that I have submitted to the development repository.
What I can do is, talk with my co-workers in the development team to accelerate the testing of these changes and try to convince my project manager to release the update before the end of the year. For now, you can use the development version of the plugin directly from my repository here [1].
Lets hope that my employer agrees to release an update for Christmas.
Let’s try to answer this question taking a look at the code:
First of all, we need to understand how does the plugin determines the state of the options in the settings page, for this we will take a look at the code that is executed when the security alert options are displayed in the dashboard. This function “sucuriscan_settings_alerts_events” [1] is used to render the HTML of all those checkboxes, and using an iterator we go through all the available options and retrieve the current value from the database [2] (actually, from the settings file, the plugin doesn’t stores the settings in the database).
If we take a look a the definition of this function “SucuriScanOption::getOption()” [3] the first thing that it does is to load all the data contained in the settings file located here [4] and checks if the requested option is contained in this file, if yes then the function returns that value, otherwise it returns the default value.
Considering this information, we can assume that the failure point is with the “read the settings file” step, because according to what you are saying, the plugin is randomly “resetting” the settings to their default values. For some reason, in your web server, this file [4] is not being readable by the PHP interpreter at certain moment — we don’t know when yet.
Since this seems to be an edge case involving specific details about the structure of your hosting account, I cannot do much to investigate. Right now I am unable to reproduce the problem in my server, so I cannot provide a fix. What I suggest you, is to monitor the permissions and content of the settings file, something in your server is either removing the read access or completely deleting the file, that’s why the plugin falls-back to show the default settings.
Let me know if you can find the reason for this, I will be happy to help if you provide more information so I can reproduce the issue in my server.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/cf06eee/src/settings-alerts.php#L386-L392
[2] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/cf06eee/src/settings-alerts.php#L483-L525
[3] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/cf06eee/src/option.lib.php#L229-L305
[4]/wp-content/uploads/sucuri/sucuri-settings.php@ohute — I am glad you were able to verify the origin of the IP address. Don’t hesitate to open a new ticket if you have additional questions and/or have suggestions about the plugin. Merry Christmas (◕‿◕)
There is something called “User Agent Spoofing” [1].
Basically, when the web browser accesses a website, it sends some information about your computer to the server, these are called HTTP headers. One of them is the “User-Agent” which holds the information about which web browser are you using, operating system, version numbers, plugins, etc.
The thing is, all this information can be spoofed with multiple tools that are publicly available on the Internet. CURL [2] for example, allows you to set any HTTP header that you want and also modify the existing ones.
In this case, it seems that someone who is trying to access the admin interface of your website is using one of these tools to brute force the login page. And is changing the User-Agent to “WordPress” for reasons that are irrelevant to us. Here [3] is an example of how someone can do this, just so you can see how easy it is.
[1] https://en.wikipedia.org/wiki/User_agent#User_agent_spoofing
[2] https://en.wikipedia.org/wiki/CURL
[3]curl -H "User-Agent: Ohute Browser 1.0.4" https://example.comThe log in the screenshot [1] is suspicious, that’s why the plugin has included it in there. It is up to the administrator of the website to determine if the event was triggered via a legitimate action or by a person/system trying to exploit a vulnerability.
Considering what I previously mentioned about WordPress deleting drafts automatically, if you agree with my statement there, we could assume that this log is referring to one of those automatic cleanups performed by the website via a scheduled task. A good way to be sure that this is true is to reverse the IP address that you marked as “Unknown IP” and check if the host corresponds to the network that you are using to serve the website.
Here are two tools [2][3] that you can use to execute an IP Lookup.
Here is an example, if you reverse this IP address [4] you will get something like [5] and so you will know that the IP corresponds to Google’s network. The majority of big hosting providers have their own network, others outsource the infrastructure. If you are lucky, you will be able to find enough information using one of these tools to determine the origin of that post deletion action.
Let me know if you need more information.
[1] https://i.imgur.com/Lc0IXXn.jpg
[2] https://mxtoolbox.com/ReverseLookup.aspx
[3] https://remote.12dt.com
[4]8.8.8.8— OR —8.8.4.4
[5]google-public-dns-a.google.comYou are right. The API key shouldn’t be among the settings that can be exported/imported. People use this tool in different ways so initially it seemed like a good idea to allow to export all the options, now I can see how including the API key can affect the import operation in other websites.
I have submitted this patch [1] to our development repository to fix this issue. The code will be available in the next update after my co-workers perform a code review and finish the testing of other changes that will be included in the next version.
For now, feel free to remove the API key and request a copy of the original one — if you already generated one before the import of the settings — or remove the key and request the generation of a new one for each site.
[1] https://github.com/cixtor/sucuri-wordpress-plugin/commit/2025373
Yes, if you get a copy of the clean version of your website you can safely re-upload it and replace the files that are infected. However, you may end up falling in an infinite loop if any of the files that you have in the backup have a vulnerability. If you upload the clean site and someone finds this vulnerability, they may upload the malware again, then you will upload the clean site again, then they will upload the malware again and so on until any of you get tired.
The only way to prevent this infinite loop and stop the infection once and for all is to either patch the vulnerability that allowed the initial infection to enter your site, or place a firewall between your website and the visitors so that any re-infection attempt can be stopped.
You may have found a bug in the code, but right now I am unable to reproduce it in my development environment. I already reviewed the source code of that interface and the logic is correctly designed to print X number of entries per page consecutively until the total number of logs are fed into the page.
You can download the files where these logs are being stored [1][2].
Marking as resolved. Feel free to share more information about this bug so I can reproduce, investigate and fix as soon as possible.
[1]
/wp-content/uploads/sucuri/sucuri-lastlogins.php
[2]/wp-content/uploads/sucuri/sucuri-oldfailedlogins.phpI am unable to answer this question properly as I have no access to your website to check what is exactly happening, I can merely speculate. By the logs, it seems that someone is creating a post and the post comes with a feature image, but the post is later deleted and the image (associated to it) is also purged from the media library.
That’s all I can say with the information that you provided.
I hope you find an explanation for these events, good luck!
The plugin displays information that comes from SiteCheck’s API [1] and this information is cached for at least 48 hours. If you are still seeing the warning even after the cache has been refreshed then I suggest you to contact my co-workers in the malware research team [2] as I have no access to the code that powers SiteCheck so I cannot answer your question of why the warning exists, the plugin simply displays what SiteCheck reports.
[1] https://sitecheck.sucuri.net/
[2] http://labs.sucuri.net/?aboutYour website has been infected with a common malware.
Malicious people inject code to promote other sites with questionable content like porn, viagra, and in this specific case, escorts. The cleanup process depends on how the infection started as there are many ways to inject these things into your code and/or database, that’s why companies like Sucuri offer premium services, because the cleanup process is more complicated than just opening the code and removing some pieces here and there.
However, even if you manage to clean the website but do not patch the vulnerability that allowed the malicious person to inject the malware in the first place, the website will get infected again.
Something that you can do for now is to scan your project using a tool like
grep[1], this program allows you to search a piece of text through multiple files, what you can use it to search for pieces of the infection and then decide what to do with the files by yourself, if you are able to clean the infected files then do so.Here is a command that could work for you [2] where
MALWAREis the text that is in the payload, maybe the domain that is being promoted, in this case “ankara escort” or simply the word “escort” since it shouldn’t be in your website at all, the chances are high that you will be able to find the infected files with this query.Good luck!
[1] https://en.wikipedia.org/wiki/Grep
[2]grep -rn "MALWARE" -- ~/public_html/
