Ask Sucuri: How Do You Find Website Backdoors?

How To Find and Remove Hidden Website Backdoors

                                <br><a href="">Source link </a>
Three Incident Response Preparations You Should Be Making

Three Incident Response Preparations You Should Be Making

This entry was posted in General Security, Learning on July 10, 2018 by Mikey Veenstra   5 Replies

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.

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.

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

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.

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.

Did you enjoy this post? Share it!

4.86 (21 votes)
Your rating:

                                <br><a href="">Source link </a>

CoinImp Cryptominer and Fully Qualified Domain Names

CoinImp Cryptominer and Fully Qualified Domain Names

                                <br><a href="">Source link </a>
Optimizing Wordfence Security Settings: Brute Force Protection

Optimizing Wordfence Security Settings: Brute Force Protection

This entry was posted in Wordfence, WordPress Security on July 5, 2018 by Kathy Zant   14 Replies

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.

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.

Did you enjoy this post? Share it!

3.93 (14 votes)
Your rating:

                                <br><a href="">Source link </a>

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

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;


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

Did you enjoy this post? Share it!

3.90 (10 votes)
Your rating:

                                <br><a href="">Source link </a>
Page 1 of 12812345...102030...Last »

Pin It on Pinterest