🎩 Awesome Black Hat Arsenal

Курируемый список инструментов с BlackHat конференций, сгруппированный по событию (USA, Europe, Asia), году и категории

➡️ Miscellaneous / Lab Tools
➡️ Web/AppSec
➡️ Web/AppSec or Red Teaming
➡️ Red Teaming
➡️ Red Teaming / AppSec
➡️ Blue Team & Detection
➡️ Reverse Engineering
➡️ OSINT

💻 Repo

#tools #blackhat #event

✈️ Whitehat Lab 💬Chat

🚩 VKACTF 2025

Решения задач на прошедший VKACTF, в котором приняли участие и заняли 2ое место

💻 Райтапы
🔗 Site
🔗 Scoreboard

#ctf #vkactf2025

✈️ Whitehat Lab 💬Chat

⛈Небезопасная генерация токена

Что может быть проще: сброс пароля, подтверждение почты или аутентификация по токену? Но если ваш токен генерируется геморройно простым методом — у злоумышленника появляется прямой доступ к системе. Давайте разберёмся, почему до сих пор взламываются даже крупные сервисы и почему “уникальный токен” — не всегда синоним безопасности.

🟢 Как появляется проблема:

Иногда разработчики генерят токены через стандартные функции вроде rand() или time(), добавляя к ним user_id или инкрементный счетчик. Примеры из реального мира:
- Сброс пароля: token = md5(time() . user_id)
- Авторизация: просто strval(rand())

❗️По факту — это не токен, а открытая дверь, где “замок” известен каждому умеющему читать код. Если сервер при отправке ссылки для сброса пароля проверяет только такой токен — любой, у кого есть доступ к user_id и времени генерации, сможет подобрать нужное значение и получить доступ к чужому аккаунту.

🔊 Как это эксплуатируют:
Самый частый паттерн:
1. Изучаем токен — часто можно декодировать его, видим время или user_id.
2. Получаем user_id жертвы (через API или просто по URL).
3. Генерируем гипотетические значения токена по шаблону, который использует сервер.
4. Подставляем их в запрос — вход срабатывает. Профит.

📌 Даже хуже, если используется стандартный rand() на популярных языках — достаточно знать seed или время запуска генератора, чтобы воспроизвести последовательность токенов полностью (пример: предсказуемые токены сброса пароля в старых версиях некоторых CMS).

🔔 Как делать правильно?

Используйте только криптографически стойкие генераторы случайных чисел:
- Для PHP: random_bytes() и bin2hex()
- Для Python: secrets.token_urlsafe()
- Для Node.js: crypto.randomBytes()

Короче — никогда не генерируйте security-токены с помощью наивных функций и не смешивайте их с очевидными константами (user_id, timestamp и прочее)! Любой аудитор кода обязан сразу поднимать тревогу, видя старые добрые md5(time()).

Когда вы в последний раз проверяли генерацию токенов в своем проекте? Поделитесь кейсами — у кого встречались "простейшие" реализации? 👀

📶 Полезная ссылка: https://cqr.company/ru/web-vulnerabilities/insecure-token-generation/

ЧТНП | #web

😊 API Gateway как линия фронта в Web3

Внимание: CatSwap в этом тексте — не стартап и не “очередной ”, а наш pet-проект для иллюстрации. Он нужен, чтобы показать, как Web3-сервисы должны мыслить в части защиты API — не опираясь на бэкэнд, а начиная с Gateway.

В Web3 большинство угроз входит не через «модные» DeFi-примитивы, а через вполне классический API-интерфейс. Просто формат другой: не form-data, а подписанный JSON с маршрутом, суммой и временной меткой. CatSwap, как агрегатор, — типичный пример. Все транзакции, котировки, swap-запросы проходят через публичное API.

✅ Чеклист по защите API Gateway

▫️ HTTPS (TLS 1.2+) + WAF
• Принудительное HTTPS;
• WAF / WAF с OWASP CRS, бот-контролем и Geo-ACL.

▫️ Аутентификация
• JWT в envoy.filters.http.jwt_authn;
• Web3-подписи (EIP-191/712) через Proxy-Wasm (X-Address + X-Signature);
• Challenge-nonce, защита от replay-атак.

