From vulnerability to exploit

Сначала авторизация — это механизм, а не оружие

Всё ниже — это теория того, как формируется эксплойт, изложенная так, чтобы защитник мог рассуждать, зачем существуют митигации и почему «низкоопасный» баг памяти всё равно может оказаться game-over. Здесь нет рабочего кода эксплойта, и его не должно быть: чтобы понять механизм, payload не нужен, и его нельзя наводить на систему, которой ты не владеешь или которую тебе явно не разрешили тестировать. Легитимные места, где можно реально наблюдать превращение бага в контроль, — это CTF-машина, намеренно уязвимая VM, развёрнутая тобой, или engagement в рамках письменной авторизации. В терминах MITRE ATT&CK то, что мы описываем, — превращение изъяна в способность выполнять выбранные атакующим инструкции — лежит на границе Initial Access и Execution, а плацдарм, который это покупает, — Persistence (TA0003): как только код запущен, следующая цель атакующего — добиться, чтобы он продолжал работать. Мы изучаем это, чтобы разорвать цепочку, а не выковать её.

Уязвимость — это потенциальная энергия; эксплойт — её высвобождение

Уязвимость — это свойство кода: где-то программа сделает не то с входными данными, которые не провалидировала. Эксплойт — это конкретный вход, превращающий это свойство в выбранное атакующим поведение. Это не одно и то же, и их смешение — самая частая ошибка джуна при оценке серьёзности. Переполнение буфера, которое только роняет процесс, — это баг отказа в обслуживании (DoS). То же самое переполнение, если оно может направить указатель инструкций, — это удалённое выполнение кода (RCE). Одна корневая причина, две радикально разные степени опасности — и какая из них у тебя, целиком зависит от того, чем управляет испорченная память.

Классический пример — переполнение буфера на стеке. Функция резервирует буфер фиксированного размера на стеке — скажем, 64 байта под имя пользователя. Прямо рядом с этим буфером, по соглашению о вызовах архитектуры, лежит сохранённый адрес возврата: место, куда CPU прыгнет, когда функция завершится. Если программа копирует вход в 64-байтовый буфер без проверки длины, вход длиннее 64 байт продолжает писать — за буфер, в соседние ячейки стека и в итоге поверх того сохранённого адреса возврата. CPU понятия не имеет, что что-то не так. Когда функция возвращается, он загружает то, что теперь лежит в этой ячейке, в указатель инструкций и прыгает туда. Если атакующий контролирует эти байты, атакующий контролирует, куда пойдёт исполнение дальше. В этом весь трюк: memory-safety — это то, что не даёт «данным, которые программа читает» и «адресам, которым программа доверяет» быть одними и теми же байтами, а баг memory-safety стирает эту стену.

Контроль над указателем необходим, но недостаточен

Владение указателем инструкций отвечает на вопрос куда идёт исполнение. Атакующему всё ещё нужно, чтобы там было нечто, на что стоит прыгать. Исторически ответ был простым и грубым: положи вредоносные инструкции (shellcode) в тот самый буфер, который ты только что переполнил, и направь адрес возврата обратно на буфер. Твои данные и есть твой код; стек — и то, и другое. Это работало, потому что на ранних системах стек был одновременно записываемым и исполняемым, а адреса предсказуемыми — буфер лежал на одном и том же месте при каждом запуске, так что можно было захардкодить, куда прыгать. Два предположения, и каждое из них следующие двадцать лет митигаций взялись уничтожить.

Это правильная ментальная модель для всей гонки вооружений в эксплуатации. Эксплойт — не одна вещь; это короткий список предусловий, которые все должны выполняться одновременно:

DEP и ASLR: две опоры, изменившие игру

DEP (Data Execution Prevention), также NX (no-execute), бьёт по предположению «твои данные — это твой код» напрямую. Страницы памяти получают флаг: записываемая или исполняемая, но не обе сразу. Стек и куча — где приземляется вход атакующего — помечаются неисполняемыми. Теперь, когда перехваченный указатель инструкций прыгает в буфер с shellcode, CPU падает с ошибкой: эти байты — данные, а данные не исполняются. DEP почти бесплатен (это аппаратный бит) и убил простейший класс эксплойтов наповал. Ответом атакующих стало return-oriented programming (ROP): вместо внедрения нового кода связывают воедино крошечные фрагменты собственного уже-исполняемого кода программы — короткие последовательности, заканчивающиеся инструкцией ret, называемые «гаджетами», — чтобы собрать нужное поведение из легитимных исполняемых кусков. ROP не нарушает DEP, потому что никогда не исполняет данные; он только запускает код, который уже был помечен исполняемым. Баг сдвинул стоимость эксплуатации, но не покончил с ней.

ASLR (Address Space Layout Randomization) бьёт по другому предположению: предсказуемым адресам. Каждый раз при загрузке программы ОС перемешивает, где живут стек, куча и библиотеки в памяти, — рандомизируя старшие биты их базовых адресов. ROP нужно знать точный адрес каждого гаджета; ASLR означает, что атакующий больше не знает, где что лежит. Захардкоженная цель прыжка, верная вчера, сегодня указывает на мусор, а неверная догадка роняет процесс вместо эксплуатации. Поэтому современным эксплойтам почти всегда нужна утечка информации как первая стадия: отдельный баг (или тот же баг, используемый для чтения, а не записи), раскрывающий один настоящий рантайм-адрес. Из этого единственного утёкшего адреса атакующий вычисляет базу и дерандомизирует весь модуль — ASLR рушится в тот миг, когда утекает один адрес. В этом глубокий урок: ASLR не делает эксплуатацию невозможной, он делает её требующей второго бага, а «нужно два бага, а не один» — это огромный практический рост сложности.

Почему это важно защитнику

Ты редко будешь писать эксплойт переполнения стека. Ты постоянно будешь принимать решения, зависящие от понимания этой цепочки. Когда зависимость выпускает CVE, описанную как «heap buffer overflow», вопрос, задающий твою срочность, — ровно тот, который тренирует этот урок: может ли эта порча дотянуться до потока управления или только роняет? Когда ты выбираешь язык, ты выбираешь, чья работа memory-safety — компилятора (Rust, Go, управляемые рантаймы ограничивают каждый доступ) или твоя (C и C++ доверяют тебе считать байты, и единственный просчёт — это вся история выше). Когда ты ужесточаешь сборку, флаги, включающие stack canary, DEP, ASLR и CFI, — не галочки: каждый удаляет конкретную опору из таблицы выше, и ценность «глубоко эшелонированной защиты» здесь буквальна: атакующему теперь приходится обойти несколько независимых механизмов за один заход, и промах по любому из них превращает его RCE обратно в падение.