Old dog, same tricks

Introduction

Old dog, old tricks

When enterprise software gets old, should we consider it tried-and-true, or decrepit and a threat, like the superglue holding the soles of my running shoes together? Old software that’s been humming around in the background hasn’t necessarily broken, but that doesn’t mean that you can necessarily trust it; in fact there should be a healthy skepticism when it comes to the security of old software, as not only do new vulnerabilities get discovered, but the capability of attackers grows as the bar rises higher in the game of cat-and-mouse. This should drive us to periodically review software that maybe we’ve been trusting, and today’s example is some software that has been around for a long time but has a landmine of a vulnerability.

Beagle Software’s ClockWatch product line includes a number of solutions for setting clocks on machines and synchronizing them with high-accuracy time sources such as Global Positioning System (GPS), including an enterprise solution which allows synchronization across a domain or other group of Windows machines. In order to synchronize the time from a single ClockWatch Enterprise host, the Enterprise Service Module (ESM) is installed on each client, but the remote administration capability of the ESM basically provides remote command injection as-a-service, leaving users open to exploitation by any attacker that reach the listening port.

ClockWatch Enterprise architecture

Let’s be clear though, today we’re not talking about a vulnerability that we need modern techniques to discover. An attacker 20 years ago would have all that is needed to discover and exploit this vulnerability. So how did this go undetected for so long? We posit that the volume of software far exceeds the ability to check the security of software, and that even projects with a large number of eyes, can have surprising vulnerabilities, so understanding the software you trust and occasionally auditing it with fresh eyes will help getting caught by surprise.

Bug identification

Beagle Software Enterprise Service Module Remote Command Injection

  • Vulnerability Type: Unauthenticated Remote Code Execution (RCE)

  • Location: fmMainEntSrvc::do_command function in EntSrvc.exe

  • Affected Versions: Enterprise Service Module v1.2.2 (latest, build: Dec 2005)

  • Impact: Arbitrary RCE as SYSTEM (in default configuration) or local user (in standalone mode)

  • CVE Number: TBD

The Beagle Software ESM is intended to run in the background on client machines, listening on TCP port 1001 by default for connections from the ClockWatch Enterprise host. The simple network protocol used by ClockWatch Enterprise invokes a command on the remote host by sending the string C+ followed by the command to execute. No authentication or encryption is used, so commands can be sent by arbitrary remote attackers.

In the do_command function, the ESM passes the command string from the network as an argument to the Visual Basic Shell function (the ESM is compiled from Visual Basic), which interprets the string as a path to an executable and any command line arguments. This is equivalent to the Windows API function WinExec and similar to the C runtime library’s system function, since it starts a new child process with the given arguments.

Technical analysis

The RCE vulnerability exists in the function fmMainEntSrvc::do_command and can be triggered by a remote, unauthenticated attacker sending properly formatted command instructions. By using a network traffic capture tool such as WireShark, we can see the plaintext traffic between the ClockWatch Enterprise host and ESM when a remote command is executed. The text-based protocol allows for several different kinds of interaction (such as time check or forced time set), but attackers will most likely be interested in the remote command functionality. The only barrier to exploitation is learning the port and format of the remote command functionality.

Sample remote command invocation traffic
Sample remote command invocation traffic

Remote commands will be executed in the context of the ESM process, so if the ESM is running as a service, remote commands will execute as SYSTEM and no resulting GUI or windows will be visible to a logged-on user. Alternatively the ESM can be run (automatically or manually) by a local user, in which case the command will execute as the local user and any GUI windows resulting from the command run may be visible to the user. On modern versions of Windows, changing time and date settings require Administrative privileges by default, so given the context of enterprise time synchronization, it is expected that deployments will be running as a service.

Exploit

The provided Python Proof of Concept (PoC) demonstrates the remote command functionality, but specialized scripts are not required. Since there is no encryption or authentication used and the protocol is plaintext, the standard netcat utility could be used to demonstrate this vulnerability. The provided script has been tested and provides a standardized experience.

The PoC itself was tested and verified to work against version 1.2.2 of the ClockWatch ESM. Due to the closed-source nature of ClockWatch, we were unable to locate additional versions on which to test, but it is suspected that all versions that support remote command functionality are vulnerable.

Testing

To test the provided PoC, the easiest setup is to create a 64-bit Windows 10 Virtual Machine (VM) and download the evaluation version of the ClockWatch Enterprise Service Module (available here).

To make commands run visibly in the foreground, we recommend running the EntSrvc.exe executable manually, not installing as a service. During the installation, when the installer asks whether to install as an enterprise service, select “No". If the installer says it cannot find “WinSock.dll" and asks to connect to the Internet to locate it, click “Ok" to proceed. The operation does not need to succeed for the installation to succeed. At the end of installation, leave the “Start Beagle Software Enterprise Service Module when done" box checked. If the Windows firewall requests access, allow for both Public and Private networks.

