A new researcher’s perspective on Wordpress security basics.
Hello everyone, project work has been going well this month. I’ll be attending a virtual B-sides on March 13th. This will be my 2nd B-sides event ever attended and I am looking forward to it.
I wanted to use this month’s blog to highlight and look at specific topic regarding our local community’s website use. As part of my initiative to make Rochester’s web safer, I decided to personally test the website security of local small business’. Compared to larger, well paced organizations, this group stands to lose the most in the event of a security breach. One particular platform came up in my research more often than others, and that would be Wordpress.
Many small business owners find the Wordpress toolkit useful; It’s easy enough to manage with plugins and resources, offloading a lot of the HTML work into an automated GUI. Wordpress is popular enough to have its own dedicated community in our town through Facebook and Meetup.
Wordpress security is important for a number of reasons. Poor implementations can lead to an attacker doing all sorts of nasty exploits, such as running bitcoin miners on web servers[1], or using them for reflected DDOS attacks[2]. I’ll be writing some recommendations based on my findings, and what an attacker might see if they were looking to exploit a Wordpress website.
Wordpress itself has a bug bounty program. This means widespread exploits can be detected and reported by security researchers. One thing to note is the implied responsibility between Wordpress and its users, the website owners. If a site owner installs a Wordpress plugin for example, it would be the site owner’s to keep the plugin secure and up to date. That would be you, the Wordpress defender. When attackers practices offense, you must practice the appropriate defense.
Starting off, WPscan is a database of vulnerabilities one would cross reference during plugin research. Web resource viewers can find what plugins your site runs from its homepage, and from there WPscan can do the identification. This allows an attacker to match version numbers, checking to see if an outdated plugin is vulnerable to a certain attack. The plugin itself can be installed into Wordpress, and if you choose to use this, it’s a good idea to schedule a regular scan time. https://wpscan.com/
XML remote procedure calling (XMLRPC) is resource that can be a serious liability if not handled correctly. The type of attacks I explored were relevant to External Entity Injection (XXE). They require the use of sending POST data with scripting. I was able to find and test in a few instances in our community’s security, and this is a very bad sign to see. I’ve taken the initiative to advise some of the worst offenders vis email, referring the following document and blog resource of brilliant security researcher Eshaan Bansal: https://blog.wpsec.com/xml-rpc/
Access to default pages, credentials and API’s should also be considered. Author lists for instance can reveal a default ‘admin’ login name. Be careful of providing RSS feeds on your site. This includes default admin logins, passwords, and user lists that would reveal these sorts of things. There are plugins out there to disable these.
Some are premium priced: https://perfmatters.io/
Others are Free and Open Source Software (FOSS). https://Wordpress.org/plugins/disable-author-archives/
Consider if honeypots would be useful. A honeypot is a tool that distracts less experienced attackers or bots and wastes their time with fake knobs and buttons. They can be bandwidth costly to your site though, so take heed. It’s also easy to know if you’re in one, as there are many tells. One such example is contact form 7’s version, which integrates on top of another plugin. https://Wordpress.org/plugins/contact-form-7/
Look at a firewall or word filter solution. Wordfence is one I’ve encountered and has worked effectively against malicious user inputs. Given that they have a security.txt file on their site, they also have some form of bug bounty support. https://www.wordfence.com/
Google your own website with the ‘site:www.example.com’ modifier. I cannot tell you how many lorrum ipsums I’ve seen this way leading to mysterious left behind resources. These resources often are insecure and need to be pulled from production ASAP!
If you run a storefront through Wordpress, outsource your cart system. If you have a shopping cart on your Wordpress site, you’re facing a major liability and running the risks of attracting bots, and vulnerabilities with indirect object references (IDORs). The least serious ones let users add nonexistent items to your cart, while the most severe may allow an attacker to hijack payment details [3]. Consider stripe’s list of web cart providers and evaluate carefully. https://stripe.com/en-dk/partners/apps-and-extensions/shopping-cart
This is certainly not an exhaustive list, so if you have any other recommendations to secure a Wordpress website, feel free to leave a comment.
Stay safe.
(Small edit, my calendar had the wrong date punched in for this year’s Bsides. It has been corrected above to March 13th)
[1]https://blog.malwarebytes.com/101/2018/02/how-to-protect-your-computer-from-malicious-cryptomining/
