Bill’s Security Blog

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

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!

IMHO, end-user ’smart meter’ device security is the smallest issue to be resolved with moving toward a Smart Grid.

The real issue with Smart Grid is having thousands of electric devices connected to the network that have intermittent production capacities.

Currently, from what I understand, the electrical grid is somewhat sensitive to large changes in the amount of electricity being put onto or being pulled down from the grid.

As energy consumption goes up, power producers put more energy on the line.  As consumption goes down, those sources are throttled back.

But what do you do when you plug 1500 windmills into the grid?

What happens when the wind starts blowing, then suddenly stops.

Here’s a hypothetical.  Suppose a 1500 turbine wind farm, producing 15 MW of power and placing it on the grid.

If consumption = supply, we are all good.

But what happens if the wind, literally, stops blowing for 30 minutes.

Is everyone going to scramble to shut off their air conditioners and unplug their fridge?

With respect to Availability aspects of the CIA triad, we have a big issue here.

Compound that concern with the fact that electrons traveling across a grid monitoring system travel at the same speed as the electrons traveling from producers to consumers, and you get an ugly producer/cosumer problem.

An effective smart grid must mitigate these intermittent sources of power by ensuring that access to the grid happens in a controlled manner.

That involves rapid ability to disconnect an intermittent source, or to store it’s electricity for later consumption.

The devices that perform that function are, in my opinion, the biggest cyber risk.

Though it’s not necessarily security related, the other issue that needs to be addressed with the introduction of large-scale intermittent power sources on the grid, is the need to match all intermittent sources with 100% non-intermittent sources.

For example.  In our example above, in the case where  you have 15MW wind being put on the grid, you must have at least 15MW stand-by power producing capacity spinning and ready to dump energy onto the grid in the event that the wind dies down.

This issue is tough, and involves, essentially, rebuilding vast amounts of the grid to attempt to decentralize the alternate energy sources as broadly as possible.

So, for example, wind turbines in Maine might be providing power to consumers in Arizona during the night, but Solar Production in Arizona might be powering Air Conditioners in DC during the mid-day.  At the moment, our grid just ain’t built that way.

I was at a FERC Commissioner’s meeting last week, and I assure you, they weren’t talking about the issues with end-point monitors.  How you secure the devices protecting the grid as a whole was on everyone’s lips.

Bill Gross

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.

...

Good article on the security of SCADA and control networks.

Some good background and some insights into how people might go about hacking these networks.  Social engineering almost always seems to work…

I know a lot of IT Security people don’t know a ton about SCADA or control networks, but they sure have an easy time hacking them.  I see a growing convergence between Control System people and IT people - hopefully they’ll talk about security.

Cyber watch

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

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

This is common theme for me.

Perhaps I should state my feelings clearly: “If you depend on wireless in a control system environment, you are friggin’ crazy!”

A few weeks ago, I wrote about a SCADA tool from Conlab called U.C.ME.

This tool touts two-way SMS management of your infrastructure! Sweet, eh?

Now, I wrote Conlab but haven’t heard anything meaningful back. Err… Well, I did. I got a quippy email… “You said you emailed us, but you never did.”

Well, I have tried again, and to no avail.

Looking at the product’s material, they seem to be referencing a company ControlSee.  I’ll contact them.  Perhaps Conlab is just a reseller?  Who knows.

I wrote Conlab, who I thought was the product creator, to ask them what kind of authentication they are doing, and how they are preventing simple things like replay attacks.

Crickets.

Google alerts just tossed me this:
“Imagine you could speak to your SCADA system… Send a text message to your SCADA system.”

More talk of controlling your infrastructure through remote access.

Zero talk of configuration and control of access.

Conlab, ControlSee, whoever, for the love of god and all that is holy, if you have any information on this, please send it to me. This kind of stuff keeps me up at night.

Bill

The attack vectors and mitigation are not exhaustive, and are exemplary only.

A denial of service (DOS) attack is an attack against limited resources. A DOS attack is an attack against the “availability” function of the typical “CIA” security triad of “Confidentiality, Integrity, and Availability”.

A DOS attack is perpetrated by applying enough pressure against a target that the target’s resource allocation is overwhelmed.

In the question you posed, a DOS attacks can be perpetrated against any resource that supports the Web infrastructure.

A successful DOS attack against a web site tends to exhaust resources in one or more of three primary categories:

1. Network resources (routing capacity, network bandwidth, etc)
2. Web server resources (processor power, memory power, host networking capacity)
3. Database server resources

Mitigating a DOS attack involves protections at all three levels of the infrastructure.

One popular DOS attack is the “Distributed Denial of Service” attack.

Mitigation for this type of attack include:

• Network layer traffic filtering to attempt to block sources of the network-based DOS traffic.
• Increased network bandwidth and capability – Can you out-power the attackers.
• Website mirroring and caching can be employed.
• Website collocating can also help. If your website is hosted on multiple physical networks, taking the site down involves attacking multiple network resources.

