labs.watchtowr.com Open in urlscan Pro
2a04:4e42:600::775  Public Scan

Form analysis
0 forms found in the DOM

Text Content

 * Home
 * Platform
 * Vuln. Disclosure Policy
 * Contact


By — Aliz Hammond — Sina Kheirkhah   —   Jun 7, 2024


NO WAY, PHP STRIKES AGAIN! (CVE-2024-4577)

Orange Tsai tweeted a few hours ago about “One of [his] PHP vulnerabilities,
which affects XAMPP by default”, and we were curious to say the least. XAMPP is
a very popular way for administrators and developers to rapidly deploy Apache,
PHP, and a bunch of other tools, and any bug that could give us RCE in its
default installation sounds pretty tantalizing.

Fortunately, for defenders, the bug has only been exploited on Windows-based PHP
installations (where PHP is specifically used in CGI mode), under some specific
locales:

 * Chinese (both simplified and traditional), and
 * Japanese.

However, Orange cautions that other locales could be affected too, and urges
users to upgrade to the latest version of PHP, which fixes these bugs (for
detail, see their blogpost).

> We are keen to point out that we are unsure how common this configuration, or
> deployment type, is in reality. It is also not our job to find out, outside of
> our client base. But, regardless, it's an interesting vulnerability due to the
> root cause. Enjoy with us.

Orange's blogpost, while informative, doesn’t tell us exactly what to do to get
that sweet RCE. Unfortunately, the wide range of configuration options makes it
difficult to conclusively prove an instance to be vulnerable (or not) at a
passive glance and, obviously, because a Windows machine's 'locale' is not
typically externally fingerprintable. Because of this, we set about reproducing
the bug—if we can exploit it, that’s the best way of proving exploitability,
right?

Reading Orange's blog, it is clear that the bug only affects CGI mode of PHP. In
this mode, the webserver parses HTTP requests and passes them to a PHP script,
which then performs some processing on them. For example, querystrings are
parsed and passed to the PHP interpreter on the command line - a request such as
as http://host/cgi.php?foo=bar might be executed as php.exe cgi.php foo=bar, for
example.

This does, of course, introduce an avenue for command injection, which is why
input is carefully handled and sanitized before calling php.exe (cough
CVE-2012-1823). However, it seems there is a corner-case which the developers
did not account for, which allows an attacker to break out of the command line
and supply arguments that are interpreted by PHP itself. This corner-case
relates to how unicode characters are converted into ASCII. This is best
explained with an example.

Here are two invocations of php.exe, one malicious and one benign. Can you spot
the difference?

No, neither can I. Let’s look at then in a hex editor and see if that give us
any clue.

Hmm, interesting - here we can see that the first invocation uses a normal dash
(0x2D), while the second, it seems, uses something else entirely (a ‘soft
hyphen,’ apparently), with the code 0xAD (highlighted). While they both appear
the same to you and me, they have vastly different meanings to the OS.

An important detail here is that Apache will escape the actual hyphen - 0x2D -
but not the second ‘soft hyphen’, 0xAD. After all, it’s not a real hyphen,
right? So there’s no need to escape it… right?

We don't care if it's the same joke as above, it's still funny.

Well. 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

<?php
phpinfo();
?>
 


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


CONCLUSIONS

A nasty bug with a very simple exploit - perfect for a Friday afternoon.

Fortunately, though, patches are available, so we echo Orange Tsai’s advice to
upgrade your PHP installation. As always, fantastic work and a salute to Orange
Tsai.

Those running in an affected configuration under one of the affected locales -
Chinese (simplified, or traditional) or Japanese - are urged to do this as fast
as humanely possible, as the bug has a high chance of being exploited en-mass
due to the low exploit complexity. Other users are still strongly encouraged to
update:

> For Windows running in other locales such as English, Korean, and Western
> European, due to the wide range of PHP usage scenarios, it is currently not
> possible to completely enumerate and eliminate all potential exploitation
> scenarios. Therefore, it is recommended that users conduct a comprehensive
> asset assessment, verify their usage scenarios, and update PHP to the latest
> version to ensure security.

We won’t duplicate the advisory here, instead, we advise those individuals
seeking remediation advice to refer to the comprehensive advisory.

At watchTowr, we believe continuous security testing is the future, enabling the
rapid identification of holistic high-impact vulnerabilities that affect your
organisation.

It's our job to understand how emerging threats, vulnerabilities, and TTPs
affect your organisation.

If you'd like to learn more about the watchTowr Platform, our Attack Surface
Management and Continuous Automated Red Teaming solution, please get in touch.

Previous post

CHECK POINT - WRONG CHECK POINT (CVE-2024-24919)


Next post

AUTH. BYPASS IN (UN)LIMITED SCENARIOS - PROGRESS MOVEIT TRANSFER (CVE-2024-5806)

watchTowr Labs - Blog © 2024

Powered by Ghost