This is part two of a two part series about AWS’s new Lightsail object storage. In part 1, I looked at the new Lightsail access key capability. In this second part we’ll look more closely at the buckets created.

It was over 7 months ago when I posted part 1, so why the delay? I was waiting for AWS to fix something, and it was low enough risk and impact that I didn’t feel a need to “encourage” them with a public post, but I’m glad it’s finally fixed.

Making a public bucket

In part 1, I identified that Lightsail object storage creates an S3 bucket in a special Lightsail account. Let’s look at that bucket.

The first thing that jumped out at me in the announcement was an indication that these buckets could be made public. AWS has been trying for a decade to stop the almost weekly news stories of public S3 buckets found with sensitive data in them. Lightsail in one aggressive move decided to add yet another way of making these public, bypassing all the previously created defenses.

This S3 bucket is created in another AWS account outside of your own, so the S3 Public Block Access control that you may have set in your account did not apply to this. This was what I was waiting for them to fix. Now S3 Public Block Access does prevent this Lightsail bucket from being made public. I was asked to hold off on posting this until that was fixed, and I figure Lightsail is rare enough among folks that have stronger cloud security concerns and few people would expect “S3” public block access to impact Lightsail, so I agreed to hold off, then I forgot about it, then AWS fixed it and told me they fixed it, so now I’m posting it.

From the screenshot, there was an option for “individual objects can be made public”, which means S3 object ACLs can also be used, which is yet another violation of best practices, as you should avoid using those. This is however prevented with S3 Public Block Access.

Looking closer at the bucket

I was curious if I could get more info about the account this S3 bucket was creatd in, so I guessed that I would be able to read the object ACL from the public bucket, and I was able to.

$ aws s3api get-object-acl --bucket bucket-kgxqi8 --key test_object.txt
{
    "Owner": {
        "DisplayName": "lightsail-shadow+386-0944",
        "ID": "09ee0cfc526e2171e2fcc2848eb3218e6ff3627e7296cce899b09876c8a43eb4"
    },
    "Grants": [
        {
            "Grantee": {
                "DisplayName": "lightsail-shadow+386-0944",
                "ID": "09ee0cfc526e2171e2fcc2848eb3218e6ff3627e7296cce899b09876c8a43eb4",
                "Type": "CanonicalUser"
            },
            "Permission": "FULL_CONTROL"
        }
    ]
}

So the name of the account is lightsail-shadow+386-0944. In the last post we figured out what the account ID was using the access key we had, but I actually had looked into the S3 bucket before I started using the access key, and identified the account ID using only the S3 bucket by translating the canonical ID of the account from the ACL. To do this, in an actual S3 bucket in my account, I changed the bucket policy to the following and saved it:

Once AWS saves an S3 bucket policy with a Canonical ID it will automatically translate it to an account ID.

So this S3 bucket is hosted in some AWS lightsail account with id 850260390076.

Why this bucket is a problem

Similar to the access key from part 1, having a resource in another account creates a number of problems. S3 Public Access Block now is able to stop this bucket from being made public, but enabling Cloudtrail data events in your account will not log access to this bucket. In November 2021, they did add the ability to enable S3 access logs, but those will not appear in your Cloudtrail logs like normal S3 object logs do.

Conclusion

You should apply an SCP from your organization to deny use of the Lightsail service. Lightsail is a useful service for personal users and maybe small businesses, but it’s not aligned with the interests of larger organizations. The addition of yet another ability to make data public, which originally circumvented the S3 public block access mitigation, and to make long-lived credentials that you have little visibility into, is a step in the opposite direction of the security best practices that AWS has tried to move people toward.