With over 5 million active installations, LiteSpeed Cache is one of the most popular caching plugins in the WordPress ecosystem. This all-in-one site acceleration plugin offers a unique server-level cache and optimization features. It supports WordPress Multisite and integrates with popular plugins like WooCommerce, bbPress, and Yoast SEO.

How did Iran hack my website?

On September 4th, 2024, between 18:00 and 20:00 Israel time, some volunteers responsible for writing daily content noticed unusual activity on the website, including plugin changes, settings modifications, and more. They immediately alerted my team.

The website, owned by me, operated by my company IMS - Network, and hosted on IMS - Cloud (my cloud solution), was promptly investigated. Shortly after 20:00, we escalated the situation to a security breach after reviewing the logs and confirming that files and settings had been altered.

To prevent further unauthorized modifications, my team temporarily disconnected the website from the internet and began a thorough investigation (On my cloud, customers have the ability to disconnect their environments from the Internet and migrate them over to their own private network whenever they want). They started by turning WordPress plugins and themes on and off to isolate the issue.

During the investigation, we discovered that a developer had left debug mode enabled on the production environment to troubleshoot an issue some users had reported. This debug mode, turned on a day prior, was accidentally left active—a mistake that shouldn't happen, as debugging in production is risky.
However, developers sometimes take shortcuts out of convenience (guilty as charged)

What is the WordPress debug mode?
WordPress debug mode is a feature that helps developers identify and fix issues within a WordPress site by displaying error messages, warnings, and notices. When enabled, it provides detailed information about problems in the code or configuration, which is helpful during development.

After several attempts, around 21:45, I disconnected all users from the website, and the file and settings changes stopped. A few minutes later, while reviewing the file changes directly on the server, I noticed that LiteSpeed Cache had been installed. This seemed strange, so I contacted my team to find out who had installed it. One of the volunteer developers responded, saying they had installed it to improve the website's caching performance.

However, the developer was unaware we had already implemented caching through Cloudflare, handling 99.98% of the website's caching needs.

That's also one of the reasons why he turned the debug log on to check what was happening and he left it online

After deactivating the debug mode and restarting the server, I thoroughly checked the connection logs to ensure everything was in order.
I confirmed that no files or settings were being altered or tampered with.
By 22:00, the website was back online, and we resumed normal Hasbara operations. 🇮🇱

Why did it take the attacker so long?

After gaining access to the admin dashboard via a vulnerability in the LiteSpeed Cache plugin, the attacker struggled because they didn’t understand the language of our WordPress admin dashboard, which is in Hebrew—naturally, as our team is based in Israel.

When we reviewed the logs, we saw that it took the attacker several minutes to make any changes, adjust plugin settings, or delete pages, due to their difficulty navigating the Hebrew interface.

Most WordPress websites have a standard UI, and attackers should be familiar with left-to-right layouts. It seems that their inexperience with WordPress and the Hebrew language slowed them down, though they specifically targeted us because we were a suitable target.

The Vulnerability

The LiteSpeed Cache plugin contains an unauthenticated account takeover vulnerability, allowing any unauthenticated visitor to gain access to logged-in user sessions. In the worst case, attackers can elevate privileges to an administrator level, enabling them to upload and install malicious plugins.

This vulnerability exploits an HTTP response headers leak in the debug log file, including the Set-Cookie header, which is triggered after a user logs in. This leak provides attackers with session cookies, giving them access to the user’s account. The vulnerability has been assigned CVE-2024-44000 and was fixed in version 6.5.0.1 of the plugin.

The vulnerable code exists in the ended() function:

/**
	* End call of one request process
	* @since 4.7
	* @access public
	*/
public static function ended()
{
	self::debug('Response headers', headers_list());

	$elapsed_time = number_format((microtime(true) - LSCWP_TS_0) * 1000, 2);
	self::debug("End response\n--------------------------------------------------Duration: " . $elapsed_time . " ms------------------------------\n");
}

