The growing risk of third-party applications: Keeping secure in the cloud.
Running third-party applications in a cloud environment has become a growing security risk for organizations, putting workloads at greater risk, especially when the third-party software exposes some API function to the public web. The lack of management, control, and visibility into these third-party applications and the software supply chain, in general, is why attackers are increasingly targeting them to gather information and infiltrate organizations.
Today’s cyber attackers are constantly evolving their techniques, making modern cloud-native workloads a very tempting target. Alongside exploiting web APIs to unleash cryptomining campaigns, they’re also abusing free tier offerings of popular cloud CI/CD platforms to easily convert compute power into digital coins.
In fact, Aqua’s research team recently uncovered tens of thousands of user tokens that are being exposed via the Travis CI API, which allows anyone to access historical clear-text logs. More than 770 million logs of free tier users are available, from which you can easily extract tokens, secrets, and other credentials associated with popular cloud service providers. Attackers can use this sensitive data to launch massive cyberattacks and to move laterally in the cloud.
In that instance, the findings were reported to Travis CI and the relevant service providers, with some initiating a wide key rotation. However, to understand how vulnerabilities in third-party scripts enable cybercriminals to gain access and carry out an attack, we must look at the methods that bad actors employ to conceal their activities and avoid detection.
For this, let’s break down another interesting attack captured by Aqua’s research team, this time on an Apache Struts 2 container.
Step 1: Initial access and defence evasion
Apache Struts 2 is a popular open source cross-platform web application framework used by many developers in their day-to-day work. The team analyzed how attackers went about exploiting an Apache Struts 2 vulnerability that allows remote code execution (RCE) under the privileges of the Apache web server.
Having initiated an HTTP GET request to check if a server is vulnerable, the hackers launched a second HTTP GET request containing an execution command line that downloads and runs a shell script into that organization’s container.
With the initial access attack completed, the shell script’s first goal is to undermine security defenses and prepare the ground for its next actions. Alongside disabling firewalls, allowing traffic, and deleting LD_PRELOAD, the script executes multiple kill commands to eliminate any competing malware or processes such as cryptominers and cloud agents.
Having completed all these tasks, the attackers next delete log files in a bid to cover their tracks and avoid detection after the fact.
Step 2: Execution
As the hackers have cleared the way for the overall attack, the script sets up variables and a ‘get’ function that is used to download and execute the main malware binary – a cryptominer. Packed by UPX to avoid detection via hashes, this binary has two functions.
Alongside performing cryptomining, it also actively looks to run more cryptominers on more container instances. It does this by gathering all available credential information held within the container itself and using a loop to connect to neighbouring systems, so it can download and execute the same malware script on these lateral systems. The analysis we undertook on this specific attack found the malware executed a massive scan in a bid to find open SSH (port 22) and Redis (port 6379) ports in the internal container network, sending over 24,000 packets to those two ports.
Step 3: payload
Now safely ensconced in the container, the malware runs a different instance of the same binary with a different process name, connecting back to the attackers’ command-and-control (C&C) server to download and execute a ‘coinminer’ variant. To support and enhance cryptomining efforts, the attacker also attempted to load an MSR kernel module to boost the overall speed of the mining process.
Growing risk factors
Organizations are dealing with modern threat actors that are always looking for new ways to exploit known vulnerabilities in third-party software. Last year, cases of cryptomining malware soared by 300%. Once a vulnerability is identified, attackers can install cyptominer malware on unsuspecting organizations. Conducting the mining process using someone else’s processing resources allows the attackers to generate profitable digital treasures.
Attacks that crypto currency mining software can result in significant performance issues in servers, databases and application development frameworks and even Denial of Service (DoS) scenarios.
However, once an initial foothold has been gained into an organization’s environment, there’s little to prevent bad actors from pivoting their efforts to focus on other higher value assets.
Today’s attackers are always honing their tactics to hide their cryptomining activities. Alongside disabling firewalls, they’re deactivating the non-maskable interrupt that signals attention for non-recoverable hardware errors and system resets. Plus, they’re downloading encoded and obfuscated shell scripts to prevent security tools from understanding their intent. Ultimately, their goal is to evade detection for as long as possible and maximize the potential for a return.
Securing your cloud environment
Organizations have a big task on their hands to keep track of all workloads and software running in a cloud environment, especially due to the relentless speed of the modern DevOps cycle. Organizations should consider enforcing two-factor authentication for all users, setting branch protection restrictions, and restricting forked pull requests to run on the CI platform to improve security. Alongside finding and fixing known CVEs and security flaws, continuously monitoring containers and troubleshooting suspicious behavioral patterns is essential. Utilizing runtime analysis, with tools that feature in-built rule sets, on third-party applications like Apache Struts 2 will help flag potential
runtime attacks and exploits. In the long term, a dedicated solution that properly governs third-party access in an organization’s software supply chain can help avoid such risk in the future.
