Trends Emerging Following Vulnerability In WP GDPR Compliance Plugin

Earlier this week the WP GDPR Compliance plugin was briefly removed from the 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 official blog. Republication of this post without permission is prohibited. You can find this post at:

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:



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:



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:


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:


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:
  • Cron Injection Method

Outbound Domains Accessed


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)


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 official blog. Republication of this post without permission is prohibited. You can find this post at:

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.


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 official blog. Republication of this post without permission is prohibited. You can find this post at:

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!


What’s a ghost’s favorite data type?



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

With a pumpkin patch.


Why are witches so good at deobfuscating malware?

They know hex.


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



“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 official blog. Republication of this post without permission is prohibited. You can find this post at:

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:



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 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

Video: WordCamp Atlanta Security Panel with Wordfence

In April, Wordfence sponsored WordCamp Atlanta and several of our team members attended the event. While there, we held a capture the flag (CTF) contest, which helps WordPress site owners learn to think like a hacker so that they can better defend their websites.

This post is Copyright 2018 Defiant, Inc. and was published on the official blog. Republication of this post without permission is prohibited. You can find this post at:

Part of hacker culture is the art of lock picking, which many of our team members do as a hobby. At WordCamp Atlanta, we taught many of the attendees to pick their first lock. Doing this is a great way to illustrate how it helps to think like your adversary when you are defending something. If you know how to pick a lock, you can better secure your home or office. Similarly, if you think like a hacker, you can better defend your WordPress websites. Our team does these demonstrations at every WordCamp we sponsor, and if you successfully pick a lock, we will award you a lock-pick set as a prize.

At WordCamp Atlanta, one of the scheduled speakers was unable to attend and our team volunteered to fill in. Four Wordfence team members participated in a panel, taking questions and discussing various WordPress security topics with the audience. Our panel consisted of:

Mark Maunder – CEO
Matt Barry – Lead Software Developer
Sean Murphy – Director of Threat Intelligence
Tim Cantrell – Customer Support Engineer

Aaron Campbell, the head of security for WordPress and an all-around great guy also makes an off-camera cameo. If you are interested in WordPress security and would like to get to know some of our best people a little better, I think you will really enjoy the conversation.



Video produced by nishasingh and originally published on

The post Video: WordCamp Atlanta Security Panel with Wordfence appeared first on Wordfence.

Read More

Introducing Wordfence Agency Solutions

Throughout 2018, we have had many conversations with agencies and other organizations protecting a large number of WordPress sites with Wordfence. You’ve told us what you need to be more successful, and we’ve responded with many changes to both our licensing and our capabilities.

This post is Copyright 2018 Defiant, Inc. and was published on the official blog. Republication of this post without permission is prohibited. You can find this post at:

To start, we added the ability to secure your staging and development environments with a single Wordfence premium license, something you should take advantage of if you have not done so already.

Introducing Wordfence Agency Solutions

Then we changed the way we handle volume discounts to make managing a large number of sites easier. We have a few additional changes coming, one of which we’re happy to announce today: Wordfence Agency Solutions.

With the new Wordfence Agency Solutions program, our client partners are empowered to create custom solutions to meet your specific needs. Our goal is to provide you with what you need to keep your clients safe and grow your business. Some of the services they might offer in your custom security solution include:

  • Auditing WordPress site security to identify and mitigate risk factors on sites.
  • Optimizing Firewall and Malware Scanner attuned to the needs of your sites.
  • Onboarding and Training to help your agency make optimal use of Wordfence.
  • Proactively Mitigating emergent security threats to keep sites safe.
  • Incident Response and Forensic Investigation in the event of an attack to minimize downtime and prevent recurrence.
  • Premium Support from our team of experts.
  • and a Dedicated Agency Partner who understands the particulars of your business needs.

Depending on your situation, you may also qualify for additional discounts.

