yorman

Thank you for the list @adz1111

I just noticed that your website is hosted in a Windows Server. I’m not very familiar with Windows, but assumming that you’re using Apache then I suggest you to search the “.htaccess” file in the parent folders because the rules are recursive.

You may also want to talk once again with your hosting provider, because regardless of what the Sucuri Scanner says, one or more pages are returning a “500 Internal Server Error” when the browser attempts to access a file that, apparently, doesn’t exists.

Of course, this is assuming that you’re having the same problem as @nnikolov

@adz1111 can you post a list of all the files (including hidden files) inside this directory [1]. And if there’s any hidden file, like “.htaccess”, can you post the content of that file as well?

[1] /public_html/wp-includes/js/

It should not say that the site is not clean, just because there is an 500 error.

Because “500 Internal Server Errors” are ambiguous by nature, there is no guarantee that your website is clean or not. Better to display a warning so the website owner can investigate. If we do not display a warning after finding a 500 status code in one or more of your web pages, then you will never know about a possible infection.

I suspect that this is a WP core file that is missing, and this is why you are showing this error. Is this correct?

No, that is incorrect.

If the file is part of a regular WordPress installation but has been deleted, the plugin will print the filename inside a table below the “WordPress Integrity Check” panel. The plugin will also provide an option to restore the content of the file in that case.

If the error is “Site Not Clean”, it means the URL is returning suspicious code.

Unfortunately, you didn’t provide the real URL so I cannot confirm this for you. I can only tell you that there is a type of malware that hides itself from the website administrators by checking if the User-Agent in the HTTP request matches one of the popular web crawlers, for example, Googlebot [1]. When the User-Agent is different, the malware returns a “404 Not Found” response, consequently confusing the user.

Please keep in mind that even if the file doesn’t exist, the malware could still be deceiving you. Please check the access control file (also known as .htaccess) for suspicious redirection rules.

Marking as resolved, let me know if you need more information.

[1] https://support.google.com/webmasters/answer/1061943?hl=en

Can you share what’s the error or the website so I can tell you how to fix it?

Hello @imagimedia

Please open the dev tools in your web browser [1][2].

Then reload the plugin dashboard and check if any of the Ajax requests (marked as XHR in the Network panel) returns an HTTP status code different than 200. If yes, then click it and inspect the response, you may find an error message explaining the failure.

Other than that, I cannot do much from here to help you because the code clearly works, otherwise much more people would be reporting the same issue. There is something in your website that is only specific to you, that is affecting the load of the malware scan.

Let me know if you need more information.

[1] https://developers.google.com/web/tools/chrome-devtools/
[2] https://developer.mozilla.org/en-US/docs/Learn/Common_questions/What_are_browser_developer_tools

Hello @halohtlo

The Sucuri plugin doesn’t communicates with the database at all.

It detects successful and failed logins via WordPress hooks [1][2].

It doesn’t matter how you named the users table, if your users are logging in using one of the user authentication methods supported by WordPress, then the Sucuri plugin will detect the operation.

Let me know if you need more information.

Thank you for supporting our work.

[1] hookLoginSuccess() via wp_login
[2] hookLoginFailure() via wp_login_failed

Hello @jarrodwhitley0518

Thank you for your concern.

Disclaimer: I wrote every line of code in that file.

First of all “escapeshellarg” is not dangerous. It is used to escape a string to be used as a shell argument. You can read more about it here: http://php.net/manual/en/function.escapeshellarg.php .

However, there is another function in that file that is actually considered dangerous: exec. Below are the details of how I am using this function, and how unlikely it is to be used to attack your website.

—

All the code in that file is used to power one single feature in the plugin called “WordPress Integrity Diff Utility” that’s disabled by default. The button that allows you to enable it contains a warning with an explanation of the consequences of turning this tool on. The code is used to enable the execution of the Unix “diff” command to allow an admin to inspect corrupt WordPress files found during a malware scan.

The plugin firsts checks if the “diff” command exists executing this:

command -v diff 1>/dev/null

This command doesn’t accepts any user input, so it is 100% safe.

Then, for every corrupt file, it executes this command:

diff -u -- FOO BAR 2> /dev/null

Where “FOO” and “BAR” are two files generated like this:

$a = tempnam(sys_get_temp_dir(), SUCURISCAN . '-integrity-');
$b = tempnam(sys_get_temp_dir(), SUCURISCAN . '-integrity-');

The user cannot tamper these files paths, so it is 100% safe.

Possible Attack Vectors

Here is a step-by-step of how to attack your website with this code:

1. The hacker tricks you (or any other admin user) to enable the “WordPress Integrity Diff Utility”
2. The hacker adds, modifies, or deletes —using a different exploit— one of the WordPress core files
3. The hacker injects malicious code into WordPress’ official GitHub or Subversion repository
4. The hacker tricks you to click the corrupt file from the “WordPress Integrity” page in the Sucuri plugin
5. The plugin creates safe temporary files, as explained above, using PHP “tempnam” function
6. The plugin downloads the malicious file from WordPress’ GitHub or Subversion repository into “FOO”
7. The plugin copies the —possibly infected— file (created in step #2) into “BAR”
8. The hacker replaces the “diff” binary with a malicious program, without alerting your hosting provider
9. The rogue “diff” program takes “FOO” and “BAR” and spits malformed text
10. The plugin prints the malformed text into the Sucuri Dashboard page
11. The malformed text, somehow, bypasses all WordPress HTML escape functions
12. The admin user who’s currently in the page gets pwned!

All of this is necessary in order to use the “command.lib.php” file maliciously. As you can see, some of these steps are very difficult to accomplish, and at some points it doesn’t makes sense to continue because, for example, if the hacker is able to compromise WordPress’ official GitHub/Subversion repository, why would they bother with your website? They can do more harm by continue the attack against Automatic instead.

In the unlikely scenario where the hacker has a grudge against you, they need to trick You, WordPress, and your Hosting Provider multiple times in order to use, maliciously, the code that I wrote inside that file.

This attack vector is almost impossible to happen.

I appreciate you taking the time to audit the Sucuri plugin’s code.

Please let me know if you have other concerns.