Текст книги "Спецвыпуск журнала «Хакер» 47, октябрь 2004 г."

Автор книги: Хакер Журнал

сообщить о нарушении

Текущая страница: 9 (всего у книги 21 страниц)

Как и где лучше искать?

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

1. www.xakep.ru. А что ты ожидал увидеть на первом месте? :). Сайт журнала сделан очень грамотно, на нем своевременно появляются новые эксплоиты, поэтому, если испытываемый сервис содержит буквально вчерашний баг, топай на хаkер.ru и бери нужный эксплоит. В остальных случаях рекомендую посетить другой сайт, ибо сайт Хакера снабжен не совсем удобным поиском (на запрос SunOS exploit, скрипт вернет ссылку на какую-нибудь статью и т.п.).

2. http://security.nnov.ru. Мой любимый портал по безопасности. У сайта много плюсов: русскоязычность, простой движок, удобный поиск. Достаточно зайти на страницу security.nnov.ru/search/exploits.asp и написать парочку ключевых слов. Ответ в виде ссылки на рабочий эксплоит не заставит себя долго ждать.

3. http://securitylab.ru. Еще один отечественный портал по безопасности. Он имеет плюсы двух предыдущих сайтов. Во-первых, на страницах этого сайта содержится подробное описание бага на русском языке (как на хаkер.ru). Во-вторых, сайт обладает весьма функциональным поисковым скриптом, который найдет уязвимость по любым ключевым словам (как на security.nnov.ru). Наконец, ты можешь подписаться на рассылку этого сайта и всегда быть в курсе новых багов.

4. http://packetstormsecurity.nl. Из англоязычных ресурсов ПакетШторм – самый лучший. Мне нравится то, что весь софт разбит на категории. Это означает, что помимо эксплоитов ты можешь найти бэкдоры, сниферы, логвайперы и многое другое. О поиске я вообще молчу – ответ на стандартный запрос может содержать 30 страниц ссылок, грамотно отсортированных по ревалентности.

5. http://securityfocus.org. Еще один зарубежный ресурс, который существует очень давно. На его страницах ты всегда найдешь новые эксплоиты и описания свежих багов. Лично я обращаюсь к страницам этого портала только за разъяснением той или иной бреши в сервисе. В остальных случаях мне хватает других источников.

Регулярно читай обзор эксплоитов в выпусках Х.

ProFTPD и Wu-ftpd – самые дырявые сервера. Но несмотря на это администраторы продолжают их использовать.

В последнее время в публичных источниках трудно найти хороший эксплоит.

О том, как админы подменяют баннеры своих сервисов, ты можешь узнать, прочитав статью в этом номере.

Очень часто авторы эксплоитов умышленно допускают ошибки в коде. Чтобы эксплоит функционировал, тебе придется их найти и исправить.

Если ты пробил защиту какого-нибудь маршрутизатора, ищи бажные сервисы в локальной сети. Поверь, там их очень много :).

Чтобы узнать, какие модули подключены к Web-серверу, отправь простой WWW-запрос. Информация о библиотеках содержится в строке «Server:».

Атака брутфорсом очень действенна. Правда, такой взлом может продолжаться несколько часов. Все зависит от пропускной способности.

Зараза для никсов / Вирусный разгул под UNIX

Крис Касперски aka мыщъх

Трудно представить себе более простую штуку, чем компьютерный вирус. Тетрис и тот посложнее будет. Однако программирование вирусов вызывает у начинающих большие трудности: как внедрить свой код в файл, какие поля необходимо изменять, а какие лучше не трогать, чем отлаживать вирусы и можно ли использовать языки высокого уровня? Ответы на эти и многие другие вопросы, связанные с созданием вирей под *nix, я постарался дать в этом материале.

Оперативная обстановка

Первые вирусы, поражающие ELF-файлы (основной формат исполняемых файлов под *nix), были зарегистрированы в конце 90-х, а теперь их популяция насчитывает свыше полусотни представителей (см. коллекцию вирусов на vx.netlux.org). Антивирусная Энциклопедия Евгения Касперского (www.viruslist.com/viruslist.html?id=3166) сообщает лишь о четырнадцати из них, что наводит на серьезные размышления о качестве AVP и добросовестности его создателей.

