Fortinet on SSH vulnerabilities: look, this really isn't a backdoor, honest

Security firm goes full disclosure on mechanics of SSH issue and finds three more vulnerabilities

A rose by any other name ....
A rose by any other name ....

Cyber-security solutions firm Fortinet has taken a proactive ‘sharing with the group' approach to dealing with confirmed vulnerabilities that have surfaced across its product line. The firewall and network security company has been open about the technical details of recent events, but perhaps less keen to label the exact nature of the dangers that may have been uncovered.

Fortinet has refuted claims that an interactive login vulnerability affecting older versions of FortiOS could have been a backdoor for hackers to gain remote console access to vulnerable devices. As detailed on SC Magazine, the firm has instead referred to the vulnerability as a “management authentication” issue.

The access in question would enable remote console access to vulnerable devices with "Administrative Access" enabled for secure shell (SSH).

To keep its ship strong, Fortinet insists that it complies with ISO industry-leading best practices that drive regular review processes. These include “multiple tiers” of inspection, internal (and third-party) audits, plus automated triggers across its entire base of source code.  

Oh… we found some more problems too

Following the recent SSH issue, Fortinet's Product Security Incident Response team says it discovered the same vulnerability issue on some versions of FortiSwitch, FortiAnalyzer and FortiCache.  These versions have the same “management authentication” (there's that term again) issue that was disclosed in legacy versions of FortiOS.

Despite security industry commentators insisting that this vulnerability is still a backdoor relabeled as a management mishap, Fortinet has added more gloss to its already arguably well-greased description of events.

“As previously stated, this vulnerability is an unintentional consequence of a feature that was designed with the intent of providing seamless access from an authorised FortiManager to registered FortiGate devices. It is important to note, this is not a case of a malicious backdoor implemented to grant unauthorised user access,” stated the company, in an open blog.

For clarity and completeness here, FortiSwitch Ethernet Access and Data Center Switches are increasingly used in offices, as well as data centre environments. FortiAnalyzer network security logging, analysis and reporting appliances aggregate log data from Fortinet Security Appliances. FortiCache is described as a high-end caching solution to provide application caching for large enterprises. All of these products are said to have been affected within the realm of this report.

Terminology tautology

Speaking directly to on this issue was co-founder of Xiphos Research, Michael Kemp. With a wistfully metaphysical air about his words, Kemp says that the ‘when is a backdoor not a backdoor' conundrum is a fascinating philosophical debate, but, he argues, it is a moderately useless technical one.

“To access the original management authentication feature, a legitimate user (or attacker for that matter) has to follow a number of complicated steps. This isn't hardcoded credentials or similar that would be ascribed to an insertion by a random attacker… and at least the first vulnerability that emerged relied upon client and server making sophisticated negotiations prior to authentication,” said Kemp.

“There is definitely a use case for this, just not one that many customers would have been comfortable with (“Hi, we'd like remote access to your security estate which we won't tell you about. Everyone cool with that?”). The fact that there is now more transparency from Fortinet regarding the authentication flaws of its equipment is a good thing, the fact that they are still debating the meaning of the term backdoor is not,” he said.

Kemp concludes by saying that it is “massively unlikely” that this would be a backdoor for law enforcement and intelligence gathering… and it may well have a legitimate purpose for being there (to assist with management and support activities by the vendor).

He states, “What is less legitimate and has had the unfortunate side effect of placing customers at risk, is not actually telling anyone about it until it was detected and not allowing this ‘feature' to be disabled in production environments from the get go. The rest of this is PR window dressing and doesn't excuse the fact a vendor potentially added undocumented features to make their own lives easier whilst downgrading customer security.”

Also on a direct line to in connection with this story was Richard Cassidy, technical director EMEA, Alert Logic. Cassidy said that organisations already have a ‘mountainous task' in the great cyber-security battle.

“You have to wonder why, therefore,  any ‘backdoor' would be purposely implemented in the code of a core security technology such as this. Furthermore to attempt to claim that this function is a manageability issue and not a vulnerability is not the kind of response one would expect from a leading security vendor such as Fortinet,” states Cassidy.

“Any access that can be gained to a system without the need for strong authentication by a third party is unacceptable in terms of security practices, at all levels of compliance and data security assurance. Regardless of the source of this data, it's pretty astonishing in light of the recent discovery on Juniper security gateway devices; cyber-criminals are more capable and resourced than ever, searching for vulnerabilities of this kind is always high on their target list, we can be absolutely assured that they will have been searching for this and one only hope it hasn't been an exploit in use already against organisations,” he added.

Calling Catalin Cosoi

Finalising the commentary on this story this week in a communiqué made directly with was Catalin Cosoi, chief security strategist at Bitdefender. Cosoi argues that, “Regardless of what software technologies [and terminologies] companies use, they do risk losing reputation and business as a result of consecutive data breaches.”

He surmises, “Companies not only have the responsibility to thoroughly asses all software goods and even set up redundancies and failsafe mechanisms, but also dissect past data breaches so that the same security mistakes can be avoided in the future. To this end, both the company and the security offering share the responsibility of securing both data and access to critical infrastructure.”

You must be a registered member of SC Magazine to post a comment.

Sign up to our newsletters