A RuggedCom switch and server (shown on either side of the electrical outlet) have a manufacturer-installed backdoor in their operating systems. Photo: Courtesy Justin W. Clarke
After ignoring a serious security vulnerability in its product for at least a year, a Canadian company that makes equipment and software for critical industrial control systems announced quietly on Friday that it would eliminate a backdoor login account in its flagship operating system, following public disclosure and pressure.
RuggedCom, which was purchased recently by German-conglomerate Siemens, said in the next few weeks it would be releasing new versions of its RuggedCom firmware in order to remove the backdoor account in critical components used in power grids, railway and traffic control systems, as well as military systems.
The company also said in a press release that the update would disable telnet and remote shell services by default. The latter were two communication vectors that would allow an intruder to discover and exploit a vulnerable system.
Critics say the company should never have installed the backdoor, which was exposed last week by independent security researcher Justin W. Clarke, and has, as a result, exhibited no evidence of security awareness in its development process, raising questions about other problems its products may contain.
“This ‘developer backdoor’ made it into release,” wrote Reid Weightman, a security researcher with Digital Bond, a company that focuses on industrial control system security, in a blog post on Monday. “Nobody and no process at RuggedCom stopped it, and RuggedCom has no process to address security concerns in already-released products. They were not going to fix it at all until Justin went full disclosure.”
Clarke, a San Francisco-based researcher who works in the energy sector, discovered the undocumented backdoor last year in the RuggedCom operating system after purchasing two used RuggedCom devices – an RS900 switch and an RS400 serial server – on eBay for less than $100 each and examining the firmware installed on them.
Clarke discovered that the login credentials for the backdoor included a static username, “factory,” that was assigned by the vendor and couldn’t be changed by customers, and a dynamically generated password that is based on the individual MAC address, or media access control address, for any specific device. He found that the password could be easily uncovered by simply inserting the MAC address, if known, into a simple Perl script that he wrote.
Clarke notified RuggedCom of his discovery in April 2011. A company representative told him that RuggedCom was already aware of the backdoor, but then stopped communicating with him about it. Two months ago, Clarke reported the issue to the Department of Homeland Security’s Industrial Control System Cyber Emergency Response Team and the CERT Coordination Center at Carnegie Mellon University.
Although CERT contacted RuggedCom about the vulnerability, the vendor was unresponsive.
That is, until Clarke threatened to go public with information about the backdoor. RuggedCom then asserted on Apr. 11 that it needed three more weeks to notify customers, but gave no indication that it planned to fix the backdoor vulnerability by issuing a firmware upgrade.
Clarke told the company he would wait three weeks if RuggedCom assured him it planned to issue an upgrade that would remove the backdoor. When the company ignored him, he took the information public on Apr. 18, by posting information about the backdoor on the Full Disclosure security list.
RuggedCom failed to respond to reporter inquiries last week about the issue, but quietly issued its press release late Friday, detailing which versions of the firmware are vulnerable and what it planned to do to fix them.
Wightman criticized the company for failing to acknowledge the trouble the backdoor creates for customers who now have to upgrade their firmware to eliminate the vulnerability it created.
“This is bad because RuggedCom’s product is not software, it is hardware and firmware,” he wrote in a blog post. “Upgrading a field-deployed device like this is expensive and can only be done at a time when entire networks of end devices (PLCs, RTUs, relays, etc) can be offline. That is not often. It is a cost that is passed on to RuggedCom’s customers in downtime and risk….”
Dale Peterson, founder and CEO of Digital Bond, said the company needs to provide more explanation to customers about what happened.
“They really need to talk about how this is not going to happen again,” he said. “How did the feature get into the product and why was the [initial] response like it was?”
Peterson, who refers to RuggedCom as the “Cisco of network infrastructure equipment” due to its core role in critical systems, said that because RuggedCom refused to address the issue for a year, other researchers are now taking a look at the company’s products to uncover more vulnerabilities.
“I’m already aware of a couple of [other] RuggedCom vulnerabilities,” he said. “When people see something so blatant and such a disregard for dealing with it, they say, ‘Well, there’s got to be other stuff in here.’ So there’s already people looking at it and things found.”
RuggedCom, on Monday, referred inquiries about its press release to Siemens. Siemens did not immediately respond to questions.
Clarke said in an e-mail to Threat Level that he hoped the incident “makes other vendors realize they need to participate when responsible coordinated disclosure is attempted. Sadly, I doubt this will be the turning point.”