Archive for the ‘Research’ Category

Decrypting files using OpenSSL

Wednesday, December 9th, 2009

Background

I’m playing with one of the De-ICE pen-testing CD’s, and I came across a file that was encrypted.

The problem is, I don’t know:

  • The cipher used to encrypt the file
  • The password used
  • Whether or not the file was Base64 encoded

Discovery

By poking around the box, I was able to determine that OpenSSL was installed.  OpenSSL will reveal the encryption commands it supports by typing:

# openssl -help

So I know the set of algorithms that could have been used to encrypt the file.

I also have a candidate set of passwords that I believe were used to encrypt the file.  These were uncovered during the pen test.

I need to figure out if the file was Base64 encoded and the cipher used.

# file encrypted_file.enc
encrypted_file.enc: data

The file is not Base64 encoded or it would be type text.  I tested this by encrypting two files, one with Base64 and one without.  The Base64 file returned type text, the other type data.

To test for the algorithm used, I tried encrypting a file and decrypting with both correct and incorrect passwords.  Only clean decryptions (where the correct password was used) result in plain text (”ASCII text”) when using the “file” command.  Decrypting a file with the wrong password results in a file with file type “data,” or something else.

This will make scripting of a solution easy.

The challenge for me is that I don’t know much about shell scripting.  Fortunately, there is a sweet resource over at the LDP - the Advanced Bash-Scripting Guide by Mendel Cooper.  It was a huge help.

What I know now:

  • Candidate passwords
  • Candidate encryption algorithms
  • The file was not Base64 encoded

What I don’t know:

  • The combination of password/algorithm used to encrypt the file.

What I want:

  • The decrypted file
  • The password and algorithm used to encrypt the file

Scripting a Solution

Result: decrypt.sh
Given a set of candidate encryption algorithms and candidate passwords, the script will:

  • Try all combinations of password/algorithm
  • Save the decrypted results in the specified directory
  • Save decrypted files wiith a file name of the type <password>_<algorithm>.txt
  • Run the “file” command at the end, looking for any that have type ASCII text

If the algorithm is successful, at least one file with type ASCII text will have be a valid decryption of the original file.

The file worked like a charm to decrypt the file I found.

The Code

#! /bin/bash

SUPPORTED_ALGS=(aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb aes-256-cbc
aes-256-ecb base64 bf bf-cbc bf-cfb
bf-ecb bf-ofb cast cast-cbc cast5-cbc
cast5-cfb cast5-ecb cast5-ofb des des-cbc
des-cfb des-ecb des-ede des-ede-cbc des-ede-cfb
des-ede-ofb des-ede3 des-ede3-cbc des-ede3-cfb des-ede3-ofb
des-ofb des3 desx rc2 rc2-40-cbc
rc2-64-cbc rc2-cbc rc2-cfb rc2-ecb rc2-ofb
rc4 rc4-40)
PASSWORD_LIST=(passwd password test)
OUTPUT_DIRECTORY="/root/1_100/decrypt_output/"
ENCRYPTED_FILE="/root/1_100/encrypted_file.csv.enc"

echo "Num algorithms=${#SUPPORTED_ALGS[*]}"
echo "Num passwords=${#PASSWORD_LIST[*]}"

for password in ${PASSWORD_LIST[*]}
do
    for alg in ${SUPPORTED_ALGS[*]}
    do
        OUTFILE="${OUTPUT_DIRECTORY}${password}_${alg}.txt"

        openssl enc -d -in $ENCRYPTED_FILE -pass pass:${password} -out $OUTFILE -${alg}
    done
done

echo "Candidate files:"
file ${OUTPUT_DIRECTORY}* | grep ASCII

exit

Setting up a pen-testing lab-in-a-box

Sunday, November 8th, 2009

So, I got my hands on a handy, used Dell Latitude 620 with 2GB ram for next-to-nothing.

I’m looking for something to do with it…

How about, set up a penetration testing platform complete with: safe, internal-only networking; hosts as attackers; hosts as targets; and do the whole thing for $0.00. And, how about doing the entire thing on a single piece of hardware? Sweet.

Purpose
The purpose of this exercise is to establish a safe environment to perform penetration testing on different target hosts and applications.

A single computer with host-only networking will be used to avoid sending attacks across the network where other hosts may reside.

