Good ideas for basic security:
a) do not use admin as the superuser login name; always make second name; don’t use the superuser admin name to build pages as it reveals that ‘user’ to hackers;
>> ‘superuser’ for site admin
>> ‘othername’ for content building as admin; not superuser level
b) use plugins like ‘limit login attempts’ – a fantastic free plugin to thwart repeat password guessing, and also shows repeat IPs so you know *where* some kinds of WordPress attacks coming from
c) disable xmlrpc – known attack vector; disable editing of WP files from the WP admin; this is done via functions.php or custom plugin
d) force https – all WP sites should be running https now. SSL certs are now free with ‘Let’s Encrypt’ – so your host should be supporting that!
e) force strong passwords (not ‘bunny72’ but ‘8g932vygSD97j$’); disable password reset functions
f) remove all old-unused plugins, themes no longer used – nulled code can still be used by hackers
g) scan site regularly with securi free site scanner
h) make sure using good host running modern versions of bind, mysql, php, etc. — make sure running php 5.6 and up as older versions are ‘end of life’
i) make sure running WP 4.8 and up (all versions of WP prior to 4.7 make have major security flaws; with over 100,000 sites hacked in 2017 due to running OLD versions!)
j) make sure web host running IPtables and automatic Ip blocking for hack attempts; this stops server side IP hacking attempts — all good hosts are running something like this (we do here)
k) fully implement suggestions from the WordPress documentation (always good to learn to use WP by reading the manual …. I know! Crazy, right?): https://codex.wordpress.org/Hardening_WordPress
l) make regular backups (ironically, I am doing that ‘right now’ on my machine while having first cup of coffee …); this means doing MySQL full dbase backups from your hosting panel; not just the ‘export’ option in WP (which doesn’t always do a good restore job on import). The full dbase backup at hosting level, allows you to ‘go back’ to clean version of site if you get content injection hack
After hack; change all passwords (hosting, FTP, and WP); delete WP, all plugins, themes, check for malicious code in htaccess, random weird php files; reinstall everything for clean copies.
Hope that helps.
If you have a high-profit website, you should also consider paying for a PCI-DSS scanner to check your site monthly, as this reveals vulnerabilities in your hosting, server, and your site (e.g., SecurityMetrics, etc.).
KNOWN SECURITY ISSUES:
* Newspaper 6.7.1
* Newspaper 7.0
* WordPress prior to 4.7
MAKE A SECURITY PRACTICE POLICY CHECKLIST FOR YOUR SITE(S):
Also good to setup a security policy internally — you should be checking update changelog/readmes for *all* plugins/themes you use and for WordPress core — as the TagDiv theme security notice for 6.7x was included way back in April 2016:
Version 6.7.2 – April 27th, 2016
fix: social counter facebook issue with new API keys
fix: security issue
a minor issue with 7.0 was fixed with 7.1 for those early adopters who rushed to install 7.0
Version 7.1 – May 20th, 2016
fix: panel got stuck while saving in specific cases, mostly related to categories
fix: Related articles filter was not working with the settings from the panel if you choose related by tags and the post had no tags set.
fix: contributor users cannot change the post template now, this is more in line with WordPress
fix: Security issues
fix: back to top on ie9
fix: missing woocommerce add to cart on mobiles
==============
Everything on the web requires periodic checkups; it’s not static like old websites with static shtml files or similar. WordPress, plugins, PHP, MySQL, WooCommerce, etc., all need to be *checked* when updates are done — new features, no need to upgrade unless you read the help info first; for security patches, these should *always* be done when originally notified!
I don’t work here — but our ‘security practice policy’ internally forces us to CHECK when new updates come out to see WHY they were updated, in case of security issue(s).
Recommended you consider the same, or hire a company to do it for you.
For those who got lost from above:
a) how to scan your site with free Securi site scan — may not catch everything, but good place to start:
https://sitecheck.sucuri.net/
b) WordPress offical docs (codex)
— on “security hardening WordPress”
https://codex.wordpress.org/Hardening_WordPress
–> includes suggestions for changes to .htaccess
–> stop php execution in uploads folder
–> disable XMLRPC
–> edits to wp-config.php
: secure the file
: disable core file editing from WP panel
c) Official WordPress security updates log
https://wordpress.org/news/category/security/
d) WPscan WordPress vulnerability log
https://wpvulndb.com/
e} Security Plugins
While there are many to choose from, an essential one we use here:
* Limit Login Attempts
https://wordpress.org/plugins/wp-limit-login-attempts/
You should be checking these — hacker sure are !!
Site hacked already?
Suggestions:
WordPress official docs (codex)
https://codex.wordpress.org/FAQ_My_site_was_hacked
SECURI – ‘How to clean hacked WordPress’
https://sucuri.net/guides/how-to-clean-hacked-wordpress
WP Beginner –
Beginner’s Guide to Fixing Your Hacked WordPress Site
http://www.wpbeginner.com/beginners-guide/beginners-step-step-guide-fixing-hacked-wordpress-site/
Forgot to include this article, also:
https://www.wordfence.com/blog/2017/08/traffictrade-malware/
attackers modify your
wp_optionstable to inject the malicious code into that table
What TrafficTrade Malware Does On Your Site
Once you have been infected with TrafficTrade, it injects Javascript onto your site that loads from the TrafficTrade.life domain. The actual script is very simple.
It redirects your visitors to a ‘trafficreceiver’ domain which then does further redirects to whichever campaign they are running. In the case of my test, you are redirected to a site that wants you to install a Chrome plugin – most likely malicious.
Seems this IP range would be useful to block:
79.110.128.0 – 79.110.135.255
<hr>
HOW TO CLEAN DBASE!
https://wpfixit.com/traffictrade-wordpress-infection/
REMOVE INFECTION SCRIPT FROM SITE
The goal here is to track down where the script we mentioned above exists and them remove all traces of it. The scanning we did in the previous step will likely show you what files on your site have this script but it will not show you where in the database it remains.
Run Search and Replace Using a Plugin
Our favorite search and replace plugin is Better Search Replace. Install and active this plugin to search and replace database content. You would simply run a search for the script above and replace it with an empty filed.
Run Search and Replace Using a SQL Query
To do this, you will need phpMyAdmin access. This access allows you entry to edit the database that your WordPress site runs on. Once you have this you will run the SQL Query below which will search the entire database for the bad script and remove it.
UPDATE wp_posts SET post_content = REPLACE(post_content, '<script src=\'https://traffictrade.life/scripts.js\' type=\'text/javascript\'></script>', '') WHERE INSTR(post_content, '<script src=\'https://traffictrade.life/scripts.js\' type=\'text/javascript\'></script>') > 0;
Also, another useful scanner we use here, checks for ‘black listed’ domains, IPs, hosts, ISP, for a website, DNS poisoning etc.
https://mxtoolbox.com/domain/
REMINDER – if you’re running one of the vulnerable version of WordPress, or vulnerable versions of Newspaper theme — you *will* get hacked.
PLEASE
a) check your theme version
b) if running vulnerable versions, or old WordPress:
— immediately run scanning software, to check for infection
c) make sure you have proper backups, even if infected
d) clean your website.
e) once fixed – make secure backups
f) then make a plan to regularly check versions and make proper secure backups
ONLY YOU CAN KEEP YOUR SITE(S) SAFE!
If you have already been infected; be sure to check your
>> theme option - header ad field
Clear that and resave. If it comes back, then you need to clean your dbase also!
NOTE – if you have a web host running Plesk/ONYX there is now a nice WordPress toolkit for the system that helps secure known issues with WordPress … and I thought I’d share some of the info from that plugin for ONYX systems for those looking for more info on hardening their setup.
=================================
The wp-content folder. The wp-content directory may contain insecure PHP files that can be used to damage your site. After WordPress installation, PHP files can be executed from the wp-content directory. The security check verifies that the execution of PHP files in the wp-content directory is forbidden. Note that custom directives in the .htaccess or web.config files might override this security measure. Also note that some of your plugins might stop working after securing the wp-content folder.
The wp-includes folder. The wp-includes directory may contain insecure PHP files that can be used to damage your site. After WordPress installation, PHP files can be executed from the wp-includes directory. The security check verifies that the execution of PHP files in the wp-includes directory is forbidden. Note that custom directives in the .htaccess or web.config files might override this security measure. Also note that some of your plugins might stop working after securing the wp-includes folder.
The configuration file. The wp-config.php file contains credentials for database access and other sensitive information. After WordPress installation, the wp-config.php file can be executed. If, for some reason, processing of PHP files by the web server is turned off, hackers can access the content of the wp-config.php file. The security check verifies that unauthorized access to the wp-config.php file is blocked. Note that custom directives in the .htaccess or web.config files might override this security measure.
Directory browsing permissions. If directory browsing is turned on, hackers can obtain information about your site (what plugins you use and so on). By default, directory browsing is turned off in Plesk. The security check verifies that directory browsing on the WordPress installation is turned off.
Database prefix. WordPress database tables have the same names in all WordPress installations. When the standard wp_ database table name prefix is used, the whole WordPress database structure is not a secret and anyone can obtain any data from it. The security check changes the database table name prefix to something other than wp_. The maintenance mode is turned on, all plugins are deactivated, the prefix is changed in the configuration file, the prefix is changed in the database, the plugins are re-activated, the permalink structure is refreshed, and then the maintenance mode is turned off.
Security keys. WordPress uses security keys (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, and NONCE_KEY) to encrypt information stored in the user’s cookies. A good security key should be long (60 characters or longer), random and complicated. This security check verifies that the security keys are set up and that they at least contain both alphabetic and numeric characters.
Permissions for files and directories. If permissions for files and directories do not comply with the security policy, these files can be used to hack your site. After WordPress installation, files and directories can have various permissions. The security check verifies that the permissions for the wp-config.php file are set to 600, for other files to 644, and for directories to 755.
Administrator’s username. When a WordPress copy is installed, by default there is a user with administrative privileges and the username admin. As a user’s username cannot be changed in WordPress, one only needs to guess the password to access the system as the administrator. The security check verifies that there is no user with the administrative privileges and the username admin.
Version information. There are known security vulnerabilities for each WordPress version. For this reason, displaying the version of your WordPress installation makes it an easier target for hackers. The version of an unprotected WordPress installation can be seen in the pages’ meta data and readme.html files. The security check verifies that all readme.html files are empty and that every theme has a functions.php file which contains the line: remove_action(\’wp_head\’, \’wp_generator\’);.
I would also like to ‘suggest’ that TagDiv discontinue ‘printing’ the theme version in the footer, as this is an easy Google search for vulnerable theme versions, much like printing the version of WordPress in header was incredibly dumb for WP security practices. I’m not sure this is still happening in latest version, but I used to have to remove that code by hack of theme files.
Also worth noting, when ‘cleaning’ your site, you need to *check* all editable fields in your theme setup; this means logo, favicon, widgets, footer, custom code blocks for javascript, ad boxes, etc. — anything managed by java, or related to java, should be checked!
updated article from SECURI:
https://blog.sucuri.net/2017/09/old-themes-abandoned-scripts-pitfalls-cleaning-serialized-data.html
WP UPDATE 9.19.17
Summary
From the WordPress 4.8.2 release post: WordPress versions 4.8.1 and earlier are affected by nine security issues:
$wpdb->prepare() can create unexpected and unsafe queries leading to potential SQL injection (SQLi). WordPress core is not directly vulnerable to this issue, but we’ve added hardening to prevent plugins and themes from accidentally causing a vulnerability. Reported by Slavco.
A cross-site scripting (XSS) vulnerability was discovered in the oEmbed discovery. Reported by xknown of the WordPress Security Team.
A cross-site scripting (XSS) vulnerability was discovered in the visual editor. Reported by Rodolfo Assis (@brutelogic) of Sucuri Security.
A path traversal vulnerability was discovered in the file unzipping code. Reported by Alex Chapman (noxrnet).
A cross-site scripting (XSS) vulnerability was discovered in the plugin editor. Reported by 陈瑞琦 (Chen Ruiqi).
An open redirect was discovered on the user and term edit screens. Reported by Yasin Soliman (ysx).
A path traversal vulnerability was discovered in the customizer. Reported by Weston Ruter of the WordPress Security Team.
A cross-site scripting (XSS) vulnerability was discovered in template names. Reported by Luka (sikic).
A cross-site scripting (XSS) vulnerability was discovered in the link modal. Reported by Anas Roubi (qasuar).
In addition to the security issues above, WordPress 4.8.2 contains six maintenance fixes to the 4.8 release series.
Nov. 29, 2017
==============
WordPress versions 4.9 and earlier are affected by four security issues which could potentially be exploited as part of a multi-vector attack. As part of the core team’s ongoing commitment to security hardening, the following fixes have been implemented in 4.9.1:
Use a properly generated hash for the newbloguser key instead of a determinate substring.
Add escaping to the language attributes used on html elements.
Ensure the attributes of enclosures are correctly escaped in RSS and Atom feeds.
Remove the ability to upload JavaScript files for users who do not have the unfiltered_html capability.
Updated tip:
If you are using Google Chrome, you can now run updated ‘audit’ via console (press F12 key); which can show vulnerable versions of javascript libraries used by old plugins. For instance older versions of JQUERY are not secure!
In Chrome
press > F12
from tabs > “Audits”
check [x] best practices
-run audits’
