Crooks target Kubernetes installs via Argo Workflows to deploy miners

Threat actors target Kubernetes installs via Argo Workflows to cryptocurrency miners, security researchers from Intezer warn.

Researchers from Intezer uncovered new attacks on Kubernetes (K8s) installs via misconfigured Argo Workflows aimed at deploying cryptocurrency miners.

Argo Workflows is an open-source, container-native workflow engine designed to run on K8s clusters. The experts discovered Argo Workflows instances with misconfigured permissions allow threat actors to run unauthorized code on the target’s environment.

The unprotected instances are operated by organizations in multiple sectors, including technology, finance, and logistics sectors.

“Exposed instances can contain sensitive information such as code, credentials and private container image names. We also discovered that in many instances, permissions are configured which allow any visiting user to deploy workflows.” states the analysis published by Intezer. “We also detected that some misconfigured nodes are being targeted by threat actors. An example of an attack found in the wild, launching a popular cryptocurrency miner container”

A Workflow is the core resource in Argo and is defined using a YAML file containing a “spec” for the type of work to be performed. Each step in an Argo workflow is a container. 

The workflows are executed from a template or submitted directly using the Argo user interface.

For some of the instances found by the researchers the permissions are misconfigured allowing an attacker to access an open Argo dashboard and submit their own workflow.

At least in one case, the researchers noticed that attackers deployed a popular cryptocurrency mining container, kannix/monero-miner, a circumstance that suggests an ongoing hacking campaign in the wild.

Users could check if instance has been misconfigured by accessing the Argo Workflows dashboard from an unauthenticated incognito browser outside their corporate environment. An alternative is to query the API of the instance and check the status code. 

“Make a HTTP GET request to [your.instance:port]/api/v1/info. A returned HTTP status code of “401 Unauthorized” while being an unauthenticated user will indicate a correctly configured instance, whereas a successful status code of “200 Success” could indicate that an unauthorized user is able to access the instance,” continue the experts. “It is critical to ensure that best practices for permissions are followed in order to prevent unauthorized activity in your environments. Methodologies such as the principle of least privilege (PoLP) should be followed and always refer to the application documentation for best practices on security.”

Follow me on Twitter: @securityaffairs and Facebook

[adrotate banner=”9″]

[adrotate banner=”12″]

Pierluigi Paganini

(SecurityAffairs – hacking, SolarWinds)

[adrotate banner=”5″]

[adrotate banner=”13″]