По умолчанию, UNIX запрещает модификацию исполняемых файлов, и успешное распространение вирусов возможно только на уровне root, который либо присваивается зараженному файлу администратором, либо самостоятельно захватывается вирусом через дыры в ядре системы. При правильной политике разграничения доступа и оперативном наложении заплаток угроза вирусного заражения сводится к минимуму. К тому же, времена тотального обмена софтом давно позади. Сейчас уже никто не копирует исполняемые файлы друг у друга, скачивая их напрямую из интернета. Даже если вирус ухитрится поразить центральный сервер, дальше первого поколения его распространение не пойдет и вторичные заражения будут носить единичный характер.

Файловые вирусы уже неактуальны, и отсутствие крупных эпидемий наглядно подтверждает этот факт. Тем не менее, накопленные методики внедрения отнюдь не стали бесполезными – без них жизнь троянов и систем удаленного администрирования была бы весьма недолгой. Захватить управление атакуемым компьютером и заполучить права root'а – все равно что бросить зернышко на раскаленный асфальт. Хакер должен укорениться в системе, цепляясь за все исполняемые файлы, что встретятся ему на пути. Но и тогда он не может быть ни в чем уверен, поскольку существует такое понятие, как резервное копирование, позволяющее восстановить пораженную систему, как бы глубоко вирус ни был внедрен.

Считается, что вирусы, внедряющиеся в исходные тексты, более живучи, однако в действительности это не так. Исходные тексты требуются небольшому числу пользователей, а девелоперы активно используют системы контроля версий, отслеживающих целостность программного кода и позволяющих делать многоуровневый «откат». Было зарегистрировано несколько попыток заражения исходных текстов операционной системы LINUX и сервера Apache, но все они с треском провалились.

То же самое относится и к вирусам, обитающим в интерпретируемых скриптах, таких, как sh, Perl, PHP. В *nix скрипты вездесущи и их модификация по умолчанию разрешена, что создает благоприятные условия для размножения вирусов. Если бы пользователи обменивались скриптами, юниксоидный мир погрузился бы в эпоху ранней MS-DOS, когда новые вирусы выходили едва ли не каждый день, а так вирусы остаются внутри пораженного компьютера, не в силах вырваться наружу.

Разумеется, вирус может распространяться и через интернет, но тогда это будет уже не вирус, а червь. Некоторые исследователи считают червей самостоятельными организмами, некоторые – разновидностью вирусов, но, как бы там ни было, черви – тема отдельного разговора.

Язык разработки

Настоящие хакеры признают только один, максимум, два языка – C и Ассемблер, причем последний из них стремительно утрачивает свои позиции, уступая место Бейсику, Delphi и прочей дряни, на которой элегантный вирус невозможно создать в принципе.

А что на счет Си? С эстетической точки зрения, это – чудовищный выбор, и вирусмэйкеры старой школы его не прощают (однако написать код на ассемблере сравнимый с тем, что выдают современные оптимизирующие C-компиляторы вроде Microsoft C Compiler, – дело для новичка не такое уж простое – прим. AvaLANche'а). С другой стороны, будучи низкоуровневым системно-ориентированным языком, Си неплохо походит для разработки вирусов, хотя от знания Ассемблера это все равно не освобождает.

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

Нельзя объявлять главную функцию программы как main: встретив такую, линкер внедрит в файл start-up код, который вирусу не нужен. Нельзя использовать глобальные или статические переменные: компилятор принудительно размещает их в сегменте данных, но у вирусного кода не может быть сегмента данных! Даже если вирус захочет воспользоваться сегментом пораженной программы, он будет должен, во-первых, самостоятельно определить адрес его «хвоста», а, во-вторых, растянуть сегмент до необходимых размера. Все это тривиально реализуется на Ассемблере, но для компилятора оказывается чересчур сложной задачей. Кроме того, нужно хранить все данные только в локальных переменных, задавая строковые константы в числовом виде. Если написать char x[] = «hello, world», коварный компилятор сбросит «hello, world» в сегмент данных, а затем динамически скопирует его в локальную переменную x. Можно сделать так: x[0]='h', x[1]='e', x[2]='l'… или преобразовать char в int, осуществлять присвоение двойными словами, не забывая о том, что младший байт должен располагаться по наименьшему адресу, что разворачивает строку задом наперед.

Нельзя использовать никакие библиотечные функции, если только не уверен в том, что они полностью удовлетворяют всем вышеперечисленным требованиям. Системные функции обычно вызываются через интерфейс native-API, также известный под именем sys-call (в Linux-подобных системах за это отвечает прерывание INT 80h, другие системы обычно используют дальний вызов по селектору семь, смещение ноль). Поскольку системные вызовы варьируются от одной системы к другой, это ограничивает среду обитания вируса и при желании он может прибегнуть к внедрению в таблицу импорта.

Откомпилировав полученный файл, мы получим объектник и ругательство компилятора по поводу отсутствия main. Остается только слинковать его в двоичный 32.64-разрядный файл. Естественно, внедрять его в жертву придется вручную, так как системный загрузчик откажется обрабатывать такой файл.

Средства анализа, отладки и плагиата

Какой вирусмэйкер удержится от соблазна пополнить свой заплечный рюкзак за чужой счет, выдирая идеи и алгоритмы из тел попавших к нему вирусов? Чаще всего вирусами обмениваются тет-а-тет. Коллекции, найденные в сети, для опытных хакеров не представляют никакого интереса, поскольку набираются из открытых источников, но для начинающих исследователей это – настоящий клад.

Если исходные тексты вируса отсутствуют (кривые дизассемблерные листинги, выдаваемые за божественное откровение, мы в расчет не берем), препарировать двоичный код вируса приходится самостоятельно. Тут-то нас и поджидает одна большая проблема. Дизассемблер всех времен и народов IDA PRO не приспособлен для работы с ELF-вирусами, поскольку отказывается загружать файлы с искаженным section header'ом (а большинство вирусов никак не корректируют его после заражения!). Других достойных дизассемблеров, переваривающих ELF-формат, мне обнаружить так и не удалось (а самому писать лень). За неимением лучших идей приходится возиться с HEX-редакторами (например, с тем же HIEW'ом), разбираясь со служебными структурами файла вручную.

