Abandoned AWS S3 buckets can be reused in supply-chain attacks that would make SolarWinds look ‘insignificant’ – Source: go.theregister.com

Abandoned AWS S3 buckets could be reused to hijack the global software supply chain in an attack that would make Russia’s “SolarWinds adventures look amateurish and insignificant,” watchTowr Labs security researchers have claimed.

The researchers, in a report due out this morning, say they identified about 150 Amazon-hosted cloud storage buckets that were long gone yet applications and websites were still trying to pull software updates and other code from them. If someone were to take over those buckets, they could use them to feed malicious software into people’s devices.

These S3 buckets had previously been owned or used by governments, Fortune 500 firms, technology and cybersecurity companies, and major open source projects.

The watchTowr team said it spent $420.85 to re-register these S3 buckets with the same names and enabled logging for all of them to track which files were being requested still and by what. They told us they spent two months watching the HTTP requests roll in.

During this time, the S3 buckets received more than eight million requests for resources including Windows, Linux, and macOS executables; virtual machine images; JavaScript files; CloudFormation templates; and SSL VPN server configurations, the watchTowr crew said.

These incoming requests came from NASA and other US government networks, along with government orgs in the UK and other countries, judging from domain records.

Military networks, plus those belonging to Fortune 500 and Fortune 100 companies, a “major payment card network,” and a “major industrial product company,” also pinged the S3 buckets, according to the security shop.

Additionally, banks and financial services firms sent file requests to the now-watchTowr-owned buckets, as did universities, instant-messaging providers, infosec firms, casinos, and others, we’re told. 

Larger problem of abandoned and expired infrastructure

This report highlights the security risks associated with abandoned and expired infrastructure. An earlier watchTowr study illustrated how throw-away internet domains can be abused if they are allowed to lapse and then purchased by some evil-minded individual or nation-state attacker.

Additionally, Truffle Security the other week highlighted the danger of startups and other businesses shutting down without closing their accounts on third-party software-as-a-service providers while using a domain for single-sign-on.

Picture this: An example startup called bigthinkr.com uses its dot-com domain for single-sign-on with Google. Its staff log into things like Slack using their name@bigthinkr.com identity after authenticating with Google. Then the startup abruptly shutters, doesn’t close down its SaaS accounts, and allows bigthinkr.com to expire. Someone buys bigthinkr.com, and can start logging into the business’s accounts again.

What should happen is that the accounts are fully deactivated before the domain expires, and that services should follow Google’s guidelines, particular the part about sub fields, to ensure single-sign-on isn’t abused.

“The underlying challenge is that people are effectively treating infrastructure as temporary, but with very, very permanent effects on what it gives access to, what it authorizes, where it’s trusted,” watchTowr CEO and founder Benjamin Harris told The Register in an earlier interview.

The security shop’s latest research identifies a similar problem, this time turning its focus to throw-away S3 buckets.

‘Terrifying simple’ attack to pull off

When asked about the feasibility of abusing this sort of abandoned internet infrastructure, Harris told The Register that it would be “terrifyingly simple” to pull off.

After identifying an S3 bucket that’s expected to host a software update or code for deployment and realizing that the bucket no longer exists, an attacker would simply need to do what watchTowr did next: Re-register this S3 bucket with the same name inside their AWS account.

Then “put your own executable and/or code in the path expected by the aforementioned deployment code/software update mechanism and watch significant numbers of systems, and sensitive networks, pull down your payload,” Harris said. 

“This scenario is exactly what we saw play out multiple times across the 150 sample S3 buckets we re-registered for this research,” he added. And while it is possible for applications to use mechanisms to verify a downloaded update is legit before using it – such as using digital signature checks – it’s not a given those protections will be in place.

In one example from the research: The team spotted a CISA.gov industrial control system security advisory from 2012 that directed users to a patch accessed via an S3 bucket.

The bucket has since been abandoned, but was still referenced on the CISA webpage, and as the researchers pointed out:

WatchTowr alerted CISA prior to publishing the research, and the referenced to the bucket in the government alert has since been removed.

In fact, all of the 150 no longer in use buckets have since been sinkholed, according to the researchers, who worked with AWS to make sure that these storage buckets can’t be used for nefarious purposes in the future.

• Have we learned anything from SolarWinds supply chain attacks?
• Judge mostly drags SEC’s lawsuit against SolarWinds into the recycling bin
• Ransomware crew abuses AWS native encryption, sets data-destruct timer for 7 days
• Crooks stole AWS credentials from misconfigured sites then kept them in open S3 bucket

And, while this latest research focused on AWS S3 storage, the overall “approach and theme is cloud-provider agnostic and applicable to any managed storage solution,” the team explained. “Amazon’s S3 just happened to be the first storage solution we thought of, and we’re certain this same challenge would apply to any customer/organization usage of any storage solution provided by any cloud provider.”

Amazon, for its part, assured The Register that “AWS services and infrastructure are operating as expected.” A spokesperson told us:

The cloud giant also noted that it provides guidance on best practices, and these include using unique identifiers when creating bucket names to prevent accidental reuse as well as ensuring applications are properly configured to reference only customer-owned buckets.

“In 2020 we launched the bucket ownership condition feature and encouraged customers to use this mechanism, specifically designed to prevent unintended reuse of bucket names,” the spokesperson said, adding that “AWS requests that researchers engage with our security research program before conducting research involving AWS services.”

Amazon did not say why it doesn’t ban the reuse of S3 bucket names, which is what watchTowr says would be the easiest way to fix the issue.

“We have repeatedly — like a broken record — shared our belief with the AWS teams that engaged with us that the most logical solution to the challenge here is to prevent the registration of S3 buckets using names that had been used previously,” Harris said. “This approach would entirely kill this vulnerability class (abandoned infrastructure) in the context of AWS S3.”

He admits that there is an argument to be made about security versus usability, and the “ability to transfer S3 buckets between accounts.” But, Harris added, “we do wonder if these requirements outweigh the impact we have demonstrated through our research.” ®