Stuxnet Worm Reveals Default Password Vulnerabilities

Monday, September 27, 2010

Jamie Adams


Just put it into production, it will be okay...

In the last two weeks, I've heard some things which made my blood boil. Such as the recent Stuxnet worm, continued cyber attacks against The Pentagon and NATO, and an article describing past U.S. electricity grid intrusions.

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.

After reading an article which identified the primary attack vector as a default password on a programmable logic controller (PLC), I cringed:

“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:

 chkconfig --list |egrep -v ":on" |awk '{printf "rpm -q --file /etc/init.d/%s\n", $1}' |sh

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?

1. “Opinion: IT needs to help secure industrial control systems” by Joe Weiss of Computerworld (August 13, 2010)

2. “Cyber Attacks Test Pentagon, Allies and Foes” by SIOBHAN GORMAN in Washington and STEPHEN FIDLER in London, The Wall Street Journal (September 25, 2010)

Cross-posted from Security Blanket Technical Blog

Possibly Related Articles:
Operating Systems
Information Security
SCADA Vulnerabilities Operating Systems Stuxnet
Post Rating I Like this!
Jamie Adams For more information regarding the default password issue, please check out this article:
shawn merdinger Hardcoded passowrds are also a problem in huge integrated systems, such as electronic medical records systems. see
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.
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.

Then there is of course the entire ATM ball of wax -

Jamie Adams @Danny.. Oh, good gravy! I forgot about the whole embedded systems arena. ATMs, etc. very scary.
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:

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.

Bottom line? It's bad and getting worse.
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!
shawn merdinger For more documented issues with hardcoded credentials, do searches here:

Search terms: hardcoded password and hard coded password
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.
Jamie Adams @David.. that is really good information and insight into your world. Thank you for the information!
Danny Lieberman David

The last thing you want to do is to let IT people run your SCADA security.

IT people have neither the mindset nor the technical background to implement robust software security in your systems.

Based on my work in embedded medical devices and in industrial process control at an Intel Fab - I shudder at the thought of a nuclear reactor SCADA system being secured by a Windows IT admin.

Read this:

Adam Gomes chkconfig --list |egrep -v ":on" |awk '{printf "dpkg -S /etc/init.d/%s\n", $1}' | sh

For those of us who run Debian / dpkg based systems ....
Danny Lieberman Adam

It tells you what startup scripts are turned on - not the ones that are currently running


Adam Gomes Actually, Danny, it tells you which startup scripts are *NOT* turned on.

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.
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"
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.
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.
Danny Lieberman David

I hear you - but actually I think we agree.

There is a disconnects between IT and engineering just like there is a huge disconnect between IT and security.

Your next question would be how to close the gap.

The answer is by creating a simple common language of threats between the 3 different stakeholders.

We've been successful in doing this in a wide variety of industries from process control to telecom to medical devices to online commodities trading.

You can read more here:

Adrian Ro It's a mere surprise yet, according to data posted by Alexander Gostev, Chief Security Expert at Kaspersky Lab, India has topped the list of the most infected countries.
Page: « < 1 - 2 > »
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.