Ninja Forms Security Updates: What You Need To Know

Yesterday, the popular WordPress plugin Ninja Forms released version 3.3.14, which disclosed and patched two security issues present in the plugin. Upon review of these issues we’ve determined their severity to be moderately low, however due to the plugin’s wide userbase of more than a million active installs we’ve elected to provide a detailed exploration of exactly what these vulnerabilities are and what risks they do pose if left unpatched. As usual, we recommend updating vulnerable versions of the plugin as soon as possible, despite the relatively low risk.

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/08/ninja-forms-security-updates-what-you-need-to-know/

Cross-Site Scripting (XSS) In Import Function

The first security issue we’ll look at can be found in the WordPress Vulnerability Database as Ninja Forms <= 3.3.13 – Cross-Site Scripting (XSS) in Import Function.

Ninja Forms contains Import/Export functionality which allows privileged users to create a form within the plugin, then save the configuration of that form in a portable .nff file downloaded to their local machine. This file can be used as a backup, migrated to other sites, etc. On import, the text data in the .nff file is parsed and converted into a functional web form.

Because the content of this imported file is ultimately converted into an HTML web form, it’s possible for a user to craft a working .nff file which contains malicious JavaScript code. When the form is displayed, this JavaScript can execute within the browser of anyone viewing the form. Because the Import/Export tool is only available to site administrators, this isn’t necessarily a vulnerability by itself, since if an attacker secured administrative access to the WordPress site they’d be able to install whatever malicious content they had regardless.

However, in unpatched versions of the plugin, it can be possible for malicious actors to manipulate a site administrator into unknowingly importing a bad .nff file. By crafting a link or redirect, or otherwise getting a logged-in administrator to visit an unsafe page, a Ninja Forms import can be triggered regardless of if the administrator has the Import page open at all.

A formatted example of a malicious field in an .nff payload.

If this import successfully triggers, the XSS payload will launch in the browser of any user who views the malicious form. Unless the shortcode for the malicious form is placed on a page or post of the affected site, this is generally limited to only affecting logged-in users who preview the form within their WordPress dashboard.

The patch for this issue adds a nonce to the Import function in the Ninja Forms, which prevents malicious redirects from triggering the import, as the administrator will need to have opened the import page and uploaded the file themselves.

What is Cross-Site Scripting (XSS)?

Cross-Site Scripting refers to the practice of injecting malicious code (nearly always JavaScript) into a web page or application with the intention of the payload executing in the browsers of a site’s visitors or administrators. Flaws in vulnerable applications commonly render user input without sanitizing it first, allowing code to be inserted in unexpected ways.

For further reading on XSS flaws, what they are, and how to prevent them, check out How to Prevent Cross Site Scripting Attacks.

What Should I Do?

Once you’ve updated Ninja Forms, take a moment to ensure there are no unknown forms on your site by clicking the Ninja Forms link in the sidebar of your WordPress dashboard (again, you must be logged in with an Administrator account to see this). If there are no unfamiliar forms present, no further action is required.

In the event that you do confirm a malicious form is present, you can delete it from the list of forms by clicking the cog-wheel icon in the rightmost column of its row, then clicking Delete and following the subsequent prompt. Do not click into the form to see what’s inside, as you run the risk of launching a malicious JavaScript payload. 

CSV Injection

The second vulnerability can be found on the WordPress Vulnerability Database as Ninja Forms <= 3.3.13 – CSV Injection.

Unrelated to the Import/Export functionality which allows the forms themselves to be exported, Ninja Forms also includes an Export function for users to archive the submissions to their forms in a .csv file, which can then be opened in a user’s spreadsheet software of choice. It behaves as you’d expect: the value in each field of a submitted form gets placed in its own cell in the spreadsheet, one row per submission.

In unpatched versions of Ninja Forms, if a user submission contains a CSV injection payload in any form fields, the exported .csv file has the potential to perform unsafe actions if opened as a spreadsheet.

What is CSV Injection?

Discussing CSV injection vulnerabilities in the context of web security is tricky, and requires some understanding of what exactly takes place.

Spreadsheet software like Microsoft Excel and LibreOffice Calc allow cells to be populated by a number of different elements. The most common are simple text and numeric values, but it’s likely that you’re also familiar with inserting formulas instead of static values.

Cell C1 displays the value “3”, but is actually a formula that sums the values of A1 and B1.

What many people may not be aware of are the sheer variety of things one can actually accomplish with this sort of syntax. Hyperlinks can be created, data from the affected spreadsheet and other open sheets can be exfiltrated, and system commands can even be executed.

The reason CSV injection is a tricky subject is because there isn’t really an agreement on where the finger should be pointed when it comes up. Fundamentally, the malicious execution takes place within the spreadsheet software itself, which is usually happy to parse and execute any function it sees. However, the argument from the other side is that automatic formula expansion works as intended, and untrusted input should be sanitized before being exported to a .csv document in the first place.

That said, in 2014 LibreOffice Calc and OpenOffice Calc both removed the DDE command execution functionality which allows this sort of command execution. Microsoft Excel instead implemented a warning dialogue, which prompts users to only allow execution if the file came from a trusted source. There’s a pretty strong issue here, though, because who doesn’t trust their own website? Outside of the fact that it’s well-known that most users are happy to click “allow” on any security pop-up they get on their computer, it’s less likely than usual that a user will know to block the execution.

