We have been working hard over the last few months to update the look and feel of the CodeGuard dashboard and are excited to announce today that it is available for everyone! Our goals were to implement the best practices in user experience for SaaS applications and streamline customer interactions. We talked with experts in the field and performed many usability reviews using a great tool called FullStory. This new theme will still provide all the functionality you know and love about CodeGuard with a more minimal and functional interface.
Same features, new navigation
One of the most noticeable changes we made was to improve the navigation. We rethought our information hierarchy and the result was that many navigation items were moved to more appropriate, easy to find locations. We also took special care to ensure that these changes would allow us to provide a similarly functional experience on smaller screens like phones and tablets. This new aesthetic will also ease the process of white labeling the application for hosting providers and resellers so that our partners can provide a seamless and integrated experience for their customers.
A fresh start!
We are very excited to share this new look with all of you! Over the last several years we have dedicated a tremendous amount of time and effort to providing industry-leading levels of backup reliability (99.999+%). We have applied that same kind of focus and rigor to our recent front-end changes. In our testing, we found that this new interface has succeeded in our internal goal of getting out of the way and allowing our customers to do what they need to do quickly, but we’re not going to stop here. Over the next several months we will be building on and extending this new interface as we add more features and functionality for all of you!
If you have any questions, comments or feedback we’d love to hear it! Please drop us a note in the Support Center.
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: