It’s hard to believe that it is almost 2011 and some systems are still rolling out with the same passwords that have been in use for over ten years. Some vendors are way past this but others seem to be stuck at this Security 101 concept. So, please forgive a little rant as I describe the situation and try to make a few practical recommendations.
What is the problem?
Control systems have a long history of using default credentials and here you can insert the boring history of “they used to be isolated but then…”. I could sympathize with that some if I wasn’t seeing the same poor practices on new systems and components deployed even within the last year. Again, some vendors are way past this but others are not. I see two levels:
1.) Willfully selling out security principles for something else. In this scenario, default credentials are used for ease of implementation or ease of support. In some cases, customers are not allowed to change the passwords and risk violating support contracts if they do. In the worst cases, changing passwords actually breaks functionality in the system.
2.) Ignorance of underlying components. Supporting applications, namely database servers, tend to be ignored when it comes to basic hardening principles. I’ve been hitting default Oracle and MSSQL accounts hard in assessments in the last 18-24 months and they are more common than you might think. Often the asset owner is unaware that a database exists let alone has default credentials that can be used to gain access to configuration data and ultimately own the system.
Some will say that password authentication is a problem in itself, but we’ll save that for a later post.
How can we fix it (big picture)?
We’ve tried a few things. We have this from NERC CIP-007:
R5.2. The Responsible Entity shall implement a policy to minimize and manage the scope and acceptable use of administrator, shared, and other generic account privileges including factory default accounts.R5.2.1. The policy shall include the removal, disabling, or renaming of such accounts where possible. For such accounts that must remain enabled, passwords shall be changed prior to putting any system into service.
The Cybersecurity Procurement Language for Control Systems addresses default credentials in numerous places, here’s an excerpt of one:
The Vendor shall recommend which accounts need to be active and those that can be disabled, removed, or modified. The Purchaser shall approve in writing the Vendor’s recommendation.
The Vendor shall disable, remove, or modify all the accounts pursuant to the approved recommendation.
Post-contract award, the Vendor shall disable or remove all default and guest accounts prior to the FAT. Once changed, new accounts will not be published except that new account information and passwords will be provided by the Vendor via protected media. After the SAT the Vendor shall disable, remove, or modify all Vendor-owned accounts or negotiate account ownership with the Purchaser.
Of course default credentials are also addressed in NIST 800-53, ISA-99, and the list goes on. So, if none of these things have helped change the reality on the ground, what will?
Maybe if we have some high-profile control system malware that leverages default credentials and makes global news… oh wait, that happened. Or maybe if there was a search engine that made it easy to find and attack Internet-connected control system equipment… oh wait, that happened too. Here’s hoping that Stuxnet and Shodan have a positive effect by helping propel us in the right direction.
How can we I fix my own system?
- Start with the assumption that there are default or easily guessed accounts somewhere in your system because they are usually there.
- Look beyond the operating systems – SNMP, databases, web interfaces to field devices, and network equipment are a few common places to find default credentials.
- Vulnerability scanners like Nessus can help with discovery for some of the basic applications, but you should dig further. Sometimes manual testing is required.
- More often than not, default credentials can be found with a Google search. Don’t let an attacker have the advantage, check this out for yourself. Here’s a search string that will help get you started (just add your device or application name): default password filetype:pdf. You can try without the filetype parameter as well but 80-90% of the time, I find the information you want is in a PDF user manual.
- Encourage your vendor (contractually, if possible) to disclose and change default credentials.
The issue of not only “default” or “hard-coded” passwords, but general password “strength” represents a significant vulnerability within ICS architectures. This is why I recommend not only (1) an authenticated scan with Nessus and a pre-approved group of audit files to validate compliance, but (2) a white-hat test whereby the password SAM is analyzed against an extensive wordlist to confirm that common passwords, dictionary words, and common variants are not used. One of the cornerstones of “Think like a hacker …” combines black-box and white-box tests which yield valuable results without actually performing a physical pen-test on the ICS.