How a Red Team Drill Avoided a New SolarWinds-Style Attack
A competent threat actor can easily infiltrate an organization’s development environment and perform a Solar winds or a Kaseya-style supply chain attack within days, according to new information from Palo Alto Networks, which warns that many software companies have been lulled into a false sense of supply chain security in the cloud .
In a recently released report on the state of the cloud security market, downloadable in full here, the company’s Unit 42 team recounted how they managed to break into a major software as a service (SaaS) vendor and ‘execute’ a supply chain attack in just 72 time.
The software company, which cannot be named for obvious reasons, hired the services of Unit 42 to break into its cloud-based software development environment after being spooked by the SolarWinds incident.
The Unit 42 red team took advantage of configuration errors in the development environment to take control of the customer’s software development process in the same way as a advanced persistent threat (APT) was able to penetrate the SolarWinds platform to introduce a tainted code update.
âSupply chain risks have received a lot of attention in the media recently, what discussions often forget is that attackers do not necessarily modify source code repositories to facilitate these breaches. They don’t have to. They find weaknesses in the software development pipeline and attack them, âMatthew Chiodi, Palo Alto’s cloud security manager, wrote in the report’s preamble.
Red teamers masqueraded as malicious developers with limited client access Continuous integration (CI) from which they tried to gain admin rights to the larger cloud environment – although this is somewhat different from what happened at SolarWinds, it similarly shows how a attacker or malicious insider could take advantage of a CI repository.
To begin with, the researchers were given a DevOps role that the customer would typically give to all developers in their environment, including access to their internal GitLab repositories. This was the client’s first failure – if he had followed the best practices recommended for segregation of duties for each developer, the exercise might not have worked out as well.
From there the red teams were able to download each GitLab repository from the customer’s cloud software storage location. Here, they found approximately 80,000 individual cloud resources, including virtual machines (VMs), databases, storage instances, network infrastructure, and network gateways in 154 unique repositories. Importantly, they also found 26 hardcoded identity and access management (IAM), five of which were session tokens, the other access keys.
From there, the red team increased their privileges by using the stolen IAM keys to exploit a misconfiguration in a specific feature of Amazon Web Services (AWS), iam: PassRole, which allowed them to create a EC2 instance with administrator access to the larger cloud environment.
With such access established, the red team had the full capacity to perform a number of actions in the cloud environment of the lucky customer or the unfortunate victim. This included poisoning CI’s operations to insert malicious code into their software development pipeline, although as this was outside the scope of the commitment, the exercise was stopped at this point.
A broader analysis of the security operations and customer response was then undertaken, which ultimately resulted in the suspicious activity being reported to the customer’s Security Operations Center (SOC) in Amazon’s custody service service, which performed as expected but was not properly configured on all of the customer’s AWS accounts and therefore only spotted a small fraction of the overall fiscal year.
Nevertheless, once alerted, the SOC team was able to quickly identify each compromised IAM key used by the red team and effectively deployed its security orchestration, automation and response (SOAR) tools to deactivate the keys and close access.
Unit 42 subsequently worked extensively with the confirmed organization to implement a ‘shift left’ security plan, elements of which (detailed in detail in the report) include more stringent and based access controls. on roles for developers to prevent DevOps repositories from going astray; implementing cloud platform detection rules for sensitive API requests originating outside the scope of the organization’s network; and cloud platform discovery rules for user-specific API requests to IAM service accounts.
âThe Red Team exercisesâ¦ show an example of the impact of poor supply chain security hygiene on cloud infrastructure. The customer, in this case a large SaaS provider, maintains what most would consider a mature cloud security posture. However, Unit 42 researchers found that 21% of the security scans they performed on the customer’s development environment resulted in configuration errors or vulnerabilities, a number that perfectly matches the industry average. 20%, âthe Unit 42 team said in the report.
“The researchers believe that it is very likely that the techniques used during the Red Team exercise can be applied successfully to many organizations developing applications in the cloud,” they said, although he Also important to note that this particular attack route was not identical to the one used against SolarWinds.
The team said that despite much discussion in the security community about the so-called left shift model, organizations clearly continue to neglect DevOps security, in part, they believe, due to the lack of attention to supply chain threats.
Since cloud native applications have such a long chain of dependencies – such as open source tools and various components from other vendors and developers, and those dependencies likely also have dependencies – it is critical that DevOps and security have full visibility. “BOM” in every cloud workload.
Too many, they said, still seem to believe that analyzing code at the end of the development cycle is sufficient, and as long as this mistaken belief persists, cloud development environments will continue to be targeted by threat actors. .
âThis was certainly the case for the SolarWinds breach as well as for this could has been a major breach for our client was that the Unit 42 team did not identify vulnerabilities in the client’s supply chain until a malicious attacker did, âthey concluded.