php

ransomware-attackers-quickly-weaponize-php-vulnerability-with-9.8-severity-rating

Ransomware attackers quickly weaponize PHP vulnerability with 9.8 severity rating

FILES LOCKED —

TellYouThePass group opportunistically infects servers that have yet to update.

Photograph depicts a security scanner extracting virus from a string of binary code. Hand with the word

Getty Images

Ransomware criminals have quickly weaponized an easy-to-exploit vulnerability in the PHP programming language that executes malicious code on web servers, security researchers said.

As of Thursday, Internet scans performed by security firm Censys had detected 1,000 servers infected by a ransomware strain known as TellYouThePass, down from 1,800 detected on Monday. The servers, primarily located in China, no longer display their usual content; instead, many list the site’s file directory, which shows all files have been given a .locked extension, indicating they have been encrypted. An accompanying ransom note demands roughly $6,500 in exchange for the decryption key.

The output of PHP servers infected by TellYouThePass ransomware.

Enlarge / The output of PHP servers infected by TellYouThePass ransomware.

Censys

The accompanying ransom note.

Enlarge / The accompanying ransom note.

Censys

When opportunity knocks

The vulnerability, tracked as CVE-2024-4577 and carrying a severity rating of 9.8 out of 10, stems from errors in the way PHP converts Unicode characters into ASCII. A feature built into Windows known as Best Fit allows attackers to use a technique known as argument injection to convert user-supplied input into characters that pass malicious commands to the main PHP application. Exploits allow attackers to bypass CVE-2012-1823, a critical code execution vulnerability patched in PHP in 2012.

CVE-2024-4577 affects PHP only when it runs in a mode known as CGI, in which a web server parses HTTP requests and passes them to a PHP script for processing. Even when PHP isn’t set to CGI mode, however, the vulnerability may still be exploitable when PHP executables such as php.exe and php-cgi.exe are in directories that are accessible by the web server. This configuration is extremely rare, with the exception of the XAMPP platform, which uses it by default. An additional requirement appears to be that the Windows locale—used to personalize the OS to the local language of the user—must be set to either Chinese or Japanese.

The critical vulnerability was published on June 6, along with a security patch. Within 24 hours, threat actors were exploiting it to install TellYouThePass, researchers from security firm Imperva reported Monday. The exploits executed code that used the mshta.exe Windows binary to run an HTML application file hosted on an attacker-controlled server. Use of the binary indicated an approach known as living off the land, in which attackers use native OS functionalities and tools in an attempt to blend in with normal, non-malicious activity.

In a post published Friday, Censys researchers said that the exploitation by the TellYouThePass gang started on June 7 and mirrored past incidents that opportunistically mass scan the Internet for vulnerable systems following a high-profile vulnerability and indiscriminately targeting any accessible server. The vast majority of the infected servers have IP addresses geolocated to China, Taiwan, Hong Kong, or Japan, likely stemming from the fact that Chinese and Japanese locales are the only ones confirmed to be vulnerable, Censys researchers said in an email.

Since then, the number of infected sites—detected by observing the public-facing HTTP response serving an open directory listing showing the server’s filesystem, along with the distinctive file-naming convention of the ransom note—has fluctuated from a low of 670 on June 8 to a high of 1,800 on Monday.

Image tracking day-to-day compromises of PHP servers and their geolocation.

Enlarge / Image tracking day-to-day compromises of PHP servers and their geolocation.

Censys

Censys researchers said in an email that they’re not entirely sure what’s causing the changing numbers.

“From our perspective, many of the compromised hosts appear to remain online, but the port running the PHP-CGI or XAMPP service stops responding—hence the drop in detected infections,” they wrote. “Another point to consider is that there are currently no observed ransom payments to the only Bitcoin address listed in the ransom notes (source). Based on these facts, our intuition is that this is likely the result of those services being decommissioned or going offline in some other manner.”

XAMPP used in production, really?

The researchers went on to say that roughly half of the compromises observed show clear signs of running XAMPP, but that estimate is likely an undercount since not all services explicitly show what software they use.