This function calls self::debug() with headers_list() as the parameter, which retrieves and logs all HTTP response headers, including Set-Cookie headers used during login. As a result, the session cookies are written into the debug logs.

The ended() function is triggered by the send_headers_force() function, which runs from the init hook. Additionally, there’s a plugin setting that logs cookies (Log Cookies), further exposing session data if enabled.

Here’s an example from the _init_request() function:

private function _init_request($log_file = null)
{
	if (!$log_file) {
		$log_file = self::$log_path;
	}

	// Check log file size
	$log_file_size = $this->conf(Base::O_DEBUG_FILESIZE);
	if (file_exists($log_file) && filesize($log_file) > $log_file_size * 1000000) {
		File::save($log_file, '');
	}

	// For more than 2s's requests, add more break
	if (file_exists($log_file) && time() - filemtime($log_file) > 2) {
		File::append($log_file, "\n\n\n\n");
	}

	if (PHP_SAPI == 'cli') {
		return;
	}

	$servervars = array(
		'Query String' => '',
		'HTTP_ACCEPT' => '',
		'HTTP_USER_AGENT' => '',
		'HTTP_ACCEPT_ENCODING' => '',
		'HTTP_COOKIE' => '',
		'REQUEST_METHOD' => '',
		'SERVER_PROTOCOL' => '',
		'X-LSCACHE' => '',
		'LSCACHE_VARY_COOKIE' => '',
		'LSCACHE_VARY_VALUE' => '',
		'ESI_CONTENT_TYPE' => '',
	);
	$server = array_merge($servervars, $_SERVER);
	$params = array();

	if (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on') {
		$server['SERVER_PROTOCOL'] .= ' (HTTPS) ';
	}

	$param = sprintf('💓 ------%s %s %s', $server['REQUEST_METHOD'], $server['SERVER_PROTOCOL'], strtok($server['REQUEST_URI'], '?'));

	$qs = !empty($server['QUERY_STRING']) ? $server['QUERY_STRING'] : '';
	if ($this->conf(Base::O_DEBUG_COLLAPSE_QS)) {
		$qs = $this->_omit_long_message($qs);
		if ($qs) {
			$param .= ' ? ' . $qs;
		}
		$params[] = $param;
	} else {
		$params[] = $param;
		$params[] = 'Query String: ' . $qs;
	}

	if (!empty($_SERVER['HTTP_REFERER'])) {
		$params[] = 'HTTP_REFERER: ' . $this->_omit_long_message($server['HTTP_REFERER']);
	}

	if (defined('LSCWP_LOG_MORE')) {
		$params[] = 'User Agent: ' . $this->_omit_long_message($server['HTTP_USER_AGENT']);
		$params[] = 'Accept: ' . $server['HTTP_ACCEPT'];
		$params[] = 'Accept Encoding: ' . $server['HTTP_ACCEPT_ENCODING'];
	}
	if ($this->conf(Base::O_DEBUG_COOKIE)) {
		$params[] = 'Cookie: ' . $server['HTTP_COOKIE'];
	}
	if (isset($_COOKIE['_lscache_vary'])) {
		$params[] = 'Cookie _lscache_vary: ' . $_COOKIE['_lscache_vary'];
	}
	if (defined('LSCWP_LOG_MORE')) {
		$params[] = 'X-LSCACHE: ' . (!empty($server['X-LSCACHE']) ? 'true' : 'false');
	}
	if ($server['LSCACHE_VARY_COOKIE']) {
		$params[] = 'LSCACHE_VARY_COOKIE: ' . $server['LSCACHE_VARY_COOKIE'];
	}
	if ($server['LSCACHE_VARY_VALUE']) {
		$params[] = 'LSCACHE_VARY_VALUE: ' . $server['LSCACHE_VARY_VALUE'];
	}
	if ($server['ESI_CONTENT_TYPE']) {
		$params[] = 'ESI_CONTENT_TYPE: ' . $server['ESI_CONTENT_TYPE'];
	}

	$request = array_map(__CLASS__ . '::format_message', $params);

	File::append($log_file, $request);
}

