DEV Community

Cover image for Leaky Bucket: Full Attack Chain Against Public S3-Compatible Buckets in Yandex Cloud
KL3FT3Z
KL3FT3Z

Posted on

Leaky Bucket: Full Attack Chain Against Public S3-Compatible Buckets in Yandex Cloud

#webdev #s3 #aws #cybersecurity

Leaky Bucket: Full Attack Chain Against Public S3-Compatible Buckets in Yandex Cloud

🛑 Disclosure: A lightweight proof-of-concept (PoC) tool was developed by hackteam.red for internal red teaming and authorized penetration testing. The PoC will not be released publicly, but it is actively used to assess Yandex Cloud Object Storage configurations for clients who explicitly permit such testing.

🔍 Overview

Yandex Cloud provides an S3-compatible Object Storage service that allows customers to host static websites via public endpoints like:

http://<bucket-name>.website.yandexcloud.net
Enter fullscreen mode Exit fullscreen mode

While this is a convenient feature for developers and enterprises, misconfigurations or oversight can lead to unintended public exposure of sensitive technical documentation, internal architecture details, or — in worst cases — source code and configuration files.

Unlike AWS S3 buckets (which are aggressively scanned by automated bots), Yandex Cloud buckets have historically flown under the radar — making them an attractive target for reconnaissance and exploitation by offensive security teams.

This article details a real-world attack chain we’ve validated during authorized engagements, from initial discovery to potential data leakage.

🧭 Full Attack Chain

1. Initial Discovery via Google Dorks

The simplest entry point starts with a basic Google search:

allinurl:.website.yandexcloud.net
Enter fullscreen mode Exit fullscreen mode

This quickly reveals active buckets used for corporate websites, developer portals, and event microsites:

  • 1cgencode.website.yandexcloud.net — “Developer Tools for 1C”
  • devops-pilot-competencies.website.yandexcloud.net — Yandex Cloud training materials
  • b3-website.website.yandexcloud.net — Waste management SaaS platform
  • transrussia.ru.website.yandexcloud.net — TRANSeuropa logistics expo

While these appear benign, they confirm existence and reveal business context.

2. Automated Enumeration with httpx

We feed discovered names into httpx (from ProjectDiscovery) to filter only HTTP 200 responses:

cat buckets.txt | httpx -silent -status-code -mc 200 -o live-buckets.txt
Enter fullscreen mode Exit fullscreen mode

This step eliminates false positives and focuses efforts on truly public buckets.

3. Wordlist Expansion & Brute-Forcing with ffuf

We generate a context-aware wordlist combining:

  • Top 100 Russian companies (sberbank, ozon, 1c, bitrix24)
  • DevOps terms (prod, staging, backup, tfstate, config)
  • Observed patterns (mitt, karta, safelist)

Then launch targeted brute-force:

ffuf -w expanded-wordlist.txt \
     -u "http://FUZZ.website.yandexcloud.net" \
     -mc 200 -t 10 -p 0.8
Enter fullscreen mode Exit fullscreen mode

This often uncovers additional buckets not indexed by Google.

4. Sensitive Path Fuzzing

For every confirmed bucket, we fuzz for high-risk paths:

/.git/HEAD
/.env
/backup.zip
/terraform.tfstate
/config.js
/id_rsa
/aws-keys.txt
/yc-keys.txt
/robots.txt
/sitemap.xml
Enter fullscreen mode Exit fullscreen mode

Using ffuf or a custom Bash script with built-in rate-limiting (to avoid IP bans), we check for 200 OK responses indicating data exposure.

✅ Even seemingly “safe” files like robots.txt can leak internal paths:

Disallow: /ru/exhibit/conference-zal/
Disallow: /ru/media/news/.../registraciya-posetitelej-otkryta-transrussia

These reveal hidden functionality, event structures, and registration logic.

5. JS/HTML Secret Hunting

We scan all public JS/HTML files for secrets:

curl -s http://bucket.website.yandexcloud.net/ | \
  grep -E "(yc|aws|key|token|secret|accessId)"
Enter fullscreen mode Exit fullscreen mode

While no live secrets were found in our scans, hardcoded endpoints, internal service names, and third-party integrations were commonly present — enriching our target map.

6. Exploitation Scenarios

Finding Impact
.git/HEAD Full source code recovery via git-dumper
terraform.tfstate Full infrastructure state, including IAM keys
yc-keys.txt Direct access to Yandex Cloud APIs
backup.zip Historical snapshots, credentials, PII
Internal paths from robots.txt Attack surface expansion

Even without direct secrets, such intelligence is invaluable for:

  • Crafting targeted phishing lures
  • Mapping internal architecture
  • Planning lateral movement in cloud environments

🛡️ Recommendations

For Yandex Cloud Users

  • Never upload .git, terraform.tfstate, .env, or backups to public buckets.
  • Use separate private buckets for build artifacts and logs.
  • Before enabling Static Website Hosting, review all files in the bucket.
  • Consider using robots.txt to disallow all paths except those strictly needed.

For Yandex Cloud Platform

Yandex already offers DSPM (Data Security Posture Management) — their equivalent of Amazon Macie. We recommend:

  1. Enable automatic scanning of Object Storage buckets for sensitive patterns (keys, .git, tfstate).
  2. Add warnings when “Static Website” is enabled on a bucket.
  3. Enforce “Block Public Access” at the account level (similar to AWS).
  4. Prevent uploads of known-sensitive files (e.g., .git) to buckets with public access.

💡 DSPM is a powerful tool — but only if applied to publicly accessible buckets.

🔚 Conclusion

Yandex Cloud’s Object Storage is a robust and developer-friendly service. However, like any cloud resource, security is a shared responsibility.

Through simple, low-cost reconnaissance and targeted fuzzing, attackers can uncover valuable organizational intelligence — and, in misconfigured environments, full system compromise.

This research was conducted strictly within the bounds of authorized penetration testing.

Our internal leaky-bucket scanner remains closed-source and is used only with explicit client permission for customers operating in Yandex Cloud.

đź”— References

📢 Note: If you’re a Yandex Cloud customer and want to test your buckets for exposure, contact a certified penetration testing provider — do not scan without authorization.

Top comments (0)