A researcher has discovered a critical vulnerability in LiteSpeed Cache, a popular plugin used by over 6 million WordPress sites to improve load times.
This flaw, CVE-2024-44000, allows attackers to gain control of a WordPress site without requiring authentication of the identity.
In our previous blog, we discussed how we can identify and fix the Vulnerabilities in LiteSpeed Cache version 6.3.0.1.
We identified another vulnerability in version 6.4.1 of the plugin: “Unauthenticated Sensitive Information Exposure via Log Files.” This flaw allows an attacker to completely take over an account.
Unauthenticated Sensitive Information Exposure
It is a security vulnerability where sensitive data is unintentionally accessible to individuals without any authentication or credentials.
This flaw occurs when the system exposes private information, like login credentials, session cookies, personal data, or system details, to anyone without requiring a login.
Improper Access Control
Improper access control or system misconfiguration may make sensitive information like debugging logs, configuration files, or internal error messages publicly accessible.
Exposed Debugging Information
Developers sometimes leave debugging enabled in production environments, which can expose information like session tokens, usernames, paths, or API keys in logs or error messages.
Attackers can exploit this by reading these logs and using the sensitive data to gain unauthorized access or perform attacks (e.g., session hijacking)
No Authentication Required
The main feature of this vulnerability is that an attacker can exploit it without logging in or submitting credentials. The system exposes sensitive data without verification of identification.
Identifying Vulnerability In LiteSpeed Cache V-6.4.1
All versions of LiteSpeed up to 6.4.1 expose sensitive information via the publicly accessible debug.log file, allowing unauthenticated attackers to access user session data and potentially log in.
WordPress stores sensitive session cookies in log files for troubleshooting, potentially exposing logged-in users, including admins.
The vulnerability occurs when the debug.log file is publicly accessible due to misconfigurations and debug mode is enabled, though it should be off by default in WordPress.
Identifying a publicly accessible debug.log file on the target website.
Accessing the file directly via its URL (e.g., http://yourwebsite.com/folder-name/debug.log).
If a hacker gains access to this log file, they can steal the session cookies, impersonate an administrator, and take full control of the site.
Steps to Exploit this Vulnerability In LiteSpeed Cache V-6.4.1
For a better understanding of this attack, please refer to the diagram.
By following these steps, you can reproduce this vulnerability on your website
1. Activate Debug Mode:-
In the WordPress root directory, open the wp-config.php file.
Enable (‘WP_DEBUG’ , true );(‘WP_DEBUG_LOG’, true );
Add the following lines to enable logging and make sure to prevent the errors from being displayed on the site:
2. Trigger Logs:
Perform any activity on your WordPress site to populate the log with entries.
You can perform any action such as: Logging in with different users and Performing administrative tasks. The admin can perform actions like adding, editing, or deleting products.
They can also create a new user account, log in with that account, add products to the cart, interact with the site, perform similar activities, etc.
These activities will cause session cookies and user information to be written to the debug.log file.
3. Access the debug.log File:
If the debug.log file is publicly accessible, the attacker can directly access it by navigating to the following URL:
http://yourwebsite.com/folder-name/debug.log
The log file will load in the browser, revealing sensitive data such as session cookies.
4. Analyze the Log File:-
Look for session-related cookies, typically starting with wordpress_logged_in_, or other authentication tokens. These cookies can be used to hijack user sessions.
Exploitation
Copy the session cookie of a logged-in user (e.g., an administrator) from the debug.log file.
Use a browser extension like Edit This Cookie to replace your browser’s session cookie with the one from the log file.
Refresh the WordPress admin page, and you will be logged in as the user whose session was exposed, potentially gaining admin access.
As shown in below snapshot;
Add Cookies Editor extension using this link or go to your Browser store:-
For Chrome:-
https://chromewebstore.google.com/detail/cookie-editor/hlkenndednhfkekhgcdicdfddnkalmdm?hl=en&pli=1
For Firefox:-
https://addons.mozilla.org/en-US/firefox/addon/cookie-editor/
Impact on Your Website
- Session Hijacking: Attackers can steal session cookies, allowing them to impersonate users, including admins.
- Data Breach: Sensitive user data, such as session tokens, could be exposed, leading to privacy violations.
- Website Takeover: Attackers may gain full control of the site, potentially defacing it or injecting malware.
- Reputation Damage: Loss of user trust, business disruption, and legal risks, particularly under privacy laws.
- Indirect Attacks: The compromised site could be used to attack other users, spreading malware or phishing schemes.
Prevention for this Vulnerability
- Delete all old debug log files from the server to remove any session cookies that may have been exposed.
- Add a .htaccess rule to block direct access to the log files, even with the new random names, to prevent hackers from trying to guess them.
- Update to LiteSpeed Cache version 6.5.0.1 immediately.
(update Version 6.4.1 to 6.5.0.1 or higher version)
- Disable Debug Mode in Production:-
Ensure that WordPress debug mode is not enabled on live or public-facing websites.
Debug mode should only be enabled temporarily for troubleshooting and immediately disabled afterward.
In the wp-config.php file, set the following to disable logging:
define(‘WP_DEBUG’, false);
define(‘WP_DEBUG_LOG’, false); - Secure the debug.log File
If debug mode is necessary, restrict access to the debug.log file. You can do this by adding rules in the .htaccess file (for Apache servers) to block public access, For Example:-
<Files “debug.log”>
Order allow,deny
Deny from all
</Files>
- Regularly Audit Website Configurations
Perform regular security audits to ensure sensitive files, like debug.log, are not publicly accessible
Security plugins like Wordfence or Sucuri can be used to monitor file access and block unauthorized access.
- Use Environment-Specific Configurations
Use different configurations for development and production environments. Enable logging in development but ensure it’s disabled or secured in production. - Monitor Server Logs for Unusual Activity
Regularly check server logs for unusual requests or access patterns targeting files like debug.log.
Conclusion:
The LiteSpeed Cache 6.4.1 vulnerability exposes session cookies through a public debug.log file, allowing attackers to hijack sessions and gain unauthorized admin access.
This risk only occurs when debug mode is enabled, which is off by default.
However, if left unaddressed, it can lead to serious consequences, including website takeover, data breaches, and reputational damage.
Preventing this vulnerability requires securing or disabling the debug.log file, ensuring the debug mode is off in production, and following best practices for WordPress security.
Need Support?
Thank You for reading this Blog!
For further more interesting blogs, keep in touch with us. If you need any kind of support, simply raise a ticket at https://webkul.uvdesk.com/en/.
For further help or queries, please contact us or raise a ticket.