An example of the security prompt triggered by Microsoft Excel.

Any application that generates spreadsheets has the potential to create unsafe files if input from untrusted users is involved. This, combined with the fact that many bug bounty programs (including HackerOne’s own bounty program for its sites) explicitly exclude CSV injection flaws from the scope of their programs, make it a unique issue for the security community at large. Since the concept of CSV injection itself is less a vulnerability in any one piece of software than it is a flaw in the way spreadsheet logic is handled globally, it’s a tough one to squash.

Back On Subject

The original patched version of Ninja Forms sanitizes potentially malicious form fields when they’re exported to a .csv file by prepending a single quote ' to any cell whose value begins with an equals sign =. This effectively prevents any spreadsheet formula from executing when rendered. However, the OWASP recommendation for mitigating CSV injection recommends additionally sanitizing cells beginning with the characters @, +, and -, as certain systems and software may have similar rendering behavior associated with these characters.

With this in mind, I reached out to Zach Skaggs, product owner of Ninja Forms, in order to discuss potentially hardening this patch to prevent these edge-case evasions. Zach was already aware of these alternate characters, and originally determined after some testing that their exploitability was too low to be of concern. While the likelihood of these evasions being successfully implemented in the wild is indeed very low, after some discussion Zach agreed it was worth implementing a patch for these to be safe. A few hours ago at the time of this writing, Ninja Forms 3.3.14.1 was released, which adds this extra hardening.

What Should I Do?

If you’ve performed a CSV export of your Ninja Forms submissions prior to this patch, make sure that no values in any of the cells begin with the characters =, @, +, or -. You will need to perform this review via text editor or command line, as opening the file in spreadsheet software has potential to perform unsafe actions. You can also export a new CSV from a patched version of Ninja Forms to safely replace old exports if you wish.

Conclusion

Despite the potential for harm that can be caused by allowing a malicious spreadsheet document to execute, the flaws patched by Ninja Forms are of low severity. Successful exploitation of both vulnerabilities rely on a number of outside factors:

  • Successfully triggering an import of a malicious .nff file requires some level of interaction by a logged-in administrator of an affected site.
    • If a malicious .nff file is imported, the resulting form needs to then be viewed for the script to execute.
  • Successful implementation of the CSV injection vulnerability requires an administrator to eventually perform a CSV export, which isn’t a behavior an attacker can rely on or predict.
    • If an export is executed, most practical CSV injection payloads are specific to the spreadsheet software in use and the operating system it’s running on. While “Microsoft Excel On Windows” is the most likely combination, the increasing popularity of operating systems like OS X and Linux, as well as open source office software like OpenOffice and LibreOffice, makes this an attack unlikely to be launched outside of very targeted engagements.

To learn more about the cause of these sorts of vulnerabilities, and how to prevent them from popping up in your code, check out our educational series Understanding PHP Vulnerabilities & How They Originate.

The post Ninja Forms Security Updates: What You Need To Know appeared first on Wordfence.

Read More

Wordfence: Live On Tour In A City Near You

This year we’ve attended and sponsored quite a few WordCamps, and have had members of our team speak at some as well. If you haven’t attended one recently we highly recommend it. They’re a great opportunity to learn and connect with other members of the WordPress community.

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/08/wordfence-live-on-tour-in-a-city-near-you/

WPCampus Highlights

While not strictly a WordCamp, in July we sponsored and attended WPCampus, “a community and conference for web professionals, educators and people dedicated to the confluence of WordPress in higher education.” We work with many educational institutions throughout the world to protect their WordPress sites, so sponsoring and attending the conference was a great opportunity to connect with our users face to face and introduce Wordfence to those who haven’t discovered us yet.

The Wordfence table was lively throughout the event, with Mikey giving impromptu lock picking lessons and Kathy going deep on how to protect WordPress at scale.

Mikey teaching lock picking to a WPCampus attendee

 

If you’re tasked with securing WordPress for a college or university and missed WPCampus, consider setting up some time with Kathy to discuss how best to leverage Wordfence to tackle the unique challenges you’re facing.

Those who attended the conference were treated to a presentation, “What the hack? Fortifying your security by understanding your adversary”, by our very own Mikey Veenstra. He is one of the Threat Analysts on our team who are responsible for developing the malware signatures and firewall rules that keep your sites safe. The WPCampus team was kind enough to capture the presentation and publish it on YouTube. We think you’ll enjoy it.

Upcoming WordCamps

WordCamp Minneapolis – this weekend

Through tomorrow (August 25th), we are attending and sponsoring WordCamp Minneapolis. Tim, Matt and James from our team are there manning the Wordfence table and running a capture the flag contest. We’re giving away great prizes including a Sony Playstation with a VR Bundle. Most of you probably know Tim from his years providing excellent support on our customer service team. Matt and James are both software developers on our team.

The Wordfence table at WordCamp Minneapolis

 

WordCamp Omaha  –  Sunday (8/26)

Our very own Brad Haas, Wordfence’s Senior Security Analyst, will be speaking tomorrow at WordCamp Omaha. His presentation, “Hacking War Stories (and what you can learn from them)”, is going to be really fun.

WordCamp New York – September 15 & 16th