С отладчиками дело обстоит еще хуже. Фактически под *nix существует всего один более или менее самостоятельный отладчик прикладного уровня – gdb (GNU Debugger), являющийся фундаментом для большинства остальных. Простейшие антиотладочные приемы, нарытые в хакерских мануалах времен первой молодости MS-DOS, пускают gdb в разнос или позволяют вирусу вырваться из-под его контроля, поэтому отлаживать вирусный код на рабочей машине категорически недопустимо и лучше использовать для этой цели эмулятор, такой, как BOCHS. Особенно предпочтительны эмуляторы, содержащие интегрированный отладчик, обойти который вирусу будет очень тяжело, а, в идеале, вообще невозможно (BOCHS такой отладчик содержит). Кстати говоря, совершенно необязательно для исследования ELF-вирусов устанавливать *nix. Эмулятора для этих целей будет более чем достаточно.

ELF

Структура ELF-файлов (ELF – Execution & Linkable Format) имеет много общих черт с PE (Portable Execution) – основным исполняемым форматом платформы Windows 9x и NT, концепции их заражения весьма схожи, хотя и реализуются различным образом.

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

Листинг

Структура исполняемого ELF-файла

ELF Header

Program header table

Segment 1

Segment 2

Section header table (optional)

Каждый сегмент представляет собой непрерывную область памяти со своими атрибутами доступа (кодовый сегмент обычно доступен только на исполнение, сегменты данных как минимум доступны на чтение, а при необходимости еще и на запись). Пусть слово «сегмент» не вводит тебя в заблуждение: ничего общего с сегментной моделью памяти тут нет. Большинство 32-битных реализаций UNIX'а помещают все сегменты ELF-файла в один 4-гигабайтный «процессорный» сегмент (т.н. плоская (flat) модель памяти – прим. ред.). В памяти все ELF-сегменты должны выравниваться по величине страницы (на x86, равной 4 Кб), но непосредственно в самом ELF-файле хранятся в невыравненном виде, вплотную прижимаясь друг к другу. Сам ELF-заголовок и program header в первый сегмент не входят (ну, формально не входят), но совместно грузятся в память, при этом начало сегмента следует непосредственно за концом program header'а и по границе страницы не выравнивается!

Последним из всех идет заголовок таблицы секций (section header table). Для исполняемых файлов он необязателен и реально используется только в объектниках. Еще в нем нуждаются отладчики – исполняемый файл с изуродованным section header table не отлаживается ни gdb, ни производными от него отладчиками, хотя нормально обрабатывается операционной системой.

Сегменты естественным образом делятся на секции. Типичный кодовый сегмент состоит из секций .init (процедуры инициализации), .plt (секция связок), .text (основой код программы) и .finit (процедуры финализации), атрибуты которых описываются в section header'e. Загрузчик операционной системы ничего не знает о секциях, игнорируя их атрибуты и загружая весь сегмент целиком. Тем не менее, для сохранения работоспособности зараженного файла под отладчиком вирус должен корректировать оба заголовка сразу – как program header, так и section header.

