Эксплуатация переполнения буфера в стеке с помощью перезаписи адреса возврата

Здравствуйте, уважаемые форумчане!
В данный момент занимаюсь исследованием такой темы как переполнение буфера и есть некоторые вопросы, на которые пока не могу найти ответы, надеюсь на вашу помощь.
Пробую все это дело я на ОС Windows (и на x32, и на x64). Попробовал я эксплуатировать уязвимость, как показано в данном видео:
1) Правильно ли я понимаю, что суть такова - мы переполняем буфер до тех пор, пока не перезапишем адрес возврата (у меня получилось 28 символов + шелл-код) . В нашей программе загружается динамическая библиотека, которая имеет всегда статический адрес (т.е. мы всегда будем его знать, в данном случае он 0x610C11DF - https://imgur.com/a/Vlk8l). После перезаписи return address'а на его месте у нас должен получится адрес этой библиотеки (после него идет шелл-код). В свою очередь эта библиотека содержит одну инструкцию - JMP ESP. ESP указывает на верхнюю часть следующего кадра стека, в нашем случае там размещается шелл-код. Т.е. выполнение программы переместится в начало следующего кадра стека и произойдет выполнение шелл-кода. Правильно ли я понял? Поправьте, пожалуйста, если не так.

2) Я пробовал на (приложение x32):
Win XP SP0 x32 / Win XP SP1 x64 - получилось
Win XP SP2 x64 / Win 7 SP1 x32 / Win 7 SP1 x64 /Win 8 x32/ Win 8.1 без SP x64 / Win 10 x64 - не получилось
На тех системах, где не вышло такая ситуация: при перезаписи адреса возврата я вместо нужного адреса библиотеки 0x610C11DF, я всегда получаю 0x610C113F (https://imgur.com/a/ZiB9O). Я так понял, это какой-то механизм защиты? Если да - то какой?

3) Поделитесь, пожалуйста, ссылками на эксплойты переполнения буфера на Windows x64, если вообще такие есть
Я нашел парочку, но не выше Win XP. Буду рад любым замечанием и предложениям. Спасибо за внимание.

 

Shemp,
1) видео не смотрел, но все верно
2) хз почему вы получаете невалидный адрес возврата, но точно могу сказать, что на 64 битных системах включен dep. Те вы не можете так просто взять и начать исполнение шелл-кода в стеке, ибо этот регион памяти не имеет прав на исполнение.
3) это вам ничего не даст(разве что цепочки собирать научитесь), механика везде одинаковая
посмотрите курс нарвахи/корелан тим/фази секьюрити или гуглите rop dep bypass

 

unc1e,

Спасибо за ответ!
Я сначала подумал о том, что это какой-то механизм защиты именно на x64 ОС. Но на win 7/8 x32 тоже самое - я получаю 0x610C113F. Причем пробовал в шелл-коде такие комбинации:
00110C61 - 00610C11
01110C61 - 610C1101
55110C61 - 610C1155
77110C61 - 610C1177
88110C61 - 610C113F
99110C61 - 610C113F
AA110C61 - 610C113F
DF110C61 - 610C113F
Причину появления "3" вместо "D" пока не знаю.

Про курс Нарвахи знаю, пока не изучал.
Про Fuzzysecurity и корелан тим тоже знаю (причем благодаря этому форуму), но там эксплойты не выше Win XP.

 

Shemp,

Эти примеры просто обучалки, показывающие общие принципы. Это не боевые" эксплойты. Механизмы защиты довольно масштабные, они действуют на разных уровнях - от простых проверок, до ядерных/аппаратных. Это принципиально не будет работать, а конкретно почему не суть важно.

> На тех системах, где не вышло такая ситуация: при перезаписи адреса возврата я вместо нужного адреса