Our Director of Information Security Colette Chamberland and Chloe Chamberland from our Security Services Team will be presenting “How to Optimally Secure Your WordPress Environment” on Saturday, September 15th at WordCamp New York.

WordCamp Sacramento – September 15th & 16th

We will be sponsoring and attending WordCamp Sacramento. Mark Maunder, our CEO, will be attending along with Kathy Zant, a Client Partner on our team. We will be running a capture the flag contest with great prizes. Kathy will be giving a talk titled “Evaluating Plugins: Strategies To Effectively Extend WordPress”, don’t miss it!

WordCamp Los Angeles – September 21st & 22nd

We will be sponsoring and attending WordCamp Los Angeles. A number of us will be attending and we will be running a capture the flag contest.

WordCamps Later in the Year

They’re still in planning stages, but we’re planning to attend quite a few WordCamps this fall. You will most likely see us in Vancouver, Orlando, Seattle, Portland and a few other cities. Stay tuned for more updates.

The post Wordfence: Live On Tour In A City Near You appeared first on Wordfence.

Read More

Announcing Revamped Volume Pricing for Premium Licenses

This year we have been very focused on the needs of agencies and other organizations with lots of sites to protect. We’ve spoken with many of you and have a clear picture of what we can do to make Wordfence work even better for you.

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/08/revamped-volume-pricing-premium-licenses/

To start things off, in June we released a feature that makes Premium licenses work seamlessly across development, test and staging domains. We’ve gotten tremendous feedback on it so far and encourage you to take advantage of it if you haven’t already.

The latest change we’ve made addresses what is probably the most common piece of feedback we receive from organizations that manage lots of sites. We’re changing the way we handle volume discounts. We have always offered volume discounts, but your discount was based solely on the number of licenses you purchased, and for how many years, during a single transaction. That worked well for us for a long time, but based on your feedback it was clear we needed to make a change.

Volume discounts for license purchases are now based on your total active license count, including what you’re buying today. For example, if you already have 5 licenses and want to purchase 2 more today, your discount is based on a total of 7. The table below shows our new volume discount rates:

Active License Count Discount % Price Per License
1 0% $99.00
2-4 10% $89.10
5-9 15% $84.15
10-14 20% $79.20
15+ 25% $74.25

 

If you are currently a Premium customer this means that any purchase you place going forward qualifies for a discount, regardless of how many licenses you purchase.

We are also offering incentives for purchasing additional years. Currently you will receive an additional 10% discount on your transaction if you purchase a 2 year license and 20% for 3.

Renewal prices for your new licenses are also based on your active license count. As you purchase more licenses, the discount applied to your renewal prices goes up.

Your old licenses won’t change… unless it’s in your favor

With this change we wanted to make sure that we didn’t raise prices for the licenses you already own. Your renewal price for licenses purchased before July 24th of this year will not change, unless your active license discount qualifies you for an even lower price. In that case we will automatically charge you the lower price. And as long as they’ve been installed on a website they count toward your active license count, improving your discount for new license purchases and lowering the renewal rate for your newer licenses.

More is on the way

Our team is currently hard at work on a major feature that will make managing and monitoring Wordfence across multiple sites much, much easier. We haven’t set a launch date yet, but you should see it within a few months. If you’d like early access I highly recommend signing up for our beta program.

Need help managing Wordfence at scale?

Our new Client Partner program was created with agencies and organizations with high profile sites to protect in mind. Set up a free 15 minute consultation today to learn how we can help you protect your sites with Wordfence.

 

 

 

The post Announcing Revamped Volume Pricing for Premium Licenses appeared first on Wordfence.

Read More

Known WordPress Threat Actor Under Investigation For Prescription-Free Online Pharmacy

Last September we published a series of three blog posts exposing a threat actor who had purchased a number of WordPress plugins as part of an elaborate supply chain attack. This ownership enabled him to inject SEO spam into hundreds of thousands of websites, boosting search engine rankings for various illicit online businesses.

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/08/known-wordpress-threat-actor-under-investigation-for-prescription-free-online-pharmacy/

In the first post we reported that a backdoor had been placed in the Display Widgets plugin by its author. We demonstrated how the backdoor worked and its purpose. We also found evidence that the plugin had recently been sold.

In our second post the following day, we were able to identify the man behind the plugin spam, Mason Soiza. We were also able to tie him to another plugin we had written about back in August of 2016, 404 to 301, which had also been used to inject SEO spam into websites. With the aid of the original plugin authors we were able to gather comprehensive information about the purchases. We were also able to tie Soiza to some of the illicit businesses the SEO spam was benefitting.

We continued our research and published a third and final post a week later. In it we were able to tie together a 4.5 year campaign impacting 9 WordPress plugins, all used by Mason Soiza to serve SEO spam on victim websites. These WordPress supply chain attacks caught the community by surprise.

The Times and BBC Take Things Further

Last week The Times published an article focused on the website UK Meds, which is owned by none other than Mason Soiza. According to The Times, the site is under investigation by regulators for selling prescription medications, including highly addictive opioid painkillers, to customers without a prescription. Customers need only complete a free “online consultation”, which is reviewed by a doctor in Romania.

A spokesman for Mason Soiza who was referenced in The Times article, “[…] accepted that he had bought WordPress plugins and inserted code but disputed that this was malicious code and denied he was a spammer.” The article also suggests the business has been profitable enough to allow Mr. Soiza to purchase a £215,000 Lamborghini and a £100,000 watch.