Основные структуры ELF находятся в файле /usr/include/elf.h.

За более подробной информацией обращайся к оригинальной спецификации на ELF-файл «Executable and Linkable Format – Portable Format Specification», составленной, естественно, на английском языке.

Методы заражения

Простейший и наиболее универсальный метод заражения сводится к поглощению оригинального файла вирусом. Вирус просто дописывает оригинальный файл к своему телу как оверлей, а для передачи управления жертве проделывает обратный процесс: пропускает первые virus_size байт своего тела (что обычно осуществляется функцией seek), считывает оставшийся «хвост» и записывает его во временный файл. Присваивает атрибут исполняемого и делает ему exec, предварительно расщепив материнский процесс функцией fork. После завершения работы файла-жертвы вирус удаляет временный файл с диска.

Описанный алгоритм элементарно реализуется на любом языке программирования вплоть до Бейсика и пригоден как для исполняемых файлов, так и для скриптов. Однако ему присущи и недостатки. Он медлителен и неэлегантен, требует возможности записи на диск и прав установки атрибута «исполняемый». Кроме того, появление посторонних файлов на диске не может долго оставаться незамеченным, и участь вируса заранее предрешена. Поэтому большинство вирусов не используют такую методику, а предпочитают внедряться в конец последнего сегмента файла, расширяя его на необходимую величину.

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

Приблизительный алгоритм внедрения в конец ELF-файла выглядит следующим образом:

1) вирус открывает файл и, считывая его заголовок, убеждается, что это действительно ELF;

2) просматривая Program Header Table, вирус отыскивает последний сегмент с атрибутом PL_LOAD;

3) найденный сегмент «распахивается» до конца файла и увеличивается на величину, равную размеру тела вируса, что осуществляется путем синхронной коррекции полей p_filez и p_memz;

4) вирус дописывает себя в конец заражаемого файла;

5) для перехвата управления вирус корректирует точку входа в файл (e_entry) либо же внедряет в истинную точку входа jmp на свое тело (впрочем, методика перехвата управления – тема отдельного долгого разговора).

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

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

1) вирус открывает файл и, считывая его заголовок, убеждается, что это действительно ELF;

2) просматривая program header table, вирус находит сегмент с атрибутом PL_LOAD и (PAGE_SIZE % p_filesz) > = virus_size; если же такого сегмента нет, вирус отказывается от заражения;

3) поля p_filez (размер на диске) и p_memsz (размер в памяти) соответствующего сегмента увеличиваются на длину тела вируса;

4) поле p_offset и факультативно sh_offset всех последующих сегментов/секций увеличивается на длину тела вируса;

5) поля e_phoff и факультативно e_shoff ELF-заголовка увеличивается на величину тела вируса;

2) вирус внедряем себя в конец выбранного сегмента;

6) для перехвата управления вирус корректирует точку входа в файл (e_entry), либо же внедряет в истинную точку входа jmp на свое тело.

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

Общая структура и стратегия вируса

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

Для большинства ELF-вирусов характерна следующая последовательность системных вызовов: sys_open (mov eax, 05h/int 80h) открывает файл; sys_lseek (mov eax,13h) перемещает файловый указатель на нужное место; old_mmap (mov eax, 5Ah/int 80h) проецирует файл в память; sys_unmap (mov eax, 5Bh/int 80h) удаляет образ из памяти, записывая на диск все изменения, а sys_close (mov eax, 06/int 80h) закрывает сам файл.

Техника проецирования (mapping) значительно упрощает работу с файлами большого объема. Теперь уже не нужно выделять буфер, копируя туда файл по кускам, и всю черную работу можно переложить на плечи операционной системы, сосредоточив свои усилия непосредственно на процессе заражения. Правда, при заражении файла протяженностью в несколько гигабайт (например, самораспаковывающегося дистрибутива какого-то программного продукта) вирусу придется либо просматривать файл через «окно», проецируя в 4-гигабайтное адресное пространство различные его части, либо попросту отказаться от заражения, выбрав файл поприличнее. Подавляющее большинство вирусов именно так и поступает.

Заключение

