Imperva, an international cyber security company founded in 2002, published its 2015 web application attack report. The report includes a thorough analysis of attack data obtained through its WAF or Web Application Firewall.
In the report, Imperva’s application defense center group analyzed 297,954 attacks and 22,850,023 alerts on 198 of the applications it protects behind its WAF. The data is from January 1st, 2015 – June 30th, 2015 and provides a solid overview of the number and types of attacks web applications are experiencing.
The report covers a lot of ground but for the purpose of this site, I’m focusing on WordPress.
Automated tools recorded the web applications’ traffic and malicious events were documented in log files. Imperva’s application defense center group analyzed the data using special-purpose software and its knowledge base.
You can find more information that explains how the data was analyzed on page seven of the report.
WordPress Is the Most Attacked CMS Application
Out of the 198 applications protected, Imperva identified 55 that are CMS-based, 20 WordPress applications, 11 Drupal, and 24 that are based on 11 other CMS frameworks.
According to the report, CMS applications suffered an average of three times more attacks than non-CMS applications. WordPress applications suffered from 3,497 attacks in the reported period which is 250% more than non-CMS Applications. Note from the above image that spam attacks against WordPress outnumber all other types of attacks.
Imperva says the attraction to CMS applications, especially WordPress is not new.
CMS frameworks have an open nature, with open developer communities that generate a never-ending sequence of plug-ins and add-ons, with varying levels of security. This situation has led to corresponding never-ending flow of CMS vulnerabilities, with WordPress as the leading CMS taking the lead also in the amount of published attacks.
Furthermore, the fact that WordPress and other CMS applications resemble each other facilitates automated scanning attacks that work effectively on all applications of this type with only minimal adjustments.
Varying levels of security in plugins have led to many vulnerabilities making WordPress the leader in the amount of published attacks.
Proportions of Attacks
Taking spam attacks out of the equation, the most popular attack type against WordPress applications is (RCE) Remote Command Execution with (RFI) Remote File Inclusion taking second place.
- Remote Command Execution (RCE) is an attack that allows the attacker to execute operating system commands in a system shell. The attack exploits applications that suffer from insufficient input validation in conjunction with passing this input to a system shell. The attacker’s payload is executed with the same privileges of the vulnerable application and can lead to full compromise of the server.
Even though the other monitored CMS applications are written in PHP, RFI attacks on WordPress are significantly higher than all other applications. Imperva offers one possible explanation:
Attackers don’t target a specific application, but start with scanning the Internet for vulnerable applications. A Low Hanging Fruit approach that is simple and effective for the detection of potential RFI targets, would be to run a WordPress test and mount an RFI attack in case of success.
The report goes on to show geographic attack trends, PHP vs non-PHP attack incidents, traffic volume, case studies, and more.
No Need to Panic
Even though it’s only six months of data, the results don’t surprise me. WordPress is used on a quarter of the top 10 million websites ranked by Alexa so of course its going to be the most attacked CMS.
The data in the report reinforces my belief that every public site online is likely being scanned or attacked multiple times a day. Unless you’re using a service or plugin that logs these types of attacks, its hard to know how popular of a target a site is.
If you’re aware of a plugin or service that provides a user-friendly interface that shows and explains the attacks it’s protecting against a site, please send me a link in the comments.
Basic Security Principles
It’s imperative that you use a strong password and two-factor authentication. Consider using a service like Clef that allows you to login to WordPress without a password. I also highly encourage you to read the WordPress security whitepaper to learn how WordPress protects itself against common attacks mentioned in Imperva’s report and how to responsibly disclose a WordPress security vulnerability.
So Jeff, we were talking the other day about how to bring up issues of wordpress, and how to engage the core developers.
Today, we are looking at a huge problem for WordPress, spam in all it’s different colors. The number of times through TRAC and other means that the developers have been engaged on spam is huge, the number of solutions and changes incredibly small.
First and foremost, there is no simple or direct method to disable the various routes taken to spam. You could require users login to post comments, but then you create additional risks by allowing them a basic level of access to the back end of your site. Allowing people to log in means that every permission escalation hack can now be applied to your site. So for many sites, forcing users to log in is not a cure, just a different and more dangerous problem waiting to happen.
So then you move to “approved comments only”. The downside (as you well know) is that you get to spend a good part of your day deleting spam. Akismet can help, but for a commercial user the cost versus the effectiveness isn’t a good balance. Way too much spam still gets through.
Why does this happen? Well, there are two core issues at hand here: WP seems to do a poor job at handling direct calls to comment code, and a seeming quiet agreement between the core developers and Automattic not to fix the spam issue and harm the income stream from Akismet services. It sounds a little weird but it really does seem that spam issues are not addressed because of a business model issue – both to sell Akismet service and also to sell wordpress “hosted” solutions for sites. It’s sort of like a non-compete clause.
WP comment system was created when the web was sweet and innocent, and track backs and glib comments were all the rage. Like email, comments have become less and less useful because the spammers realized they could get their message and links out via your sites. Faced with the issue, the true question is how to handle spam better – and that may be a complete overhaul of the way the comment systems work. There is no safe and reasonable way to have wide open comments anymore.
For me, the first step is to give better control on the sites themselves. Each of the routes for a comment to get on your site should be able to be controlled. XMLRPC? wp-comment.php ? trackbacks? each route needs to have it’s own security and choices so that sites can handle the flow. That would include the ability to shut off and return 404 errors to discourage bots and scammers from even knocking on the door. Just denying people with a “we can’t accept comments this way” message doesn’t work, because every attempt to spam uses system resources, starts a database connection, uses up a process… handling big volume spammers can cripple a site even if you don’t want their stuff.
My personal solution is to hack XMLRPC and others to deny access based on IP. I have only a few IP addresses that can use XMLRPC, everyone else gets a blank 404 response. I have to hack it because there is no provision in any of the site access programs to add security code or filtering. For the record, I do the same on wp-login and /admin/index.php to control the flow of door knockers and hackers – all with code added manually on each update because, well… there is no hook and no place to handle this stuff directly.
WordPress is a target. Developers need to more clearly understand that and understand what it means not for highly technical users but for “end users” who can’t write a regex or code htaccess well enough to be secure. We need to push down the business model barriers that appear to block progress on the issue, it’s very likely that this sort of issue is what will eventually bring wordpress down.