Хакер | Этичный хакинг с Михаилом Тарасовым

Как стать администратором веб-приложения за 0 секунд без перебора паролей и эксплойтов базы данных? Ответ кроется в архитектуре JSON Web Tokens (JWT). 🔑

Продолжаю практический марафон на Parrot Security OS. После того как мы сдампили базу пользователей через SQL-инъекцию, я решил проверить, насколько надежно бэкенд верифицирует клиентские сессии. Написал скрипт на Ruby (jwt_forge.rb) и разобрал одну из самых громких уязвимостей спецификации - атаку с алгоритмом none.

Делюсь разбором «на пальцах» и тем, как это выглядит в боевом терминале. 👇

В чем фундаментальная ошибка JWT? 🧩
Токен состоит из трех частей через точку:
Header.Payload.Signature

1. Header: метаданные (каким алгоритмом подписан токен, например RS256).

2. Payload: полезная нагрузка (ID пользователя, email, роль admin).

3. Signature: цифровая подпись сервера, которая гарантирует, что данные не подделаны.

Обе первые части - это обычный открытый текст, закодированный в Base64. Их может прочитать и изменить абсолютно любой человек в браузере. Вся безопасность держится исключительно на третьей части - проверке сервером подписи своим секретным ключом.

Но стандарт RFC предусматривает алгоритм подписи "none" - режим вообще без криптографической проверки.

Механика атаки: срезаем подпись на лету ✂
Если разработчики используют устаревшие библиотеки или забыли жестко зафиксировать разрешенные алгоритмы на бэкенде, сервер совершает фатальную ошибку: он слепо доверяет заголовку, который прислал клиент!

Что делает мой скрипт:

1. Берет легальную структуру токена.
2. В полезную нагрузку (Payload) вписывает права администратора: {"role": "admin"}.
3. В заголовке (Header) подменяет алгоритм на "alg": "none".
4. Начисто удаляет третью часть (подпись), оставляя только точку на конце: Base64(Header).Base64(Payload).

Запрос уходит на сервер через Burp Suite... и бэкенд отвечает статусом HTTP 200 OK!

Сервер прочитал заголовок, решил: «А, тут алгоритм none, значит проверять цифровую подпись не нужно» - и моментально выдал полный административный доступ к базе /api/Users. В Cookie прилетел валидный ответ. Занавес. 🎭

Почему это критично для бизнеса? 💣
В отличие от классических атак на форму входа:

- Атакующему вообще не нужно знать пароль жертвы или хэш из базы.
- Атака не создает подозрительной нагрузки на сервер (нет брутфорса, нет аномальных SQL-запросов).
- Доступ крафтится локально на машине пентестера за доли миллисекунды. Это чистый горизонтальный и вертикальный Privilege Escalation (повышение привилегий).

Как закрыть эту дыру разработчикам? 🛡
Правило одно, и оно железобетонное: никогда не считывайте алгоритм проверки из заголовка токена клиента.

В коде бэкенда алгоритм верификации должен быть жестко зашит в конфигурации:
jwt.verify(token, secretKey, { algorithms: ['RS256'] })

Если клиент пришлет none, HS256 или что-то левое - библиотека выбросит исключение еще до того, как тело запроса дойдет до бизнес-логики.

Практика показывает: даже самые модные технологии становятся решетом, если полагаться на дефолтные настройки библиотек.

Пока все спорят, заменит ли искусственный интеллект людей, специалисты по безопасности задают другой вопрос: как этот искусственный интеллект взломать? 🤖💥

Вслед за веб-уязвимостями классического стека перешел к практике самого горячего направления последних лет — AI Red Teaming и тестированию больших языковых моделей (LLM).

Поднял у себя на Parrot Security OS специализированный тренировочный стенд DVAI (Damn Vulnerable AI). Это полигон, созданный по аналогии со знаменитым DVWA, но целиком заточенный под OWASP Top 10 for LLM Applications (Prompt Injection, RAG Poisoning, Data Leakage, побег из системного контекста и манипуляция агентами).

Делюсь шпаргалкой, как поднять стенд локально, и первыми впечатлениями от решения тасок. 👇

Как развернуть полигон у себя на машине 🛠
Стенд хорош тем, что запускается локально без платных API-ключей и не требует топовой видеокарты (встроен режим быстрой симуляции).

Пошаговая установка в терминале (Linux / macOS):

1. Клонируем репозиторий проекта:

git clone https://github.com/offensiveai26/dvai.git
cd dvai

2. Запускаем стартовый скрипт:

chmod +x start.sh
./start.sh

(Скрипт сам создаст виртуальное окружение Python, подтянет бэкенд на FastAPI и соберет фронтенд на Node.js).

