«Разбор полёта: не оправдание, а карта маршрута. Откуда взялось “холодное железо”, где лежит код и почему CVSS 8.3 — это не про копейку»

Салют, честная ИТ‑публика! Дед на печи, пчёлы жужжат, но сегодня без мёда на клавиатуре. Сегодня — только код, ссылки и факты.

Меня много ругали за фразу «холодное железо» и за пробелы в коде. И знаете, я благодарен. Потому что вы заставили меня вытащить из закромов то, что обычно лежит только на GitHub и в приватных репортах. Сейчас покажу, откуда всё это взялось, как это работает и почему это вообще не про «дед не шарит в CPU», а про конкретный паттерн маскировки нагрузки.

Фраза «холодное железо» — это не моя личная поэтическая вольность. Это устоявшийся инженерный сленг, который встречается в PoC‑репозиториях, в том числе в проекте «Шмель‑63» на GitHub (ищите ssmel63). Там этот термин используют для описания паттерна, при котором система под нагрузкой не выдаёт себя метриками.

Что значит «холодное» в этом контексте:

То есть «холодное железо» = «нагрузка есть, но телеметрия её не видит». Это не ошибка в понимании физики процессора. Это описание архитектуры, которая специально спроектирована так, чтобы не напрягать железо и не триггерить алерты.

Ссылка на репозиторий: github.com/ssmel63/shmel-63. В README и комментариях к коммитам как раз разбирается этот паттерн маскировки трафика. Если хотите спорить — спорьте с кодом в репозитории, а не со мной. Это самый честный способ: открываете, смотрите, проверяете.

Знаете, это как с ульем: снаружи тихо, спокойно, ни одна пчела не бьётся в стекло. А внутри — бурление, перенос нектара, вентиляция, всё работает. Вот и тут: снаружи система «холодная», а внутри — поток операций. Именно эта тишина и опасна: её не видит мониторинг.

Да, в статьях на vc.ru были EXECUTEIMMEDIATE и source_account = > p_from. И да, это ошибки. Но это ошибки публикации, а не разработки.

Как это происходит:

Это классическая проблема переноса кода из IDE в блог. Любой, кто хоть раз копировал сниппет в статью, знает эту боль.

Иногда мне кажется, что Markdown — это такой маленький вредитель, который живёт в редакторе и специально съедает стрелки =>, когда ты смотришь в другую сторону. И самое обидное: он делает это не из‑за бага, а будто из принципа: «Мы тут за чистоту строк, дед, не ворчи».

И вот тут — самый сильный аргумент против теории «это ИИ»: ИИ не делает таких ошибок. ИИ всегда выдаёт синтаксически чистый код. А человек, который копирует код из своей рабочей среды в публичный блог, сталкивается с тем, что редактор «съедает» форматирование. Именно эти ошибки — лучшее доказательство того, что я публикую реальный рабочий код, а не генерирую текст в чате.

Про Markdown у меня вообще отдельная история. Он как тот самый джун, который на код‑ревью говорит: «А давай уберём все пробелы, чтобы было компактнее». Я ему: «Стой, это же EXECUTE IMMEDIATE, а не EXECUTEIMMEDIATE!» А он в ответ: «У нас тут лимит символов в строке, дед, не ворчи». В итоге я сдался. Пусть будет слитно. Зато статья влезла в лимит символов, и пчёлы довольны — я не сидел до трёх ночи, пытаясь победить вёрстку.

Я не ставил себе 8.3. Эту оценку выставила команда триажа BI.ZONE после воспроизведения моего PoC.

Мой PoC был на 1 копейку. Это стандартная практика в bug bounty: PoC должен доказать возможность обхода контроля, а не размер ущерба. Если я могу провести транзакцию на 1 копейку без верификации ЕСИА, значит, механизм верификации не работает. Точка.

BI.ZONE оценили вектор атаки как High (8.3) именно потому, что:

Банк пытался снизить оценку — это нормальный процесс. Но факт остаётся фактом: независимая экспертиза платформы подтвердила критичность вектора.

Если вы считаете, что 8.3 — это ошибка, вы должны спорить не со мной, а с методологией CVSS v3.0 и командой триажа BI.ZONE. Это переводит дискуссию из плоскости «Дед дурак» в плоскость «Давайте разберём CVSS».

Меня спрашивали: «Где реальные запросы, где токены?» Ребята, я не могу публиковать эндпоинты, токены и полные заголовки в открытом блоге. Это нарушение правил bug bounty и NDA.

Реальный PoC с конкретными адресами и токенами лежит на платформе BI.ZONE и доступен только мне и триажерам. В статье я даю паттерн — логику работы уязвимости. Это как дать повару не сам трюфель, а рецепт, как его искать. Трюфель — на платформе, рецепт — тут. Надеюсь, аналогия зашла.

Пчёлы не любят, когда кто‑то сливает координаты медоноса. Так и тут: пока баг не закрыт, координаты эндпоинта — это святое. Поэтому в статье только паттерн.

Посмотрите публичные writeup‑ы на HackerOne после закрытия багов — там тоже нет реальных эндпоинтов. Это стандарт индустрии.

Да, стиль у меня яркий: «эшелонированный залп», «гиперзвуковой поток». Но я делаю это осознанно. Если я напишу сухо: «Запустил цикл FOR i IN 1..1000000 LOOP», половина читателей уснёт на второй строке. А мне нужно, чтобы статью дочитали до конца, чтобы банк заметил баг, а не чтобы меня похвалили за лаконичность.

Да, я люблю громкие слова. Но это не потому, что мне нравится звучать как герой боевика. Просто если я напишу «система обрабатывает запросы», половина читателей закроет вкладку на третьей строке. А если я скажу «эшелонированный залп транзакций», они хотя бы дочитают до того места, где я объясняю, почему это важно.

Это как кричать «Пожар!» вместо «Наблюдается незначительное повышение температуры в отсеке №5». Смысл один, а эффект разный. Пусть лучше ругают за пафос, чем пропускают суть.

Если хотите проверить факты — вот прямые точки входа:

А если хочется проверить воспроизводимость паттерна — его можно развернуть на тестовой среде с Oracle и DBMS_AQ: сделать входной шлюз, который только ставит задачу в очередь, и асинхронный воркер, который её выполняет. Вы увидите тот самый эффект «холодного железа»: нагрузка есть, но CPU и очереди выглядят спокойными. В репозитории shmel-63 есть минимальный пример, который можно поднять за 15 минут. Это не магия, это архитектура.

Если вы хотите спорить — давайте спорить про архитектуру: про DBMS_AQ, про маскировку трафика, про методологию CVSS. А про пробелы в коде — давайте больше не будем.

Пойду к пчёлам. Они не спрашивают про CVSS, не ругаются за пафос и не ломают форматирование кода. Они просто делают мёд. А я буду делать статьи, но теперь буду внимательнее проверять код перед публикацией. Хотя нет, то буду проверять, то не буду)) Интерестно же смотреть как шершни попадают в медовую ловушку)