Секреты покорения эльфов

Если загрузить исполняемый файл в hex-редактор, мы увидим цифры. Много цифр. Можно нажать на ноль, наслаждаясь, как машинный код стирается под натиском нашей силы, но... это слишком просто и неинтересно. Лучше собраться с умом и дописать несколько осмысленных ассемблерных строк! В этой статье говорится о том, как устроены ELF-файлы, как они загружаются в память, и как хакеры внедряют в них свои имплантанты.

[введение]

Ворвавшись в нашу жизнь, Linux прочно обосновался на операционной арене, и все чаще и чаще на компакт-дисках гламурных журналов оказываются программы для этой оси. Причем, в отличие от Windows, большинство линуксовых приложений не требует установки и спокойно копируется с одного компьютера на другой, что способствует интенсивному обмену файлами. Помнишь MS-DOS? Какие там дистрибутивы! Наше поколение таких слов тогда вообще не знало!

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

Есть и другая проблема. Линуховые программисты не заморачиваются с интерактивными конфигураторами и серьезно злоупотребляют «дефайнами» - директивами условной компиляции. Например, для однопроцессорной машины создается одна сборка, для двух- или четырехпроцессорной - другая. Таких опций может быть очень много и выложить все разновидности сборок на официальный сайт просто нереально. А компилировать самостоятельно - лень. Вот и приходится рыскать по сети в поисках готовых сборок, откомпилированных независимыми разработчиками, и качать их. При этом возникает естественная угроза нарваться на вирус, закладку или троян, и такие происшествия уже случались!

Доработать исходные тексты проще всего, но что делать, если есть только исполняемый файл и больше ничего? Берем hex-редактор и в самых ответственных местах правим yes на no - пускай юзеры потом удивляются! А еще круче внедрить «часовой механизм», который в определенный момент выведет приветственное сообщение на экран или выполнит некоторое событие. Вот об этом мы сейчас и поговорим.

[анатомия эльфов и их репродуктивные возможности]

Изначально *nix поддерживали множество исполняемых форматов, ожесточенно конкурирующих между собой, но теперь поле боя опустело, и среди дымящихся обломков минувших сражений остался один ELF, ставший стандартом де-факто для Linux и BSD. Кое-где еще встречается древний a.out, но на него можно не обращать внимания.

За ELF-header'ом следует таблица сегментов (program header table), перечисляющая имеющиеся сегменты и их атрибуты. В формате линковки она необязательна. Линкер не обращает внимания на сегменты, так как работает исключительно на уровне секций. Напротив, системный загрузчик, загружающий исполняемый ELF-файл в память, игнорирует секции и оперирует целыми сегментами.

Сегменты и секции - что это такое? Сегмент - это непрерывная область адресного пространства со своими атрибутами доступа. В частности, сегмент кода имеет атрибут исполнения, а сегмент данных - атрибуты чтения и записи. Не стоит путать ELF-сегменты с сегментами x86 процессора! В защищенном режиме 386+ никаких «сегментов» в изначальном смысле этого слова уже нет, а есть только селекторы, и все сегменты ELF-файла загружаются в единый 4 Гбайтовый x86-сегмент! В зависимости от типа сегмента величина выравнивания в памяти может варьировать от 4h до 1000h байт (размер страницы на x86). В самом ELF-файле они хранятся в невыровненном виде, плотно прижатые друг к другу. Так что со свободным пространством для внедрения сплошные напряги.

Ближайший аналог ELF-сегментов - PE-секции, но в PE-файлах секция - это наименьшая структурная единица, а вот в ELF-файлах сегмент может быть разбит на один или несколько фрагментов - секций. В частности, типичный кодовый сегмент состоит из секций .init (процедуры инициализации), .plt (секция связок), .text (основой код программы) и .finit (процедуры финализации). Секции нужны линкеру для комбинирования, чтобы он мог отобрать секции с похожими атрибутами и оптимальным образом растасовать их по сегментам при сборке файла, то есть «скомбинировать».

Несмотря на то, что системный загрузчик игнорирует таблицу секций, линкер все-таки помещает ее копию в исполняемый файл. Место тратится совсем немного, зато отладчикам и дизассемблерам так приятнее. По не совсем понятным причинам gdb и многие другие программы отказываются загружать файл с поврежденной или отсутствующей таблицей секций, чем часто пользуются для защиты программ от постороннего вмешательства.

