Jared Stroud
Cloud Security Researcher – Lacework Labs

Key Points

• XMRigCC vulnerabilities enable rogue clients/compromised hosts/victims to attack upstream servers.
• Vulnerabilities include:
  • Arbitrary file writing w/ specific extension of “_config.json“.
  • Default configuration overwrite via client “worker-id” leading to potential client takeover.
  • Persistent XSS via client “worker-id”.
  • Remote Denial of Service via client “worker-id”.

Summary

Lacework Labs identified an XMRigCC binary being used in conjunction with an opportunistic Cryptojacking (T1496) campaign. Lacework Labs examined the XMRigCC utility for vulnerabilities to identify additional risks to victims. Upon brief analysis, several unique opportunities exist to execute code on the XMRigCC server from a client that has either been compromised (ex: rogue client) or from a victim host. 

Lacework Labs disclosed these vulnerabilities, proof-of-concept code and recommended mitigations to the developer of XMRigCC prior to making this blog post. At the time of this blog post being published, the vulnerabilities have been fixed and new releases are available on XMRigCC’s Github. Thank you BenDr0id for the fast patches!

The Right Tool For The Job

Opportunistic adversaries seek to compromise hosts to deploy Cryptojacking malware in order to monetize illicit access. The vast majority of Cryptocurrency miners identified during Crytpojacking attacks (T1496) by Lacework Labs are XMRig. XMRig is the defacto-standard miner in Cryptocurrency mining and offers several configuration options for mining configurations. Notably, the XMRig client has a built-in restful API that if enabled allows for remote configuration of the clients. XMRigCC is a fork of XMRig that offers a UI for those managing numerous Cryptominers, along with the ability to start, stop, restart and execute commands on the remote miners. 

XMRigCC Topology

The XMRigCC offers a client-server model to enable remote management of deployed Cryptocurrency miners. The XMRigCC client connects to the XMRigCC server based on either command line arguments or a pre-configured configuration file (config.json). This configuration file contains vital information for mining operations as well as the details to connect to the XMRigCC server. Some key information stored in this configuration file includes:

• • Wallet address
  • Username (for the mining pool)
  • Password (for the mining pool)
  • Mining pool
  • XMRigCC server access token (this allows the client to authenticate to the server)
  • reboot-cmd (this is a command to execute when rebooting the client from the server UI)

Figure -1  below shows a snippet of a basic client-server topology with XMRigCC.

Figure 1 – Basic XMRigCC Topology

XMRigCC Initial Connection

A notable feature of the XMRigCC client is that the client configuration file can be set to always upload to the XMRigCC server when starting the XMRigCC client. When the XMRigCC server receives the configuration file, the configuration file is named to whatever the worker-id setting is specified within the client configuration file.  Figure – 2 shows the cc-client configuration section within the XMRigCC configuration file.

Figure 2 – XMRigCC Client Configuration Snippet

If no worker-id is specified, the hostname of the machine is used. Upon the XMRigCC server receiving the client’s configuration file, it is written to disk within the current working directory that the XMRigCC server is running. The XMRigCC server configuration file can specify a separate location to store client configuration files, but this is not enabled by default. Finally, an extension of “_config.json” is appended to the client’s file. For example, if the worker-id is “example-worker”, the configuration file would be stored on the XMRigCC server as “example-worker_config.json”.

XMRigCC Server Web Interface

After the XMRigCC clients have connected to the XMRigCC server it’s possible to manage clients entirely through the web interface. The web server is built into the XMRigCC server. All state is entirely stored in memory. There is no persistent storage beyond client configuration files being uploaded and written to disk.

 Figure-3 below shows the web UI interface with one client connected. 

Figure 3 – XMRigCC UI

Attacking XMRigCC Servers via Client Configuration Files

The original XMRig miner only allows for remotely updating configurations if the clients have the API enabled. Enabling the client-side API results in a listening TCP port further expanding the footprint of a Crytpojacking compromise. Additionally, an adversary would have to connect to the client to update the configuration, requiring ingress firewall rules to permit inbound access on a particular port. Due to these environmental considerations, Lacework Labs rarely sees Cryptocurrency miners deployed configurations with the API enabled,

