Fortinet has found that an SSH vulnerability may be more widespread than once thought. The company insisted that...
the flaw should not be considered a backdoor, and experts tended to agree.
The flaw allowed a Python exploit script -- posted earlier this month to the Full Disclosure mailing list -- to gain administrative access via SSH by taking advantage of hardcoded login credentials on devices using FortiOS versions 4.3.0 to 4.3.16 and 5.0.0 to 5.0.7. Fortinet initially said that systems updated with builds released after July 2014 were not affected. A new investigation by Fortinet's Product Security Incident Response team found that the vulnerability affects more versions of FortiOS than previously believed, as well as versions of FortiSwitch, FortiAnalyzer and FortiCache.
Fortinet asserted that updated devices are not affected, but refused to comment when SearchSecurity asked for an estimate of how many systems may still need to be updated.
Steve Gates, chief research analyst and principal engineer at NSFOCUS IB, said the use of hardcoded logins was a serious oversight by Fortinet.
"Security vendors need to think like attackers. If there is a hole, attackers will find it," Gates said. "The vulnerability could allow remote access to Fortinet's security and network devices deployed in a network. Once remote access is established, attackers can hijack devices, open security holes, sniff packets and a host of other unwanted activities."
The SSH vulnerability has been called a backdoor, because the issue stems from hardcoded login credentials in Fortinet products. Fortinet contended that the "vulnerability is an unintentional consequence of a feature that was designed with the intent of providing seamless access from an authorized FortiManager to registered FortiGate devices," and is not a malicious backdoor, but rather a "management authentication issue."
Experts agreed that hardcoded credentials were a bad idea, but gave Fortinet the benefit of the doubt that this issue was not a true backdoor because the access consequences were unintentional.
Rebecca Herold, CEO of Privacy Professor, said it matters whether the system was made unsecure intentionally or not when calling something a "backdoor," because it points to management endorsing the feature.
"When access is purposefully engineered into technology to allow admins, or others, to be able to get into a system [or] application, etc., using a method other than the access control method that the typical system [or] application users use, it is a backdoor. This is not a new concept or practice," Herold said.
"When I started my career as a systems engineer over 25 years ago, the programmers then were creating such backdoors. And many inappropriate accesses occurred as a result through these hardcoded holes. This really bad, but common, practice is one of the reasons I moved into the security field -- to help systems engineers understand the security risks of engineering these vulnerabilities into their systems and devices."
Learn about how lawmakers don't understand the problems with encryption backdoors.
Learn how Fortinet is unifying its channel approach.