Exactly 30 days after the announcement that Juniper Networks had jeopardized customer security by shipping products with a hard-coded SSH password, security appliance manufacturer Fortinet has announced that many of their products contain a similar hard-coded backdoor password.
The vulnerability came to light last week when attack code exploiting the backdoor was posted online, according to Ars Technica. Fortinet said the vulnerability was “an undocumented method for logging into servers using the secure shell (SSH) protocol,” and that it was a “remote management feature.”
Unlike the recent Juniper Networks case, where a hard-coded backdoor was allegedly embedded in the product by the NSA, the Fortinet case is not a case of a malicious backdoor implemented to grant unauthorized user access. Instead, it was “designed with the intent of providing seamless access from an authorized FortiManager to registered FortiGate devices,” said the company. The scheme would allow support technicians to use a single password across all customer devices.
While Fortinet officials say the backdoor in its products had no malicious intentions, there’s little doubt it could be used for covert eavesdropping by people with knowledge of its presence, Ars Technica reports, including former Fortinet employees and anyone to whom they gave the password.
Though extraordinarily reckless, the practice of incorporating SSH backdoors is not uncommon. The challenge of keeping up with the individual login credentials of thousands or tens of thousands of devices can be quite daunting for the manufacturer’s support organization. In that context, a hard-coded backdoor password that grants complete access to any device can seem like a reasonable solution, despite the risks.
iTivity makes accessing remote devices on customer sites seamless. iTivity authenticates support technicians using standard authentication systems like Active Directory, PAM, and LDAP. There is no need for support technicians to manage passwords or keys for individual remote systems because iTivity does it for them. Once the support tech logs into iTivity, they simply click to access the desired remote device and iTivity handles all privileged access management duties in the background. iTivity is an OEM component of hundreds of Linux device manufacturers and ISVs for just this reason.