The initial agencies who have enrolled in Wordfence Agency Solutions each faced unique challenges, and together we identified and implemented a resolution for each case. For example, we started one customer’s engagement with a thorough security audit for 50 of his customer’s sites. In addition to a number of smaller issues we learned that his hosting environment was in need of security improvements.

Our security analysts worked with him as he implemented their recommendations, including changes to his hosting configuration and an optimized implementation of Wordfence Premium. His customers’ sites are now much more secure, and he has the Wordfence security team available to help with any future security incidents.

Partner with Your Security Team

Because no other agency is just like yours, you need a solution reflecting your unique needs. No matter your size, capabilities and requirements, you’ll get to work with a dedicated Client Partner to determine your perfect solution. Our Client Partners are technically adept, have worked in agency roles managing large numbers of sites, and they live up to their title as a Client Partner. Whether you’re facing immediate security challenges or just looking for a streamlined way to offer excellent security to your clients, we’re here to help.

Working together with Wordfence Agency Solutions will help you leverage all that Wordfence has to offer, allowing you to focus on growing your business with the knowledge that your clients’ security is in good hands. This means fewer headaches for you, while giving your current and future clients the assurance that the security of their sites is a priority for your agency.

Qualifying is easy: you just need 20 or more sites in your care.

Learn more about Wordfence Agency Solutions! A client partner is ready discuss your goals.

The post Introducing Wordfence Agency Solutions appeared first on Wordfence.

Read More

Breaking Out of Shells at DerbyCon

I downloaded my first copy of BackTrack when I was 13. I had no idea what I was doing, or how to use it, but I knew that I was hooked. I’ve been fascinated with technology since I was a kid, so the idea that I could interact with that technology in new and unexpected ways was exciting. I followed my passion for technology into my adult life, but had always played it relatively safe. I got into satellite and other RF communications, then found myself working various IT roles. I worked my way up to an admin role for a hosting provider, decided it wasn’t for me, and found myself back where I originally started: information security. I began pursuing a career in InfoSec and rediscovered my passion for red team work, but felt disconnected from the community. I didn’t feel like I had the talent or experience required to get involved in any hackerspaces, and was holding myself back from interacting with other people like myself. This is a story of how I overcame that by doing something I’ve always wanted to do, but never had the social courage to take on: attend a security conference, and involve myself in a community that I’ve always admired from afar.

This post is Copyright 2018 Defiant, Inc. and was published on the official blog. Republication of this post without permission is prohibited. You can find this post at:

DerbyCon is a security conference that puts an emphasis on learning and collaboration, while also promoting hospitality and family values. It takes place in Louisville, KY each fall and ticket sales are limited in order to promote a more intimate and welcoming experience. Conceptualized in a pizza shop by a group of friends, the conference was intended for a community of peers, learning from one another. With so much thought clearly put into the conference planning, it seemed like the perfect opportunity for anyone looking to connect with the InfoSec community for the first time. None of us at Defiant had ever been to DerbyCon, so a few of us had the opportunity to check it out.

Upon my arrival I made the typical rounds, speaking to vendors and checking the clever swag they give out to attendees. As I explored the venue I noted the thought put into simple things, like the group-friendly seating in the main conference area and water coolers every twenty yards or so. The organizers certainly accomplished their goal of making attendees feel welcome, because after only an hour I was interacting and connecting with new people. It didn’t matter what they were doing, whether or not I was familiar with the technology, or what their title might be; each person I spoke with was excited to share their passion and knowledge, and was open to questions. I met many interesting and impressive people, and through our conversations I finally understood something that I’ve been repeatedly advised: everyone struggles with something, and that’s okay. The community is there to help, as long as you’re open and honest in those conversations.

Sitting in talks was a great way to be introduced to new ideas, techniques, and technology, because it removed the pressure of admitting when something was new. The talks available at DerbyCon spanned many subject fields, but they were kept to a reasonable number so that attendees rarely felt pressured to choose between two talks that held their interest. Whether you were into exploiting Ubiquiti networks and IOT devices, getting into buildings via bypassing physical security measures, Google dorking, or even some friendly social engineering, there was always something interesting going on in a track or a stable talk.