▫️ Авторизация (OPA / ExtAuthz)
• RBAC/ABAC-политики по ролям, slippageTolerance, gasPrice, геопозиция, времени суток;
• Динамические политики Rego + GitOps-репозиторий.

▫️ JSON-валидация запросов
• OpenAPI-схемы → Envoy JSON Validator, ошибка 400 при несоответствии;
• Чёткое разделение обязательных и опциональных полей.

▫️ Rate Limit & QoS
• /v1/quote ≤ 1000 r/m; /v1/swap ≤ 100 r/m;
• Circuit breaker, retry, max concurrent;
• Приоритет маршрутов, Kubernetes Resource Limits.

▫️ API Gateway (Envoy + Proxy-Wasm)
• JWT (RS256) через envoy.filters.http.jwt_authn;
• JSON Schema Validator — строгая валидация payload;
• Rate-limit, circuit breaker, retry с экспоненциальным backoff;
• ExtAuthz → ML-анализ;
• mTLS внутри кластера (Istio-SDS или Envoy native).

▫️ Логирование & мониторинг
• JSON Access Logs (path, key, user_id, latency, tx_hash);
• Prometheus (p95/p99, ошибки, RPS) / Grafana—дашборды;
• OpenTelemetry + Jaeger; трассировка end-to-end;
• GitOps-аудит конфигов (ArgoCD/Flux).

▫️ Management plane hardening
• Bastion-host с MFA для доступа к административным интерфейсам;
• Жёсткие IAM-роли и Just-In-Time elevation для операторов.

▫️ CI/CD & GitOps
• Инфраструктура как код (Terraform, Helm);
• ArgoCD синхронизация; PR-ревью, tfsec/checkov, canary-релизы.

▫️ Supply chain security & SBOM
• Генерация и хранение SBOM для всех контейнеров и зависимостей;
• Подпись артефактов (cosign/Sigstore) и верификация на этапе деплоя.

▫️ Контроль изменений и drift detection
• Policy as Code (OPA, Terraform Sentinel);
• Инструменты проверки конфигураций (tfsec, Checkov, Conftest).

▫️ ML-анализ в Gateway 💻
• Isolation Forest в Seldon Core; Envoy ExtAuthz вызывает /predict;
• Блокировка при score > 0.8; алёрты в SIEM/Slack.

▫️ API lifecycle & versioning
• Явное управление версиями API, deprecation-policy, backward-compatibility тесты;
• Тёмные и канареечные запуски (traffic mirroring) новых эндпоинтов.

▫️ Disaster recovery & multi-region failover
• Репликация Gateway в нескольких регионах; автоматический DNS-фейловер;
• Документированные RTO/RPO и регулярные drill-тесты.

▫️ Пентесты & Bug Bounty
• Ежеквартальные внешние пентесты API Gateway и RPC-узлов;
• Запуск программы Bug Bounty (HackerOne / Standoff / bizone) для непрерывного обнаружения уязвимостей.

▫️ План реагирования на инциденты (по просьбе SOC)
• Определённые playbook: detection → containment → eradication → recovery;
• SLA/TTR для критичных сервисов; регулярные учения.

▫️ Приватные RPC (PrivateLink / IAM)
• JSON-RPC узлы скрыты за VPC Endpoint (PrivateLink / PSC);
• Доступ по SigV4 / ACL; rate-limit и circuit breaker перед нодами.

▫️ HTTP-security headers
• HSTS (Strict-Transport-Security), CSP, X-Frame-Options, X-Content-Type-Options;
• Защита от clickjacking и MIME-sniffing.

▫️ Сегментация сети и ограничения доступа
• Kubernetes NetworkPolicies; NSG/Security Groups;
• Микросегментация: отдельные VPC/subnet для критичных сервисов.

🔫 А зачем

В общем, это не просто чеклист для галочки. Это попытка собрать разумную, масштабируемую и живучую архитектуру, в которой API Gateway — не прослойка между интернетом и микросервисами, а полноценная точка принятия решений.

#appsec