В ближайшее время, по-видимому, следует ожидать значительный рост численности ELF-вирусов, ибо для этого имеются все условия. Всплеск интереса к Linux пошел не на пользу этой операционной системе. В погоне за улучшениями ее превратили в решето, прикрутили «интуитивно понятный» графический интерфейс, но не предупредили пользователей, что прежде чем начать работать с системой, следует перелопатить тысячи страниц технической документации и прочитать хотя бы пару умных книжек, в противном случае зараза не заставит себя долго ждать. Чем больше народу перейдет на *nix, тем больше среди них окажется хакеров и вирусописателей, и тогда с *nix произойдет то же, что в свое время произошло с MS-DOS. Будут ли эти вирусы добродушными или злобными, зависит от тебя.

Перехват управления путем модификации таблицы импорта

Классический механизм импорта внешних функций из/в ELF-файлов в общем виде выглядит так: на первом этапе вызова импортируемой функции из секции .text вызывается «переходник», который располагается в секции .plt (Procedure Linkable Table) и ссылается в свою очередь на указатель на функцию printf, что расположен в секции .got («Global Offset Tables»), ассоциированной с таблицей строк, содержащей имена вызываемых функций (или их хэши).

Ниже приведена схема вызова функции printf утилитой ls, позаимствованной из комплекта поставки Red Hat 5.0.

В какое место этой цепочки может внедриться вирус? Ну, прежде всего, он может создать подложную таблицу строк, перехватывая вызовы всех интересующих его функций. Чаще всего заражению подвергается функция printf/fprintf/sprintf (поскольку без нее не обходится практически ни одна программа) и функции файлового ввода/вывода, что автоматически обеспечивает прозрачный механизм поиска новых жертв для заражения.

Вирусы-спутники создают специальную библиотеку-перехватчик во всех заражаемых файлах. Поскольку IDA Pro при дизассемблировании ELF-файлов не отображает имя импортируемой библиотеки, заподозрить что-то неладное в этой ситуации нелегко. К счастью, HEX-редакторы еще никто не отменял. Другие же вирусы склонны манипулировать полями глобальной таблицы смещений, переустанавливая их на свое тело.

Ссылки по теме

WWW

bochs

http://bochs.sourceforge.net

Качественный эмулятор ПК с интегрированным отладчиком внутри. Хорошо подходит для экспериментов с вирусами непосредственно на твоей рабочей машине без риска уничтожения информации. Бесплатен, распространяется с исходными текстами.

Executable and Linkable Format – Portable Format Specification

www.ibiblio.org/pub/historic-linux/ftp-archives/sunsite.unc.edu/Nov-06-1994/GCC/ELF.doc.tar.gz

«Родная» спецификация на ELF-формат. Настоятельно рекомендуется к изучению всем вирусописателям, пробующим свои силы на платформе UNIX.

The Linux Virus Writing And Detection HOWTO

www.creangel.com/papers/writingvirusinlinux.pdf

Пошаговое руководство по проектированию и реализации вирусов под LINUX с кучей готовых примеров (на английском языке).

«UNIX viruses» от Silvio Cesare

http://vx.netlux.org/lib/vsc02.html

Статья, описывающая основные принципы функционирования UNIX-вирусов и способы их детектирования (на английском языке).

LINUX VIRUSES – ELF FILE FORMAT Marius Van Oers

www.nai.com/common/media/vil/pdf/mvanvoers_VB_conf%25202000.pdf&e=747

Блестящий обзор современных UNIX-вирусов и анализ используемых ими методик внедрения в ELF-файлы (на английском языке).

Некоторые администраторы полагают, что под *nix вирусов нет. Вирусы же придерживаются иного мнения.

Некоторые пользователи в желании почувствовать себя богом подолгу работают в системе на из-под root'а. Вирусы и хакеры любят таких пользователей :).

Малочисленность вирусов в мире *nix компенсируется отсутствием нормальных антивирусов.

IE и IRC – вот основные источники для пополнения твоей коллекции вирусов.

Открытость ELF-формата вкупе с доступностью исходных текстов системного загрузчика значительно упрощает конструирование вирусов под *nix.

Создание вирусов не преследуется по закону. По закону преследуется создание вредоносных программ.

Из десятка возможных методов внедрения в ELF-файлы вирусописателям удалось освоить лишь два-три, так что на отсутствие творческого простора жаловаться не приходится.

*nix– и Windows-вирусы строятся по одним и тем же принципам, причем UNIX-вирусы даже проще.

Антивирусная Энциклопедия Касперского содержит большое количество фактических ошибок в описании *nix-вирусов.

Многие *nix-вирусы зависят от версии операционной системы, поэтому всякий исследователь вынужден держать на своей машине зоопарк осей.

Огромная коллекция *nix-вирусов (и не только) имеется на http://vx.netlux.org.