SSH Backdoor for FortiGate OS Version 4.x up to 5.0.7

[MikeU]

SSH Backdoor for FortiGate OS Version 4.x up to 5.0.7

http://seclists.org/fulldisclosure/2016/Jan/26

I have not had a chance to try this. I don't see any threads discussing it. So, I thought I'd share.

[emnoc]

No set a generic public key for a user "'Fortimanager_Access" and see what happens.

[localhost]

You can't edit Fortimanager_Access.

FortiGate-VM64 (admin) # edit Fortimanager_Access
table name 'Fortimanager_Access' can't be added or edited because of duplication or reservation
Command fail. Return code -515

[emnoc]

I see thanks for validating. It looks like you can edit  the acct in 5.2.x, which I realize is not  impacted.

e.g

config system admin     edit "Fortimanager_Access"         set accprofile "prof_admin"         set vdom "root"         set password ENC AK1wkED9vYrMpQdDCa3VH7ciPxpid81Y0m8lUB4/qIzc+I=     next end

What OSversion are you running on that VM?

[localhost]

I'm running: FortiGate-VM64 v5.0,build0128,121101 (GA)

I wonder what they've changed. I hope it's not just the salt or the method how they calculate the password.

Otherwise it's just a matter of time untill someone reverses the new method.

If you manually add the Fortimanager_Access user, do you still receive the challenges? And if you don't receive the challenges.. would the box still be manageable by the fortimanager?

[emnoc]

Yes and I can't answer the latter, no fortimanager here. Okay back to sleep for me it's 05:03AM ;)

[tab]

Hi Folks,

Is disabling SSH admin access a viable (temporary) fix as suggested here?

We have 2 FWs that are on a vulnerable version and they will be replaced in 2 weeks. I'd just rather not go through the trouble of notifying customers and an extra downtime window if they're going to be decommissioned shortly.

TIA :)

[localhost]

tab wrote:

Is disabling SSH admin access a viable (temporary) fix as suggested here?

Yes sir. Easiest and fastest workaround.

[emnoc]

And if you must need to open ssh to the public ( untrust ) than use a SSL access with ssl.root enable interface enabled for ssh. This will require ssl vpnclient, access ( local user or remote ) and then the sys admin login. So you have 2 jump thru 2 hoops to gain access.

http://socpuppet.blogspot.com/2015/03/sslvpn-sslroot-management-access.html

Ken

[tab]

Great, thanks localhost and emnoc. I was a worried by the initial info that seemed to suggest that it was independent of having SSH enable. 

[NotMine]

What is fascinating to me, and I must say this even though it is somewhat unprofessional, is how little attention this "issue" is getting here and on the Fuse. On that same note, I do not consider this to be an "issue". It is much worse than that. The fact that a "leading provider of fast and secure cyber security solutions" would let this kind of design/implementation flaw go into production worldwide is almost unbelievable. I hold the entire company responsible for this, and here's why: Product manager(s), for adopting this kind of "solution" to a relatively simple authentication problem. Product developers for implementing this "solution". Internal product security teams for not immediately (or ever, apparently - because if they did, the code wouldn't make it to FAZ 5.2) spotting and banning this obvious high-level security risk. Personally, I would much rather prefer this to have been a maliciously planted backdoor, than a design/implementation flaw. Because, after this, one has every right to ask: "Do these people even know what they are doing, can I trust them to protect my network?". At least in the Juniper case someone intentionally planted the malicious code, which implies they knew what they were doing. Here, it was unintentional. You cannot imagine how embarrassing the conversations with the customers were these days. Or can you?