PfSense XSS vulnerability analysis

PfSense XSS vulnerability analysis

PfSense is an open-source network firewall software based on FreeBSD operating system. It has been widely used by companies around the world to protect its infrastructure.
Last year, we found some security vulnerabilities in PfSense (reported by the red/Black Alliance) and submitted them to the PfSense security team. So far, more than a year has passed. This time is enough for companies and individuals who use PfSense to upgrade to the latest version through patching. Therefore, we intend to make these vulnerabilities public so that security researchers can share information with each other.

In this article, we will introduce the CVE-2014-4687 vulnerability found in pfSense, which only exists in versions 2.1.3 and below, and has been fixed in later versions.

0 × 01 storage XSS in the Schedules Interface

If you click Schedules, you will see the following Web interface.

 
Figure 1 Schedules page

After the page is opened, you can click the + button to add a timetable. In this process, we can change the value of the POST parameter starttime0 to 0: 00 '> alert (1 );

Figure 2 malicious JavaScript requests sent to the server

Then, the entered JavaScript code is written to the response without any encapsulation of special characters. Shows the response content.

Figure 3 malicious JavaScript code in response

Once this request is displayed in a Web browser, it becomes an XSS vulnerability because the JavaScript code is executed by the browser, as shown in.

Figure 4 JavaScript code executed by the browser

This vulnerability allows you to execute arbitrary JavaScript code in your Web browser, so it can be used to steal users' session cookies.

0 × 02 storage XSS vulnerability in Rss. widget. php file

In the PHP script widgets/rss. widget. php, there is a stored XSS vulnerability. More specifically, this vulnerability is located in the POST parameter named rssfeed. The Code related to this vulnerability is as follows. The highlighted part is the code of the vulnerability.

 php  if($POST[rssfeed]) {  $config[widgets][rssfeed] = str_replace(n, ,, $POST[rssfeed]);  $config[widgets][rssmaxitems] = str_replace(n, ,,POST[rssmaxitems]);  $config[widgets][rsswidgetheight] = $POST[rsswidgetheight];  $config[widgets][rsswidgettextlength] = $POST[rsswidgettextlength];  writeconfig(Saved RSS Widget feed via Dashboard);  Header(Location: /);  }  if($config[widgets][rssfeed])  $textareatxt = strreplace(,, n, $config[widgets][rssfeed]);  else  $textareatxt = "";  ?>   name="rssfeed" class="formfld unknown" id="rssfeed"ols="40" rows="3">  $textareatxt;?>

 
The request shown below will be sent to the corresponding Web server by malicious JavaScript code in the POST parameter named rssfeed.

Figure 5 malicious JavaScript code in the POST parameter rssfeed

The returned response contains the following code, and the special characters are not properly processed.

Figure 6 malicious JavaScript code sent before is directly put into the returned Web page

The POST parameters shown below also have security vulnerabilities, and they are all in the same script:
-Rssmaxitems
-Rsswidgetheight
-Rsswidgettextlength
-Rsswidgettextlength

Attackers can send malicious JavaScript code to a Web application, and the application will store the code in the page and return it to other users.

0 × 03 reflective XSS in Services_status.widget.php script

We found that the widgets/services_status.widget.php script does not properly encapsulate user data. For example, for the following code, we can directly assign the POST variable servicestatusfilter to $ config [widgets '] [servicestatusfilter]', this script does not sanitize user input. Then, we can use HTML code to display the value of this variable.

php  if(isset($_POST['servicestatusfilter'])) {  $config['widgets']['servicestatusfilter'] =_POST['servicestatusfilter'];  write_config("Saved Service Status Filter via Dashboard");  header("Location: ../../index.php");  }  ?>  config['widgets']['servicestatusfilter'] ?>" />

The following request contains a POST parameter servicestatusfilter with the value "/> alert (1 );

Figure 7 malicious JavaScript code in the POST parameter servicestatusfilter

Through observation, we can find that the response value is exactly the same as the previous value.

Figure 8 malicious JavaScript code in the POST parameter rssfeed

It should be noted that the JavaScript code here is not executed in the Web browser, because a Location header is provided here, so the JavaScript code is redirected before execution. However, this is still a security vulnerability and must be fixed. Attackers can use it to execute arbitrary JavaScript code in users' browsers.

XSS vulnerability in HTTP header Referer in 0 × 04 Log. widget. php script

An XSS vulnerability exists in the widgets/log. widget. php script, as shown in the code. The Referer in the HTTP header is read into the variable $ filename, which is then placed in the response page, but no special characters are encoded.

$filename = $_SERVER['HTTP_REFERER'];if(headers_sent($file, $line)){echo '';echo '//;echo 'window.location.href="'.$filename.'";';echo '//]]>';echo '';echo '';echo '.$filename.'" />';echo '';}

If we use the HTTP header Referer to send a string, we will receive the following response, indicating that a problem has occurred, the reason is that the strings in the HTTP Referer header do not match those set by the system.

Figure 9 response when a referer is sent using the HTTP Header

This is because Pfsense implements HTTP_REFERER redirection detection and the default setting will block this behavior. To change this setting, you can modify it using System-Advanced-Admin settings, as shown in.

Figure 10 pfsense settings related to the HTTP header referer

We need to disable the force check HTTP_REFERER and save the corresponding settings. In this way, we can use the HTTP Referer header to send the string "/> alert (1 );

Figure 11 HTTP Referer headers contain requests with malicious JavaScipt code

In the following response, the value stored in the HTTP header Referer is displayed twice to the user.

Figure 12 malicious JavaScript code is put into the returned Web page

Because we have escaped other HTML elements, these injected JavaScript can be executed in the user's browser, as shown in.

Figure 13 malicious JavaScript Code Execution

The default Pfsense settings enable the HTTP_REFERER force check function. Therefore, this vulnerability is difficult to use. However, this vulnerability does exist, so you must perform corresponding security measures. In addition, some other POST parameters contained in the response are not properly sanitized, which makes the attack more likely. The POST parameters with security defects include:
-Filterlogentries
-Actpass
-Actblock
-Actreject
-Filterlogentriesinterfaces

In addition, attackers can inject JavaScript code into the HTTP Referer header and execute it in the user's browser.
The JavaScript injection vulnerability in The 0 × 05 Exec. php script is known as The Diagnostics: The Execute command function allows attackers to upload files to The server, as shown below.

Figure 14 File Upload

To allow users to access this function, they must be granted the corresponding permissions to access Diagnostics: Command, as shown in.

Figure 15 required permissions

When uploading files, attackers have the opportunity to inject arbitrary JavaScript code into the txtRecallBuffer parameter. As shown in, this example injects a string in txtRecallBuffer, that is, "bbb"); var arrRecalBuffer = new Array ('aaa ", as highlighted in the figure below.

 

Figure 16 malicious input data sent to the server
The response caused by the above request is as follows, which indicates that it is feasible to inject arbitrary JavaScript code.


Figure 17 the input data sent above is directly placed in the JavaScript code block

Note that we cannot exploit this vulnerability because the entire JavaScript code block is in the annotation, Which is commented out. Generally, we can try to escape the code from the annotator's curse, such as injecting the symbol> first, and then adding any code to it. In this example, we cannot do this because these two special characters are correctly encoded. In addition, JavaScript code can be injected into Web pages. In this way, attackers can execute arbitrary JavaScript code in users' browsers.

0 × 06 Summary

This article describes in detail some of the XSS vulnerabilities we have found in PfSense, hoping to help readers.