The XMRigCC fork of XMRig solves this problem via the client-server architecture mode. The client connects to the server periodically to “check-in” and receive any tasks that the XMRigCC server operator may have set up. However, this variant of XMRig also introduces inherent vulnerabilities into an adversary’s operational environment due to the lack of data sanitization.

Lacework Labs identified multiple vulnerabilities within XMRigCC Server that stem from the client configuration file. Given that a victim host/rogue client would have a copy of the configuration file, the victim/rogue client would have the appropriate access token to connect to the upstream XMRigCC server and perform the attacks discussed below.

Overwriting Default XMRigCC Configuration – Client Hijacking

The XMRigCC server has a default configuration file (default_miner_config.json) which can be delivered to clients that do not have a configuration file present on the host. According to a XMRigCC Github issue, this allows the XMRigCC server operator to maintain one “golden” config that is shipped to all clients. From a legitimate deployment standpoint, this configuration model makes a lot of sense in the DevOps age. However, a compromised client can overwrite the default configuration on the server resulting in deploying this compromised default configuration file to future clients.

Due to the previously discussed functionality of XMRigCC server saving client configuration files upon initial connection, it’s possible to overwrite the default configuration file if the worker-id is set to “default_miner”. By overwriting the default configuration, it’s possible to set these values to whatever an adversary would desire. Figure – 4.a and 4.b below shows the workflow where this configuration file overwrites new victims.

Figure 4.a – XMRIg Victim Hijacking via Default Configuration Overwrite

Figure 4.b – XMRIg Victim Hijacking via Default Configuration Overwrite

The XMRigCC client configuration also contains a section for commands to be executed in the event of a reboot (reboot-cmd). This could lead to code execution on numerous hosts in the event that the following actions occur:

1. A default configuration file was overwritten on the XMRigCC server via a rogue client.
2. New clients connect to the XMRigCC Server.
3. The XMRigCC server operator pushes the default configuration.
4. The XMRigCC clients receive the poisoned default configuration.
5. New XMRigCC clients are rebooted via the XMRigCC server UI, executing the “reboot-cmd” from the XMRigCC client configuration.

Arbitrary File Writing via Worker ID

The XMRigCC server leverages the worker-id file name to create a file while appending the extension of “_config.json” when initially receiving configuration files from XMRig clients. Having a worker id of a file path will enable arbitrary writes within the XMRigCC server, but with the extension of _config.json. For example, if a client connected with the worker-id of “/tmp/testing”, a configuration file of /tmp/testing_config.json would be created. Alone, this is more of a bug than a vulnerability. However, in conjunction with a known configuration location this could be used to overwrite other miner’s configuration files.

Persistent XSS via Worker ID

The web UI shows the worker ID in the table. If no worker ID is provided, the hostname of the machine is used. There is no data sanitization applied to the incoming text. This enables persistent XSS until the XMRig server is either restarted or leverages the “Reset ClientStatusList” button.  A simple alert(1) example is shown in figure 5 below.

Figure 5 – XMRigCC Server XSS – 1

Lacework Labs modified the XSS payload to fetch a remote resource revealing the IP of the connecting client to demonstrate the potential of revealing a XMRigCC server operator’s IP address in the event a proxy or VPN was not being used.

Figure 6 – XSS Payload Requesting Remote Resource

Further research into the web UI and XSS payload may reveal more damaging effects that can be executed client-side.

Denial of Service via Worker ID

A parsing issue exists within XMRigCC Server code for worker-id that results in a segment fault if a worker-id is too long. At this time Lacework Labs has created a simple unauthenticated remote Denial of Service payload via a worker-id with a long name. Server side, this results in a segmentation fault. 

Figure 7 – XMRigCC Server Denial of Service 

Conclusion

As adversaries seek to monetize victim infrastructure, it’s important to understand vulnerabilities within their tools that create additional risk within a victim’s environment. While these vulnerabilities can be beneficial to those with proper authorities to take action, it also presents additional scenarios of adversaries attempting to take over other adversaries. Scenarios like this create difficulties for threat intelligence professionals performing research on specific actors. The research presented in this blog post should not be considered complete as further vulnerabilities may exist within the codebase.

For more content like this, follow us on social media @LaceworkLabs Twitter or LinkedIn to keep up with our latest research.

Categories

• Research