Goals

  • Establish the lab with no additional hardware or software investment.
  • Ensure that the box does not leak attacks over the network.
  • Provide an easy-to-maintain platform where new attackers and targets can be added or modified over time.

Basics: Establishing the virtual environment

The lab-in-a-box comprises a used Dell Latitude D620 with 2 GB ram, and 80GB hard disk space. Not a bleeding edge host, but more than adequate for this endeavor.

Software used:

  • Host OS – Ubuntu Linux 9.04, Jaunty Jackalope
  • Virtualization – Sun VirtualBox
  • Attacker – BackTrack 4 pre-release
  • Target – De-ICE Lab CD 1

Step 1. Download and install the Host OS

Download and install Ubuntu on the host. Get it up-and-running, patched, and configured to your tastes.

Step 2. Download and install VirtualBox

Virtual box can be downloaded from: http://www.virtualbox.org/

I’m using Ubuntu, there are a few kernel modules you may need depending on the version of Ubuntu  you are working with.  If you are using a different OS, do a little research.  The VirtualBox site has pretty good info on installing.

Step 3. Download the BackTrack and De-ICE ISO images

BackTrack can be found at Remote Exploit.
The De-ICE images can be found at De-ICE.net.

Step 4. Create the hosts in VirtualBox

Follow the installation instructions on the BackTrack site.

The De-ICE image is a bootable image, so you don’t need to create a big hard disk for this. I created a simple 1GB disk for it, and have the VM configured to mount the De-ICE ISO on boot. Pretty simple.

Step 5. Set up host networking

When I set up the VM’s, they had bridged networking. This means that each VM connects to the local network through the host computer. It is as though they are separate hosts on the network, and each receives an IP address via DHCP if so configured.

The problem is that two virtual machines on the same host will still communicate with one another over the LAN – and that could mean trouble.

The image below shows, in the upper-left hand corner, my BT4 VM doing an Nmap scan of my De-ICE VM in the upper right-hand corner. The window at the bottom is my host (physical box) doing a tcpdump.

Data Traveling Across Lan

Data Traveling Across Lan

As you can see from the host tcpump, the network traffic from BT4 is traveling across the net. That’s a big problem in fat-finger space.

I don’t want to be in the coffee shop and inadvertently fat finger a target and end up in the joint.

The solution, set the virtual machines to use a local-only network. In VirtualBox, this is called “Internal Networking.”

VirtualBox supports two types of local only networking. One is called “Host Only.” With this configuration, the host can still interface with the VMs, but the VMs cannot communicate off the host. This is pretty good. But I’m going for maximal safety. That is where “Internal Only” comes in. In this configuration, the virtual machines are assigned to a named network that is created by VirtualBox. Hosts on that virtual network can communicate with other VMs on that network, but not with hosts outside that network. Even your physical box (host) cannot communicate with the VMs…

Shut down and set both the network interfaces on the BT4 and De-ICE VMs to Internal Networking as shown in the screen shot below.

VirtualBox Internal Networking Setting

VirtualBox Internal Networking Setting

Note the default internal network name (in the screen shot it is “intnet”) as you will need this when configuring the VirtualBox DHCP server…

Next, we will set up the DHCP Server for the internal network. You may not need to do this step, but I’m following the instructions for the De-ICE CD which specifies that the DHCP server should be on 192.168.1.1 and have a lower DHCP lease range of 192.168.1.2. I set the upper range at 2.254 to accommodate other De-ICE CDs.

Using a terminal on the host, run the following command (all on one line):

VBoxManage dhcpserver add --netname intnet --ip 192.168.1.1 --netmask 255.255.0.0 --lowerip 192.168.1.2 --upperip 192.168.2.254 --enable

Sweet. All is well and good. Boot up the two images.

I performed two tests to make sure there was no data leakage.

First, I ran a similar test as I had above – running tcpdump on the host while running Nmap from the BT4 VM targeting the De-ICE VM.

Second, I disabled the host’s network connection and performed the same test.

In both cases the two VMs could talk to one another, but no data leakage, as shown in the screen shot below.

Internal Networking Enabled

Internal Networking Enabled

Step 6. Have fun!

You are good-to-go. Fire up those virtual machines and have some fun!

