Backdoor access to Techboard/Syac devices

Authors: Roberto Paleari (@rpaleari), and Luca Giancane

During a security assessment on one of our customers, we had the opportunity to analyze a device by Techboard/Syac, a manufacturer of digital video recorders (DVR) and network cameras. In particular, our analysis focused on a device of the DigiEye product line. The assessment led to the identification of a "backdoor" service, originally introduced by the device manufacturer for testing and support purposes, that could be abused by remote attackers to execute arbitrary commands on the device, with administrative privileges.

Vulnerability overview

Affected devices include a backdoor service listening on TCP port 7339. After a preliminary "authentication" phase, clients can leverage this service to execute arbitrary commands on the underlying Linux system, with root privileges. To the best of our knowledge, end-users are not allowed to disable the backdoor service, nor to control the "authentication" mechanism.

Vulnerable devices are still widely deployed on the Internet, thus we won't release the full details on the backdoor communication protocol. Instead, we just document in a following paragraph the initial "protocol handshake", in order to allow Techboard/Syac customers to identify vulnerable devices on their networks.

As a "proof-of-concept", the following figure shows the Python script we developed to complete the challenge-response authentication with the device and submit the commands to be executed (obviously, source and destination IP addresses have been obscured). As can be seed from the figure, the name of the process associated with port tcp/7339 is "backd", possibly a shorthand for "backdoor" (see the red box).

"Proof-of-concept" of the RCE backdoor on a Syac DigiEye device

A glimpse at the "authentication" protocol

Strictly speaking, the protocol handshake works as follows:
  1. The client connects to port tcp/7339 of the vulnerable device and sends the string "KNOCK-KNOCK-ANYONETHERE?", terminated with a NULL byte.
  2. The server replies with a 12-byte response. First 8 bytes are a timestamp, while last 4 bytes are a "magic number" equal to 0x000aae60.
  3. Follows a challenge-response procedure that uses the timestamp provided by the server at step 2. Details of this step won't be disclosed.
After authentication has been completed, the client can send arbitrary commands which are immediately executed by the device with administrative privileges.

To allow customers to identify vulnerable devices on their network, we provide a Nmap NSE script, available for download here. Usage is very simple, as shown in the following screenshot.

Nmap NSE script to detect vulnerable devices (target IP as been obscured)


We contacted Techboard/Syac about this vulnerability on April 2nd, 2014 and provided them with the technical details of the issue we found. The device vendor promptly replied back to our e-mails and, on April 9th, they confirmed a patched firmware version was going to be released to their customers. At the time of writing, the patched firmware has not been checked by Emaze.


  1. "The server replies with a 12-byte response. First 8 bytes are a timestamp, while last 4 bytes are a "magic number" equal to 0x000aae60." But in syac-backdoor.nse

    "if (not status or result:sub(9, 12) ~= "\x00\x0a\xae\x60") then return"

    Now the question is, is "\x00\x0a\xae\x60" in the response an indicator for a vulnerable device or not?

  2. Ignore my above comment. I missunderstood the '~=' operator.