Once installed, return to your host and run the esm_poc.py script. You will need to enter the IP address of the target along with a command to run. If the ESM program is running in the foreground and not as a service, a command that opens a window such as “calc.exe” or “notepad.exe” should suffice.

  python3 esm_poc.py XXX.XXX.XXX.XXX calc.exe

When you run this command, the script will output [+] Success if it succeeds. Since the ESM’s network response only confirms that a command was run and does not include any output, demonstrations of the exploit working may require a visible effect such as opening a window or writing to a file. The text in the ESM window will also change to indicate the command that was just run, as well as the source and timestamp of the command.

ESM Command Display

Impact

The impact of this vulnerability is that all machines running the ESM could be taken over since any commands executed by an attacker will be run with escalated local privileges (by default). Since the ESM is expected to run on any machine that needs its time synchronized and it requires a listening port in order to function properly, the only prerequisite to exploitation is that an attacker can send network traffic to the desired port. This means the vulnerability could be leveraged for lateral movement or privilege escalation within a corporate network.

This also presents a threat for any machines that may travel outside of the corporate network, as they would be vulnerable to exploitation any time that port is open to the Internet or network-adjacent attackers (such as when a traveler connects to an open Wifi network at an airport, hotel, or cafe). This may be partially mitigated by using Windows firewall settings to block the port on public networks, but this would depend on a correct configuration and users correctly identifying networks as “Public” or “Private”.

Affected software

Since the most recent version of the ClockWatch ESM is over 15 years old, we were unable to test older versions. Due to the lack of recent updates, it is likely that any machine currently running this software is vulnerable.

Vendor response

On May 24th, 2021, GRIMM reached out to CISA to facilitate communications with Beagle Software regarding the reported vulnerability. During these conversations, Beagle Software claimed that support for ClockWatch Enterprise had been discontinued in 2007, even though the product was described as supporting Windows 7, 8, and 10, all of which were released after 2007, and was still available for purchase through the vendor’s website. As a result of this conversation, Beagle Software removed ClockWatch Enterprise from their online store and update its product page to make clearly state that the product had been discontinued. However, since the product was discontinued, Beagle Software opted not to fix the vulnerability. As such, the RCE described above is now an evergreen 0-day vulnerability.

Conclusions

This report detailed an exposed remote command interface in the ClockWatch Enterprise Service Module, the exploitation of which allows unauthenticated, remote attackers to gain RCE on any device running the vulnerable software. Due to the plaintext nature of the protocol and ease of discovery, this vulnerability poses a threat to all computers running the software since any attacker that can reach the exposed port can execute arbitrary commands in the context of SYSTEM.

Recommended mitigations include network-level blocking of traffic related to the port or remote command interface, or uninstalling the software. From a broader perspective, this vulnerability serves as a reminder that any software being deployed across an enterprise should adhere to common security standards such as the use of proper authentication and encryption. In particular, software implementing remote administration features deserves additional scrutiny in the software procurement and deployment processes to avoid unnecessary risks for the organization.

Timeline

  • 05/19/2021 - Notified vendor

  • 05/24/2021 - Notified CISA

  • 06/02/2021 - Beagle Software agrees to update product page to indicate that ClockWatch Enterprise has been discontinued and remove it from their online store

  • 06/02/2021 - Beagle Software confirms that they will not fix the vulnerability

  • 07/07/2021 - NotQuite0DayFriday release

  • 07/07/2021 - Blog post release

GRIMM’s Private Vulnerability Disclosure (PVD) program

GRIMM’s Private Vulnerability Disclosure (PVD) program is a subscription-based vulnerability intelligence feed. This high-impact feed serves as a direct pipeline from GRIMM’s vulnerability researchers to its subscribers, facilitating the delivery of actionable intelligence on 0-day threats as they are discovered by GRIMM. We created the PVD program to allow defenders to get ahead of the curve, rather than always having to react to events outside of their control.

The goal of this program is to provide value to subscribers in the following forms:

  • Advanced notice (at least two weeks) of 0-days prior to public disclosure. This affords subscribers time to get mitigations in place before the information is publicly available.

  • In-depth, technical documentation of each vulnerability.

  • PoC vulnerability exploitation code for:

    • Verifying specific configurations are vulnerable

    • Testing defenses to determine their effectiveness in practice

    • Training

      • Blue teams on writing robust mitigations and detections

      • Red teams on the art of exploitation

  • A list of any indicators of compromise

  • A list of actionable mitigations that can be put in place to reduce the risk associated with each vulnerability.

The research is done entirely by GRIMM, and the software and hardware selected by us is based on extensive threat modeling and our team’s deep background in reverse engineering and vulnerability research. Requests to look into specific software or hardware are welcome, however we can not guarantee the priority of such requests. In addition to publishing our research to subscribers, GRIMM also privately discloses each vulnerability to its corresponding vendor(s) in an effort to help patch the underlying issues.

If interested in getting more information about the PVD program, reach out to us.

Working with GRIMM

Want to join us and perform more analyses like this? We’re hiring. Need help finding or analyzing your bugs? Feel free to contact us.

Popular posts from this blog

New Old Bugs in the Linux Kernel

SOHO Device Exploitation

The walls have ears