On 2025/05/20, we received a couple of emails from Google re: users being added to Google Search Console.
After seeing the mail, Bruce sent an inquiry to the team about it and Nick responded with indication that it appeared that the site had been taken over. I looked at the DNS on GoDaddy, confirmed that the record was still pointing to the bucket, and on AWS that the bucket was indeed deleted (Bruce, Marco and I deleted as part of SAGL-78 last week).
I deleted the DNS record, which essentially moves the problem off the ‘sagebase.org’ domain.
xschildw@w156 deploy % dig +short versions.synapse.sagebase.org xschildw@w156 deploy % |
Nick and Jay mentioned we should also look at the Google Search Console. We clicked on ‘I dont know this person’ in one of the original emails above. When we looked at the ‘sagebase.org’ property, everything looked fine.
However, when adding the property ‘versions.synapse.sagebase.org’ in the left panel we did recognize the email addresses from the emails. We deleted these users from the list of users.
The incident is an instance of a known problem called ‘subdomain takeover’ that can happen when leaving dangling DNS records pointing to S3 records:
we start with an S3 bucket configured as static website, the DNS record just points the website endpoint
we delete the bucket but do not delete the DNS record
the S3 website can still be accessed, all it takes it for someone to create an S3 bucket with the same name, set it up as a static website and they can now server content at your website endpoint…
delete DNS record that points to an S3 bucket when deleting the bucket
require domain validation (https)
do not use bare S3 buckets as websites, put them behind a Cloudfront distribution
alternatively, do not delete the bucket, set up a redirect and keep it locked down
preemptive steps:
review DNS records in sageit/synapse and delete dangling records (PLFM-8998)
follow best practices for DNS management in organization