On Monday, the BBC Panorama series covered the topic of online pharmacies in the UK (linked content only accessible from the UK). Mason Soiza’s site UK Meds is among the four online pharmacy sites profiled.

In the episode, five volunteers order prescriptions, most of which could prove fatal for them. Three of them ordered opioid-based painkillers, one diet pills and another antibiotics. All five were able to successfully place their orders online by answering online questions dishonestly and receive the medications. In the most touching part of the episode, a mother whose son died as the result of a drug overdose is interviewed. Dependent on the drugs, he was able to buy them online for two years after his doctor had cut him off.

They also go undercover to talk to the owner of EuroRX, who explains how online pharmacies can leverage doctors in Romania to circumvent prescription requirements.

Protect the Community by Keeping Your Site Secure

We were happy to see both The Times and BBC take this story further. What they uncovered serves as an important reminder that the people behind the attacks on our websites are generally up to no good. It might just be a website to you, but to a criminal it’s an important resource they can use to further their agenda. Unfortunately, that agenda sometimes includes potentially deadly activities. We can all do our part to help keep the community safe by keeping our sites secure and out of the hands of criminal actors.

The post Known WordPress Threat Actor Under Investigation For Prescription-Free Online Pharmacy appeared first on Wordfence.

Read More

Brad Haas Discusses BabaYaga Malware on the CyberWire Podcast

In early June we published an article and accompanying white paper detailing an interesting malware infection which we’ve internally dubbed BabaYaga. The relatively sophisticated malware is unique because it contains a number of features intended to ensure the infected site remains in working order. It keeps WordPress core up to date, performs and stores backups and even scans for and removes malware.

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/07/baba-yaga-cyberwire-podcast/

Brad HaasOn Saturday one of our Senior Security Analysts and the author of the BabaYaga white paper, Brad Haas, sat down for an interview with Dave Bittner on the CyberWire podcast. We think you’ll really enjoy the 20 minute interview. Simply click play below to hear it. If you prefer a written version a full transcript is available here.

As always we’d love to hear your thoughts and questions in the comments.

The post Brad Haas Discusses BabaYaga Malware on the CyberWire Podcast appeared first on Wordfence.

Read More

Your Site Can Help Defend Millions Of Others

As you’re probably aware, Wordfence’s Security Services Team (SST) provides world-class remediation services in the event that your site falls victim to malicious activity.  Our analysts combine their considerable expertise with the best threat intelligence in the industry to deliver results we’re consistently proud to stand behind. To be clear, the word “consistently” is used deliberately here, as the continued reliability of our services is crucial in maintaining the trust placed in us by our users.

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/07/your-site-can-help-defend-millions-of-others/

An early struggle with consistency was in handling the volatility of our order volume, where peak volumes would sometimes impact the quality of our service. Limiting these situations became an immediate priority, and in April we introduced ‘high demand’ pricing to better ensure that we never compromise on quality. At the same time, we integrated the SST and Customer Service teams and completely revamped our internal processes to align with this trajectory.

The results of these changes were dramatic. The improvements allowed us to introduce discounted prices during periods of lower demand, which we rolled out in May. Our motivation to discount rates extends beyond pure economics, though, because each closed case is about more than money to us.

Helping Future Victims

Our ability to protect Wordfence users from new and more sophisticated attacks hinges on our ability to absorb the latest intelligence into our Threat Defense Feed. Each incident responded to by our SST analysts advances this process–whether by discovering new or mutated malware samples, contributing forensic data to broader investigations, or by revealing the presence of new threat actors–and directly improves the security of millions of websites as a result. Offering temporary discounts during periods of low volume is an easy choice when it means stimulating an uninterrupted flow of high-value threat intelligence.

We know the immediate aftermath of a WordPress compromise is always a stressful time, and understand that the improved security of the rest of our users isn’t terribly compelling when you’ve got your own situation to take care of. With that in mind we offer thanks to all of our SST customers, whether for responding to a hacked site or performing a site security audit, by including a free one-year license for Wordfence Premium. With an active Premium subscription your site will immediately benefit from up-to-date threat intelligence, where the data gathered from your own case and others like it can be put to work defending your site from future attacks.

Wait No Longer

At this time, the SST’s volume allows us to offer a 30% discount on site cleaning and security audit services. If you believe your site has suffered a successful attack, or are interested in having our experts check under the hood to identify future concerns, there’s no better time to get in touch.

You’ll be joining a network of websites which have all contributed to the improved security of your web presence, and what we learn from your case will in turn go on to help those who need it in the future. Whether we’re publishing analyses of emerging malware trends or using our collected data to identify popular infection vectors, we’re committed to providing the best security solutions in the industry, and we’re thrilled to have your help.

The post Your Site Can Help Defend Millions Of Others appeared first on Wordfence.

Read More

Three Incident Response Preparations You Should Be Making

In the context of cybersecurity, the adage “An ounce of prevention is worth a pound of cure” is a massive understatement. Make no mistake, the easiest way to handle a security incident is to prevent it from ever happening in the first place. We continually remind our readers about security best practices because the time spent implementing them is nominal compared to the time that would be spent responding in the aftermath of a successful attack.

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/07/three-incident-response-preparations-you-should-be-making/