Я не знаю системных механизмов, которые изменяют адреса возврата на стеке. Система их проверяет разными путями, но не изменяет. Это делают только сторонние защитные апп, типо EMET или AV. Это однозначно какая то ошибка у вас. Тем более что разница 0x11DF и 113F битовая, а запись всегда байтовая. Даже если бы значение переписывалось защитным механизмом, то это было бы совсем иное значение(указатель в другую область памяти). Как минимум значение адреса возврата может изменяться на страничное выравнивание, те. младшее значение смещения неизменно. Что бы биты изменить нужно либо использовать битовые операции, либо прочитать-изменить-записать значение. У вас код использует это ?

 

Indy_,

А можно ли найти примеры боевых эксплойтов? Хотя бы на Win7 x64 SP1. Я уже долго ищу это, но ни литературы, ни туториалов об этом почти нигде нет. Хотелось бы исследовать обход хотя бы некоторых механизмов защиты на x64.

В том то и проблема - я не знаю, где я ошибаюсь. Вроде как делаю все также, как и видео выше (например, сравнение Win XP SP1 и SP2 x64):
1)Определяю количество символов, которое необходимо для краша программы при переполнении буфера. В обоих случаях количество символов больше 28.
2)Адрес библиотеки 610C11DF, в блокноте выполняю реверс порядка байтов (обратный порядок хранения): DF110C61. Далее к этой записи добавляется шелл-код.
3)С помощью онлайн-конвертора выполняю преобразование из HEX в ASCII:

https://imgur.com/CBK7V9t
4)Добавляю в аргумент отладчика 28 символов + полученный выше аргумент. Ставлю точку остановки отладки на функции strcpy
Как выглядит для SP1:
https://imgur.com/mrSgw3A
SP2:
https://imgur.com/JGNh99D
Я не знаю правильно ли это, но уже видны различия в аргументах. Это нормально? Может дело в кодировке?
5)Состояние стека перед перезаписью адреса возврата (28 символов уже введены):
SP1:
https://imgur.com/RqyB2lM
SP2:
https://imgur.com/LUb56iV
6)Перезапись return address'а:
SP1:
https://imgur.com/1lkNswl
SP2:
https://imgur.com/MAPTjtW

Вроде все расписал. Где может быть ошибка? Делаю все идентично. Также наверно стоит упомянуть, что тестирую я это все на виртуалках. Не знаю важно ли это, но мало ли.

 

скорей всего ты промахиваешься с адресом возврата == функа вылетает в сегфолт и подхватывается сехом.

 

Shemp,

> А можно ли найти примеры боевых эксплойтов?

Это нужно спросить на чёрных площадках. Я этим не интересуюсь, так что не могу сказать.

> В том то и проблема - я не знаю, где я ошибаюсь.

Ваше описание выше не информативно. Это значит что инфы не достаточно что бы разобраться. Две копии стека с изменённым указателем - ничего не означает. Есчо до передачи управления может быть валидация, но у них у всех штатный путь обработки - поднимается исключение. Это нужно отладчиком прогнать и выяснить что происходит. Если вы не можите в этом разобраться, то получается вообще не ориентируетесь в отладчике. Думаю следует потренироваться на чём то попроще, чем видеокурсы, обычные апп подебажить или крякми/протекторы. Что бы для начала узнать как минимум инструмент(отладчик)

 

Indy_, да, Вы правы, в отладчике я не силен. Благо курс от Нарвахи немного помог мне разобраться

Наконец у меня получилось найти корень проблемы. И как бы это смешно и глупо не было, но как есть. Насколько я понял, моя проблема состоит в кодировке. Искал долго, сравнивал, и решил этот адрес библиотеки 610C113D передать в аргументы отладчика (просто посмотреть как он будет выглядеть в стеке). Конвертировал с помощью онлайн-конвертора из шестнадцатеричного представления в ASCII, получил "ßa" (возможно не отобразится полностью). Передаю в аргументы отладчика и на кое-что обратил внимание (раньше тоже замечал, но не предавал этому значения) на Windows XP SP1 и SP0 эти символы выглядели корректно, а вот уже, например, на Windows XP SP2 выглядело вот так "?a". И опять получаю в стеке на SP1 610C113D, на SP2 610C113F. Учитывая порядок байтов Little-endian нас интересуют именно символы "ß" и "?". И действительно - символ "?" в hex имеет вид 3F, а символ "ß" - DF. Попробовал проверить на своей машине (у меня Win7), опять "?" и опять 3F. Заглянул в таблицу ASCII, а там для hex DF есть еще одно представление в виде символа "Я" Попробовал на свой прогнать с "Яa" - вышло.