I visited each village in turn, and simply marveled at the amount of knowledge sharing and collaboration I witnessed. I saw locksmiths helping hobbyists learn how to use their new rake or plastic shim in the lockpicking village, and got the time to pick through a few locks myself. The vendors onsite were happy to show off the various tools and techniques employed by locksmiths, and offer advice to anyone struggling with a particular lock or tool. A short walk would take you to the car hacking village, the hardware hacking village, or even a room dedicated to ham radio and chess. The social engineering village offered a two-day panel with industry experts, as well as a Mission Impossible themed challenge that pitted volunteer contestants against obstacles like handcuffs, locks, and a laser grid. It’s no secret that our field contains a high percentage of individuals who struggle with mental health concerns like anxiety, depression, and imposter syndrome, so DerbyCon thoughtfully included a Mental Health Village. If the crowds became too much, it was a calm place to find your bearings, sip some tea, and maybe even sharpen your crafting skills.

A large portion of any conference will be the content provided in the talks, as well as the hands-on experiences gained by participating in the villages, and DerbyCon certainly delivered in those areas. One thing I didn’t expect was the global collaborative and accepting mindset that seemed to be shared by most. Walking through the halls, I saw people from different backgrounds, ideologies, and skill sets talking and working together. I overheard conversations where experienced developers or engineers were explaining programming theory to someone who’d never written a line of code. I saw physical intrusion and social engineering experts breaking down their techniques to people who spend most of their time behind a keyboard. It didn’t seem to matter what you knew, only that you wanted to learn.

It was great seeing Winn and the gang heckle teams brave enough to go onstage to compete in Hacker Jeopardy. The questions spanned a large range of topics, and several questions stumped the teams and had to be passed to the audience. Not answering in the form of the question would earn a little friendly humiliation, but answering correctly would earn a free shirt and roaring applause. This general mindset of being tough on issues and playfully tough on people, really took me out of my comfort zone, and allowed me to interact with others without feeling the need to explain myself. Once the doors closed for the day, groups spilled out onto the sidewalks, and into various restaurants and bars around town. The odd collections of professionals and enthusiasts carried their antics out into the public, where spirited debates and complicated conversations could continue to evolve organically. In my personal experience, many of those after-hours conversations held as much weight as any of the experiences I had within the conference walls. It was hard not to get swept up in everyone’s excitement with the novelty of it all, like the guy covered in neon broadcasting song lyrics as WiFi SSIDs.

Photo used with permission from @securid


“A trade show for practitioners” is a description that I heard from another attendee over the course of the weekend, and I couldn’t agree more. While I regret not getting involved in the community sooner, DerbyCon was exactly what I needed to break out of my own shell, and interact with others as passionate about security as I am. If you’re passionate about information security, and are concerned about involving yourself in the community for any reason, keep in mind that everyone is there to learn and collaborate. My advice for attending your first security conference: simply remain honest, open, and ready to learn and make connections with other people like yourself. I’d like to thank the organizers, speakers, and attendees for coming together to put together something that impacted me, and others like me, in such a meaningful way. I look forward to seeing you at the next con!

The post Breaking Out of Shells at DerbyCon appeared first on Wordfence.

Read More

Three WordPress Security Mistakes You Didn’t Realize You Made

Considering the amount of malicious activity that takes place on the internet, it’s no surprise that successful attacks on WordPress sites are launched across a wide variety of vectors. Whether outdated plugin code is to blame, or password reuse, or any number of other security flaws, no site owner sets out to introduce a vulnerability into their environment. Ultimately any security issue begins with a mistake, and while mistakes are forgivable there’s still risk involved if they’re not discovered and remedied.

This post is Copyright 2018 Defiant, Inc. and was published on the official blog. Republication of this post without permission is prohibited. You can find this post at:

In today’s post, we’ll look at a few common mistakes made by owners of WordPress sites that can create security concerns. These mistakes aren’t strictly application-specific, but are issues many WordPress users will encounter in the course of running their site.


Mistake 1 – Abusing Addon Domains

In the era of one-stop-shop customer experiences, it can be attractive for a WordPress design agency to be able to offer site hosting to their clients. However, when corners are cut in the implementation of such solutions, security flaws begin to surface.

Web hosts commonly make use of user-friendly control panels, like cPanel and Plesk, to improve the process of handling many server-side tasks for typical websites. Common operations like FTP user management and database setup can be done easily by just about anyone through a handy web interface. Many hosting companies running such control panels also allow their users to create and host multiple domains within a single account. In cPanel and most other contexts, these are called addon domains. With addon domains, a user can easily start and manage a number of sites without investing in separate hosting accounts for each of them. Many shared hosting providers encourage this use of addon domains, offering plans which allow users to run “unlimited” sites on a single account. However, misusing addon domains can create an insecure condition in the event that multiple users have access to the account–authorized or otherwise.

When a script on a webserver is accessed by a client, like a visitor requesting WordPress’s index.php file, the process is executed by a certain user account on the server itself. On typical WHM/cPanel servers, web processes are run as the user associated with the site’s cPanel account. Put another way, if I have a cPanel account with the username mikeyv and host three WordPress sites on it, every PHP process for each site executes as mikeyv on the server itself. This means that scripts running on one site have the ability to read and write files on other sites within the same cPanel account. Consequently, if those three WordPress sites each belong to a different one of my clients, it becomes possible for someone with file access to any one of the sites to influence the rest.

What’s The Problem?

There are two primary causes for concern with this particular mistake. First, in general this means that a disgruntled or otherwise troublemaking contributor to one of your addon domains can be disruptive (or worse) to other sites in your account. As long as they have FTP access or administrative permissions to their site, they can cause considerable damage to your account if they’re of a mind to. Even in cases where an FTP account associated with one of the addon domains may be jailed to its own site’s directory, if the user is able to upload a PHP file they can traverse the entirety of the cPanel account with a web shell or similar script.

The second cause for concern is in the case of a security incident. If one site is vulnerable and an attacker installs a backdoor, they now have complete access to further infect the rest of the sites you’re hosting. This scenario is a common one, and often results in cases of repeated reinfection. When the owner of the cPanel account is unaware of the scope of the infection, it’s common for the individual infected sites to be restored by their respective owners, allowing them to be immediately reinfected by scripts contained elsewhere in the account.

What Should I Do?

If you don’t host multiple sites within the same hosting account, you’re in the clear. If you do host multiple sites in one account, but you and other administrators are approved to access them all, just remain aware that any security issue for one site is an issue for all of them.

However, if you host multiple sites in the same account that belong to different clients, or each have different administrators, it should become a priority to get these sites isolated as soon as possible. While there are costs associated with maintaining hosting accounts for each client, it simply isn’t worth the risk to your business if an incident were to occur.

Mistake 2 – Unsafe Copying & Renaming

It’s always a good idea to make a backup of an important file if you’re making a risky change to it. After all, it’s already bad enough that something is getting tweaked on the live site, so you’d better make sure you can revert the change quickly in case it doesn’t behave as intended. The tricky part here is that depending on how you’re making the backup copy of that file, you could be exposing sensitive information about your site.

It’s fairly common to see these hastily-made copies of files given names ending in something like .bak or .old. For example, if someone is making a quick change to their site’s wp-config.php file, they might make a copy first and name it wp-config.php.bak. That way, later on they can easily identify the contents and purpose of the file in case they need to restore it.

What’s The Problem?

The issue here stems from the way your web server treats files based on their extensions. While there’s nothing inherently “magic” about file extensions like .php and .jpg, applications will typically use the extension as a way to interpret how a file should be handled. In particular, a web server is going to see a request to a file ending in “.php” and assume it contains PHP code to be processed locally. Once processed, the response sent to the client contains the output of the script, but not the code itself.

