2024 Guide: How LiteSpeed Cache Plugin’s Latest Patch Prevents Account Takeovers

Critical Account Takeover Vulnerability Patched in LiteSpeed Cache Plugin

This post focuses on a significant vulnerability recently discovered in the LiteSpeed Cache plugin. If you’re using this plugin, it’s crucial to update it to at least version 6.5.0.1 to protect your site from potential attacks. This vulnerability posed a major threat to the security of WordPress sites running the plugin, allowing unauthorized users to take over accounts, including those with administrative privileges.

About the LiteSpeed Cache Plugin

LiteSpeed Cache is one of the most popular caching plugins available in the WordPress ecosystem. With more than 5 million active installations, it has established itself as a key tool for website performance optimization. The plugin provides server-level caching, which greatly enhances website speed and reduces server load. In addition to caching, it offers a host of optimization features, such as CSS/JS minification, lazy loading of images, and database optimization.

The plugin supports WordPress Multisite installations and is compatible with a wide range of commonly used WordPress plugins, including WooCommerce, bbPress, and Yoast SEO, making it highly versatile for different types of websites.

The Security Vulnerability: A Deeper Dive

The critical vulnerability in the LiteSpeed Cache plugin allowed unauthenticated users to take over accounts, including administrative accounts. Once an attacker gained access to an administrative account, they could upload and install malicious plugins, thereby completely compromising the website.

This vulnerability was discovered during a detailed technical investigation following the earlier report of an Unauthenticated Privilege Escalation vulnerability in the same plugin. John Blackbourn, an alliance member, was instrumental in uncovering this security flaw. He identified that sensitive data, such as the session cookies of logged-in users, could be leaked through the plugin’s debug log file.

How the LiteSpeed Cache plugin Vulnerability Works

The root of the issue lies in the way the LiteSpeed Cache plugin handled HTTP response headers within its debugging functionality. Specifically, the plugin’s debug log file included sensitive HTTP response headers, such as the “Set-Cookie” header. When a user logs into the WordPress site, the “Set-Cookie” header is used to manage their session. If this data were exposed through the debug logs, an attacker could hijack the session and gain access to the account, even without authentication.

The problematic code was found in the ended() function within the src/debug2.cls.php file. This function calls headers_list(), which retrieves all the HTTP response headers sent by the server. These headers, including sensitive ones like “Set-Cookie,” were then logged in the debug file. This became especially dangerous when the plugin’s “Log Cookies” feature was enabled, as it allowed the session cookies to be recorded in the log.

Additionally, the ended() function is called by the send_headers_force() function, which is triggered during the init hook. This meant the exposure of sensitive data was closely tied to the plugin’s fundamental processes, making it a critical flaw.

Conditions for Exploitation

For an attacker to successfully exploit this vulnerability, certain conditions needed to be met:

1. The debug log feature in the LiteSpeed Cache plugin had to be activated.
2. The debug log feature had to be enabled at least once in the past, even if it wasn’t currently active.
3. The file /wp-content/debug.log must still exist and not have been purged, allowing attackers to access the leaked data from previous sessions.

If these conditions were present, attackers could potentially access sensitive data stored in the debug log, leading to account takeover.

The Official CVE and Fix

This vulnerability has been assigned the identifier CVE-2024-44000. The LiteSpeed team acted quickly to address the issue, releasing a patch in version 6.5.0.1 of the plugin. Users are strongly encouraged to update to this version or later to prevent exploitation.

Details of the Patch

To resolve the issue, several key changes were made in the plugin’s codebase:

1. Debug Log Relocation: The debug log file has been moved to a dedicated LiteSpeed folder at /wp-content/litespeed/debug/. This makes it less likely for the log file to be inadvertently exposed or accessed by unauthorized users.
2. Randomized Log Filenames: The log file names now incorporate a random string based on a substring of the MD5 hash of the WordPress AUTH_KEY. This ensures that log files have unique, hard-to-guess names, making it more difficult for attackers to locate and access them.
3. Removed Log Cookies Option: The plugin no longer provides an option to log cookies in the debug file, eliminating one of the main avenues for leaking sensitive data.
4. Excluded Cookies from Response Headers: Cookies and other sensitive information are no longer included in the HTTP response headers logged in the debug file, further reducing the risk of exposure.
5. Added Security to Debug Directory: A dummy index.php file was added to the new debug directory, preventing direct access to the directory’s contents through a browser.

Additional Recommendations for Users

While the patch fixes the vulnerability, there are further steps users should take to ensure their sites are fully protected:

• Apply proper .htaccess rules to block direct access to the new log file. While the LiteSpeed team has already implemented an .htaccess rule, it is not entirely foolproof. Users are advised to strengthen the rule to ensure the log file cannot be accessed, even if its name is known.
• Purge or remove the old debug.log file from the /wp-content/ directory. If the debug log feature was previously enabled, there could be sensitive cookie data still stored in the old log file. Removing or purging this file is critical to prevent attackers from exploiting previously leaked data.

Conclusion

This vulnerability serves as a reminder of the importance of securing debug logs and the potential dangers of logging sensitive information such as authentication data. Developers of plugins and themes should avoid logging sensitive data and ensure that their debug logs are securely stored, using randomized filenames and appropriate access restrictions.

Ensuring that no sensitive data, like authentication cookies or session tokens, is logged in debug files is essential to prevent exploitation. The LiteSpeed Cache team has addressed the issue, but users must also follow best practices to safeguard their sites by removing old debug logs and applying additional security measures. Regularly updating plugins and closely monitoring site security are essential steps for preventing future attacks of this nature.