Saturday, 23 May 2015

Multiple Vulnerabilities in eFront CMS v3.6.15.4

Hi friends,

I am back with Three stories Today. There are multiple critical bugs effecting the e-front, one of the Top 10 e-learing cms available, version build 18023. The details are as follows.
  1. Directory Traversal       (CVE : 2015-4461)
  2. Local File Inclusion      (CVE : 2015-4462)
  3. Bypass for Blocked extension file uploads      (CVE : 2015-4463)
About the e-front:
E-front is one of the Top 10 e-learning cms available free on the market till date. A small description from the vendor's site:

"The core of eFront is distributed as an open-source project. We have created a superior training product and we are not afraid to let you try it! The open-source edit of eFront will cover a wide range of your needs. If you are looking for a specialized solution then take a look at different efront editions."

The Issues are fixed as part of new release, efront v3.6.15.5 build 18024. You can find the change log here

Point of the Story:
e-front has a wide range of security precautions when using publicly. For example, server side files like php, jsp, asp and/or exe files are not supported to use within e-front. So, as a security researcher, I am curious to find the security holes in the cms and hence started to dissect the code and application. Finally I was able to find 3 critical vulnerabilities effecting the latest version of the cms (v3.6.15.4 build 18023).

Background Story:

Once the CMS is installed successfully, it creates 3 user roles namely Admin, Professor and Student. The user privilege required for these attacks is the Professor role. The issues are effecting all the e-front editions earlier than and also applicable for both environments on Linux and Windows (32bit and 64bit editions).

Foreground Story:

1. Directory Traversal Attack :
For Professor role users, there is a feature designed to upload files as the content for different lessons. In the same feature, professor's can create multiple directories within the content/lessons directory. After creating the new directory, while opening the directory contents through the application, application sends a GET request with the absolute path of the directory as follows.


The Parameter "other" is found to be vulnerable to path traversal attack. By pointing the parameter "other" to your target directory, we can traverse to the directory and lists all the contents of the directory.
2. Local File Inclusion :
In the same file uploading feature, we will have two options to upload files into the directory. one is using file upload and the second options is using files from remote urls.
e-front before version accepts local files also within this 'files from remote url' option. By exploiting this weakness, I was able to upload local files into the application server file system.
For example, php.ini file of the server:
vulnerable parameter:  url_upload
vulnerable payload : c:\xampp\php\php.ini

once the request is processed, an instance of php.ini file is copied into the current directory and can be accessed directly from the location : /www/content/lessons/<lesson no>/<directory name>/php.ini

The same can be directly access from the url  http://localhost/www/content/lessons/2/Test/php.ini

3. Unrestricted Remote file Inclusion :

The same file upload feature has another weakness which enabled me to upload blocked extension files including php and exe files into the target server file system.

e-front has inbuilt security features to block file uploads of restricted file types like php, jsp and exe etc. If we try to upload any remote file with extension php, application throws an exception related to blocked file extensions.

Here, we can see that the application is validating the file extension of the given URL. But I was able to find a bypass for this blacklist based input validation.

To bypass this validation, I added an additional parameter at the end of the url, such as login=test. Here, login and test are not having any significance apart from bypassing the validation.

By adding an additional parameter at the end of the url, extension based validation is bypassed and the file is uploaded successfully into the file server. However, the file content is not as I expected.

In this process, when I uploaded the phpinfo.php file, a file with the exact name is created, but the content of HTML code which is a result of the file execution on my own domain. So when I executed the file, the output is always same and also it is not from the original server.

So my challenge is to upload a php file with content of php code. For this, I created my own php file with name phpinfo.php with the following content.

phpinfo.php ( on - attacker controlled domain):
    echo "<?php  phpinfo();  ?>";

which is executed on the (my own domain) and sends <?php  phpinfo();  ?> as the output and hence   <?php  phpinfo();  ?>    is written into phpinfo.php  on target server.

phpinfo.php ( on - target victim domain):

Once the php file is created, the file is available in the same location as previous, which is, http://localhost/www/content/lessons/18/phpinfo.php

In this way, I was able to upload any blacklisted extension files into the file server and can execute also.

This is it guys... Done for today... Will be back with more again.. stay tuned.

As always, suggestions and questions are always welcome.. Thanks for reading.... Bye