Doomed by default passwords

Many years ago, I was hired to penetration-test a customer’s IBM AS/400 system, and the system administrator admonished me for even trying. “AS/400s aren’t like cheap and insecure little PC systems,” he argued. “They’re built from the ground up to be secure.”

As he completed his last sentence, I logged into his system and took complete control of it. He had not changed the default account password. It had been left as is for almost 20 years. His system was contactable over the Internet, so I had to wonder, as his mouth dropped open, if I’d been the first to try the obvious.

[ Download Roger Grimes’s “Data Loss Prevention Deep Dive” PDF expert guide today! | Stay up to date on the latest security developments with InfoWorld’s Security Central newsletter. | Get a dose of daily computer security news by following Roger Grimes on Twitter. ]

This anecdote came to mind not long ago as I read about more SCADA (supervisory control and data acquisition) systems with hard-coded passwords. Legacy systems are often the culprit, but as the Stuxnet worm showed last year, even modern SCADA systems are vulnerable. More recently, a hacker going by the handle of prOF claims to have hacked into a South Houston waterworks SCADA system because it was easily findable on the Internet and had a 3-character password. Why is a public waterworks system using 3-character passwords? Why are there SCADA systems allowing 3-character passwords?

Legacy systems don’t get a password pass Most vendors ship software and hardware with default admin logon names and passwords. The better vendors force users to choose a new password when logging in for the first time, require strong passwords, and force adequate password updates after that. The worst vendors have products with hard-coded administrative passwords that cannot be changed.

The risk posed by hard-coded passwords is nothing new — it’s No. 7 on the top 25 list of dangerous software errors. SCADA systems are more at risk for a couple of reasons: The SCADA industry, in general, is at least a few years behind the rest of the software industry in writing secure code, and SCADA systems often come with long depreciation schedules. Whereas organizations might upgrade office PCs every three to five years, they would usually keep the same SCADA system running for decades.

SCADA environments are full of devices and appliances with supposedly secure operating systems. However, when examined, most fall over just as easily as their comparable software counterparts. Most contain old versions of OSes (such as Windows 3.1 and NT) and software, with aged, publicly known exploits; they also tend to have easy-to-find security bypasses, cross-site-scripting vulnerabilities, or any other software programming error that might be made in software.

What is a device or appliance other than software on a chip or proprietary hardware? There is absolutely nothing inherently more secure about a device or appliance as compared to a regular software system. Software systems are easier to patch and can be made more secure because the software components are simpler to inspect and upgrade.

Perform a password check Many SCADA environments have at least a few of these weakly password-protected systems lying around. It goes without saying that these systems need to be found and mitigated. It can be a single-person project or a team endeavor.

First, search for and locate all the appliances, computer devices, and network-connected SCADA systems in your environment. Don’t forget to include your routers, wireless access points, badge machines, network-connected copy machines, and dusty SCADA control systems.

Next, locate and use one of the many big lists of default passwords available on the Internet. My favorites are available through Phenoelit, Default Password, and CIRT. If you have a device or system that isn’t listed, you can always try performing an Internet search using the product’s name or model number, along with the search terms “default password.” They work most of the time.

Then, using the vendor’s default logon names and passwords, try each device in your environment. Each item still using a default password should be marked for immediate change (if allowed by the vendor) and altered after going through change control authorization.

Devices with hard-coded, unchangeable passwords should be considered for removal, especially from the network or from Internet connectivity. If the product is still supported, contact the vendor and ask for product updates to correct the situation. If the product is no longer supported or the vendor doesn’t want to make the necessary changes, consider deprovisioning the device. If a hacker took complete control of the system, how much damage could he or she cause? Is the device’s function worth the risk?

If you can’t remove or secure the device, make sure physical and logical access is strictly controlled. Allowing any Internet access to a SCADA device is high risk, but permitting access to one with a weak password is unforgivable. A last-ditch effort, if you must keep it on the network, might be to filter out incoming weak password strings if you can get a proxy or filtering machine in between the rest of the network and the problem device.

Even your properly protected SCADA devices should be re-examined. A complex 8-character password is no longer considered secure in today’s world of cloud computing and graphic-CPU computing. Today, complex 12-character passwords constitute the bare minimum. Network traffic streams containing authentication information must be encrypted and authenticated. Plaintext-passing protocols, such as Telnet and 3270 protocols, are no longer acceptable.

SCADA systems are under attack like never before, and administrators can no longer count on obscurity as their greatest protector.

This story, “Doomed by default passwords,” was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes’s Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.