back to article Fortinet tries to explain weird SSH 'backdoor' discovered in firewalls

Enterprise security vendor Fortinet has attempted to explain why its FortiOS firewalls were shipped with hardcoded SSH logins. It appears Fortinet's engineers implemented their own method of authentication for logging-into FortiOS-powered devices, and the mechanism ultimately uses a secret passphrase. This code was reverse- …

  1. David 132 Silver badge

    Time to update contract language?

    Surely any end-customer IT organization of reasonable competence already has language in their vendor contracts to the effect that:

    "- Vendor certifies that the Equipment herein described, is free of hard-coded credentials and other access bypass mechanisms to the best of their knowledge, and has passed an independent security audit"

    Given the drip-drip of such revelations, it would be negligent to NOT make such terms a condition of purchase. Knowing that they would be on the hook for breach of contract and deception should focus the vendor's attention.

    Or am I being hopelessly naïve?

    1. Steve Knox Silver badge
      Meh

      Re: Time to update contract language?

      "- Vendor certifies that the Equipment herein described, is free of hard-coded credentials and other access bypass mechanisms to the best of their knowledge, and has passed an independent security audit"

      "...to the best of their knowledge..."

      The contracts will be signed by sales droids.

      1. Fatman Silver badge

        Re: Time to update contract language?

        The contracts will be signed by sales droids who lack the authority to make such a statement, and in effect, those terms will be considered null and void by the vendor's attorneys when an aggrieved purchaser attempts to seek damages.

        1. eldakka Silver badge

          Re: Time to update contract language?

          As official representatives of the company, any contract they enter into on behalf of the company is legally binding.

          A company is a thing, an entity unto itself, a person under the law. As that person cannot personally sign contracts and so on, the employees of that entity sign contracts on behalf of that entity. In which case, irrespective of the employees actual role within the company, "the company" is now aware of that contract.

          If that was not the case, VW would be able to avoid all liability by saying (and "finding" the evidence supporting) that it was done by a few specific low-level individuals. That may protect the management from CRIMINAL prosecution, but it won't save "the company" from civil, tort/contractual penalties, fines and so on. As it doesn't matter WHO in the company does something, if it's something done by ANYONE in the company then "the company" is "aware" of that. You often see in the charges or pleadings words along the lines of "did know or SHOULD have known that...". As an act taken by any employee of a company, the company itself knows and the management SHOULD know of the act and is thus responsible for it at least at a tort level.

    2. Anonymous Coward
      Anonymous Coward

      Re: Time to update contract language?

      We already have customers who have this listed in their acceptance requirements. Even on managed services, any default username needs to be changed to something unique to the customer.

      Causes some hassles from time to time, but It's a good thing in my book

    3. a_yank_lurker Silver badge

      Re: Time to update contract language?

      It probably depends on whose law the contract is under. AFAIK, this would be a valid stipulation though the language probably should require a vendor issued certification signed by a company officer as part of the contract. The last part is to make sure someone in management is aware of the clause.

      If your account is big enough, the vendor may agree; money has a habit of making people more alert.

      1. Anonymous Coward
        Anonymous Coward

        Re: Time to update contract language?

        " the language probably should require a vendor issued certification signed by a company officer as part of the contract. "

        CE marking in the EU (strictly, in the EEA) already requires such a process; a product's Declaration of Confirmity (where one is required) confirms that the product meets the relevant legislative requirements of the EU. The DoC must be provided by whoever puts the product on the market in the EU (manufacturer or importer) and must be signed by a named official who is authorised and competent to do so.

        https://www.gov.uk/guidance/ce-marking

        The continued existence on the market of huge volumes of clearly non-compliant product, and the absence of prosecutions let alone convictions, indicates that all is not well with the process as currently implemented.

        In the UK, a large part of the issue is that there is effectively no funding for ensuring that the rules are upheld.

    4. Anonymous Coward
      Anonymous Coward

      Re: Time to update contract language?

      However it does rely on you being a large enough organisation and/or the supplier being a small enough organisation (or you're buying enough kit) for them to even entertain a customer contract for the supply of kit (at least in the UK)

      If you've done months of research and testing on kit to find the perfect product at the right price point sometimes it is difficult to have to go and use kit that doesn't really do the job just because you can't get a contract signed.

      It may be different in the US but I'd still be surprised if Microsoft or Oracle agreed to a contract from a customer unless the customer was .gov, .mil or $b

    5. Archaon

      Re: Time to update contract language?

      Naive doesn't even cover it. As a rule the people signing on both ends can barely tell you what a computer does let alone what a 'hard-coded SSH backdoor' is.

  2. Anonymous Coward
    Anonymous Coward

    > malicious activity by any party, internal or external

    Nah. Just sheer incompetence and stupidity.

  3. thames
    Unhappy

    Trust?

    Let's not forget how Cisco are setting up dead drop addresses to try to stop the NSA intercepting their hardware in transit and installing back doors. Can anyone seriously keep a straight face when they say that any American IT product is safe to use?

    I can't think of any realistic solution other than that all security related software and firmware be open source so that hiding back doors isn't so easy, and that customers install it themselves after downloading it from known good sources and verifying the hashes.

    There are people who say that "you have to trust someone". However, ask a security professional what they mean by "trust", and they will tell you that a "trusted party" is simply someone who is able to break your security if they are so inclined. I'm not sure I'm ready to "trust" a foreign government, especially one who has a record of hacking into everything in sight.

    1. a_yank_lurker Silver badge

      Re: Trust?

      Point well taken, but I am not sure whose kit is not hacked by the local spookhaus. So it may be a problem of jumping out of the frying pan into the fire, neither are good options.

    2. tom dial Silver badge

      Re: Trust?

      Stipulating that equipment shipped from the US might be subject to interception and modification, the same certainly is true of similar equipment shipped from non-US addresses. The variable is who does the interception and modification, so the operational decision might be about your choice of third party intervenor. On the other hand, interception and modification by a government agency in the receiving country also would be a possibility, one not under the control of either sender or receiver, and that is not one about which either has a choice.

      There also is a strong case for open source hardware, and for great care about things like cables, as some of Snowden's stolen documents show. It is reasonable to assume that the Chinese and Russian governments, among others, have roughly equivalent capabilities and motivations.

      1. thames

        Re: Trust?

        @tom dial - "Stipulating that equipment shipped from the US might be subject to interception and modification, the same certainly is true of similar equipment shipped from non-US addresses. (...) On the other hand, interception and modification by a government agency in the receiving country also would be a possibility, one not under the control of either sender or receiver, and that is not one about which either has a choice."

        My own government could simply arrest me and grill me in the police station in order to find out whatever they want to know. They''re also unlikely to engage in economic espionage which will hurt their own economy. Foreign countries such as the US on the other hand can't simply send the police around, nor do they have any problems with engaging in economic espionage (e.g. against Airbus as was discovered in an EU investigation as long ago as the 1990s).

        You could say "well, Russia and China could theoretically do the same". Sure, but that's the whole point, US kit is no more trustworthy than Chinese kit. Back doors in Chinese kit may at present be a theoretical possibility, but we know that US kit is being back-doored on a mass scale. If people just continue to stick their heads in the sand over US kit, then they may as well just set their root passwords to "passw0rd" and be done with it.

        The solution is to trust no single outside party. That means making everything as open as possible, which provides fewer corners to hid back doors in.

    3. Anonymous Coward
      Anonymous Coward

      Re: Trust?

      "I can't think of any realistic solution other than that all security related software and firmware be open source so that hiding back doors isn't so easy, and that customers install it themselves after downloading it from known good sources and verifying the hashes."

      But you still need hardware to run it on. If the NSA install a hypervisor in your BIOS or boot ROM, your open source software will happily run in an environment which captures all the traffic but is none the wiser.

      1. Anonymous Coward
        Anonymous Coward

        Re: Trust?

        My (UK) company develops software that works with digital signatures, and it's used as part of a bigger project run by a European government. When the Snowden revelations came out, our integrator had to answer a lot of questions along the lines of "how do we know that software from a UK company can be trusted and hasn't been backdoored by GCHQ".

        It didn't lead to any long-term problems for us, but of course the next revelation may change that. The point is the presumption of government meddling in security software isn't restricted to the US.

      2. Anonymous Coward
        Anonymous Coward

        Re: Trust?

        Don't forget that all x86 processors sold in the last few years have built in hardware back doors.

        http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub

        https://en.wikipedia.org/wiki/Intel_Active_Management_Technology

        They don't call it gathering Intel for nothing...

        1. chivo243 Silver badge

          Re: Trust?

          They don't call it an Intel gathering for nothing...

        2. Blane Bramble

          Re: Trust?

          Neither of those links are to do with x86 processors.

      3. thames

        Re: Trust?

        @AC - "But you still need hardware to run it on. If the NSA install a hypervisor in your BIOS or boot ROM, your open source software will happily run in an environment which captures all the traffic but is none the wiser."

        People are working on this issue, because it's also a problem for ordinary viruses. One solution being proposed is for "stateless" hardware - there is no firmware shipped with the device, nor any persistent storage for it. Instead the user inserts their own flash (or OTP memory) with software later. This would be in the form of a generic card or module which is not specific to that device. Pull out the storage card, reboot, and you are back to a "clean" state.

        Joanna Rutkowska, creator of Qubes OS (a Linux distro) has proposed something like this for a laptop, but it should be applicable to things like firewalls and other network hardware as well. Other people are also looking into the question of how the OS knows whether to trust the hardware.

        If you're worried about something being built into the CPU, then using one with multiple suppliers from different parts of the world, such as ARM, or the up and coming open source CPU RISC-V (backed by a number of major IT companies) will mean that there is no single "choke point" which puts any particular government in a position of privilege for all hardware.

  4. ZSn

    in, out, in, out, shake it all about.

    I know that it doesn't make a *lot* of difference but can you use these credentials from outside the firewall? From the inside it's bad enough but if you can access it from the outside world then this is criminal.

    Another point, why not hardwire a public certificate? If you hardwire it so it accepts a certificate that only you have the private key to, wouldn't that still be secure? Assuming that your customers accept that you can still enter their systems? Hardwiring basic username/password seems the most insecure way possible, or am I missing something?

    1. tom dial Silver badge

      Re: in, out, in, out, shake it all about.

      I would have thought they would (assuming a fairly standard SSH setup) configure SSH with interactive login disabled, and their (Fortinet's) public key in the authorized key database along with a specific permitted FQDN and IP address associated with the user in the hosts file, and documentation describing how the purchaser could create and add their own keys and remove Fortinet's.

      Anything less adequate is an indication of negligence or something worse.

    2. Vic

      Re: in, out, in, out, shake it all about.

      Another point, why not hardwire a public certificate?

      They'd do better to put a public key on a removable SD card, labelled and shipped with the unit. That way, the customer can enable/disable[1] the login according to whether the card is in the machine...

      Vic.

      [1] This isn't, of course, entirely proof against the unit deliberately and maliciously caching that key after the card has been removed - but if your level of trust is so low in that vendor as to believe that to be happening, best to buy from somewhere else, really...

  5. Anonymous Coward
    Anonymous Coward

    Does El Reg still call them

    enterprise security vendor ? To me they're nothing but another enterprise vendor that I myself I would laugh them out of any contract they might show up for.

  6. frank ly Silver badge

    Semantics

    "This was not a 'backdoor' vulnerability issue but rather a management authentication issue. ..."

    It's a backdoor key issue.

    1. Destroy All Monsters Silver badge

      Re: Semantics

      It's also subject to authentic shit management.

    2. maffski

      Re: Semantics

      It's a backdoor key issue.

      The login method is used by FortiManager, a tool for controlling any number of Fortinet devices from a central system.

      More a front door issue. Of course my next question would be '...so how does FortiManager access the devices now?'

  7. fajensen Silver badge

    Why upgrade?

    If one assumes that this is an TLA-requested backdoor then, perhaps, it is counter-productive to update because the new software will have updated backdoors too, that we don't know about and therefore have to find and block.

    Better the devil we know, sortt of thing?

    1. Anonymous Coward
      Anonymous Coward

      Re: Why upgrade?

      Simple - you just need to put a firewall in front of the firewall. Oh, I see the problem.

  8. Anonymous Coward
    Anonymous Coward

    Someone just kicked my "management authentication issue" in, said no one ever...

  9. PassiveSmoking

    Don't be too hard on them, they're only ensuring that their equipment is Snooper's Charter Compliant.

    Also, "management authentication issue"? nice double-speak.

  10. Christoph Silver badge

    When is a backdoor not a backdoor?

    Whan it's a backjar management authentication issue

  11. SolidSquid

    Not sure why backdoor and "management authentication issue" are necessarily mutually exclusive, it seems that the issue in question is them installing a backdoor into the firewalls

  12. spuluka

    Internal Party WORSE than hacked from outside

    One significant part of Fortinet's statement was the assertion that this didn’t come from an external party. Ever since the Juniper backdooring security vendors have been at pains to avoid any suggestion that they are allowing intelligence agencies access to their products.

    I'm not so sure Fortinet should be PROUD of the fact that THEIR OWN ENGINEERS thought this was a GOOD IDEA and put it into the code. In some ways it is better that an outside hacker got in to do the deed.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019