Bill’s Security Blog

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

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

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

Step 6. Have fun!

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

Why do we still use Windows?

Why is this capability even enabled by default?

Windows AutoPown.  Sweet.

“Microsoft, doing it’s part to keep security professionals and hackers gainfully employed during this time of economic hardship.”

I guess we should be thankful.

                    National Cyber Alert System

              Technical Cyber Security Alert TA09-020A

Microsoft Windows Does Not Disable AutoRun Properly

   Original release date: January 20, 2009
   Last revised: --
   Source: US-CERT

Systems Affected

     * Microsoft Windows

Overview

   Disabling AutoRun on Microsoft Windows systems can help prevent the
   spread of malicious code. However, Microsoft's guidelines for
   disabling AutoRun are not fully effective, which could be
   considered a vulnerability.

I. Description

   Microsoft Windows includes an AutoRun feature, which can
   automatically run code when removable devices are connected to the
   computer. AutoRun (and the closely related AutoPlay) can
   unexpectedly cause arbitrary code execution in the following
   situations:

   * A removable device is connected to a computer. This includes, but
   is not limited to, inserting a CD or DVD, connecting a USB or
   Firewire device, or mapping a network drive. This connection can
   result in code execution without any additional user interaction.

...

So, where have I been?

For the last 4 weeks, I’ve been working like crazy on this FERC Order.

FERC Order RM06-22-000 seeks, in a nutshell, to modify the exemption for nuclear facilities that exists in each of the CIP standards.

Comments are due to FERC today.

Essentially, the NERC CIP’s exempt nuclear facilities in the US from compliance because those facilities are regulated by the NRC.

NRC has indicated that they do not regulate all components in a plant, only those that deal with safety, security, or emergency response (SSEP).

FERC is concerned that there may be components that are not protected by NRC but play a role in in the reliability of the Bulk-Power System.

As well they should. FERC is responsible for the reliability of the grid, and power continuity.

The industry has a robust cyber security program. And I’m not saying that because I work in the industry. I say it as a security guy who is more impressed by the program the more I learn about how plants have implemented it.

The industry program considers every device within the facility, irrespective of it’s role. COP systems may get a lower risk score than some other devices, but that seems reasonable, given we are talking about a nuclear reactor.

But the fact is that all systems are under the program.

The issue FERC has is that that program is not mandated by the NRC.

NRC, on the other hand, is about to adopt a regulation that would “codify” the requirement for a cyber security program (proposed regulation 10 CFR 73.54).

NRC says the industry adopted program, “goes a long way toward meeting the requirements of the new rule.”

In any event.

You get the idea. It’s a complicated issue.

In the end, what we’d like to avoid most is a situation where we have dual or duplicate regulation on a single device. NRC regulating for X, FERC for Y.

That gets ugly.

Particularly when plant licensees are required to operate two distinct cyber security programs. Ugh.

In any event, lets cross our fingers that FERC and NRC can work out an arrangement where a single regulator (NRC) can regulate all systems under a single cyber security program regulation.

Bill

The March 15, 2008 SploitCast podcast was recorded at SchmooCon and consisted of a panel discussion including some notables in the InfoSec space: Johnny Long, Rodney Thayer, Simple Nomad, Landon Lewis, Squidly, and Matt Hillman.

Though the entire cast is a must-hear, with an extensive discussion SCADA and critical infrastructure security, the conversation turned toward practical security in a space where the boundary of the ‘network perimeter’ is rapidly vanishing.

Simple Nomad made the observation that end users don’t, and won’t, care about security.  Paraphrasing, it’s not that they are dumb, or stupid, but that they have different areas of expertise, and security may not be it.

The group agreed that security awareness is important, but it can’t be ‘the fix’.  Users will not become security experts.  Users can, however, be taught basics, such as not clicking on untrusted links in email.

At this point, Johnny Long stepped in.

He stated that awareness is good, and perhaps policy as well, but that when we really boil this security thing down, it reduces to three basic principles:

1. A server should not be a client
2. A client should not be a server
3. Peers should only connect in certain ways

He noted that when a computer changes roles, that’s when we know there’s a problem.

For example, when a laptop gets infected with bot malware and begins phoning home, it starts acting like a server, and that’s the behavior we should be looking for.

Important points, and I subscribe to this view of the network.

It doesn’t matter if the device is completely controlled by our IT team, or an iPhone connected inside our network… If it’s a client, it should be acting like a client…

Imagine the simplicity of this view.

Suppose we had the simple tools necessary to determine if our machines are abiding by their designated role, then what will we need to ensure about the device.

Do we have to ensure that the box is 100% patched?
Do we have to pay lots of cash for anti-virus, anti-phishing, anti-this and anti-that?
Do we have to make sure that the user has a 100% crack-resistant password?
Do we have to spend countless hours configuring our network to prevent unauthorized hosts?