The unfortunate reality, however, is that sites continue to fall victim to malicious activity every day. Even perfectly responsible site owners who follow every security guideline in the book need to prepare for the possibility of a critical security incident. Similar to household emergency readiness preparations, like owning an appropriately classed fire extinguisher or keeping a first aid kit, there are a few favors you should be doing for yourself as a site owner to help you get back on your feet in the event of a disaster.

Logs Or It Didn’t Happen

When an owner hears for the first time that their site has been compromised, the first question on their mind is usually the same: How? It’s a natural response, and it’s a question that security firms are commonly brought in to investigate. Forensic review of the breached system can provide answers in some cases, but the efficacy of these efforts frequently hinges on the existence of reliable event logs to be reviewed.

Server logs provide investigators with a dataset they can use to establish a timeline of events leading up to and during an attack. By identifying the activity taking place and its source, it can be possible to determine the scope of the compromise. That intelligence is how you can know whether an attacker had access to your users’ data or if you simply fell victim to a defacement campaign, and being able to confidently disclose these details to your users can be crucial in dampening the impact to your business’s reputation following an attack.

Log retention policies seldom come up in the conversations between new site owners and their prospective hosting companies, so it’s possible to unknowingly be a step behind in this process based simply on your site’s provider. If a host has an opt-in logging policy, or defaults to very short log periods, in all likelihood an inexperienced user will have no usable logs of a security event by the time they’ve been made aware of the issue.

Just how long to retain server logs for security purposes depends heavily on your industry and location. Industry compliance regulations may demand retention minimums or specific destruction timeframes, and regional regulations can introduce their own requirements. If you believe that your site might fall under such restrictions, consult with a legal expert familiar with your particular case. Otherwise, the amount of log history to maintain depends on how closely you monitor your site in other ways. If a site doesn’t see much attention under the hood it’s much more likely that a compromise can go undetected for months, so lower-maintenance sites might opt to retain logs longer to shore up that disadvantage a bit.

If your site is running on shared web hosting, take a moment to identify how your host handles access logging. Standard cPanel-based hosting accounts are becoming more and more common and default to a functional logging policy unless the host enforces changes, but proprietary hosting solutions may not play so nicely in every case. Either way, ensure that you’re able to archive and retain logs for an appropriate amount of time for your needs.

If your site lives on a server you have more direct control over, you can really roll up your sleeves and set up your logging however you like. For example, your run of the mill Linux webserver is probably making use of logrotate to manage the storage and archival of various logfiles. Logrotate leans on a fairly simple scripting syntax to build rotation rules, so it’s easy to configure retention policies for just about any purpose. Windows servers typically handle event logs directly, so there isn’t as much to worry about on a private Windows system in terms of storage and rotation.

If You Have One Backup, You Have No Backups

If the scope of an attack isn’t conclusively determined, or if a compromise has left a site owner uncertain of the continued integrity of their environment, it often becomes necessary to revert to a known-good backup of the site. This also facilitates the process of migrating a site from a compromised server to a new host while minimizing the potential to include infected code in the migration.

Of course, an owner’s ability to restore a site from backup depends entirely on whether they were making the backups to begin with. This, again, is a problem many unfortunate business owners fail to identify until it’s too late to be of use. Maybe they assumed their hosting provider was handling their backups for them, or that their site was so stable that they’d never need backups to begin with. Either way, a site needs backups.

To be clear, we’re using the plural “backups” very intentionally. Your filesystem and database contents are typically changing constantly, especially with a dynamic web application like WordPress running the site, so as backups get older they begin to lose usefulness. At the same time, having backups across a span of time can help ensure there’s a clean backup if a breach went unnoticed for too long.

There’s a commonly repeated guideline for backups called the 3-2-1 rule which suggests keeping three copies of your data, on two different media, with one off-site. It’s a pretty basic guideline, one which has been around for a while and may be due for a revamp in the age of cloud storage, but its basic tenets are sound. You can pull the numbers from the rule and still end up with sound advice: Keep redundant copies of your data, diversify how your data is stored, and make sure at least some backups are accessible regardless of the nature of the disaster.

One point that the 3-2-1 rule does fail to address is the need to test your backups. The aftermath of a cyberattack is the worst possible time for you to learn that your backup script broke five months ago. Periodically check your backups for integrity and watch closely for errors reported by any automated scripts you’re running. For critical systems, consider performing complete disaster recovery tests by spinning up a temporary server and restoring a backup to a running environment.

It sounds boring, but spending the time every now and then to make sure your backups are reliable brings with it a great deal of peace of mind. Simply put, it’s better to have them and not need them than to need them and not have them.

Hope For The Best, Plan For The Worst

While there are precautionary measures in place to prevent fire hazards in an office building, the workers in the building need to know there are fire alarms and an emergency exit plan just in case. By the same token, the members of your organization need to have a security incident response plan in place to ensure the issue is handled appropriately.

Depending on the size of your business, your incident response plan can be as simple as a sheet of instructions or a massive PDF document with diagrams and walkthroughs. Regardless of size, this document should clearly establish at least these few important pieces of information pertinent to the immediate aftermath of an incident:

Who is the person or team in charge of responding to security incidents?
Include any relevant contact information. If you retain the services of a third party team for your security, be sure to make note of who is authorized to contact them.

