Let’s keep this in mind as we begin analyzing the binary. I will be utilizing Ghidra to perform static analysis.

Utilizing the String Search feature, we quickly identify our vulnerable function, identified as FUN_00009010 in Figure 1.

Figure 1: String Search results for sync.

Investigating FUN_00009010, shown below, at line 30 the user-supplied NTP serverName string is passed to the variable iVar2. At line 38, iVar2 is added to a string using the snprintf function. Ultimately, this unsanitized string is passed as a parameter for lsystem, executing a system command like ntpd -nqp [serverNameParam. We’ve successfully identified our command injection vulnerability! This vulnerable input sink enables us to execute additional arbitrary commands by appending first a semi-colon (;) followed by the command to execute.

Figure 2: time.cgi – Unsanitized input sink.

When passing an arbitrary command, such as ;id, one will observe that the output from this command is not returned to the user, making this a “blind” command injection vulnerability. Reviewing the end of the vulnerable function, we observe that the function crafts a JSON object which ultimately will not include standard output or standard error from the executed command.

Figure 3: NTP server update – Response message.

However, it is still possible to verify the presence of command execution by utilizing a local binary to establish a connection to a listening service you control. An example could be using ping by crafting a JSON message like:

CVE-2024-30169

Zeus Z3 SME-01 HDMI H.264 video encoder & decoder – Unauthenticated command injection

CVE-2024-30169 details an unauthenticated command injection vulnerability in the /cgi-bin/debug.cgi route for the web-based management interface for the Zeus Z3 SME-01 HDMI H.264 video encoder & decoder.

Figure 4: Zeus Z3 SME-01 web management interface.

Official fix

Zeus specifically addressed CVE-2024-30168 and CVE-2024-30169 in firmware release 2024-05-03 v3.00a SME-01 SW-4R3-01053-02. Product owners may acquire the latest firmware release by first registering their product and creating an account at https://z3technology.com.

Vulnerability details

By performing a specially crafted GET request, a malicious actor can read any file on the device’s file system or execute commands on the underlying operating system as the root user. The vulnerable input sink is the logfile parameter.

The vulnerable /cgi-bin/debug.cgi path is accessible regardless of whether an administrative password has been applied to the device.

Figure 5: Vulnerable cgi-bin/debug.cgi route.

For a standard GET request, the debug.cgi script expects a parameter like: logfile=mcsenc.log.d

It is possible to arbitrarily read any file on the file system by specifying a literal path for the file:

Alternatively, it is possible to execute commands on the underlying host operating system and receive its output by escaping the command string generated by the debug.cgi script using specific special characters. An example special character commonly used in command injection tests (leveraged in this case) is a semi-colon (;).

Example: GET /cgi-bin/debug.cgi?divload=yes&logfile=id;

Figure 6: Example arbitrary file read & command injection exploitation.

Figure 6 provides an example request that exploits both vulnerabilities. Output from the injected command is returned as part of the response. After performing some target reconnaissance on the device, I also discovered that it is possible to acquire shell access via telnetd: telnetd -l /bin/sh -p 2222 &:

GET /cgi-bin/debug.cgi?divload=yes&logfile=%2Ftmp%2Fmcsenc.log.d;telnetd%20-l%20/bin/sh%20-p%202222%26

Working backwards: Vulnerability research following exploitation

While researching SME-01 I discovered that firmware for Zeus products is not publicly available without first creating an account and registering a purchased product. This required me to exfiltrate the filesystem off the remote target to adequately reverse engineer and fully understand the root cause of the actual vulnerability.

Fortunately, with tar being available on the device, it was possible to archive the filesystem using a command like the following: tar -cvpzf backup.tar.gz –exclude=/backup.tar.gz /

Moving the archived filesystem to the path hosted by the device’s web server (/opt/webgui/cgi-bin/) it is possible to then download the archive from the device via a web request at /cgi-bin/backup.tar.gz).

debug.cgi analysis:

