Category: Wordpress

High Severity Vulnerabilities in PageLayer Plugin Affect Over 200,000 WordPress Sites

A few weeks ago, our Threat Intelligence team discovered several vulnerabilities present in Page Builder: PageLayer – Drag and Drop website builder, a WordPress plugin actively installed on over 200,000 sites. The plugin is from the same creators as wpCentral, a plugin within which we recently discovered a privilege escalation vulnerability.

One flaw allowed any authenticated user with subscriber-level and above permissions the ability to update and modify posts with malicious content, amongst many other things. A second flaw allowed attackers to forge a request on behalf of a site’s administrator to modify the settings of the plugin which could allow for malicious Javascript injection.

We initially reached out to the plugin’s developer on April 30, 2020 and after establishing an appropriate communication channel, we provided the full disclosure on May 1, 2020. They responded quickly on May 2, 2020 letting us know that they were beginning to work on fixes. An initial patch was released on May 2, 2020 and an optimal patch was released on May 6, 2020.

These are considered high-level security issues that could potentially lead to attackers wiping your site’s content or taking over your site. We highly recommend an immediate update to the latest version available at the time of this publication, which is version 1.1.4.

Wordfence Premium customers received a new firewall rule on April 30, 2020, to protect against exploits targeting this vulnerability. Free Wordfence users will receive this rule after thirty days, on May 30, 2020.

Description: Unprotected AJAX and Nonce Disclosure to Stored Cross-Site Scripting and Malicious Modification
Affected Plugin: Page Builder: PageLayer – Drag and Drop website builder
Plugin Slug: pagelayer
Affected Versions: <= 1.1.1
CVE ID: Will be updated once identifier is supplied.
CVSS Score: 7.4 (High)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L
Fully Patched Version: 1.1.2

PageLayer is a very easy to use WordPress page builder plugin that claims to work with nearly all themes on the market and in the WordPress repository. It provides extended customization of pages through the use of widgets that can add page elements like buttons, tables, excerpts, products and more.

We discovered that nearly all of the AJAX action endpoints in this plugin failed to include permission checks. This meant that these actions could be executed by anyone authenticated on the site, including subscriber-level users. As standard, these AJAX endpoints only checked to see if a request was coming from /wp-admin through an authenticated session and did not check the capabilities of the user sending the request.

There were nonce checks in use in all of these functions, but nonces can be easily compromised if incorrectly implemented – for example, if a usable nonce is displayed within the source code of the site’s output. Unfortunately for the PageLayer plugin, this is precisely what happened. A usable nonce was visible in the header section of the source code of any page that had previously been edited using the PageLayer plugin. Any site visitor could find this nonce, whether they were logged in or not, allowing any unauthenticated user the ability to obtain a legitimate nonce for the plugin’s AJAX actions.

PageLayer nonce obtainable from page source.

Using a single nonce as the mechanism for authorization control caused various security issues in the functionalities of the page builder due to this nonce being so easily obtainable.

WordPress nonces should never be used as a means of authorization as they can easily be compromised if implemented improperly or if a loophole is found. WordPress nonces are designed to be used for CSRF protection, not authorization control. Implementing capability checks in conjunction with CSRF protection on sensitive functions for full verification provides protection to ensure a request is coming from an authorized user.

The Impact

As previously mentioned, several AJAX functions were affected, causing a large variety of potential impacts. A few of the most impactful actions were wp_ajax_pagelayer_save_content, wp_ajax_pagelayer_update_site_title, and wp_ajax_pagelayer_save_template.

122 add_action('wp_ajax_pagelayer_save_content', 'pagelayer_save_content');
314 add_action('wp_ajax_pagelayer_update_site_title', 'pagelayer_update_site_title');
940 add_action('wp_ajax_pagelayer_save_template', 'pagelayer_save_template');

The pagelayer_save_content function is used to save a page’s data through the page builder. The lack of permission checks on this function allowed authenticated users, regardless of permissions, the ability to change any data on a page edited with PageLayer.

