At CodeGuard, we have the privilege of partnering with some of the best hosting and web service providers in the business. Some of these partners refer customers to CodeGuard.com to sign up, but others offer our service to their customers through an API-driven integration. With this kind of arrangement, partners interact with CodeGuard through our REST APIs to create new customer accounts, configure backups, generate Single Sign-On links and more. This provides a great experience for customers and allows our partners to offer CodeGuard at scale.
We do our best to make our backup solution as reliable as possible and integrated partners work hard to streamline the customer experience by automating the process of configuring websites and databases for backups on our platform. However, as the customer base grows, the partner platform is updated and customers make adjustments to their own accounts, issues affecting CodeGuard backups can arise.
The .htaccess file is a hidden text file used by the Apache web server to configure your website without the need to create or modify global server configuration files. It is usually located in the root folder of the website but can be in other locations as well, depending on what files and folders do you want to be affected by the specified configuration.
This file contains a series of “directives,” similar to those in traditional Apache web server configuration files. Usually, these directives are key-value pair commands indicating if a configuration should be on or off, but they can be more complex. The .htaccess file allows anyone in control of a particular set of website content to execute many directives which can change the behavior of that site, without access to Apache’s global httpd.conf.
Why is it important?
This file is very important to your website as it can affect the availability and the security of your site or application. In this post, we are going to focus on the security functions of .htaccess although it is important to understand that using a .htaccess file on your server might cause your site to load more slowly, negatively impacting your visitors, and adds complexity to your website or application setup.
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!
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:
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/
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:
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:
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.