Bill’s Security Blog

Howdy folks!

Episode 195 of PaulDotCom Security Weekly prompted me to revisit an old favorite, netcat (many netcat versions exist). On the episode, Ed Skoudis provided an excellent technical segment on using netcat and netcat-like relays.

The write-up at PDC is very well done, but I thought I’d work my way through the examples, and try to illustrate with more text and some graphics. If you are following the notes on PDC, be advised I am using the term pivot synonymously with relay…

The goal of this post is to reinforce my own understanding of netcat by providing an informative introduction, and help readers who may not have familiarity with netcat develop an understanding of the possibilities the tool introduces.

Background

The simple netcat session consists of two steps:

1. On one host, create a netcat listener on a specified port – sometimes referred to as the server
2. On another host, create a netcat connection to the listener created in Step 1, sometimes referred to as the client

Once established, a netcat session provides bi-directional communication. Data going in one end, comes out the other. The session does not discriminate between ‘client’ and ’server.’ The only differentiator is that the listener is created first.

A fairly contrived networking example is provided below to illustrate netcat in use.

The version of netcat used in these examples is provided with BackTrack 4, and is slightly different than the version provided with some flavors of *Nix. But the basics are the same.  If you are using Ubuntu - the -p when creating the listener is optional.  Other than that, these command should work as written.

Example 1: Simple Netcat Session

Image 1: Simple Netcat Session

In this example, Host A and Host B want to communicate. Following the process described above, Host B creates a listener in Step 1, and Host A connects to that listener in Step 2.

A slightly more complicate example is provided in Example 2.

Example 2: Partial Pivot

Image 2: Partial Pivot

In Example 2, Hosts A and B can communicate, and B and C can communicate, but A and C cannot, directly.

If A wants to send data to C, we must pivot through B.  We must use B as a relay between A and C.

This requires two netcat sessions. One between B and C, and another between A and B. Naturally, then, we need to set up two listeners (servers) and two talkers (clients).

The first session is established between B and C. This is done in Step 1 and the second part of Step 2.
Step 1) > nc -l -p 3333
Step 2.2) > nc 10.1.0.3 3333

The second session is created between A and B. This is done in the first part of Step 2 and in Step 3:
Step 2.1) > nc -l -p 2222
Step 3) > nc 10.1.0.2 2222

The key to making this pivot work, is that we must connect the output of the second session (between Host A and B) to the input of the first session (between Host B and C). This can be seen in the diagram’s Step 2. Host B issues the command to establish the listener for the communication with Host A using a pipe to send the output to the connection is it making to Host C.
> nc -l -p 2222 | nc 10.1.0.3 3333
This basically says, “listen for data coming in on 2222 and pipe it to port 3333 on host 10.1.0.3.

Perfect. Now all data sent to stdin on Host A will be sent through the pivot at Host B and to stdout on Host C.

The problem, however, is that Host A cannot see the results of whatever he sends through to C.

The challenge is that Host A’s output to B is being piped into a netcat session with C. Data coming back from C appears on the stdout of Host B! Host A never gets to see what is going on.

To remedy this, we must pipe the stdout coming from Host C to Host B to a place A can see it. If Host B has write access to a publicly accessible source (e.g., ftp server, wwwroot, etc) then problem solved. Or, we can create a third netcat session back from B to A!

Example 3: Two-way Pivot

Image 3: Two-way Pivot

This example extends the second example by simply providing one more netcat session back from stdin on B (coming from C) to Host A.

The stinky part is that Host A now has two terminal windows open:

1. A session for sending the data through the pivot at B to C, and
2. A session for receiving the results coming from C back through the pivot at B.

What we do gain, however, is that though Hosts A and C cannot talk directly, they can relay their communications through an intermediary set of hosts to accomplish the same task.

This method can be simplified.

As Ed pointed out in his Technical Segment, a shell redirect through a named pipe works quite well.

Example 4: Two-Way Pivot Using Named Pipe

Image 3: Two-Way Pivot Using Named Pipe

In Example 3, the relay, Host B, creates a named pipe, and then funnels the netcat input/output through the named pipe.

Host B issues the following two items on the command line:
> mknod bp p
> nc -l -p 2222 0<bp | nc 10.1.0.3 3333 1>bp

To analyze, let me label each part of this set of commands:
A) mknod bp p
B) nc -l -p 2222 0<bp
C) nc 10.1.0.3 3333 1>bp
D) B | C

A) mknod bp p
In step A, Host B creates a named pipe of type FIFO (p). A FIFO pipe works just like a FIFO queue – First In, First Out. This means that the first data arriving in the pipe will be the first data taken out of the pipe. This will allow us to create a writer and a reader attached to the queue. If you envision this as a line at a bank, the reader will be the bank teller, taking folks out of the queue, and the door to the bank acts as the writer, adding folks to the queue.

B) nc -l -p 2222 0<bp
In step B, the host creates a listener bound to port 2222, and uses input redirection to dump anything from the named pipe (bp) into the netcat session. When a client actually connects to this netcat session, the input will be written to stdout on Host B.

C) nc 10.1.0.3 3333 1>bp
In step C, the host creates a netcat session to host 10.1.0.3, where the output (stdout) arriving from the listener at the far end will be written into the named pipe (because of 1>bp).

What we can see now, is that the netcat listener in Step B is the reader from the FIFO queue, and the netcat session created in Step C is the writer to the queue. Perfect.

D) B | C
The final command D ties the two components together. Without using the pipe operator, the stdout arriving from Host A is still written to stdout on Host B. By using the pipe, we push stdout arriving from A into the netcat session created to Host C, just as we’ve done several times in these examples.

To illustrate the full data flow, then. Once both sets of netcat sessions are established as illustrated in Example 4, data flows through the system as follows. Data entered at Host A is sent over the netcat session to Host B where it is redirected through a pipe ( “|” ) into the netcat session Host B has created with Host C. As data comes back from Host C, it arrives at Host B, is written into the named pipe using output redirection (1>bp), where it is picked up by the netcat session Host B has with Host A because of input redirection (0<bp)

Conclusion

Skoudis goes into several deeper examples in the PDC Episode 195 show notes, and I encourage folks to read. It seems that your imagination, and the combination of your user access rights and a forgiving firewall rule-set are the only things limiting you!

The goals of this post are to:

• Strengthen my knowledge by educating;
• Assist those who may not have much exposure to netcat; and
• Help spark interest in the countless possibilities introduced!

I help you found it useful.

Bill

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