Perhaps not.

One simple reason, it takes much less time to re-ghost a PC than it does to keep it ’secure’.

In my organization, for example, we could let the desktops and laptops run free on the Internet.

As long as we know what clients are allowed to do on the network, and what they are not allowed to do, then we are far better off.

Imagine this… Say you have all the latest updates, and anti-virus scanners and whatnot.  Well, do you know you are safe, or do you believe you are safe?

If you believe you are safe, then I’ll be happy to show you how you are wrong.  And if you know you are safe, then I’ll call you ignorant.

Why? Because security degrades over time.  Even the most secure system on earth is only secure until an attacker finds out a new way into the system.

For example, social engineering always works…  Plain and simple, it doesn’t matter how secure the system, if I convince you to reveal the appropriate information, I will own you.

Perhaps I need to ponder this a little more, but it seems logical that we can dramatically simplify our IT infrastructure if we focus on separation of duties in the hardware/software space, and then focused our security dollars on making sure that those roles were being followed.

The old conceptions of the network no longer apply in a space where the network perimeter is porous, or non-existent.  We need to change our thinking to match reality.

Bill

Security systems are hard to implement.

The currently disclosed vulnerability that exists in applications using GnuPG illustrates what is referred to as the “secure composition” problem.

The secure composition problem states that you cannot be guaranteed a secure system composed of multiple, independently secure applications.

IE, if A is secure, and B is secure, if C = A + B, then C is not necessarily secure…

Here’s a great, detailed explanation of the flaw.  Understanding the 4 attack vectors will help illustrate the complexity of building secure systems…

By Core Security Technologies:
CORE-2007-0115: GnuPG and GnuPG clients unsigned data injection vulnerability

Bill Gross

Fellow Bloggers;

I want to put a shout out in the blogosphere.

One of our own, Abdelkareem Nabil Soliman (Kareem), is in prison as we speak.  His crime?  Using his blog to express his personal views to the world.  Views that did not follow the “party line” in Egypt.

Kareem’s prosecutor has exclaimed that he intends to wage jihad against ‘the likes of Kareem.’

Help right this tragedy!

Read about his plight, and more importantly, GET INVOLVED at freekareem.org

Bill Gross

Hardware DEP (or, Data Execution Prevention) is a method for preventing buffer overflows by marking certain pages in memory as “code” or “non-code”.  The idea being that if a buffer overflow writes code into a page marked non-executable, then the overflow would not be successful in running the malicious code.

DEP promises to be the end of the buffer overflow attack.

Or is it…

Dave Aitel of Immunity has some interesting things to say about using his debugger to create code that circumvents hardware DEP.

Here’s a snip:

Yesterday, before most of Immunity went bowling (like all hackers, we’re
extremely athletic), Nico was showing me the “defeat dep” Immunity Debugger
script. You type “!defeatdep” and then it has a little wizard you go through
and then you’ve got a buffer that will do the return into libc trick to
defeat DEP. Simple and easy! It’s part of an “Advanced Windows Overflows”
class we’re teaching all next week. Nico’s Immunity Debugger !heap script
allows you to do do all sorts of tricks with heaps - and to defeat the next
generation of heap protection, you’re going to need all of it, plus some
luck. Kostya’s “!safeseh” script does various neat things around that as
well. None of the free debuggers allow you to do this stuff, but none of the
free debuggers are specifically for exploit development either.

Read the full thread for more lively discussion:
http://lists.immunitysec.com/pipermail/dailydave/2007-February/004094.html

Bill Gross

Some people only focus on the second part.

If it can be used for bad, it must be bad.

We see it all the time.  Misused hand guns result in death, so hand guns are bad.

It gets really ugly when people associate the “unknown” with bad.

I suspect a little of that is going on at Bowling Green State University where they are cracking down on the use of TOR on campus.

Here’s a great article from a professor down there.  He espouses many of the good uses and bad uses of TOR, and he did something I find really schweet.  He decided to go ahead with his lectures on TOR.

Good job, Paul Cesarini

Here’s the article:
http://seclists.org/isn/2007/Feb/0053.html

Enjoy,
Bill Gross

A few weeks ago I bought an iPod and have been using to listen to a series of security related podcasts.

And, of course, some non security related information as well…

But anyway, on the Metro this morning, it locked up.  Screen frozen, and completely unresponsive to my vast knowledge of information systems… LoL.

Here’s how to fix that issue, courtesy of Rachael Smithey and About.com:
http://macs.about.com/od/ipod/a/ipod_frozen.htm

Enjoy,
Bill Gross
 

For the *nix lovers.

Enjoy.

Explicit lyrics, so be warned.

http://www.youtube.com/watch?v=Fow7iUaKrq4

Bill