Структуру и назначение полей служебных заголовков здесь разбирать не будем. Этим займется hex-редактор, и нам эти подробности не понадобятся. Интересующиеся могут обратиться к файлу /usr/include/elf.h - там все подробно расписано.

Лучше сосредоточимся на загрузке файла в память. По умолчанию ELF-заголовок находится по адресу 8048000h. Это и есть базовый адрес загрузки. На стадии линковки он может быть свободно изменен на другой, но большинство программистов оставляют его «как есть». Все сегменты проецируются в память в соответствии с виртуальными адресами, прописанными в таблице сегментов, причем, виртуальная проекция образа всегда непрерывна, и между сегментами не должно быть незаполненных «дыр».

Для вызова функций типа открытия файла можно обратиться либо к библиотеке libc, либо непосредственно к самой операционной системе. Первый вариант - самый громоздкий, самый переносимый и наименее приметный. Последний - прост в реализации, но при первом же взгляде на дизассемблерный листинг тут же бросается в глаза (правильные программы INT 80h не вызывают!), к тому же он испытывает проблемы совместимости с различными версиями Linux. Вот она - расплата за простоту!

Последний гигабайт адресного пространства (от адреса C0000000h и выше) занимают код и данные операционной системы, к которым мы будем обращаться только посредством прерывания INT 80h или через разделяемые библиотеки.

Стек находится в нижних адресах. Он начинается с базового адреса загрузки и «растет вверх» по направлению к нулевым адресам. В большинстве линуксов стек исполняем (то есть сюда можно скопировать машинный код и передать на него управление), однако некоторые параноидальные администраторы устанавливают заплатки, отнимающие у стека атрибут исполняемости, но большой распространенности они не получили, и ими можно пренебречь.

[имплантация чужеродного кода в ELF-файл]

Для экспериментов по имплантации нам потребуется живой исполняемый файл, который при помощи компилятора и текстового редактора мы сможем изготовить и самостоятельно. Нажмем <Shift-F4> в Midnight Commander'е, наберем программу следующего содержания (см. листинг), затем <F2>/"имя-файла.c" и откомпилируем ее своим любимым gcc с настройками по умолчанию (gcc имя-файла.c -o имя-файла).

Демонстрационная программа, в которую мы будем внедрять посторонний код

#include <stdio.h>

main()

{

printf("LORDI - the best group in the world!\n"\

"(www.lordi.org)\nmonsters, bondage and sado-maso\n");

}

Образовавшийся файл загрузим в hex-редактор (./ht-0.7.5-linux-i386 имя-файла), а затем нажмем <F6> (mode) и выберем elf/image. Редактор перейдет в режим отображения образа исполняемого файла, автоматически перенося нас в окрестности точки входа, отмеченной меткой entrypoint. Если этого не произойдет, нажмем <F5> (goto) и введем entrypoint (без кавычек). Экран должен выглядеть приблизительно так:

Измененные байты редактор выделят красным цветом, что наглядно и очень красиво, но при нажатии на <F2> (save) они вновь зеленеют, подтверждая, что все исправления успешно сохранены. Полей контрольной суммы в ELF-заголовке нет, и потому заботиться о ее пересчете не нужно. Линух контрольную сумму файла не считает! А не считает он ее потому, что проектировался головой. Это же не Windows! Такое впечатление, что PE-файл проектировала толпа народу, с трудом взаимодействующая между собой. Суди сам: и Линух, и Windows поддерживают механизм отложенной загрузки по требованию. Страницы образа проецируются в память тогда и только тогда, когда к ним происходит обращение, в результате чего немедленно после запуска файл готов к работе, а все недостающие страницы дозагружаются уже потом (или не загружаются вообще, например, часть программы, ответственная за печать, вообще не будет загружена, если ни разу не был выбран пункт print). Процесс загрузки как бы «размазывается» во времени, не нервируя никакими песочными часами, которые так любит демонстрировать Windows. Но! Ведь при подсчете контрольной суммы происходит неизбежное обращение ко всем страницам, и все они загружаются в память, даже если не нужны. Получается, что у нас есть два механизма - один оптимизирует загрузку, другой ее «пессимизирует», съедая весь выигрыш. Где логика?!

