Precurio 2.1: Remote Command Execution via Xinha Plugin


Precurio

Precurio is an Intranet portal that can be used as a calendar, phone directory, and much more. It is available as an open-source and commercial solution. We focused our analysis exclusively on the open-source version and detected several critical vulnerabilities that can be used to execute PHP code on the target system without any form of authentication.

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.

See RIPS report

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.

public/library/xinha/plugins/ImageManager/Classes/Files.php


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

public/library/xinha/plugins/ExtendedFileManager/Classes/ExtendedFileManager.php


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']);
        break;
        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);
        break;

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.

public/library/xinha/plugins/ImageManager/Classes/Files.php


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
</IfModule>
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

DateWhat
2016/09/20First try to contact vendor
2016/10/21Second try to contact vendor
2016/11/16Third 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.

Summary

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

DateAuthorTitle
24 Dec 2016Johannes DahseWhat we learned from our Advent Calendar
23 Dec 2016Hendrik Buchwalde107 2.1.2: SQL Injection through Object Injection
22 Dec 2016Daniel PeerenSecurity Compliance with Static Code Analysis
21 Dec 2016Martin BednorzAbanteCart 1.2.8 - Multiple SQL Injections
20 Dec 2016Martin BednorzKliqqi 3.0.0.5: From Cross-Site Request Forgery to Code Execution
19 Dec 2016Robin PeraglieosClass 3.6.1: Remote Code Execution via Image File
18 Dec 2016Daniel PeerenContinuous Integration - Jenkins at your service
17 Dec 2016Johannes DahseOpenConf 5.30 - Multi-Step Remote Command Execution
16 Dec 2016Robin PeraglieRedaxo 5.2.0: Remote Code Execution via CSRF
15 Dec 2016Dennis DeteringGuest Post: Vtiger 6.5.0 - SQL Injection
14 Dec 2016Hendrik BuchwaldThe State of Wordpress Security
13 Dec 2016Johannes DahsephpBB 2.0.23 - From Variable Tampering to SQL Injection
12 Dec 2016Martin BednorzTeampass 2.1.26.8: Unauthenticated SQL Injection
11 Dec 2016Daniel PeerenRescanning Applications with RIPS
10 Dec 2016Hendrik BuchwaldNon-Exploitable Security Issues
9 Dec 2016Hendrik BuchwaldPrecurio 2.1: Remote Command Execution via Xinha Plugin
8 Dec 2016Martin BednorzPHPKit 1.6.6: Code Execution for Privileged Users
7 Dec 2016Hendrik BuchwaldSerendipity 2.0.3: From File Upload to Code Execution
6 Dec 2016Robin PeraglieRoundcube 1.2.2: Command Execution via Email
5 Dec 2016Hendrik BuchwaldExpression Engine 3.4.2: Code Reuse Attack
4 Dec 2016Johannes DahseIntroducing the RIPS analysis engine
3 Dec 2016Martin BednorzeFront 3.6.15: Steal your professors password
2 Dec 2016Martin BednorzCoppermine 1.5.42: Second-Order Command Execution
1 Dec 2016Hendrik BuchwaldFreePBX 13: From Cross-Site Scripting to Remote Command Execution
25 Nov 2016Martin BednorzAnnouncing 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.

Tags: hendrik buchwald, php, security, precurio, apav, path traversal,

Author: Hendrik Buchwald

CISO, Co-Founder

Hendrik graduated in computer science at the Ruhr-University Bochum and is a professional software engineer. In addition to designing and building complex systems, he particularly enjoys breaking and securing web applications. He is an experienced security consultant and the lead developer of the open source web application firewall Shadow Daemon.

Comments

comments powered by Disqus