It's going to be a busy few days with an awful lot of plugins wanting to update.
Multiple WordPress Plugins are vulnerable to Cross-site Scripting (XSS) due to the misuse of the add_query_arg() and remove_query_arg() functions. These are popular functions used by developers to modify and add query strings to URLs within WordPress. The official WordPress Official Documentation (Codex) for these functions was not very clear and misled many plugin developers to use them in an insecure way. The developers assumed that these functions would escape the user input for them, when it does not. This simple detail, caused many of the most popular plugins to be vulnerable to XSS.
To date, this is the list of affected plugins:
Google Analytics by Yoast
All In one SEO
Multiple Plugins from Easy Digital Downloads
Multiple iThemes products including Builder and Exchange
There are probably a few more that we have not listed. If you use WordPress, we highly recommend that you go to your wp-admin dashboard and update any out of date plugins now.
This issue was first identified by Joost from Yoast in one of his plugins (he did
Very detailed and thorough overview of how to understand plugin vulnerabilites. This is particularly relevant in light of the recent forced updates from the WordPress Core team of the WordPress SEO (Yoast) plugin.
The last 7 days have been very busy with a number of vulnerabilities being disclosed on multiple WordPress plugins. Some of them are minor issues, some are more relevant, while others are what we’d categorize as noise. How are you supposed to make sense of all this? To help provide some clarity on the influx of data, we want to provide some insights to help you, the website owner, navigate and understand these vulnerabilities. We will provide a summary and an explanation of the ones that matter and the ones that do not.
The Impact of Roles (Authentication) in Vulnerabiltiies
Contrary to popular belief, just because you hear “SQL Injection”, it doesn’t mean someone can actually hack your site. The real problem comes in remote and unauthenticated attacks. These can lead to mass compromises; compromised can be mean leveraged to distribute malware, spam and can lead to brand reputation issues like getting blacklisted by Google.
When an attack requires an authenticated user, the severity drops. However, it is not that uncommon for sites to allow subscribers to register. So, any vulnerability that requires a subscriber user can also lead to serious issues.
Once a vulnerability requires a
Excellent investigation on a plugin hijacking. Really scary story but so glad quick action was taken.
Last summer we shared a story about the SweetCaptcha WordPress plugin injecting ads and causing malvertising problems for websites that leveraged the plugin. When this plugin was removed from the official WordPress Plugin directory, the authors revived another WordPress account with a long abandoned plugin and uploaded SweetCaptcha as a “new version” of that plugin. In the end of the SweetCaptcha saga, we gave this warning:
It’s quite a common scenario when criminals try to hijack or buy developer accounts of legitimate applications, or pay their developers to add some malicious code into their software, so some benign plugin or application may turn bad after an update — the only thing that protects you is the author reputation and the security screening and approval process in the repository.
This time we’ll tell you of another plugin that turned bad after an update.
Backdoor in Custom Content Type Manager
Custom Content Type Manager (CCTM) is a relatively popular plugin with three years of development, 10,000+ active installs, and a satisfaction rating of 4.8. It helps create custom post types. Website owners find the classical “blog format” too restrictive, use the plugin to add
This guide is basic, but well rounded: it should help the thought about performance and which areas to focus on.
Since launching our website performance testing tool we have been getting a lot of questions about how to improve the speed and performance of WordPress websites. Many website owners are not aware how slow their sites are, so we are excited to help shed some light on the matter. There are a number of different resources available to help you dive into the world of performance optimization. In this article, I want to create a proper foundation for any website owner to start thinking about performance optimization.
This basic guide should help website owners understand how to think about performance and which areas to focus on. This information is designed as a high-level overview, but it is structured so that if you were interested in more data, you can follow the links provided for additional research, details, and tutorials online that help you optimize your website at every layer.
Performance – Core Domains
First, we have to understand that website performance can be divided into three domains. These areas each affect the speed of your website in different ways.
The basic performance principles for each domain can be delineated as follows:
Networking: Reduce distances
I don't even have words for this. GoDaddy is becoming an unstoppable behemoth, and that is scary. (And yes, I know where I'm saying this).
Authored by Daniel & Tony We are happy to announce that as of today Sucuri will be joining the GoDaddy family.
This acquisition will bring the best of both worlds. It will allow us to expand our product-line to all GoDaddy customers, while also remaining true to our foundation supporting all our current and future customers.
Since our inception our goal was simple: protect our customers websites – at all costs. This was built on the premise that every website owner should be able to deploy enterprise-grade security, without the enterprise-grade costs. Our approach to achieving this was to build things that delivered real value, while simultaneously staying ahead of the emerging threats.
Joining GoDaddy allows us to achieve this goal at a much larger scale than the one we are currently at. As a product company, this is the greatest challenge!
What Does this Mean for Sucuri?
We will continue to operate as is. What you can expect however are improvements to our processes and more resources to enable us to continue to invest in the things we love – our team, our customers and our product.
What Does this Mean for Sucuri Customers?
There are no changes to our customers.
This covers more details about security vulnerabilities in WordPress 4.7 & 4.7.1 that just got fixed in 4.7.2. Here its comes from Sucuri who contributed in this finding and a solid good responsible disclosure.
Security Risk: Severe Exploitation Level: Easy/Remote
DREAD Score: 9/10
Vulnerability: Privilege Escalation / Content Injection
Patched Version: 4.7.2
As part of a vulnerability research project for our Sucuri Firewall (WAF), we have been auditing multiple open source projects looking for security issues. While working on WordPress, we discovered was a severe content injection (privilege escalation) vulnerability affecting the REST API. This vulnerability allows an unauthenticated user to modify the content of any post or page within a WordPress site.
We disclosed the vulnerability to the WordPress Security Team who handled it extremely well. They worked closely with us to coordinate the disclosure timeline and get as many hosts and security providers aware and patched before this became public.
A fix for this was silently included on version 4.7.2 along with other less severe issues. This was done intentionally to give everyone time to patch. We are now disclosing the details because we feel there has been enough time for most WordPress users to update their sites.
Are You At Risk?
This privilege escalation vulnerability affects the WordPress REST API that was recently added and enabled
Scary story on nulled WordPress Plugin or Themes. This story tracks down the real culprit behind all of this and dig really deep.
If you have been following our blog for some time, you know that we regularly warn about risks associated with the use of third-party software on your site. A benign plugin may sneakingly inject ads into your site which cause malvertising problems for the site visitors (e.g. SweetCaptcha). Other plugins may be hijacked by hackers or black hat freelancers too (remember the epic story of Wooranker?). Another common issue is the use of so-called “nulled” premium themes and plugins that usually come with backdoors, hidden links, unwanted ads and even pure malware (e.g CryptoPHP or fake jquery scripts). This time I’ll tell you one more story that combines all the above mentioned problems: nulled plugins, black hat SEO, malvertising, and a software development company that turned to the dark side.
Suspicious gma_footer Code
Recently the lead of our remediation team, Bruno Zanelato, cleaned a site and found this piece of code in one premium WordPress plugin:
Suspicious gma_footer code
The encrypted part decodes to hxxp://cdn .gomafia[.]com. As you might expect, he investigated what’s going on there.
That gma_footer function was hooked to the wp_footer action. As a result,
Rather upsetting the reaction by MailPoet to Sucuri, sadly it won't harm their business perhaps as much as it should, makes you think Full Disclosure might be the way forward for WordPress plugins.
Many don’t know who I am. My name is Tony Perez, I’m the CEO of Sucuri. I have the pleasure of calling this company my family and everyday I work for every person at this company. My partner is Daniel Cid. He is one of the foremost thought leaders in the website security domain, his influence extending far beyond the communities that make up some of the most popular CMS applications today. Together we are building one of the fastest growing Website Security companies in the domain, we have one simple mission, to create a safer web. We are a technology company built by technologists with a special, quirky, idea that we can make a difference.
Many don’t realize that the bedrock of our business is Research, all facets of research. It’s how we stay ahead of the bad guys, or attackers. It’s a responsibility we have, not just to the general public, but one that we owe to our clients – in basic terms, it’s what they pay us for. It’s how we ensure our tools and technologies stay ahead of the rest and what makes us the ideal solution for every website owner, our commitment to the Website Security domain.
This has come to head recently from the huge debacle over the past few weeks in which we
[note: runs in command line, more suited for developers] -- Use WPScan to scan your site for known vulnerabilities within the WordPress core, plugins, and themes. You can also find out if any weak passwords, users, and security configuration issues are present. This tool uses the WPScan Vulnerability Database (wpvulndb.com). There's detailed tutorials on how to install it, and how to run a scan.
When using WPScan you can scan your WordPress website for known vulnerabilities within the core version, plugins, and themes. You can also find out if any weak passwords, users, and security configuration issues are present. The database at wpvulndb.com is used to check for vulnerable software and the WPScan team maintains the ever-growing list of vulnerabilities. Last time, we taught you how to install WPScan on Mac and Linux.
This time we are going to dive into how to use WPScan with the most basic commands.
Updating WP Scan
You should always update WPScan to leverage the latest database before you scan your website for vulnerabilities.
Open Terminal and change your directory to the wpscan folder we downloaded in the first tutorial:
From this directory we can run a command to pull the latest update from Github, and then another command to update the database.
ruby wpscan.rb --update
You will see the WPScan logo and a note that the the database update has completed successfully.
Scanning for Vulnerabilities
Next we are going to point the WPScan application at your WordPress website. With a few commands we can check your website for vulnerable themes, plugins, and
Krasimir highlights an aspect most of us have probably never considered a security issue - a plugin's domain !
Recently our incident response team had a case in which a website was redirecting users to an external domain. Ad pop-ups were displayed, and some were obviously malicious. For example, below is this Comcast tech support scam pop-up that tried to block a web browser and asked to call their number.
Flexytalk Widget Plugin
Read this article by Sucuri about a recent hacking attempt on WordPress site, and redirect website to adult site. Must read. Stay careful.
We write a lot about various blackhat SEO hacks on this blog and most of you are already familiar with such things as doorways, cloaking and SEO poisoning. This time we’ll tell you about yet another interesting black hat SEO attack that we’ve been watching for the last year. Let’s begin with symptoms:
When people click on search results in Google, Bing or Yahoo, they get redirected to porn sites. In all other cases the redirections cannot be triggered.
Only real legitimate pages redirect. No new doorways (as it usually happens in pharma and replica spam hacks) are created.
Not all real web pages redirect to porn (e.g. homepages almost never redirect) but those that do, redirect all the time.
This happens to all sort of sites: WordPress, forums, custom, and pure HTML sites.
When webmasters check code of the pages that redirect to porn sites (it’s quite easy to do on pure HTML sites) they do not find anything malicious there.
If they check the same pages with “Fetch as Google” (via Search Console) or in Unmask Parasites, they see that the pages have lots of porn keywords and blocks of 20 links to porn doorways on other similarly hacked sites.
In the blocks of spammy links, we regularly
Choosing the right WordPress Security Plugin can be an ordeal. The challenge however revolves around understanding what the WordPress Security Ecosystem looks
As a child, did you ever play that game where you sit in a circle and one person is responsible for whispering something into one persons ear, and that message gets relayed around the circle? Wasn’t it always funny to see what the final message received would be? Oh and how it would have morphed as it was processed and conveyed by each individual in the group. This is what I see when I look at the WordPress Security Ecosystem.
The biggest challenge the ecosystem faces is product / service confusion. This is compounded by a variety of factors. I often categorize them, generally into two buckets – deliberate and non-deliberate confusion. For me deliberate product confusion comes often by marketeers and those looking to make a quick buck on what they perceive to be the next virtual gold rush. While non-deliberate is being introduced by those that mean well, were once affected, and have come up with a genuine solution that likely addresses a very narrow issue.
An easy way to better appreciate this is to look at the WordPress Security Plugins specifically, as it’s tangible and easier to truly appreciate the nuances.
Contrary to popular belief, not all plugins are the same or created equal
Bad code written well. Hijack a plugin function, let it continue to work, this lets malicious code have a long life span before anyone notices.
Most authors of website malware usually rely on the same tricks, making it easy for malware researchers to spot obfuscated code, random files that don’t belong, and malicious lines injected at the top of a file. However, it can become difficult when the malware is buried deep within the lines of code on normal files. Why is some malware harder to spot than others?
An attacker’s primary goal is to retain access to an infected site, so they go to great lengths to hide their access methods. There may be hundreds of malicious files that are easy to find. As long as the attacker can regain access, ultimately reinfecting your website, it doesn’t really matter how clever they are in hiding the payload. It’s why it is so important to place extra emphasis in identifying the access vector, most often known as a backdoor.
Hijacking legitimate functions inside plugin files
Recently, we came across strange malware deep within a file, and hidden in an unusual way. The malicious code was hijacking a legitimate function inside the CForms plugin.
At first glance, this plugin file seemed benign because the flagged piece of code was not obviously malicious. On closer inspection, the original plugin function
This is an interesting article on the steps Sucuri takes to clean an infected website. It provides good insight into the thinking and steps involved as well as highlights preventative actions all site owners should take.
Question: How does Sucuri clean hacked websites? What is the process? We clean a lot of websites, ~ 400 / 500, daily during our normal load. To understand how we do it, you have to understand where it all comes from.
The biggest challenge with providing incident response services (remediation) on compromised websites is that a majority of website owners (webmasters) are not prepared. Most website owners lack security knowledge and fail to invest the time necessary to become familiarized with its concepts and how it’s applicable to their environment. They fail to get their websites ready for when, not if, an attack or disaster happens. In many instances, if the webmaster had been prepared, the entire remediation process would’ve been streamlined.
Being prepared can be as simple as having visibility (logging enabled), monitoring the logging activity and having a backup. While it would not stop the attacks, it would provide a solid foundation from which you can work from in the event of a compromise. These basics would do a lot for most website owners during the initial post-compromise phase. The phase in which we’re often engaged.
Because of this lack of data, it’s impossible to offer
Nice Sucuri posts on a hacking technique better than creating new admin users. A legitimate admin user will not be deleted during a cleanup.
When a site gets hacked, the attack doesn’t end with the malicious payload or spam content. Hackers know that most website administrators will clean up the infection and look no further. Many go on to patch vulnerable software, change their passwords, and perform other post-hack steps. All of this is good, but hackers who follow through the sustainment phase of the attack also leave behind ways to easily reinfect the site. After breaking into a website, hackers want to make sure they still have access if the original security hole is closed. Most often, they upload backdoors or create new malicious users. There is also a combination of the two approaches: login bypasses. These allow attackers to gain administrative rights without authentication by using a special parameter in the HTTP request.
WordPress Login Bypass
Recently, we found this buggy bypass code injected into a WordPress wp-login.php file.
Login bypass using the kidsid parameter
The request was placed inside legitimate comments, which made it more suspicious since this trick is only used by malware.
The purpose of this code is to provide an admin user ID for the kidsid parameter when requesting wp-login.php. This allows
Sucuri has identified active defacement campaigns targeting the REST API content injection vulnerability disclosed a week ago.
WordPress 4.7.2 was released two weeks ago, including a fix for a severe vulnerability in the WordPress REST API. We have been monitoring our WAF network and honeypots closely to see how and when the attackers would try to exploit this issue the wild. In less than 48 hours after the vulnerability was disclosed, we saw multiple public exploits being shared and posted online. With that information easily available, the internet-wide probing and exploit attempts began.
Patches are Not Being Applied
WordPress has an auto-update feature enabled by default and an easy 1-click manual update process, but unfortunately, not everyone is aware of this issue or able to update their site. This is leading to a large number of sites being compromised and defaced.
We are currently tracking 4 different hacking (defacement) groups doing mass scans and exploits attempts across the internet. We see the same IP addresses and defacers hitting almost every one of our honeypots and network.
If google is correct, these defacers seem to be succeeding.
Just for one defacer, which we call Campaign #1, Google alone shows 66,000+ pages compromised:
They started the exploits less than 48 hours ago. We
If you or your customers use WP Statistics (plugin is currently installed on 300,000+ websites) then read more about this discovered SQL Injection vulnerability.
Security Risk: Dangerous Exploitation Level: Easy/Remote
DREAD Score: 7/10
Vulnerability: SQL Injection
Patched Version: 12.0.8
As part of a vulnerability research project for our Sucuri Firewall, we have been auditing popular open source projects looking for security issues.
While working on the WordPress plugin WP Statistics, we discovered a SQL Injection vulnerability. This plugin is currently installed on 300,000+ websites.
Are You at Risk?
This vulnerability is caused by the lack of sanitization in user provided data. An attacker with at least a subscriber account could leak sensitive data and under the right circumstances/configurations compromise your WordPress installation.
If you have a vulnerable version installed and your site allows user registration, you are definitely at risk.
WordPress provides an API that enables developers to create content that users can inject to certain pages just using a simple shortcode:
[shortcode atts_1=”test” atts_2=”test”]
Among other functionalities, WP Statistics allows admin users to get detailed information related with the number of visits by just calling the shortcode below:
As you can see on
Factors When Put In Place Will Help Solidify And Secure Your WordPress Site From Hackers
Before you freak out, allow me to clarify. It was one of several honeypots we have running. The honeypots are spread across the most commonly employed hosting companies. From Virtual Private Servers (VPS) to shared environments, to managed environments. In most instances we pay and configure them like any other consumer would so that we aren’t given any special treatment. Honey Pot Systems are decoy servers or systems set up to gather information regarding an attacker or intruder into your system… A Honey Pot system is set up to be easier prey for intruders than true production systems but with minor system modifications so that their activity can be logged or traced. The general thought is that once an intruder breaks into a system, they will come back for subsequent visits. During these subsequent visits, additional information can be gathered and additional attempts at file, security and system access on the Honey Pot can be monitored and saved. – SANS
Our goal is simple; we want to better understand the dynamic nature of website security and continue to analyze and interpret attackers’ intentions. Having live sites that we allow to get hacked also keeps us sharp in terms of how
Nice information from a regular report from Sucuri looking at 9,000 infected websites. Looks like WP sites on a decrease overall, but half of WP sites still out of date.
Today we’re releasing our quarterly Hacked Website Report for 2016/Q2. The data in this report is based on compromised websites we worked on, with insights and analysis performed by our Incident Response Team (IRT) and Malware Research Team (MRT). CMS Analysis
Our analysis consisted of over 9,000 infected websites. The graphs below show a side-by-side comparison with our 2016/Q1 report.
The four open-source Content Management Systems (CMS) we focus on in our report include WordPress (78%), Joomla! (14%), Magento (5%), and Drupal (2%).
We dive into specific information about out-of-date software found on websites going through our cleanup process. Some interesting datasets include that WordPress installations were out-of-date 55% of the time while Joomla! (86%), Drupal (84%), and Magento (96%) continue to lead the way with out-of-date software.
We briefly cover specific extensible components within the WordPress platform. As it makes up the largest sampling in our environment (78%), we place special emphasis on the top three plugin vulnerabilities contributing to 22% of WordPress site hacks.
In this report, we also include a new telemetry dataset that shows the most popular WordPress
Fancybox-for-WordPress has a security hole and should be removed from your sites.
Our research team was alerted to a possible malware outbreak affecting many WordPress websites. All the infections had a similar malicious iframe from “203koko” injected into the website. We were also directed to a forum thread where users were sharing their concerns and describing similar issues they were experiencing. In analyzing the infected websites, we found that all the websites were using the fancybox-for-wordpress plugin.
Zero day in fancybox-for-wordpress
The fancybox-for-wordpress plugin is a popular WordPress plugin with more than 550,000 downloads. There doesn’t appear to be any public vulnerabilities being reported, which piqued our interest. To understand how it was connected, we decided to do our own code / vulnerability review.
After some analysis, we can confirm that this plugin has a serious vulnerability that allows for malware (or any random script/content) to be added to the vulnerable site. Because it is currently unpatched, we will not disclose more information.
What makes things worse, is that it’s being actively exploited in the wild, leading to many compromised websites.
We could confirm via our Website Firewall logs by seeing many exploit attempts blocked.
Sucuri announces vulnerability found and patched in the popular WP eCommerce plugin. The security hole is similar to the MailPoet risk discovered recently. Users of this plugin are highly advised to update asap. (Side note: I have no idea why Homer Simpson showed up as an image choice - but hey, why not)
Advisory for: WordPress WP eCommerce Plugin Security Risk: Medium (DREAD score : 6/10)
Exploitation level: Easy/Remote
Vulnerability: Information leak and access control bypass.
Patched Version: 220.127.116.11
If you’re using the popular WP eCommerce WordPress plugin (2,900,000 downloads), you should update it right away. During a routine audit for our Website Firewall (WAF), we found a dangerous vulnerability that could be used by a malicious user to easily get access and modify private information in the site.
The vulnerability allows an attacker to export all user names, addresses and other confidential information of any one that ever made a purchase through the plugin. It also allows an attacker to modify someone’s orders (e.g., non-paid to paid and vice versa). It was discovered and disclosed this week, the development team immediately patched by the WP eCommerce team. They also released the update 18.104.22.168 to fix this issue.
What are the risks?
Any WordPress based website running the WP eCommerce version 22.214.171.124 (or lower) are at risk. An attacker could perform administrative-related tasks without actually being authenticated as an administrator on the target website. Using this vulnerability,
CTO and Founder of Sucuri, Daniel B. Cid covers new brute force attacks exploiting XMLRPC in WordPress.
Brute force attacks against WordPress have always been very common. In fact, Brute Force attacks against any CMS these days is a common occurrence, what is always interesting however are the tools employed to make it happen. You create a website, because it’s super easy these days, publish the content and within a few weeks people try to repeatedly log in. These login attempts come from botnets, they are automated and their goal is simple “break into as many websites as they can by guessing their passwords.” Once they find one that matches, they take over of the site and use it to distribute malware, spam and similar activities.
Here is a small example, from our own honeypots, where we see hundreds of login attempts per day, trying various combinations:
user: admin, pass: admin
user: admin, pass: 123456
user: admin, pass: 123123
user: admin, pass 112233
user: admin, pass: pass123
The passwords may seem silly, but after going through the most common 200/300 dictionary passwords, they can get into many web sites.
Originally, these brute force attacks always happened via /wp-login.php attempts, lately however they are evolving and now leveraging the XMLRPC wp.getUsersBlogs
Rodrigo Escobar goes a good job showing off some techniques and provide in-depth technical knowledge on how to decode an advanced piece of malware.
When cleaning websites, one of the most complicated parts of our job is ensuring we find all backdoors. Most of the time, attackers inject code into different locations to increase the chances of reinfecting the site and maintaining access for as long as possible. Our research finds that in 67% of the websites we clean, there is at least one backdoor variant. Although we have hundreds of posts on backdoors and their effects, today we want to discuss a few techniques and provide in-depth technical knowledge on how to decode an advanced piece of malware.
This particular infection isn’t new but over the past few months, we have seen an increase in attacks against WordPress & Joomla using a related variant.
After compromising a website, attackers may inject backdoors, web shells, add bogus admin users, and more. A very common characteristic is that either one or more of the following techniques are employed to hide their code – encoding, encryption, and obfuscation.
In the following snippet, attackers added pretty much all three techniques. Let’s go step-by-step through the process of decoding it.
Simplifying the Code
When decoding, it’s very important
Yes, another day, another XSS vulnerability! You know what to do...
Any WordPress Plugin or theme that leverages the genericons package is vulnerable to a DOM-based Cross-Site Scripting (XSS) vulnerability due to an insecure file included with genericons. So far, the JetPack plugin (reported to have over 1 million active installs) and the TwentyFifteen theme (installed by default) are found to be vulnerable. The exact count is difficult to grasp, but both the plugin and theme are default installs in millions of WordPress installs. The main issue here is the genericons package, so any plugin that makes use of this package is potentially vulnerable if it includes the example.html file that comes with the package. DOM-based XSS
The XSS vulnerability is very simple to exploit and happens at the Document Object Model (DOM) level. If you are not familiar with DOM attacks, the OWASP group explain it well:
DOM-Based XSS is an XSS attack wherein the attack payload is executed as a result of modifying the Document Object Model (DOM) “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side