LimeSurvey is an open source and commercial web application written in PHP that enables its users to quickly design and setup scalable surveys. Last year, we scanned the at that time latest version 2.72.3 with our static code analysis tool RIPS. In this technical post we will discuss and present two of the automatically detected vulnerabilities in 1MLOC: An unauthenticated persistent cross-site scripting vulnerability in the continue later feature and an authenticated arbitrary file write vulnerability. Both vulnerabilities can be chained by an attacker in order to execute code on the targeted web server with only one payload.

Unauthenticated Persistent Cross-Site Scripting

LimeSurvey 2.72.3 is prone to a persistent cross-site scripting vulnerability which is exploitable through the unauthenticated perspective. When submitting a public survey, the Continue Later feature allows users to save their partially completed survey repose and reload it at a later time. In order to identify the returning user, he provides an email address and a password when saving his response. This email address is persistently displayed unsanitized in the admin panel’s HTML context allowing the execution of malicious JavaScript.

application/views/admin/saved/savedlist_view.php

4647

<td><a href='mailto: <?php echo $oResult->email; ?>'>
<?php echo $oResult->email; ?></td>

The JavaScript is executed in the browser of an authenticated victim who is visiting a specially crafted link or who is viewing the partially saved repose data in the administrator’s control panel. Through this vulnerability the attacker can perform actions in the name of the victim and therefore gains access to the authenticated perspective of the web application which allows the adversary to leverage the next vulnerability.

Authenticated Arbitrary File Write

The exploitation of this vulnerability is only possible if the attacker can read, update and import templates¹. The attacker imports a new template by uploading a zip file containing a single config.xml file. The XML file specifies the path of the file to be modified:

template.zip/config.xml

 1 2 3 4 5 6 7 8 910111213141516171819202122232425262728293031

<?xml version="1.0" encoding="UTF-8"?>
<config>
    <files>
        <css>
        	<filename>../../../index.php</filename>
        </css>
        <js>
        </js>
        <print_css>
        </print_css>
        <rtl>
            <css>
                <filename>../../../index.php</filename>
            </css>
            <js></js>
		<print_css></print_css>
        </rtl>
        <logo>
            <filename>files/logo.png</filename>
        </logo>
    </files>
    <files_editable>
            <css>
                <filename>../../../index.php</filename>
            </css>
            <js>
            </js>
    </files_editable>
    <engine>
    </engine>
</config>

In this particular example the attacker modifies the index.php file of the LimeSurvey web root by using the built-in template file editor. This is possible because the web application does not properly sanitize the filenames which are passed within the <files_editable>-tag. Therefore a path traversal attack will mislead the application logic to treat the index.php of the web root as an editable file of the template. The following method templatesave_changes() is invoked when processing modifications to the template through the built-in template editor.

application/controllers/admin/templates.php

606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645

public function templatesavechanges()
{
	⋮
	if (returnGlobal('changes')) {
		$changedtext = returnGlobal('changes');
		$changedtext = str_replace('<?', '', $changedtext);
		if (get_magic_quotes_gpc())
			$changedtext = stripslashes($changedtext);
	}
	⋮
	$editfile        = returnGlobal('editfile');	
	$aScreenFiles    = $this->getValidScreenFiles($sTemplateName);
	$cssfiles        = $this->_initcssfiles($oEditedTemplate);
	$jsfiles         = $this->_getEditableJsFiles($oEditedTemplate);
	⋮
// Check if someone tries to submit a file other than one of the allowed
		if (in_array($editfile,$aScreenFiles)===false &&
		    in_array($editfile,$cssfiles)===false &&
		    in_array($editfile,$jsfiles)===false)
		{
			⋮		// throw error
		}
		$savefilename =gettemplatefixlename(Yii::app()->getConfig('user
templaterootdir') . "/" . $sTemplateName, $editfile);

		if (is_writable($savefilename))
		{
			if (!$handle = fopen($savefilename, 'w'))
			{
				⋮	// throw error
			}
			if (!fwrite($handle, $changedtext))
			{
				⋮	// throw error
			}
			⋮
			fclose($handle);
		}
	⋮
}

On line 610 the new content of the file is received through the parameter changes. The variable $editfile holds the name of the file and is received on line 616. The if statement ranging from line 622 to line 624 is the only check to prevent an attacker from changing files which are not part of the template. By previously importing the malicious template, the array $cssfiles will contain the file index.php causing the check to complete successfully and the file is finally opened and written to on line 633 and 637 respectively.

Time Line

Impact & Summary: What can an attacker do?

The vulnerability chaining in LimeSurvey 2.72.3 yields a single final exploit which would add malicious JavaScript code to the admin panel through the Continue Later functionality of a public survey. As soon as the JavaScript payload is executed in the administrator context it can exploit the arbitrary file write vulnerability to give the adversary persistent shell access to the operating system remotely to maximize impact. Our proof of concept has shown that an unauthenticated attacker can chain multiple vulnerabilities to gain access to the remote system without user interaction. We thank LimeSurvey for the very fast reaction and patch and highly recommend to update to the latest version 3.