Security through simplicity - live it

Monday, December 15th, 2008

Over the past semester, I have had the opportunity to assist a co-worker who was taking an “Introduction to C++” class.

I was a C++ tutor in my undergraduate program, and I helped a lot of my fellows in the Master’s Degree program I was in at JMU. Though I’m no expert, and haven’t done any C++ since graduation, I have probably written close to 25,000 lines of C++, and was excited to get involved.

My coworker was taking the class in the context of an IT Management class that has a focus on security and disaster recovery.

After she submitted her last project, she sent me an email talking about how tough the class was for her.

Below was my reply. I felt it worth capturing in a blog post…


Also, don’t worry if you didn’t leave this class as the world’s best developer.

I think the real take-away is that coding is hard. It’s really, really hard.

It’s easy to make mistakes, very easy.

And it’s easy to hack something together, just enough to get the project done. It happens ALL the time. With the simple tools at our disposal, even novice developers can develop huge, web enabled, and EXTREMELY BUGGY software.

And from a security perspective, you must remember that fact ALL the time. That is the big learning lesson!

Not only will the software you buy have bugs.
But so will your firewalls, your anti-virus, you name it.

Coding is hard. It is F’ING hard.

And even worse, you can take two completely secure pieces of code, and put them together. And you know what, the result may have security bugs!!!

Remember your experiences in this class. Use that experience to govern your thinking in future security related projects.

The experiences you have had are why my number one motto is: “Security through simplicity.”

It’s my opinion that every piece of hardware or software increases risk through it’s very nature.

Even a security countermeasure has some implicit security risk that must be assumed.

On the business side, when implementing software, or installing a new piece of hardware you make a business case. Does the hardware or software save money, or allow sufficient increase in revenue to justify the cost.

From the security perspective, particularly with security countermeasures, that equation is a little different. The “cost” is measured in risk.

So the consideration must be: Does the amount of risk offset by the countermeasure, adjusted for the inherent risk associated with the countermeasure itself, reduce the overall risk sufficiently to justify the use of the countermeasure.

It’s a tough equation, given that it can be tough to calculate the risk inherent in a security countermeasure.  Why?  Because we want to think that security systems are secure.  But we know the truth.  We know how deep the rabbit hole goes.

For example, what’s the risk profile of a firewall?

Well, there’s a lot. Among them:

  • Potential for flaws in firewall hardware and software that could allow unacceptable traffic through.
  • Potential for human error in configuring rule sets.
  • Potential for the firewall to fail in an unsafe mode.

And there are plenty of associated costs.

  • Cost of the system.
  • Cost of maintenance.
  • Cost of developing security processes and procedures to manage the firewall.
  • Cost of developing and maintaining trained staff to manage the firewall.
  • Cost to accurately monitor the system.

The logic is cyclical.  The more risk you offset, the more you assume.

Hence my motto:

Security through simplicity.

Bill

OpenBSD - Episode 3 - Installing applications

Tuesday, May 20th, 2008

Installing applications

Out of the box, there’s no nifty graphical package installer in OpenBSD.

Installation can be performed by two methods:
1) The traditional method of building from source and installing
2) Downloading and installing pre-build binaries from CD or over the Web

For my experimenting, I’ll be installing binaries.

Though the absence of a package manager may seem a bit burdensome, the reality is that OpenBSD, IMHO, is best suited for a server environment where the number of installed packages should be quite small.

The bare-bones install of OpenBSD is very thin, requiring little more than is needed to get the host to boot a kernel.

From a security perspective, this is a bonus. Smaller install set = smaller attack surface.

The other thing I like is that it’s pretty easy to script the installation of packages, greatly simplifying the process of creating standard builds for web servers, database servers, etc.

Purchasing copies of the CD’s help to support the project, and packages can be installed directly from CD.

I don’t have the CD’s, so I’ll be installing from the Web.

The overall process is pretty straight forward:
1) Select an FTP mirror
2) Identify the package(s) to install
3) Use the pkg_add command to install

From scratch, here’ the process for installing the latest pre-built nmap package:

