RIPS Analysis

RIPS detected many security vulnerabilities, such as SQL injection and cross-site scripting issues. In order to exploit most of these vulnerabilities in Precurio’s code base, a user account is required. Precurio also includes a lot of third-party code though that is directly accessible. These contain many vulnerabilities as well and do not require any authentication. As always, an attacker needs only a single exploitable issue for a successful attack. All third-party vulnerabilities are inside of Xinha plugins.

The truncated analysis results are available in our RIPS demo application. Please note that we limited the results to the issues described in this post since there are no fixes available.

Case Study

Path Traversal to Code Execution

The most critical vulnerability is inside the plugin of a plugin. Xinha is a WYSIWYG HTML editor and it is shipped together with ExtendedFileManager. The file manager contains example code to demonstrate how it is used. Unfortunately this example code is extremly insecure.


function makeFile($pathA, $pathB) {
    $pathA = Files::fixPath($pathA);
        $pathB = substr($pathB,1);
    Return $pathA.$pathB;


function processPaste() {
    switch ($_GET['paste']) {
        case 'copyFile':
            $src = Files::makeFile($this->getImagesDir(), $_GET['srcdir'].$_GET['file']);
            $dest = Files::makeFile($this->getImagesDir(), $_GET['dir']);
            return Files::copyFile($src,$dest,$_GET['file']);
        case 'moveFile':
            $src = Files::makeFile($this->getImagesDir(), $_GET['srcdir'].$_GET['file']);
            $dest = Files::makeFile($this->getImagesDir(), $_GET['dir'].$_GET['file']);
            return Files::rename($src,$dest);

The source and destination paths for copying and renaming a file in the ExtendedFileManager are build from a static path location and unsanitized user input. This code is vulnerable because the character sequence ../ can be used to traverse the directory structure (path traversal). As a result, attackers can point the destination of the file operations to any directory on the system. We will demonstrate how this can be abused shortly.


function escape($filename) {
    Return preg_replace('/[^\w._]/', '_', $filename);

function copyFile($source, $destination_dir, $destination_file, $unique=true) {

    $filename = Files::escape($destination_file);
    if (!copy($source, $destination_dir.$filename))
        return FILE_ERROR_COPY_FAILED;

function rename($oldPath,$newPath) {

    if (!rename($oldPath, $newPath))
        return FILE_ERROR_COPY_FAILED;

Note, that the regular expression in the escape() method prevents a path traversal within the file name while it misses to sanitize the directory. To avoid further security problems, the Xinha authors placed a .htaccess file inside of the upload directory that removes the handler for PHP files, i.e. they are not evaluated but directly displayed. This way, a direct upload of PHP files is prevented.

<IfModule mod_php.c>
 php_flag engine off
AddType text/html .html .htm .shtml .php .php3 .php4 .php5 .php6 .php7 .php8 .phtml .phtm .pl .py .cgi
RemoveHandler .php
RemoveHandler .php8
RemoveHandler .php7
RemoveHandler .php6
RemoveHandler .php5
RemoveHandler .php4
RemoveHandler .php3

There are multiple problems with this approach. First, not all installations are using Apache as a web server and other servers could ignore these instructions. Second, the blacklist might be missing a file extension that is attached to the PHP interpreter in the web server configuration. Third, we can use the ExtendedFileManager as described above in order to rename the .htaccess file. Yes, it is that simple. Once the file is disabled, an attacker can inject PHP code into the web server log file and copy it to the upload folder with an PHP extension. The vulnerability can also be used to copy configuration files into the upload folder to get access to passwords and other private information.

Time Line

Date What
2016/09/20 First try to contact vendor
2016/10/21 Second try to contact vendor
2016/11/16 Third try to contact vendor

We tried to get in contact with the vendor both by e-mail and by web form for almost 3 months with no response.


A takeway from this analysis is to not use the Xinha plugin or open-source software using it. It contains dangerous vulnerabilities and is not maintained anymore. As a workaround, it is advised to remove the Xinha plugin or, in case of Precurio, the directory public/library/xinha/plugins/ImageManager, as already considered by the Xinha authors.

I think we should give consideration to just deleting these folders totally,
over the last year I've had a number of instances of people coming to me
with these folders filled with various malware.

Third-party code in general can introduce a big threat to your application’s safety. In order to increase security, libraries and plugins should be stored outside of the web directory, i.e. it should never be directly accessible by attackers. Using a dependency manager like Composer is also a good idea because it helps to easily update libraries and warns about deprecated dependencies.

Follow us on Twitter to be notified when the next gift of our advent calendar is opened!

APAV Time Table

Date Author Title
24 Dec 2016 Johannes Dahse What we learned from our Advent Calendar
23 Dec 2016 Hendrik Buchwald e107 2.1.2: SQL Injection through Object Injection
22 Dec 2016 Daniel Peeren Security Compliance with Static Code Analysis
21 Dec 2016 Martin Bednorz AbanteCart 1.2.8 - Multiple SQL Injections
20 Dec 2016 Martin Bednorz Kliqqi From Cross-Site Request Forgery to Code Execution
19 Dec 2016 Robin Peraglie osClass 3.6.1: Remote Code Execution via Image File
18 Dec 2016 Daniel Peeren Continuous Integration - Jenkins at your service
17 Dec 2016 Johannes Dahse OpenConf 5.30 - Multi-Step Remote Command Execution
16 Dec 2016 Robin Peraglie Redaxo 5.2.0: Remote Code Execution via CSRF
15 Dec 2016 Dennis Detering Guest Post: Vtiger 6.5.0 - SQL Injection
14 Dec 2016 Hendrik Buchwald The State of Wordpress Security
13 Dec 2016 Johannes Dahse phpBB 2.0.23 - From Variable Tampering to SQL Injection
12 Dec 2016 Martin Bednorz Teampass Unauthenticated SQL Injection
11 Dec 2016 Daniel Peeren Rescanning Applications with RIPS
10 Dec 2016 Hendrik Buchwald Non-Exploitable Security Issues
9 Dec 2016 Hendrik Buchwald Precurio 2.1: Remote Command Execution via Xinha Plugin
8 Dec 2016 Martin Bednorz PHPKit 1.6.6: Code Execution for Privileged Users
7 Dec 2016 Hendrik Buchwald Serendipity 2.0.3: From File Upload to Code Execution
6 Dec 2016 Robin Peraglie Roundcube 1.2.2: Command Execution via Email
5 Dec 2016 Hendrik Buchwald Expression Engine 3.4.2: Code Reuse Attack
4 Dec 2016 Johannes Dahse Introducing the RIPS analysis engine
3 Dec 2016 Martin Bednorz eFront 3.6.15: Steal your professors password
2 Dec 2016 Martin Bednorz Coppermine 1.5.42: Second-Order Command Execution
1 Dec 2016 Hendrik Buchwald FreePBX 13: From Cross-Site Scripting to Remote Command Execution
25 Nov 2016 Martin Bednorz Announcing the Advent of PHP Application Vulnerabilities

Disclaimer: The information provided here is for educational purposes only. It is your responsibility to obey all applicable local, state and federal laws. RIPS Technologies GmbH assumes no liability and is not responsible for any misuse or damages caused by direct or indirect use of the information provided.