Реверсинжиниринг PWN-тасков или эксплуатируем бинарные уязвимости (Часть 4 / Stack3)
Всем доброго времени суток! Набираем обороты… Сегодня мы будем 'пывнить» stack3.exe (ссылочка на файл, как обычно, на Github).
Stack3
Закидываем в Ghidra:
Анализируем…
Получаем декомпилированный код. Нас встречает все тот же массив из 64-х байт. Небезопасная функция gets (). Функция gets () считывает строку символов из стандартного потока ввода (stdin) и помещает ее в массив local_54. Также в коде есть указатель (local_14) на функцию и проверка (if), не является ли local_14 — NULL.Т. е. если мы «перезапишем» local_14, то попадем в ветку THEN и получим сообщение «calling function pointer, jumping to…», а также перейдем по адресу, которым мы перезапишем local_14:
Вроде бы все понятно, но есть ощущение, что чего-то нехватает? :)
Обращаем внимание на функцию «win»:
Функция «win» просто выводит сообщение «code flow successfully changed»:
Фактически, нам нужно использовать BOF, чтобы изменить значение указателя функции, сделав так, чтобы он указывал на адрес функции «win» (это и будет успешным прохождением таска «Stack3»).
Переходим к «динамике». Делаем поиск по strings:
Кликаем по строчке с «code flow successfully changed» и смотрим адрес инструкции «push ebp» (З.Ы. Это начало функции «win». Кому интересно, почему так, читайте про пролог/эпилог процедуры):
Супер! Адрес есть. Давайте посмотрим на наш «пейлоад», который мы подадим на стандартный поток ввода (stdin):
64 байта «A» + адрес инструкции «push ebp» в LE
Эксплуатируем. Указатель изменён и мы попали в функцию «win» (о чем говорит сообщение «code flow successfully changed»):
Всем спасибо за внимание! Если понравилась статья, буду рад «пальцу вверх»!