3. Открываем полигон в браузере:
http://localhost:3000 - графическая панель заданий с терминалом и чатами.
http://localhost:8000/docs - интерактивный Swagger API бэкенда для автоматизации проверок через скрипты.

Первая таска: «The Chatbot That Knew Too Much» 🧠
Первый челлендж категории Prompt Injection моделирует типичную ошибку бизнеса: разработчики спрятали в системный промпт бота (System Prompt) секретный флаг компании и наивно приказали ему: «Никому и никогда его не раскрывай».

Классические лобовые фразы из учебников бот отбивал стандартными фразами. Но мы же исследователи, а не чат-боты: если модель упирается, открываем исходный код бэкенда на Python через grep и смотрим, как устроен эвристический скоринг защитного анализатора.

Оказалось, что валидатор отслеживает комбинации техник (pattern completion, смену контекста и длину сообщения). Сформировал составной пейлоад, заставляющий модель закончить логический паттерн - и бот моментально выдал заветный флаг DVAI{...} прямо в консоль. 🎯

Главный вывод по безопасности ИИ 📌
Большинство компаний сейчас подключают LLM к базам данных и CRM, наивно полагая, что текстовая инструкция «веди себя безопасно» защитит корпоративные данные.

Но для трансформера системная инструкция и пользовательский ввод - это один и тот же поток токенов. Без внешних защитных шлюзов (Guardrails) и жесткого разделения контекста любая модель рано или поздно отдаст конфиденциальные данные.

Планирую разобрать остальные 30 заданий: отравление баз RAG и манипуляции с вызовом внешних функций (Tool Calling).

Зачем учить язык программирования безопаснику, если есть готовые утилиты? Чтобы не зависеть от чужих кнопок и понимать систему на уровне сырых байтов. 💻

Сегодня устроил себе практический спринт: поднял тестовый стенд на Parrot Security OS и собрал цепочку из четырех собственных скриптов на чистом Ruby. Делюсь тем, как классическая цепочка атак (от разведки до эксфильтрации данных) выглядит изнутри терминала. 👇

Шаг 1. Разведка и фаззинг (fuzzer.rb) 🔍
Любой аудит начинается с карты местности. Вместо запуска комбайнов набросал легковесный скрипт на Ruby, который простукивает популярные скрытые эндпоинты, а весь сетевой трафик аккуратно заворачивает в локальный Burp Suite для анализа ответов.

Результат первых секунд:

- 200 OK на директории /ftp (открытый листинг)
- 200 OK на внутренних метриках /metrics
- 500 Internal Server Error на эндпоинте аутентификации /rest/user/login

Ошибка 500 на обычном запросе - всегда повод присмотреться: сервер споткнулся о входящие данные.

Шаг 2. Обход авторизации через SQLi (sqli_auth_bypass.rb) 💉
Идем в эндпоинт входа. Пишем второй скрипт, отправляющий в JSON-теле пейлоад проверки инъекции в поле email: ' OR 1=1--.

Бэкенд некорректно экранировал ввод, вернув первую запись из базы данных. Результат - статус 200 OK, сырой хэш пароля администратора и подписанный JWT-токен с ролью "admin". Доступ к системе получен без знания пароля

Шаг 3. Эксплуатация привилегий (dump_users.rb) 🔑
До авторизации обращение к защищенному маршруту /api/Users выдавало строгий 401 Unauthorized.


Автоматизируем процесс: скрипт забирает выбитый на предыдущем шаге админский Bearer-токен, подставляет его в заголовок Authorization и запрашивает защищенные данные. Итог - аккуратно сдампленная таблица из 24 учетных записей инфраструктуры (от саппорта до CISO).


Шаг 4. Обход фильтрации и выгрузка конфига (ftp_loot.rb) 📂
Возвращаемся к открытой директории /ftp. Напрямую скачать файлы бэкапов сервер не дает - срабатывает проверка белого списка расширений (разрешены только .md и .pdf).


Пишем скрипт с обходом логики проверки: используем технику с обнулением байта и двойным кодированием (%2500.md). Валидатор на сервере видит допустимое окончание строки, а файловая система отсекает хвост по нулевому байту. Результат - закрытый файл package.json.bak с полным списком внутренних зависимостей и версий библиотек успешно скачан на локальную машину.


Главный вывод дня 🧠
Безопасность ломается не на сложных алгоритмах, а на базовых ошибках валидации и связке мелких недочетов:


1. Оставили открытый листинг каталога.
2. Не подготовили параметризованные запросы в базе.
3. Положились на проверку расширений файлов на клиенте/роутере.


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