A second attack vector is against the web server’s physical resources.

Perhaps you can get enough traffic through the network filters to overwhelm the web server’s processing capabilities.

Mitigation for this type of attack include:

• Throttling network filtering to ensure that the web server(s) do not get more traffic than they can handle.
• Website mirroring helps by adding additional capacity.
• Caching can also help by reducing the amount of processing necessary to serve the site.

Another type of DOS attack is a targeted attack against the applications running on the website.

If the website uses a database back-end, it is possible to execute a DOS attack by using SQL Injections that destroy database integrity, or prevent database access.

Mitigation for this type of attack include:

• Proper coding practices in the web applications that prevent SQL Injection attacks.
• Proper database account security that prevents unauthorized destruction of data.
• Database redundancy that attempts to keep the data available even if one or more data source is unavailable.

A snapshot of topics of personal interest that have been talked about in the IT Security realm over the past week.

NOTE: I have changed the name of this weekly post from “this week in infosec” to “last week in infosec” to capture the obscenely obvious.

NOTE 2: Last two weeks have been crushingly busy. Will try to catch up this coming week, but have doubts about my capability :)

Threats/Countermeasures

New core networking vulnerability in TCP on the horizon

Thought things were over when Kaminsky’s bug got fixed? Guess again.

From Rich Mogul’s Securosis blog: Massive TCP Flaw Looming (selected quotes)

Basically, it’s a massive unpatched denial of service attack that can take down nearly anything that uses TCP, in some cases forcing remote systems to reboot or potentially causing local damage. Codified in a tool called “Sockstress”, Robert E. Lee and Jack C. Louis seem to be having trouble getting the infrastructure vendors to pay attention.

From what Robert told me, supported by the articles, this tool allows an attacker to basically take down anything they want from nearly anywhere (like a home connection).

Rich points to other material:
Dark Reading Room: New DOS Attack Is a Killer
SearchSecurity: New attacks reveal fundamental problems with TCP

Rich followed up with a post on October 3: Why The TCP Attack Is Likely Bad, But Not That Bad - again, quoting selectively:

Here’s what I think you need to know:

1. It is almost certainly real.
2. Using this technique, an attacker with very few resources can lock up the TCP stack of the target system, potentially draining other resources, and maybe even forcing a reboot (Could this trash a host OS? We don’t know yet.).
3. Anything that accepts TCP connections is vulnerable. I believe that means passive sniffing/routing is safe.
4. The attack is obvious and traceable. Since we are using TCP and creating open connections (not UDP) it means spoofing/anonymous attacks don’t seem possible.
5. Thus, I’d be more worried about a botnet that floods your upstream provider than this targeted attack.
6. This is the kind of thing we should be able to filter, once our defenses are updated.

Countermeasures -
None at the moment - prayer might be a good start. From the SearchSecurity article:

“The best advice I have right now is don’t allow anonymous connections. Make whitelist so only certain IP addresses can come in,” Lee said, acknowledging the impracticality of that for a Web server or mail server or virtually any other TCP-enabled device. “There’s no real workaround right now.”

Verizon - Security FAIL
From BugTraq:
Verizon FIOS (and DSL?) wireless access point insecure default WEP key

By default, the 40-bit WEP key for the wireless router provided by
Verizon to FiOS (fiber optic) and possibly DSL customers is set to the
last 40 bits of the router’s 48-bit MAC address. This is significant
because the router’s MAC address (the MAC address of it’s WAN-side
ethernet port) is easily discoverable using kismet without even
needing to know the WEP key.

When I got my FIOS, I was excited to see that they at least had WEB enabled by default.

Because I don’t trust any wireless connection, I didn’t even bother looking too closely at the default WEP key. The built-in firewall is enabled, and it seemed much better of a default configuration than I expected.

But using the MAC as the WEP key… Uh… FAIL

Countermeasure - Change your WEP key. Do it… 5 minutes…

Yes, you can crack WEP easily, but why make it obscenely obvious. Changing the default at least makes the attacker have to work more than 30 seconds.

Attack Vectors/Trends

Exploiting web trends to serve malware
From ZDNet’s ZeroDay blog post: Cybercriminals syndicating Google Trends keywords to serve malware

In an underground ecosystem that is anything but old fashioned when it comes to abusing legitimate web services, cybecriminals have started exploiting the traffic momentum, and by monitoring the peak traffic for popular search queries using Google’s Trends, are syndicating the keywords in order to acquire the traffic and direct it to malware serving blogs primarily hosted at Windows Live’s Spaces.

One method for distributing malware is getting people to visit your malicious website and then using browser hacks or other tactics to get the user to download and install your app.

This technique takes advantage of popular search terms to seed their malware pages, increasing their relevancy in searches.

Cute.