When a file is instead given an unknown extension like .bak, the server will need to fall back on default behavior in determining what to do if the file is requested by a client. In most cases, the default behavior will be to treat it as a download and simply send the requested file as-is to the client. This means if an attacker successfully guesses that our example site contains a file named wp-config.php.bak, they can download that file and read its contents, giving them access to database credentials and cryptographic salts.

Additionally, unsafe directory backup practices can allow highly vulnerable code to remain accessible on your site long after it would have been removed otherwise. For example, if you redesigned your site and left the old one in a subdirectory like /oldsite or /backup for some reason or another, those directories will still be accessible on the web. Any vulnerable code present in the defunct sites may still allow an attacker to breach your environment and infect your primary site.

What Should I Do?

Short answer, don’t leave files hanging around your WordPress environment when you no longer need them. In the cases where you must, though, just be sure to keep a file’s original extension at the end of the renamed file. To call back our example above, wp-config_backup.php is still a perfectly descriptive name which has the advantage of not being freely downloadable to anyone on the internet.

For the sake of completeness, yes, it’s possible to hack in some special handling for your .bak files into your site’s .htaccess or webserver configuration. With that said, it’s far outside the scope of this article, and still probably a better idea just not to use the unsafe extension to begin with.

Mistake 3 – Hosting Email On Your Webserver

The initial shopping stage of building a web presence can be tough. Eventually though, you nabbed a good deal for a hosting plan and–Score!–it came with unlimited free email accounts! You knew there were professional email solutions around, but you seriously can’t beat free.

Fast forward a bit, and now you’ve got a site pulling in a respectable amount of traffic, and a dozen or more inboxes belonging to members of your team. They use their email to talk to each other, send documents to clients, and receive any number of automated emails from various services.

What’s The Problem?

As we discussed in Mistake 1 above, all of the files in a cPanel account are owned by the same user. This user also happens to pass on its authority to any PHP scripts it executes. What many fail to realize is that the email inboxes within your cPanel account are all still just files living under that very same account ownership.

The practical implication of this situation is similar to the above. Any user with filesystem access on the account (whether it’s a legitimate FTP user, or a WordPress administrator, or a malicious intruder) can access the directory structure that contains all of the cPanel account’s mailboxes.

While the immediate privacy concerns of someone reading someone else’s email are obvious, the problem compounds when third-party services are considered. Effectively, this means that an attacker is able to perform password resets for accounts associated with the cPanel-hosted email addresses, since they can copy the email validation links out of the raw email file directly. This technique can allow the attacker to pivot from a web application breach to much larger scopes, depending on the kind of accounts associated with affected email addresses. Is your company Twitter account associated with one of these addresses? How about financial accounts?

What Should I Do?

If the email for your domain is hosted on a cPanel account (or any similar environment, as this isn’t necessarily a cPanel-specific problem), consider your use case carefully. If you’re running a hobby blog and just need a simple address, you’re probably okay as long as you’re aware of the risks. If you’re running a business of any notable size, though, it’s highly recommended that you seek out a standalone email solution in order to isolate mail from your webserver entirely.

Note that these warnings apply to typical shared environments, and individual systems may be configured more or less securely. Through use of open_basedir and disable_functions restrictions to prevent PHP from reading files outside of allowed directories or from executing system calls, it can be made more difficult for an attacker to access email hosted on the account. However, these measures are far from bulletproof and there are documented methods to bypass such restrictions. In general, it’s still a safer decision just to get the mailboxes onto a different environment.


Whether it’s the result of a hasty shortcut or honest inexperience, mistakes are bound to happen and don’t have to be the end of the world. Just be sure to remain mindful of the decisions you make in the process of running your website. Don’t cram a bunch of clients into the same hosting account, don’t leave sensitive files accessible to the web, and don’t keep your email where someone else could read it. Thanks for reading!