123 124 125 126 127 128 129 130 131 132 133 134 function pagelayer_save_content(){     // Some AJAX security     check_ajax_referer('pagelayer_ajax', 'pagelayer_nonce');     $content = $_POST['pagelayer_update_content'];     $postID = (int) $_GET['postID'];     if(empty($postID)){         $msg['error'] =  __pl('invalid_post_id');     }

An attacker could wipe the pages completely or inject any content they would like on the site’s pages and posts. In addition, a few widgets allowed Javascript to be injected, including the “Button” widget. There is no sanitization on the “Button” widget’s text, which allows for malicious Javascript to be used as a text. This Javascript would execute once any user browsed to a page containing that button.

PageLayer button with alert JS injected.

The pagelayer_update_site_title function is used to update a site’s title. The lack of permission checks on this function allowed authenticated users the ability to change a site title to any title of their choosing. Though less detrimental, this could still affect your sites search engine ranking if unnoticed for an extended period of time.

315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 function pagelayer_update_site_title(){     global $wpdb;     // Some AJAX security     check_ajax_referer('pagelayer_ajax', 'pagelayer_nonce');     $site_title = $_POST['site_title'];     update_option('blogname', $site_title);     $wpdb->query("UPDATE `sm_sitemeta`                 SET meta_value = '".$site_title."'                 WHERE meta_key = 'site_name'");     wp_die(); }

The pagelayer_save_template function is used to save PageLayer templates for the PageLayer Theme Builder. The lack of permission checks on this function allowed authenticated users the ability to create new PageLayer templates that were saved as new posts.

941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 function pagelayer_save_template() {          // Some AJAX security     check_ajax_referer('pagelayer_ajax', 'pagelayer_nonce');          $done = [];          $post_id = (int) $_GET['postID'];          // We need to create the post     if(empty($post_id)){              // Get the template type         if(empty($_POST['pagelayer_template_type'])){             $done['error'] = __pl('temp_error_type');             pagelayer_json_output($done);         }                  $ret = wp_insert_post([             'post_title' => $_POST['pagelayer_lib_title'],             'post_type' => 'pagelayer-template',             'post_status' => 'publish',             'comment_status' => 'closed',             'ping_status' => 'closed'         ]);

Though this function was intended to be used in the PRO version of the plugin, the function could still be executed in the free version, affecting all 200,000+ users of the PageLayer plugin. An attacker could create a new template, which created a new page on the site, and inject malicious Javascript in the same way they could with the pagelayer_save_content function.

Malicious Javascript can be used to inject new administrative users, redirect site visitors, and even exploit a site’s user’s browser to compromise their computer.

The Patch

In the latest version of the plugin, the developers implemented permissions checks on all of the sensitive functions that could make changes to a site, and reconfigured the plugin to create separate nonces for the public and administrative areas of a WordPress site.

150 151 152 153 154 // Are you allowed to edit ? if(!pagelayer_user_can_edit($postID)){     $msg['error'][] =  __pl('no_permission');     pagelayer_json_output($msg); }
Description: Cross-Site Request Forgery to Stored Cross-Site Scripting
Affected Plugin: Page Builder: PageLayer – Drag and Drop website builder
Plugin Slug: pagelayer
Affected Versions: <= 1.1.1
CVE ID: Will be updated once identifier is supplied.
CVSS Score: 8.8 (High)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Fully Patched Version: 1.1.2

The PageLayer plugin registers a settings area where configuration changes can be made. This includes functionality such as where the editor is enabled, basic content settings, basic information configurations, and more.

PageLayer settings area.

The settings update function used a capability check to verify that a user attempting to make any changes had the appropriate permissions. However, there was no CSRF protection to verify the legitimacy of any request attempting to update a site’s settings. This made it possible for attackers to trick an administrator into sending a request to update any of the PageLayer settings.

156 157 158 159 160 161 162 163 164 165 166 167 function pagelayer_settings_page(){     $option_name = 'pl_gen_setting' ;     $new_value = '';     if(isset($_REQUEST['pl_gen_setting'])){         $new_value = $_REQUEST['pl_gen_setting'];                  if ( get_option( $option_name ) !== false ) {                  // The option already exists, so we just update it.             update_option( $option_name, $new_value );

The “Information” tab in the settings area provides site owners with a way to set a default address, telephone number, and contact email address that are displayed whenever the corresponding widgets were used on a page. There was no sanitization on the address or telephone number settings, and due to the administrator’s capability to use unfiltered_html, Javascript could be injected into these settings.

PageLayer Address updated with alert JS.

The Impact

This allowed attackers the ability to inject malicious scripts while exploiting the CSRF vulnerability in the settings. If the widget was already enabled, any injected malicious scripts would execute whenever someone browsed to a page containing that widget. If the widget was not yet enabled, the malicious scripts could be executed once an administrator started editing and inserting the widget into a page. As always, these scripts can do things like create a new administrative account and redirect users to malicious sites.

The Patch

In the patched version of the plugin, the developers implemented CSRF protection consisting of a WordPress nonce and verification of that nonce when updating settings.

176 177 178 if(isset($_REQUEST['submit'])){     check_admin_referer('pagelayer-options'); }

PoC Walkthrough: pagelayer_save_content

Disclosure Timeline

April 24, 2020 to April 30, 2020 – Initial discovery of minor security flaw and deeper security analysis of plugin.
April 30, 2020 – Firewall rule was released for Wordfence Premium customers. We made our initial contact attempt with the plugin’s development team.
May 1, 2020 – The plugin’s development team confirms appropriate inbox for handling discussion. We provide full disclosure.
May 2, 2020 – Developer acknowledges receipt and confirms that they are beginning to work on fixes. An update is released the same day.
May 4, 2020 – We analyze the fixes and discover a few security issues left unpatched and responsibly disclose these issues to the developer.
May 6, 2020 – Developer releases the final sufficient patch.
May 30, 2020 – Free Wordfence users receive firewall rule.

Conclusion

In today’s post, we detailed several flaws related to unprotected AJAX actions and nonce disclosure that allowed for attackers to make several malicious modifications to a site’s pages and posts in addition to providing attackers with the ability to inject malicious Javascript. These flaws have been fully patched in version 1.1.2. We recommend that users immediately update to the latest version available, which is version 1.1.4 at the time of this publication.

Sites running Wordfence Premium have been protected from attacks against this vulnerability since April 30, 2020. Sites running the free version of Wordfence will recieve this firewall rule update on May 30, 2020. If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected.

Source :
https://www.wordfence.com/blog/2020/05/high-severity-vulnerabilities-in-pagelayer-plugin-affect-over-200000-wordpress-sites/

Large Scale Attack Campaign Targets Database Credentials

Between May 29 and May 31, 2020, the Wordfence Firewall blocked over 130 million attacks intended to harvest database credentials from 1.3 million sites by downloading their configuration files.

The peak of this attack campaign occurred on May 30, 2020. At this point, attacks from this campaign accounted for 75% of all attempted exploits of plugin and theme vulnerabilities across the WordPress ecosystem.

A graph showing the spike in attacks
We were able to link these attacks to the same threat actor previously targeting XSS vulnerabilities at a similar scale. All Wordfence users, including Wordfence Premium and those still using the free version of Wordfence, are protected by our firewall’s built-in directory traversal protection.

Different vulnerabilities, same IPs

The previously reported XSS campaigns sent attacks from over 20,000 different IP addresses. The new campaign is using the same IP addresses, which accounted for the majority of the attacks and sites targeted. This campaign is also attacking nearly a million new sites that weren’t included in the previous XSS campaigns.

As with the XSS campaigns, almost all of the attacks are targeted at older vulnerabilities in outdated plugins or themes that allow files to be downloaded or exported. In this case the attackers are attempting to download wp-config.php, a file critical to all WordPress installations which contains database credentials and connection information, in addition to authentication unique keys and salts. An attacker with access to this file could gain access to the site’s database, where site content and users are stored.

Indicators of Compromise

Attacks by this campaign should be visible in your server logs. Look for any log entries containing wp-config.php in the query string that returned a 200 response code.

The top 10 attacking IP addresses in this campaign are listed below.

200.25.60.53
51.255.79.47
194.60.254.42
31.131.251.113
194.58.123.231
107.170.19.251
188.165.195.184
151.80.22.75
192.254.68.134
93.190.140.8

What should I do?

Sites running Wordfence are protected against this campaign. If your site is not running Wordfence, and you believe you have been compromised, change your database password and authentication unique keys and salts immediately.

If your server is configured to allow remote database access, an attacker with your database credentials could easily add an administrative user, exfiltrate sensitive data, or delete your site altogether. Even if your site does not allow remote database access, an attacker who knows your site’s authentication keys and salts may be able to use them to more easily bypass other security mechanisms.

If you’re not comfortable making the changes above, please contact your host, since changing your database password without updating the wp-config.php file can temporarily take down your site.

Conclusion

In today’s post, we covered another large-scale attack campaign against WordPress sites by a threat actor we have been tracking since February. All Wordfence users, including sites running the free version of Wordfence, and Wordfence Premium, are protected against these attacks. Nonetheless, we urge you to make sure that all plugins and themes are kept up to date, and to share this information with any other site owners or administrators you know. Attacks by this threat actor are evolving and we will continue to share additional information as it becomes available.

Source :
https://www.wordfence.com/blog/2020/06/large-scale-attack-campaign-targets-database-credentials/

WordPress 5.4.2 Patches Multiple XSS Vulnerabilities

WordPress Core version 5.4.2 has just been released. Since this release is marked as a combined security and bug fix update, we recommend updating as soon as possible. With that said, most of the security fixes themselves are for vulnerabilities that would require specific circumstances to exploit. All in all this release contains 6 security fixes, 3 of which are for XSS (Cross-Site Scripting) vulnerabilities. Both the free and Premium versions of Wordence have robust built-in XSS protection which will protect against potential exploitation of these vulnerabilities.

A Breakdown of each security issue

An XSS issue where authenticated users with low privileges are able to add JavaScript to posts in the block editor

This flaw would have made it possible for an attacker to inject JavaScript into a post by manipulating the attributes of Embedded iFrames. This would be exploitable by users with the edit_posts capability, meaning users with the Contributor role or higher in most configurations.

The changeset in question is:
https://core.trac.wordpress.org/changeset/47947/

This issue was discovered and reported by Sam Thomas (jazzy2fives)

An XSS issue where authenticated users with upload permissions are able to add JavaScript to media files

This flaw would have made it possible for an attacker to inject JavaScript into the “Description” field of an uploaded media file. This would be exploitable by users with the upload_files capability, meaning users with the Author role or higher in most configurations.

The changeset in question is:
https://core.trac.wordpress.org/changeset/47948/

This issue was discovered and reported by Luigi – (gubello.me)

An open redirect issue in wp_validate_redirect()

For this flaw, the wp_validate_redirect function failed to sufficiently sanitize URLs supplied to it. As such it would have been possible under certain circumstances for an attacker to craft a link to an impacted site that would redirect visitors to a malicious external site. This would not require specific capabilities, but it would typically require either social engineering or a separate vulnerability in a plugin or theme to exploit.

The changeset in question is:
https://core.trac.wordpress.org/changeset/47949/

This issue was discovered and reported by Ben Bidner of the WordPress Security Team.

An authenticated XSS issue via theme uploads

This flaw would have made it possible for an attacker to inject JavaScript into the stylesheet name of a broken theme, which would then be executed if another user visited the Appearance->Themes page on the site. This would be exploitable by users with the install_themes or edit_themes capabilities, which are only available to administrators in most configurations.

The changeset in question is:
https://core.trac.wordpress.org/changeset/47950/

This issue was discovered and reported by Nrimo Ing Pandum

An issue where set-screen-option can be misused by plugins leading to privilege escalation

For this flaw, a plugin incorrectly using the set-screen-option filter to save arbitrary or sensitive options could potentially be used by an attacker to gain administrative access. We are not currently aware of any plugins that are vulnerable to this issue.

The changeset in question is:
https://core.trac.wordpress.org/changeset/47951/

This issue was discovered and reported by Simon Scannell of RIPS Technologies

An issue where comments from password-protected posts and pages could be displayed under certain conditions

For this flaw, comment excerpts on password-protected posts could have been visible on sites displaying the “Recent Comments” widget or using a plugin or theme with similar functionality.

The changeset in question is:
https://core.trac.wordpress.org/changeset/47984/

This issue was discovered and reported by Carolina Nymark

Note: This is unrelated to an issue where unmoderated spam comments were briefly visible and indexable by search engines.

What should I do?

Most of these vulnerabilities appear to be exploitable only under limited circumstances or by trusted users, but we recommend updating as soon as possible. Attackers may find ways to exploit them more easily, or the researchers who discovered these vulnerabilities may publish Proof of Concept code that allows simpler exploitation. This is a minor WordPress release, so most sites will automatically update to the new version.

Conclusion

We’d like to thank the WordPress core team and the researchers who discovered and responsibly reported these vulnerabilities for making WordPress safer for everyone.

You can find the official announcement of the WP 5.4.2 release on this page. If you have any questions or comments, please don’t hesitate to post them below and we’ll do our best to answer them in a timely manner. If you are one of the researchers whose work is included above and would like to provide additional detail or corrections, we welcome your comments.

Source :
https://www.wordfence.com/blog/2020/06/wordpress-5-4-2-patches-multiple-xss-vulnerabilities/

Inadequate security makes WordPress sites a land of opportunity for hackers

The famous American robber Willie Sutton was asked once why he robbed banks. His answer was humorous, direct, and revealing: “Because that’s where the money is.”

For hackers, WordPress sites represent a similar rich vein of opportunity. WordPress is one of the world’s most popular web publishing platforms. Its ease of publishing is popular with smaller businesses and organizations looking to establish a quick and easy presence on the internet.

Unfortunately, that same ease lends itself to insecure web practices, such as web platforms that aren’t properly protected, weak passwords, and lack of administrative controls. The latter can also make it easy for increased lateral movement once an initial web server is compromised. This can greatly increase the scale of damage, making WordPress infrastructure very lucrative for hackers.

Cisco Umbrella threat researchers have been analyzing attacks on various WordPress sites recently. We found some interesting examples of how attackers are compromising WordPress sites. Let’s look into it.

How do attackers compromise a WordPress site?

Generally, what we’ve seen are variations of land-and-expand techniques. Hackers seek opportunities to infiltrate weakly protected WordPress sites, identify associated assets through phishing and other subterfuge, and expand their network of compromised assets for further expansion of opportunities to monetize their activities.

There are several ways to infiltrate WordPress infrastructure. But, generally, we’ve seen attackers progress by these sorts of actions:

  1. Take control of the WordPress site through brute force attacks, trojans inside themes and plug-ins, and exploitation of poorly protected admin controls
  2. Host malware
  3. Host phishing pages that mimic popular brands to collect more information
  4. Host spam pages to create more intelligence-gathering opportunities
  5. Most importantly, use the compromised site to attack other WordPress sites

How does an attacker find and select a site to attack?

An attacker can use systems that are designed to scan the internet for vulnerable WordPress sites and then notify the attacker’s command-and-control server.

Another method to discover vulnerable sites for attack is open source domain intelligence. For example, an attacker could find a domain by using Google Dorks.

When our researchers examined the compromised machines, they found a lot of malicious PHP scripts and malware.

First, an attacker would append the malicious code in the index page. So when a customer visits the WordPress site, it redirects to spam pages — or it may trigger the server to do something else.

 An example of such spam page redirection follows:

Example of spam page redirection - Cisco Umbrella Blog

This attack type is not new — we have been seeing attacks like this for a while.

We also observed cases where malware was hosted on the website. In one case, we found a trojan that made contact with the domain detroidcliper[.]at.

example of a command-and-control server whose domain has very high query volume - Cisco Umbrella Blog

This particular domain is a command-and-control server. It receives a lot of queries, with high query volumes reaching a max of 94k queries. We also observed a login panel hosted at this domain, that matches the login panel of Sarwent.

Example of a login panel that matches the login panel of sarwent, which is implicated in prior attacks - Cisco Umbrella Blog

Let’s take a closer look at malicious scripts that were hosted on a compromised WordPress site. Most of them are PHP scripts which are obfuscated heavily. The most commonly used obfuscation method is eval(gzuncompress(base64_decode(Endoded_content)));

Example of the most commonly used obfuscation method - Cisco Umbrella Blog

After decoding, we found the following script.

Example of obfuscated PHP script found after decoding - Cisco Umbrella Blog

This PHP code contains an executable file delivered via Base64 encoding. When the PHP code runs, the executable file executes directly in the memory.

Example of WordPress site with PHP code containing an executable file delivered via Base64 encoding - Cisco Umbrella Blog

Another function in the PHP code also searches for an exploit in order to perform privilege escalation.

Example of a function in the PHP code searching for an exploit to escalate the privilege in WordPress - Cisco Umbrella Blog

The remainder of the malicious scripts perform various tasks. Some of these redirect to spam sites, give shell access to attackers, and others are used to attempt to compromise other WordPress sites. Generally, the objectives are to collect more intelligence in search of further opportunities to exploit, and compromise more sites to continue the cycle.

A brute force WordPress attack is an ongoing process. On average, a single compromised WordPress site tries to brute force about 2,000 other domains per day. Not every WordPress site will be compromised, but enough WordPress sites have easy-to-guess common passwords to make this type of attack worthwhile. Usually, attackers keep a list of simple passwords and use them to launch a brute force attack on a site.

During an analysis of network traffic, we noticed that one of the compromised sites was contacting another domain continuously.

The domain was styleofphucet[.]at. Surprisingly, this one also has high query volume.

Example showing that the higher the query volume of the command-and-control server, the more the sites have been compromised - Cisco Umbrella Blog

This domain was repeatedly contacted during the same compromise that included network callouts to detroidcliper[.]at.

While we were researching more about this attack, we found a domain that was embedded in pages of many compromised domains. We found that it hosted an open directory that was very revealing. Inside the directory, we found almost all of the WordPress domains related to the attacks.

Example of a WordPress directory where we found almost all the domains involved in the attacks - Cisco Umbrella Blog
Example of a massive amount of random text that may be browser history of victims - Cisco Umbrella Blog

We observed that a massive amount of random text was collected and stored by the attacker. After closer analysis, we realized that it may be browser history of victims.

Why would an attacker store a random massive list of browser history? Isn’t this strange?

We believe that attackers use this browser history to search in various search engines for vulnerable domains using a bot. Any of those domains may become the target.

Also, the attackers use the sitemap for the pages they have hosted and let the bots crawl them. This way, when a user searches for a website, they get the pages that are hosted by the attackers instead of what they intended to visit.

How can WordPress administrators protect themselves from these kinds of exploits? Whenever a WordPress site is being hosted, the administrator has to make sure that all security requirements are met. So many attacks that are happening today are because of a lack of security controls, use of weak passwords, and because of vulnerable themes and plugins.

Here are some best practices to protect WordPress sites:

  1. Use a strong password and change it regularly
  2. Use adequate access controls
  3. Update plugins and themes

By taking these types of measures, you can reduce the attack surface so that your site is less likely to be compromised.

With Cisco Umbrella, you get instant access to interactive threat intelligence that lets you conduct investigations and uncover attacks before they start. Our recursive DNS servers resolve more than 200 billion requests per day, so we can see the relationships between malware, domains, IPs, and networks across the internet. Our threat analysis learns from internet activity patterns to automatically identify attacker infrastructure being staged for the next threat.

Learn more about how predictive intelligence can make a difference in your ability to stop threats by reading our technical paper, The Role of Predictive Intelligence in the Fight Against Cyber Attacks.

Check out our recent article on threat intelligence to dive into pandemic-themed phishing attacks and uncover how attackers orchestrate sophisticated campaigns to take advantage of the current pandemic.

IOCS

Possible Compromised sites:
https://github.com/minakushi/Domains

Hash:
593b2c9292dc36ab619453bb7d8480f78d5d1e04e811f5f1f8d9b612de771718

Uris:
/15hftjsefg.php
/wp-ss.php
/jtyergd
/jtyergd
/hoinudh12jshs
/qoclekrjs
/alekfjwh62jshd.php
/xlvkfjehq
/bzk7md
/l3x7zxz9dsv3rt.php
/zzz.php
/wp_butt.php
/wp_class_datalib.php
/runargg.php
/shathagg.php
/roman.php
/wp-less
/story2.php Source :
https://umbrella.cisco.com/blog/inadequate-security-makes-wordpress-sites-a-land-of-opportunity-for-hackers

One Attacker Outpaces All Others

Starting April 28th, we saw a 30 times increase in cross site scripting attack volume, originating from a single attacker, and targeting over a million WordPress sites. We published research detailing the threat actor and attack volume increase on May 5th. By the time we published, the attack volume had dropped back down to baseline levels.

As of May 11, 2020, attacks by this same threat actor have once again ramped up, and are ongoing. This attacker has now attacked over 1.3 million sites in the past month. As of May 12, 2020, attacks by this threat actor have outpaced all other attacks targeting vulnerabilities across the WordPress ecosystem.

The chart below describes the attack volume we are seeing.

Attacks by this threat actor vs all other sources
These attacks are targeting the same vulnerabilities as the previous wave, with a heavy focus on older XSS vulnerabilities. Additionally, we have been able to link this threat actor to previously described attacks as far back as February 9, 2020.

A History of attacks

Our Threat Intelligence team has been able to link this threat actor to previous attacks with payloads hosted at domains: collectfasttracks[.]com and destinyfernandi[.]com.

Our logs show that this attacker has been ramping up attack volume, sustaining the attack over a two day period, and then reducing volume to a trickle. Each of these surges has progressively increased in volume as the attacker becomes more aggressive.

The earliest attacks containing the destinyfernandi[.]com payload occurred on February 9th and 10th, 2020 and targeted over 200,000 sites with 3.8 million requests.

On March 14 and 15, 2020, attacks containing the collectfasttracks[.]com payload ramped up and targeted over 500,000 sites with more than 7 million requests. That is an approximate doubling in attack volume and number of sites targeted from February to March.

What has changed?

Previous attacks appeared to be spaced roughly a month apart and had much lower volume. Comparatively, the last 30 days have seen 4 attacks of increasing size, cumulatively targeting over 1.3 million sites.

While this threat actor is not targeting different vulnerabilities, the new wave of attacks is hosting the initial malware payload on a different domain:

https://css[.]digestcolect[.]com/stm

The script hosted on the new domain is similar to the one previously hosted at count[.]trackstatisticsss[.]com.

There are a few changes that indicate the attacker is refining their technique. They fixed a bug in the previous version of their PHP backdoor that would have prevented it from being usable on most sites. They have also added two additional backdoor variants, one of which is similar to the backdoor used in a previous attack campaign.

The screenshot below has three chunks of PHP code, each starting with a <?php tag. These are three separate malware variants that the attacker embeds in infected sites. The first loads code from the attacker’s domain and the second and third malware variants allow the attacker to manually execute malicious code by sending a request containing a password and encoded data to execute.

Partially deobfuscated PHP backdoors
*The PHP backdoor variants in this screen shot have been partially deobfuscated for readability

When the older backdoor attempted to execute the payload located at https://stat[.]trackstatisticsss[.]com/n.txt, it tried to use the PHP include() function to include the payload source code. This was a bug because include() expects a file. The attackers should have been including the temporary file containing the payload. We spotted this bug during our previous research but neglected to mention it in our earlier post in order to avoid reporting bugs to malware authors.

The threat actor has now fixed this bug and the current backdoor correctly includes the payload located at http://css[.]digestcolect[.]com/m.txt.

The two additional backdoors, shown in the screenshot above, allow attackers to maintain access to the site, even if the payload URL is taken down due to an abuse complaint.

New Indicators of Compromise

While previous indicators of compromise still apply, the updated final payload also uses the following string to determine whether the site is already infected. It can do this because this is the name of the variable that it attempts to insert into every JavaScript file on the infected site:

mndfhghjf

The presence of the following domains in your database or filesystem should be considered an indicator of compromise:

digestcolect[.]com
trackstatisticsss[.]com
stivenfernando[.]com
collectfasttracks[.]com
destinyfernandi[.]com

As with most attack campaigns, the attacker frequently rotates IP addresses. At the moment, we are seeing attacks from these top 10 attacking IP addresses.

5.187.34.95
91.121.106.106
94.23.3.130
54.36.197.5
46.37.172.252
104.238.222.178
2001:41d0:2:482::
104.236.133.77
2001:41d0:c:c3d::
151.80.25.182

What should I do?

As with the previous attacks, the majority of vulnerabilities being targeted are Cross-Site Scripting (XSS) flaws. The Wordfence Firewall’s built-in XSS protection provides protection from these attacks. Nonetheless, we strongly recommend updating any outdated plugins or themes. We also recommend deactivating and deleting any plugins installed on your WordPress site that have been removed from the official WordPress repository.

If you are running the Wordfence plugin, our scanner will alert you if have any plugins or themes with known vulnerabilities, or that have been removed from the WordPress repository. If you are a Wordfence Premium customer, the real-time blacklist will detect and block access to your site from these malicious IP addresses.

Source :
https://www.wordfence.com/blog/2020/05/one-attacker-rules-them-all/?utm_campaign=Wordfence%20Blog%20Emails&utm_source=hs_email&utm_medium=email&utm_content=87850880&_hsenc=p2ANqtz-9lEkvPw6bT49NMTdlKA-HDGgzWZ9DM4ZTKadCpqSTs0nrKPLtzlaeelrU61WmFcNlwxZHEbmdq55xpk0XSuzvspi6IcA&_hsmi=87850880

4 ways to create a new website for your small business

Being online is crucial – after all, people in the UK are the biggest online spenders. So whether you’re starting a new business, getting an existing business online for the first time or launching a replacement site for your existing online business, building the right website is crucial.

But if you’ve never created a website before, or don’t think of yourself as “technically minded” the number of options available to you can feel overwhelming.

In this guide, we’ll look at four difference options for creating a small business website and the pros and cons of each approach.

Option 1 – Using a web designer to build your small business website

This is the option you’re most likely to be familiar with already. There are scores of reputable web designers out there, just waiting to create your ideal site.

If you’re looking to create a large, powerful website packed with features, then this is likely to be the option you go for.

However, if you’re only looking to create a small brochure type site, you may find there are cheaper options that meet your needs just as well.

You also need to be sure that you hire a reputable web designer, who is capable of delivering what you need for a price you can afford. Look at examples of a designer’s previous work, and all reputable designers should be keen to put you in touch with past clients so you can get a true idea of their ability.

If you’re struggling to find a good web designer, then check out GoDaddy’s directory of local web designers.

In the negative column, along with the potentially high cost of hiring a web designer, you also need to think about future updates to your website. If you’ll need to make regular updates to your site, then make sure the designer factors this in when creating it. (Or use one of the other methods outlined in this guide.) You don’t want to be left in a situation where you have to contact your web designer to make even the smallest of changes to your site.

Option 2 – Using a website builder

If you want to create a website quickly and easily at a low cost (usually a small monthly fee), then opting for a website builder package may be right for you.

You won’t be able to create a large, complex site using this method, but then a lot of online businesses won’t need a large, complex site.

So if you’re looking to create a website focused on providing customers with information – such as a portfolio or restaurant website, or a website aimed at lead generation, then this is a great option for you.

Another huge advantage of using a website builder is that it allows you to create your own website without having to learn to code. By using templates and a drag and drop interface, you can create a site that suits your business down to the ground, and then easily update it whenever you need to.

Why not take a look at GoDaddy’s Website Builder to see if it meets your needs?

And if you do want to sell products online, but need a low-cost solution to do so, then take a look at Online Store from GoDaddy. It allows you to add up to 1,500 products to your store, while still providing you with the flexibility of a website builder.

Plus, with the launch of GoDaddy Websites + Marketing, you’ll find it easier than ever before to promote your website if you create it with Website Builder.

There’s a whole host of integrated marketing tools covering things like search engine optimization, social media and email.

Option 3 – Use a CMS like WordPress

WordPress is a content management system (CMS) that lets you create any kind of website you need.

In some ways it’s similar to a website builder – you can pick from a huge number of themes which dictate what your website will look like. It’s also relatively straightforward to add new content to your website.

However, WordPress is a little bit more complex than using a website builder, so you will need some technical skills if you’re going to make the most of it. It is possible to reduce the amount of technical know-how needed to create and maintain a WordPress site by opting for a managed WordPress hosting package, like the one offered by GoDaddy.  If you do this, things like updates to the WordPress CMS will be handled automatically, so you don’t have to worry about them.

An even simpler option is GoDaddy WordPress Websites, which provides you with a drag and drop interface, making it easier for you to build a site you love.

Of course, you can always hire a professional to create a WordPress site for you, and then update it yourself, but you’ll need a budget to pay a web designer.

You can even get GoDaddy to design and build a WordPress website for you – so you can get the website you want, while benefiting from GoDaddy’s best-in-class customer service.

This blog post explains more about why WordPress is a good choice for small businesses.

Option 4 – Build your own website from scratch

The big one. Learning to build your own website from scratch is possible, but you need to be realistic about what you can achieve and how quickly you can achieve it.

Web designers spend years learning their craft, so don’t expect that you’ll be able to build a large, complex website with just a few weeks of an online course under your belt.

That said, with persistence and dedication, there’s no reason why you can’t learn to build websites that any business would be proud to call their own.

However, if you need a site quickly then this probably isn’t the option for you unless you only need a small, simple site for your business.

That said we really don’t want to put off budding web designers – so if learning to build quality websites is on your bucket list, but you’re not ready to create your own business site just yet, why not opt for one of the three options above while you hone your skills?

If you do decide to go down the DIY path, Codecademy offer a make a website course, focused on coding.

And if you need some pointers on designing your site, check out this guide on how to avoid web design mistakes that could sabotage your business.

However you decide to get your business online, GoDaddy will be here to help you succeed.

 

Source :
https://uk.godaddy.com/blog/4-ways-create-new-website-small-business/

How to Minify HTML in WordPress Without a Plugin

What is HTML Minification?

When you minify HTML it removes the unnecessary characters and lines in the source code. Indentation, comments, empty lines, etc. are not required in HTML. They just make the file easier to read. Cutting out all this unnecessary stuff can shave down your file size considerably. When you minify HTML code on your website, the server will send a much smaller page to the client making your website load quicker.

WordPress creates pages on demand by executing PHP code to put together the HTML version of your site and querying your database to get the content to insert into that HTML. There is no physical file that we can download and minify ourselves, so we will need to use a bit of PHP code inside the functions.php file of your theme. This code will compress the output HTML before being sent to your visitors. Below are two screenshots that show a webpage before and after HTML Minification.

Before HTML Minification

Before HTML Minify

After HTML Minification

After HTML Minify

Step 1: Create a Child Theme

Before we edit the functions.php file, it’s always best to create a child theme. Using a child theme will allow you to revert back to the parent theme if there are problems. Also, any changes you make will not be deleted if your parent theme gets updated.

If you prefer not to create a child theme or you do not feel comfortable doing this on your own, there is a great lightweight plugin you can use called Code Snippets. Code Snippets is an easy, clean and simple way to add code snippets to your site. It removes the need to add custom snippets to your theme’s functions.php file.

Step 2: Edit your Child Theme functions.php File

There are 2 different ways we can edit the functions.php file in your child theme.

Inside WordPress Control Panel

While you are logged into WordPress you can access and edit the functions.php file of your theme by going to Appearance > Editor and selecting Theme Functions on the right hand side of the page.

Edit the File Directly in cPanel

Log into your cPanel File Manager. Go to the public_html/wp-content/themes/ and choose the folder of your current theme or child theme if you have created one. The functions.php file will be inside your theme folder.

Copy and paste the code below inside your functions.php file and save.

class FLHM_HTML_Compression { protected $flhm_compress_css = true; protected $flhm_compress_js = true; protected $flhm_info_comment = true; protected $flhm_remove_comments = true; protected $html; public function __construct($html) { if (!empty($html)) { $this->flhm_parseHTML($html); } } public function __toString() { return $this->html; } protected function flhm_bottomComment($raw, $compressed) { $raw = strlen($raw); $compressed = strlen($compressed); $savings = ($raw-$compressed) / $raw * 100; $savings = round($savings, 2); return '<!--HTML compressed, size saved '.$savings.'%. From '.$raw.' bytes, now '.$compressed.' bytes-->'; } protected function flhm_minifyHTML($html) { $pattern = '/<(?<script>script).*?</scripts*>|<(?<style>style).*?</styles*>|<!(?<comment>--).*?-->|<(?<tag>[/w.:-]*)(?:".*?"|'.*?'|[^'">]+)*>|(?<text>((<[^!/w.:-])?[^<]*)+)|/si'; preg_match_all($pattern, $html, $matches, PREG_SET_ORDER); $overriding = false; $raw_tag = false; $html = ''; foreach ($matches as $token) { $tag = (isset($token['tag'])) ? strtolower($token['tag']) : null; $content = $token[0]; if (is_null($tag)) { if ( !empty($token['script']) ) { $strip = $this->flhm_compress_js; } else if ( !empty($token['style']) ) { $strip = $this->flhm_compress_css; } else if ($content == '<!--wp-html-compression no compression-->') { $overriding = !$overriding; continue; } else if ($this->flhm_remove_comments) { if (!$overriding && $raw_tag != 'textarea') { $content = preg_replace('/<!--(?!s*(?:[if [^]]+]|<!|>))(?:(?!-->).)*-->/s', '', $content); } } } else { if ($tag == 'pre' || $tag == 'textarea') { $raw_tag = $tag; } else if ($tag == '/pre' || $tag == '/textarea') { $raw_tag = false; } else { if ($raw_tag || $overriding) { $strip = false; } else { $strip = true; $content = preg_replace('/(s+)(w++(?<!baction|balt|bcontent|bsrc)="")/', '$1', $content); $content = str_replace(' />', '/>', $content); } } } if ($strip) { $content = $this->flhm_removeWhiteSpace($content); } $html .= $content; } return $html; } public function flhm_parseHTML($html) { $this->html = $this->flhm_minifyHTML($html); if ($this->flhm_info_comment) { $this->html .= "n" . $this->flhm_bottomComment($html, $this->html); } } protected function flhm_removeWhiteSpace($str) { $str = str_replace("t", ' ', $str); $str = str_replace("n", '', $str); $str = str_replace("r", '', $str); while (stristr($str, ' ')) { $str = str_replace(' ', ' ', $str); } return $str; } } function flhm_wp_html_compression_finish($html) { return new FLHM_HTML_Compression($html); } function flhm_wp_html_compression_start() { ob_start('flhm_wp_html_compression_finish'); } add_action('get_header', 'flhm_wp_html_compression_start'); PHP

Step 3: Make Sure Everything is Working

After you have added the code, you can check to see if the HTML is being minified on Google Chrome by right clicking the page and selecting “View page source.” If everything is working correctly, it should look like the example picture I gave at the top of this page.

I highly recommend you check all aspects of your website after you add this code. Check and make sure all plugins and theme functionality is working properly.

If you enjoyed this tutorial, please be sure to follow us on Facebook and Twitter. You can also find us on Freelancer if you need some help with your WordPress website or web development issues.

Source :
https://zuziko.com/tutorials/how-to-minify-html-in-wordpress-without-a-plugin/
Exit mobile version