А вот разработчики Линуха переложили подсчет контрольной суммы на устройства ввода/вывода, которые ее действительно считают. Конечно, это не страхует от искажений. В частности, жесткие диски контролируют только физические дефекты, но не обращают внимания на логические искажения (вирусы). Тем не менее, особого смысла в контрольной сумме, хранящейся непосредственно в самой файле, все равно нет. Если вирус может модифицировать файл, он модифицирует и контрольную сумму. По науке, контрольные суммы нужно хранить в отдельном «защищенном хранилище», и их подсчетом должна заниматься файловая система или антивирусные ревизоры. Ни того, ни другого в мире Линуха не наблюдается. Хотя они как бы есть, но ни у кого реально не установлены.

Единственную проблему представляют протекторы и упаковщики исполняемых файлов, контролирующие собственную целостность. С каждым годом их становится все больше и больше. UPX, протектор от shiv'ы... В них на первых порах лучше не внедряться!

Но мы отвлеклись. Выходим из hex-редактора, нажав <F10>, и запускаем пропатченный файл. Он запускается, подтверждая свою работоспособность. Значит, модификация прошла успешно!

Но все не так плохо, как кажется! По умолчанию gcc выравнивает стартовые адреса функций по границе 10h, а это значит, что даже наш демонстрационный файл содержит просто кучу свободного пространства. В среднем 10h/2h = 8h байт на каждую функцию, включая служебные. Сюда и мамонта упрятать можно, если, конечно, его предварительно расчленить.

Цепочка команд NOP, оставленная компилятором в конце функции main для выравнивания

....... ! main: ;xref o80482d7

....... ! push ebp

8048385 ! mov ebp, esp

8048387 ! sub esp, 8

804838a ! and esp, 0fffffff0h

804838d ! mov eax, 0

8048392 ! sub esp, eax

8048394 ! mov dword ptr [esp], strz_LORDI___the_best_group_in_the_80484e0

804839b ! call wrapper_8049634_80482b0

80483a0 ! leave

80483a1 ! ret

80483a2 nop

.......

80483ac nop

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

STDIN-буфер, расположенный в сегменте данных

80484c2 db 00h ; ' '

80484c3 db 00h ; ' '

80484c4

....... ;********************************************************

....... ; data object _IO_stdin_used, size 4 (global)

....... ;********************************************************

....... _IO_stdin_used:

....... db 01h ; ' '

80484c5 db 00h ; ' '

80484c6 db 02h ; ' '

.......

80484de db 00h ; ' '

Остается решить, как передать управление на внедренный код. Это можно сделать различными путями: скорректировать точку входа (HTE это умеет) или внедрить в ее окрестности специальный jmp. Вот так мы и поступим! Запускам редактор, переходим в точку входа и смотрим на нее очень внимательно:

Точка входа и ее окрестности

....... ! entrypoint:

....... ! pop esi

80482c1 ! xor ebp, ebp

80482c3 ! mov ecx, esp

80482c5 ! and esp, 0fffffff0h

80482c8 ! push eax

80482c9 ! push esp

80482ca ! push edx

80482cb ! push __libc_csu_fini

80482d0 ! push __libc_csu_init

80482d5 ! push ecx

80482d6 ! push esi

80482d7 ! push main

80482dc ! call wrapper_8049630_80482a0

80482e1 ! hlt

80482e2 ! nop

Почему бы нам не заменить pop esi/xor ebp,ebp на «jmp на наш код», откуда мы сможем сделать все, что задумано, выполнить эти команды и вернуться обратно? Но для начала необходимо подготовить код, который мы будем внедрять. Для простоты выведем короткое приветствие на экран. На языке ассемблера это звучит приблизительно так:

Исходная программа, выводящая приветствие на экран

mov eax, 4 ; системный вызов write

mov ebx,1 ; идентификатор стандартного вывода

mov edx, offset end_msg ; указатель на последний символ выводимого сообщения

int 80h ; вывод на экран

pop esi ; сохраненные команды

xor ebx,ebp

jmp 80482C3h ; возврат в программу

Это не самый оптимальный вариант, и его можно здорово оптимизировать, если переписать так:

Оптимизированный вариант

xor eax,eax

add al, 4

xor ebx,ebx

inc ebx

mov ecx, offset begin_msg

mov edx,ecx

add edx, sizeof(msg)

int 80h

pop esi

xor ebp, ebp

jmp 80482C3h