# ftp -4 -V ftp://ftp.openbsd.org/pub/OpenBSD /4.3/packages/i386/index.txt
100% |**************************************************| 105 KB 00:01
# grep nmap index.txt
nmap-4.53.tgz
nmap-zenmap-4.53.tgz
# pkg_add ftp://ftp.openbsd.org/pub/OpenBSD /4.3/packages/i386/nmap-4.53.tgz
lua-5.1.2p1: complete
libdnet-1.10p2: complete
nmap-4.53: complete
# nmap -p80 localhost

Starting Nmap 4.53 ( http://insecure.org ) at 2008-05-20 04:18 EDT
Interesting ports on bsdvm.localdomain (127.0.0.1):
PORT STATE SERVICE
80/tcp closed http

Nmap done: 1 IP address (1 host up) scanned in 0.334 seconds
#

For some reason, I was having trouble connecting to FTP servers… I kept getting the following error:
435 Can’t build data connection: illegal port number

I suspect the reason is the network I’m on, but who knows.

I also found that many of the mirrors didn’t have the latest 4.3 builds, which may not be too suprising as 4.3 was released only a few weeks ago.

Identifying what is installed

Ok, so now I know how to install, how do I tell what’s on my box?

The pkg_info command will list all packages installed on the host.

For example:

# pkg_info
atk-1.20.0p0 accessibility toolkit used by gtk+
cairo-1.4.14 vector graphics library
desktop-file-utils-0.14p1 utilities for 'desktop' entries
...

For further information on a package, you can:

# pkg_info <pkg name>

This will give detailed information about a package, including it’s full version (if it can be determined) and any dependencies…

For example:

# pkg_info tiff
Information for inst:tiff-3.8.2p0

Comment:
tools and library routines for working with TIFF images

Required by:
gtk+2-2.12.7

Description:
This software provides support for the Tag Image File Format (TIFF), a widely used format for storing image data.


...

Maintainer: The OpenBSD ports mailing-list <ports@openbsd.org>

The documentation is quite extensive, and I recommend reading the FAQ and the MAN pages.

I certainly haven’t made it through all the documentation yet :)

Next time, getting Apache, PHP, and MySQL running…

Bill

OpenBSD - Episode 2 - Getting up and running

Wednesday, May 14th, 2008

I’ve heard that getting OpenBSD installed and running can be intense.

I reserve judgment until I am able to actually try the installation a few times on bare metal.

For now, I want to set this puppy up in a virtual machine.

Here’s my rig:

  • HP Pavilion DV5224nr Laptop with AMD Turion 64 Mobile, 2 GHz processor with 1 GB Ram.
  • Microsoft Windows XP (32bit) Professional, fully patched.
  • VMWare Server 1.0.5 build 80187

Ok, so I’m ready to go.

Doing some quick Googling, I came across a very good, short OpenBSD on VMWare how-to by Jan Exß.

I downloaded the latest OpenBSD (4.3) installer ISO from one of the many mirrors. There were many iso images, the file I nabbed was openbsd-install43.iso.

Then I got down to work using Jan’s recommended settings.

I followed the instructions pretty much 100% with a few exceptions. Notably, I didn’t install all the packages he described on the Installation page. I also set up the NIC a little differently.

I wanted the install to be relatively thin, and I also wanted to reserve some packages out so that I can get experience with installing them later, when the excitement wears off.

In the end, I completed all the tasks up to the top of the Applications page.

Reboot, and presto! OpenBSD 4.3.

OpenBSD 4.3 Splash Screen

Sweet.

I banged around in the terminal a bit, just enough to realize that things weren’t as different as I thought they’d be.

I know the machine isn’t doing much at the moment, but I’m surprised how fast it responds considering it’s only allocated 512 MB ram, and is running in a VM…

Current impression: Sweet! This hasn’t been as challenging as I though it would be.  Let’s see how things go from here.

Stay tuned for the next episode - Installing Applications…

OpenBSD - Episode 1

Monday, May 12th, 2008

OpenBSD

For years I’ve heard about the mythical, OpenBSD.

While getting my Master’s Degree in Information Security, one of my professors remarked, “Out of the box, OpenBSD is widely considered to be the most secure operating system.”

The home page of the OpenBSD site clearly, and proudly claims: “ Only two remote holes in the default install, in more than 10 years!

Sounds impressive. Secunia shows that of the 189 advisories it reported from 2003 to 2008 for Microsoft Windows XP Professional, 61% were remote exploits.

