Time for an upgrade

Introduction

Cleaning your domain clock

Sometimes we grow to like the old software we’ve become familiar with over the years, but because as users we only see the facade of an interface and functionality, we don’t know what risks may exist in something as simple as a clock. The bar is high for enterprise software: we have to expect that our software accomplishes all of its tasks in a manner that doesn’t put us at risk. Today we dive into a venerable piece of software that appears to carry out its underappreciated task, because despite the engineering behind its functionality, it contained a classic software flaw.

Domain Time II from Greyware Automation Products, Inc. is enterprise-grade time synchronization software, including client and server software as well as testing, administration, and auditing capabilities. Everyone has probably had a moment when they realized that the clocks on two different devices were off by a few minutes (or more), but some businesses are particularly sensitive to this issue and need to ensure that their computer systems are as closely synchronized as possible.

While this might seem like a boring problem, it actually requires a fair bit of work to keep computers’ clocks in sync; so much so that it’s a well-known issue in computing with a number of protocols and approaches for solving it to different precisions. In addition to implementing some of the more well known protocols such as NTP, Domain Time II implements its own high-precision protocol that can provide a tiered approach to serving time with clients and a hierarchy of servers.

All of this organization is very convenient, but it does require administering and trusting the software that runs on all the clients and servers you want synchronized. The difficulty with trust and software is that the authors have to get things right all the time, as well as be familiar with the tactics an attacker would use. Otherwise they end up in a situation like we found, where a weakness was obviously visible if one knew where to look... This time it’s an area that is overlooked by many, but rarely ignored by attackers: the update process. Most people know that updates are important for security, but typically only attackers and experts bother to look at the security of an update process itself and understand what a motivated attacker could do.

If you’ve never heard of a Man-on-the-Side (MotS) attack, it’s really just a variant of the classic Man-in-the-Middle (MitM) attack, where the attacker can inspect and control the communication flowing between two parties. In a MotS, the attacker can inspect but not control the data, though they may be able to respond to traffic they see. This attack is more easily achieved than a full MitM (think of any time you get on unencrypted WiFi, for example), but is also usually easily foiled by the use of encryption by the participants. Concerns over these kinds of attacks have led to the widespread adoption of Secure Hypertext Transfer Protocol (HTTPS) and Transport Layer Security (TLS). Without such encryption, any communication that can be eavesdropped at any point along the path of network communication could potentially be vulnerable, especially connectionless User Datagram Protocol (UDP) traffic like that used in the upgrade process for Domain Time II.

Bug identification

Domain Time II upgrade attack

• Vulnerability Type: Unauthenticated Upgrade Process

• Location: dttray.exe

• Affected Versions: Domain Time II versions 5.2.x (current releases), 5.1.x (starting from 2010), and 4.1.x (starting from 2007) from 5.2.b.20210103 to at least 4.1.b.20070308

• Impact: Potential Download and Execution of Malicious Payloads

• CVE Number: TBD

The Domain Time II Client and Server programs both use the same executable, dttray.exe, to check for updates. Neither program automatically checks for updates by default, but both can be set to check for updates on startup or can be instructed to check for an update manually. Additionally, the Domain Time II Update Server component, if installed, does automatically check for updates whenever the Domain Time II Manager is opened.

Figure 1: Disassembly of client processing upgrade response

