Как найти 0day-уязвимость? Пошаговый гайд

Йо, пентестеры и баг-хантеры! Вам надоели скучные отчёты с CVSS 3.2? Хотите найти свой собственный 0day, который превратит вас из «ещё одного хакера» в легенду? Тогда садись поудобнее — щас расскажу, как это делается на реальных проектах, а не в вакууме CTF.

Что такое 0day и почему все за ним охотятся
0day — это как найти биткоин-кошелёк на 10 лямов: вендор не знает, патча нет, защита спит. Это твой личный ключ к любой системе, пока мир не проснулся. Но чтобы его найти, нужно думать как разраб, который накосячил, и как атакующий, который видит этот косяк.

Шаг 1: Выбери цель (и не еби мозги)
Не лезь сразу в Chrome или OpenSSL — там армии исследователей уже всё перерыли. Начни с:
• Нишевого софта (корпоративные CMS, специализированные IoT-устройства)
• Open-source проектов с маленькими комьюнити (меньше глаз = больше багов)
• Web-фреймворков для специфичных языков (Ruby, Go, Rust — там ещё не всё затоптано)
Лайфхак: ищи софт, который активно развивается, но не имеет огромной базы юзеров. Там баги плодятся как кролики

Шаг 2: Читай код как порно (внимательно и с наслаждением)
Скачай исходники. Открой IDE. И начинай:
• Grep по ключевым словам: eval(), exec(), system(), unserialize(), innerHTML, dangerouslySetInnerHTML
• Ищи кастомные парсеры: XML, JSON, YAML — если разраб писал свой парсер, он 100% накосячил
• Проверяй input validation: где user-input попадает в SQL, OS commands, file paths
Команда дня:

grep -rn "exec\|system\|eval" ./src/

Ищи места, где нет санитизации. Это как открытая дверь с табличкой «Welcome, hacker!»

Шаг 3: Фаззинг — твой лучший друг
Автоматизация — это не для ленивых, это для умных. Используй:
• AFL++ / libFuzzer для нативных бинарников
• Burp Intruder / ffuf для веба
• Radamsa для протоколов
Пример фаззинга API:

ffuf -u https://target.com/api/FUZZ -w wordlist.txt -mc 200,500 -o results.txt

Крэши, segfaults, unexpected behavior — это твои золотые билеты. Каждый крэш = потенциальный 0day.

Шаг 4: Думай нестандартно (или как говорят в CTF — «outside the box»)
Race conditions: два запроса одновременно могут сломать логику

Type confusion: отправь строку вместо числа, объект вместо массива


Logic bugs: не все баги — это переполнение буфера; иногда это просто тупая логика разраба

Шаг 5: Эксплойт или не трогай (proof-of-concept обязателен)
Нашёл баг? Молодец. Теперь докажи, что он реальный:
• Напиши PoC-скрипт (Python, Bash — без разницы)
• Покажи impact: RCE? Доступ к БД? Утечка данных?
• Задокументируй всё: шаги, payload, скриншоты
Пример payload для SQLi:

' OR '1'='1' --
admin' UNION SELECT NULL, password FROM users --

Если можешь забрать /etc/passwd или дампить базу — это уже не просто баг, это 0day-охуенность.

Шаг 6: Responsible Disclosure (или продай на darknet, но я этого не говорил)
Варианты:
• Bug bounty программы (Standoff365, BI.Zone) — легально, деньги + репутация
• Прямой контакт с вендором — иногда платят больше, чем bounty
• CVE ID — добавь в резюме, выглядишь как бог
Важно: не публикуй 0day до патча. Иначе армия скрипт-киддисов сломает весь интернет, а виноватым будешь ты.

Инструменты, без которых ты — никто
• Burp Suite Pro — если не используешь, мы не друзья
• IDA Pro / Ghidra — реверс-инжиниринг бинарников
• AFL++ — фаззинг на стероидах
• Nuclei — автоматический поиск CVE и misconfiguration
• Git — да, обычный git. Через git log можно найти баги, которые разрабы “исправили”, но на самом деле нет

Финальный совет: будь упорным ублюдком
Поиск 0day — это не спринт, это марафон. Ты будешь читать тысячи строк кода, запускать сотни тестов, получать false positives. Но когда найдёшь — это оргазм 🎉
И помни: каждый патч — это подсказка. Читай changelog’и, смотри на коммиты в GitHub. Часто разрабы “фиксят” один баг, а создают три новых.
Мантра дня: “Если код может сломаться — он сломается. Твоя задача — найти как.”