Sixty-one percent! That’s 115 in just over 4 years!

The skeptic in me says, well, how many OpenBSD installs are there, relative to the number of XP installs. The bigger the install base, the more attractive the target.

But still. The seed had been planted.

I needed to try this thing out for myself!

I’ve toyed around with Linux since the late 90’s, but hadn’t used a Unix system since before that.

I have been stuck in Microsoft shops since ‘99 :/

But the power of virtualization has now made it possible for me to kick the tires of this mythical beast, and see how it responds.

In my next post, getting up-and-running with OpenBSD and VMWare Server.

For those who can’t wait, here’s my browser’s User Agent:
Mozilla/5.0 (X11; U; OpenBSD i386; en-US; rv:1.8.1.12) Gecko/20080310 Firefox/2.0.0.12
So, it works :)

DNSstuff.com - schweet

Friday, April 11th, 2008

Every now and again I stumble across a tools site that knocks my socks off.

Here’s one: DNSstuff.com - every kind of tool for testing network connectivity to your site/network, right at your fingertips, right when you need it.

Queries are run from off-site, so you can really get a view of your network from outside, in the cloud.

Some tools can be used freely, and there are different fee rates to use the more advanced features, but it’s well worth it.

They have a development tools area (where they beta test new tools) and there is lots of fun stuff there…  Here’s the description of a few that caught my eye!

VectorTrace

What is this tool?

VectorTrace is unique in that it allows for traceroutes to be performed simultaneously from multiple locations and that information displayed in context of each other. For example, on initial launch VectorTrace will trace from three discrete locations and display the route taken to the requested destination.

How do the results help me?

This will allow the user to understand critical common points in the path. This will help identify the most critical points with poor performance so that you can remedy that situation by working with the administrators of that point or giving you the information to choose a better location for the final destination. As the product matures we will offer options to present the data on a map and even automate and alert on the quality of the paths taken.

DNS Traversal

What is this tool?

This tool is essentially similar to the “dig” tool and is more advanced than our nslookup. When you change your name servers and need to verify your changes are being seen throughout the world the traversal tool looks at what each root server is returning. If any are not correct then all subsequent DNS servers that look up your domain from that root server are going to be getting incorrect information.

How do the results help me?

Displays which DNS servers the world thinks are responsible for your domain and what information they are returning.

Speed Test

What is this tool?

Speed test measures the performance of your Internet connection. If you are experiencing performance issues use this tool to get a good understanding of what it really is.

How do the results help me?

Measures speed of your connection - Download/Upload/Latency

Here’s a quick rundown of some of the tools available to you:

Some free tools:

WHOIS/IPWHOIS Lookup
Country IP Range Lookup
RFC Lookup
IP Information
Traceroute

Some paid tools:

DNS Timing
WHOIS/IPWHOIS Lookup - Advanced
Spam Database Lookup
Reverse DNS lookup - Advanced
Traceroute - Advanced
DNS Lookup - Advanced
Zone File Dump
Ping
ISP Cached DNS Lookup
Top Level Domain Lookup
Web Site HTTP Headers
SPF
ASN Information
ASN WHOIS
MAC Address
SSL Examination
Find Nearby IPs 

Enjoy!
Bill

Excellent research and advice on password security

Sunday, February 18th, 2007

Schneier wrote a great article on password security, the impact of complexity, and the ease of cracking passwords.

Finally, great advice on how to choose good passwords.

Some of us, after all, do not have two-factor authentication.

http://www.schneier.com/blog/archives/2007/01/choosing_secure.html

Enjoy,
Bill Gross

TOR traffic can be traced

Monday, November 6th, 2006

From Security Wire Daily on Thursday, November 2:

TOR NETWORK PRIVACY COULD BE CRACKED
The Tor network is used by those who want to keep their IP addresses private. But new research shows that it’s possible to compromise the system and unmask the user.

A TOR network operates by forwarding requests from source to destination through a series of intermediate hosts in an effort to confuse tracing the traffic. It’s a fairly cool concept.

As researched by Danish security research firm FortConsult uncovered, specially crafted web content can allow tracing of the requests back to the originating hosts.

They published a paper on how they discovered the flaw, and how a “compromise” might be effected in the real world.

Interesting read.

Bill Gross