Privilege Escalation Vulnerability in WordPress

On February 1st, 2017, Sucuri Security disclosed a 0-day vulnerability in WordPress. If you are running WordPress version 4.7.0 which was released on December 6, 2016, or 4.7.1 which was released on January 11th, 2017, you should stop reading and go update immediately!

The disclosure describes the privilege escalation vulnerability which was found in the core of WordPress, affecting the newly updated feature: the REST API. This vulnerability could allow anyone to modify any post or page on a WordPress site without even being authenticated! Pretty scary, right? Good thing this issue was found by security researchers!

They responsibly disclosed the flaw to WordPress Security on January 20th and they fixed it right away, making a silent patch on version 4.7.2, which was released on January 26th, 2017, and protecting anyone who performs automatic updates on their sites. The WordPress Security Team has also reached out to several companies with WAF products including SiteLock, Cloudflare, and Incapsula to help them create rules in their tools to protect their customers and make sure no harm would be done until the fix was released. After that, WordPress hosting providers were alerted about this issue, how the vulnerability worked and how to protect their customers’ sites.

This vulnerability affects the WordPress Rest API. According to the security researcher who discovered the vulnerability, one of these REST endpoints (WP_REST_Posts_Controller) allows anyone to access to view, edit, delete and create posts via the API. The REST API was added and enabled by default on version 4.7.0, leaving versions 4.7.0 and 4.7.1 vulnerable to this flaw!

Type Juggling

The flaw in the WordPress REST API works due to a “feature” in PHP, also present in some other languages, called type juggling.  It allows the developer to silently change the values of one type to another. Since PHP doesn’t require explicit type definition in a variable declaration, that feature is permitted. What does that mean? It means that when comparing a string to a number, PHP will attempt to convert the string to a number then perform a numeric comparison. If you are comparing a string like “123CODEGUARD” to an integer variable, only the numbers will be used for the comparison operation.  Watch the examples below:

The problem is that PHP has two comparison modes: loose and strict. Loose comparisons have a set of operand conversion rules to make it easier for programmers, unfortunately even PHP developers admit that “[it] may not be obvious exactly what will happen when casting between certain types.” Although PHP type-juggling bugs are very common, they are difficult to exploit because you are usually not able to input typed data over HTTP. Unfortunately, that was not the case with the WordPress REST API.

WordPress REST API Code

Let’s go back to the WordPress code now. More specifically the code inside /wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php file, where they found the input validation issue in the update_item function. In this function, the input validation issue that could allow a privilege escalation by a malicious user is the first line of code where they are type-casting the ID from the request to the $id variable. According to this, it would be possible to submit a request to the REST API like /wp-json/wp/v2/posts/123?id=999STRING, which would result in the id variable being set to 999.

 

Function update_item in class-wp-rest-posts-controller.php file – WordPress 4.7.1

The WordPress Team fixed this in version 4.7.2 by ensuring that the id input is not coerced and is validated prior to proceeding:

Fixed function update_item in class-wp-rest-posts-controller.php file – WordPress 4.7.2

PoC in the wild

As you can imagine since the disclosure of this flaw there are already exploits in the wild being used to target this problem. A video was made and uploaded to Youtube explaining how it the vulnerability works and how to exploit it. You can watch it here:

Some security researchers also published a few Proof of Concept (PoC) tests to check if your site is vulnerable. Here is one from Larry Cashdollar, who works at Akamai:

Another PoC from Leon Jacobs can be found at his GitHub: https://gist.github.com/leonjza/2244eb15510a0687ed93160c623762ab

Stay up to date

This is a serious vulnerability that can be misused to compromise a vulnerable site. Make sure your WordPress installation is up to date and be safe!

References

Disclosure of Additional Security Fix in WordPress 4.7.2

https://blog.sucuri.net/2017/02/content-injection-vulnerability-wordpress-rest-api.html

https://blogs.akamai.com/2017/02/wordpress-web-api-vulnerability.html

MalwareGone Threat Analysis – PHP Ransomware

Today we’re going to explore a newer type of threat: Ransomware or, more precisely, PHP Ransomware. Ransomware attacks have increased greatly over the last few years and many variations have been made and are still being used in the wild. First, we should define what we mean when we talk about Ransomware. We’re specifically talking about a piece of code or software that encrypts your files in place and demands a ransom payment to receive the key that decrypts your files. So, if you are the victim of a ransomware attack and do not have recent, verified backups you could be in trouble! You have no other way to retrieve your files besides paying the ransom unless the ransomware is an old one and security companies have already created the software that decrypts it. If you are curious, here is a list of Ransomware Decryptor Tools: http://www.thewindowsclub.com/list-ransomware-decryptor-tools (use at your own risk!)

How does a ransomware infect a computer?

Traditional Ransomware usually affects personal computers and is delivered by email or infected websites. Whether in an email attachment or served from a hacked website, possibly using drive-by download techniques, the payload may disguise itself as a PDF, Flash, Adobe or Java update or some other type of executable. According to this PhishMe Q1 2016 Malware Review report, 9 out of 10 phishing emails sent in March 2016 carried a ransomware payload. Read the full report here: http://phishme.com/phishing-ransomware-threats-soared-q1-2016/

phishme_phishing_email_ransomware_stats

Read More “MalwareGone Threat Analysis – PHP Ransomware”

MalwareGone Threat Analysis – MulCiShell Backdoor and File Uploader – Part II

This is the second part of our exploration MulCiShell Backdoor and File Uploader, a malicious PHP Web Shell that was detected on a customer’s website using CodeGuard’s MalwareGone tool. If you haven’t already, take a look at Part I before continuing. In this post, we’ll wrap things up by discussing the vulnerabilities that were found on this site, which may have allowed the MulCiShell Backdoor and File Uploader to be inserted. To pick up where we left off before, here is a list of installed WordPress plugins installed on the hijacked site:

codeguard-malwaregone-pluginsfolder

 

A search on the WPScan Vulnerability Database reveals a number of public vulnerabilities for some of these plugins. Here are a few examples:

  1. WordPress Plugin: Akismet

Version installed: 3.0.4

Vulnerability:  Unauthenticated Stored Cross-Site Scripting (XSS)

Versions affected: Akismet 2.5.0-3.1.4

Source: https://wpvulndb.com/vulnerabilities/8215

2. WordPress Plugin: iThemes Security (formerly Better WP Security)

Version installed:  5.6.1

Vulnerability: Unauthenticated Stored Cross-Site Scripting

Versions affected: <= 5.6.1

Source: https://wpvulndb.com/vulnerabilities/8635

Read More “MalwareGone Threat Analysis – MulCiShell Backdoor and File Uploader – Part II”

MalwareGone Threat Analysis – MulCiShell Backdoor and File Uploader – Part I

For this installment, we’ll talk about a webshell called “MulCiShell”, more specifically the “MulCiShell v0.2” backdoor file, which is a PHP Web Shell that we found in another client’s website using CodeGuard’s MalwareGone tool. Here is a snippet of code for this webshell:

codeguard-malwaregone-mulcishell

If you’d like the full version of the file you can find a copy on GitHub.

Doing a little bit of research we found that the first versions of this webshell dates back to 2009, which is really old for malware like this, but it seems that the developer of this backdoor has been maintaining it as it keeps getting updated with new capabilities and enhancements. As we can see this webshell has many functions and there’s even a changelog in the comment at the top of the file. This specific version was last updated by someone nicknamed KingDefacer.

Read More “MalwareGone Threat Analysis – MulCiShell Backdoor and File Uploader – Part I”

MalwareGone Threat Analysis – WSO FilesMan Backdoor

Note: This is the first post in a series of in-depth investigations into threats that have been detected by the CodeGuard MalwareGone tool. In each post, we will pick a specific kind of malware, trojan, virus, backdoor, rootkit, etc. to dissect and discuss. We will also provide manual removal instructions at the end, just in case you’re not yet using CodeGuard.

For this inaugural post, we will be looking at a modified version of the WSO FilesMan backdoor, which is a PHP webshell designed to control the whole system. Here is just a piece of the PHP file that was named prbnts.php and located in the /wp-includes/js/jquery/ui/ folder, which usually only holds JavaScript files (.js):

<?php
eval(gzinflate(base64_decode("5b37W9tG0zD8c+7r6v8gVLeyG2NsQ9IUsBNCICEHSDkkaSCv
(...)
?>

As you can see, the file is encoded in base64 and compressed with the PHP core gzdeflate function. When we decode and decompress the file we get something more readable:

$color = "#df5";
$default_action = 'FilesMan';
$default_use_ajax = true;
$default_charset = 'Windows-1251';

if(!empty($_SERVER['HTTP_USER_AGENT'])) {
  $userAgents = array("nouseragenthere");
  if(preg_match('/' . implode('|', $userAgents) . '/i', $_SERVER['HTTP_USER_AGENT'])) {
    header('HTTP/1.0 404 Not Found');
    exit;
  }
}

 

This gives us some clues that file is malicious and shouldn’t be there. Even if you aren’t tech savvy, just searching for the first four lines on Google will show you some hints that this file is a backdoor and the first findings date back to the end of 2010. More specifically, the malicious file is a PHP Web Shell, or just PHP Shell, which is a shell wrapped in a PHP script and it uses built-in PHP functions to execute commands on the system. With it, we can do basically anything on the server where it is located like upload or download files, install, run or delete programs and sometimes even create or delete users, depending on the web server’s user permissions. It is a bit similar to having an SSH (Secure SHell) connection to the server. Can you imagine the damage this could do? If you have your web shell on a server you literally “own” it. Now you know why people say someone got owned when their site gets hacked!

Read More “MalwareGone Threat Analysis – WSO FilesMan Backdoor”

CodeGuard Launches Sandbox Staging™: Staging Servers for WordPress Developers

ATLANTA, GA. (September 13, 2016) – CodeGuard, Inc. (www.codeguard.com), the global leader in cloud website backup services announced today a new feature, Sandbox Staging™, which instantly creates test environments for customers with WordPress websites.

Sandbox Staging

“Developers and designers know that they should be using a staging environment for the websites and applications they manage, update, or otherwise contribute to. It’s a widely accepted best practice”, says CTO Jonathan Manuzak. “The reason that many do not is that it’s a time-consuming and technically complex process to set up and maintain one of these environments. We saw an opportunity to simplify this for customers by leveraging our technical expertise and unique position in the market.”

CodeGuard manages a dynamic fleet of servers that perform more than 11 million backups per month and process 450 million API requests over the same time period. 260 Terabytes (TB) are transferred daily, and nearly 100 Petabytes (PB) are transferred annually. Operating at this scale in a reliable, performant and cost-effective way has forced the company to develop industry-leading practices for infrastructure container management and automation. “Combining our world-class infrastructure expertise with the foundational CodeGuard backup product to create a feature that allows our customers to work faster, reduce risk and adhere to best practices? That’s a winning proposition for everyone involved”, says Manuzak.

Sandbox Staging™ will allow customers to test work on a staging site and utilize CodeGuard’s backups to create the staging environment almost instantly. With the click of a button, a new server will be provisioned to host the content stored in the backup repository. Now customers can experiment away from production, test new versions of WordPress safely, explore new plugins, and do all of this without downtime or risk to the production site.