LimeSurvey 2.72.3 - Persistent XSS to Code Execution10 Apr 2018 by Robin Peraglie
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 (CVE-2017-18358) 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
Authenticated Arbitrary File Write
The exploitation of this vulnerability is only possible if the attacker can read, update and import templates1. 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:
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.
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
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
|2017/11/08||Provided vulnerability details and PoC to vendor|
|2017/11/08||Vendor acknowledged and fixes cross-site scripting|
|2017/11/10||Fixed version released|
Impact & Summary: What can an attacker do?