“Given that XAMPP is vulnerable by default, it’s reasonable to guess that most of the infected systems are running XAMPP,” the researchers said. This Censys query lists the infections that are explicitly affecting the platform. The researchers aren’t aware of any specific platforms other than XAMPP that have been compromised.

The discovery of compromised XAMPP servers took Will Dormann, a senior vulnerability analyst at security firm Analygence, by surprise because XAMPP maintainers explicitly say their software isn’t suitable for production systems.

“People choosing to run not-for-production software have to deal with the consequences of that decision,” he wrote in an online interview.

While XAMPP is the only platform confirmed to be vulnerable, people running PHP on any Windows system should install the update as soon as possible. The Imperva post linked above provides IP addresses, file names, and file hashes that administrators can use to determine whether they have been targeted in the attacks.

Ransomware attackers quickly weaponize PHP vulnerability with 9.8 severity rating Read More »

nasty-bug-with-very-simple-exploit-hits-php-just-in-time-for-the-weekend

Nasty bug with very simple exploit hits PHP just in time for the weekend

WORST FIT EVER —

With PoC code available and active Internet scans, speed is of the essence.

Nasty bug with very simple exploit hits PHP just in time for the weekend

A critical vulnerability in the PHP programming language can be trivially exploited to execute malicious code on Windows devices, security researchers warned as they urged those affected to take action before the weekend starts.

Within 24 hours of the vulnerability and accompanying patch being published, researchers from the nonprofit security organization Shadowserver reported Internet scans designed to identify servers that are susceptible to attacks. That—combined with (1) the ease of exploitation, (2) the availability of proof-of-concept attack code, (3) the severity of remotely executing code on vulnerable machines, and (4) the widely used XAMPP platform being vulnerable by default—has prompted security practitioners to urge admins check to see if their PHP servers are affected before starting the weekend.

When “Best Fit” isn’t

“A nasty bug with a very simple exploit—perfect for a Friday afternoon,” researchers with security firm WatchTowr wrote.

CVE-2024-4577, as the vulnerability is tracked, stems from errors in the way PHP converts unicode characters into ASCII. A feature built into Windows known as Best Fit allows attackers to use a technique known as argument injection to pass user-supplied input into commands executed by an application, in this case, PHP. Exploits allow attackers to bypass CVE-2012-1823, a critical code execution vulnerability patched in PHP in 2012.

“While implementing PHP, the team did not notice the Best-Fit feature of encoding conversion within the Windows operating system,” researchers with Devcore, the security firm that discovered CVE-2024-4577, wrote. “This oversight allows unauthenticated attackers to bypass the previous protection of CVE-2012-1823 by specific character sequences. Arbitrary code can be executed on remote PHP servers through the argument injection attack.”

CVE-2024-4577 affects PHP only when it runs in a mode known as CGI, in which a web server parses HTTP requests and passes them to a PHP script for processing. Even when PHP isn’t set to CGI mode, however, the vulnerability may still be exploitable when PHP executables such as php.exe and php-cgi.exe are in directories that are accessible by the web server. This configuration is set by default in XAMPP for Windows, making the platform vulnerable unless it has been modified.

One example, WatchTowr noted, occurs when queries are parsed and sent through a command line. The result: a harmless request such as http://host/cgi.php?foo=bar could be converted into php.exe cgi.php foo=bar, a command that would be executed by the main PHP engine.

No escape

Like many other languages, PHP converts certain types of user input to prevent it from being interpreted as a command for execution. This is a process known as escaping. For example, in HTML, the < and > characters are often escaped by converting them into their unicode hex value equivalents < and > to prevent them from being interpreted as HTML tags by a browser.

The WatchTowr researchers demonstrate how Best Fit fails to escape characters such as a soft hyphen (with unicode value 0xAD) and instead converts it to an unescaped regular hyphen (0x2D), a character that’s instrumental in many code syntaxes.

The researchers went on to explain:

It turns out that, as part of unicode processing, PHP will apply what’s known as a ‘best fit’ mapping, and helpfully assume that, when the user entered a soft hyphen, they actually intended to type a real hyphen, and interpret it as such. Herein lies our vulnerability—if we supply a CGI handler with a soft hyphen (0xAD), the CGI handler won’t feel the need to escape it, and will pass it to PHP. PHP, however, will interpret it as if it were a real hyphen, which allows an attacker to sneak extra command line arguments, which begin with hyphens, into the PHP process.

This is remarkably similar to an older PHP bug (when in CGI mode), CVE-2012-1823, and so we can borrow some exploitation techniques developed for this older bug and adapt them to work with our new bug. A helpful writeup advises that, to translate our injection into RCE, we should aim to inject the following arguments:

-d allow_url_include=1 -d auto_prepend_file=php://input  

This will accept input from our HTTP request body, and process it using PHP. Straightforward enough – let’s try a version of this equipped with our 0xAD ‘soft hyphen’ instead of the usual hyphen. Maybe it’s enough to slip through the escaping?

POST /test.php?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input HTTP/1.1  Host: host  User-Agent: curl/8.3.0  Accept: */Content-Length: 23  Content-Type: application/x-www-form-urlencoded  Connection: keep-alive       

Oh joy—we’re rewarded with a phpinfo page, showing us we have indeed achieved RCE.

The vulnerability was discovered by Devcore researcher Orange Tsai, who said: “The bug is incredibly simple, but that’s also what makes it interesting.”

The Devcore writeup said that the researchers have confirmed that XAMPP is vulnerable when Windows is configured to use the locales for Traditional Chinese, Simplified Chinese, or Japanese. In Windows, a locale is a set of user preference information related to the user’s language, environment, and/or cultural conventions. The researchers haven’t tested other locales and have urged people using them to perform a comprehensive asset assessment to test their usage scenarios.

CVE-2024-4577 affects all versions of PHP running on a Windows device. That includes version branches 8.3 prior to 8.3.8, 8.2 prior to 8.2.20, and 8.1 prior to 8.1.29.

The 8.0, 7, and 5 version branches are also vulnerable, but since they’re no longer supported, admins will have to follow mitigation advice since patches aren’t available. One option is to apply what are known as rewrite rules such as:

RewriteEngine On  RewriteCond %QUERY_STRING ^%ad [NC]  RewriteRule .? - [F,L]

The researchers caution these rules have been tested only for the three locales they have confirmed as vulnerable.

XAMPP for Windows had yet to release a fix at the time this post went live. For admins without the need for PHP CGI, they can turn it off using the following Apache HTTP Server configuration:

C:/xampp/apache/conf/extra/httpd-xampp.conf

Locating the corresponding lines:

ScriptAlias /php-cgi/ "C:/xampp/php/"  

And comment it out:

# ScriptAlias /php-cgi/ "C:/xampp/php/"  

Additional analysis of the vulnerability is available here.

Nasty bug with very simple exploit hits PHP just in time for the weekend Read More »

i-abandoned-openlitespeed-and-went-back-to-good-ol’-nginx

I abandoned OpenLiteSpeed and went back to good ol’ Nginx

Adventures in server babysitting —

One weather site’s sudden struggles, and musings on why change isn’t always good.

Ish is on fire, yo.

Enlarge / Ish is on fire, yo.

Since 2017, in what spare time I have (ha!), I help my colleague Eric Berger host his Houston-area weather forecasting site, Space City Weather. It’s an interesting hosting challenge—on a typical day, SCW does maybe 20,000–30,000 page views to 10,000–15,000 unique visitors, which is a relatively easy load to handle with minimal work. But when severe weather events happen—especially in the summer, when hurricanes lurk in the Gulf of Mexico—the site’s traffic can spike to more than a million page views in 12 hours. That level of traffic requires a bit more prep to handle.

Space City Weather!” data-height=”2008″ data-width=”2560″ href=”https://cdn.arstechnica.net/wp-content/uploads/2024/01/Screenshot-2024-01-24-at-9.02.05%E2%80%AFAM.jpg”>Hey, it's <a href=Space City Weather!” height=”235″ src=”https://cdn.arstechnica.net/wp-content/uploads/2024/01/Screenshot-2024-01-24-at-9.02.05%E2%80%AFAM.jpg” width=”300″>

