Embedded Passwords: Dangerous by Default
Devices ranging from home wireless routers to printers to major industrial systems often use hard-coded passwords and embedded credentials -- built-in usernames and passwords that are sometimes publicly known. In some cases, admins close up these potential security holes by manually changing the credentials, but other times the step is overlooked. And in a few cases, it's not even possible.
The security community was horrified when it learned about Stuxnet, the worm designed to eat into industrial control systems, or SCADA systems, that was purportedly targeted at Iran's Bushehr nuclear reactor.
Hard-coded passwords and embedded credentials are "extremely pervasive," being found in "everything from embedded systems such as printers, mobile and wireless devices, to databases to major applications like SAP or Oracle's PeopleSoft," Stuart McClure, senior vice president of risk and compliance at McAfee, told TechNewsWorld.
Default passwords, which are included in everything from routers to software, can and should be changed, although many users don't do so. The most common example of this is wireless routers, most of which offer no security at all unless users actively change their default passwords.
"Administrators sometimes neglect to change default passwords due to fear of breaking things and creating more work for themselves," McClure said.
So why would anyone include default passwords in their products?
Having a default password makes it easy to install large numbers of devices, Russell Smoak, director of security research and operations at Cisco Systems, told TechNewsWorld. Further, default passwords allow untrusted suppliers to install large numbers of devices or do pre-staging because the passwords can later be changed, Smoak said.
Hard-coded passwords, however, cannot be changed by system administrators. They can be a "significant security risk," Smoak pointed out. "They reduce the security posture and expose devices to illicit access," he explained.
Outlining the Threat
"Using embedded credentials secures apps from regular system users to some degree, but it's like closing your door but leaving it unlocked," Al Hilwa, a program director at IDC, told TechNewsWorld. "Unless there are ways to obfuscate code in a secure way, embedded credentials will be readable by anyone who has access to the code."
Cisco's Unified Videoconferencing products constitute a case in point. Several of the products in the Cisco Unified Videoconferencing 5100, 5200 and 3500 series run on a Linux shell which contains three hard-coded usernames and passwords that cannot be changed.
The accounts can't be deleted, either. Cisco has warned that these products have multiple vulnerabilities that let attackers obtain remote access to them illicitly to compromise them.
It's not as if the danger of embedded credentials and hard-coded passwords is new.
"This is a well-known industry issue and you'd have thought that most major software players would have expurgated these passwords and credentials from their code by now, but it's clearly not the case," Hilwa said.
The problem is most clearly seen in databases, attacks on which often yield thousands of names for cybercriminals to harvest and exploit with identity theft schemes. However, just getting rid of default passwords in databases isn't a solution, because they are included in the databases for a reason.
"Having default accounts is very helpful in a testing environment," Noa Bar Yosef, a senior security strategist at Imperva, told TechNewsWorld. "They let you do everything from testing the connection to creating tables and testing scripts."
For example, every default Oracle installation contains a default test account which is accessed using the credentials "scott" or "tiger," Bar Yosef said. The "scott" default username has a limited set of privileges, but these are sometimes elevated for testing.
The trouble occurs when testers forget to restore the original privilege level for the username or delete the username altogether, and the database is moved into production. That might open the database to hacking, Bar Yosef pointed out.
Vendors generally view hard-coded passwords as unacceptable even though they use them, Barbara Fraser, CTO Consulting Engineering at Cisco, told TechNewsWorld.
"Over the years, I've seen an increased awareness of the risk represented by embedded credentials, but also an increased focus within the industry to eliminate or avoid them altogether," Fraser added.
The trouble is that there's lots of old code that's difficult to secure, IDC's Hilwa pointed out.
It wouldn't be wise for DBAs to change or delete hard-coded password accounts at once.
For example, the owner of a database may not be able to change a default hard-coded password because it might break the application or he's restricted from doing so, Bar Yosef suggested. He will have to find a bypass solution instead.
That's not necessarily the case, Adam Bosnian, an executive vice president at Cyber-Ark, told TechNewsWorld.
"If you don't change the password correctly and restart the app correctly it would be a problem," Bosnian said. "If you can set the credential there must be a way to reset it and manage it in a more secure manner."
Corporations should set up a database assessment process that tests their databases against accepted industry benchmarks, Bar Yousef recommended. They should also hold one individual accountable for ensuring that default logins and accounts are taken off production servers, she added.
Some security vendors offer products that search for default passwords and notify system administrators in real-time. One is McAfee Vulnerability Manager. Further, third-party applications like John the Ripper and L0phtcrack that audit weak passwords have been available for a while, McAfee's McClure said.
Corporations don't necessarily need a vendor to do the job for them, Bosnian said. "These things can be fixed without product, but you need to monitor what you do," he explained.
Meanwhile, the International Organization for Standardization (ISO) is working on secure coding guidelines, Fraser said.
However, these may not be accepted wholeheartedly by vendors.
"Once completed, it remains to be seen how the secure coding practices will be applied within the industry," Fraser said.
"We will need a few more Stuxnets to give the situation the urgency it deserves," McClure opined.