In this code, if this->conf(Base::O_DEBUG_COOKIE) is enabled, the HTTP_COOKIE value is appended to the $params[] array and written into the debug log file.

Exploit Conditions

This vulnerability can only be exploited if specific conditions are met:

1. The debug log feature is active in the LiteSpeed Cache plugin.
2. Debug logging has been enabled previously (even if currently disabled), and the /wp-content/debug.log file has not been purged or removed.

Both of these logs were active on the server at the time. The developer had enabled them to troubleshoot caching issues, as some files weren't being cached properly or weren't functioning as expected after installing the plugins. Unbeknownst to the developer, our caching was already being handled by Cloudflare.

Timeline

• • August 22, 2024: John Blackbourn uncovered a vulnerability in the LiteSpeed Cache plugin, and I promptly reached out to the LiteSpeed team regarding the issue.

  • September 4, 2024 - 18:34: The first signs of unusual activity appeared on the website, including suspicious changes to plugins and settings.

  • September 4, 2024 - 19:01: Our team, along with the WordPress security plugin, received an alert indicating "file change detected."

  • September 4, 2024 - 19:13: The team was fully alerted, and the issue was escalated for further investigation.

  • September 4, 2024 - 19:30: After reviewing logs, we confirmed that plugin and file changes were being made without authorization.

  • September 4, 2024 - 19:45: The team began systematically turning off WordPress plugins and themes to isolate the source of the issue.

  • September 4, 2024 - 20:15: We discovered that debug mode had been left enabled on the production environment by a developer, which may have contributed to the vulnerability.

  • September 4, 2024 - 21:00: After further investigation, we noticed LiteSpeed Cache had been installed, and upon inquiry, a developer confirmed they installed it to improve caching, unaware of the existing Cloudflare caching setup.

  • September 4, 2024 - 21:45: I disconnected all users from the website to stop any ongoing unauthorized changes.

  • September 4, 2024 - 22:00: The website was brought back online, and normal Hasbara operations resumed.

  • September 5, 2024: Patchstack.com released an article about the vulnerability, which confirmed our belief that this was the entry point for the attackers.

How do we know they are from Iran?

To answer that, we first need to understand why our website was accessible to Iran. As everyone knows, Iran is a well-known adversary of Israel. Our website is a Hasbara platform with the primary goal of presenting the truth about the war in Israel. We aimed to reach as many people as possible from different countries, which is why we didn't restrict our Web Application Firewall (WAF) by country.

While we conducted thorough checks using Bot Management variables to verify that requests from suspicious regions were not malicious, one thing we didn’t have in place was strict access control on the WordPress admin dashboard. This left us vulnerable.

Our goal is to ensure our message reaches a global audience, but we must also take extra precautions to prevent adversaries like Iran from exploiting our platform. Moving forward, we will ensure stricter security measures are in place to protect against such threats.

And now back to the question: is the IP :) 

Why was this website targeted?

As I mentioned earlier, this attack required specific conditions to be met, and the attacker had to act within a particular timeline. This suggests that the attacker was actively monitoring our website, waiting for vulnerabilities to appear. They likely compared potential weaknesses in widely used WordPress plugins—ones that had not been publicly disclosed but were circulating in forums or on the dark web.

Our website, an Israeli Hasbara site focused (one of the largest websites with more than 7,000 pages) on the ongoing Iron Swords War, the site has been a target due to its mission of sharing the truth about the conflict.
The war began on October 7, following the massacre carried out by Palestinian Hamas, which further highlights why adversaries, like those from Iran, would seek to exploit any available vulnerabilities to disrupt our operations.

Why I'm happy about this?

Surprisingly, I see a silver lining in this attack. The fact that someone invested time and effort to monitor and target my website shows that it’s having an impact.
It means my website is making significant strides in its mission to showcase and document the truth about this war. If adversaries feel the need to try and silence us, it’s a sign that we’re successfully reaching people and making a difference.

Check out the website

BringThemBackHomeNOW!