Lee Hutchinson

For a very long time, I ran SCW on a backend stack made up of HAProxy for SSL termination, Varnish Cache for on-box caching, and Nginx for the actual web server application—all fronted by Cloudflare to absorb the majority of the load. (I wrote about this setup at length on Ars a few years ago for folks who want some more in-depth details.) This stack was fully battle-tested and ready to devour whatever traffic we threw at it, but it was also annoyingly complex, with multiple cache layers to contend with, and that complexity made troubleshooting issues more difficult than I would have liked.

So during some winter downtime two years ago, I took the opportunity to jettison some complexity and reduce the hosting stack down to a single monolithic web server application: OpenLiteSpeed.

Out with the old, in with the new

I didn’t know too much about OpenLiteSpeed (“OLS” to its friends) other than that it’s mentioned a bunch in discussions about WordPress hosting—and since SCW runs WordPress, I started to get interested. OLS seemed to get a lot of praise for its integrated caching, especially when WordPress was involved; it was purported to be quite quick compared to Nginx; and, frankly, after five-ish years of admining the same stack, I was interested in changing things up. OpenLiteSpeed it was!

check my blog. Yeah, I still have a blog. I’m old.” data-height=”1442″ data-width=”2318″ href=”https://cdn.arstechnica.net/wp-content/uploads/2024/01/Screen-Shot-2022-06-09-at-6.37.47-AM-1.jpg”>The OLS admin console, showing vhosts. This is from my personal web server rather than the Space City Weather server, but it looks the same. If you want some deeper details on the OLS config I was using, <a href=check my blog. Yeah, I still have a blog. I’m old.” height=”398″ src=”https://cdn.arstechnica.net/wp-content/uploads/2024/01/Screen-Shot-2022-06-09-at-6.37.47-AM-1.jpg” width=”640″>

Enlarge / The OLS admin console, showing vhosts. This is from my personal web server rather than the Space City Weather server, but it looks the same. If you want some deeper details on the OLS config I was using, check my blog. Yeah, I still have a blog. I’m old.

Lee Hutchinson

The first significant adjustment to deal with was that OLS is primarily configured through an actual GUI, with all the annoying potential issues that brings with it (another port to secure, another password to manage, another public point of entry into the backend, more PHP resources dedicated just to the admin interface). But the GUI was fast, and it mostly exposed the settings that needed exposing. Translating the existing Nginx WordPress configuration into OLS-speak was a good acclimation exercise, and I eventually settled on Cloudflare tunnels as an acceptable method for keeping the admin console hidden away and notionally secure.

Just a taste of the options that await within the LiteSpeed Cache WordPress plugin.

Enlarge / Just a taste of the options that await within the LiteSpeed Cache WordPress plugin.

Lee Hutchinson

The other major adjustment was the OLS LiteSpeed Cache plugin for WordPress, which is the primary tool one uses to configure how WordPress itself interacts with OLS and its built-in cache. It’s a massive plugin with pages and pages of configurable options, many of which are concerned with driving utilization of the Quic.Cloud CDN service (which is operated by LiteSpeed Technology, the company that created OpenLiteSpeed and its for-pay sibling, LiteSpeed).

Getting the most out of WordPress on OLS meant spending some time in the plugin, figuring out which of the options would help and which would hurt. (Perhaps unsurprisingly, there are plenty of ways in there to get oneself into stupid amounts of trouble by being too aggressive with caching.) Fortunately, Space City Weather provides a great testing ground for web servers, being a nicely active site with a very cache-friendly workload, and so I hammered out a starting configuration with which I was reasonably happy and, while speaking the ancient holy words of ritual, flipped the cutover switch. HAProxy, Varnish, and Nginx went silent, and OLS took up the load.

I abandoned OpenLiteSpeed and went back to good ol’ Nginx Read More »