Trustwave recently reported a remotely exploitable issue in the Telnet administrative interface of numerous DblTek branded devices. 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.
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 fundamental 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.
The issue was first identified in an 8 port DblTek VoIP GSM Gateway, however numerous other devices (listed below) are also believed to be vulnerable.
Affected Models:
N.B. Most of DBLtek's other devices they manufacture (http://www.dbltek.com/goip.html) appear to have the same login binary in their firmware images, but we haven't been able to confirm this. We're currently investigating which other devices contain OEM versions of the same firmwire.
The Telnet service implemented by the DblTek devices presents the following distinctive banner.
Upon presenting the "dbladm" user to the above prompt, the service answers by presenting the user with a challenge, for instance:
The code responsible for presenting the challenge to the remote user can be found in the binary 'sbin/login' stored on the devices local ROM, disassembling this code we have the following:
The code commences by presenting the challenge to the user via the call to 'printf()' at offset 0x9394. The response is read from the user via repeated calls to 'fgetc()' from stdin, in this case, it is assumed that stdin and the socket through which the user is connected have been subject to a call to 'dup2()'.
Upon receiving the response from the user, the code zeros buffers utilized in the computation of an MD5 hash, the input buffer to the MD5 hash is formatted via a call to 'sprintf()' at offset 0x93e0 and thus clearly contains the following:
"XXXXXX\0\0\0\0\0…(padded to 64-bytes)…\0" where "XXXXXX" is the decimal expansion of the value computed by instructions at offset 0x93cc, 0x93d0 and 0x93d4.
As shown in the above screenshot, this computation results in the computation: 'r2 = r6 + 20139 + (r6 >> 3)' where the value of 'r6' is that of the challenge itself, see offset 0x938c. As a corollary, we may conclude that given the challenge value, a remote user can compute the resultant MD5 hash.
The remainder of the verification procedure performs the following:
The above formats the MD5 hash via a call to 'sprintf()' at offset 0x9424 with format string "%x%x%x%x%x%x" the input of which is the first 6-bytes of the MD5 hash. The resulting string is then compared against the value read from the user via the call to 'strcmp()' at offset 0x9430. It is interesting to note that the MD5 format via the call to 'sprintf()' truncates each byte '< 0x10' to a single byte whereas the norm for MD5 expansion as hexadecimal has each byte padded to 2-bytes.
An interesting aspect of the undocumented authentication scheme is the fact that upon attempting to authenticate using the "dbladm" username the Telnet daemon emits several UDP packets directed to the IP address '192.168.2.1' on port 11000/udp.
$ tcpdump -qns 0 -A -r packet.pcap
reading from file packet.pcap, link-type EN10MB (Ethernet)
20:55:59.751632 IP 172.16.9.10.51384 > 192.168.2.1.11000: UDP, length 17
E..-..@.?.....
......*...RhNCHAPRQ:813853712
The daemon then attempts to read a response, a valid response results in the automatic authentication of the user attempting to login. It is highly likely that this authentication scheme is the result of a testing mechanism built into the '/sbin/login' binary to permit DblTek engineers to login to devices without having to authenticate for devices running on the local network.
The issue was reported to the vendor on 10/13/2016, a patched version of the firmware was produced and distributed on 12/22/2016. Verification of the patched version reveals that the challenge response mechanism is still present in the latest version albeit a little more complex. It seems DblTek engineers did not understand that the issue is the presence of a flawed challenge response mechanism and not the difficulty of reverse engineering it.
The main differences between the latest challenge response mechanism and the older variant is the level of complexity it employs: a simplistic MD5 with a linear equation changed to several 'round' functions mixed with a modified version of the MD5 hash algorithm.
