The built-in backdoor discovered by Trustwave in IoT devices enables access by the manufacturer and leaves the devices open to exploitation by others, which despite Trustwave following the responsible disclosure process, has repeatedly been left exposed by the vendor.
When researchers disclosed the discovery, DBLTek responded by trying to make the backdoor more hidden rather than closing it, before cutting off contact with Trustwave. Since then the security researchers been able to write exploits that open both the old and new backdoors.
The discovery has just been publicly disclosed in a Trustwave blog here, written by Dr Neil Kettle and John Anderson, the principle consultants with SpiderLabs at Trustwave who made the discovery.
>See also: Have you left the backdoor open?
Zach Lanier, research director at Cylance, in response to this revelation from Trustwave has said that “Unfortunately, this is not an isolated issue. Network devices from manufacturers all over the world have fallen prey to attackers time and time again – often by way of backdoor services and accounts. These backdoors are often present under the guise of providing ‘remote administration’ or ‘support’, but occasionally for more nefarious purposes.”
“What’s frustrating about this particular instance is the vendor’s response to Trustwave’s findings: ‘security through obscurity’ is not the way to go, nor is cutting off communications with researchers who are trying to disclose something’. Trying to ‘hide’ something like this is what brings about the “Streisand Effect” – it will only draw more attention.”
“Chances are high that we’ll continue to see more of the same as far as backdoors go, especially as IoT-esque devices proliferate.”
In the blog, Kettle and Anderson writes that the ‘issue permits a remote attacker to gain a shell with root privileges on the affected device due to a vendor backdoor in the authentication procedure. The Telnet interface of the GoIP is documented as providing information for users of the device through the use of logins “ctlcmd” and “limitsh”. Both of these logins provide limited information about the device, and are accessed using the user-configured administrator password.’
‘However, an additional undocumented user, namely “dbladm” is present which provides root level shell access on the device. Instead of a traditional password, this account is protected by a proprietary challenge-response authentication scheme.’
>See also: An insecure platform: WhatsApp can read user’s ‘secure’ messages
‘The simplest form of challenge-response protocol is that of a password authentication scheme, in this case, the challenge is asking for the password and the only valid response is the correct password.’
‘However, more advanced challenge-response schemes attempt to obscure the secret (password in the above) in order to guard against network interception and replay attacks. The DblTek device in question implements a proprietary challenge-response scheme. Investigation has shown this scheme to be fundamentally flawed in that it is not necessary for a remote user to possess knowledge of any secret besides the challenge itself and knowledge of the protocol/computation.’
They also provided a list of the affected, potentially vulnerable models. Confirmed affected versions include, GoIP 1, 4, 8, 16 and 32.