Если судить по таблице, представление с "Я" это Win1252, "ß" это Win1251. Что делать, если оба символа представляются как "?" В настройках ОС вроде автоматически стоит поддержка и 1251, и 1252

 

шрифты поставь и все символы будут отображаться корректно.

 

С Win1252 разобрался - в настройках языка необходимо поставить было русский язык для не-Юникод программ. А вот для Win1251 все также.

 

на любых шрифтах?

 

Немного не понял Вашего вопроса. Как шрифты могут повлиять? И я ошибся в предыдущих сообщениях - русские символы в 1251, извиняюсь.
К сожалению, все онлайн-конвертеры преобразуют hex в ASCII с расширенными символами Win1252. В настройках системы (панель управления - язык - настройка отображения текста программами, не поддерживающими Юникод) я выбрал Englist (United States). Через буфер обмена, просто вставляю получившуюся последовательность ASCII символов в отладчик. И все равно в отладчике символы "?". Но в командной строке, например, символы стали отображаться корректно.
Я вручную преобразовал из hex в ASCII на Win1251 (с расширенными русскими символами), скопировав в отладчик он автоматически перевел это на Win1252. Все хорошо, но только теперь командная строка выводит символы "?"

 

есть кодировка, а есть шрифт (выводящий символы с заданным кодом). встречаются случаи, когда в шрифте попросту непрописаны некоторые символы. попробуй в отладчике прописать либо нужную кодировку, либо нужный шрифт. и будет усё отображаться.
ЗЫ.. какой отладчик используешь?

 

Использую Immunity Debugger (в Olly та же шляпа), только что установил на вм Win XP SP3 (EN), там все отлично - что в отладчике, что в ком. строке.

 

Вот что еще интересно - товарищ unc1e выше писал, что x64 системах включен DEP. Насколько я понял, он может быть включен и на x32 битных системах, посредством использования ядром PAE (Physical Address Extension, расширение физического адреса). PAE автоматически включается, если включен DEP. Только что на Win XP SP3 x32 проверил эксплойт переполнения буфера - все работает. Странно, на SP3 DEP уже есть. Посмотрел через Свойства компьютера-Рекомендованные-Быстродействие-DEP, стояла отметка только для служебных программ Windows, на всякий случай поставил для всех. Эксплойт все равно работает (хотя в теории не должен). Засомневался, проверил через boot.ini: /NoExecute=OptOut - все верно. И нашел одну статью для проверки DEP через Тестер инструментария управления Windows (https://support.microsoft.com/ru-ru...dware-dep-is-available-and-configured-on-your). А вот там уже информация о том, что DEP отключен: https://imgur.com/a/8Zl102H
В чем причина разной информации о DEP? Может быть потому, что в одном случае речь идет о программной DEP, а в другом об аппаратном? (на всякий случай проверил - мой процессор поддерживает NX-бит). И может это все быть из-за того, что тестирование ведется на ВМ?

 

Shemp, скорей всего это просто особенность твоей пиратки иль настройки вм надо смотреть.

 

А разве это не должно сломать стек на столько, что процесс выйдет в исключение ? Или это зависит от соглашения вызова ф-ции в которое эксплуатируется переполнение?

 

запись в стек может сломать функу, куда втиснули малварь-строку == к примеру, может затереться некий указатель (размещённый в стеке) и функа, при попытке обратиться по этому адресу, улетит в сегфолт вместе со всем заражённым процессом.

 

x86 уже таки облупленный, и хвала индусам придумавшими байткод, со своими виртуальными правилами. Это просто вопрос к спецам на правах оффтопа)))

 

Ты считаешь х86 устарел? вообще, дырки с переполнением буфера обычно кладут процесс железно и фактически реально пашут лишь "дизайнерские" бэкдоры.. всё остальное годно только для тупого дидоса