The post Three WordPress Security Mistakes You Didn’t Realize You Made appeared first on Wordfence.

Read More

Meet the Defiant Team

In August, most of our team attended DefCon, a hacker conference in Las Vegas attended by tens of thousands of security professionals. All of us work remotely, so it is always really special to spend time together as a team.

This post is Copyright 2018 Defiant, Inc. and was published on the official blog. Republication of this post without permission is prohibited. You can find this post at:

While we were there we completed a fun project. We created a video with footage from many of our team events and interviews of team members talking about what it’s like to work at Defiant. We’re really happy with how it turned out, and thought you might enjoy getting to know the team behind Wordfence a little better and how we work together to keep your sites safe.

The post Meet the Defiant Team appeared first on Wordfence.

Read More

Yes, You Should Probably Have A TLS Certificate

Last week’s article covering the decision to distrust Symantec-issued TLS certificates generated a great response from our readers. One common question we received, and one that pops up just about any time SSL/TLS comes up, is how to determine when a site does and does not need such a certificate. Spoiler: Your site should probably have a TLS certificate.

This post is Copyright 2018 Defiant, Inc. and was published on the official blog. Republication of this post without permission is prohibited. You can find this post at:

A subject of some discussion in the web community surrounds the use of TLS certificates and the implementation of HTTPS that these certificates allow. While their use is critical on sites where sensitive data from visitors may be involved, like payment data or other personally identifiable information (PII), the debate concerns the use of HTTPS in cases where users aren’t providing sensitive input. In today’s post, we’ll take a practical look at the difference between HTTP and HTTPS traffic, and discuss the benefits of being issued a certificate regardless of the way users interact with your site.

What’s TLS? Is It Different From SSL?

Before we really dig in, let’s clear up some terminology for anyone who might be unfamiliar.

HTTPS (short for Hypertext Transfer Protocol Secure) allows for the secure transmission of data, especially in the case of traffic to and from websites on the internet. The security afforded by HTTPS comes from the implementation of two concepts, encryption and authenticationEncryption is a well-known concept, referring to the use of cryptography to communicate data in a way that only the intended recipient can read. Authentication can mean different things based on context, but in terms of HTTPS it means verification is performed to ensure the server you’re connecting to is the one the domain’s owner intended you to reach. The authentication portion of the transaction relies on a number of trusted sources, called Certificate Authorities (CA for short). When a certificate is requested for a domain name, the issuing CA is responsible for validating the requestor’s ownership of that domain. The combination of validation and encryption provides the site’s visitors with assurance that their traffic is privately reaching its intended destination, not being intercepted midway and inspected or altered.

TLS, or Transport Layer Security, is the open standard used across the internet to facilitate HTTPS communications. It’s the successor to SSL, or Secure Sockets Layer, although the name “SSL” has notoriously picked up common usage as an interchangeable term for TLS despite it being a deprecated technology. In general when someone brings up SSL certificates, outside of the off chance they’re literally referring to the older standard, they’re probably talking about TLS. It’s a seemingly minor distinction, but it’s one we hope will gain stronger adoption in the future.

I Shouldn’t Use TLS Unless I Really Need To, Right?

There’s no shortage of conflicting advice across the web regarding when to implement TLS and when to leave a site insecure, so it’s no surprise that a lot of strong opinions develop on both sides of the issue. Outside of cut-and-dry cases like PCI compliance, where payment transactions need to be secure to avoid a policy violation, you’ll find plenty of arguments suggesting cases where the use of TLS is unnecessary or even harmful to a website. Common arguments against the wide use of TLS tend to fall into two general categories: implementation and performance.

