Perhaps, I am over simplifying the root causes but the information available to me makes me want to get up on the soap box to talk about security basics.

I have a love-hate relationship with the idea of computer appliances. On one hand, this pre-installed piece of hardware is ready-to-go. It has already been configured, tested, and you can pretty much guarantee it is going to work when you plug it in. This is a real operational cost savings.

On the other hand, I have many security concerns which stem from the “default” nature of their configuration. After all, an appliance usually runs on top of a general-purpose operating system combined with commonly available software such as databases.

“The [Stuxnet] worm was directed at a very popular process controller (Siemens Simatic Programmable Logic Controller) and exploited a zero-day vulnerability in the PLC's WINCC SQL database.

The exploit lay bare the disconnect between the IT and Industrial Control Systems (ICS) communities. This particular PLC (as well as many other ICSs) burned the default passwords in software. The hackers exploited this design to get access to the database.”[1]

If you're an organization which deploys appliances, does the vendor provide the ability to change default parameters such as a password?

When it comes to minimizing the attack surface and applying patches, I hear so many reasons not to remove software and not to apply patches. I've heard that the cost to install software later is more than if they just delivered it in the original installation – besides, there is very few services or packages one can leave off the system.

As Colonel Sherman T. Potter, my favorite character from the television series M*A*S*H, would say, “Mule Muffins.”

I ran the following shell command on two generic Linux server installations to determine how many services were not running and their associated packages:

In Fedora 12, there were approximately 30 services not running and in openSUSE 11 there were about 40 services. My argument is if the system is performing its assigned tasks and these services aren't running, then remove them before they become inadvertently started or associated tools are exploited.

This is no reflection on an operating system itself; it simply means that operating system distributions typically include many services for maximum interoperability and ease of configuration. Nonetheless, you should take a serious look at what isn't used on your system and remove it.

Every good operating environment should have a digitally signed software repository where system administrators can pull authorized software and patches. This only takes a few seconds and the beautiful thing about Linux packaging is that it resolves dependencies.

So, if you needed to add a webserver (e.g., Apache), all of the associated packages could easily be pulled and installed in your operating system very quickly.

When I read about the state of NATO systems and their reported reluctance to apply system patches, I began to grind my teeth:

NATO's systems are behind the U.S.'s, said one person familiar with U.S. assessments of NATO's systems after a recent trip the deputy defense secretary made there. "The Chinese totally owned them," this person said, adding that NATO hadn't installed many of the basic network security patches, because it had decided some of its computers were too important to ever turn off.[2]

NATO spokesman James Appathurai denied that the alliance's computers were regularly compromised. However, I didn't hear him dispute the fact that the systems were missing many of the basic security patches.

So, is it just a matter of time? Or have the systems already been comprised but NATO is unaware? Lastly, if the systems are so important, why isn't there any redundancy? A load-balanced or fail-over system?

How many applications have been deployed in your environment with default passwords? When was the last time they were patched? How many lingering, dormant services reside on your systems?

Jamie Adams
@Shawn... thanks for that information. I did not know that!! I've never worked in that industry. With that said, I'd be interested in a master list of "appliance" based technologies used in various industries. Very scary.

1285621486

Danny Lieberman
I can echo Shawn's input regarding medical devices - is that since they are generally small footprint hardware embedded systems - the technician password is hardcoded.

shawn merdinger
@Jamie - I'm unaware of such a master list, at last in the public domain, though I expect many companies doing their research in differing verticals have such info for competitive intelligence purposes.

For a great tangible demonstration of default passwords in many vendors' gear, check out the well-established "Default Passowrd List" by the German research outfit Phenoelit here: http://www.phenoelit-us.org/dpl/dpl.html

As for real-world examples of live devices, on the Internet right now, with no or default passwords, Shodan is the best tool now. For example, here is the most popular Shodan search for Cisco routers/switches with HTTP enabled, but no password set and almost 6000 open worldwide for the taking right now.

Jamie Adams
@Shawn.. thanks for the links! I am getting ready to do another podcast and I believe the next topic will be on appliances and embedded systems. The sheer number of burned-in default passwords used to make deployment easier really, really scares me!

David Alexander
I appreciate the directness of this article and I agree with its tenets. However, as an employee in the IT Division of a "Power Industry" organization, let me set the record straight on a few IT Security assumptions here that may shed some light on WHY there is such a proliferation of these issues.

First, as with many organizations that utilize this equipment, it is NOT the IT organizations that design, implement , and maintain this type of equipment. It is typically power system engineers and associates that perform these tasks/projects.

Second, when these systems are designed and implemented, there is an expectancy of a long durable life with this equipment, up words of 15-20 years, whereas the life span of an IT system is usually rated to be three to seven years. With the move to more automation, and the utilization of more computer automation, these design methods are reaching critical mass. The power system engineers are being forced to rely on computers to perform functions for a much shorter time and are not used to the idea of such a short lifespan. They are just now starting to include IT in the design, implementation, and maintenance of SCADA-type environments.

These two factors have caused a collision of approach; with the addition of the Internet, security is now being approached as a bolt-on optional extra. It will probably take a complete cycle of these first-generation SCADA environments before security is taken as a fundamental design requirement, three to seven years.

1285686119

Jamie Adams
@David.. that is really good information and insight into your world. Thank you for the information!

I believe the author's point is that if they are installed but not being used, remove them, since they come with default configs (and usually default credentials) and potentially exploitable tools and executables.

The author clearly uses an RPM based system. I just throught I might help and provide the equivelant for dpkg based distributions.

1285693099

Jamie Adams
@Danny... wow.. great information. I am learning a lot about the power industry and the different groups who manage/involved in their security.

Also, @Adam's script is correct.. the "-v" option inverts the logic and shows only those services which does not have ":on"

1285693162

Jamie Adams
@Danny.. by the way, the quote of the week here in my office is now "I shudder at the thought of a nuclear reactor SCADA system being secured by a Windows IT admin." ... just beautiful ...we all got a great laugh at that.

1285693265

David Alexander
@Danny: I disagree. Actually, the issue here is not WHO should design, install and maintain the environment. The issue here is that neither side allows collaboration from the other. In the case of the engineers, they think that systems design is easy and there is minimal consideration given to SDLC or information security. From the IT perspective, they dismiss the longevity of a system, seldom understand the depth and breadth of the control data and environments, and other engineering concerns. So, the result is that neither side is completely correct and both sides actually need to foster a collaborative effort because they both bring critical experience and requirements to the table.

My previous point was simply to have people understand some of the history of WHY our SCADA/control systems are in the "IT Security" situation they are in.

The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.