😈 Ержан, вставай!

Давно не было разбора атак на моих проектах. Время исправляться, есть интересная находка. Впервые на проекте нашёл вектора для DoS-атаки, так еще и первая на практике критическая уязвимость.

Конечные точки API для осуществления денежного перевода на вход в JSON-запросе принимают экспоненциальное значение (1e-1) и обрабатывают её, выдавая в ответе рассчитанную сумму с учётом комиссии. При увеличении количества нулей в экспоненте (1e-100...) возрастает время ответа от сервера. На обычные запросы это ~100 мс, после 300, 1000, 8000 и так далее. Наткнулся на такое значение экспоненты, при котором ответ с сервера я получаю через 60000 мс (стандартное ограничение в некоторых браузерах) с 504 HTTP ошибкой.

Решили с Заказчиком провести более глубокое исследование потенциального DoS под наблюдением за сервером. Выяснилось, что экспонента 1e-100000000 и подобные нагружают сервер до 30% при отправке очередью (при ожидании ответа на каждый запрос), когда в обычном состоянии нагрузка не выше 5%. Физически такое число практически равно нулю, но математически нет. Если код пытается его обрабатывать "честно" (например, переводя в дробь или делая арифметику с высокой точностью), это может создать огромную вычислительную нагрузку. Всё говорит о серьёзной проблеме, учитывая то, что это было проделано лишь с помощью одного устройства. А если это сделать в кооперации с другими устройствами? Нагрузка выйдет куда выше.

▎ Риски:
➡️Отказ в обслуживании: один запрос нагружает сервер до 30%, а координированная атака способна нанести более серьёзный урон;
➡️Финансовые потери: запросы связаны с платёжным API, в случае его отказа возможны сбои в транзакциях пользователей;
➡️Репутационный ущерб: нестабильность сервиса подрывает доверие пользователей.

▎ Рекомендации по устранению уязвимости:
✅Валидация входных данных: запрет экспоненциальной записи;
✅Лимиты на обработку чисел: установка максимальной точности (например, округление до 5 знаков после запятой). Timeout на обработку запроса (например, 1 сек), при которой сервер автоматически будет откидывать запросы, которые обрабатывает более установленного времени;
✅Защита от DoS/DDoS: пропускать не более, например, 100 запросов/мин с одного IP, иметь детекты на атаку с различных IP-адресов и отражать вредоносные запросы на сервер;
✅Мониторинг и логирование: алерты при резком росте нагрузки на CPU, логирование подозрительных запросов.

Снова тот случай, когда недостаточная валидация входных данных может привести к катастрофическим последствиям. Нельзя доверять пользовательскому вводу.

"1e-100000000" — это не число, а таймер до перезагрузки сервера.

#кейс

👨‍💻 Награждение Red Team на Standoff 15

😈 ПриветСнова%20

В этот чудесный день решил поделиться с вами забавной находкой на проекте, позволяющей повторно использовать номер телефона для регистрации и обходить блокировку по нему. Банальный пробел в URL-кодировке (%20) превращает номер в "нового пользователя"!

Система регистрирует аккаунты по номеру телефона, но не проверяет его корректность перед обработкой. Если даже к заблокированному в системе номеру (например, 79999999999) добавить пробел в виде %20, сервер воспримет это как новый номер (79999999999%20) и разрешит регистрацию. Также можно добавлять сколько угодно пробелов: 79999999999%20%20, 79999999999%20%20%20 и так далее. Для системы каждый такой вариант — уникальный аккаунт, хотя SMS-код всегда уходит на один и тот же номер.

Это как если бы вас не пускали в клуб по имени «Даффиер», но пропускали с тем же лицом, представившись «Даффиер%20».

▎ Риски:
➡️Обход блокировок: злоумышленник может продолжать использовать заблокированный номер, хоть и с новым аккаунтом в системе;
➡️Спам и злоупотребление: флуд SMS-сообщениями, создание тысяч "мусорных" аккаунтов;
➡️Захламление БД: дубликаты номеров, проблемы с аналитикой и чистотой данных.

▎ Рекомендация по устранению уязвимости:
✅Нормализация номера со строгой валидацией: удалять пробелы (регулярки в помощь)/спецсимволы до проверки на блокировку и регистрации нового аккаунта.

#кейс

🤨 Прямо из печи!

Нашёл для вас свежий материал по SSTI уязвимости: "Полное руководство по использованию расширенных серверных шаблонных внедрений" (на английском языке).

Серверный шаблонизатор — мощный инструмент, но без должных проверок ввода он становится оружием для атакующего. Многие до сих пор пропускают SSTI из-за сложностей в идентификации, хотя эксплуатация может привести к серьезным последствиям.

▎ Содержание:
➡️Почему SSTI так опасны;
➡️Как находить и использовать их в реальных сценариях;
➡️Сложные кейсы эксплуатации в разных шаблонизаторах.