Теперь прокручивая файл в hex-редакторе, найдем и выпишем стартовые адреса всех цепочек NOP'ов, пригодных для внедрения. А какие цепочки пригодны для внедрения? Если две соседние цепочки расположены в пределах досягаемости короткого перехода (грубо - в пределах сотни байт), 3х NOP'ов будет вполне достаточно (2 байта на команду перехода, один - на любую однобайтовую команду полезного кода, например, inc ebx или pop esi). В противном случае нам необходимо иметь цепочку, по крайней мере, из шести NOP'ов: пять на команду близкого перехода и один на полезную команду. В нашем случае получается:

8048306h 10 байт

80483a2 14 байт

8048464 12 байт

Итого - 36 байт. Вполне достойное место для демонстрационной программы! Начинаем заполнять цепочки NOP'ов полезным кодом. С первой попытки у нас получается:

8048306 31 c0 xor eax, eax

8048308 04 04 add al, 4

804830a e9 93 00 00 00 jmp 80483a2h

804830f 90 nop

При этом один последний NOP останется потерян, но по-другому не получается. Команда xor ebx,ebx занимает два байта и сюда не помещается. А что если переставить команды местами? Перенести add al,4 в следующую цепочку NOP, а вместо нее вставить xor ebx,ebx/inc ebx:

8048306 31c0 xor eax, eax

8048308 31db xor ebx, ebx

804830a 43 inc ebx

804830b e9 92 00 00 00 jmp 80483a2h

Тогда следующая цепочка будет заполнена так:

80483a2 0404 add al, 4

80483a4 b9 ?? ?? ?? ?? mov ecx, offset begin_msg

80483a9 89ca mov edx, ecx

80483ab e9 b4 00 00 00 jmp 8048464h

В третью, последнюю, цепочку NOP'ов остаток кода уже не идет, не хватает одного единственного байта! Что ж, попытаемся еще немного ужать наш код. Например, вместо пары инструкций mov edx,ecx/add edx,sizeof(msg), которые занимают 5 байт, можно использовать lea edx,[ecx+sizeof(msg)]. Тогда все влезает! Ну а само сообщение можно разместить в сегменте данных. Поскольку свободного места там не очень много, ограничимся строкой "hello". Завершающий нуль в конце ставить необязательно, поскольку системный вызов write выводит ровно столько символов, сколько ему приказано вывести, и ни на какие знаки «останова» не реагирует.

Если все было сделано правильно (что маловероятно, в первый раз ошибки делают все), наш файл победоносно выведет строку "hello", а следом за ней ту строку, которую выводит наша подопытная программа, и экран будет выглядеть так:

[заключение]

Мы рассмотрели простейший случай, а пропыхтели над ним два часа. А сколько займет троянизация полноценной программы? Всю оставшуюся жизнь? Конечно же, нет. Долго это только с непривычки, потом вырабатывается навык, и все идет на автопилоте. Главное - не бояться трудностей и постоянно тренироваться, оттачивая свое мастерство!

Для правки исполняемых файлов Линух необязателен. Достаточно иметь HIEW, запущенный из-под Windows, или даже MS-DOS, однако, в этом случае придется сильно попыхтеть и к тому же - как потом это отлаживать? Так что Линух все-таки желателен, хотя бы в виде эмулятора - VMWare, BOCHS или QEMU.

Мы остановимся на hex-редакторе HTE, готовую сборку которого можно бесплатно скачать с hte.sf.net. Он «переваривает» ELF-формат, в нем есть мощный ассемблер и прочие вкусности. Как вариант, можно воспользоваться редактором BIEW (biew.sf.net), но он намного слабее.

Желательно иметь ИДУ. Линуховый порт содержит удобный интерактивный отладчик в стиле Turbo-Debugger'а, плюс сам дизассемблер. Если нет ИДЫ, возьми gdb - стандартный отладчик, входящий в штатный комплект поставки большинства Линухов, но его возможности сильно ограничены. В частности, он отказывается грузить файлы без section table, спотыкается на антиотладочный приемах и т.д.

Из документации нам, в первую очередь, понадобится спецификация на ELF-формат, которую можно бесплатно скачать с www.cs.princeton.edu/courses/archive/fall05/cos318/docs/ELF_Format.pdf и перечень системных вызовов в разных осях - UNIX Assembly Codes Development for Vulnerabilities Illustration Purposes (www.lsd-pl.net/documents/asmcodes-1.0.2.pdf).