LimeSurvey 2.72.3 - Persistent XSS to Code Execution

TL;DR overview

• LimeSurvey contains a persistent cross-site scripting vulnerability that can be escalated to remote code execution by chaining it with an insecure file upload or template injection flaw.
• An attacker with survey editor access can inject malicious scripts that execute in the administrator's browser session, potentially escalating to server-side code execution through admin-only functionality.
• This vulnerability chain illustrates how client-side flaws (XSS) become server-side risks when they're exploited in admin contexts—a pattern common in CMS and web application platforms.
• LimeSurvey users should apply available patches, restrict editor access to trusted users, and enforce strict Content Security Policy headers to limit the impact of any residual XSS vectors.

LimeSurvey is an open source and commercial web application that enables its users to quickly design and setup scalable surveys. We detected two vulnerabilities in LimeSurvey < 2.72.3: An unauthenticated persistent cross-site scripting vulnerability (CVE-2017-18358) and an authenticated arbitrary file write vulnerability which can be chained. 

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

46    <td><a href='mailto: <?php echo $oResult->email; ?>'>
47    <?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

<?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

606    public function templatesavechanges()
607    {
608        ⋮
609        if (returnGlobal('changes')) {
610            $changedtext = returnGlobal('changes');
611            $changedtext = str_replace('<?', '', $changedtext);
612            if (get_magic_quotes_gpc())
613                $changedtext = stripslashes($changedtext);
614        }
615        ⋮
616        $editfile        = returnGlobal('editfile');	
617        $aScreenFiles    = $this->getValidScreenFiles($sTemplateName);
618        $cssfiles        = $this->_initcssfiles($oEditedTemplate);
619        $jsfiles         = $this->_getEditableJsFiles($oEditedTemplate);
620        ⋮
621        // Check if someone tries to submit a file other than one of the allowed
622        if (in_array($editfile,$aScreenFiles)===false &amp;&amp;
623            in_array($editfile,$cssfiles)===false &amp;&amp;
624            in_array($editfile,$jsfiles)===false)
625        {
626            ⋮    // throw error
627        }
628        $savefilename = gettemplatefixlename(
629                    Yii::app()->getConfig('usertemplaterootdir') . "/" . $sTemplateName, $editfile);
630
631        if (is_writable($savefilename))
632        {
633            if (!$handle = fopen($savefilename, 'w'))
634            {
635                ⋮    // throw error
636            }
637            if (!fwrite($handle, $changedtext))
638            {
639                ⋮    // throw error
640            }
641            ⋮
642            fclose($handle);
643        }
644        ⋮
645    }

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.

Timeline

Summary

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.