The SME-01 utilizes the open-source web server lighthttpd to host the web management interface. Investigating running processes on the device, lighthttpd is executed with the following flags: /opt/webgui/lighttpd/sbin/lighttpd -D -f /opt/webgui/.

Reviewing configuration details for lighthttpd, cgi is enabled and .cgi extensions are being handled by /bin/sh:

Figure 7: lighthttpd cgi.conf settings.

Web servers that support CGI (The Common Gateway Interface) provide an interface for external programs to handle specific web requests. In this instance, a request to the vulnerable path /cgi-bin/debug.cgi is handled by the shell script /opt/webgui/cgi-bin/debug.cgi.

Being a simple shell script, analysis is straightforward. Figure 8 highlights that unsanitized user input (contained in the logfile parameter) is passed directly to a system command which attempts to print a file using the cat command.

Figure 8: Unsanitized input sink in debug.cgi.

How adversaries benefit from IoT exploitation

The official overview of the Zeus Z3 SME-01 describes the device as Zeus’s most compact encode/decode solution, making it ideal for remote applications such as video conferencing, on-site research or emergency broadcasts. Atlona describes the AT-OME-MS42 as a matrix switcher ideal for video conferencing and many other 4K presentation applications.

At first glance, these devices seem to be of little use to an adversary or a red team during an engagement. They likely host services insignificant to an organization or store non-sensitive information; however, I have identified multiple benefits of exploiting embedded systems while targeting these types of devices. This is not a comprehensive list; however, the following points come to mind.

Expanded access

To provide additional context, I discovered both vulnerabilities immediately following the Initial Access phase of an engagement. After acquiring internal access and establishing reliable persistence on a compromised target, my priority shifted to establishing additional accesses separate from the initial compromise. In permissive environments, I began conducting network reconnaissance and explicitly marking services for embedded devices for additional review.

In the case of both exploited devices, where there is one discovered device, there are often many more deployed across the internal network. In the case of the Zeus Z3 SME-01 exploitation campaign, I identified over 100 SME-01 devices present in the internal network, sprinkled across multiple unique subnets. The same held true for the Atlona AT-OME-MS42 campaign, but a smaller quantity of devices was discovered.

It becomes apparent that the large proliferation of vulnerable devices on an internal network can enable an adversary to acquire an extremely robust foothold.

Compromise enables second-order effects

Often, services on embedded devices are running with overly permissive privileges and typically execute in the context of the root user. This means the exploitation of a vulnerable service results in the total compromise of the device itself. If the service is running as an unprivileged user, well-documented privilege escalation vulnerabilities are often present on embedded devices.

Operating as a root user on an embedded Linux device provides the access necessary to perform additional post-exploitation against an internal network. An example of post-exploitation opportunities could include Layer-2 attacks such as Adversary-in-the-Middle Credential Attacks: MITRE T1557.

Evade endpoint detection & response

One of the most compelling reasons for exploiting IoT devices is the ability to avoid hosts with deployed endpoint detection and response (EDR) solutions. Simply, targeting IoT can be a unique mechanism for expanding access internally while exploiting potential gaps in visibility for a security operations center (SOC). Often, IoT devices provide no administrative access to the underlying operating system, making host-level monitoring impossible. This naturally provides a mechanism to assess an organization’s effectiveness at properly identifying, mitigating and recovering from threats when endpoint data isn’t available.

Threat faithful

Finally, Threat Intelligence Reports, like those shared from X-Force Threat Intelligence, highlight the frequency of malicious actors exploiting IoT devices during campaigns. There are a multitude of infamous data breaches in which IoT exploitation played a pivotal role in an attack chain. This emphasizes the importance of red teams to emulate the same type of exploitation for organizations.

Conclusion

This article hopes to convey how IoT exploitation may look in an environment, illustrate its second-order effects in a campaign and provide context surrounding its value to a malicious actor. While I am certainly not the first to reach the conclusions made in this article, I hope to contribute to the already expansive repository of IoT vulnerability research and detailed approaches to adversary emulation. IoT is a proven target of opportunity for malicious actors and IoT exploitation can serve as a tremendous contribution toward a successful red team engagement.