🔗 Ссылка на полное руководство по SSTI

#материал

🤨 О наслышанном

Думаю, вы уже видели информацию про ежегодную премию Pentest Award.

Pentest Award — это отраслевая награда для специалистов по тестированию на проникновение, которую ежегодно вручает компания Awillix. Основная задача премии — выделить лучших специалистов и показать их вклад в развитие российского пентеста. Мероприятие состоится уже в третий раз.

Изначально приём номинаций был до 30 июня (до сегодня), но их продлили до 16 июля (и более продлений не будет). Кто не успел подать номинацию для участия — подавайте, время еще есть! 😎

▎ Имеются следующие номинации:
➡️Пробив web;
➡️Пробив инфраструктуры;
➡️Мобильный разлом:от устройства до сервера;
➡️Девайс;
➡️«**ck the logic»;
➡️«Раз bypass, два bypass»;
➡️«Ловись рыбка»;
➡️Out of Scope;
➡️Антиноминация — Осторожно грабли.

Номинации можно подавать обезличенными без раскрытия Заказчиков. Количество номинаций для участия не ограничено.

Лично я подал 3 номинации, будет круто пройти хотя бы в шорт-лист 😁

🔗 Ссылка на Telegram пост Awillix
🔗 Ссылка на подачу номинации для участия в премии

🤨 Аналог Burp Suite Pro за бесплатно?

Caido — кроссплатформенное решение для веб-пентестов, которое уже на старте даст фору платному Burp Suite Pro. Создан, чтобы было легче и быстрее проводить аудит веб-приложений.

▎ В инструменте имеется:
➡️Intercept — перехват и просмотр HTTP-трафика в реальном времени;
➡️Replay — ручное тестирование через повтор запросов;
➡️Automate — массовая отправка запросов со словарями;
➡️Sitemap — визуализация структуры приложения;
➡️Match & Replace — автозамена данных по шаблонам;
➡️Workflows — сборка кодеров и декодеров без кода;
➡️Плагины — простая система на HTML/CSS/JS;
➡️HTTPQL — фильтрация трафика по гибким правилам;
➡️Клиент-серверная архитектура — удобно работать удалённо;
➡️Проектная модель — сессии, история и автоматизация под рукой.

На данный момент Caido находится в Beta-тестировании.

Уже используете Burp? Попробуйте Caido для разнообразия — свежий взгляд на привычные задачи :)

🔗 Ссылка на официальный сайт Caido

#инструмент

😈 По секрету всему свету

На одном из проектов я наткнулся на целый набор уязвимостей, включая критическую — из‑за неправильно настроенного GraphQL API.

Началось всё с того, что на веб-сайте был обнаружен сам GraphQL. Первая идея — проверить работоспособность интроспекции (раскрытие схем). И чудо, удачно! Мне удалось вытащить очень жирную схему, которую взялся исследовать далее.

Один из GraphQL-запросов возвращал id, имя, логин, пароль (в открытом виде), креды PostgreSQL и прочую конфиденциальную информацию всех пользователей компании! И для этого не требовалась авторизация — любой мог получить доступ к данным через один запрос.

▎ Обезличенный вариант GraphQL-запроса:

{
  "query": "query { entities { id name username password и т.д. } }" 
}

▎ Риски:
➡️Утечка персональных данных;
➡️Компрометация учётных записей пользователей;
➡️Доступ к внутренним сервисам и базе данных через утёкшие креды;
➡️Потеря доверия клиентов и партнёров;
➡️Возможные штрафы за нарушение законов о защите данных.

▎ Рекомендации по устранению уязвимости:
✅Отключить интроспекцию в продакшене (__schema, __type);
✅Внедрить проверку прав на каждом query/mutation;
✅Исключить выдачу паролей и других секретов через API;
✅Хранить пароли в хэшированном виде.

Ты ему query, а он тебе креды.

#кейс

📕 Здравствуй, небо в облаках

Прошёл интересный и содержательный курс по ред тиму AWS (Amazon Web Services) — AWS Red Team Apprentice (ARTA) от Hacktricks. От эксплуатации уязвимостей с методологией проведения работ до обхода систем обнаружения в облаке.

Мотивацией стало то, что Яндекс Облако во многом похоже на AWS.

Впервые был опыт изучать облака. Поначалу было необычно, непонятно, испытывал трудности при изучении базы ещё до эксплуатаций. Но с началом лабораторок стало приходить общее понимание AWS. Мне всё понравилось!

Да, помимо курса ARTA есть еще и ARTE, но сертификаты по облакам в России не особо востребованы в тендерах, так что не увидел смысла переплачивать.

Если у кого какие вопросы по курсу — задавайте!

#hacktricks #redteam