Fortinet SSH Backdoor Shenanigans

Good morning campers, if you have a Fortinet device running an elderly version of FortiOS you will really want to read to the end of this post.

Forti-what now?

Forti-what now?

In Short

There is an interactive SSH backdoor built into a large spread of Fortinet FortiOS devices. This includes dozens of router and firewall models, as well as their more recent threat management devices.

Roll up, roll up

Roll up, roll up

The backdoor permits an unauthorised user to gain substantial access to the device via its SSH management interface, without a username or password.

The vulnerable versions are officially confirmed to be:

    • FortiOS 4.3.0 to 4.3.16
    • FortiOS 5.0.0 to 5.0.7

In addition there are community reports that earlier version 4 branches (4.0 onwards) may also be vulnerable.

Currently supported branches (FortiOS 5.2 and 5.4) are not affected.

Clearly this is bad news, and Fortinet have confirmed it in a rather terse official posting.

Backdoors and You

It is perhaps alarmist to refer to this as a ‘backdoor’ right off the bat; a backdoor is a hole deliberately introduced into an otherwise strong and integral security system, to permit access to resources without going through proper authentication and authorisation. If your file server had a backdoor, placed there for example by a malicious user, that user might retain access to the server long after the administrator disables or deletes their ‘official’ account.

Copyright someone else entirely

Copyright someone else entirely

Backdoors are also commonly installed by external hackers as a means of retaining access once their initial compromise vector is inevitably closed off, or by nosy nation states that prefer to know precisely which episodes of The Good Wife you’ve been watching, and when.

Fortinet themselves are referring to this as an “Undocumented Interactive Login Vulnerability”.

Make of that what you will…

Mismanagement Protocol

To editorialise somewhat, this particular FortiOS ‘vulnerability’ appears more like a badly implemented management function than anything too sinister or underhanded. Vendors are well known for adding ‘back channel’ logins during firmware and product development, and to their shame a number of vendors have been caught out failing to properly disable their internal tools when the code is shipped to primetime.

In this case, Fortinet have already ‘fixed’ the problem; they contest that recent ‘supported’ releases of FortiOS do not suffer from this issue.

The patch notes for these versions do not mention the excision of any malicious backdoor code. It is difficult to speak to this inconsistency, it could be an elaborate coverup Fortinet have been praying would never come back to haunt them or it could merely represent the well-natured removal of a forgotten administrative protocol.

Shhhh I don't think anyone noticed...

Shhhh I don’t think anyone noticed…

Technical Analysis

The Fortinet backdoor (I will refer to it as such from now on for the sake of convenience, as we shall see it is certainly not a front door…) operates in a slightly nonstandard fashion.

The management interface of the Fortinet appliance listens for SSH connections; it would be nice to live in a world where no such management interface is exposed to the world, but sadly we don’t live in that reality. Somewhere, a vulnerable FortiOS appliance is listening on an SSH port.

Sophisticated authentication protocol or what

Sophisticated authentication protocol or what

The Proof of Concept script released to the world runs in the perennial favourite language for such things, Python. The original seclist disclosure of the backdoor code can be found here. By dissecting this script, we are able to determine how this particular backdoor operates.

The backdoor is triggered by an SSH connection to the Fortinet appliance, using a rather predictable username with a blank password. Now things get interesting.

Wait for it...

Wait for it…

The Fortinet appliance responds to the interactive session with a numerical value; this is similar in operation to various One Time Password systems, and in fairness to Fortinet would have been pretty tough to reverse-engineer without the PoC code. The script accepts this numerical value, and from it calculates the password it must submit.

Wait for iiit...

Wait for iiit…

The freshly minted password is submitted and….



In the words of my generation, pwned.

Did we mention that the FortiOS appliance hides all logs of these transactions from you, the diligent administrator?




Fortinet’s own remediation advice is really quite straightforward; patch to the latest version.

The most recent releases of the 4.3 and 5.0 FortiOS branches have the backdoor removed.

In the event that such an in-place upgrade is either impossible or too far out-of-band, there are some short-term workarounds that may help, specifically;

    • Disable SSH administrative access on all interfaces; you will rely on the Web GUI for all administrative tasks
    • Restrict direct SSH access to the smallest possible range of known-friendly IP addresses

These steps are good security practice in any case, the emergence of this backdoor simply underscores the need to ensure that administrative interfaces are locked down to the greatest possible degree.

On January 12th, OxCERT were speculating that tomorrow would bring a surge in inbound SSH traffic as various scanners began to pick up the exploit code, and this is precisely what happened;

Showing only Port 22, inbound to Autonomous System 786 (us)

Showing only Port 22, inbound to our Autonomous System

This output from our prototype NetFlow analytics system shows a fairly clear surge in Port 22 traffic just as news of the exploit was spreading across Reddit and various news sources like Arstechnica were gearing up for their evening reporting of ‘The Fortinet Backdoor‘.

Be safe out there.


Paul D. Hood

Further Reading

Posted in Uncategorized | Comments Off on Fortinet SSH Backdoor Shenanigans

Comments are closed.