Connect with our team of offensive security, AI security and pen testing experts at Black Hat Europe 2023. Learn More

Connect with our team of offensive security, AI security and pen testing experts at Black Hat Europe 2023. Learn More

Managed Detection & Response

Eradicate cyberthreats with world-class intel and expertise

Managed Security Services

Expand your team’s capabilities and strengthen your security posture

Consulting & Professional Services

Tap into our global team of tenured cybersecurity specialists

Penetration Testing

Subscription- or project-based testing, delivered by global experts

Database Security

Get ahead of database risk, protect data and exceed compliance requirements

Email Security & Management

Catch email threats others miss with layered security & maximum control

Co-Managed SOC (SIEM)

Eliminate alert fatigue, focus your SecOps team, stop threats fast, and reduce cyber risk

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
The Trustwave Approach
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Platform
SpiderLabs Fusion Center
Security Operations Centers
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Undocumented Backdoor Account in DBLTek GoIP

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:

  • Confirmed affected Versions: GoIP 1, 4, 8, 16 and 32

N.B. Most of DBLtek's other devices they manufacture ( 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.

Telnet and the 'backdoor'

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.

The mystery of the UDP packets

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 '' 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 > UDP, length 17

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.

DblTek updates the challenge response scheme

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.

Latest SpiderLabs Blogs

The 2023 Retail Services Sector Threat Landscape: A Trustwave Threat Intelligence Briefing

The annual holiday shopping season is poised for a surge in spending, a fact well-known to retailers, consumers, and cybercriminals alike. The latter group, however, is poised to exploit any...

Read More

Pwning Electroencephalogram (EEG) Medical Devices by Default

Overall Analysis of Vulnerability Identification – Default Credentials Leading to Remote Code Execution During internal network testing, a document was discovered titled the “XL Security Site...

Read More

Hidden Data Exfiltration Using Time, Literally

I was looking at my watch last week and my attention was moved towards the seconds over at the right of the watch face, incrementing nicely along as you’d expect. Now, I don’t know if I’d just spent...

Read More