written by Pierluigi Stella
“This was not a backdoor vulnerability but rather a management authentication issue” per statement issued by Fortinet representatives.
OK, how does that make it any better? Instead of being a spy for the NSA, you are a company with incapable developers who forget passwords around? But wait, what does “a management authentication issue” even mean? According to what I’m reading, this password was embedded into the code; it wasn’t a password someone forgot to write into a password file under/etc on a Linux filesystem.
Am I reading this right?
The password is embedded into the code itself?
The news I read says “code discovered within a challenge response routine for SSH authentication, a _hidden_ _hardcoded_ password”. This isn’t a management authentication issue. That’d be if someone put in a login password, which ended up in the password file, and forgot to remove it before creating the production image. That’d be nothing; all products come with a default management password; it’s the responsibility of the installer to take care and change it the first time it’s used. This isn’t what we’re reading here. This is a password _embedded_ into the code. I don’t care how much Fortinet’s PR department may try to sugar coat it in their damage control efforts; this is a backdoor. There is no refuting that.
Now, we need to see if we can find out why that password is there. Are we looking at a case of developer leaving a way for him to get back in and exploit clients’ information? Is this something only one person knew? Are we looking at Fortinet’s development servers after they were hacked and a hacker changed their distribution code so as to be able to easily gain access to any Fortigate later on? Or are we looking at Fortinet bowing to pressure from the NSA? I’m confident I can come up with other reasons; but I think these cover the spectrum of possibilities. The common thread between these issues? They’re all malicious, intentional, and NOT a mistake. And they are creepy too. The idea that someone could logon to my firewall, leave no trace of this at all in the logs, and run any snooping activity on my traffic, thoroughly worries me!
There is one possible attenuating factor; if the product is configured properly, the ports required for this to occur should be locked from the outside.
But this is a rather optimistic statement for 2 reasons.
First, hackers plant Trojans on LAN workstations all the time, so the fact that this might be exploitable only from the LAN doesn’t console me in the least. And, this consideration assumes devices are properly configured, which, unfortunately, is a very optimistic assumption. Having been in this business for a long time, I’m well aware of how frequently firewall devices are grossly misconfigured, leaving the network already vulnerable to attacks, even without the help of a backdoor.
Seriously, hackers are already going in and out of our networks, unseen, undetected, and as they please. We certainly don’t need to offer them a mechanism to make their life even easier.