Today we are going to talk about something a bit less technical than our last post, but also very important for anyone that manages a website: how to detect and address file changes. Why? Well, reviewing your file changes is one of the best ways to detect and prevent your website from infections and hacking. When your website is hacked, the attacker or the malware could either change original files on your website or add new ones. Checking and monitoring any file changes on your server will allow you to take action right away in case anything suspicious happens. We’ll discuss how exactly how we can do that with more details in this post and share with you some tips and tricks for staying on top of changing files.
Fortunately, we don’t have to do this manually. Today there are tools like CodeGuard and many plugins that can help you track file changes automatically for sites built with WordPress, Joomla, Drupal, or anything else.
A little bit about hashing
To explain how file monitoring software works I’d like to first talk about cryptographic hash functions a.k.a. hashing. You might not know what this is, but I can assure that you have used it at least once in your life.
“A hash function is any function that can be used to map data of arbitrary size to data of fixed size” – Wikipedia
What a hash function does is produce a unique string of letters and numbers that represent the input file. If you’ve heard the terms checksum, digest or signature, the value that the hash function returns is similar. These functions are very common in the security world and they are used to validate integrity and authentication. The most common hashing algorithms are MD5 and SHA, which have many versions like SHA-1, SHA-2 and even SHA-3 which was released in 2015 by NIST. Although MD5 and SHA-1 are not considered safe anymore to be used as cryptographic hash functions, they are still widely used as a checksum to verify data integrity, which is exactly what we need here.
Recently, security researcher Dawid Golunski released an advisory describing a remote code execution vulnerability in the core of WordPress version 4.6 affecting the PHPMailer library. The vulnerability was published under CVE-2016-10033 and could be used by unauthenticated remote attackers against servers running WordPress with default web server configurations. In this post, we will summarize this advisory and explain the technical aspects of the vulnerability. To start, here is a short video of the exploit being executed by the researcher.
According to the WordPress Foundation, more than 40% of WordPress installations are still using versions 4.6 or older and could be vulnerable to this attack. If you are using WordPress, you should make sure to update to the latest version (4.8 at this time) as soon as possible!
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/