Concerns about implementation difficulties with TLS, like the cost of purchasing a certificate, difficulty in setting up proper HTTPS redirects, and compatibility in general are common, but are entirely manageable. In fact, TLS has never been more accessible. Let’s Encrypt, a free certificate issuer which launched in early 2016, has issued just under two-thirds of the active TLS certificates on the internet at the time of this writing. Following the flood of free certificates into the marketplace, many popular web hosting companies have begun allowing Let’s Encrypt certificates to be installed on their hosted sites, or are at least including their own certificates for free with their hosting. After all, site owners are more security-conscious now than ever, and many will happily leave a host if TLS is a cost-prohibitive endeavor.

Other pain points in the implementation of HTTPS, like compatibility with a site’s existing application stack, are no different than the pain points you’d see following other security best practices. Put simply, avoiding the use of HTTPS because your site will break is the same as avoiding security updates because your site will break. It’s understandable that you might delay it for a period of time so you can fix the underlying issue, but you still need to fix that issue.

The other arguments against widespread TLS are those of performance concerns. There’s certainly overhead in play, considering the initial key exchange and the processing necessary to encrypt and decrypt traffic on the fly. However, the efficiency of any system is going to depend heavily on implementation. In the case of most sites, the differences in performance are going to be negligible. For the rest, there’s a wealth of information available on how to fine-tune an environment to perform optimally under TLS. As a starting point, I recommend visiting Is TLS Fast Yet? to learn more about the particulars of this overhead and how best to mitigate it.

My Site Doesn’t Take Payments, So Why Bother?

Each debate ultimately hinges on whether the site owner sees value in HTTPS in the first place. A lot of the uncertainty in this regard can be traced to unfamiliarity with the data stored in HTTP requests, as well as the route that these requests travel to reach their destination. To illustrate this, let’s take a look at the contents of a typical WordPress login request.

The request contains a number of interesting pieces of information:

  • The full URL of the destination, including domain and file path
  • User-Agent details, which describe my browser and operating system
  • My referer, which reveals the page I visited prior to this one
  • Any cookies my browser has stored for this site
  • The POST body, which contains the username and password I’m attempting to log in with

The implications of this request falling into the wrong hands should be immediately recognizable in the fact that my username and password are plainly visible. Anyone intercepting this traffic can now establish administrative access to my site.

Contrast this with the same request submitted via HTTPS. In an HTTPS request, the only notable information left unencrypted is the destination hostname, to allow the request to get where it needs to go. As far as any third party is concerned, I’m sending this request instead:

Outside of examples as obvious as login security, the thing to keep in mind above all is the value of privacy. If a site’s owner hasn’t installed a TLS certificate, even though the site is purely informational and takes no user input, any traffic to that site can be inspected by the user’s ISP, or even the administrator of the network they’re connected to. This is notably problematic in certain cases, like when someone might be researching private medical or legal matters, but at the end of the day the content of a site is irrelevant. Granted, my hat probably contains a bit more tinfoil than most, but there’s no denying this is an era where browsing habits are tracked wherever possible. Real examples exist of ISPs injecting advertising into unencrypted traffic, and the world has a nonzero number of governments happy to inspect whatever traffic they can get their hands on. Using HTTPS by default shows your site’s users that their privacy is important to you, regardless of whether your site contains anything you might consider private.


The internet at large is rapidly adopting improved security standards, and the majority of web traffic is now being delivered via HTTPS. It’s more important than ever to make sure you’re providing your users with the assurance that their traffic is private, especially with HTTP pages being flagged as “Not Secure” by popular browsers. Secure-by-default is a great mindset to have, and while many of your users may never notice, the ones who do will appreciate it.

Interested in learning more about secure networking as it pertains to WordPress? Check out our in-depth lesson, Networking For WordPress Administrators. It’s totally free, you don’t even need to give us an email address for it. Just be sure to share the wealth and help spread the knowledge with your peers, either by sharing this post or giving them the breakdown yourself. As always, thanks for reading!

The post Yes, You Should Probably Have A TLS Certificate appeared first on Wordfence.

Read More
Page 10 of 1,020« First...«89101112»203040...Last »