back to article Abandoned AWS S3 buckets can be reused in supply-chain attacks that would make SolarWinds look 'insignificant'

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 …

  1. b0llchit Silver badge
    FAIL

    Someone else's computer

    Computer hygiene is a process that costs money and takes effort. It is particularly difficult for people to get their heads around the fact that much data is not stored on their own infrastructure but on some"cloud" that rainspours data down from the interwebs.

    I guess,... stupid sees, stupid does.

    1. doublelayer Silver badge

      Re: Someone else's computer

      This is no different to things people can and do on their own infrastructure. S3 bucket names are DNS names and they can be reregistered when abandoned. This makes a case for Amazon deciding that it should only be possible to register a name once and once it is deleted, it's burned forever, but we don't attack the original domain name system for allowing that. As usual, it's the responsibility for the people using those names to keep track of them.

      In fact, cloud services makes it easier to do that than traditional ones. If I have a domain name that I've registered and I don't want someone to be able to squat on it, I have to keep paying for it every year. This is one reason why I have a bias to not having very many second-level domains*. If I have a S3 bucket that I don't want people to squat on, I can keep it around for free. I am charged for files stored in it and for bandwidth it uses, but if I delete all the files but keep the bucket around, the name stays registered and I retain control. It is better, however, for me to check such things rather than trust that whatever file comes back from an HTTP request is good enough.

      * I generally suggest that a company with the domain company.com refers to other services they run using subdomains (product.company.com) rather than creating another second-level domain (companyproduct.com). It has three benefits. Users can more quickly identify that the domain is related to the company since only they can create a subdomain (unless they've been hacked, which is a possibility), it is easier for the company to keep track of domains they control and make sure they are either in operation or shut down, and for smaller projects, it can cut down on money spent on registrars.

      1. CowHorseFrog Silver badge

        Re: Someone else's computer

        This is another example of how flawed AWS architecture and design is, that people can buy an abandoned domain and then gain ownership of S3 and other stuff n AWS.

        1. doublelayer Silver badge

          Re: Someone else's computer

          This comment is another example of how you're not understanding what the problem is or how it works, since buying an abandoned domain was an alternative to, not a component of, this problem. If you leave your domain but keep your AWS account, then I cannot get access to any of your AWS resources by getting your domain.

          1. Anonymous Coward
            Anonymous Coward

            Re: Someone else's computer

            If I get your abandoned domain and use the wayback machine to figure out which admin account registered your AWS account, I can own your AWS account unless you manually changed all of your admin/billing information in AWS.

            On another note, if someone abandoned bigthinkr.com, and I buy it, why should I be prevented from using an S3 bucket in AWS? Does it mean that I should register, and abandon S3 buckets for Microsoft, Google, SpaceX, ESA, etc. Or considering todays political climate should I be going after names like kaspersky?

            Stop trying to protect idiots from bigger idiots.

            1. doublelayer Silver badge

              Re: Someone else's computer

              "If I get your abandoned domain and use the wayback machine to figure out which admin account registered your AWS account, I can own your AWS account unless you manually changed all of your admin/billing information in AWS."

              I think you'll need to clarify that a bit. The email address used for the AWS account is not necessarily going to be found anywhere in the Wayback Machine. I probably didn't post that to the website. Even if you do get it, that isn't enough to gain access to the account. You can set up an email address and try to reset passwords, but if they had any other security on the account, that will not be enough.

              "On another note, if someone abandoned bigthinkr.com, and I buy it, why should I be prevented from using an S3 bucket in AWS?"

              Maybe you shouldn't. That is what we're discussing. Those who have argued that you should argue that buckets don't have to be memorable, so they could make them unique so that they can only exist once, in one account. I generally take the view that people should be careful about what they do because, even if AWS did that, lots of other systems wouldn't do that and the same problem would apply.

    2. CowHorseFrog Silver badge

      Re: Someone else's computer

      All these stupid bad things (tm) are because there are far too many fake people in the industry.. Too many managers and experts who dont add value and charge too much.

  2. cyberdemon Silver badge
    WTF?

    What!

    I have never (and never intend to) work with Amazon S3. But what you are saying is, Amazon lets you address a storage "bucket" by name and name alone, and then when you stop paying your money, they will let anyone else register with the same name and start stealing data from your dead Android apps etc??

    Shirley, they should not allow name re-use, not without some proof that you are the original owner

    Or at the very least, there should be some mandatory API key authentication, and the keys obviously would be regenerated when the bucket of the expired name is created by someone else

    1. balrog

      Re: What!

      I think its more how you set up your privileges when you build your S3, if you allow access to everyone with no security Amazon says if thats what you want. For some use cases that could be fine, say a document repository.

      It may be lazy developers who point the 'update url' in their app to a named S3 instance much as they could to any domain name. Once the domain name has lapsed you can buy it and do much the same.

      1. An_Old_Dog Silver badge

        Reverse Authentication

        There needs to be some sort of reverse authentication such that when queried, S3 and similar services would transmit to the querying app a hash of the current owner's name.

        Thus, the app could check to see whether the bucket address was still valid, i.e., owned by the person/company which created the app.

        1. balrog

          Re: Reverse Authentication

          There are ways to do this already. The issue is not an Amazon one, its that people are not using the facilities there already.

          1. bazza Silver badge

            Re: Reverse Authentication

            Ways that are burned into the S3 APIs?

            1. bazza Silver badge

              Re: Reverse Authentication

              Ways that don't involve client authentication?

              1. CowHorseFrog Silver badge

                Re: Reverse Authentication

                And people trust AWS even after they build something on this completely flawed and stupid 'feature".

        2. MonkeyJuice Bronze badge

          Re: Reverse Authentication

          Putting that responsibility onto app developers is just kicking it down the road (also multiplying potential points of failure), and I trust developers as far as I can throw them to bother to implement that correctly. Cybersquatting previously created bucket ids should not be possible, 'convenience' be damned.

      2. O'Reg Inalsin

        Re: What!

        At the very least each customer should have a non reusable account name, and the bucket names should be keyed off the account name, i.e. a prefix.

        Suppose a large company abandons a bucket. However some links inside the company still refer the the documents inside the abandoned bucket for procedural instructions, or a list of authorized contacts, etc. That's a weak link too, isn't it?

        1. Hawkeye Pierce

          Re: What!

          Indeed - I've always thought that the fact that AWS bucket names are globally unique is crazy.

          There was (and is) another vulnerability reported a short while back whereby anyone finding an enumerable list of buckets such as "ABC-Client-1", "ABC-Client-2" etc, can simply go and create a bucket called "ABC-Client-99" in their own AWS account and wait to see what happens.

          If AWS stuck the account number in front of the bucket name then sure you could create "ABC-Client-99" but it would be unique under your account not globally. And if you wanted anyone else to access it, you still can by just issuing the account number + bucket name and setting the appropriate permissions.

      3. bazza Silver badge

        Re: What!

        >It may be lazy developers who point the 'update url' in their app to a named

        >S3 instance much as they could to any domain name. Once the domain

        >name has lapsed you can buy it and do much the same.

        And it's kinda crazy that the same problem exists with domain names too. But it's particularly nuts with S3 buckets. There' no reason why the primary identified for an S3 bucket as used in the API couldn't be an UUID / GUID, that a developer could get hold of when first accessing the bucket (i.e. when they know for sure who is providing the bucket). On the basis that Amazon could easily make it very difficult for a customer to get an S3 bucket with an arbitrary UUID / GUID, it would be very difficult for someone to come in later and squat on the bucket.

        It's a bit harder with domain names, for sure, as people generally have to interact with them and long unique identifiers of a hexanumerical nature are not user friendly. But that's partly why websites have certificates...

        1. MonkeyJuice Bronze badge

          Re: What!

          With you up until the domain certificates part.

          Once I have control of your domain, I can trivially roll my own certificate with Certbot, or indeed purchase one if I'm feeling like a corporate whore from Verisign.

        2. Anonymous Coward
          Anonymous Coward

          Re: What!

          You've just described megaupload.com and the Tor network... so congratulations, the US government will be breaking down the door of the office at your previous address in two hours. I hope you didn't think it was going to be that easy. Or was Kim correct?

    2. Brewster's Angle Grinder Silver badge

      Re: What!

      Same issue with domain names. Once you stop paying, someone else can take it over.

      1. Paul Hovnanian Silver badge

        Re: What!

        But they'll need a new SSL certificate. Users didn't check the new ownership? Not my problem.

        "Wisdom comes through suffering." - Aeschylus

        1. bazza Silver badge

          Re: What!

          "True wisdom comes through observing closely the suffering of others." - me.

          1. stiine Silver badge
            Devil

            Re: What!

            Not only wisdom, but joy as well.

        2. Brewster's Angle Grinder Silver badge

          Re: What!

          As others have pointed out, you could take these sort of precautions with S3 buckets, too.

    3. JamesTGrant Bronze badge

      Re: What!

      Yes - not namespaced. Name and name alone. The S3 client API provides a way to test ’expected bucket owner’ but in the same way you can just download warez from a URL if you’re insane, you don’t need to do any authentication or province checking if you don’t want to. It’s interesting but it’s no different from including a download URL with no auth or sanity checks.

    4. vulture65537

      Re: What!

      S3 buckets can be used for web hosting. These days you need to fiddle with settings to allow that. So if someone is intentionally providing something to the public it's not normal that the public would need to authenticate to read it.

  3. Roland6 Silver badge

    Shutting down stuff on AWS…

    Just in the final phases of shutting down an AWS account, following a migration to another cloud provider, including wiping of used AWS buckets, we’ve been doing this since September 2024 - Amazon just don’t want it to be easy. So I fully understand how people can shut stuff down yet accidentally leave stuff accessible etc.

    1. isdnip

      Re: Shutting down stuff on AWS…

      And the usual case being addressed here does not provide for that effort. Something like 90% of venture capital backed firms fail within five years; that's the VC model, after all -- bet on a lot and hope a big winner covers the losses on the losers. So a customer buys a device from a firm that fails, and the device looks for that firm's bucket. The company closed down and laid off its entire staff, shut down its real buckets, and turned the lights off. So weeks later someone else comes along and impersonates that failed firm's buckets. The customer devices are happy; they think they found the mothership again. Sure, a device might have a fancier level of authentication, but that VC-backed startup was in a hurry to ship something and didn't want to add t hat complexity.

  4. IGotOut Silver badge

    It's about a decade since I left IT...

    ...just as this shit was kicking off.

    Devs loved "the cloud", because they didn't have to bother with us in IT, and all their stupid rules, like security, server management , ownership and proper administration.

    And because they decided they knew better, this is why you have these clusterfucks now.

    Right I'm off to bash some metal, I find it's less painful then repeatedly banging my head against a desk.

  5. KalF

    Turns out blindly trusting downloaded resources is dumb. who knew

    Just like the whois issue, this class of attacks relies on clients using a hardcoded or statically configured path forever. In the case of whois, it was exacerbated because the protocol has no legit delegation path, meaning every client had to do this and some just forgot to ever update. that protocol also has no inherent validation for received data.

    With any client that relies on fetching a resource via FQDN, the process should always use signatures to validate that the resource was actually generated by the author you trust. That way, even if you forget to update the clients, at least a malicious actor wont be able to send you files that you blindly trust. This really has nothing to do specifically with S3. Blocking out a name for eternity the first time it is used would be really dumb. This won't happen in the DNS world, so a validated supply chain practice that works well for FQDNs will work just fine for S3 also.

  6. Anonymous Coward
    Anonymous Coward

    So all these failed stratups, who's paying for the accounts?

    1. Paul Crawford Silver badge
      Facepalm

      Ultimately, all of us.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like