Which other parties need to be involved in which situations?
Above a certain scale, where your infrastructure relies on multiple teams, the security team handling the incident may not be directly familiar with the affected systems. Identify who needs to be called for each system, so your incident handler knows how to contact your database administrator for a database breach without pinging your entire IT staff.

What defines success in your response?
The key is to have measurable goals. These goals could be to limit service disruptions, or to publish a public disclosure of the event within a certain timeframe, et cetera.

Are there any mandatory steps that need to be taken?
If your region or industry imposes disclosure timeframes or other incident handling regulations, put these in plain language in your plan. Assign ownership of these steps to relevant parties to ensure they don’t slip through the cracks.

Include this information alongside details of where backups and logs are stored, and any other information that may be pertinent to your organization’s response. Having a predefined plan accessible to your team allows your organization to hit the ground running after a successful attack takes place, where time is critical. Even if your team is small and the contents of a plan could probably just be assumed, putting it on paper helps to remove any ambiguity in what is already a stressful event.

Conclusion

A common thread in the world of security advice is that any effort you’re able to give is going to be more effective than not doing anything. Even if you don’t have the capital to implement a redundant and scalable automated backup strategy for your site, you can at least set a reminder to yourself to pull a backup of your site down to a local drive once a week. Just put something into place sooner rather than later, because you can always improve it further down the road.

The post Three Incident Response Preparations You Should Be Making appeared first on Wordfence.

Read More

Details of an Additional File Deletion Vulnerability – Patched in WordPress 4.9.7

Today WordPress released version 4.9.7, a security release which addresses two separate arbitrary file deletion vulnerabilities requiring Author privileges. Some details can be found on the WordPress.org blog.

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/07/details-of-an-additional-file-deletion-vulnerability-patched-in-wordpress-4-9-7/

The first arbitrary file deletion vulnerability was disclosed June 26, 2018 on the RIPS Tech blog with no official patch to WordPress in place. We released a firewall rule the same day to protect Wordfence users from attacks against this vulnerability.

A Second Vulnerability Discovered

After developing a proof of concept of the attack to aid in writing the Wordfence firewall rule, we decided to have a closer look at the code used to create and delete attachments. During this review, we discovered a second arbitrary file deletion vulnerability exploitable by authors. We released a Wordfence firewall rule to our Premium customers on July 2nd to protect against this vulnerability.

The details of the second vulnerability are as follows: In WordPress core, there is an “upload-attachment” AJAX action used by the media uploader. The AJAX call will handle the file upload and pass an array of additional data about the attachment to wp_insert_post, since media attachments are a specific post type within WordPress.

