CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

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
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
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 Secret Cipher: Modern Data Loss Prevention Solutions

This is Part 7 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here. Far too many organizations place Data Loss Prevention (DLP) and Data...

Read More

CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway

Overview A command injection vulnerability has been discovered in the GlobalProtect feature within Palo Alto Networks PAN-OS software for specific versions that have distinct feature configurations...

Read More


We all know the cybersecurity industry loves its acronyms, but just because this fact is widely known doesn’t mean everyone knows the story behind the alphabet soup groups of letters, we must deal...

Read More