Kliqqi 188.8.131.52: From Cross-Site Request Forgery to Code Execution20 Dec 2016 by Martin Bednorz
Today’s gift in our advent calendar contains descriptions of vulnerabilities in Kliqqi, the successor to the popular Pligg CMS mostly used for the creation of interactive social communities. Due to missing CSRF protection, an attacker is able to prepare a website that ultimately leads to code execution on the applications server when visited by a target.
RIPS’ analysis of the ~77,000 lines of Kliqqi code took only 31 seconds to complete and was able to discover several risks within the application. There were no critical vulnerabilities found directly but it is possible to escalate one high-rated security issue to a critical one - as we are going to demonstrate in the following case study.
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 in order to ensure a fix is available.See RIPS report
In this case study we are going to present a chain of vulnerabilities that ultimately lead to code execution on the attacked server by
- installing the upload module,
- allowing .php extensions in the upload module,
- and uploading a malicious PHP file.
Install / Activate Upload Module
The installation of a module by an Kliqqi administrator requires only a few HTTP GET requests. Hence, a very simple malicious link can be crafted that is able to install arbitrary modules in the application. It is sufficient to lure an administrator into clicking this link to install the upload module that is required for the vulnerability chain explained in this post. Exploitation of this security issue is possible due to the fact that there is no sufficient protection against cross-site request forgery attacks. The referrer check shown in the code summary below can be easily bypassed.
The regular expressions in both calls to
preg_replace() only remove the protocol and www subdomain used for the request and base url in the variable
$my_base_url. By default, when Kliqqi is installed at the domain
$my_base_url variable is set to
http://www.example.com. Now, the
if statement checks whether the base url is positioned at the beginning of the HTTP referrer. This check can be easily circumvented by simply prepending the domain of the targeted application to the attacker controlled domain as a subdomain. In our example, an attacker can circumvent the referrer check by using the following domain:
http://example.com.attacker.com. First, the
$my_base_url variable and the referrer are striped to
example.com.attacker.com respectively. Obviously, the check whether
example.com is at the beginning of
example.com.attacker.com via the
strpos() function succeeds.
In general, relying on the HTTP referrer should be avoided because it can be easily manipulated by malicious users and oftentimes it is not available at all (company proxy etc.). It is recommended to use CSRF tokens for proper security.
Allow PHP Extension for Uploads
module.php?module=upload on a client with administration privileges to add new extensions that are allowed within the upload module. As a result, it is possible to upload arbitrary PHP files to the targeted web server by any user in the social community. Similar to the previous step, CSRF tokens should be used in order to prevent this type of attack. In addition, it should not be allowed to change the file extension whitelist arbitrarily in order to prevent the upload of malicious PHP files.
Upload PHP Files
Once the attacker added
php to the allowed extension list as described in the previous steps, it is possible to upload arbitrary PHP code by using the following file upload functionality.
Here, the allowed file extensions in the validation check in line 197 are read from the database in line 201, making it possible to upload PHP files. Once again, as demonstrated in several previous blog posts, a file upload causes the trouble.
Putting it all together
|2016/10/24||First try to contact vendor|
|2016/11/16||Second try to contact vendor|
|2016/12/17||Vendor released a fixed version|
Cross-site request forgery protection is critical to remedy vulnerability chains such as the one presented in this blog post. In addition, allowing the upload of (basically) user-defined file extensions is never a good idea. Instead, the file extension whitelist should be more strict and under no circumstances allow PHP files to be uploaded in order to prevent malicious code execution. We thank the vendor for the professional handling of these issues and for providing security patches.
Follow us on Twitter to be notified when the next gift of our advent calendar is opened!
APAV Time Table
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.