function wp_ajax_upload_attachment() {
    
    ...
    
    // Post data from user input.
	$post_data = isset( $_REQUEST['post_data'] ) ? $_REQUEST['post_data'] : array();

	// If the context is custom header or background, make sure the uploaded file is an image.
	if ( isset( $post_data['context'] ) && in_array( $post_data['context'], array( 'custom-header', 'custom-background' ) ) ) {
		$wp_filetype = wp_check_filetype_and_ext( $_FILES['async-upload']['tmp_name'], $_FILES['async-upload']['name'] );
        
        ...
        
	}

	$attachment_id = media_handle_upload( 'async-upload', $post_id, $post_data );

The vulnerability lies in the way wp_insert_post populates the meta data for the attachment. The path to the attachment file is stored in the meta key _wp_attached_file. By supplying post_data[meta_input][_wp_attached_file] in the request to the “upload-attachment” AJAX action, we can pass in ../../wp-config.php which WordPress will treat as the attachment file.

Similar to the first arbitrary file deletion vulnerability, when an author deletes this attachment, the wp-config.php is deleted allowing the author to go through the initial WordPress installation process which allows them to fully compromise the site.

WordPress Releases a Fix in 4.9.7

The WordPress security team has just released version 4.9.7 which addresses both of these issues by performing some additional checks before deleting attachment files. Specifically, they have added the function wp_delete_file_from_directory which they use to verify the file is within the uploads directory before deleting it.

/**
 * Deletes a file if its path is within the given directory.
 *
 * @since 4.9.7
 *
 * @param string $file      Absolute path to the file to delete.
 * @param string $directory Absolute path to a directory.
 * @return bool True on success, false on failure.
 */
function wp_delete_file_from_directory( $file, $directory ) {
	$real_file = realpath( wp_normalize_path( $file ) );
	$real_directory = realpath( wp_normalize_path( $directory ) );

	if ( false === $real_file || false === $real_directory || strpos( wp_normalize_path( $real_file ), trailingslashit( wp_normalize_path( $real_directory ) ) ) !== 0 ) {
		return false;
	}

	wp_delete_file( $file );

	return true;
}

Timeline

  • 2018-06-29 11:26 AM (-500) – Initial report of second arbitrary file deletion vulnerability submitted to WordPress security team.
  • 2018-07-02 1:14 PM (-500) – Firewall rule released to Wordfence Premium customers to address second vulnerability.
  • 2018-07-05 12:00 PM (-500) – WordPress releases version 4.9.7 which fixes both vulnerabilities.

What To Do

We strongly encourage you to update to 4.9.7 as soon as possible. If you have automatic updates enabled, your site should update within the next 24 hours. Automatic updates are enabled by default in WordPress for minor releases.

Credits: Congrats to Matt Barry, our lead developer at Wordfence for finding this vulnerability and writing up technical details. Thanks to Mikey Veenstra for editing this post. As always, thanks to the WordPress security team for being super responsive and for their hard work helping secure WordPress core.

The post Details of an Additional File Deletion Vulnerability – Patched in WordPress 4.9.7 appeared first on Wordfence.

Read More

Optimizing Wordfence Security Settings: Brute Force Protection

As a part of the Wordfence Client Partner initiative, we’ve recently had some in depth conversations with organizations using Wordfence at scale. These conversations have been enlightening, and we wanted to share some of the stories we’ve heard about how different organizations use Wordfence.

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/07/optimizing-wordfence-security-settings-brute-force-protection/

Wordfence is the most robust security solution available for WordPress site owners, and the number of security features available is unparalleled. This ensures that Wordfence can be customized to be an optimal security solution for your specific environment and security needs.

Wordfence Brute Force Protection

Getting Started with Wordfence

When you install Wordfence for the first time, the plugin defaults to recommended settings that are a perfect starting place for customization. You won’t need to do much else. However, Wordfence is highly configurable, allowing you to tailor how it works to meet your needs.

How our Customers Use Brute Force Protection:

Wordfence includes a number of powerful brute force protection features that can be used to prevent malicious bots from gaining access to your site, including the integration with Troy Hunt’s version 2 of the Pwned Passwords API that prevents access using passwords previously seen in a breach. In this post we will focus on Brute Force Protection and how our customers can customize this feature, based on their security needs.

Factors to consider when modifying your site’s Brute Force Protection settings include:

  1. How adept are your users? Do you have users that forget their passwords often? Are they logging in sporadically and have a high probability of losing their passwords? You’ll want to take them into consideration and allow room for user error.
  2. Is this a high traffic, high profile site that often experiences hacking attempts?
  3. Is your site under repeated attack from brute force attempts?

The following customer scenarios serve as great real-world examples of how Wordfence can be customized to meet specific needs.

Kyle’s Agency Customer Site

One of our agency partners, Kyle, manages a number of WordPress installations for his customers. His customers rarely perform any administrative tasks, but they have editor access in order to add and modify new content. The agency has administrator access, and they have set up Wordfence Premium to protect the site. In addition to the premium features of country blocking and two-factor authentication for administrators only, he has tightened Brute Force Protection. Some of his customers often forget their passwords, and he wants to ensure they can still access the site to post content without causing too much administrative work for his team.

Kyle sets up his sites so that failed logins lockout after 5 attempts, forgot password attempts are set to 10 and a user is locked out for 24 hours. He does not set the site to immediately lock out invalid usernames, but he immediately blocks anyone who uses ‘admin’, ‘administrator’, or any other failed logins he sees. He routinely audits his site’s failed logins and adjusts this setting accordingly.

brute force protection

Maria’s Membership Site

Maria uses Wordfence on a WordPress membership site. She has a team of publishers and administrators and a large number of members who need to login in order to access content. Some of them use good password hygiene, but others do not. Maria’s site is also protected by Wordfence Premium, and she has made some adjustments to her brute force protection settings.

Maria has set her failed logins lockout to 5 attempts, forgot password attempts are set to 10, and a user is locked out for 24 hours. She does not set the site to immediately lock out invalid usernames because she has a large user base. She immediately blocks anyone who uses ‘admin’ or ‘administrator’, but does not go further than that. She uses Wordfence Premium’s two-factor authentication and some minor country blocking to augment her site’s security.

brute force protection

Dave’s Personal Site

Dave has a personal blog. He has one login for himself and no other users. He knows his password, and also has access to FTP in order to easily deactivate Wordfence if he ever locks himself out. He has tightened his Brute Force Protection settings because he’s quite confident in his ability to store his password safely.

Dave sets up his sites so that failed logins lockout after 2 attempts, forgot password attempts are set to 3, and IP addresses that reach these limits are locked out for one month. He immediately locks out any invalid users and also immediately blocks anyone who uses ‘admin’, ‘administrator’, or any other failed logins he sees.

He also uses two-factor authentication to ensure that logging in is difficult for anyone other than himself should his credentials ever be discovered.

brute force protection

Sam’s Small e-commerce Site

Sam has a small e-commerce site that is growing rapidly. He has a number of contractors on the site updating product information. He has users that need to login for various business functions and needs to ensure that everyone can log in, but doesn’t want to risk his site’s security given how sensitive e-commerce data is. He’s invested in Wordfence Premium and requires his administrators to use two-factor authentication for logging in.

Sam sets up his sites so that failed logins lockout after 5 attempts, forgotten password attempts are set to 5, and a user is locked out for 4 hours. He does not set the site to immediately lock out invalid usernames. He has set his Wordfence installation to block any passwords from data breaches to anyone who can publish as well as administrators because of the turnover in the contractors he is using to update product information.

brute force protection

How are you using Brute Force Protection?

We hope this deeper look at our Brute Force Protection settings has been helpful. If you’ve been using Wordfence for a while, how are you using Brute Force Protection? Are there rules you’ve set that work well for your unique site requirements?

Are you seeing any new brute force attack patterns that concern you? Let us know in the comments.

We’ll be covering more ways that our customers use Wordfence in upcoming posts.

The post Optimizing Wordfence Security Settings: Brute Force Protection appeared first on Wordfence.

Read More

Optimizing Wordfence Security Settings: Brute Force Protection

As a part of the Wordfence Client Partner initiative, we’ve recently had some in depth conversations with organizations using Wordfence at scale. These conversations have been enlightening, and we wanted to share some of the stories we’ve heard about how different organizations use Wordfence.

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/07/optimizing-wordfence-security-settings-brute-force-protection/

Wordfence is the most robust security solution available for WordPress site owners, and the number of security features available is unparalleled. This ensures that Wordfence can be customized to be an optimal security solution for your specific environment and security needs.

Wordfence Brute Force Protection

Getting Started with Wordfence

When you install Wordfence for the first time, the plugin defaults to recommended settings that are a perfect starting place for customization. You won’t need to do much else. However, Wordfence is highly configurable, allowing you to tailor how it works to meet your needs.

How our Customers Use Brute Force Protection:

Wordfence includes a number of powerful brute force protection features that can be used to prevent malicious bots from gaining access to your site, including the integration with Troy Hunt’s version 2 of the Pwned Passwords API that prevents access using passwords previously seen in a breach. In this post we will focus on Brute Force Protection and how our customers can customize this feature, based on their security needs.

Factors to consider when modifying your site’s Brute Force Protection settings include:

  1. How adept are your users? Do you have users that forget their passwords often? Are they logging in sporadically and have a high probability of losing their passwords? You’ll want to take them into consideration and allow room for user error.
  2. Is this a high traffic, high profile site that often experiences hacking attempts?
  3. Is your site under repeated attack from brute force attempts?

The following customer scenarios serve as great real-world examples of how Wordfence can be customized to meet specific needs.

Kyle’s Agency Customer Site

One of our agency partners, Kyle, manages a number of WordPress installations for his customers. His customers rarely perform any administrative tasks, but they have editor access in order to add and modify new content. The agency has administrator access, and they have set up Wordfence Premium to protect the site. In addition to the premium features of country blocking and two-factor authentication for administrators only, he has tightened Brute Force Protection. Some of his customers often forget their passwords, and he wants to ensure they can still access the site to post content without causing too much administrative work for his team.

Kyle sets up his sites so that failed logins lockout after 5 attempts, forgot password attempts are set to 10 and a user is locked out for 24 hours. He does not set the site to immediately lock out invalid usernames, but he immediately blocks anyone who uses ‘admin’, ‘administrator’, or any other failed logins he sees. He routinely audits his site’s failed logins and adjusts this setting accordingly.

brute force protection

Maria’s Membership Site

Maria uses Wordfence on a WordPress membership site. She has a team of publishers and administrators and a large number of members who need to login in order to access content. Some of them use good password hygiene, but others do not. Maria’s site is also protected by Wordfence Premium, and she has made some adjustments to her brute force protection settings.

Maria has set her failed logins lockout to 5 attempts, forgot password attempts are set to 10, and a user is locked out for 24 hours. She does not set the site to immediately lock out invalid usernames because she has a large user base. She immediately blocks anyone who uses ‘admin’ or ‘administrator’, but does not go further than that. She uses Wordfence Premium’s two-factor authentication and some minor country blocking to augment her site’s security.

brute force protection

Dave’s Personal Site

Dave has a personal blog. He has one login for himself and no other users. He knows his password, and also has access to FTP in order to easily deactivate Wordfence if he ever locks himself out. He has tightened his Brute Force Protection settings because he’s quite confident in his ability to store his password safely.

Dave sets up his sites so that failed logins lockout after 2 attempts, forgot password attempts are set to 3, and IP addresses that reach these limits are locked out for one month. He immediately locks out any invalid users and also immediately blocks anyone who uses ‘admin’, ‘administrator’, or any other failed logins he sees.

He also uses two-factor authentication to ensure that logging in is difficult for anyone other than himself should his credentials ever be discovered.

brute force protection

Sam’s Small e-commerce Site

Sam has a small e-commerce site that is growing rapidly. He has a number of contractors on the site updating product information. He has users that need to login for various business functions and needs to ensure that everyone can log in, but doesn’t want to risk his site’s security given how sensitive e-commerce data is. He’s invested in Wordfence Premium and requires his administrators to use two-factor authentication for logging in.

Sam sets up his sites so that failed logins lockout after 5 attempts, forgotten password attempts are set to 5, and a user is locked out for 4 hours. He does not set the site to immediately lock out invalid usernames. He has set his Wordfence installation to block any passwords from data breaches to anyone who can publish as well as administrators because of the turnover in the contractors he is using to update product information.

brute force protection

How are you using Brute Force Protection?

We hope this deeper look at our Brute Force Protection settings has been helpful. If you’ve been using Wordfence for a while, how are you using Brute Force Protection? Are there rules you’ve set that work well for your unique site requirements?

Are you seeing any new brute force attack patterns that concern you? Let us know in the comments.

We’ll be covering more ways that our customers use Wordfence in upcoming posts.

The post Optimizing Wordfence Security Settings: Brute Force Protection appeared first on Wordfence.

Read More
Page 3 of 1,012«12345»102030...Last »