In all update cases, dttray.exe will send a UDP query to the update server to see if an update is available. If the server responds with a Uniform Resource Locator (URL) (i.e. it begins with “http://” or “https://”), the software will open a dialog box notifying a user that an update is available. If the user accepts the dialog, the software calls ShellExecuteA with the "open" argument on the URL returned by the server. This causes a browser window to open and navigate to the provided URL of the update webpage, which instructs the user to download and apply an update patch executable. The disassembly for this process can be seen in Figure 1, and the web page displayed to registered users can be seen in Figure 2. The web page for evaluation software users is similar except it doesn’t ask for email and password information.

If an attacker is able to intercept the initial UDP query and send back their own URL, then the user in the above scenario would be prompted to download and execute an attacker-controlled payload. Any executable downloaded and run in this way would execute with user privileges, though it could request elevation of privileges the same way the legitimate installer does.

Figure 2: Greyware’s update webpage

Technical analysis

Observing the weakness in the update protocol is straightforward. By viewing the traffic generated during the update check in a tool like Wireshark, we can see two UDP packets originating from the user software: one Domain Name System (DNS) query, and one packet sent to the IP resolved from the DNS query to UDP port 9909.

Figure 3: Client upgrade request packet contents

The upgrade request packet contains the client’s version string in ASCII in plaintext as shown in Figure 3.

Figure 4: Update server response to up-to-date clients

Figure 4 shows a normal response from the update server contains only the plaintext phrase “CURRENT”, demonstrating there was no encryption or authentication used.

Exploit

In order to demonstrate the weakness in this process, the provided script, upgrade_attack.py, listens on the provided network interface for upgrade traffic and responds to the appropriate DNS and Domain Time II requests. Additionally, the Proof of Concept (PoC) has an Hypertext Transfer Protocol (HTTP) impersonation mode (see --help). In this mode, the PoC will respond to HTTP requests as well, and direct users to a look-alike web server with the correct URL but over HTTP instead of HTTPS. When run outside of the HTTP impersonation mode, the PoC will send users directly to the IP of the web server. The script’s functionality can be summarized in how it deals with each of these three protocols:

1. Listens for and responds to DNS requests for update.greyware.com

2. Listens for and responds to unencrypted Domain Time II version check packets, providing a URL that the target will open via HTTP

3. Serves a lookalike update webpage over HTTP as well as a demonstration executable for users to download and run

The result is an attack that mirrors the appearance of the legitimate update mechanism in order to increase its believability (see Figure 5).

Figure 5: Greyware’s official update website (left) and the demonstration attack website (right)

The PoC itself was tested and verified to work against versions 4.1.b.20070308, 5.1.b.20100731, and 5.2.b.20210103 of Domain Time II.

Testing

To test the provided PoC, the easiest setup is to create a 64-bit Windows 10 Virtual Machine (VM) and install the evaluation version of Domain Time II (available here: https://www.greyware.com/software/domaintime/). Since both the client and server are vulnerable, you can choose to install either one. To simplify the setup, set the network adapter of the VM to NAT.

Once installed, return to your host and run the upgrade_attack.py script. You will need to provide the IP of your host (as visible to the client VM) and the name of the interface shared between the host and the guest VM. In our demonstration using VMWare, this is “vmnet8”.

  python3 upgrade_attack.py vmnet8 XXX.XXX.XXX.XXX

Depending on your host configuration, you may need to run this script with root privileges. Once the script starts sniffing the specified interface for the target DNS request, trigger the update process from within the guest VM. In the Windows system tray (bottom right of the screen), right click the dttray.exe icon, select “Setup” then “Check for newer version now...” This will trigger the update process and start the MotS race. If the attack server wins the race, the following messages will appear in the console output of upgrade_attack.py:

  DNS Query for "update.greyware.com." from <Guest VM IP>
  [+] Target DNS Query responded to with <Host IP>
  DNS Response for "update.greyware.com." from <Attack Server>
  DT2 from <Guest VM IP>:60605 to <Host IP>:9909
  [+] Responded to target DT2 Update request: <Payload>
  DT2 from <Host IP>:9909 to <Guest VM IP>:60605

These messages indicate that the attack server sniffed the DNS request for the legitimate upgrade server, responded with its own IP, then responded to the upgrade request with its own payload. In this case, the payload is a fake website that mimics a legitimate Greyware Automation Products page. At the bottom of the page is a link to “Get the patch!” Clicking this link prompts the user to download a payload (calc.exe) and execute it as the current user.

We’ve chosen opening the calculator application as an easily-observed payload action, but the attack server is set up to transparently serve the attacker’s chosen executable while showing the user the executable name they requested (typically dtpatch.exe). The included demonstration payload illustrates what warnings the user would experience in an attack that isn’t trying to evade antivirus, but for testing purposes the payload could be replaced with Microsoft’s signed calc.exe or a penetration testing tool. Such testing will show the impact in payload choice on what the victim would see.

 Victim's Perspective when running the PoC

Since the MotS vulnerability exploited by this PoC is a race (between the attack server and the legitimate DNS server), the PoC is not guaranteed to succeed every time. Additionally, the use of the HTTP impersonation mode introduces a second race that must be won for the PoC to be successful. If an attacker can achieve a MitM scenario on the traffic, they can ensure they always win the race by blocking either traffic to/from the Internet side. For testing purposes, we recommend simulating that scenario by disabling your host’s access to the internet and not running in HTTP impersonation mode.

Impact

The expected deployment scenario for this software is that the Domain Time II Server is installed on the Domain Controller within an Active Directory forest, and that the Update Server component would be run from such a machine (see “admin.txt” in the Domain Time II install bundle).

As such, the impact of successfully executing a MotS attack against a server would be to execute malware with administrative privileges in the context of the server. Since the Domain Time II server can track and update versions of the client software across the network, compromising the server could lead to attackers being able to spread laterally across a network to workstations, database servers, or source code repositories. All this could be performed under the guise of legitimate administration tasks of recognized software, similar to how some recent intrusions hid their activity on a network under the guise of Solar Winds software activity.

It is also possible that any user running the client software could infect themselves with malware, regardless of whether they are in a standalone client or domain setting, though in a domain setting the malware may be limited to domain user permissions.

Affected software

Since Domain Time II is closed-source software, it is difficult to generate an exact list of impacted versions. GRIMM was able to obtain evaluation copies of the following three versions of Domain Time II: 5.2.b.20210103, 5.1.b.20100731 (released in 2010), and 4.1.b.20070308 (released in 2007). Through static analysis of the software installed by these installers, GRIMM was able to confirm that the vulnerability exists in all three versions of Domain Time II. As such, it is reasonable to believe that the vulnerability affects all versions of Domain Time II released after 4.1.b20070308. It is possible that the vulnerability exists prior to this version, but GRIMM was unable to source earlier versions of the software. A fix for this vulnerability was released in version 5.2.b.20210331.


Conclusions

This blog post details a MotS attack that allows attackers to potentially gain code execution on machines running versions of Domain Time II that date back at least ten years. The crux of this vulnerability lies in the lack of authentication between Domain Time II servers and clients, and external Greyware update servers. If an attacker is able to detect outgoing update requests and respond to them before the legitimate Greyware servers do, then said attacker can direct users to download executable code from attacker-controlled servers. A combination of privilege reduction (e.g. only allowing Domain Time II servers to call out for external updates) and better user training (e.g. create documentation on secure update procedures) poses significant mitigation to this, and similar, vulnerabilities.

Timeline

• 03/30/2021 - Notified vendor

• 03/31/2021 - New version of software released with patch (5.2.b.20210331)
  

• 04/06/2021 - NotQuite0DayFriday release

• 04/06/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.