Comment on Display Widgets Plugin Review by SEO Dave.

Display Widgets Plugin Dynamic Post Hacker Code Sorry to hear of the problems.

In principle yes the hack could have compromised your site in other ways.

I never installed the Display Widgets Plugin v2.6.* on a live site, only tested it in Localhost, so have no examples to look at beyond the “displaywidgets_ids” example I’ve pasted below (that was from my localhost test install).

The Display Widgets plugin v2.6.* adds a database option in the “wp_options” table looks like this:

displaywidgets_ids

a:1:{s:26:"__3371_last_checked_3771__";s:10:"1499359495";}

This in itself doesn’t cause any harm per se, but the entry and the plugin code allowed the developer to add a dynamic post into your database.

I don’t have an example of what this looks like, but understand it includes the name of the plugin “Display Widgets” and would assume it’s also in the “wp_options” table.

I’m afraid it’s a case of going through the database to see if anything stands out, for most WordPress sites the wp_options table tends to be below a few hundred entries so doesn’t take too long to look through. You are looking for anything that mentions Display Widgets or displaywidgets.

If the hacker went as far as to add one of these dynamic posts into your database there’s no reason why the entry couldn’t include other malicious code.

So basically they add a database entry which the malicious plugin (v2.6.*) uses to make a dynamic post database entry, but it could also be used to do other malicious things to your site. They could add all sorts of vulnerabilities to add backdoors.

The best advice would be to use a backup from before you installed the v2.6.* code, but that could be a backup from over 3 months ago!!!

Even though I have regular backups, if I had installed the malicious code I couldn’t go back three months (would loose important articles/comments), so would have to go with a manual security clean. I wrote a comment about what I’d do with the sites files: https://stallion-theme.co.uk/display-widgets-plugin-review/comment-page-1/#comment-48617 now I know a little more about what the backdoor hack does I’d also go through the database looking for options related to displaywidgets (did this in my localhost test installs, found nothing).

The person/people behind the malicious code has been doing this for years, they own loads of sites related to payday loans, finance, gambling… and have been hacking sites for years (found one mentioned on the WP forums from ~4 years ago) to add SEO link SPAM (they have a very well thought out SEO link SPAM program: I’m impressed). To put things into perspective the main suspect is in his early twenties and lives in a property that was bought in December 2016 for over £750,000 and they say blackhat SEO techniques don’t work anymore :-)

BTW Before doing anything I’d look through your sites log files for errors, white screen suggests a 500 error. The logs can point you in the right direction.

If you find it difficult to access your log files you can also get WordPress to output a “debug.log” file by adding this to your “wp-config.php” file:

Download the “wp-config.php” file via FTP to your computer, edit it with a text editor.

Find this line:

$table_prefix  = 'wp_';

Might not be ‘wp_’, doesn’t matter.

Below it add

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

when there’s errors it creates a file under:

“example.come/wp-content/debug.log” this file is publicly available (anyone can read it).

Browse through your site and check the file (can load it in a browser).

After finding and fixing the errors modify the code to:

#define('WP_DEBUG', true);
#define('WP_DEBUG_LOG', true);
#define('WP_DEBUG_DISPLAY', false);

Adding # comments out the code so it won’t run, but it’s in the file for next time (just remove the #s to check for other issues).

Also go to “/wp-content/” and delete the “debug.log” file, error notifications can be used by hackers to test for vulnerabilities, so you don’t want an easy to find log file left behind.

If you want to harden WordPress a little also add this to the “wp-config.php” file:

# Disable Editing in Dashboard
define('DISALLOW_FILE_EDIT', true);

This turns file editing under your Dashboard off: this assumes you don’t edit plugin and theme files under your Dashboard (which you shouldn’t do as there’s no backup).

David Law