Интеллектуальные развлечения. Интересные иллюзии, логические игры и загадки.

Добро пожаловать В МИР ЗАГАДОК, ОПТИЧЕСКИХ
ИЛЛЮЗИЙ И ИНТЕЛЛЕКТУАЛЬНЫХ РАЗВЛЕЧЕНИЙ
Стоит ли доверять всему, что вы видите? Можно ли увидеть то, что никто не видел? Правда ли, что неподвижные предметы могут двигаться? Почему взрослые и дети видят один и тот же предмет по разному? На этом сайте вы найдете ответы на эти и многие другие вопросы.

Log-in.ru© - мир необычных и интеллектуальных развлечений. Интересные оптические иллюзии, обманы зрения, логические флеш-игры.

Привет! Хочешь стать одним из нас? Определись…    
Если ты уже один из нас, то вход тут.

 

 

Амнезия?   Я новичок 
Это факт...

Интересно

99 % живых существ, обитавших на Земле вымерли.

Еще   [X]

 0 

Защита от хакеров корпоративных сетей (Коллектив авторов)

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

Год издания: 2002

Цена: 199 руб.



С книгой «Защита от хакеров корпоративных сетей» также читают:

Предпросмотр книги «Защита от хакеров корпоративных сетей»

Защита от хакеров корпоративных сетей

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


Дэвид М. Ахмад, Идо Дубравский, Хал Флинн, Джозеф «Кингпин» Гранд, Роберт Грэм, Норис Джонсон, K2, Дэн «Эффугас» Камински, Ф. Уильям Линч, Стив Манзуик, Райян Пемех, Кен Пфеил, Рэйн Форест Паппи, Райян Расселл Защита от хакеров корпоративных сетей

Благодарности

   Ральфа Троупа (Ralph Troupe), Ронда Ст. Джона (Rhonda St. John) и коллектив Callisma за бесценную способность вникнуть в суть сложных задач проектирования, развертывания и поддержки сетей учреждений мирового класса.
   Карена Кросса (Karen Cross), Ланса Тилфорда (Lance Tilford), Мегхана Канигхэма (Meaghan Cunningham), Кима Вилли (Kim Wylie), Гарри Кирчнера (Harry Kirchner), Кевина Вотела (Kevin Votel), Кента Андерсона (Kent Anderson), Фрида Яра (Frida Yara), Билла Геца (Bill Getz), Джона Мейеса (Jon Mayes), Джона Месджака (John Mesjak), Пега О'Доннелли (Peg O'Donnell), Сандру Паттерсона (Sandra Patterson), Бетти Редмонда (Betty Redmond), Роя Ремера (Roy Remer), Роя Шапиро (Ron Shapiro), Патрисию Келли (Patricia Kelly), Андреа Тетрика (Andrea Tetrick), Дженнифера Паскаля (Jennifer Pascal), Дуга Реила (Doug Reil) и Дэвида Дахла (David Dahl) из Западной группы издателей (Publishers Group West) за обмен потрясающим опытом в области маркетинга и экспертизу.
   Жакью Шанахэм (Jacquie Shanahan) и ЭнХелен Линдехолм (AnnHelen Lindeholm) из Elsevier Science за придание нам уверенности в правоте нашего дела.
   Анабел Дент (Annabel Dent) и Паулю Барри (Paul Barry) за все то, что они для нас сделали.
   Дэвиду Букланду (David Buckland), Венди Вонгу (Wendi Wong), Мэри Чиенгу (Marie Chieng), Люси Чонгу (Lucy Chong), Лесли Лиму (Leslie Lim), Одри Гану (Audrey Gan) и Джозефу Чану (Joseph Chan) из Transquest Publ ishers за энтузиазм, с которым они просматривают наши книги.
   Квон Шунг Джун (Kwon Sung June) из Acorn Publishing за поддержку.
   Етан Аткин (Ethan Atkin) из Cranbury International за помощь в расширении программы Syngress.
   Джекки Гросса (Jackie Gross), Гейла Войсея (Gayle Voycey), Алексия Пенни (Alexia Penny), Аник Робитэйла (Anik Robitaille), Крэга Сиддалла (Craig Siddall), Дарлен Морроу (Darlene Morrow), Иолану Миллер (Iolanda Miller), Джан Макей (Jane Mackay) и Мэри Скелли (Marie Skelly) из Jackie Gross & Associates за помощь и энтузиазм, с которым они представляют книгу в Канаде.
   Лоиса Фрасера (Lois Fraser), Конни Макменеми (Connie McMenemy), Шэннона Рассела (Shannon Russell) и других талантливых сотрудников из Jaguar Book Group за их помощь в распространении книг издательства в Канаде.
Слова благодарности от технического редактора Райана Рассела (Ryan Russel)
   Я хотел бы посвятить свою работу своей замечательной жене и детям, не будь которых не было бы смысла работать над книгой. Я люблю тебя, Сара, с Днем святого Валентина тебя! Я также хотел бы поблагодарить Брайена Мартина (Brian Martin) за помощь при редактировании и, конечно, авторов, которые нашли время написать книгу. Особенно хочется поблагодарить авторов первого издания за их идеи по улучшению книги.

   Райан Рассел

От автора Предисловие (версия 1.5)

   Авторы первого издания книги относительно ее содержания единодушны в одном: после первоначального изложения материала у них появилось желание представить материал своих глав по-другому. Объясняется это допущенными ошибками, недостаточным, с точки зрения авторов, пояснениями изложенного в книге материала, нехваткой времени для написания еще одного примера программы или тем, что авторы забыли рассмотреть дополнительные вопросы. Как и в любом другом проекте, время в конечном счете истекло, и пришлось завершить работу.
   Предоставленный шанс повторно вернуться к работе над книгой позволил авторам исправить недостатки, выявленные с момента первого ее издания. Большая часть была выявлена благодаря читателям, написавшим авторам: «Вам следовало бы по-другому написать об этом…» В абсолютном большинстве случаев они были правы. В результате была предпринята попытка исправления максимально возможного числа недостатков первого издания книги «Защита от хакеров корпоративных сетей» (Hack Proofing Your Network).
   К моменту первого издания книги в продаже было совсем немного книг, посвященных в полном объеме методам преодоления средств компьютерной защиты. Для издательства Syngress Publishing эта книга стала первой в подобной серии. Руководство издательства немного нервничало. Оно не было уверено в том, что обучение хакерским методам – это хорошо. (Похоже, что другие издательства были напуганы. Когда автор говорил с представителями некоторых из них о книге, посвященной методам работы хакеров, то они даже не захотели просмотреть план книги. «Никаких книг о хакерских методах». Конечно, некоторые из них к настоящему времени уже выпустили книги по этой тематике.)
   Поэтому в издательстве Syngress полагали, что если будет написана книга Hack Proofing Your Network, то она должна в полном объеме описать мероприятия по защите информации. Так и было сделано. Кто-то может возразить вам, что он не имеет ничего против методов защиты, что он применяет их годами. Но когда в книге упоминается о защите, речь идет о совершенно других технологиях. В первом издании ряд глав был посвящен вопросам защиты, которые трудно реализовать целиком и которые, вообще говоря, неудобны для работы.
   По сравнению с первым изданием произошли некоторые изменения. Например, под словосочетанием Hack Proofing теперь понимается серия книг, а не одна книга. Кроме книги, которая перед вами, в серию входят:
   • Hack Proofing Your E-commerce Site (ISBN: 1-928994-27-X)
   • Hack Proofing Your Web Applications (ISBN: 1-928994-31-8)
   • Hack Proofing Sun Solaris 8 (ISBN: 1-928994-44-X)
   • Hack Proofing Linux (ISBN: 1-928994-34-2)
   • Hack Proofing Windows 2000 Server (ISBN: 1-931836-49-3)
   • Hack Proofing Your Wireless Network (ISBN: 1-928994-59-8)
   • Hack Proofing ColdFusion 5.0 (ISBN: 1-928994-77-6)
   Готовятся к печати и другие книги этой серии, которых объединяет их ориентация на описание методов защиты.
   Это версия 1.5 предисловия. С течением времени содержимое данной книги пересматривается (точнее, тщательно проверяется и совершенствуется, но вы поняли идею). Однако слова Мудге все еще остаются в силе. Читая книгу, скоро вы убедитесь в этом сами. Полагайте, что перед вами протокол изменений содержимого книги. Обратите внимание на изменения, внесенные во второе издание, которые заключаются или в добавлении нового материала, или в улучшении старого. В издание добавлено несколько новых глав, включая:
   • Хакинг аппаратных средств ЭВМ;
   • Туннелирование;
   • Уклонение от IDS;
   • Атаки, основанные на форматирующей строке.
   Эти главы поясняют некоторые сложные темы, включение которых в книгу способно сделать ее содержание актуальнее. Сведения об использовании форматирующей строки стали общедоступны только после завершения работы над первым изданием. В первом издании ничего не рассказано об этом, поскольку в то время были неизвестны методы работы с форматирующей строкой.
   Каждая глава второго издания была обновлена, переработана с точки зрения возможных атак, сжата и вообще улучшена. Есть бесконечное число вариантов изложения, но некоторые читатели предложили разбить материал первого издания по темам таким образом, чтобы каждый используемый метод был освещен в одной главе. Это выглядело привлекательно, поэтому и было осуществлено во втором издании. В начале книги пара глав посвящена теории, но сразу за этими «вводными» главами по существу обсуждается каждый тип нападения. Наконец, для большей пользы книгу завершает краткая глава о правилах информирования нас о найденных вами изъянах в системах защиты.
   Одно из центральных изменений второго издания состоит в том, что авторы издания оставили попытку объяснить свои действия. В первом издании потрачено много времени и усилий для разъяснения, почему знания о хакерских методах полезны, почему в разное время люди используют слово «хакер» и почему восстановление алгоритмов работы существующих программ (reverse engineering) должно относиться к основным человеческим правам.
   После выхода первого издания большинство людей, купивших книгу, уже согласились с тем, что представленная в книге информация должна быть доступна (или, по крайней мере, они захотели ознакомиться с ней). А люди, которые не соглашались со мной. Что ж, они не согласны со мной и после прочтения книги, даже после ознакомления с приведенными в книге доводами ! Говоря искренне, я был потрясен. Я не убедил их своими тщательно подобранными аргументами. Действительно, невозможно всегда всем нравиться.
   Возвращаясь к обсуждаемым вопросам, отметим, что люди, которым нравится то, что, мы делаем, могут не читать объяснений, почему мы занимаемся этим. Эти объяснения для тех, кто не разделяет наших позиций. Авторы используют слово хакер для обозначения субъекта, который взламывает компьютер без разрешения. Однако это слово не используется исключительно в данном контексте. Оно также обозначает ряд других «субъективных» понятий. Вы как образованный читатель и профессионал в области безопасности должны, в зависимости от контекста, понять его смысл. Если вы прочтете остальную часть этой книги, то найдете там разные значения этого слова.
   Если вы хотите точно знать, что было в первом издании книги и чего нет во втором, то посетите сайт Syngress Solutions по адресу www.Syngress.com/solutions. В дополнение к электронной версии первого и второго издания книги у вас появится возможность задать авторам вопросы по электронной почте о книге и получить ответы на них. Если этого недостаточно, в течение года вам будет предоставлена возможность ознакомиться с периодическими обновлениями содержимого книги в форме официальных изданий. Для издательства это еще один дополнительный способ познакомить вас с новыми материалами, ставшими известными только после выхода издания книги. Сайт Solutions – это ваш ресурс, используйте его. Кроме того, мне интересно узнать мнение читателей.
   Я надеюсь, что книга вам понравится.

   Райан Рассел (Ryan Russell)

Глава 1
Хакерские методы

   В этой главе обсуждаются следующие темы:
   • Что понимают под «хакерскими методами»
   • Обзор содержимого книги
   • Правовое обеспечение хакинга
   · Конспект
   · Часто задаваемые вопросы

Введение

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

Что понимают под «хакерскими методами»

   Когда автор был ребенком, диалоговый мир сетевых компьютерных онлайн-систем состоял из электронных досок объявлений (BBS). На многих BBS были текстовые файлы, заголовок которых представлял собой вариацию на тему «Как стать хакером». Почти все эти файлы были бесполезны и содержали советы подобно следующим: «попробуйте приведенные мастер-пароли» или «нажмите на клавиатуре комбинацию клавиш Ctrl + C и посмотрите, не приведет ли это к выходу из программы». Название главы «Хакерские методы» – это способ автора воздать должное подобным файлам. Они стали его источником вдохновения для написания приличного набора инструкций по применению хакерских методов – хакингу.
   Итак, какой смысл подразумевается под словом хакерство ? Под ним понимается обход мер безопасности компьютерных систем и вычислительных сетей. Слово хакерство применимо и как существительное, характеризуя умную или быструю программу. В реальной жизни (в выпусках новостей, беседах, списках адресатов почты и т. д.) люди применяют слово хакерство, хакинг или хакер без объяснения вкладываемого в него смысла. Но его можно понять из контекста или чтения между строк. Эта книга не является исключением. Кроме того, авторы иногда используют выражения, как, например, хакер-новичок (script kiddie), для обозначения чего-либо связанного или производного от значения слова хакер. Если читателю не нравится термин, который применяется для рассматриваемой человеческой деятельности, то авторы искренне призывают его мысленно заменить обсуждаемый термин на привычное для читателя слово и далее считать, что именно привычный для него термин используется в книге.
   Если читатель действительно хочет познакомиться с философским обсуждением значения слова, то, пожалуйста, посетите Web-сайт Syngress Solutions и загрузите электронную копию первого издания книги. В ее первой главе под названием «Политика» обсуждаются различные значения слова хакер. В этом издании подобное обсуждение опущено, но если читатель хочет пойти своим путем в поисках старой истины, то не говорите, что его не предупреждали.
   Вообще говоря, авторы надеются избежать использования слова хакер в значении «плохой программист».

Зачем применяют хакерские методы?

   Если читатель хочет услышать длинный рассказ о причинах чьего-либо любопытства о том, как это делается, автор отсылает его к первому изданию книги с длинными рассуждениями о слове хакер. Но кратко: лучшая защита – это нападение. Другими словами, единственный способ остановить хакера заключается в том, чтобы думать как он. И если после этого вы не сможете взломать ваши системы, то кто сможет? Эти фразы звучат банально, но они олицетворяют подход, который, по мнению авторов, позволит наилучшим образом обеспечить безопасность вашей собственной системы (или системы работодателя, или ваших клиентов и т. д.).
Приоткрывая завесу
   «Мы не нанимаем хакеров»
   Вы, возможно, слышали о заявлениях различных компаний безопасности о том, что они «не нанимают хакеров». Очевидно, смысл подобных заявлений заключается в том, что компании имеют в виду исправившихся хакеров-преступников, хакеров, ныне работающих в области безопасности, или что-то другое. В основном это делается из-за опасения отказа некоторых людей от сотрудничества с компанией в случае, если им станет известно о найме подобных работников, поскольку бытует мнение, что преступнику нельзя доверять безопасность систем клиентов. В действительности это дело принципа. Некоторые просто не желают видеть, как хакеры-преступники получают что-либо, напоминающее вознаграждение за их противозаконную деятельность.
   Иногда компании полагают, что разумнее сделать наоборот: Если о хакере уже слышали (даже если у него скандальная репутация), то, вероятно, компании испытывают определенное желание принять на работу такого высококлассного профессионала. Будет ли от этого положительный эффект? Это зависит от сферы деятельности компании. Конечно, если вы говорите о компании, предоставляющей сервисные услуги, то люди могут колебаться, но меньше, чем в случае, когда компания тестирует безопасность компьютерных систем.
   В целом это палка о двух концах. Ну и конечно, у хакеров всегда есть вопрос к компаниям, которые «не нанимают хакеров»: «Как вы об этом узнали?»
   Чтобы рассказать о том, как злоумышленник будет преодолевать нашу защиту, авторам потребуется выступить в его роли. Означает ли это, что, информируя читателя о методах взлома, авторы в то же время сообщают их и «злоумышленникам»? Да. Но авторы полагают, что в этой игре все должны иметь равные права: все стороны должны быть вооружены одними и теми же общедоступными методами. А с другой стороны, как вы сможете отличить законопослушного пользователя от злоумышленника?

Обзор содержимого книги

   В трех последующих главах книги представлен минимум теоретического багажа знаний. В главе 2 исследуется сформулированный авторами список законов, которые определяют работу (или отказ) систем компьютерной безопасности. Далее в книге вы увидите, как можно применять эти законы в хакерских технологиях. В главе 3 описываются типы атак и возможный потенциальный ущерб компьютерной системы в случае их успешного осуществления, а также приведены примеры каждого типа атак. В главе 4 рассказывается о различных методологиях, которыми кто-нибудь (например, вы) может руководствоваться при обнаружении проблем безопасности. Первые четыре главы этой книги должны быть доступны читателям любого уровня подготовки. Читатели с высоким уровнем профессиональной подготовки могли бы пропустить эти главы, если они уже знакомы с излагаемой теорией, но мы рекомендуем им, по крайней мере, просмотреть текст и удостовериться в отсутствии для них новой информации в изложенном материале. Раздел «Краткие выводы» хорошо подходит для этих целей.
   Начиная с пятой главы мы рассматриваем методы хакинга. Глава 5 описывает простейший метод хакинга – поиск различий (diffing), состоящий в простом сравнении кода до и после осуществления некоторого действия. Это удивительно полезно. Материал данной главы доступен даже новичкам.
   Глава 6 – о криптографии и различных средствах обеспечения конфиденциальности информации. В главе исследуются дилетантские попытки шифрования, примеры использования которых в мире наблюдаются почти каждый день. Вы познакомитесь с распознаванием шифров, основами их вскрытия и очень простыми криптоподобными схемами кодирования. Эта глава не рассчитана на уровень подготовки выше среднего (в главе приводится вводный материал для читателей с небольшим опытом в рассматриваемой области).
   Глава 7 посвящена проблемам безопасности, возникающим при программных сбоях в результате непредсказуемого ввода данных пользователем. К ним относится хакинг сервера через дефектную программу CGI интерфейса, получение SQL доступа при помощи Web-формы или сценария, позволяющего вскрыть командный процессор операционной системы UNIX обманным путем (tricking scripts). (С технической точки зрения сюда же можно отнести переполнение буфера и ошибки форматирования строк (format string holes), но этим вопросам посвящены отдельные главы.) Глава по уровню предполагаемой подготовки читателя заслуживает оценки от средней до высокой. Это обусловлено обсуждением различных языков программирования и необходимостью понимания принципов работы командной оболочки.
   В главах 8 и 9 показаны методы использования машинно-ориентированного языка для максимального использования преимуществ переполнения буфера или ошибок форматирования строк. Эти главы предполагают высокий уровень подготовки читателя. Но написаны они вполне доступно, с подробным объяснением изложенного материала. Для усвоения материала потребуются определенные знания языка C и ассемблера.
   Глава 10 описывает возможности применения мониторинга сетевых коммуникаций sniffing методами в интересах хакинга. Приведены простые примеры. Описано, при помощи каких протоколов лучше всего получить доступ к паролям, и даже приведены основы программирования мониторинга сетевых коммуникаций методами sniffing. Эта глава ориентирована на читателей с начальным и средним уровнями подготовки.
   Глава 11 представляет тему, посвященную пиратским подключениям (hijacking connections). В большинстве случаев эта разновидность взлома является расширенным применением мониторинга сетевых коммуникаций методами sniffing за счет активного участия злоумышленника. В главе описан тип атак «злоумышленник посередине» (man-in-the-middle). Для изучения приведенного материала требуется средний уровень квалификации читателя.
   Глава 12 обсуждает концепцию доверия и то, как ниспровергать ее при помощи имитации соединения (spoofing). Эта глава обсуждает ряд потенциальных нападений и требует уровеня подготовки читателя от среднего до высокого.
   Глава 13 описывает механизм туннелирования для перехвата сетевого трафика посредством враждебного сетевого окружения (настолько надежным способом, что при перегрузке перехват возобновляется). Приводится подробное обсуждение SSH, для которого требуется уровень подготовки от среднего до высокого.
   Глава 14 – о хакерстве аппаратных средств компьютера. Эта глава приводит основные сведения о хакерстве аппаратных средств ЭВМ с целью получения максимальной безопасности. Это ознакомительная глава, потому что фактическая реализация приведенных методов потребует высокой подготовки.
   Глава 15 посвящена вирусам, Троянским коням и червям. Описано, не только чем они являются и как работают, но также принципы их построения, используемые ими методы и что ожидать в будущем. Это глава по сложности излагаемого материала занимает промежуточный уровень.
   В главе 16 описаны способы, при помощи которых системы обнаружения вторжения уклоняются от атак или обезвреживают их. Также описаны уловки (ловкие приемы), которые эффективны на уровнях от сетевого до уровня приложений. Разобраны такие темы, как фрагменты и использование полиморфизма. Уровень сложности обсуждаемого материала – от среднего до сложного (читатель должен хорошо знать протокол TCP/IP).
   В главе 17 обсуждается автоматизация некоторых из задач читателя при помощи автоматизированного обозревания безопасности и инструментов нападения (после того как читатель познакомится с правилами их написания). Обсуждение охватывает коммерческие и свободно распространяемые программные средства. Это позволяет хорошо представить следующее поколение программных средств, которые будут не только определять уязвимости тестируемой системы, но и позволят укрепить ее.
   Последнее, но не менее важное. В главе 18 сообщается о действиях читателя при обнаружении проблем безопасности. Не подумайте, что авторы книги не поощряют обнаружение брешей в системе защиты информации. Поощряют, но при условии, что читатель несет полную ответственность за свои действия.

Правовое обеспечение хакинга

   В этой книге читатель узнает о методах, которые в случае неправильного их применения приведут его к нарушению законодательства и связанным с этим последствиям. Слова автора подобны словам инструктора по вождению автомобиля: «Я собираюсь научить вас ездить на автомобиле, но если вы водите плохо, то можете кого-нибудь сбить». В обоих случаях вам придется отвечать за причиненный ущерб.
   Автор использует очень простое правило, заключающееся в ответе на вопрос: «У меня есть разрешение сделать это на этом компьютере?» Если ответ – нет, то не делайте этого. Ваши действия принесут вред и почти наверняка будут противозаконны. Но если ответ не столь очевиден, то, возможно, есть исключения, ну и т. д. Например, в большинстве мест (нет, не в вашей организации, по этому поводу проконсультируйтесь у юриста) сканирование порта разрешено. Хотя это рассматривается как предпосылка к незаконному проникновению в систему со злым умыслом, но это законно – кроме тех случаев, когда сканирование портов запрещено.
   Самый простой способ обезопасить себя заключается в хакинге своей собственной сети (автор подразумевает домашнюю сеть читателя, а не сеть на работе, потому что иначе у вас могут быть неприятности). Вы хотите освоить тонкости сложной программы, работающей на платформе Sun Sparc? Идите и купите старый Sparc за 100$. Вы хотите заняться хакерством на многомиллионной универсальной ЭВМ? Хорошо, но, вероятно, вас постигнет неудача.
   Можно было бы склониться к предположению о полной безопасности хакерских действий на собственном оборудовании. Но, строго говоря, это не так в случае действий, направленных на вскрытие программного обеспечения. Много людей думают также, то есть если я купил копию программы, то я имею естественное право делать с ней все, что я захочу на своем собственном компьютере. Право интеллектуальной собственности так не считает. В Соединенных Штатах, а также в соответствии с международным соглашением в ряде других стран обход средств недопущения копирования материалов, защищенных авторским правом, противозаконен. Это – часть акта DMCA. Формально противозаконно заниматься этим даже у себя дома, но если вы все-таки сделали это и пользуетесь результатами своих действий только сами, то кажется маловероятным, что у вас появятся проблемы. Но при попытке поделиться полученными результатами с другими людьми вам следует проявить осторожность.
   Предупреждая о безопасности, автор хотел бы рассказать о чрезвычайной истории, произошедшей в результате нарушения новых законов. Это касается российской компании – разработчика программного обеспечения ElcomSoft Co. Ltd., специализирующейся на вскрытии паролей, снятии защиты от копирования и восстановлении поврежденных файлов. Имейте в виду, что на тот момент времени в России не было никакого закона против восстановления алгоритма работы программы по ее коду. Один из программистов компании ElcomSoft Co. Ltd., Дмитрий Скляров, прибыл на конференцию DEF CON 9 в Лас-Вегасе и сделал доклад относительно формата электронных документов eBook компании Adobe. Формат содержит некоторые смехотворные попытки безопасности. На следующий день Дмитрий был арестован и обвинен в «распространении изделия, предназначенного для обхода средств защиты авторского права». При этом упоминалась программа его компании, которая конвертировала формат eBook документа в стандартный формат Adobe Acrobat.PDF файлов. Выполнение подобного конвертирования покупателем одного из этих средств eBooks для себя юридически законно, поскольку пользователю разрешается делать резервные копии.
   Короче говоря, Дмитрий был арестован 17 июля 2001 года и отпущен домой только 31 декабря 2001 года. Компания Adobe отозвала свою жалобу из-за повсеместных протестов, но американское правительство отказалось снять обвинения. Поскольку вопрос не закрыт до сих пор, Дмитрий все еще полностью не освобожден от ответственности.
   Относительно сказанного хочется добавить, что используемые им методы для разгадывания системы безопасности изделия были относительно просты. Мы осветим подобные методы декодирования в главе 6.
   Пожалуйста, будьте осторожны с информацией, которая изложена в книге.

Конспект

   В этой книге авторы собираются рассказать о подробностях поиска брешей в системе безопасности и их использования на основании таких методов, как анализ пакетов, пиратское подсоединение, имитация соединения для получения доступа, схем раскрытия шифров, уклонение от систем обнаружения атак и даже хакинг аппаратных средств ЭВМ. Это не книга о проектировании безопасности, политике, архитектуре, управлении рисками или планировании. Если читатель так думает, то его ввели в заблуждение.
   Все обнаруженные бреши в системе защиты должны быть преданы огласке. Публичное сообщение об ошибках приносит пользу каждому, включая вас самих, поскольку это может способствовать вашему признанию.
   Вы должны научиться хакерским методам, для того чтобы знать, как защитить вашу сеть или сеть вашего работодателя. Вы должны это знать, потому что это интересно. Если вы не соглашаетесь с чем-либо, о чем говорится в этой главе или книге, то это хорошо! Первое, что хакеры должны уметь делать, – это самостоятельно думать. Нет никаких причин для слепой веры в изложенный авторами книги материал. Если у вас есть замечания к книге, то зайдите на Web-сайт www.syngress.com/solutions, найдите адрес электронной почты авторов и пошлите им письмо. Возможно, ваше опровержение будет помещено на сайт.

Часто задаваемые вопросы

   Ответ: Существует два ответа на этот вопрос. Первый, созвучный мыслям многих: хочешь быть хакером – будь им. Второй: если вы называете себя хакером, то будьте готовы к широкому диапазону оценок вследствие большого количества определений слова «хакер» и их двусмысленности. Одни будут думать, что вы только что сказали им, что вы – преступник. Другой, кто сам себя считает хакером, осмеет вас, если вы будет заподозрены в недостаточной квалификации. Некоторые не будут знать, что и подумать, но затем попросят вас о хакерской услуге для себя… Автор советует вам сначала приобрести необходимые навыки и практику. Лучше всего, если кто-либо другой назовет вас хакером.

   Вопрос: Законно ли написание вирусов, Троянских коней и червей?
   Ответ: Фактически (в большинстве случаев) да. Пока. Это утверждение заслуживает серьезного разъяснения. Существует ряд программистов, которые открыто пишут вирусы и делятся результатами своей работы. До сих пор они, кажется, никому не мешали. Однако если хотя бы часть написанного ими кода выйдет из-под контроля и привлечет к себе внимание, то дело примет серьезный оборот. Если вы пишете программы вирусов, будьте осторожны, чтобы не потерять контроль над ними. Вы можете захотеть ограничить их способность к распространению, проявляя необходимую предосторожность. В этой связи задумайтесь, как вы будете выглядеть, если кто-то доработает ваш вирус и выпустит его на волю. Также обратите внимание на то, не противоречит ли отправление по почте подобного кода правилам, установленным вашим Интернет-провайдером, особенно если вы – учащийся. Ваши действия могут и не противоречить установленным правилам, но могут легко привести к разрыву соединения с вашим Интернет-провайдером, получения предупреждения или лишения вас прав пользователя.

   Вопрос: Несете ли вы ответственность за хакинг систем?
   Ответ: Вообще, если вы санкционированный (авторизованный) пользователь, нет. Пожалуйста, примите во внимание если. Когда есть сомнения, получите письменное разрешение от юридического лица – владельца компьютерной системы, например школы или работодателя. Множество людей, отвечающих за безопасность компьютерных систем, регулярно тестируют их хакерскими методами. Дополнительные сведения и примеры вы сможете найти по адресу www.lightlink.com/spacenka/fors.

Глава 2
Законы безопасности

   В этой главе обсуждаются следующие темы:
   • Обзор законов безопасности
   • Закон 1. Невозможно обеспечить безопасность клиентской части
   • Закон 2. Нельзя организовать надежный обмен ключами шифрования без совместно используемой порции информации
   • Закон 3. От кода злоумышленника нельзя защититься на 100 %
   • Закон 4. Всегда может быть создана новая сигнатура кода, которая не будет восприниматься как угроза
   • Закон 5. Межсетевые экраны не защищают на 100 % от атаки злоумышленника
   • Закон 6. От любой системы обнаружения атак можно уклониться
   • Закон 7. Тайна криптографических алгоритмов не гарантируется
   • Закон 8. Без ключа у вас не шифрование, а кодирование
   • Закон 9. Пароли не могут надежно храниться у клиента, если только они не зашифрованы другим паролем
   • Закон 10. Для того чтобы система начала претендовать на статус защищенной, она должна пройти независимый аудит безопасности
   • Закон 11. Безопасность нельзя обеспечить покровом тайны
   · Резюме
   · Конспект
   · Часто задаваемые вопросы

Введение

   Для обнаружения уязвимостей в безопасности компьютерных систем используется ряд экспресс-методов (shortcuts). Один из них основан на мысленном составлении списка требований, которым должна удовлетворять исследуемая система. Каждое требование из этого списка несет информацию о безопасности системы и может быть проанализировано. Выявление при подобном анализе специфических особенностей в работе системы позволяет подозревать ее в ненадежности еще до начала детального тестирования.
   Этот список назван законами безопасности. Причем под законами понимаются руководящие принципы, которые должны использоваться для того, чтобы не упустить из виду вопросы безопасности при анализе или проектировании системы. Система в этом случае может состоять как из единственной программы, так и полномасштабной сети компьютеров, включая сетевые экраны (firewalls), фильтрующие шлюзы (filtering gateways) и вирусные сканеры. Не важно, в чьих интересах исследуется система: в интересах защиты или нападения. Важно понять, где у нее уязвимости.
   Законы безопасности помогают распознать слабые места и сосредоточить на них внимание. Эта глава познакомит читателя с законами безопасности. Большая часть остальной части книги посвящена подробному рассмотрению методов использования уязвимостей, выявленных при помощи законов безопасности.
   Если читатель достаточно квалифицирован в области информационной безопасности, то он может пропустить эту главу. Хотя авторы рекомендуют, по крайней мере, бегло просмотреть ее, чтобы удостовериться в том, что читатель знает эти законы и согласен с ними.

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

   1. Невозможно обеспечить безопасность клиентской части.
   2. Нельзя организовать надежный обмен ключами шифрования без совместно используемой порции информации.
   3. От кода злоумышленника нельзя защититься на 100 %.
   4. Всегда может быть создана новая сигнатура кода, которая не будет восприниматься как угроза.
   5. Межсетевые экраны не защищают на 100 % от атаки злоумышленника.
   6. От любой системы обнаружения атак можно уклониться.
   7. Тайна криптографических алгоритмов не гарантируется.
   8. Шифрование без ключа является кодированием.
   9. Пароли не могут надежно храниться у клиента, если только они не зашифрованы другим паролем.
   10. Для того чтобы система начала претендовать на статус защищенной, она должна пройти независимый аудит безопасности.
   11. Безопасность нельзя обеспечить покровом тайны.
   Известны различные точки зрения на законы безопасности. В этой главе авторы решили обратить особое внимание на теоретические основы безопасности систем или, другими словами, на строгие формулировки законов. (По крайней мере, настолько, насколько это возможно. Такой сложный предмет исследования, как безопасность систем, плохо поддается строгому математическому описанию.) Существует и иной способ построения списка законов: в список включается не то, что является возможным, а то, что применяется на практике. Естественно, что отчасти эти два принципа перекрываются: если что-то невозможно, то это нереализуемо на практике. Скотт Кулп (Scott Culp), менеджер консультационного центра по вопросам безопасности компании Микрософт (Microsoft's Security Response Center Manager), сформулировал десять законов на основе своего опыта и опыта клиентов. Он назвал этот список как «Десять абсолютных законов безопасности». К ним относятся следующие:
   1. Закон № 1: Если злоумышленник смог убедить вас запустить его программу на вашем компьютере, то компьютер уже не ваш.
   2. Закон № 2: Если злоумышленник может изменить операционную систему на вашем компьютере, то компьютер уже не ваш.
   3. Закон № 3: Если злоумышленник имеет неограниченный физический доступ к вашему компьютеру, то компьютер уже не ваш.
   4. Закон № 4: Если вы позволяете злоумышленнику загружать программы на ваш Web-сайт, то Web-сайт уже не ваш.
   5. Закон № 5: Слабые пароли сводят на нет хорошую систему безопасности.
   6. Закон № 6: Компьютерная система защищена настолько, насколько заслуживает доверия обслуживающий ее администратор.
   7. Закон № 7: Безопасность зашифрованных данных определяется безопасностью ключа их расшифровки.
   8. Закон № 8: Устаревший сканер вирусов ненамного лучше никакого.
   9. Закон № 9: Абсолютная анонимность практически недостижима ни в реальной жизни, ни в Web-пространстве.
   10. Закон № 10: Технология – не панацея.
   Полный список (с разъяснениями смысла каждого правила) может быть найден на сайте www.microsoft.com/technet/columns/security/10imlaws.asp. Этот список приведен для иллюстрации подхода к теме с точки зрения администратора безопасности. По большей части читатель найдет, что приведенные законы – обратная сторона исследуемых авторами законов безопасности.
   Перед применением законов для обнаружения потенциальных проблем следует сформулировать их рабочее определение. В следующих разделах рассмотрены законы безопасности и их значение для обеспечения безопасности вычислительных сетей и систем.

Закон 1. Невозможно обеспечить безопасность клиентской части

   В первом законе безопасности следует определить пару понятий. Что именно имеется в виду, когда говорят о клиентской части (client-side)? Рассматривая сетевое (клиент-серверное) окружение, авторы определили бы клиента как приложение, которое инициирует запрос на обслуживание или соединение, а сервер – как приложение, которое или ожидает запрос на обслуживание и установление связи, или способно выполнять эти запросы. Термин «клиентская часть» применительно к вычислительным сетям используется для обозначения компьютера, за которым работает пользователь и при помощи которого пользователь (или злоумышленник) получает контроль над системой. В сформулированном законе отличие в использовании термина «клиентская часть» заключается в том, что он применяется без связи с какой-либо сетью или сервером, то есть авторы говорят о безопасности клиентской части даже в случае одного компьютера с частью программного обеспечения на дискете. Главное состоит в том, что подчеркивается мысль о возможности получения контроля пользователей (или злоумышленников) над собственными компьютерами и их способности сделать с ними все, что они захотят.
   После определения термина клиентской части выясним, что понимается под ее безопасностью. Безопасность клиентской части – это некоторый механизм безопасности, работающий исключительно у клиента. В одних случаях его реализация допускает привлечение сервера, как в традиционной архитектуре клиент-сервер. В других – это может быть частью программного обеспечения, которое выполняется на компьютере клиента в интересах предотвращения действий пользователя, нежелательных с точки зрения безопасности.
   Основная проблема безопасности клиентской части состоит в том, что человек, физически сидящий за клиентским компьютером, имеет абсолютный контроль над ним. Закон № 3 Скотта Кулпа (Scott Culp) иллюстрирует это более упрощенным способом: Если у злоумышленника неограниченный физический доступ к вашему компьютеру, то компьютер уже не ваш. Для полного понимания тонких моментов этого вопроса требуются дополнительные разъяснения. Вы не сможете разработать механизм безопасности клиентской части, который пользователи не смогли бы, если они этого захотят, преодолеть. В лучшем случае вы сможете усложнить им эту задачу. Проблема состоит в том, что поскольку большинство программного обеспечения и аппаратных средств ЭВМ – результат массового производства, то один профессионал, разгадавший, как обойти механизм безопасности, может, вообще говоря, рассказать кому-либо об этом или часто пользоваться результатами своего решения. Посмотрите на пакет программ, в котором предусмотрено ограничение его использования тем или иным способом. Какие инструменты нападающий имеет в его или ее распоряжении? Он или она могут использовать отладчики, дизассемблеры, редакторы шестнадцатеричного кода, модификацию операционной системы и системы мониторинга, не говоря уже о неограниченных копиях программного обеспечения.
   А если программное обеспечение обнаружит, что оно было модифицировано? Тогда удалите часть кода, которая обнаруживает модификацию. Что, если программное обеспечение скрывает информацию где-нибудь в компьютере? Контролирующие механизмы немедленно найдут это изменение. Имеется ли защита аппаратных средств ЭВМ от преступного использования? Нет. Если нарушитель может потратить неограниченное время и ресурсы, атакуя аппаратные средства вашего компьютера, то любое средство защиты в конечном счете признает себя побежденным. Это особенно справедливо для аппаратуры массового производства. Поэтому в общем случае следует полагать, что безопасность клиентской части невозможно обеспечить.
   Примечание
   Этот закон используется в главах 5 и 14.

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

   Для иллюстрации этого давайте рассмотрим процесс установления зашифрованной связи через Интернет. Пусть как на вашем компьютере, как и на компьютере, с которым вы, как предполагается, соединяетесь, установлена ныне модная программа CryptoX. Вы вводите известный вам IP-адрес другого компьютера и ударяете на клавишу Connect (установить соединение). Программное обеспечение сообщает вам об установке соединения и обмене ключами. Теперь вам доступна надежная связь с 1024-битным шифрованием. Следует ли вам верить этому? Да, следует. Ведь за простым интерфейсом работы этой программы скрывается сложная криптоинфраструктура, обеспечивающая описанный процесс соединения (позднее в этой главе будет объяснено, что это означает). К сожалению, похитить IP-связь не только не невозможно, но даже не слишком трудно (см. главу 11).
   Проблема состоит в том, как узнать, с каким компьютером вы обменялись ключами. Вы могли установить соединение именно с тем компьютером, с которым вы и хотели осуществить обмен, так и со злоумышленником, ожидающим ваших действий по установке соединения, для того чтобы попытаться подменить IP-адрес компьютера, с которым вы соединяетесь, на свой. Единственный способ удостовериться в факте соединения с требуемым компьютером состоит в наличии на обоих компьютерах порции информации, которая позволила бы удостовериться в идентичности друг друга. Как это осуществить? Сразу приходит на ум пара методов. Во-первых, можно воспользоваться открытыми ключами, распространяемыми сертификационными центрами в Интернете. Во-вторых, можно использовать разделяемый секретный ключ или средства аутентификации протокола защищенных сокетов SSL, гарантирующего безопасную передачу данных по сети в результате комбинирования криптографической системы с открытым ключом и блочного шифрования данных. Конечно, все перечисленное является разделяемыми порциями информации, необходимой для проверки отправителя информации.
   Отсюда следует необходимость решения задачи управления ключами, поэтому исследуем некоторые аспекты этого процесса, ответив на следующие вопросы. Как переслать ключи туда, где они необходимы? Защищен ли маршрут распространения ключей от злоумышленника, готового к атаке типа «злоумышленник посередине» (man-in-the-middle – MITM)? Какие затраты ресурсов необходимы и насколько оправдано их использование по отношению к ценности защищаемой информации? Участвует ли доверенное лицо в обмене ключей? Может ли оно быть атаковано? Какие методы используются для обмена ключей и насколько они уязвимы?
   Давайте рассмотрим некоторые способы распределения и обмена ключами. После обмена ключами шифрования нужна дополнительная информация, чтобы удостовериться в том, что обмен состоялся именно с тем, с кем нужно, и ключи не стали добычей злоумышленника в результате его успешной атаки типа MITM. Доказать это трудно потому, что доказательство сводится к рассмотрению всевозможных протоколов обмена ключами, которые когда-либо могли быть изобретены, и поиску уязвимости каждого из них к атакам типа MITM.
   Как и в случае большинства нападений, может быть, разумнее всего положиться на то, что люди, как правило, не следуют хорошим советам по обеспечению безопасности, или на то, что результат шифрования обычно менее криптостоек, чем примененный алгоритм шифрования.
   Это – документ компании Cisco Systems, Inc., который описывает, помимо всего прочего, как обмениваться ключами стандарта цифровой подписи DSS. DSS – стандарт открытых/секретных ключей (public/private key standard), который Cisco использует для аутентификации одноранговых маршрутизаторов. Шифрование с использованием открытых/секретных ключей обычно считается слишком медленным для шифрования в реальном масштабе времени, поэтому для обмена информацией применяются симметричные сеансовые криптографические ключи (типа ключей DES или 3DES алгоритмов). DES – американский правительственный стандарт алгоритма шифрования, принятый в 70-х годах. 3DES – улучшенная версия алгоритма DES, связывающая вместе три отдельных выполнения алгоритма DES для двукратного или трехкратного, в зависимости от реализации, повышения криптостойкости алгоритма. Для успешной работы по описываемой схеме у каждого маршрутизатора должен быть правильный открытый ключ другого маршрутизатора. Если в случае атаки типа MITM злоумышленнику удастся обмануть каждый маршрутизатор, подсунув свой ключ вместо открытого ключа другого маршрутизатора, то сначала он сможет узнать все ключи сессии, а затем контролировать любой трафик сети.
   Cisco признает это и идет дальше, заявляя, что вы «должны устно проверить» открытые ключи. В документации описан сценарий, по которому два администратора маршрутизатора, имея безопасную связь с маршрутизатором (возможно, при помощи терминала, физически подключенного к консоли), связываются друг с другом по телефону. Во время обмена ключей они должны сообщить друг другу по телефону полученный ключ. Безопасность этого сценария основывается на предположении, что, во-первых, эти два администратора узнают голос друг друга, а во-вторых, трудно фальсифицировать чей-либо голос.
   Если администраторы хорошо знают друг друга и каждый из них сможет получить ответы на свои вопросы, если они оба зарегистрированы на консоли маршрутизаторов и маршрутизаторы не скомпрометированы, если нет ошибок в алгоритме шифрования, то эта процедура безопасна.
   Никто не собирается учить вас подражанию чьему-либо голосу или как захватывать коммутаторы телефонных компаний для неправильного соединения незнакомых друг с другом администраторов. В первую очередь критически разберем предположение о достижении безопасности при использовании двух администраторов и рассмотренного механизма безопасности.
   Есть подозрение, что вопреки документации компании Cisco большинство обменов ключами между маршрутизаторами этой компании осуществляются одним администратором с использованием двух Telnet-окон. Если дело обстоит именно так и если злоумышленник в состоянии сыграть роль «нарушителя посередине» и похитить Telnet-окна и ключевой обмен, то он сможет взломать зашифрованную передачу данных.
   Сформулируем выводы. Безопасность сети не может быть обеспечена в большей степени, чем безопасность наиболее уязвимого соединения. Если в нашем примере маршрутизатор может быть взломан и похищены секретные ключи, то не нужно никаких атак типа MITM. Кажется, в настоящее время компания Cisco уделяет большое внимание совершенствованию защиты секретных ключей. Их не могут просматривать даже уполномоченные администраторы. Однако ключи хранятся в памяти. Тот, кто захочет вскрыть маршрутизатор и воспользоваться той или иной разновидностью циклического опроса, сможет легко восстановить секретный ключ. К тому же до последнего времени в IOS Cisco не было проведено открытого изучения вопросов переполнения буфера и т. п. Авторы уверены, что когда-нибудь это произойдет, поскольку ряд известных нападений убедительно свидетельствует о возможности переполнения буфера.
   Другой способ реализации обмена заключается в использовании протокола SSL вашим браузером. При нормальном режиме обмена информацией, если от вас не запросили никакой информации, криптозащита должна быть отключена. Как в этом случае работает протокол SSL? Когда вы посещаете защищенную Wed-страницу, то от вас не требуется никаких действий по обеспечению безопасности. Подразумевает ли это, что SSL – жульничество? Нет, некоторая часть информации действительно используется совместно. Прежде всего это открытый ключ основного сертификата полномочий. Всякий раз, когда вы загружаете программное обеспечение браузера, оно активизирует встроенные в программу сертификаты. Эти сертификаты содержат необходимую информацию для обеспечения безопасности. Да, сохраняется вероятность атаки типа MITM во время загрузки файла. Если кто-то подпортил файл во время его нахождения на сервере, с которого файл был загружен, или во время загрузки по пути к вашему компьютеру, то теоретически весь ваш трафик по протоколу SSL может быть скомпрометирован.
   SSL особенно интересен, так как это один из лучших работающих образцов массового рынка средств обеспечения защиты, поскольку он управляет ключами и т. д. Конечно, протокол не без недостатков. Если вам интересны технические детали работы SSL, посетите сайт: www.rsasecurity.com/standards/SSL/index.html.
   Примечание
   Этот закон используется в главе 6.

Закон 3. От кода злоумышленника нельзя защититься на 100 %

   В течение последних лет зафиксировано увеличивающееся число атак, которые использовали слабые места в операционных системах и прикладном программном обеспечении для получения доступа к системам пользователя. Недавно мы стали свидетелями широкомасштабных разрушений сервисов и потери данных в результате быстрой модификации ряда программ и их повторной загрузки в Интернет. Почему это произошло? Потому, что нельзя на 100 % защититься от разрушительного кода, когда он изменяется так быстро, как теперь. Авторы рассмотрят некоторые примеры на эту тему в следующем разделе и обсудят в качестве примера способ защиты против вирусов.
   Если, подобно большинству людей, вы работаете с Windows-подобной операционной системой, то вы запускаете антивирусные программы. Возможно, вы даже прилежно обновляете ваши средства обнаружения вирусов современными копиями. Вы полностью защищены от вирусов? Конечно, нет.
   Давайте посмотрим, какими бывают вирусы и Троянские кони (программы, которые выдают себя за другие программы с целью получения информации) и как они попадают на ваш компьютер. Вирусы и Троянские кони – просто программы, каждая из которых имеет специфическую характеристику. Вирусы размножаются, и им нужны другие программы, к которым они присоединяются. Троянские кони выдают себя не за то, чем они на самом деле являются. В основном это программы, которые программист разработал для выполнения чего-то такого, чего бы вы вообще никогда не допустили, если бы знали про это. Эти программы обычно попадают на ваш компьютер обманным путем. Они скрывают свое истинное предназначение, присоединяясь к нужным вам программам или, находясь на носителях информации, которыми вы пользуетесь, не зная об их инфицировании. Они могут попасть к вам и в результате действий удаленного злоумышленника, вскрывшего вашу систему безопасности.
   Как работает антивирусное программное обеспечение? Перед выполнением программы антивирусные средства сканируют ее код или носитель информации для определения «вредных штучек», которые обычно состоят из вирусов, Троянских коней и даже потенциального инструментария хакера. Тем не менее имейте в виду, что только разработчик вашего антивирусного программного обеспечения определяет, что именно проверяется. Это справедливо при условии, что у вас нет ни времени, ни инструментария для формирования собственных файлов сигнатур. Файлы сигнатур – основа большинства антивирусных программ. Они обычно состоят, как хочется верить, из уникальных для отдельного вируса или Троянского коня порций двоичных данных. Поэтому если на ваш компьютер попадает не зафиксированный в базе данных вирус, то ваше антивирусное программное обеспечение вам помочь не сможет.
   Почему процесс обезвреживания новых вирусов такой медленный? Чтобы сформировать файл сигнатур, разработчик антивирусного программного обеспечения должен получить копию вируса или Троянского коня, проанализировать ее, сформировать уникальную для нового вируса сигнатуру, модернизировать файл сигнатур (а иногда еще и антивирусную программу) и опубликовать обновления – скорректированную версию программного обеспечения. После этого конечный пользователь должен установить и применить обновленную программу. Вы можете себе представить, насколько большими могут оказаться задержки времени от момента получения информации о новом вирусе до его обезвреживания. И все это время пользователи уязвимы.
   Из-за контролирующих действий антивирусного программного обеспечения вы не сможете вслепую запустить на выполнение какую-либо программу или просто так загрузить любое приложение. Не так давно на антивирусное программное обеспечение обычно можно было положиться из-за медленной скорости размножения вирусов по вине людей, переносящих их на дискетах, или при помощи зараженных общих программ. Сейчас, в связи с ростом числа подключенных к Интернету компьютеров, возможность соединения компьютеров между собой стала очень привлекательным транспортным средством для вирусов. Они распространяются через Web-страницы, электронную почту и загрузку приложений по каналам связи. Сейчас намного больше шансов увидеть новый вирус прежде, чем производитель вашего антивирусного программного обеспечения опубликует обновления. И не забудьте, что сделанный на заказ вирус или Троянский конь может быть написан специально для инфицирования вашего компьютера в любое время. При этих обстоятельствах ваше антивирусное программное обеспечение никогда не спасет вас.
   Поскольку целая глава этой книги посвящена вирусам и Троянским коням, то авторы опустят многие детали написания вирусов или обмана людей посредством Троянского коня во время его выполнения. Будет лучше, если авторы приведут их любимый пример на тему вирусов. В апреле 2000 года пользователи Интернета впервые познакомились с вирусом «I love you». Это был еще один представитель вирусных червей (программ, самостоятельно распространяющих свои копии по сети). Вирус «I love you» выполнялся совместно с программой электронной почты Microsoft Outlook. Он обладал гораздо большим разрушительным эффектом в результате рассылки самого себя всем адресатам адресной книги, а не первым пятидесяти, как более ранний вирус «Мелисса». Но, несмотря на усилия разработчиков антивирусного программного обеспечения и других специалистов по сдерживанию вируса, он быстро распространялся и порождал множество имитаторов вирусов за короткий промежуток времени после своего возникновения. Почему его не смогли остановить быстрее? В случае ряда моих клиентов – из-за слишком большого числа служащих, которые не смогли сопротивляться желанию узнать, кто их так сильно любит! Ограничение распространения вирусов не всегда входит в компетенцию вашей безопасности или программного обеспечения, следящего за безопасностью вашего компьютера.
   От Троянских коней и вирусов фактически можно было бы полностью защититься, если бы пользователи изменили свое поведение. Хотя после этого они, вероятно, не смогли бы многого от своего компьютера. Пользователи были бы вынуждены установить только то программное обеспечение, которое было получено непосредственно от доверенного производителя. (Однако было несколько случаев коммерческой продажи программ с вирусами на носителях информации.) Вероятно, пользователи должны были бы воздержаться от применения сети и никогда не обмениваться информацией с кем-либо еще. И конечно, должна быть обеспечена физическая безопасность компьютера.
   Примечание
   Этот закон используется в главе 15.

Закон 4. Всегда может быть создана новая сигнатура кода, которая не будет восприниматься как угроза

   Этот закон сравнительно нов в обсуждении вопросов безопасности, но за последний год он стал очень популярен. Это новая реальность, поскольку теперь у злоумышленников появилась возможность изменять существующие вирусы, Троянские кони и удаленно управляемые приложения почти одновременно с моментом выпуска их на волю. Это приводит к необходимости обсуждать новые проблемы. Если продолжить обсуждение на примере антивирусной защиты, то можно обнаружить, что даже незначительное изменение в коде вируса дает ему шанс стать невидимым для антивирусного программного обеспечения. Эти проблемы ранее доставляли гораздо меньше беспокойства. Несомненно, кто-то должен был заразиться вирусом первым, после чего их системы переставали работать, но были большие шансы, что это случится не с вами. К тому времени, когда вас заражал тот же вирус, производители ваших антивирусных программ имели нужную копию, и вы обновляли свои файлы.
   Теперь это не так. Ряд новейших вирусов размножается намного быстрее. Многие из них используют электронную почту для рассылки себя среди пользователей. Некоторые даже маскируются под вас и используют грубую форму социотехники для обмана ваших друзей и проникновения в их компьютеры. В этом году многие стали свидетелями подобного происшествия, наблюдая за различными версиями вируса «Code Red», который распространился по всему миру. Если вспомните, первоначальная версия имела возможность запуска по времени и дате с запрограммированным нападением на Web-сайт американского правительства. В ряде различных модификаций вируса его поведение было успешно изменено, что привело к быстрому увеличению числа атак и потребовало дополнительного времени для их отражения. Почему это оказалось настолько эффективным? Потому что возможности для модификации кода вируса бесконечны и для этого существуют многочисленные методы. Например, можно модифицировать первоначальный код, чтобы создать новую сигнатуру кода, сжать файл, зашифровать файл, защитив его паролем или иначе изменить, для того чтобы избежать обнаружения кода вируса. В результате будет получена новая сигнатура кода, которая еще не будет признана вирусными сканерами, межсетевыми экранами и системами обнаружения вторжения как угроза, что позволит модифицированному вирусу беспрепятственно их преодолевать.
   Примечание
   Этот закон используется в главах 15 и 16.
Инструментарий
   Хотите проверить межсетевой экран?
   Есть невероятное число свободно распространяемых инструментальных программных средств, доступных вам для проверки собственной уязвимости. Конечно, основные средства включают в себя основные команды протокола TCP/IP, встроенные в протокол: ping, tracert, pathping, Telnet и nslookup помогут быстро оценить уязвимость вашей системы. Наряду с ними у авторов есть пара любимых инструментальных средств, позволяющих быстро исследовать и проверить информацию о различных IP-адресах:
   • Sam Spade от компании SamSpade.org: www.samspade.org.
   Эти два инструментальных средства с богатыми функциональными возможностями позволят вам, по крайней мере, увидеть некоторые из уязвимостей, которые могут существовать на вашей системе.

Закон 5. Межсетевые экраны не защищают на 100 % от атаки злоумышленника

   Межсетевые экраны могут защитить сеть от некоторых типов нападений. Они обеспечивают полезную регистрацию сетевого трафика. Однако, во многом подобно антивирусному программному обеспечению, межсетевые экраны никогда не обеспечат стопроцентную защиту. Фактически они часто обеспечивают гораздо меньшую защищенность.
   Прежде всего, даже если бы межсетевые экраны были бы на 100 % эффективны и отражали бы все проходящие через них атаки, следует понимать, что не все направления нападений проходят через межсетевой экран. Недобросовестные служащие, физическая безопасность, модемы и инфицированные дискеты все еще представляют различные угрозы безопасности. В интересах обсуждения не рассматриваются угрозы безопасности, не связанные с необходимостью их прохождения через сетевые экраны.
   Межсетевые экраны – это устройства и/или программное обеспечение, разработанное для выборочного разделения двух или более сетей. Они предназначены для того, чтобы разрешить прохождение одних потоков информации и запретить другие. Что именно разрешать или запрещать, обычно контролирует человек, управляющий межсетевым экраном. Что разрешено или запрещено, должно быть отражено в письменной форме в политике безопасности, которая разрабатывается в каждой организации.
   До тех пор, пока какому-либо трафику разрешено проходить через межсетевой экран, сохраняется потенциальная угроза нападения. Например, большинство межсетевых экранов разрешают тот или иной доступ к заранее определенным Web-узлам, из защищаемой сети к Web-узлам и обратно или только к Web-серверам. Простейшая реализация подобного варианта доступа основана на фильтрации порта, которая может быть осуществлена маршрутизатором со списками доступа. Простой фильтр трафика по протоколу ICMP, блокируя трафик внешнего интерфейса, запретит прохождение ответов от вашей системы к другой при выдаче команды ping. Для примера воспользуйтесь командами ping или tracert, указав в качестве параметра адрес www.microsoft.com. Вы получите сообщение о превышении интервала ожидания ответа на запрос. Узел компании Микрософт вышел из строя? Вряд ли. Скорее всего, при настройке системы обеспечения безопасности была заблокирована, помимо всего прочего, передача информации по протоколу ICMP. Есть несколько уровней защиты, которые могут предоставить межсетевые экраны для работы в Интернет. Простое конфигурирование маршрутизатора позволит хостам внутренней сети, защищенной межсетевым экраном, получить доступ к любой машине в Интернете по порту 80 протокола TCP, а также любой машине в Интернете послать ответ c 80 порта на любую машину защищенной сети. Более «осторожные» межсетевые экраны могут понимать протокол HTTP, пропуская только разрешенные команды HTTP. Это поможет сравнить сайт, посещаемый пользователем в данный момент, со списком сайтов, запрещенных к посещению. Тем самым можно сразу передавать программе сканирования вирусов файлы, полученные с этих сайтов, для проверки.
   Давайте рассмотрим пример максимально защищенного межсетевого экрана протокола HTTP. Пусть вы администратор межсетевого экрана. Вы сконфигурировали межсетевой экран таким образом, что разрешили только некоторые команды протокола HTTP. Вы разрешаете вашим пользователям посещать только те сайты, которые перечислены в списке из 20 санционированных к посещению сайтов. Вы настроили межсетевой экран таким образом, чтобы не пропускать программы на языках Java, JavaScript и ActiveX. Вы сконфигурировали межсетевой экран таким образом, что разрешили лишь загрузку HTML-файлов и файлов с расширениями gif и jpg.
   Могут ли ваши пользователи чувствовать себя в безопасности за межсетевым экраном, настроенным подобным образом? Конечно, могут. Пусть я буду злым хакером (или возможно, неосведомленным в вопросах безопасности Web-мастером), пытающимся передать свою программу через такой межсетевой экран. Как мне обойти тот факт, что вы разрешили загружать только определенные типы файлов? Я разработаю и вывешу на всеобщее обозрение Web-страницу, которая сообщает вашим пользователям о необходимости нажатия правой копки мыши на jpg-файле для его загрузки на компьютер пользователя, а затем переименую загруженный файл в evil.exe, как только он окажется на вашем жестком диске (имеется в виду, что предварительно внедряемая программа была переименована в jpg-файл). Как преодолеть антивирусное программное обеспечение? Вместо сообщения вашим пользователям о переименовании файла в исполнимый exe-файл я сообщаю им о его переименовании в zip-файл и разархивирую его с использованием пароля «hacker». Ваше антивирусное программное обеспечение никогда не сможет проверить защищенный паролем архивный zip-файл. Пусть вы тем или иным способом не позволите своим пользователям попасть на мой сайт. Нет проблем. Все, что я должен делать, – это взломать один из одобренных вами для посещения сайтов. Однако вместо обычного очевидного искажения информации на сайте я оставлю все как есть, но с маленьким дополнением небольшого кода на JavaScript. К тому времени, когда кто-либо обнаружит эту едва различимую подмену, я наверняка добьюсь своей цели.
   Разве производители межсетевых экранов не знают об этих проблемах? Хакеры и разработчики межсетевых экранов играют в бесконечную игру «догони меня». Производители межсетевых экранов вынуждены ждать, пока хакеры придумают новый тип атаки, поскольку они не знают, как им защититься, и поэтому всегда будут отставать.
   В различных рассылках публикаций по тематике межсетевых экранов можно найти немало философских дебатов по точному определению периметра сетей, защищаемого межсетевыми экранами, но эти обсуждения сейчас неактуальны для нас. Для наших целей важно то, что межсетевые экраны – это коммерческие продукты, продаваемые как аппаратно-программные средства межсетевой защиты, которые, как утверждается, выполняют фильтрацию информации в сети, маршрутизаторах и т. д. В основном нас интересует то, как мы получаем нашу информацию через межсетевой экран.
   Оказывается, есть множество способов подвергнуться нападению через межсетевой экран. В идеале межсетевые экраны осуществляют политику безопасности в полной мере. В действительности межсетевой экран создают люди, поэтому он далек от совершенства. Одна из основных проблем межсетевых экранов состоит в том, что его администраторы с трудом могут ограничить именно тот трафик, который они хотели бы. Например, в политике безопасности может быть заявлено, что разрешен доступ к Интернету по протоколу HTTP и запрещено использование RealAudio. Администратору межсетевого экрана следует запретить порты RealAudio, не так ли? Проблема состоит в том, что люди, которые написали RealAudio, понимая, что подобное может произойти, предоставили пользователю возможность загрузить файлы RealAudio по протоколу HTTP. В действительности если вы при настройке не укажите явно вариант доступа к содержимому RealAudio с Web-сайта, то большинство версий RealAudio выполнит ряд проверок для определения варианта подобного доступа. При этом, если это потребуется, автоматически будет выбран протокол HTTP. Фактически проблема в этом случае состоит в том, что любой протокол может быть туннелирован по любому другому, если только синхронизация по времени не критична (то есть если туннелирование не приведет к чрезмерному замедлению работы). RealAudio выполняет буферизацию, если сталкивается с проблемой синхронизации.
   Разработчики различных интернетовских «игрушек» хорошо осознают, какие протоколы обычно разрешены, а какие нет. Много программ разработано с использованием протокола HTTP в качестве основного или резервного средства переноса информации через сеть.
   Вероятно, существует много способов нападения на компанию, защищенную межсетевым экраном, и без какого-либо воздействия на экран. Можно атаковать, используя модемы, дискеты, взятки и подкуп, взлом компьютерных систем защиты, получение физического доступа к компьютеру и т. д. Но сейчас мы рассматриваем атаки на межсетевой экран.

Социотехника

   Социотехника – это искусство обмана пользователей сети или администраторов, используемое злоумышленниками с целью выведывания паролей, необходимых для проникновения в защищенную систему. Обман – один из первых и наиболее очевидных способов преодоления межсетевого экрана. Электронная почта стала очень популярным средством, с помощью которого предпринимаются попытки обмануть людей, заставив их совершить дурацкие поступки. Вирусы «Мелисса» и «I live you» – наиболее известные примеры подобного обмана. Другими примерами могут служить специально написанные программы, демонстрирующие свое злонамеренное поведение во время выполнения (Троянские кони), или вполне легальные программы, которые были «инфицированы» или взяты под контроль тем или иным способом (Троянские кони/вирусы). В большинстве операций массовой почты низкой скорости реакции пользователя вполне достаточно для успеха. В случае злонамеренной пользовательской программы ущерб может быть особенно значительным, поскольку у антивирусных программ нет шансов обнаружить ее. Для информации о том, что можно сделать с вирусом или Троянским конем, см. главу 15.

Нападение на незащищенные сервера

   Другой способ пройти межсетевой экран состоит в том, чтобы напасть на незащищенные участки сети. Межсетевые экраны образуют демилитаризованную зону (DMZ), в которой размещаются Web-сервера, почтовые сервера и т. д. Известны дебаты относительно того, является ли классическая демилитаризованная зона сетью, находящейся целиком вне действия межсетевого экрана (и поэтому им не защищенной), или демилитаризованная зона – это некоторая промежуточная сеть. В настоящее время в большинстве случаев Web-сервера, почтовые сервера и т. п. относятся к так называемому третьему интерфейсу межсетевого экрана, который защищает их от воздействия извне, не позволяя в то же время компонентам внутренней сети устанавливать с ними доверительные отношения и напрямую принимать от них информацию.
   Проблема для администраторов межсетевых экранов состоит в том, что межсетевые экраны не до конца интеллектуальны. Они могут фильтровать потоки информации, могут требовать выполнения процедуры аутентификации и регистрировать информацию, но они не могут отличить плохой разрешенный запрос от хорошего. Например, автору не известен ни один межсетевой экран, способный отличить легитимный запрос для Web-страницы от нападения с использованием сценария CGI. Конечно, некоторые межсетевые экраны могут быть запрограммированы для поиска некоторых типов CGI-сценариев, которые пытались выполнить (например, *.phf). Но если вы захотите распространить CGI-сценарий для совместного использования, межсетевой экран не в состоянии отличить законных пользователей от атакующего злоумышленника, нашедшего дырку в системе защиты. Многое из сказанного справедливо для протоколов SMTP, FTP и большинства других широко используемых сервисов. Все они уязвимы. (В главе 7 приведены дополнительные сведения о нападениях на сетевые сервисы и примеры атак при помощи CGI-сценариев.)
   Предположим, что вы нашли способ проникнуть на сервер в демилитаризованной зоне. В результате вы получили доступ к корневому каталогу сервера или права администратора на сервере. Означает ли это, что удалось проникнуть во внутреннюю сеть? Пока еще нет. Вспомните, что согласно ранее данному определению демилитаризованной зоны устройства зоны не имеют доступа во внутреннюю сеть. На практике это выполняется не всегда, поскольку очень немногие изъявляют желание заниматься администрированием своих серверов, сидя за консолью. Что, если на FTP-сервере, например, они захотели бы открыть всем, исключая себя, доступ к FTP-портам? И пусть в интересах работы организации наибольшая часть трафика в сети должна проходить от внутренней сети к демилитаризованной зоне. Большинство межсетевых экранов могут работать как диоды, пропуская трафик только в одном направлении. Организовать подобный режим работы сложно, но можно. В этом случае главная трудность проникновения во внутреннюю сеть состоит в том, что вы должны находиться в ожидании наступления определенных событий. Например, если вы поймаете момент начала передачи данных по протоколу FTP или момент открытия администратором во внутренней сети окна XWindow (XWindow окна широко используются в сетевой среде UNIX протокола для многооконного отображения графики и текста), то у вас появится возможность проникнуть во внутреннюю сеть.
   Более вероятно, что вы захотите найти порт, открытый для работы. Многие сайты поддерживают сервисные возможности, для работы которых требуется, чтобы компьютеры демилитаризованной зоны могли инициировать обратную связь с компьютерами внутренней сети. Это может быть электронная почта (почта должна быть доставлена во внутреннюю сеть), поиск по базам данных (например, для сайтов электронной коммерции) и, возможно, механизмы отчетности (вероятно, системные журналы). Попытка проникновения из демилитаризованной зоны во внутреннюю сеть упрощается, потому что вы сможете точно определить момент обмена информацией между демилитаризованной зоной и внутренней сетью. Рассмотрим следующую ситуацию. Предположим, что вам удалось успешно проникнуть на почтовый сервер в демилитаризованной зоне, используя ошибки почтового демона (демон – сетевая программа, работающая в фоновом режиме, или процедура, запускаемая автоматически при выполнении некоторых условий). Появились хорошие возможности наладить связь из демилитаризованной зоны с внутренним почтовым сервером. Возможности хороши, поскольку на внутреннем почтовом сервере выполняется тот же самый почтовый демон, который вы только что взломали, или даже менее защищенный (в конце концов, это – внутренний компьютер, который не предназначен для непосредственной работы с Интернетом, не так ли?).

Прямое нападение на межсетевой экран

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

Бреши в системе безопасности клиентской части

   Один из лучших способов обхода защиты межсетевого экрана основан на использовании ее слабых мест. Кроме уязвимостей Web-браузера, в состав программ с возможными брешами в системе защиты входят такие программы, как AOL Instant Messenger, MSN Chat, ICQ, клиент IRC и даже Telnet и клиенты ftp. Возможно, потребуются дополнительные исследования, терпение и немного удачи, для того чтобы воспользоваться слабыми местами в их системе защиты. Рекомендуется найти пользователя в организации, намеченной для нападения, который сможет запустить одну из этих программ. Многие из программ интерактивной переписки содержат средства обнаружения собеседников, поэтому нет ничего необычного в том, что люди публикуют свой номер ICQ на своей домашней страничке. (I Seek You – система интерактивного общения в Internet, позволяющая находить в сети партнеров по интересам и обмениваться с ними сообщениями в реальном масштабе времени.) Значит, легко найти программу victim.com и номер ICQ, которые будут использованы для обхода системы защиты. А затем дождаться, когда предполагаемый человек будет на работе, и совершить задуманное с использованием его номера ICQ. Если воспользоваться серьезной брешью в системе безопасности, то, вероятно, удастся передать выполнимый код через межсетевой экран, который может сделать все, что вы захотите.
   Примечание
   Этот закон используется в главах 7, 11, 12, 13, 15 и 17.

Закон 6. От любой системы обнаружения атак можно уклониться

   Во время написания книги уже существовали сотни производителей программно-аппаратных средств обнаружения вторжения (IDS – intrusion detection system), объединенных с межсетевыми экранами и средствами защиты от вирусов или реализованных как автономные системы. Принцип работы системы обнаружения вторжения слегка отличается от работы межсетевых экранов. Межсетевые экраны предназначены для остановки небезопасного трафика в сети, а системы обнаружения вторжения – для его определения, но не обязательно его остановки (хотя ряд систем обнаружения вторжения будет взаимодействовать с межсетевыми экранами для запрещения трафика). Системы обнаружения вторжения способны распознать подозрительный трафик при помощи ряда алгоритмов. Одни из них основаны на совпадении трафика с известными образцами нападений, очень схожими с базой данных сигнатур антивирусной программы. Другие проверяют трафик на соответствие правилам оформления трафика и его признаков. Третьи – анализируют признаки стандартного трафика и наблюдаемого на предмет отличия от статистической нормы. Поскольку системы обнаружения вторжения постоянно контролируют сеть, то они помогают обнаружить нападения и необычные условия как внутри сети, так и вне ее и обеспечить новый уровень безопасности от внутреннего нападения.
   От межсетевых экранов, методов обеспечения безопасности клиентской части и от систем обнаружения вторжения можно уклониться и работать с ними в одной сети, не обращая на них внимания. Одна из причин этого заключается в наличии пользователей, работающих на компьютерах внутри сети. Ранее было показано, что по этой причине система становится уязвимой. В случае межсетевых экранов и систем обнаружения вторжения появляется еще одна причина ослабления системы безопасности: хотя при первой установке межсетевых экранов и систем обнаружения вторжения их настройки обеспечивают безопасность, со временем ухудшается обслуживание систем, притупляется осторожность при внесении изменений в их настройки и снижается бдительность. Это ведет ко многим ошибочным настройкам и неверному обслуживанию системы, а в результате появляются предпосылки для уклонения злоумышленника от системы обнаружения вторжения.
   Для злоумышленников проблема с системой обнаружения вторжения состоит в том, что они не смогут определить факт ее присутствия и работы. В отличие от межсетевых экранов, которые легко обнаружить при атаке, системы обнаружения вторжения могут быть полностью пассивными и поэтому незаметными. Они могут распознать подозрительную активность в сети и незаметно для злоумышленника предупредить об угрозе администратора безопасности сайта, подвергнувшегося нападению. В результате злоумышленник сильно рискует подвергнуться судебному преследованию за нападение. Задумайтесь над вопросом приобретения системы обнаружения вторжения! Свободно распространяемые системы обнаружения вторжения доступны и жизнеспособны, позволяя экспериментировать с различными методами обнаружения атак, которые предлагаются их разработчиками. Обеспечьте аудит системных журналов, потому что ни одна система не достигнет когда-либо уровня понимания хорошо осведомленного в этой области человека. Обеспечьте абсолютные гарантии своевременного обновления программного обеспечения новейшими патчами и реагирования на современные сообщения о выявленных уязвимостях в системе защиты. Подпишитесь на различные профильные рассылки и читайте их. С точки зрения нападения, помните, что злоумышленник может получить ту же самую информацию, которая есть у вас. Это позволит злоумышленнику выяснить, что различает системы обнаружения вторжения и, что более важно, как это делается. Внесенные в код программы злоумышленника изменения приведут к тому, что система обнаружения вторжения не сможет обнаружить опасность при помощи своих оригинальных признаков или установок.
   В последние месяцы системы обнаружения вторжения играли ключевую роль в сборе информации о новых типах атак. Это затрудняет осуществление атак злоумышленниками. Ведь чем быстрее станет известен и опубликован алгоритм атаки, тем легче защититься от нее, поскольку в систему защиты будут внесены исправления. На самом деле любое новое исследование, проведенное злоумышленником, будет представлять ценность в течение короткого периода времени. Авторы полагают, что через несколько лет системы обнаружения вторжения войдут в число стандартного оборудования Интернет-соединений каждой организации, как межсетевые экраны сегодня.
   Примечание
   Этот закон используется в главе 16.

Закон 7. Тайна криптографических алгоритмов не гарантируется

   Этот специфический «закон», строго говоря, не является законом в определенном ранее смысле. Теоретически возможно существование безопасного криптографического алгоритма, разработанного в частном порядке, незаметно от других. Такое может быть, но только не в нашем случае. Криптографический алгоритм можно полагать безопасным только после продолжительного открытого обсуждения алгоритма и многочисленных неудачных попыток взлома алгоритма хорошими криптографами.
   Брюс Шнейер (Bruce Schneier) часто заявлял, что любой может изобрести криптографический алгоритм, но не каждый – взломать его. Программисты и криптографы знают это очень хорошо. Программисты не могут эффективно протестировать собственную программу, точно так же как криптографы не могут эффективно оценить свой криптоалгоритм. Криптограф должен знать все возможные типы атак и результат их воздействия на его алгоритм. То есть он должен знать типы известных атак и атак, которые могут появиться в будущем. Ясно, что никакой криптограф не может предсказать будущее, но некоторые из них способны изобрести криптостойкий в новых условиях алгоритм в силу своего предвидения или догадки о некоторых возможных типах атак в будущем.
   В прошлом это было показано уже не один раз. «Криптограф» изобретает новый алгоритм. Для новичка это уже прекрасно. Изобретя алгоритм, «криптограф» может следующее: использовать его конфиденциально, опубликовать детали алгоритма или на основе алгоритма выпустить коммерческий продукт. В случае опубликования алгоритма он, за редким исключением, часто взламывается достаточно быстро. А как насчет других двух вариантов? Если алгоритм не обеспечивает безопасности в момент его опубликования, то он небезопасен в любое время. Что еще можно добавить о личной безопасности автора или его клиентов?
   Почему так получается, что почти все новые алгоритмы терпят неудачу? Один ответ состоит в том, что трудно получить хороший криптоалгоритм. Другой – сказывается недостаток соответствующих знаний. На всех хороших криптографов, которые могли бы раскрыть чей-либо алгоритм, приходится намного больше людей, желающих попробовать его написать. Авторам в области криптографии нужна богатая практика, чтобы научиться созданию хороших криптографических средств. Это означает, что им нужно раскрывать свои алгоритмы много раз, чтобы они смогли научиться на своих ошибках. Если они не смогут найти людей, взломавших их криптосредства, доказать их высокое качество становится тяжелее. Худшее, что может произойти, – это когда некоторые авторы сделают вывод о безопасности криптоалгоритма только потому, что никто его не раскрыл (вероятно, из-за недостатка времени или интереса).
   В качестве примера предвидения будущего рассмотрим стандарт шифрования DES. В 1990 году Ели Бихам (Eli Biham) и Ади Шамир (Adi Shamir), два всемирно известных криптографа, обнаружили нечто, что впоследствии они назвали дифференциальным криптоанализом (differential cryptanalysis). Это произошло спустя некоторое время после изобретения DES^ и принятия его в качестве стандарта. Естественно, они испытывали новые методы дифференциального криптоанализа на DES. У них была возможность усовершенствовать атаку по типу простой грубой силы (simple brute-force attack), но при этом выяснилось, что эти улучшения не приводят к принципиальному уменьшению времени взлома DES. Оказалось, что структура блоков подстановки s-boxes в DES была почти идеальна для защиты от дифференциального криптоанализа. Казалось, что кто-то, кто разрабатывал DES, знал или подозревал о технике дифференциального криптоанализа.
   Очень немногие криптографы способны изобрести алгоритмы такого качества. Как правило, они же могут и взломать хорошие алгоритмы. Авторы слышали, что несколько криптографов поддерживают попытки взлома алгоритмов других авторов, рассматривая это как способ обучения написания хороших алгоритмов. Эти мирового класса криптографы, допуская, что их алгоритмы могут быть взломаны, знакомят криптографический мир со своими работами для экспертизы. И даже в этом случае требуется время для корректной оценки. Некоторые новые алгоритмы в процессе работы используют передовые методы. В этом случае для их взлома может потребоваться новаторская техника атак, на разработку которой нужно дополнительное время. Кроме того, большинство квалифицированных специалистов в области криптографии пользуются большим спросом и весьма заняты, поэтому у них нет времени на рассмотрение каждого опубликованного алгоритма. В некоторых случаях алгоритм должен был бы, казалось, стать популярным хотя бы потому, что на его проверку потрачено значительное время. Все эти шаги по тестированию алгоритмов требуют времени – иногда на это уходят годы. Поэтому даже лучший криптограф иногда посоветует не доверять своему новому алгоритму, пока он не выдержит тщательного длительного испытания. Время от времени даже лучшие в мире криптографы изобретают слабые криптографические средства.
   В настоящее время правительство Соединенных Штатов решило заменить DES новым стандартом криптографического алгоритма. Новый стандарт будет называться улучшенным стандартом шифрования AES (Advanced Encryption Standard), и национальный институт стандартов и технологии NIST (National Institute of Standards and Technology) выбрал алгоритм «рейндолл» (Rijndael) в качестве основы AES алгоритма. (Принят Министерством торговли США 12 октября 2000 года вместо устаревшего стандарта DES.) Большинство лучших мировых криптографов представили на рассмотрение свои работы на конференции продолжительностью в несколько дней. Несколько алгоритмов во время конференции были раскрыты другими криптографами.
   Авторы не смогут научить читателя правилам вскрытия реальных криптографических средств. В рамках одной книги это невозможно. Хотя авторы приготовили отдельные забавные криптографические упражнения. В мире много людей, которые хотели бы создавать и продавать криптографические средства только потому, что они считают себя хорошими криптографами. Зачастую разработчики понимают невозможность использования существующих криптографических средств из-за недостатков отдельных ключей. В этом случае для скрытия своих действий они могут выбрать что-то более простое, но тогда взломать результаты их работы можно гораздо быстрее. (В главе 6 будет показано, как это сделать.)
   Итак, суть этого закона заключается не в том, чтобы на его основе что-то сделать, а скорее всего в том, чтобы акцентировать внимание на этом вопросе. Вы должны применять данный закон для оценки характеристик криптографических средств. Очевидное решение заключается в использовании известных криптографических алгоритмов. Но при этом обязательно следует проводить максимально возможную проверку их разумного использования. Например, какой прок в применении алгоритма 3DES, если использовать только семисимвольный пароль? Большинство выбираемых пользователями паролей использует лишь несколько бит из возможного количества бит на букву. В этом случае семь символов гораздо меньше 56 бит.
   Примечание
   Этот закон используется в главе 6.

Закон 8. Без ключа у вас не шифрование, а кодирование

   Ключ при шифровании используется для обеспечения уникальности результатов в условиях, когда каждый использует тот же самый небольшой набор алгоритмов. Разработать хороший криптографический алгоритм трудно, поэтому только небольшая их часть используется во многих различных приложениях. Необходимость в новых криптографических алгоритмах появляется нечасто потому, что известные сейчас алгоритмы могут использоваться во многих областях (подпись сообщения, блочное шифрование и т. д.). Если хорошо известный (и предсказуемый) тип атаки методом грубой силы занимает много времени, то нет достаточных причин для замены криптоалгоритма. Уже было написано, что не следует полностью доверять новым криптографическим алгоритмам.
   В ранней истории криптографии большинство схем зависели от взаимодействующих сторон, использующих ту же самую систему скремблирования (скремблирование – шифрование путем перестановки и инвертирования групп символов) посылаемых друг другу сообщений. Ключ или разновидность ключевой фразы (pass-phrase) обычно не использовались. Двум сторонам нужно было договориться о схеме преобразования, например о замене каждой на букву, находящуюся в алфавите на три позиции дальше, чем заменяемая, и они могли посылать сообщения.
   Позже начали использовать более сложные системы. Результат преобразования сообщения с их помощью зависел от слова или фразы, устанавливающих начальное состояние процесса преобразования сообщений. Такие системы были широко известны. Они позволяли обмениваться сообщениями со многими сторонами и обеспечивали определенную безопасность при условии использования различных фраз.
   Рассмотренные два типа систем позволяют лучше увидеть концептуальное различие между кодированием и шифрованием. При кодировании ключ не используется, и если вовлеченные в обмен информацией стороны хотят обеспечить секретность, то их схема кодирования должна быть секретной. При шифровании используется ключ (или ключи), который обе стороны должны знать. Алгоритм шифрования может быть известен, но если у злоумышленника нет ключей, знание алгоритма ему не поможет.
   Конечно, проблема состоит в том, что схемы кодирования редко удается сохранить в тайне. Перед обменом каждый получит копию алгоритма. Если ключ не использовался, то каждый, получивший копию программы, сможет расшифровать все зашифрованное этой программой. Это не сулило ничего хорошего массовому рынку криптографических средств. Использование ключа позволяет применять известные хорошие алгоритмы во многих приложениях. Что вы сделаете, когда столкнетесь с криптографическим средством, о котором известно, что в нем используется тройное DES-шифрование, но вводить пароли не нужно? Бегите прочь! Возможность расшифровки сообщений, зашифрованных DES и его разновидностями (подобно 3DES), зависит от секретности ключа. Если ключ известен, то тайны могут быть расшифрованы. Откуда средство берет ключ для работы, если не от пользователя? Откуда-то с жесткого диска компьютера.
   Этот вариант лучше использования слабого алгоритма? Вероятно, это слегка лучше, если зашифрованные файлы предназначены для переноса на другой компьютер, например через сеть. Если их перехватят вне компьютера, то они могут остаться в безопасности. Однако если модель угрозы включает людей, имеющих непосредственный доступ к компьютеру, то ситуация сильно меняется, поскольку они могут завладеть ключами. Криптографы хорошо поднаторели в определении схем кодирования и расшифровки сообщений. Если вы говорите о встроенной в продукт массового рынка схеме кодирования, забудьте о возможности сохранения в тайне алгоритма ее работы. У злоумышленника будут все необходимые возможности для определения схемы кодирования.
   Если вы столкнетесь с системой, про которую говорят, что она шифрует коммуникации и при этом, кажется, ей не нужно обмениваться ключами, хорошо подумайте над этим. Задайте производителю побольше вопросов о том, как именно она работает. Вспомните все, что ранее говорилось о надежном обмене ключами. Если ваш производитель замалчивает вопросы обмена ключевой информацией и не может досконально объяснить детали точного решения проблемы обмена ключами, то, вероятнее всего, вы встретили небезопасное средство. В большинстве случаев для вас должна быть нормой необходимость иметь программные ключи в различных конечных точках коммуникаций.
   Примечание
   Этот закон используется в главах 6 и 10.

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

   Это утверждение о паролях в особенности относится к программам, которые в той или иной форме хранят пароль на компьютере клиента в архитектуре клиент-сервер. Помните, что клиентская машина всегда полностью контролируется работающим на ней пользователем. Поэтому в общем случае нельзя гарантировать безопасное хранение информации на клиентском рабочем месте. Как правило, сервер отличается тем, что пользователь-злоумышленник вынужден взаимодействовать с сервером при помощи сетевых средств через, скорее всего, ограниченный интерфейс. Допускается единственное исключение из правила о недопущении хранения информации на уязвимой машине клиента: хранимая информация должна быть зашифрованной. Этот закон – фактически специфический вариант предыдущего: «Без ключа у вас не шифрование, а кодирование». Ясно, что это относится к паролям, поскольку они специфический вариант информации. О паролях говорится отдельно, потому что в приложениях безопасности они часто заслуживают специального внимания. Каждый раз, когда приложение запрашивает у вас пароль, вам следует задуматься: «Каким образом пароль будет сохранен?» Некоторые программы не хранят пароль после его использования, потому что они больше не нуждаются в нем. По крайней мере, до следующего раза. Например, многие Telnet– и ftp-клиенты вообще не запоминают пароли. Они сразу передают их серверу. Другие программы предложат «вспомнить» ваш пароль. Они могут предложить щелкнуть на иконке вместо ввода пароля.
   Насколько надежно эти программы хранят ваш пароль? Оказалось, что в большинстве случаев они не могут надежно хранить ваш пароль. Согласно предыдущему закону, поскольку преобразование выполнялось без использования ключа, то все, что они могут сделать, – это закодировать пароль. Это может быть очень сложный алгоритм кодирования, тем не менее это кодировка, потому что у программы должна быть возможность расшифровки пароля для последующего использования. Если программа сможет это сделать, то сможет и кто-то еще.
   Данный факт также универсален, хотя могут быть очевидные исключения. Например, Windows предложит вам сохранить пароли для доступа по телефонной линии dial-up. Вы щелкаете на иконке и регистрируетесь у вашего Интернет-провайдера. Судя по всему, ваш пароль хранится где-нибудь на жестком диске в закодированном виде и его можно декодировать, правильно? Не обязательно. Майкрософт разработал процедуру сохранения этого пароля во время регистрации пользователя Windows. (Регистрация – процедура идентификации пользователя при вхождении в компьютерную систему.) Если у вас есть такой сохраненный пароль, пробуйте щелкнуть на кнопке «Отмена» вместо ввода вашего пароля регистрации во время загрузки Windows. Вы найдете, что ваш сохраненный пароль для доступа по телефонной линии недоступен, потому что Windows использует пароль регистрации для разблокировки пароля доступа по телефонной линии. Все необходимое для выполнения этих операций хранится в файле с расширением. pwl в директории Windows.
   Иногда, по ряду причин, программное обеспечение захочет сохранить нужную ему информацию на машине клиента. Например, Web-браузеры сохраняют файлы cookies (в системах с удаленным доступом – пароль, порождаемый сервером при первом подключении и отсылаемый пользователю; при последующих подключениях пользователь должен предоставлять серверу этот пароль) и, иногда, пароли. (Последние версии браузера Internet Explorer предложат запомнить ваши имена и пароли.) Программы, которые для доступа к серверу используют компоненту идентификации, типа Telnet-клиентов и программ чтения почты, также часто сохраняют пароль. С какой целью сохраняются ваши пароли? Для того, чтобы вы не должны были вводить их каждый раз.
   Очевидно, что включение в программы такой возможности не является хорошей идеей. Если на вашей машине есть иконка, просто щелкнув на которую, вы получаете доступ к серверу, и при этом серверу автоматически передаются ваше имя и пароль, то любой подошедший может сделать то же самое. С точки зрения безопасности, можно ли было сделать что-нибудь худшее, чем это? Как мы увидим, да.
   Давайте рассмотрим пример клиента электронной почты, который услужливо помнит за вас ваш пароль. Вы делаете ошибку, оставляя на мгновение злоумышленника наедине с вашим компьютером. Что он может сделать? Ясно, что он может легко прочитать вашу почту и получить постоянный доступ к ней. Поскольку в большинстве случаев пароли почты передаются открыто (и давайте предположим, что в нашем случае это так и есть), то если у злоумышленника есть программа «захвата пакетов» (packet capture program), он мог бы быстро загрузить ее на ваш компьютер. Или если у него был бы наготове портативный компьютер (laptop), он смог бы переписать ваши пароли. Это лучше, чем типичная мониторинговая атака, так как у него есть возможность заставить ваш компьютер переслать кому-либо ваш пароль по его желанию.
   Однако у него может не быть времени для таких сложных приготовлений. Тогда он может незаметно вынуть дискету из-за пазухи и скопировать файл. Возможно, вместо этого злоумышленник смог бы переслать файл через сеть, если был бы уверен, что не будет где-нибудь зарегистрирован в системном журнале и обнаружен. Конечно, предварительно ему следовало бы знать, на какой файл или на какие файлы обратить внимание. Это потребовало бы дополнительной подготовки или исследования. Злоумышленник должен был бы знать, какую почтовую программу вы обычно используете. Но если он находится в вашем офисе, то у него хорошие шансы обменяться с вами почтой, а каждое электронное письмо, которое вы посылаете злоумышленнику, сообщает ему в заголовке, какую программу электронной почты вы используете.
   Что содержится в украденном злоумышленником файле? Ваш сохраненный пароль, конечно. Некоторые программы сохраняют пароль в явном виде, позволяя злоумышленнику прочитать его непосредственно. Это плохо с точки зрения безопасности, и, как будет видно дальше, подобные программы незатейливо просты. В этом случае вы должны попробовать отключить любые возможности программы, позволяющие локализовать место хранения пароля, если это возможно.
   Если при просмотре файла ничто не напоминает пароль, то можно найти копию такой же почтовой программы, воспользоваться вашим файлом и щелкнуть на кнопке «Соединить». У злоумышленника появилась возможность получать вашу почту. Если он все еще не удовлетворил своей любознательности, то теперь он может организовать перехват пакетов и на досуге найти пароль. Но, возможно, есть причина, по которой злоумышленник не хочет (или не может) щелкнуть на кнопке «Соединить» и наблюдать за мгновенной передачей пароля. Возможно, злоумышленник не может добраться до сервера в данный момент, потому что сервер находится в защищенной сети. Вероятно, вы использовали протокол, который не посылает пароль в явном виде.
   Подумайте над следующим: без всякой помощи ваша почтовая программа знает, как расшифровать пароль и отослать его (или некоторую его форму). Как она это делает? Очевидно, она знает что-то, что не знает злоумышленник, по крайней мере сейчас. Программа или знает алгоритм раскодировки, который является одинаковым для каждой копии этой программы, или знает секретный ключ расшифровки пароля, который должен храниться на вашем компьютере.
   В любом случае, если действительно украдены правильный файл или файлы, то у злоумышленника есть все для определения вашего пароля даже без попытки использовать его. Если это простое декодирование, то можно определить алгоритм с использованием эксперимента и догадки или дизассемблировать часть программы, реализующей этот алгоритм и определить его. На это может потребоваться время, но при известной настойчивости есть все для его определения. Затем ваш секрет может быть рассказан остальным, чтобы каждый смог это легко сделать.
   Если программа действительно использует шифрование, то в случае кражи нужного файла или файлов и это не является гарантией безопасности. Ведь если программа может расшифровать пароль, а все действия злоумышленника по его раскодировке ни к чему не привели, то ясно, что программа где-нибудь должна хранить ключ расшифровки. Злоумышленнику следует только удостовериться в том, что файл ключа расшифровки тоже украден.
   Разве программа не могла потребовать, чтобы законный пользователь помнил ключ расшифровки? Могла, но тогда почему пароль клиента запоминается в первую очередь? Только для того, чтобы пользователь не вводил пароль постоянно.
   Примечание
   Этот закон используется в главе 6.
Приоткрывая завесу
   Будьте бдительны!
   Недавно усилился интерес к обсуждению совершенных атак для выяснения причин быстрого распространения злонамеренного программного кода и увеличения числа нападений. К счастью, большинство атак ориентировано на использование уже известных уязвимостей операционных систем и программ приложений. Например, в этом году многие атаки вируса Code Red и его модификаций были нацелены на уязвимости атакованных программных средств, известные в течение длительного времени. Грустно сознавать (и это смущает как с профессиональной, так и с личной точки зрения), что целый ряд сетевых администраторов и специалистов не смогли обеспечить работоспособность своих систем, своевременно исправляя найденные в них ошибки. Ни сколь угодно длительное обучение, ни подробная документация не сможет защитить ваши системы, если вы потеряете бдительность и перестанете поддерживать высокую квалификацию в области настройки своих систем.

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

   Писатели знают, что они не в состоянии качественно вычитать корректуру своей собственной работы. Программисты должны знать, что они не смогут протестировать на ошибки свои собственные программы. Большинство компаний, разрабатывающих программное обеспечение, понимая это, нанимают тестировщиков программного обеспечения. Они ищут ошибки в программах, которые препятствуют выполнению заявленных функций. Это называется функциональным тестированием.
   Функциональное тестирование значительно отличается от тестирования безопасности, хотя на первый взгляд это близкие понятия. Оба тестирования ищут дефекты программ, правильно? И да, и нет. Тестирование безопасности требует гораздо более глубокого анализа программы и обычно включает экспертизу исходного кода программы. Функциональное тестирование проводится для гарантии того, что большой процент пользователей сможет эксплуатировать программу без жалоб. Защититься от среднего пользователя, случайно споткнувшегося на проблеме, намного легче, чем попытаться защититься от хорошо осведомленного хакера, пытающегося взломать программу любым доступным ему способом.
   Даже без подробного обсуждения того, что собой представляет аудит безопасности, его необходимость очевидна. Сколько коммерческих средств подвергается проверке безопасности? Практически ни одно. Обычно даже те немногие, которые имеют хотя бы поверхностный обзор безопасности, считаются безопасными. Хотя позднее часто становится очевидным, что они не прошли должную проверку.
   Заметьте, что этот закон содержит слово «начала». Аудит безопасности – только один шаг в процессе создания безопасных систем. Для того чтобы понять, что в защите систем программного обеспечения полно недостатков, достаточно лишь ознакомиться с архивами списка отчетов любой уязвимости. Более того, можно увидеть одни и те же ошибки, неоднократно допущенные различными производителями программного обеспечения. Ясно, что это относится к классу систем, не подвергавшихся аудиту даже в минимальном объеме.
   Вероятно, OpenBSD представляет собой один из наиболее интересных примеров роли аудита в разработке более безопасной системы программного обеспечения. С самого начала в проекте OpenBSD, являющемся ответвлением от главного проекта NetBSD, было решено обратить особое внимание на вопросы безопасности. Команда разработчиков OpenBSD потратила пару лет, занимаясь аудитом исходного кода для поиска и устранения ошибок. Разработчики исправляли любые найденные ошибки независимо от того, относились они к безопасности или нет. При нахождении общей ошибки они возвращались назад и просматривали все исходные коды, чтобы убедиться в том, что подобная ошибка не была сделана где-нибудь еще.
   В конечном результате OpenBSD часто считается одной из наиболее безопасных операционных систем. Часто, когда обнаруживается новая ошибка в операционных системах NetBSD или FreeBSD (другой вариант BSD систем), в аналогичных условиях признается неуязвимость OpenBSD. Иногда причиной подобной неуязвимости является решение выявленной в других системах проблемы (случайно) во время обычного процесса исправления всех ошибок. В других случаях недостаток системы защиты был ранее выявлен и устранен. И в этих случаях системы NetBSD и FreeBSD (если в их составе была та же самая часть программного кода) были уязвимы, потому что никто не просматривал базу данных новых исправлений ошибок в OpenBSD (все исправления в OpenBSD обнародованы).
   Примечание
   Этот закон используется в главах 4, 5, 8 и 9.

Закон 11. Безопасность нельзя обеспечить покровом тайны

   В основе обеспечения безопасности покровом тайны (STO – «security through obscurity») лежит идея о том, что что-то безопасно только в силу своей неочевидности, отсутствия рекламы или интереса с чьей-либо стороны. Хорошим примером является новый Web-сервер. Предположим, что вы разрабатываете новый Web-сервер, доступный пользователям сети Интернет. Вы можете подумать, что поскольку вы еще не зарегистрировали имя службы имен доменов DNS и нет пока ссылок на новый Web-сервер, то можно отложить реализацию защитных мер компьютера до начала ввода в эксплуатацию Web-сервера.
   Проблема заключается в том, что сканирование портов стало постоянным явлением в Интернете. В зависимости от вашей удачи обнаружение вашего Web-сервера, вероятнее всего, – вопрос нескольких дней или даже часов. Почему разрешено сканирование портов? В большинстве случаев сканирование портов вполне законно, и большинство Интернет-провайдеров ничего не будет предпринимать в ответ на ваше заявление о том, что у вас сканировали порты.
   Что может произойти в результате сканирования портов? Огромное большинство систем и пакетов программ небезопасны после их установки на компьютер. Другими словами, если вы подключаетесь к Интернету, ваш компьютер может быть относительно легко взломан, если вы не предпримите активных действий по укреплению его безопасности. Большинство злоумышленников, сканирующих порты, ищут известные им уязвимости. Если они присущи вашей системе, то у злоумышленников найдется программа, которая скомпрометирует Web-сервер за секунды. Если удача сопутствует вам, вы обнаружите сканирование портов. Если нет, вы могли бы продолжать «защищать» хост и только позже выяснить, что злоумышленник оставил лазейку (backdoor), которую вы не смогли заблокировать, потому что к этому времени были скомпрометированы.
   Хуже всего то, что в последнее время огромное количество «червей» стало постоянным атрибутом Интернета. Они постоянно занимаются сканированием, выискивая новые жертвы типа только что появившихся незащищенных Web-серверов. Даже когда черви настроены миролюбиво, любой хост в Интернете подвергается зондированию пару раз в день. А когда черви агрессивны, то всякий хост зондируется каждые несколько минут за время жизни необновленного Web-сервера. Не следует думать, что оставленная брешь в системе защиты или ее нестабильная работа не сулит никаких неприятностей только в силу вашего предположения о невозможности обнаружения этого кем-либо. Через минуту новая дырка в системе защиты будет обнаружена, а вы – беззащитны. Злоумышленнику нет необходимости проводить многочисленные исследования раньше срока, поэтому он терпеливо выжидает. Часто сведения о дефектах в защите программ разглашаются очень быстро, что приводит к атакам на уязвимости слабозащищенных систем.
   Неопределенность освещения некоторых вещей не обязательно плоха. Просто вы не хотите делиться информацией больше, чем это нужно вам. Вы можете воспользоваться преимуществами «темной лошадки», но не слишком полагайтесь на это. Одновременно тщательно рассмотрите возможности разработки сервера, вплоть до предоставления общественности исходных текстов программ сервера, для того чтобы специалисты смогли проанализировать их и при необходимости исправить найденные ошибки. При этом будьте готовы к одной или двум итерациям работы над исправлением брешей в системе защиты, прежде чем программа станет безопасной.
   В какой степени необходима секретность? Одна из проблем обеспечения безопасности путем умалчивания состоит в том, что не существует соглашения, что именно следует хранить в тайне и что может рассматриваться как действительная тайна. Например, является ли ваш пароль тайной или просто «умолчанием», вероятно, зависит от способа обращения с ним. Если вы положили клочок бумажки с записанным паролем под клавиатуру в надежде, что его никто не найдет, то именно это авторы и называют неработоспособностью засекреченной безопасности, или говорят просто «мрак». (Между прочим, авторы прежде всего там его и искали бы. В компании, где работал один из авторов, использовали стальные кабели с замками, чтобы прикрепить компьютеры к столам. Его часто вызывали для перемещения компьютеров, а пользователи не раз забывали необходимые меры предосторожности при работе с ключами. Автор искал ключи в следующей последовательности: держатель карандаша, под клавиатурой, верхний ящик стола. При поиске ключа у него были 50 %-ные шансы на успех.)
   Размышления по этому поводу основаны на здравом смысле. Личное мнение авторов по этому поводу состоит в том, что нельзя обеспечить безопасность замалчиванием проблемы. Не имеет значения, говорите ли вы о ключе от дома под дверным ковриком или о 128-битном криптографическом ключе. Вопрос состоит в том, знает ли злоумышленник то, что ему нужно, сможет ли он раскрыть нужную ему информацию. Одна из причин, по которой вам следует прочесть книгу, заключается в конкретном изучении, что злоумышленник может сделать. Многие системы и сайты просуществовали длительное время под покровом секретности, укрепляя свою веру, что нет никаких оснований для нападения на них. Мы увидим, является ли их компрометация вопросом времени или нет.
   Примечание
   Этот закон используется в главах 4 и 5.

Резюме

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

Конспект

Обзор законов безопасности
   · Законы нужно знать для того, чтобы сделать систему более безопасной.
   · Помните, что законы изменяются.
Закон 1. Невозможно обеспечить безопасность клиентской части
   · Безопасность клиентской части целиком определяется клиентом.
   · У пользователя всегда есть возможности для взлома системы защиты, потому что у него физический доступ к компьютеру.
   · Если у злоумышленника достаточно времени и ресурсов, то безопасность клиентской части невозможна.
Закон 2. Нельзя организовать надежный обмен ключами шифрования без совместно используемой порции информации
   · Общая информация используется для идентификации компьютеров до установления сетевого соединения.
   · Вы можете обмениваться общими секретными ключами (shared private keys) или использовать протокол безопасных соединений SSL при работе с браузером.
   · Обмен ключами уязвим к атаке типа MITM (злоумышленник посередине (MITM).
Закон 3. От кода злоумышленника нельзя защититься на 100 %
   · Программное обеспечение несовершенно.
   · Программное обеспечение обнаружения вирусов и Троянских коней основано на исследовании сигнатуры файлов.
   · Незначительные изменения в коде сигнатуры приводят к необнаружению измененного кода до момента выпуска следующего файла сигнатуры.
Закон 4. Всегда может быть создана новая сигнатура кода, которая не будет восприниматься как угроза
   · Злоумышленники могут быстро изменить характерные признаки или сигнатуру файла.
   · Злоумышленники могут использовать сжатие, шифрование и пароли для изменения сигнатуры кода.
   · Нельзя защититься от каждой возможной модификации.
Закон 5. Межсетевые экраны не защищают на 100 % от атаки злоумышленника
   · Межсетевые экраны – это программные или аппаратные, или программно-аппаратные средства ЭВМ.
   · Главная функция межсетевых экранов состоит в фильтрации входных и выходных пакетов.
   · Успешные атаки возможны в результате ошибочных правил, несовершенной политики безопасности и проблем с обслуживанием межсетевых экранов.
Закон 6. От любой системы обнаружения атак можно уклониться
   · Системы обнаружения вторжения – часто пассивные системы.
   · Для злоумышленника трудно обнаружить присутствие системы обнаружения вторжения.
   · Эффективность системы обнаружения вторжения снижается в результате неверной конфигурации и недостатков обслуживания.
Закон 7. Тайна криптографических алгоритмов не гарантируется
   · Хорошие криптографические алгоритмы обеспечивают высокую степень защиты.
   · Большинство криптографических средств не подвергаются достаточному исследованию и тестированию до начала использования.
   · Единые алгоритмы используются в различных областях. Взломать их трудно, хотя и возможно.
Закон 8. Без ключа у вас не шифрование, а кодирование
   · Этот закон универсален, не существует никаких исключений.
   · Шифрование используется, чтобы защитить результат кодирования. Если ключ не используется, то нельзя ничего зашифровать.
   · Ключи должны храниться в тайне, иначе ни о какой безопасности не может быть и речи.
Закон 9. Пароли не могут надежно храниться у клиента, если только они не зашифрованы другим паролем
   · Пароли, сохраненные на компьютере клиента, легко обнаружить.
   · Если пароль хранится в открытом виде (незашифрованным), то это небезопасно.
   · Безопасное хранение паролей на компьютере клиента предполагает вторичный механизм обеспечения безопасности.
Закон 10. Для того чтобы система начала претендовать на статус защищенной, она должна проити независимый аудит безопасности
   · Аудит – начало хорошего анализа систем безопасности.
   · Системы безопасности часто не анализируются должным образом, что ведет к их дефектам.
   · Внешняя проверка имеет решающее значение для защиты; ее отсутствие – дополнительное условие для атаки злоумышленником.
Закон 11. Безопасность нельзя обеспечить покровом тайны
   · Скрыть что-либо – не значит обеспечить безопасность этого.
   · Необходима упреждающая защита.
   · Использование только скрытия информации способствует компрометации.

Часто задаваемые вопросы

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

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

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

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

Глава 3
Классы атак

   В этой главе обсуждаются следующие темы:
   • Обзор классов атак
   • Методы тестирования уязвимостей
   · Резюме
   · Конспект
   · Часто задаваемые вопросы

Введение

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

Обзор классов атак

   Каждая атака принадлежит к определенному классу атак. Последствия атаки могут быть самыми различными: атакованная система может быть выведена из строя или удаленный злоумышленник сможет полностью контролировать ее. О последствиях атак речь пойдет в специальном разделе этой главы. Сначала рассмотрим классификацию атак, в основу которой положен наносимый ими ущерб.
   Можно выделить семь классов атак, последствия которых отражают общие критерии оценки проблем безопасности:
   • отказ в обслуживании (Denial of service);
   • утечка информации;
   • нарушения прав доступа к файлу;
   • дезинформация;
   • доступ к специальным файлам / базам данных;
   • удаленное выполнение программ (Remote arbitrary code execution);
   • расширение прав (Elevation of privileges).

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

   Что собой представляет атака, приводящая к отказу в обслуживании (DoS-атака)? О DoS-атаке говорят в том случае, когда в результате действий злоумышленника ресурс заблокирован или его функциональные возможности существенно ограничены. Другими словами, атака препятствует доступности ресурса его постоянным авторизованным пользователям. Атаки этого класса могут осуществляться как локально на автономной системе, так и удаленно через сеть. Они направлены на ограничение функциональных возможностей процессов, уменьшение объема запоминаемой информации, разрушение файлов. Подобные атаки преследуют цель сделать ресурс непригодным для работы или добиться завершения работы системы или процессов. Рассмотрим DoS-атаки подробнее.
Локальная DoS-атака
   Локальная DoS-атака встречается часто, и ее во многих случаях можно предотвратить. Несмотря на большой ущерб от атак этого класса, все же предпочтительнее иметь дело именно с ними. При грамотно реализованной системе безопасности этот класс атак легко отследить, а злоумышленника – идентифицировать.
   Локальная DoS-атака наиболее часто преследует следующие три цели: существенное снижение функциональных возможностей процесса, исчерпание места на диске и истощение индексных узлов (index node (inode) exhaustion).

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

   #!/bin/sh
   # by Nergal
   mklink()
   {
   IND=
   NXT=$(($IND+1))
   EL=l$NXT/../
   P=“”
   I=0
   while [ $I -lt $ELNUM ] ; do
   P=$P“$EL”
   I=$(($I+1))
   done
   ln -s “$P”l l$IND
   }
   #main program
   if [ $# != 1 ] ; then
   echo A numerical argument is required.
   exit 0
   fi
   ELNUM=
   mklink 4
   mklink 3
   mklink 2
   mklink 1
   mklink 0 /../../../../../../../etc/services
   mkdir l5
   mkdir l

   Еще один вариант локальной DoS-атаки получил название fork bomb – развилочная бомба (fork bomb – самовоспроизводящаяся командная строка, способная в конечном итоге уничтожить все другие записи в таблице процессов командной системы). Эта проблема не только операционной системы Linux. Она не решена и в других операционных системах на различных платформах. Развилочную бомбу легко реализовать на языке командной оболочки shell или языке C. Код бомбы на языке командной оболочки shell представлен ниже:

   ( & &)

   Код на языке С следующий:

   (main() {for(;;)fork();})

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

   Переполнение диска
   Цель другого класса локальной DoS-атаки состоит в том, чтобы полностью заполнить диск. Емкость диска – конечный ресурс. Ранее дисковая память была очень дорогим ресурсом. В настоящее время цена хранения информации на диске значительно снизилась. Несмотря на возможность решения многих задач хранения информации при помощи дисковых массивов и программ, контролирующих хранение информации, емкость дисковой памяти продолжает оставаться узким местом во всех системах. Программные решения типа выделения квот хранения информации каждому пользователю позволяют лишь смягчить эту проблему.
   Этот вид атак преследует цель сделать невозможным создание новых файлов и увеличение размера существующих. Дополнительная проблема состоит в том, что некоторые UNIX-системы завершаются аварийно при полном заполнении корневого раздела. Хотя это нельзя характеризовать как конструкторский дефект UNIX, правильное администрирование системы должно предусматривать отдельный раздел для журналов регистрации типа /var и отдельный раздел для пользователей типа директории /home на Linux-системах или директории /export/home на системах Sun.
   Если при планировании работы с диском не было предусмотрено разбиение диска на раздел(ы) для пользователей и, отдельно, раздел(ы) для журналов регистрации, то злоумышленник может воспользоваться этим типом DoS-атаки для достижения аварийного отказа системы. Он может также воспользоваться этим типом атаки для затруднения работы пользователей: при генерации большого количества событий, регистрируемых в системном журнале syslog, расходуется отведенная разделу журналов регистрации дисковая память, и при ее исчерпании нельзя зарегистрировать новые события в журнале syslog.
   Реализация такой атаки тривиальна. Пользователю локального компьютера достаточно выполнить следующую команду:

   cat /dev/zero > ~/maliciousfile

   Эта команда свяжет файл устройства /dev/zero (который просто генерит нули) с файлом злоумышленника. Команда будет продолжаться до тех пор, пока пользователь не прекратит ее выполнение или не будет заполнен диск.
   Для усиления разрушительного эффекта атаки, направленной на исчерпание дисковой памяти, можно воспользоваться идеей бомбежки почты. Хотя это старая идея, на практике она почти не применяется. Возможно, из-за того, что на основе анализа заголовков пакетов протокола SMTP путь электронной почты легко проследить. И хотя для передачи пакетов могут использоваться открытые ретрансляторы (open relays), поиск отправителя почтовой бомбы – не очень сложная задача. Поэтому большинство бомбардировщиков почты окажется или без Интернета, или в тюрьме, или одновременно и там, и там.

   Истощение индексных узлов
   Несмотря на разные цели, атаки, направленные на истощение индексных узлов, похожи на предыдущий тип DoS-атаки, ориентированный на переполнение диска. Локальные DoS-атаки истощения индексных узлов изначально ориентированы на тот или иной тип файловой системы. Индексные узлы – обязательная часть файловой системы UNIX.
   Индексные узлы содержат важную информацию файловой системы. Как минимум, это сведения о владельце файлов, групповом членстве файлов, их типе, разрешениях, размере и адресах блоков, содержащих данные файла. При форматировании файловой системы создается конечное число индексных узлов для обработки индексов файлов каждой группы.
   Ориентированные на истощение индексных узлов DoS-атаки стараются использовать все доступные индексные узлы раздела. Истощение этих ресурсов создает ситуацию, подобную той, которая происходит в случае нехватки места на диске. В результате система не может создавать новые файлы. Этот класс атак обычно используется для нанесения ущерба системе и препятствования регистрации системных событий, особенно действий злоумышленника.
Сетевые DoS-атаки
   Сетевые DoS-атаки, преследующие цель вывода подключенного к сети компьютера (или компьютеров) из строя, могут быть отнесены к одному из двух подклассов: нападение на какую-либо службу системы или нападение на систему в целом. Такие атаки могут быть очень опасными. Эти типы атак были придуманы для создания дискомфорта пользователям и предпринимаются злоумышленником как карательные акции.
   Характеризуя людей, стоящих за подобными атаками, следует сказать, что DoS-атаки из сети – в основном метод действия малодушных людей, пытающихся уйти от ответственности за совершенные действия. Любые оправдания DoS-атак из сети несостоятельны. Свободно распространяемый и легкодоступный инструментарий создал субкультуру, называемую миром возможностей новичков-недоумков (script kiddiot), способных только на то, чтобы запустить нужный сценарий. (Автор позаимствовал неологизм, придуманный Джосом Оквендо (Jose Oquendo) – автором известной программы antiofiline.com.) Выражение новичок-недоумок произошло от базового словосочетания, в котором сценарий определяется как «предварительно написанная программа, запускаемая пользователем», а словообразование новичок-недоумок (kiddiot) является комбинацией слов ребенок и недоумок. Очень доходчиво. Доступность существующего инструментария позволяет им причинять неудобства, оставаясь при этом анонимными. При этом пользователям совсем не обязательно утруждать себя хотя бы минимальными техническими знаниями. Единственные, кто несет за подобные атаки большую ответственность, чем новички-недоумки, – это группа профессионалов, создающих условия для подобных атак.
   DoS-атаки из сети, как уже было сказано, могут быть направлены на службы или систему в целом в зависимости от того, какую цель преследует атака и почему. Они могут быть подразделены на атаки, направленные для достижения отказа в обслуживания клиентской части, сервисов или систем. В следующих разделах каждый из этих типов атак будет рассмотрен более детально.

   Сетевые DoS-атаки на клиентскую часть
   Специальные программы ориентированы на достижение отказа в обслуживании клиентской части. Они преследуют следующую цель: добиться невозможности выполнения клиентской частью запросов пользователя. Примером подобной атаки являются так называемые бомбы JavaScript (JavaScript bombs).
   По умолчанию большинство Web-браузеров разрешают использование сценария на языке JavaScript. То, что это действительно так, можно заметить во время посещения Web-сайта, когда отображается всплывающая или фоновая (pop-under) реклама. К сожалению, злоумышленник может использовать возможности JavaScript преступным образом, например для атаки с целью достижения отказа обслуживания клиентской части. Используя ту же самую технику, что и рекламодатели для создания нового рекламного окна, злоумышленник может создать злонамеренную Web-страницу, состоящую из бесконечного цикла создания окон. В конечном счете всплывет так много окон, что система исчерпает все свои ресурсы.
   Это был пример атаки на клиентскую часть для достижения отказа в обслуживании пользователя в результате исчерпания ресурсов. Принцип атаки аналогичен ранее описанному, но теперь атака организована через сеть. Это только одна из многих атак на клиентскую часть. Другие используют возможности таких программ, как AOL Instant Messenger, ICQ Instant Message Client и аналогичные им.

   Сетевые DoS-атаки на сервисы
   Другим представителем класса сетевых DoS-атак являются сетевые DoS-атаки на сервисы. Они предназначены для нападения на выбранные для атаки сервисы, для того чтобы добиться их недоступности для авторизованных пользователей. Подобные атаки обычно осуществляются при помощи таких используемых пользователями сервисов, как демон протокола передачи гипертекста (Hypertext Transfer Protocol Daemon – HTTPD), агент доставки почты (Mail Transport Agent – MTA) и др.
   Иллюстрацией подобной проблемы служит уязвимость, которая случайно была обнаружена в инфраструктуре Web-конфигурации операционной системы фирмы Cisco CBOS (Cisco Broadband Operating System). После появления на свет червя Code Red, который создавался, ориентируясь на Wed-сервера с IIS (Internet Information Server) 5.0 фирмы Микрософт, было обнаружено, что червь неразборчив к типу атакуемого Web-сервера. Червь сканировал сети в поисках Web-серверов и предпринимал попытки атаковать любой встретившийся сервер.
   Побочный эффект червя проявился в том, что хотя некоторые хосты оказались ему не по зубам, другие хосты, в частности хосты с CBOS, оказались подверженными другой опасности: прием от хостов, инфицированных Code Red, многократных запросов на соединение с использованием протокола TCP через порт 80 приводил к аварии CBOS.
   Хотя эта уязвимость была обнаружена как проявление другой, любой пользователь мог воспользоваться ею с помощью легкодоступного инструментария аудита сети. Тем более что после нападения маршрутизатор не смог бы самостоятельно выключиться и сразу включиться, чтобы восстановить свою работоспособность. Это классический пример атаки, нацеленной на уязвимый сервис.

   Сетевые DoS-атаки на систему
   Нацеленные на разрушение системы сетевые DoS-атаки обычно преследуют те же цели, что и локальные DoS-атаки: уменьшение производительности системы вплоть до ее полного отказа. Выявлено несколько характерных подходов для осуществления этого типа атак, которые по существу полностью определяют используемые методы. Один из них основан на атаке одной системы из другой. Этот тип нападения был продемонстрирован в нападениях land.c, Ping of Death (звонок смерти) и teardrop (слезинка), происходивших пару лет назад, а также в нападениях на различные уязвимости фрагментированных пакетов TCP/IP в маршрутизаторе D-Link, Microsoft ISA Server и им подобных программных средствах.
   Аналогична идея синхронной атаки (SYN flooding). (SYN flooding – злонамеренное действие, состоящее в генерировании злоумышленником лавины синхронизирующих символов SYN с целью заблокировать легальный доступ на сервер путем увеличения полуоткрытых соединений к TCP порту). Синхронная атака предполагает наличие ряда условий: начиная от случая, когда атакующий компьютер обладает большей производительностью, чем атакуемый, и заканчивая случаем наличия в сети компьютеров, соединенных скоростными каналами. Этот тип нападения используется главным образом для деградации производительности системы. Синхронная атака реализуется путем посылки запросов на TCP-соединение быстрее, чем система сможет их обработать. Атакованная система расходует ресурсы на отслеживание каждого соединения. Поэтому получение большого количества символов синхронизации может привести к тому, что атакованный хост исчерпает все свои ресурсы и не сможет выделить их новым легальным соединениям. IP-адрес источника, как обычно, подменяется таким образом, чтобы атакованная система не смогла получить ответ на свою посылку второй части трехстороннего представления SYN-ACK (синхронизированное уведомление об успешном приеме данных, генерируемое получателем пакетов). Некоторые операционные системы несколько раз повторно передадут SYN-ACK, перед тем как освободить ресурс и вернуть его системе. Заках (Zakath) написал программу синхронной атаки syn4k.c. Программа позволяет указать в пакете подмененный адрес отправителя и порт системы жертвы синхронной атаки. По соображениям краткости изложения в книге не приведен исходный код программы, но его можно загрузить с www.cotse.com/sw/dos/syn/synk4.c.
   Синхронную атаку можно обнаружить различными инструментальными средствами, например командой netstat, результат действия которой показан на рис. 3.1, или с помощью сетевых систем обнаружения вторжения (IDS).
   Рис. 3.1. Пример использования команды netstat для обнаружения синхронной атаки

   В некоторых версиях операционных систем использование параметра – n команды netstat позволяет отобразить адреса и номера портов в числовом формате, а переключатель -p – выбрать протокол для просмотра. Это дает возможность просматривать не все соединения по протоколу UDP (User Datagram Protocol), а только те из них, которые представляют интерес в рамках определенной атаки. Перед использованием команды ознакомьтесь с описанием команды netstat, установленной на вашей операционной системе, чтобы гарантировать использование правильных параметров.
   Добавим, что некоторые операционные системы поддерживают возможность работы с маркерами SYN cookies по протоколу TCP. Использование маркеров SYN cookies позволяет устанавливать защищенные криптографическими средствами соединения (в системах с удаленным доступом использование маркеров подразумевает пароль, порождаемый сервером при первом подключении и отсылаемый пользователю; при последующих подключениях пользователь должен предоставлять серверу этот пароль). При получении символа синхронизации SYN от системы – инициатора обмена система возвращает символы синхронизированного уведомления об успешном приеме данных SYN+ACK, как если бы SYN-очередь в действительности была больше. При возврате системой-инициатором обмена символа ACK обратно системе она вызывает специальную функцию сервера, передавая функции в качестве входного параметра значение 32-битового счетчика времени по модулю 32. Если результат, возвращаемый функцией, соответствует ожидаемому, то используется извлеченный максимальный размер сегмента MSS и восстанавливаются внутренние переменные для правильного поступления SYN-символов в очередь.
   Рассмотрим атаки типа smurf или packet, которые обычно инициируются ранее упомянутыми новичками-недоумками. Атаки типа smurf – DoS-атаки из сети, ставящие перед собой цель вывести из строя атакованный хост. Этот тип атак использует маршрутизатор, играющий роль посредника, как это показано на рис. 3.2. Злоумышленник, подменивший исходный IP-адрес на адрес атакуемого хоста, генерирует большое количество эхо-сообщений по протоколу ICMP (Internet Control Message Protocol), создавая тем самым большой поток информации по широковещательным IP-адресам. Маршрутизатор, в данном случае выступающий в роли усилителя smurf-атаки, преобразует широковещательный запрос на IP-передачу к широковещательному запросу уровня канала передачи данных Layer 2 и посылает их дальше. Каждый хост, получив широковещательный запрос, отвечает эхо-сигналом по подмененному IP-адресу отправителя. В зависимости от числа хостов в сети как маршрутизатор, так и атакуемый хост могут быть перегружены потоком информационного обмена, что может привести к снижению сетевой производительности атакованного хоста. В зависимости от числа используемых сетевых усилителей атакованная сеть сможет достичь предела своих возможностей обработки информации.
   Рис. 3.2. Схема smurf-атаки

   В последнее время появились сетевые распределенные DoS-атаки (DDoS). В их основе лежит та же самая идея, что и в smurf-атаках, хотя средства нападения и метод усиления атаки значительно отличаются.
   Типы DDoS-атак различаются способом использования клиентов, мастеров и демонов (также называемых зомби). Для того чтобы DDoS-атака стала возможной, специальная программа должна быть размещена на десятках или сотнях системах-«агентах». Обычно кандидаты на роль «агентов» ищутся автоматически среди хостов, которые могут быть cкомпрометированы (например, в результате переполнения буферов во время удаленного вызова процедур (RPC) служб statd, cmsd и ttdbserverd). Затем на скомпрометированные хосты размещается специальная программа – мастер или демон. На них же загружаются специальные программы запуска демонов вместе с программами-генераторами потока пакетов информации, нацеленных на атакуемую систему. Для атаки злоумышленник использует клиента мастера, размещенного на скомпрометированном хосте. Мастер позволяет злоумышленнику управлять демонами. В конечном счете злоумышленник управляет несколькими мастерами, а те – демонами. Во время DDoS-атаки каждый из агентов участвует в создании избыточного потока информации по направлению к атакуемой системе и перегружает ее. Современный набор инструментальных средств DDoS-атак состоит из таких средств, как trinoo, Tribe Flood Network, Tribe Flood Network 2000, stacheldraht, shaft и mstream. Для дополнительного ознакомления о средствах и методах обнаружения демонов и инструментарии DDoS-атак посетите Web-сайт Дэвида Дитриха (David Dittrich): http://staff.washington.edu/dittrich/misc/DDoS.
Приоткрывая завесу
   Код Red Worm
   В июле 2001 года фильтр IIS (Internet Information Server – информационный сервер Internet) фирмы Микрософт был преобразован в автоматическую программу, названную червем. Используя брешь в системе защиты IIS, червь сначала атаковал один IIS, а затем, пользуясь скомпрометированной системой, нападал на другие системы IIS. Червь предназначался для двух вещей. Во-первых, для стирания Web-страницы инфицированной системы. И, во-вторых, для координации DdoS-атаки против Белого дома. Червь потерпел неудачу, не достигнув своих целей, в основном из-за своевременной квалифицированной реакции штаба информационных технологий Белого дома (White House IT staff).
   Последствия от нападения червя не ограничились уязвимыми операционными системами Windows или Белым домом. В результате атаки были переполнены журналы серверов HTTP, неуязвимых к нападению, и был найден оригинальный способ воздействия на маршрутизаторы цифровой абонентской линии (DSL-Digital Subscriber Line) фирмы Cisco. После нападения червя на маршрутизаторы DSL с интерфейсом Web-администрирования они работали неустойчиво, аварийно завершались, способствуя тем самым отказу в обслуживании. В результате клиенты Qwest и некоторых других известных Интернет-провайдеров остались без доступа к сети, пораженной червем. Из-за деятельности червя инфицированная сеть была перегружена операциями сканирования.

Утечка информации

   Утечку информации можно сравнить с протечкой воды из прохудившихся труб. Почти всегда утечка информации нежелательна и заканчивается неприятностями. Как правило, утечка информации – результат неправильного обращения с ресурсом, от которого зависит возможность нападения. Точно так же как генералы полагаются на сведения разведчиков, проникших в тыл врага, так и злоумышленники проникают в сеть для выполнения аналогичных задач, собирая информацию о программах, операционных системах и архитектуре сети, намеченной для нападения.
Пути утечки информации
   Пути утечки информации различны. Один из возможных путей – баннеры. Баннеры – текст, предъявляемый пользователю при регистрации в системе посредством той или иной службы. Баннеры можно найти в протоколах FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), POP3 (Post Office Protocol v. 3, оболочках безопасности (SSH-secure shell), службе telnet. Большинство программного обеспечения этих служб услужливо предоставляют внешним пользователям информацию о своей версии и конфигурации, как показано на рис. 3.3.
   Рис. 3.3. Версия демона SSH

   Другой путь – сообщения об ошибках. Часто Web-сервера предоставляют избыточную информацию о себе при возникновении исключительных условий. Исключительные условия определяются обстоятельствами, отличными от нормальных условий работы, например запросом несуществующей страницы или неопознанной командой. В этой ситуации лучше всего предусмотреть возможность настройки формата выдачи диагностических сообщений или тщательно продумать (workaround) формат выдачи диагностики. На рисунке 3.4 показано излишне болтливое сообщение об ошибке Apache.
   Рис. 3.4. Разглашение информации о версии HTTP-сервера

Анализ протоколов
   Обзор путей утечки информации будет неполным, если не сказать об анализе протоколов (protocol analysis). Существуют различные варианты анализа протоколов. В одном из вариантов используются ограничения, предусмотренные при разработке протоколов якобы для предотвращения выдачи избыточной информации о системе. Посмотрите на этот FTP-запрос system type:

   elliptic@ellipse:~$ telnet parabola.cipherpunks.com 21
   Trying 192.168.1.2...
   Connected to parabola.cipherpunks.com.
   Escape character is “^]”.
   220 parabola FTP server (Version: 9.2.1-4) ready.
   SYST
   215 UNIX Type: L8 Version: SUNOS

   В HTTP – аналогичная проблема. Посмотрите, как выбалтывается информация о системе в заголовке HTTP посредством команды HEAD:

   elliptic@ellipse:~$ telnet www.cipherpunks.com 80
   Trying 192.168.1.2...
   Connected to www.cipherpunks.com.
   Escape character is “^]”.
   HEAD / HTTP/1.0

   HTTP/1.1 200 OK
   Date: Wed, 05 Dec 2001 11:25:13 GMT
   Server: Apache/1.3.22 (Unix)
   Last-Modified: Wed, 28 Nov 2001 22:03:44 GMT
   ETag: “30438-44f-3c055f40”
   Accept-Ranges: bytes
   Content-Length: 1103
   Connection: close
   Content-Type: text/html

   Connection closed by foreign host.

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

   elliptic@ellipse:~$ nmap -sS -O parabola.cipherpunks.com

   Starting nmap V. 2.54BETA22 (www.insecure.org/nmap/)
   Interesting ports on parabola.cipherpunks.com (192.168.1.2):
   (The 1533 ports scanned but not shown below are in state:
   closed)

   Port State Service
   21/tcp open ftp
   22/tcp open ssh
   25/tcp open smtp
   53/tcp open domain
   80/tcp open http

   Remote operating system guess: Solaris 2.6 – 2.7
   Uptime 5.873 days (since Thu Nov 29 08:03:04 2001)

   Nmap run completed – 1 IP address (1 host up) scanned in 67 seconds

   Во-первых, давайте выясним смысл флажков, использованных для сканирования системы parabola. Флаг sS используется при SYN-сканировании для исследования полуоткрытых соединений с целью определения открытых портов хоста. O флаг указывает Nmap на необходимость идентификации операционной системы, если это возможно, на основе ранее выявленных и сохраненных в базе данных особенностей реакции систем на сканирование. Как вы можете видеть, Nmap смог идентифицировать все открытые порты системы и достаточно точно определить операционную систему системы parabola (на самом деле это была операционная система Solaris 7, выполняющаяся на платформе Sparc).
   Приведенные примеры показывают пути утечки информации, которые помогли злоумышленнику собрать обширные сведения о сети при подготовке к нападению.
   Примечание
   Один примечательный проект, связанный с утечкой информации, – исследование протокола ICMP (протокол управляющих сообщений в сети Internet), проводимое Офиром Аркином (Ofir Arkin). На его сайте www.sys-security.com размещено несколько html-страниц, на которых обсуждаются методы использования ICMP для сбора важной информации. Две страницы, озаглавленные «Identifying ICMP Hackery Tools Used In The Wild Today» («Современный инструментарий дикого хакера для идентификации ICMP») и «ICMP Usage In Scanning» («Использование ICMP для сканирования»), доступны на www.sys-security.com/html/papers.html. Они не предназначены для щепетильных людей, но содержат много информации.
Утечка информации об архитектуре сети
   Это общая проблема. Некоторые программы любезно и охотно предоставляют важную информацию об архитектуре сети. Протоколы типа SNMP (Simple Network Management Protocol) предусматривают открытое описание соединений для взаимодействия с другими системами. Ухудшает положение дел и то, что в очень многих реализациях протокола SNMP для ограничения предоставления сведений об архитектуре сети применяются примитивные или легкоугадываемые процедуры аутентификации.
   Печально, но SNMP все еще широко используется. Например, маршрутизаторы Cisco поддерживают SNMP. Некоторые операционные системы типа Solaris устанавливают и запускают SNMP-средства по умолчанию. Помимо других уязвимостей, найденных в этих средствах, их использование с конфигурацией по умолчанию – явно плохая практика.

   Утечка с Web-серверов
   Предварительно уже говорилось о чрезмерно болтливых Web-серверах, сообщающих назойливым пользователям лишние сведения о себе при некоторых режимах их работы. Эта проблема еще более усложняется, когда используются такие вещи, как PHP, CGI (Common Gateway Interface) и мощные машины поиска. Подобно любому другому инструментарию, они могут использоваться как на пользу, так и во вред.
   Так, PHP, CGI и машины поиска могут использоваться для создания интерактивных Web-средств, настраиваемой среды пользователя для работы в Интернете и автоматизации предпринимательской деятельности. А могут использоваться и для злонамеренных действий, особенно если в их реализации есть ошибки. Беглое знакомство с документом ARIS (Attack Registry and Intelligence Service) показывает, что под номером 3 в нем значится тип атак, использующих обход директории («Generic Directory Traversal Attack»). (Этим типам атак в документе предшествуют атаки с использованием ISAPI и нападения типа cmd.exe, которые на момент написания книги были очень многочисленными и разнообразными.) В группу атак на основе обхода директории входят атаки типа dot-dot (..) или атаки относительного пути (…), в ходе которых в URL добавляются точки для выяснения, приведет ли это к переходу в другую директорию и выдаче листинга или выполнению программы на Web-сервере.
   Сценарии, которые предоставляют возможность обхода директорий, позволяют не только кому-либо сменить директорию и просмотреть список файлов системы. Они позволяют злоумышленнику прочитать любой файл, читаемый HTTP-сервером с учетом монопольного использования и группового членства. А это, в свою очередь, может позволить пользователю получить доступ к файлу паролей passwd в директории /etc и к другим непривилегированным файлам Unix-систем или иных систем, например Microsoft Windows, привести к чтению (а потенциально и к записи) привилегированных файлов. Любые данные, полученные в результате этого типа атак, могут быть использованы для подготовки более опасных нападений. Web-сценарии и приложения должны стать темой тщательного рассмотрения еще до их установки. Подробнее познакомиться с ARIS можно по адресу http://ARIS.securityfocus.com.

   Гипотетический сценарий
   Некоторые программы, например Sendmail, в большинстве своих реализаций по умолчанию предоставляют сведения о пользователях системы. Усугубляет ситуацию еще и то, что эти программы используют пользовательскую базу данных как справочник для адресов электронной почты. Кое-кто, возможно, лишь усмехнется, услышав рассуждения о возможности утечки информации. В этом случае задумайтесь над следующим примером.
   В маленьком городке два Интернет-провайдера. Интернет-провайдер A появился позднее Интернет-провайдера B и быстро развивается, существенно увеличивая число своих клиентов. Интернет-провайдер B обосновался в городке раньше A и владеет большим процентом клиентов. Интернет-провайдер B ведет конкурентную войну с Интернет-провайдером A, недовольный тем, что A ограничивает сферу деятельности B и выбивает почву из-под его ног. У Интернет-провайдера A работают более квалифицированные системные администраторы, которые смогли воспользоваться преимуществами различных программных средств, ограничив доступ пользователей к важной информации. Они достигли этого с помощью таких ухищрений, как организация почты (hosting mail) на отдельном сервере, использование различных регистрационных имен оболочки сервера для исключения возможности получения доступа к базе данных почтовых адресов различным пользователям. Однако Интернет-провайдер B не предпринял таких мер предосторожности. Однажды сотрудников Интернет-провайдера A осенила блестящая идея, как получить учетные записи Интернет-провайдера B. Эти учетные записи позволят им сначала получить доступ к почтовому серверу Интернет-провайдера B, а затем легко завладеть файлом паролей passwd. Зная пароли, можно будет по почте отправить всем пользователям Интернет-провайдера B предложение о сотрудничестве с Интернет-провайдером A, предлагая им существенные скидки по сравнению с текущими расходами у Интернет-провайдера B.
   Как вы можете видеть, утечка подобной информации может привести не только к взлому системы безопасности, но и, возможно, к банкротству. Предположим, что компания смогла получить доступ к информационным системам своего конкурента. Что остановит ее от кражи, дезинформации, мошенничества и осуществления всего того, что можно сделать для подрыва честной конкуренции? Дни наивности в Интернете закончены.
Почему опасна утечка информации?
   В силу различных причин всегда найдутся люди, которые не обеспокоены утечкой информации. Такое отношение к утечке информации объясняется, например, тем, что, по их мнению, утечку информации остановить невозможно и тайное всегда станет явным, или тем, что без допуска к некоторой хранимой на сервере информации нельзя наладить доверительные отношения с клиентами. Сюда относится и такая возможность, как «снятие отпечатков пальцев» систем, смысл которой состоит в идентификации систем на основе сравнения реакции системы с ожидаемыми действиями.
   Любая грамотно разработанная операционная система предоставляет возможности или для уклонения от «снятия отпечатков пальцев», или для затруднения проведения идентификации системы на их основе, требуя проведения дополнительных мероприятий. Некоторые системы даже предоставляют возможность посылки поддельных «отпечатков пальцев» чрезмерно навязчивым хостам. Причины этого очевидны. Возвращаясь к примеру из военной области, отметим, что зачастую подготовка к предстоящему нападению тщательно скрывается для достижения эффекта неожиданности. Это может достигаться маскировкой своих сил, скрытию их передислокации, передаче только зашифрованных сведений и т. д. Подобное ограничение утечки информации заставляет неприятеля принимать решения без знания истинного положения дел, увеличивая тем самым возможность совершения ошибки.
   Поэтому, по аналогии с армией, для которой существует риск нападения на нее грозного врага, следует приложить максимум усилий для скрытия ресурсов собственной сети от сбора сведений и предотвратить утечку информации. Любая имеющая значение информация о сети, которая окажется в распоряжении злоумышленника, предоставит ему возможность сделать обоснованные выводы в нужном направлении. Устранение утечки информации вынуждает злоумышленника предпринимать дополнительные меры для сбора необходимой ему информации. Возросшая активность злоумышленника увеличивает шансы его обнаружения.

Нарушения прав доступа к файлу

Права
   Один из самых простых способов обеспечить безопасность файла состоит в обеспечении прав работы с ним. Часто это один из наиболее освещаемых аспектов безопасности системы. Некоторые однопользовательские системы типа Microsoft Windows 3.1/95/98/ME не поддерживают права доступа к файлам. В то же время многопользовательские системы имеют, по крайней мере, одно, а обычно несколько возможностей управления доступом к файлам.
   Например, Unix-подобные системы и некоторые Windows-системы поддерживают пользователей и группы пользователей, позволяют задавать атрибуты файлов для указания прав пользователя и группы пользователей на выполнение тех или иных действий с файлом. Пользователь или владелец файла может быть наделен правами полного управления файлом, включая операции чтения, записи и выполнения других разрешенных действий с файлом. В то же время пользователь группы, назначенной этому файлу, может иметь права на чтение и выполнение файла, а пользователи, не являющиеся владельцами файла или членами группы, могут обладать другим набором прав или вообще не иметь никаких разрешений на работу с файлом.
   В дополнение к стандартному набору прав владельца файла группы пользователей и многие Unix-подобные системы поддерживают более изощренные методы разрешения доступа к файлу. Их реализация разнообразна: от простого – типа предоставления возможности определить, какие пользователи имеют доступ к файлу, – до более сложного – назначения ролевого имени для открытия пользователям доступа к набору утилит. В составе операционной системы Solaris имеется два таких примера: ролевое управление доступом (Role-Based Access Control – RBAC) и списки управления доступом (ACL – Access Control Lists).
   Списки управления доступом ACL позволяют пользователю определить доступ к файлу для отдельных пользователей системы. Список доступа связан с владельцем и членством в группе.
   Ролевое управление доступом RBAC – сложный инструментарий, предусматривающий различные слои прав. Инструментарий можно настраивать, предоставляя пользователям обширные общие роли для выполнения таких функций, как добавление пользователей, изменение некоторых настроек системы и т. п. Также можно ограничить права пользователей, разрешив им выполнять только отдельные функции.
   Примечание
   Дополнительные сведения о RBAC и ACL можно найти в книге издательства Syngress Hack Proofing Sun Solaris 8 (ISBN 1-928994-44-X).
Атаки символических связей
   Атаки символических связей – это проблема, которая обычно используется злоумышленником для реализации своих замыслов. Цель подобных атак состоит в изменении полномочий работы с файлом, разрушении файла в результате добавления в конец новых данных или перезаписи файла с уничтожением ранее содержащейся в нем информации.
   Атаки символических связей часто начинаются из директорий для хранения временных данных. Обычно проблема возникает из-за ошибки программирования. Когда запускается уязвимая программа, она создает файл с параметрами, делающими его уязвимым для нападения. Таких параметров два.
   Первый – права работы с файлами. Второй – создание небезопасных временных файлов, то есть уязвимых для нападения злоумышленника. Если файл был создан с опасными с точки зрения безопасности системы правами работы, то он может быть изменен злоумышленником. В зависимости от алгоритма работы программы возможна ситуация, когда измененные злоумышленником данные временного файла могут быть переданы сессии пользователя.
   Во втором случае, если программа не проверяет существование файла на диске перед его созданием, атака на систему реализуется следующим образом. Если пользователь в состоянии определить имя временного файла прежде, чем он будет создан, то создается символическая связь с временным файлом, который будет создан и который намечен для нападения. В следующем примере продемонстрирован исходный текст программы, создающей файл с предсказуемым именем:

   /* lameprogram.c – Hal Flynn <mrhal@mrhal.com> */
   /* does not perform sufficient checks for a */
   /* file before opening it and storing data */
   #include <stdio.h>
   #include <unistd.h>
   int main()
   {
   char a[] = “This is my own special junk data
   storage.\n”;
   char junkpath[] = “/tmp/junktmp”;
   FILE *fp;
   fp = fopen(junkpath, “w”);
   fputs(a, fp);
   fclose(fp);
   unlink(junkpath);
   return(0);
   }

   Эта программа создает файл /tmp/junktmp без первоначальной проверки его существования.
   Пусть во время выполнения программы, создающей небезопасный временный файл, создаваемый файл уже существует. Тогда файл, указанный в символической связи, будет или перезаписан, или в конец этого файла будут добавлены новые данные при условии, если пользователь, выполняющий потенциально опасную программу, имеет право на запись в файл. Рисунки 3.5 и 3.6 демонстрируют пример использования подобной программы пользователем haxor для перезаписи файла пользователя ellipse.
   Рис. 3.5. Пользователь haxor создает злонамеренную символическую ссылку

   Рис. 3.6. В результате выполнения программы Lameprogram пользователем Ellipse осуществляется перезапись данных файла Lamedata

Дезинформация

   Можно предположить, что генерал неприятеля уже думал над возможными вариантами своих действий при подобном развитии обстановки. Например, он может решить скрывать свои силы, пока не убедится, что перед ним никого нет. «Но что, если кто-то увидит мои наступающие силы, – может быть его следующей мыслью. – И если противостоящий мне неприятель пошлет разведчиков для разведки моих сил и занимаемых ими позиций, которые найдут мою армию сильнее, чем свою, то неприятель, вероятно, или укрепит свои позиции, или отойдет на другие позиции, где на них труднее напасть или где их нельзя обнаружить».
   Поэтому вражеский генерал может захотеть представить свои силы менее опасными, чем они являются в действительности. Он может спрятать тяжелое вооружение и большую часть пехоты, оставляя на обозрении только маленькую часть своих сил. В основе дезинформации лежит та же самая идея.
Способы и инструментарий дезинформации
   Как правило, после компрометации системы злоумышленник прилагает максимум усилий для скрытия своего присутствия и распространения дезинформации. Злоумышленники добиваются этого при помощи ряда способов.
   Например, в системе Sun Solaris была обнаружена уязвимость, предоставляющая злоумышленнику дополнительные возможности для распространения дезинформации. Речь идет об обработке списков контроля доступа ACL (access control list) на псевдотерминалах, подсоединенных к системе. После получения доступа к терминалу злоумышленник может установить элемент списка контроля доступа и завершить работу. Во время обращения другого пользователя к системе с того же самого терминала предыдущий владелец терминала (в данном случае злоумышленник) сохраняет за собой право записи на терминал, что позволит ему записать дезинформацию на терминал нового владельца.
   В следующих разделах рассмотрены некоторые из применяемых на практике способов дезинформации и соответствующего инструментария.

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

   Программы типа rootkit
   К средствам дезинформации можно отнести программы rootkit, предназначенные для скрытия деятельности злоумышленника в системе. Известно несколько вариантов этих программ с собственными возможностями и недостатками. Программа rootkit – первое, что выбирает злоумышленник для обеспечения длительного доступа к системе.
   Rootkit работает, подменяя в UNIX-системах ключевые системные программы типа ls, df, du, ps, sshd и netstat, а в Windows – драйверы и записи системного реестра. Rootkit заменяет эти программы, а возможно, и еще какие-нибудь, на другие, которые настроены таким образом, чтобы не предоставлять администраторам достоверной информации о работе системы. Вне всякого сомнения, программы типа rootkit используются для скрытия злоумышленника и его деятельности в системе и предназначены для дезинформации. Они подталкивают администратора к мысли о нормальной работе системы в то время, когда злоумышленник контролирует ее, атакует новые хосты или занимается другими нехорошими делами.

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

Доступ к специальным файлам / базам данных

Нападения на специальные файлы
   Проблема нападений на специальные файлы становится очевидной, если пользователь использует сервис RunAs операционной системы Windows 2000. Когда пользователь выполняет обращающуюся к RunAs программу, Windows 2000 создает поименованный канал (канал – механизм связи между процессами, который позволяет одному процессу передавать данные другому процессу), запоминая мандат аутентификации в незашифрованном виде. Если сервис RunAs остановлен, то злоумышленник может создать именованный канал под тем же самым именем. Когда сервис RunAs стартует еще раз, соответствующий процессу мандат будет передан злоумышленнику, что позволит злоумышленнику зарегистрироваться в системе пользователем сервиса RunAs.
   Аналогичные проблемы есть и в UNIX-системах. Уже упоминалось об одной из них – псевдотерминалах системы Solaris. В компоненте дистрибутива Red Hat Linux 7.1, отвечающего за обновление системы, была выявлена следующая уязвимость. Оказывается, у злоумышленника есть возможность тайно просматривать файл подкачки, создаваемый пользователем при обновлении системы. Это происходит из-за создания файла подкачки с атрибутами, которые разрешают всем пользователям читать его. Сначала злоумышленник, руководствуясь низменными целями, основательно загружает память системы, вынуждая систему использовать файл подкачки. А затем, при различных состояниях системы, несколько раз копирует файл подкачки, для того чтобы на досуге поискать в копиях пароли и другую важную информацию.
Нападения на базы данных
   Автор на одном из этапов своей карьеры собирался стать администратором базы данных, полагая, что это позволит ему усовершенствовать профессиональные навыки в обслуживании систем и их безопасности. Чем больше он входил в курс дела, тем сильнее убеждался в том, что по напряженности труда работа администратором баз данных сродни участию в боевых действиях, потому что от него зависит финансовое благополучие компании. И если пришлось бы выбирать, он лучше бы пошел добровольцем на войну.
   Базы данных всегда были лакомым кусочком для злоумышленника. Современная профессиональная деятельность людей зачастую немыслима без централизованного хранилища информации, в котором содержатся финансовые данные, сведения о кредитных карточках, платежные ведомости, списки клиентов и т. д. Одна только мысль о ненадежности баз данных способна лишить сна генерального директора, не говоря уже о доведении администратора баз данных до нервного срыва. Можно сказать, что сегодня электронная коммерция процветает. А где бизнес, там и базы данных.

   Зона риска
   Системы управления базами данных являются объектами нападения с двух сторон. Поскольку они относятся к программному обеспечению, то им присущи общие проблемы программ, как, например, переполнение буфера, отказ в обслуживании, скорость реакции. Дополнительно к этому системы управления базами данных – фоновая компонента большинства современных программ Web-интерфейса, средств графического интерфейса пользователя и т. д. Поэтому базы данных безопасны настолько, насколько безопасны программные средства интерфейса с пользователем и обработки данных.
   Наблюдается устойчивая зависимость безопасности баз данных от Web-интерфейса, по крайней мере, по двум причинам. Во-первых, зачастую программы Web-интерфейса завершаются аварийно при обработке специальных символов. Во-вторых, из-за неважного проектирования алгоритмов Web-интерфейса известны случаи неавторизованного доступа к базам данных. Сказанное подтверждается фактами регулярного нахождения ошибок в интерфейсах пакетов электронной коммерции.
   Сложно написать хорошую программу обработки информации, введенной пользователем. Пользователь всегда может ввести что-нибудь такое, что почти невозможно предусмотреть. Иногда – по невежеству, иногда – специально. Программа должна правильно обрабатывать специальные символы, например одинарные () и двойные (") кавычки, прямой (/) и обратный слэш (\) и некоторые другие, иначе быстро найдется желающий воспользоваться ошибками. Пропускающая спецсимволы программа интерфейса не сможет служить преградой для выполнения произвольно заданных команд.
   Плохо разработанный интерфейс – тема отдельного разговора. Ошибки в проектировании интерфейса позволяют злоумышленнику по своему желанию просматривать и удалять таблицы, выполнять SQL-запросы. Хотя в этом нет ничего нового, подобные инциденты происходят постоянно.

   Программные средства баз данных
   Программные средства баз данных богаты сюрпризами нарушения безопасности. Безопасность базы данных зачастую определяется безопасностью ее программных средств. И это не требует особых пояснений.
   Например, система управления базами данных Oracle может работать на нескольких платформах. Нишад Херат (Nishad Herath) и Брок Теллер (Brock Tell ier) из Network Associates COVERT Labs нашли уязвимость в версиях Oracle 8.1.5–8.1.7. Уязвимость была вызвана некорректной работой программы Oracle – TNS Listener.
   Для незнакомых с Oracle поясним, что программа TNS Listener облегчает подключения к базе данных и управляет ими. Она прослушивает произвольный порт данных, в последних версиях порт 1521/TCP, ожидая запроса на установку соединений к базе данных. После получения запроса программа разрешает пользователю зарегистрироваться в базе данных в соответствии с его мандатом (мандат – учетная запись с параметрами доступа пользователя, сформированными после его успешной аутентификации).
   Выявленная уязвимость проявляется при посылке откорректированного злоумышленником пакета Net8, который перехватывается программой TNS Listener. Логика работы программы TNS Listener такова, что этого оказывается достаточно для получения доступа к базе данных на локальной машине и выполнения произвольной программы на ней. Если для Unix-систем подобный дефект имеет большое значение, то для систем Windows – очень большое. Для Unix-систем найденная уязвимость позволяет злоумышленнику получить доступ к базе данных на локальной машине и зарегистрироваться пользователем Oracle, а для систем Windows – с привилегиями LocalSystem, эквивалентными правам администратора. Вопросы выполнения программы будут рассмотрены в следующей секции.
   Служба компьютерной безопасности предупреждает!
   Oracle – не единственный уязвимый программный продукт. Просматривая различные технические отчеты или базу язвимостей SecurityFocus, можно найти большое количество слабо защищенных программ, например MySQL или Microsoft SQL. Не дайте себя одурачить, делая поспешные выводы о безопасности тех или иных программ, поскольку в отчетах приведены cведения только об известных уязвимостях.

   Разграничение доступа в базах данных
   Напоследок обсудим разграничение доступа в базах данных. Большинство баз данных используют собственные средства разграничения доступа. Например, Microsoft SQL Server версии 6.5 (и более ранних) при выборе стандартной защиты использует свои собственные процедуры подтверждения достоверности при регистрации, а не аналогичные процедуры, предоставляемые операционной системой. Есть учетная запись SA с пустым паролем, которая создается при инсталляции SQL Server, она описывает права администратора во всех базах данных на сервере. Администратору рекомендуется заменить пароль по умолчанию учетной записи SA сразу же после инсталляции.
   Системы управления, работающие под управлением UNIX, также могут иметь собственные средства разграничения доступа. Например, у MySQL собственный список пользователей, не связанный со списком пользователей UNIX. В MySQL есть учетная запись root (которую не следует путать с основной учетной записью операционной системы UNIX), устанавливаемая по умолчанию без пароля. Если не назначить пароля этой учетной записи, то любой сможет подключиться к MySQL c максимально возможными правами, введя следующую команду:

   mysql – u root

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

   mysql – u root mysql

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

Удаленное выполнение программ

   Возвращаясь к примеру о разведчиках, предположим, что вражеская разведка просочилась мимо сторожевых постов и выследила позиции наших войск, нанесла их на карту и доложила о результатах разведки.
   Оценив полученные сведения, неприятель может принять решение о нанесении артиллерийского удара по выявленным целям. Предположим, что, зная технологию выдачи целеуказания, противоборствующая сторона в состоянии подменить выявленные цели ложными, для того чтобы вражеская артиллерия нанесла удар по своим силам.
   Точно так же и злоумышленник, имея возможность удаленного запуска произвольных программ в системе, может извлечь для себя выгоду, заставив программы работать против собственной системы. Известно несколько методов удаленного выполнения программ. Наиболее известны атаки, основанные на переполнении буфера и форматированных строках.
Атака
   Удаленное выполнение программ всегда осуществляется с использованием автоматизированного инструментария, как правило, при помощи скриптов. Практически невозможно выполнить программу вручную.
   Чаще всего целью удаленного выполнения программ является получение прав администратора на уязвимой системе. Подобным атакам обычно предшествует сбор информации при помощи автоматизированных средств сканирования для поиска уязвимых версий программного обеспечения. Если уязвимое программное обеспечение найдено, то для получения прав администратора злоумышленник запускает сценарий, использующий бреши в системе защиты идентифицированных программ.
   Примечание
   Дополнительные сведения об уязвимостях форматированных строк можно найти в главе 9 книги, которая посвящена детальному обсуждению уязвимостей форматированных строк, и дополнительно в официальном документе Team Teso's по адресу www.team-teso.net/articles/formatstring/index.html.
   Получив права администратора, он выполняет комплекс мероприятий по дезинформации, освещенный в секции «Дезинформация». Злоумышленник будет стараться скрыть свое присутствие в системе. После этого он может использовать скомпрометированный хост для начала атак.
   Хотя удаленное выполнение программ позволяет злоумышленнику вводить команды, тем не менее на их выполнение накладываются некоторые ограничения.
Ограничения удаленного выполнения программ
   Групповое членство и монопольное использование ресурса накладывают на удаленное выполнение программ точно такие же ограничения, как на процессы и работу пользователей.
   Как правило, в UNIX-системах привилегированные процессы – это процессы, взаимодействующие с портами, чьи номера меньше, чем 1024. Но некоторые пакеты программ, например Apache Web Server, тоже могут модифицировать групповое членство и условие монопольного использования ресурса, несмотря на то что это разрешено делать лишь привилегированным процессам. Злоумышленник, контролирующий HTTP-процесс Apache, может присвоить себе его привилегии. Но в этом случае он может получить доступ к системе только как непривилегированный пользователь, потому что по умолчанию предусмотрено понижение привилегий Apache после его запуска. Для расширения своих привилегий воспользовавшемуся непривилегированным процессом злоумышленнику потребуются другие уязвимости локальной системы и незаурядные способности, если он не хочет быть пойманным.
   Он может попытаться повлиять на процесс таким образом, чтобы вместо пользователя с более высокими привилегиями его могли запускать пользователи с более низкими. Это называется понижением привилегий (dropping privileges). В качестве ответной меры используется так называемая подмена корневого каталога (change root или chroot), которая заключается в следующем: Apache помещается в фальшивый корневой каталог для изоляции его процессов. Для подмены корневого каталога разработаны специальные программные средства, например программы-оболочки большинства сервисов, запирающие сервисы в так называемые изолированные подмененные корневые каталоги (chroot jail). Изолированные подмененные корневые каталоги были придуманы для ограничения пользователя рамками определенного каталога. Программа подмены корневого каталога разрешает доступ только к программам и библиотекам внутри этого каталога. Это ограничение – западня для неопытного злоумышленника.
   Если злоумышленник получает доступ к системе, но его прав недостаточно для осуществления своих замыслов, то, вероятнее всего, он попытается расширить свои права.

Расширение прав

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

   Удаленный непривилегированный пользовательский доступ
   При атаках на систему с использованием непривилегированных процессов можно наблюдать удаленное расширение прав непривилегированного пользователя. Подобное квалифицируется как расширение прав из-за того, что злоумышленник, не имеющий доступа к локальной системе до атаки, в результате атаки получает его. Некоторые люди, как ранее и сам автор, только усмехнутся, прочитав это. Координатор Bugtraq Дэвид Ахмад (David Ahmad) переубедил автора.
   Однажды ночью за чашечкой кофе автор совместно с Дэвидом обсуждали тему получения доступа к системе. Автор, основываясь на своем опыте обеспечения безопасности компьютерных систем, был совершенно убежден в их неприступности даже в том случае, если злоумышленнику удастся получить локальный доступ к системе. Автор был убежден, что защита, основанная на недопущении хранения в стеке выполнимого кода (non-executable stacks), ограниченный по своим возможностям пользовательский интерфейс, средства подмены корневой директории (chrooted environments) и небольшие setuid-программы не позволят злоумышленнику получить права администратора. Дэвид был настолько любезен, что доказал автору вопиющую неправоту его убеждений.
   В распоряжении злоумышленника имеются различные способы получения доступа непривилегированного пользователя к локальной системе. Возможно использование непривилегированных сервисов, таких как HTTP-демоны, процессов, работающих в рамках подмененной корневой директории, или других сервисов, запущенных со стандартными правами пользователей. Имеются и иные способы получения доступа к системе. В некоторых случаях пароли, полученные из исходных текстов ASP (Active Server Pages – активные серверные страницы (протокол ASP – разработанная корпорацией Microsoft технология, с помощью которой Web-мастер может динамически формировать автоматически обновляемые Web-страницы)), позволяют злоумышленнику получить доступ обычного пользователя. Печально известная проблема заключается в ошибке фильтрования спецсимволов программами Web-интерфейсов. Если атакующий сможет добиться передачи спецсимволов из Web-интерфейса в систему, то он сможет связать порт системы с оболочкой. Вероятно, это и не позволит ему сейчас получить права администратора, но он получит права HTTP-процесса позднее. По словам Дэвида Ахмада: «Это – только вопрос времени».

   Удаленный привилегированный пользовательский доступ
   Приобретение злоумышленником удаленного привилегированного пользовательского доступа чревато более тяжкими последствиями. Если удаленный пользователь сможет получить доступ к системе с правами привилегированного пользователя, целостность системы будет нарушена. Можно говорить о получении злоумышленником удаленного привилегированного пользовательского доступа при условии приобретения им прав, предоставляемых учетными записями uucp, root, bin или sys в UNIX-системах, или же Administrator либо LocalSystem в Windows 2000.
   Методы получения удаленного привилегированного или непривилегированного пользовательского доступа по существу одинаковые, за исключением нескольких ключевых моментов. Одно отличие заключается в использовании сервисов. Для того чтобы получить удаленный доступ на правах пользователя, злоумышленник должен использовать процесс с правами привилегированного пользователя.
   Большинство сервисов UNIX все еще выполняются с правами привилегированных пользователей. В некоторых из них, как telnet и SSH, недавно были обнаружены серьезные уязвимости. Особенно серьезна ошибка в SSH, первоначально обнаруженная Михаилом Залевски (Michal Zalewski) и преданная огласке в феврале 2001 года. Не вникая в сложные детали, отметим только, что уязвимость позволяет удаленному пользователю инициировать злонамеренное сетевое соединение, защищенное криптографическими средствами, с демоном. После установления соединения злоумышленник может, воспользовавшись недостатками протокола, запустить произвольную программу с правами администратора, связав оболочку с портом, закрепленным за нулевым идентификатором пользователя.
   Аналогичная уязвимость была недавно обнаружена в Windows 2000 IIS (Internet Information Server – информационный сервер Internet), что позволило успешно атаковать системы Windows NT. IIS 5.0 выполняется с правами, эквивалентными правам администратора. Проблема заключалась в переполнении буфера индексации инфраструктуры ISAPI IIS 5.0. Благодаря ей стали возможны различные вторжения, например червя Code Red и его модификаций.
   Получение удаленного привилегированного пользовательского доступа является целью большинства Троянских коней и скрытых программ (backdoor programs). Такие программы, как SubSeven, Back Orifice, и их варианты могут применяться для получения злоумышленником удаленного привилегированного пользовательского доступа к инфицированной системе. Эти программы широко используют методы социотехники, дезинформации или убеждения, для того чтобы заставить пользователя запустить программу с правами привилегированного пользователя. После их выполнения злоумышленнику потребуется связаться тем или иным способом с запущенной программной, чтобы наблюдать за инфицированной системой, управлять ее работой и работой ее пользователей.
   Целью других атак может быть получение прав иных привилегированных пользователей, отличных от администратора. Злоумышленник, завладевший такими правами, сильно отличается по своим возможностям от обычного пользователя, поскольку теперь он может получить доступ к жизненно важным компонентам системы. К тому же пользователь, получивший доступ к системным учетным записям, отличным от записи администратора, вероятно, позднее сможет получить его права.
   То же самое справедливо и для повышения прав на локальной системе. При помощи социотехники или вредной программы пользователь с локальными непривилегированными правами может добиться повышения своих прав на локальной системе.

Методы тестирования уязвимостей

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

Доказательство возможности нападения

   Доказательство возможности нападения проводится для демонстрации уязвимостей в системе. Доказательство не проводится само по себе, оно проводится для демонстрации проблем с использованием небольших безопасных для системы программ или технического описания, позволяющего пользователю воспроизвести проблему. Доказательство возможности нападения может использоваться членом сообщества для выявления источника проблем, формулирования рекомендаций по вычищению программ с целью максимального устранения недоделок в них и, в некоторых случаях, рекомендаций по исправлению ошибок до выхода патчей производителя, а также для обнаружения уязвимых систем.
   Доказательство возможности нападения используется как средство уведомления сообщества безопасности о проблеме при возникновении даже незначительных подозрений с целью опережения злоумышленника. Узнав о проблеме, у производителя появляется возможность решить ее и выпустить заплатку раньше, чем злоумышленник научится извлекать из нее выгоду и ринется в безумную атаку.
Написание программ, демонстрирующих проблему
   Написание программ, демонстрирующих проблему, — еще один метод, используемый сообществом безопасности. В первом написание демонстрирующих проблему программ может быть определено как написание программ, так или иначе использующих выявленную уязвимость и преимущества программирования. Конечно, это может быть использовано для извлечения личной выгоды.
   Написание программ, демонстрирующих проблему, может быть отнесено к доказательству возможности нападения, поскольку в результате на практике демонстрируется существование уязвимости и детали атаки на нее. Программа может быть написана на разных языках: например, C, Perl или ассемблер.
   Написание подобных программ – обоюдоострый меч. С одной стороны, общественности предоставляются программы, демонстрирующие уязвимости и возможности их использования для личной выгоды, а с другой – злоумышленнику невольно предоставляются средства нападения на системы. В целом же написание демонстрирующих проблему программ – хорошая вещь, потому что вносит ясность в рассмотрение выявленной уязвимости и подталкивает производителей к исправлению ошибок и выпуску заплаток.
   Зачастую производитель с удовольствием не торопился бы с выпуском заплаток, позволяя злоумышленнику, знающему об уязвимости и инструментарии работы с ней, воспользоваться ею. Поэтому написание демонстрирующих проблему программ позволяет акцентировать на ней внимание и подстегнуть производителей, перекладывая на их плечи всю ответственность после обнародования сведений об уязвимости.
   Как уже говорилось, обсуждаемые программы – обоюдоострый меч. Предание гласности программ, демонстрирующих проблему, на практике означает появление работающих программ, которые могут служить источником личной выгоды. Большинство форумов, на которых разглашаются технические детали уязвимостей программного обеспечения и распространяются использующие их программы, многими участниками оцениваются по-разному. Обсуждение программ на форуме может позволить некоторым непорядочным членам форума воспользоваться свободно распространяемыми программами демонстрации проблем для личной или злонамеренной выгоды.
Автоматизированный инструментарий безопасности
   Автоматизированный инструментарий безопасности – это пакеты программ, разработанные производителями для автоматизированного тестирования систем безопасности. Обычно это программы с хорошим пользовательским интерфейсом и средствами генерации отчетов. Генерация отчетов позволяет пользователям инструментальных средств распечатать детальный список проблем и наметить пути их решения.
   Автоматизированный инструментарий безопасности – еще один обоюдоострый меч. С одной стороны, он позволяет законным владельцам инструментария проводить аудит безопасности своих сетей и повышать тем самым их безопасность. А с другой – позволяет злонамеренным пользователям находить уязвимости в системе и использовать их для личной выгоды.
   Но все же автоматизированный инструментарий безопасности полезен всем. Он позволяет недостаточно квалифицированным пользователям определить уязвимые хосты и обеспечить их безопасность. Еще полезнее средства обновлений с подключаемыми программами (plug-ins), разработанными для выявления новых или недавно обнаруженных уязвимостей.
   Различные производители выпускают различные средства автоматизированного тестирования. Среди них можно выделить CyberCop Security Scanner, выпущенный Network Associates, NetRecon компании Symantec и Internet Scanner – производитель Internet Security Systems. Свободно распространяется Nessus от Nessus Project. Более подробно с ними можно познакомиться в главе 17 книги.
Контроль версий
   Контроль версий (versioning) – отказоустойчивый метод тестирования систем на наличие уязвимостей. По сравнению с ранее упомянутыми методами его не так часто используют, но он приводит к надежным результатам.
   Контроль версий заключается в определении версии или редакции используемого программного обеспечения. Это может оказаться сложным, поэтому большинство программного обеспечения различается версиями, как, например, Windows 2000 Professional или Solaris 8, а многие из пакетов, помимо своей версии, характеризуются еще и версиями включаемых программ, например wget версии 1.7. На практике это часто приводит к необходимости решения сложных проблем, как, например, кошмар с дистрибутивом Linux, который является сборищем различных версий разного программного обеспечения.
   Контроль версий осуществляется во время анализа ассортимента предлагаемых программ. Идея очень проста – ищутся версии программ с известными уязвимостями. Поиск выполняется различными способами. Один из способов состоит в выдаче команды отображения версии проверяемой программы, например команды uname, как это показано на рис. 3.7.
   Рис. 3.7. Определение редакции ядра Linux с помощью команды uname-a

   Другой метод использует предоставляемые производителем средства определения на вашей машине последней редакции системы (см. рис. 3.8).
   Рис. 3.8. Проверка редакции Sun Solaris System при помощи команды showrev-p

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

Стандартные методы исследования

   Уже говорилось о том, что 97 % злоумышленников – это неопытные пользователи-недоумки. Действительно опасные – остальные 3 %. У этой группы есть чему поучиться, при условии что полученные знания не будут использованы для достижения зловредных целей. Ланс Спитзнер (Lance Spitzner), один из наиболее хорошо подготовленных специалистов по вопросам безопасности (и вообще всесторонне развитый человек), некоторое время назад написал несколько работ, в которых все расставил по своим местам. Заимствуя принцип Сан Цзу (Sun Tzu) из его книги «Искусство войны», работы Спицнера были озаглавлены «Узнай своего врага». Они доступны по адресу http:// project.honeynet.org.
   В первую очередь следует обратить внимание на интеллектуальные нападения. Нападение – акт агрессии, а интеллектуальность предполагает твердые навыки познавательной деятельности. При подготовке интеллектуальной атаки осуществляется сбор информации либо с использованием утечки информации, либо при помощи доступных ресурсов Интернета. Рассмотрим некоторые методы, основанные на использовании базы данных Whois, службы имен доменов (DNS – Domain Name System), программы Nmap и индексирования Web.
База данных Whois
   Whois – это общедоступная база данных, содержащая информацию о владельцах сетевых ресурсов. База данных Whois подразделяется на базы данных Whois доменов. com, biz и базу данных Американского регистра Интернет-адресов (ARIN – American Registry of Internet Numbers), которые содержат сведения об именах служб и сетях.

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

   elliptic@ellipse:~$ whois cipherpunks.com
   Whois Server Version 1.3
   Domain names in the .com, .net, and .org domains can now be
   registered
   with many different competing registrars. Go to http://
   www.internic.net
   for detailed information.
   Domain Name: CIPHERPUNKS.COM
   Registrar: ENOM, INC.
   Whois Server: whois.enom.com
   Referral URL: http://www.enom.com
   Name Server: DNS1.ENOM.COM
   Name Server: DNS2.ENOM.COM
   Name Server: DNS3.ENOM.COM
   Name Server: DNS4.ENOM.COM
   Updated Date: 05-nov-2001
   >>> Last update of whois database: Mon, 10 Dec 2001 05:15:40
   EST <<<
   The Registry database contains ONLY .COM, .NET, .ORG, .EDU
   domains and Registrars.
   Found InterNIC referral to whois.enom.com.
   Access to eNom’s Whois information is for informational
   purposes only. eNom makes this information available “ as is,”
   and does not guarantee its accuracy. The compilation,
   repackaging, dissemination or other use of eNom’s Whois
   information in its entirety, or a substantial portion
   thereof, is expressly prohibited without the prior written
   consent of eNom, Inc. By accessing and using our Whois
   information, you agree to these terms.
   Domain name: cipherpunks.com
   Registrant:
   Cipherpunks
   Elliptic Cipher (elliptic@cipherpunks.com)
   678-464-0377
   FAX: 770-393-1078
   PO Box 211206
   Montgomery, AL 36121
   US
   Administrative:
   Cipherpunks
   Elliptic Cipher (elliptic@cipherpunks.com)
   678-464-0377
   FAX: 770-393-1078
   PO Box 211206
   Montgomery, AL 36121
   US
   Billing:
   Cipherpunks
   Elliptic Cipher (elliptic@cipherpunks.com)
   678-464-0377
   FAX: 770-393-1078
   PO Box 211206
   Montgomery, AL 36121
   US
   Technical:
   Cipherpunks
   Elliptic Cipher (elliptic@cipherpunks.com)
   678-464-0377
   FAX: 770-393-1078
   PO Box 211206
   Montgomery, AL 36121
   US
   DOMAIN CREATED : 2000-11-12 23:57:56
   DOMAIN EXPIRES : 2002-11-12 23:57:56
   NAMESERVERS:
   DNS1.ENOM.COM
   DNS2.ENOM.COM
   DNS3.ENOM.COM
   DNS4.ENOM.COM

   Из примера видно, как можно узнать регистрационные сведения владельца домена Cipherpunks.com: его имя, адрес, контактные номера телефонов и факса.
   С точки зрения безопасности, база данных Whois – находка для злоумышленника, потому что она содержит информацию, которая может быть использована для атаки на сервер и установления контроля над доменами. Например, названия серверов доменных имен.
   В последнее время регулярно наблюдаются попытки злоумышленников использовать почтовые адреса лиц, зарегистрировавших домен. Для этого, в случае одновременного администрирования одного домена несколькими людьми, могут быть применены методы социотехники. Наиболее часто добытые таким способом сведения используются для распространения спама. Такие компании, как Network Solutions, даже продают подобную информацию фирмам «направленного маркетинга» (метод маркетинга, при котором компании рассылают образцы своей продукции потенциальным заказчикам), прославившимся распространением спама. Эти фирмы в буквальном смысле слова захламляют почтовый ящик жертвы различным мусором. То, как это происходит, описано в статье Newsbytes «ICANN To Gauge Privacy Concerns Over 'Whois' Database», доступной в Интернете по адресу www.newsbytes.com/news/01/166711.html.

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

   elliptic@ellipse:~$ whois -h whois.arin.net 66.38.151.10
   GT Group Telecom Services Corp. (NETBLK-GROUPTELECOM-BLK-
   3) GROUPTELECOM-BLK-3
   66.38.128.0 – 66.38.255.255
   Security Focus (NETBLK-GT-66-38-151-0) GT-66-38-151-0
   66.38.151.0 – 66.38.151.63
   To single out one record, look it up with “!xxx”, where xxx
   is the handle, shown in parenthesis following the name,
   which comes first.
   The ARIN Registration Services Host contains ONLY Internet
   Network Information: Networks, ASN’s, and related POC’s.
   Please use the whois server at rs.internic.net for DOMAIN
   related Information and whois.nic.mil for NIPRNET
   Information.

   Как можно заметить, адреса Интернет от 66.38.151.0 до 66.38.151.63 закреплены за SecurityFocus. Кроме того, эти адреса принадлежат GT Group Telecom.
   Подобная информация позволяет злоумышленникам очертить границы будущего нападения. Если злоумышленник захочет скомпрометировать хост сети SecurityFocus, ему нужно только выбрать хост сетевого сегмента, поддерживаемый ARIN. А затем, используя скомпрометированный хост сети, выбрать другие хосты той же самой или другой сети.
Служба имен доменов
   Служба имен доменов (DNS) – еще одно средство в арсенале злоупотреблений злоумышленника для сбора информации в процессе подготовки атаки на сеть. Люди, принимая решение об использовании DNS на каждом хосте Интернета, часто даже не подозревают о той удавке, которую они накидывают себе на шею. Не обсуждая недостатки протокола, которые приводят к подобным последствиям, сконцентрируемся на злоупотреблениях DNS.
   Источник уязвимостей был обнаружен в широко распространенной программе разрешения имен в Интернете BIND. Служба доменных имен в сети Интернет или BIND (Berkley Internet Name Domain – программа для поддержки сервера имен доменов, первоначально написанная для UNIX, в настоящее время является наиболее популярной реализацией DNS и перенесена практически на все платформы. BIND задает структуру баз данных, функции DNS и конфигурационные файлы, требующиеся для установки и функционирования сервера имен) ранее имела ряд уязвимостей, которые позволяли злоумышленнику получать удаленный административный доступ. Также известна уязвимость в старших версиях программы, при помощи которой можно подменять содержимое кэш DNS, дурача клиентов. Подмена состояла в изменении занесенного в кэш соответствия между доменом и его адресом. В результате пользователь вместо желаемого сайта мог попасть куда угодно. Далее рассмотрим методы определения уязвимостей, возникающие при работе DNS.

   Утилита dig
   dig – легкодоступный инструментарий, тесно связанный с программой BIND. В утилите предусмотрен как интерактивный режима запуска, так и удобный режим командной строки, позволяющий собирать сведения о DNS-сервере. Утилита dig выполняется под управлением многих свободно распространяемых операционных систем и может поставляться консорциумом программного обеспечения Интернет (Internet Software Consortium) совместно с BIND.
   Утилита dig может быть использована для определения IP-адресов по их именам (прямое преобразование) и, наоборот, определения доменного имени хоста по его адресу (обратное преобразование). Это может оказаться очень полезным из-за того, что много приложений не смогут определить IP-адрес по имени, а для нормального функционирования им нужно указать явный адрес хоста.
   Также утилита dig может использоваться для определения версии серверов DNS. Поступив таким образом, злоумышленник может собрать необходимые для начала атаки сведения о хосте. Но, самостоятельно определив версию сервера имен, специалист по безопасности сможет сам найти потенциально уязвимый сервер и повысить безопасность охраняемой системы (вспомните метод определения версий).
   Проанализируйте следующий пример использования утилиты dig:

   elliptic@ellipse:~$ dig @pi.cipherpunks.com TXT CHAOS
   version.bind
   ; <<>> DiG 8.2 <<>> @pi.cipherpunks.com TXT CHAOS
   version.bind
   ; (1 server found)
   ;; res options: init recurs defnam dnsrch
   ;; got answer:
   ;; ->>HEADER<<– opcode: QUERY, status: NOERROR, id: 6
   ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0,
   ADDITIONAL: 0
   ;; QUERY SECTION:
   ;; version.bind, type = TXT, class = CHAOS
   ;; ANSWER SECTION:
   VERSION.BIND. 0S CHAOS TXT “8.2.1”
   ;; Total query time: 172 msec
   ;; FROM: ellipse to SERVER: pi.cipherpunks.com 192.168.1.252
   ;; WHEN: Mon Dec 10 07:53:27 2001
   ;; MSG SIZE sent: 30 rcvd: 60

   Из отчета можно определить версию BIND, установленную на pi в домене cipherpunks.com. А также то, что на pi запущена версия BIND, уязвимая для многих атак, одна из которых – переполнение NXT-буфера, известная с 1999 года и позволяющая злоумышленнику получить удаленный доступ к системе с правами программы BIND (обычно выполняющейся с правами привилегированного пользователя root).
   Сервисы преобразования имен зачастую могут сообщать больше информации, чем ожидается. Утилиты типа dig могут выполнять и иные DNS-сервисы, например передачу зоны. DNS использует передачу зоны для распределения записей преобразования имен между остальными хостами. Инициировав вручную передачу зоны, злоумышленник может получить ценную информацию о системах и преобразовании адресов серверами DNS.

   nslookup
   nslookup (Name Service Lookup – служба поиска имен) – полезная утилита, которая свободно распространяется консорциумом программного обеспечения Интернет.
   Принцип работы nslookup почти такой же, как и dig. Пользователю точно так же предоставляется как диалоговый интерфейс, так и интерфейс командной строки. После запуска утилита собирает информацию о хостах с помощью DNS. О доменах nslookup выдает хотя и общедоступную, но очень важную информацию.
   Например, nslookup может использоваться для поиска почтовых доменов или записей типа MX (Mail Exchanger). В результате станут возможными различные атаки на почтовый сервер: посылка спама для достижения отказа в обслуживании, атаки на программное обеспечение с целью получения доступа к серверу или использование почтового сервера для рассылки спама другим хостам, если это разрешено. Посмотрите на следующий пример:

   elliptic@ellipse:~$ nslookup
   Default Server: cobalt.speakeasy.org
   Address: 216.231.41.22
   > set type=MX
   > cipherpunks.com.
   Server: cobalt.speakeasy.org
   Address: 216.231.41.22
   cipherpunks.com preference = 10, mail exchanger = parabola.
   cipherpunks.com
   cipherpunks.com nameserver = DNS1.ENOM.COM
   cipherpunks.com nameserver = DNS2.ENOM.COM
   cipherpunks.com nameserver = DNS3.ENOM.COM
   cipherpunks.com nameserver = DNS4.ENOM.COM
   cipherpunks.com nameserver = DNS5.ENOM.COM
   DNS1.ENOM.COM internet address = 66.150.5.62
   DNS2.ENOM.COM internet address = 63.251.83.36
   DNS3.ENOM.COM internet address = 66.150.5.63
   DNS4.ENOM.COM internet address = 208.254.129.2
   DNS5.ENOM.COM internet address = 210.146.53.77

   Анализируя приведенный пример, можно найти обработчик почты для домена cipherpunks.com. Хост parabola.cipherpunks.com может быть использован для сбора информации. Например, если в системе используется версия программы sendmail, которая позволит злоумышленнику расширить учетные записи пользователя, то он сможет найти адреса электронной почты системного администратора. Из этого можно будет узнать тип транспортного агента, установленного в системе, как это показано в следующем примере:

   elliptic@ellipse:~$ telnet modulus.cipherpunks.com 25
   Trying 192.168.1.253...
   Connected to 192.168.1.253.
   Escape character is “^]”.
   220 modulus.cipherpunks.com ESMTP Server (Microsoft Exchange
   Internet
   Mail Service 5.5.2448.0) ready

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

   Nmap
   Атака, имеющая своей целью получение доступа к хосту, может быть направлена против выполняющихся в системе сервисов. Нередко сервисы уязвимы, и это позволяет злоумышленнику добиться своего. Еще до атаки можно высказать предположение о сервисах, используемых системой для предотвращения сбора информации, и исследовать порты, запустив утилиту netcat, чтобы выяснить возможность подключения через них в службе.
   Сбор сведений о доступных сервисах системы сильно упрощается при использовании такого инструментария, как Network Mapper или Nmap. Как ранее уже упоминалось, Nmap в случае его применения для достижения злонамеренных целей использует многочисленные изощренные методы определения характеристик хоста. К этим возможностям относится переменный режим сканирования TCP-трафика и анализ IP-ответов для определения операционных систем и идентификации прослушиваемых сервисов на хосте.
   Nmap может использоваться для определения общедоступных сервисов сети, а также прослушиваемых сервисов, подвергнувшихся фильтрации такими средствами, как оболочки TCP-трафика, или межсетевыми экранами. Посмотрите на следующий отчет:

   elliptic@ellipse:~$ nmap -sS -O derivative.cipherpunks.com
   Starting nmap V. 2.54BETA22 (www.insecure.org/nmap/)
   Interesting ports on derivative.cipherpunks.com
   (192.168.1.237):
   (The 1533 ports scanned but not shown below are in state: closed)
   Port State Service
   21/tcp open ftp
   22/tcp open ssh
   23/tcp filtered telnet
   25/tcp open smtp
   37/tcp open time
   53/tcp open domain
   80/tcp open http
   110/tcp open pop-3
   143/tcp open imap2
   Remote operating system guess: Solaris 2.6 – 2.7
   Uptime 11.096 days (since Thu Nov 29 08:03:12 2001)
   Nmap run completed – 1 IP address (1 host up) scanned in 60
   seconds

   Давайте одновременно проанализируем эту небольшую часть отчета о сканировании. Во-первых, Nmap был запущен с флагами sS и O. Эти флаги указывают Nmap на необходимость сканирования символов синхронизации SYN на хосте и идентификации операционной системы на основе полученных IP-ответов. Во-вторых, в отчете видны три колонки данных. В крайней слева колонке расположен номер порта и протокол, используемый прослушиваемым сервисом. В средней – состояние порта: подвергнулся ли порт фильтрации, как у порта службы telnet, являющейся оболочкой TCP-трафика, или открыт для общедоступного использования, как остальные.
Индексация Web
   Индексация Web (или, как ее еще обычно называют, спайдеринг (spidering) – движение паука по паутине) – следующий тип сбора информации. С начала 90-х годов компании типа Yahoo! WebCrawler и другие начали использовать автоматизированные программы для посещения Web-сайтов и индексации размещенных на них данных, чтобы впоследствии проиндексированные данные можно было найти с помощью поискового запроса. Это было началом бизнеса Web-порталов.
   Индексация сайтов обычно выполняется различными по форме и названию программами. Их называют роботами, пауками или червяками. Хотя все они выполняют одну и ту же функцию, их безо всякой видимой причины называют по-разному. Эти программы просматривают все связи анализируемого Web-сайта и индексируют находящиеся на них данные. Индексы просмотренных данных помещаются в реляционную базу данных и связываются с поисковой машиной (машина поиска – в сети Internet инструментальные средства, предназначенные для отсеивания информации, не относящейся к теме запроса). Если пользователь во время посещения портала сформулирует поисковый запрос по ключевым словам, то ему будут предъявлены ссылки на проиндексированные Web-страницы, соответствующие его запросу.
   Но что произойдет, если конфиденциальная информация Web-страниц не сохранится с соответствующими правами доступа? Поскольку данные Web-страниц архивированы, то злоумышленник может получить доступ к важной информации о сайте, а значит, он может собирать интересующие его сведения с помощью поисковой машины. Уже упоминалось о том, что эта проблема не нова. Она существовала несколько лет назад, начиная с первых поисковых машин, существует сегодня и, к сожалению, будет существовать завтра.
   Эта проблема не ограничена порталами. Инструментарий типа wget может быть использован для рекурсивного извлечения всех страниц сайта. Для этого достаточно запустить программу с нужными параметрами. Посмотрите на следующий пример:

   elliptic@ellipse:~$ wget -m -x http://www.mrhal.com
   –11:27:35– http://www.mrhal.com:80/
   => “www.mrhal.com/index.html”
   Connecting to www.mrhal.com:80... connected!
   HTTP request sent, awaiting response... 200 OK
   Length: 1,246 [text/html]
   0K -> . [100%]
   11:27:35 (243.36 KB/s) – “www.mrhal.com/index.html” saved
   [1246/1246]
   Loading robots.txt; please ignore errors.
   –11:27:35– http://www.mrhal.com:80/robots.txt
   => “www.mrhal.com/robots.txt”
   Connecting to www.mrhal.com:80... connected!
   HTTP request sent, awaiting response... 404 Not Found
   11:27:35 ERROR 404: Not Found.
   –11:27:35– http://www.mrhal.com:80/pics/hal.jpg
   => “www.mrhal.com/pics/hal.jpg”
   Connecting to www.mrhal.com:80... connected!
   HTTP request sent, awaiting response... 200 OK
   Length: 16,014 [image/jpeg]
   0K -> .......... ..... [100%]
   11:27:35 (1.91 MB/s) – “www.mrhal.com/pics/hal.jpg” saved
   [16014/16014]
   […]
   FINISHED –11:27:42–
   Downloaded: 1,025,502 bytes in 44 files

   В примере вывод команды wget завершен символами […] из-за большого количества файлов (44 файла), загружаемых с Web-сайта www.mrhal.com, которые были бы напечатаны в конце отчета. Команда wget была запущена с переключателями m и x. Переключатель m (переключатель зеркального сохранения информации) включает режим загрузки копии всех файлов сайта www.mrhal.com в соответствии с их ссылками. Переключатель x используется для сохранения структуры директорий сайта при его загрузке на компьютер пользователя.
   Подобный инструментарий позволяет злоумышленнику проиндексировать сайт и создать его зеркальную копию. Впоследствии злоумышленник может воспользоваться стандартными системными утилитами для быстрого анализа скопированных данных. Например, программа grep позволяет быстро найти представляющие для него интерес строки. В первую очередь это относится к строкам «password», «root» и «passwd».

Резюме

   Об атаках, приводящих к отказу в обслуживании (DOS-атаках), говорят в том случае, когда в результате действий злоумышленника ресурс преднамеренно заблокирован или деградирован. Локальные DOS-атаки нацелены на достижение локального отказа в обслуживании и приводят к деградации процесса, исчерпанию дисковой памяти или истощению индексных узлов. DOS-атаки из сети могут начинаться как с сервера, так и с клиентской части (как в одном из вариантов DOS-атаки из сети на Web-браузеры – бомбы JavaScript). DOS-атаки из сети на сервисы используют многочисленные подключения для предотвращения использования сервисов. DOS-атаки на систему похожи на локальные DOS-атаки и основаны на создании потока символов синхронизации SYN для переполнения очереди или использовании атак типа smurf для достижения отказа в обслуживании в результате перенасыщения сетевого трафика. Распределенные DOS-атаки (DDoS-атаки) относятся к классу сетевых атак, нацеленных на систему в целом. Распределенные программы перенасыщения трафика, как, например, tfn и shaft, могут быть использованы для достижения отказа в обслуживании.
   Утечка информации – результат злоупотребления ресурсами. Обычно нападению на систему предшествует утечка информации. В главе рассмотрены пути утечки информации через баннеры оболочки безопасности SSH. Была показана принципиальная возможность «снятия отпечатков пальцев» у ряда служб, например у служб, обеспечивающих работу по протоколам HTTP или FTP. Протокол SNMP – пример протокола, в котором недопустимо мало внимания уделено вопросам безопасности, и поэтому сравнительно легко получить доступ к важной информации в системах, построенных на его основе. Web-сервер легко предоставляет сведения, интересующие злоумышленников, если на него совершено нападение атакой типа точка-точка – слэш (../). Уже упоминалось об инциденте, когда один Интернет-провайдер воспользовался файлами паролей другого провайдера, для того чтобы переманить к себе его клиентов. Тем самым были рассеяны любые мифы о допустимости утечки информации в хорошо сделанной системе, даже если она может маскировать или скрывать свои «отпечатки пальцев».
   При помощи изменения прав доступа к файлу злоумышленник может получить доступ к важной информации, например к именам пользователей и их паролям. Поэтому непонятно, почему зачастую специалисты в области безопасности пренебрегают такой мерой предосторожности, как изменение разрешений доступа к файлу или владельцев файлов, в которых записаны эти разрешения. При рассмотрении подобных вопросов важно различать однопользовательские системы, в которых не предусмотрено управление доступом к файлу, и многопользовательские системы с одним или несколькими уровнями доступа, примерами которых служат списки контроля ACL системы Solaris и ролевой механизм управления доступом (Role-Based Access Control-RBAC). В главе также обсуждались атаки символических связей для перезаписи файлов других пользователей.
   Дезинформация определяется как предоставление противоположной стороне фальшивых данных, провоцирующих противоположную сторону на неадекватное поведение. Стандартные методы дезинформации предусматривают редактирование журналов, использование программных инструментальных средств с правами привилегированного пользователя (rootkits) и модулей ядра. Редактирование журналов – элементарное средство скрытия вторжения. Инструментальные средства типа rootkits позволяют подменять системные программы. Наиболее изощренные методы дезинформации заключаются в подмене модулей ядра, осуществляющих компрометацию системы на нижнем уровне операционной системы: на уровне ее ядра.
   Доступ к специальным файлам / базам данных – еще одно средство получения доступа к системным ресурсам. Ранее обсуждалась возможность использования специальных файлов для получения важной информации, например паролей. База данных – хранилище важной информации о ресурсах системы. Доступ к базе данных может быть получен в результате использования ошибок в обслуживающем их программном обеспечении, например ошибок в Web-интерфейсе или программных ошибок типа переполнения буфера. Ну и конечно, от злоумышленника потребуются определенные усилия, чтобы разобраться с разграничением доступа в базах данных.
   Удаленное выполнение программ – серьезная проблема, позволяющая злоумышленнику взять под свой контроль атакованную систему. Эта угроза легко реализуется в тех случаях, когда в системе не предусмотрена аутентификация. Удаленное выполнение программ осуществляется при помощи автоматизированного инструментария, накладывающего те или иные ограничения на используемые программы.
   О расширении прав говорят в случае, когда неавторизованный пользователь получил доступ к ресурсу, хотя ранее он им не обладал. Были рассмотрены варианты удаленного получения доступа на правах как привилегированного, так и непривилегированного пользователя. В первом случае при помощи демонов HTTP на UNIX-системах, во втором – при помощи таких служб, как демоны SSH. В главе также обсуждались вопросы применения Троянских коней и методов социотехники для получения привилегированного пользовательского доступа к хосту. Отмечалось сходство методов удаленного и локального расширения прав.
   Тестирование уязвимостей – необходимая и обязательная обязанность всякого, кто занимается администрированием систем или обеспечением их безопасности. Доказательство возможности нападения (proof of concept) – один из методов тестирования, который используется для доказательства существования уязвимостей. Другие методы заключаются в применении демонстрирующих проблему программ, автоматизированного инструментария безопасности и контроля версий (versioning) для обнаружения уязвимых версий программного обеспечения.
   Опытный злоумышленник применяет различные методы подготовки атак. Базы данных Whois могут использоваться для сбора разносторонней информации о системе, доменах и сетях. Такие средства DNS, как утилита dig, могут использоваться для сбора информации о хостах и используемом ими программном обеспечении, а nslookup – для идентификации почтовых серверов доменов. В главе кратко освещены вопросы сканирования сети при помощи Nmap. Сканирование сети позволяет выудить сведения о сервисах операционных систем хостов. Наконец, обсуждался спайдеринг для сбора сведений о сайте: его расположении и наличии на нем потенциально важной информации.

Конспект

Обзор классов атак
   · Отказ в обслуживании хоста может быть достигнут в результате локальной или DOS-атаки из сети.
   · Атаке почти всегда предшествует анализ сведений, полученных в результате утечки информации.
   · Незащищенная директория и неверные права доступа к файлу могут позволить локальному злоумышленнику получить доступ к информации, важной для других пользователей.
   · Скомпрометированной системе нельзя доверять ни при каких обстоятельствах до тех пор, пока она не будет восстановлена с безопасного носителя (например, дистрибутива производителя).
   · Атаки на базы данных могут использовать либо бреши программного интерфейса, например Web-интерфейса, либо ошибки программного обеспечения баз данных, например переполнение буфера.
   · Большинство уязвимостей, используемых для удаленного выполнения программ, могут быть в значительной мере обезврежены при помощи ограничения прав доступа, замены корневой директории (change rooting) и недопущения помещения в стек программ (non-executable stack protection).
   · При расширении прав доступа злоумышленник может получить удаленный непривилегированный и привилегированный доступы или локальный привилегированный доступ.
Методы тестирования уязвимостей
   · Тестирование уязвимостей – необходимая часть обеспечения безопасности систем.
   · Доказательство возможности нападения (proof of concept) – лучший метод определения любой уязвимости, поскольку он помогает определить суть уязвимости, место ее нахождения и способ защиты.
   · Применение программ, демонстрирующих уязвимости, – наиболее часто используемый метод доказательства возможности нападения. Подобные программы можно найти в Интернете.
   · Широко используется автоматизированный инструментарий обеспечения безопасности, с помощью которого в большинстве случаев корпоративные группы персонала по безопасности проводят плановый аудит безопасности.
   · Контроль версий позволяет перегруженному работой отделу безопасности оценить опасность со стороны известных уязвимостей и их влияние на работоспособность развернутых систем.
   · Для подготовки атак могут быть использованы сведения из баз данных Whois. А в случае атаки из базы данных Whois можно получить контактную информацию владельца сайта.
   · Информация DNS раскрывает структуру сети.
   · Индексация Web (спайдеринг – spidering) позволяет получать сведения о структуре директорий и важных файлах.

Часто задаваемые вопросы

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

   Вопрос: Где можно дополнительно прочитать о предупреждении DDoS-атак?

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

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

   Вопрос: Где можно достать программы, демонстрирующие уязвимости?
   Ответ: Их можно найти при помощи подробных адресных списков типа Bugtraq (www.securityfocus.com) или в архивах подобных программ PacketStorm (www.packetstormsecurity.org) либо Church of the Swimming Elephant (www.cotse.com).

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

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

Глава 4
Методология

   В этой главе обсуждаются следующие темы:
   • Суть методологии исследования уязвимости
   • Значение экспертизы исходного текста программы
   • Технологии реинжиниринга
   • Тестирование методом «черного ящика»
   · Резюме
   · Конспект
   · Часто задаваемые вопросы

Введение

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

Суть методологии исследования уязвимости

   Поясним простым языком, что понимается под методологией исследования уязвимости. Уязвимость – это нечто, что независимо от того, воспользовался ли ею кто-нибудь или нет, присутствует всюду, будь то микроконтроллер или суперкомпьютер. Исследование – процесс сбора информации, который может как привести, так и не привести к нахождению уязвимости. Методология — это обычно используемые на практике, рекомендуемые или признанные большинством профессионалов приемы и методы исследования уязвимостей.
   Методы исследования уязвимостей по своей сути универсальны. Как домашний энтузиаст безопасности, так и корпоративные аудиторы безопасности в повседневной деятельности применяют одни и те же методы, один и тот же набор инструментальных средств. Диапазон применяемых средств широк: от шестнадцатеричных редакторов до дизассемблеров кода. Методы могут быть как эмпирическими, основанными на счастливой догадке, так и научно обоснованными на основе фундаментальных знаний. Некоторые из этих методов могут показаться хаотичными, в то время как другие – детализированными, строго регламентирующими последовательность выполняемых при исследовании действий. Новичок может предпочесть последние методы, в то время как закаленные исследователи с большим опытом программирования в большей степени полагаются на свою интуицию. Причина выбора тех или иных методов кроется в личном предпочтении исследователя.
   Примечание
   В практике обеспечения безопасности используется ряд схем исследования уязвимостей, которые предусматривают различные методы исследования. Некоторые предпочитают детализированные методичные методы пошагового аудита программ, а другие – методы, в которых последовательность выполняемых действий напоминает «белый шум».
   Выбор субъективен и целиком определяется предпочтениями исследователя. Уже говорилось о широком распространении программных средств определения уязвимостей и аудита программного обеспечения. Некоторые из них по своим возможностям аналогичны Web CGI или SQL Database. Другие, как, например, Bugzilla, предоставляют ряд дополнительных возможностей, включая прекрасный интерфейс, ведение учетных записей пользователя, идентификаторов ошибок и их отслеживание.
   Следует сказать, что для анализа различных типов данных требуются разные методы исследования. Для анализа двоичных данных требуется совершенно иной подход, чем для анализа исходного текста программы. Поэтому рассмотрим эти два подхода отдельно друг от друга.

Анализ исходного текста программы

Поиск подверженных ошибкам функций
   Аудит исходного текста программы осуществляется различными способами. Прежде всего это поиск потенциально небезопасных функций при помощи различных утилит поиска, например grep.
   Следует обратить внимание на использование функций языка C strcpy и sprintf. Злоумышленник часто их применяет, пытаясь добиться переполнения буфера из-за отсутствия или неверного выполнения проверки принадлежности адресов диапазону правильных адресов памяти. Использование других функций, как, например, mktemp, может привести к перезаписи файлов в результате конкуренции программ, содержащих функцию, или к повышению привилегий.
Построчная экспертиза исходного текста
   Один из методов анализа исходного теста программы – построчная экспертиза программы в соответствии с алгоритмом ее выполнения. Это более тщательное изучение программы, на которое уходит больше времени.
   Согласно этому методу от исследователя требуется просмотреть исходный текст программы в соответствии с гипотетической последовательностью ее выполнения. Гипотетическая последовательность выполнения отражает различные условия выполнения программы, определяемые ее входными данными. Ход выполнения программы визуально прослеживается исследователем, мысленно отслеживающим обработку данных различными функциями по мере их вызова программой.
Анализ различий
   Анализ различий – метод определения уязвимостей программы, который применяется, если производитель сообщил об уязвимости, не детализируя ее сути. С помощью этого метода определяется, был ли изменен файл программы, a если был, то где именно.
   diff – одна из лучших утилит, реализующая рассматриваемый метод. Она поставляется с большинством версий операционных систем UNIX и благодаря Фонду свободно распространяемого программого обеспечения (Free Software Foundation) реализована на многих платформах. diff сравнивает две копии данных и отображает любые различия между ними, то есть она позволяет найти различия в двух исходных файлах программ и их местонахождение.
   Обычно метод различий применяется для уточнения сути и последствий уязвимости, о которой производитель опубликовал какие-либо детали. Например, в оперативных сообщениях об обновлении программного обеспечения часто содержатся неопределенные детали обновления программ, которые могут оказать влияние на их безопасность, как это было продемонстрировано последним сообщением об обновлении программы axspawn.
   Про патч уязвимости было заявлено, что он исправляет возможную ошибку переполнения буфера. При этом ни слова не было сказано о каких-либо подробностях. Детали прояснились после сравнения версий 0.2.1 и 0.2.1a программы при помощи утилиты diff:

   elliptic@ellipse:~$ diff axspawn-0.2.1/axspawn.c axspawn-
   0.2.1a/axspawn.c
   491c491
   < envc = 0;
   –
   > envc = 0;
   493c493
   < sprintf(envp[envc++], “AXCALL=%s”, call);
   –
   > sprintf(envp[envc++], “AXCALL=%.22s”, call);
   495c495
   < sprintf(envp[envc++], “CALL=%s”, (char *)user);
   –
   > sprintf(envp[envc++], “CALL=%.24s”, (char
   *)user); 497c497
   < sprintf(envp[envc++], “PROTOCOL=%s”, protocol);
   –
   > sprintf(envp[envc++], “PROTOCOL=%.20s”,
   protocol); 500c500
   < envp[envc] = NULL;
   –
   > envp[envc] = NULL;

   Видно, что в первой версии программы axspawn.c используется функция sprintf без всяких ограничений на длину выводимой строки данных, а во второй – введено ограничение на длину выводимой строки в спецификации преобразования.
   В некоторых случаях производитель может выпустить патч, который будет сообщать отличия между двумя версиями программы. Обычно такие патчи выпускаются для операционных систем типа BSD (BSD – Berkeley Software Design Incorporated – компания-разработчик программного обеспечения), например FreeBSD. В январе 2002 года была найдена уязвимость в пакете инструментальных средств операционной системы FreeBSD. До ее устранения пользователь мог извлечь данные во временную директорию и изменить их. До тех пор, пока уязвимость не была всесторонне изучена, патч pkg_add сообщал точное местонахождение уязвимости:

   – usr.sbin/pkg_install/lib/pen.c 17 May 2001 12:33:39 -0000
   +++ usr.sbin/pkg_install/lib/pen.c 7 Dec 2001 20:58:46 -0000
   @@ -106,7 +106,7 @@
   cleanup(0);
   errx(2, __FUNCTION__ “: can’t mktemp “%s””, pen);
   }
   – if (chmod(pen, 0755) == FAIL) {
   + if (chmod(pen, 0700) == FAIL) {
   cleanup(0);
   errx(2, __FUNCTION__ “: can’t mkdir “%s””, pen);
   }

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

Анализ двоичного кода

   Первое, что приходит на ум при исследовании уязвимостей, – аудит исходного текста программы. Тем не менее в большинстве случаев анализ двоичного кода – единственно возможный метод поиска уязвимостей. Благодаря появлению движения за открытые исходные тексты программ и проекта создания свободно распространяемого программного обеспечения GNU License получить исходные тексты программ стало намного проще. Но не все производители поддержали открытый обмен исходными текстами. К тому же большая часть программного обеспечения по-прежнему поставляется без исходных текстов.
Трассировка двоичного кода
   Один из методов определения потенциальных уязвимостей заключается в трассировке выполнения программы. Для трассировки используется различный инструментарий. Для этой цели в системе Solaris применяется специальный пакет программ truss компании Sun. В других операционных системах используются аналогичные программы, например strace для Linux.
   Трассировка выполнения программы позволяет наблюдать за ее взаимодействием с операционной системой. Используемые программой переменные окружения могут быть исследованы в соответствии с режимами ее работы. Дополнительно при трассировке программы можно просмотреть используемые программой адреса памяти и получить другую полезную информацию о возможных проблемах в каких-либо частях программы.
   Использование трассировки позволяет определить, где и когда проявится уязвимость в исследуемой программе.
Отладчики
   Применение отладчиков – еще один способ поиска уязвимостей. Отладчики позволяют выявить ошибки программы во время ее выполнения. На практике применяются различные отладчики. Gnu Debugger (GDB) – один из наиболее известных среди них.
   Отладчики могут управлять работой программы во время ее выполнения. С помощью отладчика может быть выполнена как вся программа целиком, так и ее часть. Отладчик может отображать содержимое регистров, память по указанным адресам и другую полезную для поиска уязвимостей информацию.
Аудит документации
   Другой способ аудита двоичного кода заключается в анализе принятых соглашений и документов по разработке программ (которые не следует путать с исходным кодом программ). Материалы по разработке программ обычно представляются в виде диаграмм, информационных листов или спецификаций, как, например, RFC (Requests for Comments – запросы на комментарии, серия документов IETF, первые упоминания о которой относятся к 1969 году. Документы этой серии содержат описания протоколов Internet и связанную с ними информацию).
   Анализ программ на основе протокола спецификации может привести к различным выводам. Этот тип исследования заключается не только в установлении соответствия анализируемой программы спецификациям проектирования, но и в детальном анализе проблемных ситуаций в ней. Воспользовавшись результатами исследования основополагающих принципов построения протокола, например Telnet или POP3, можно протестировать службу, написанную на основе выбранного протокола, на предмет ее соответствия протоколу. Рассматривая ранее изученные классы атак на выбранные части реализации протокола (атаки, нацеленные на переполнение буфера или ошибки форматирующей строки), можно написать программу, демонстрирующую найденную уязвимость.
Анализаторы
   Последний, заслуживающий внимания метод поиска уязвимостей – это применение анализаторов. Анализаторы – это инструмент исследования уязвимостей, который применяется как средство поиска неисправностей или для отладки. Другими словами, анализаторы – это модули проверки текущего состояния программы. К сожалению, цели применения анализаторов могут быть разными.
   Анализаторы могут применяться для контроля взаимодействия между системой и ее пользователями. С их помощью можно графически отображать происходящие в работе программы события, например генерацию последовательности чисел. Они также позволяют контролировать работу программ общего шлюзового интерфейса, определять предназначение программ CGI и даже собирать информацию о критических ошибках проектирования этих программ.
   Анализаторы применяются совместно с ранее упомянутым аудитом документации проектирования. С их помощью проводятся исследования Web-интерфейсов или других сетевых протоколов, которые хотя и не являются общепризнанными стандартами, но широко используются.

Значение экспертизы исходного текста программы

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

Поиск функций, подверженных ошибкам

   Рассмотрим несколько простых примеров уязвимостей, которые могут быть найдены в исходном тексте программы в результате поиска функций, подверженных ошибкам.
Переполнение буфера
   Переполнение буфера, известное также как ошибка граничных условий, происходит в том случае, когда размер записываемых в память данных превышает размер выделенной для этого области памяти. Елиас Леви (Elias Levy), известный как Alephl, написал на эту тему статью «Smashing the Stack for Fun and Profit» («Разрушение стека для забавы и обогащения»). Со статьей можно ознакомиться в 49-ом выпуске Phrack, статья номер 14.
   Посмотрите на следующую программу:

   /* scpybufo.c */
   /* Hal Flynn <mrhal@mrhal.com> */
   /* December 31, 2001 */
   /* scpybufo.c demonstrates the problem */
   /* with the strcpy() function which */
   /* is part of the c library. This */
   /* program demonstrates strcpy not */
   /* sufficiently checking input. When */
   /* executed with an 8 byte argument, a */
   /* buffer overflow occurs. */
   #include <stdio.h>
   #include <strings.h>
   int main(int argc, char *argv[])
   {
   overflow_function(*++argv);
   return (0);
   }
   void overflow_function(char *b)
   {
   char c[8];
   strcpy(c, b);
   return;
   }

   В этой написанной на языке C программе приведен пример использования функции strcpy. Данные из массива argv [1], в котором хранится аргумент вызова программы, копируются функцией strcpy в массив символов, для которого при объявлении была выделена память для восьми символов. Поскольку в программе не выполняется никаких проверок размера пересылаемых данных, то при копировании более восьми символов происходит переполнение буфера.
   Функция sprintf — еще один пример часто встречающейся подверженной ошибкам функции. В результате ее применения возможно переполнение буфера, как это показано в следующем примере:

   /* sprbufo.c */
   /* Hal Flynn <mrhal@mrhal.com> */
   /* December 31, 2001 */
   /* sprbufo.c demonstrates the problem */
   /* with the sprintf() function which */
   /* is part of the c library. This */
   /* program demonstrates sprintf not */
   /* sufficiently checking input. When */
   /* executed with an argument of 8 bytes */
   /* or more a buffer overflow occurs. */
   #include <stdio.h>
   int main(int argc, char *argv[])
   {
   overflow_function(*++argv);
   return (0);
   }
   void overflow_function(char *b)
   {
   char c[8];
   sprintf(c, “%s”, b);
   return;
   }

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

   /* scatbufo.c */
   /* Hal Flynn <mrhal@mrhal.com> */
   /* December 31, 2001 */
   /* scatbufo.c demonstrates the problem */
   /* with the strcat() function which */
   /* is part of the c library. This */
   /* program demonstrates strcat not */
   /* sufficiently checking input. When */
   /* executed with a 7 byte argument, a */
   /* buffer overflow occurs. */
   #include <stdio.h>
   #include <strings.h>
   int main(int argc, char *argv[])
   {
   overflow_function(*++argv);
   return (0);
   }
   void overflow_function(char *b)
   {
   char c[8] = «0»;
   strcat(c, b);
   return;
   }

   Данные командной строки из массива argv [1] передаются функции overflow_function, которая сцепляет их с данными восьмибайтового массива символов с. Поскольку в программе размер сцепляемых данных не проверяется, то в результате возможен выход за границы массива c.
   Gets – еще одна проблематичная функция языка C. Компилятор GNU языка C выдает предупреждающее сообщение при компиляции программ с функцией gets, потому что эта функция никак не контролирует размер получаемых данных. Посмотрите на следующий пример:

   /* getsbufo.c */
   /* Hal Flynn <mrhal@mrhal.com> */
   /* December 31, 2001 */
   /* This program demonstrates how NOT */
   /* to use the gets() function. gets() */
   /* does not sufficient check input */
   /* length, and can result in serious */
   /* problems such as buffer overflows. */
   #include <stdio.h>
   int main()
   {
   get_input();
   return (0);
   }
   void get_input(void)
   {
   char c[8];
   printf(“Enter a string greater than seven bytes: ”);
   gets(c);
   return;
   }

   В исходном тексте программы можно найти функцию gets. В результате выполнения функции gets данные входного потока пересылаются в восьмибайтовый массив символов c. Но поскольку эта функция не выполняет никаких проверок на размер обрабатываемых данных, то в результате легко получить ошибку переполнения буфера.
   Подробнее с проблемой переполнения буфера можно познакомиться в главе 8.
Ошибки проверки входных данных
   Причина других типичных ошибок программирования кроется в недостаточной проверке входных данных программы. В результате уязвимость программы может проявиться при передаче ей различных типов данных, как, например, это происходит с программами Web CGI.
   Ошибки проверки входных данных программы могут привести к уязвимостям форматирующей строки. Уязвимость форматирующей строки проявляется при использовании в программе таких спецификаций преобразования, как, например, %i%i%i%i или %n%n%n%, что может привести к неожиданному результату. Подробно форматирующие строки рассмотрены в главе 9.
   Но перед этим приведем пример программы с уязвимой форматирующей строкой. Проанализируйте следующую программу:

   /* fmtstr.c */
   /* Hal Flynn <mrhal@mrhal.com> */
   /* December 31, 2001 */
   /* fmtstr.c demonstrates a format */
   /* string vulnerability. By supplying */
   /* format specifiers as arguments, */
   /* attackers may read or write to */
   /* memory. */
   #include <stdio.h>
   int main(int argc, char *argv[])
   {
   printf(*++argv);
   return (0);
   }

   В результате запуска программы и передачи ей на вход форматирующей строки со спецификацией преобразования %n пользователь сможет распечатать содержимое произвольных областей памяти. При распечатке соответствующей области памяти можно запустить программу с привилегиями привилегированного пользователя root.
   Проверка программами Web-интерфейса, например CGI-программами, входных данных программы часто приводит к неожиданным результатам. Нередко недостаточно квалифицированно написанные CGI-программы (особенно это касается программ, написанных на языке Perl) позволяют выполнять команды, заключенные в специальные символы, что дает возможность выполнять произвольные команды системы с привилегиями Web-пользователя. В некоторых случаях это может привести к серьезным последствиям. Например, к удалению файла index.html, если HTTP-процесс является владельцем этого файла и имеет право писать в него данные. Или к предоставлению пользователю локального доступа к системе с разрешениями HTTP-процесса, если пользователь свяжет оболочку shell c произвольным портом системы.
   К сходным проблемам может привести предоставленная пользователю возможность выполнять произвольные SQL-команды. Обычно CGI-программы используются для облегчения взаимодействия между внешним Web-интерфейсом и серверной частью системы управления базами данных, поддерживающих SQL, например Oracle, MySQL или Microsoft SQL Server. Пользователь, который может выполнять произвольные SQL-команды, сможет просматривать произвольные таблицы, обрабатывать данные таблиц и даже удалять их.
   Посмотрите на вариант вызова функции open:

   #!/usr/bin/perl
   open(“ls $ARGV[0] |”);

   Эта функция не проверяет входные данные, переданные программе в $argv [0]. Добавив к входным данным символы точек (..), становится возможным сменить директорию и просмотреть родительский каталог, в котором может храниться важная информация. Более подробное обсуждение ошибок проверки входных данных приведено в главе 7.
Соперничество программ за ресурсы
   При соперничестве программ за ресурсы часто встречается программная ошибка, получившая название «состояние гонок» (Race Conditions). Проявляется состояние гонок различным образом, например в виде блокирования одним процессом разделяемой области памяти, не позволяя тем самым другому процессу изменить в ней данные, или в виде ошибок одновременной работы нескольких процессов с одним и тем же файлом.
   Изучим пример использования функции mktemp, которая часто является источником подобных ошибок:

   /* mtmprace.c */
   /* Hal Flynn <mrhal@mrhal.com> */
   /* mtmprace.c creates a file in the */
   /* temporary directory that can be */
   /* easily guessed, and exploited */
   /* through a symbolic link attack. */
   #include <stdio.h>
   #include <stdlib.h>
   int main()
   {
   char *example;
   char *outfile;
   char ex[] = “/tmp/exampleXXXXXX”;
   example = ex;
   mktemp(example);
   outfile = fopen(example, “w”);
   return (0);
   }

   В некоторых операционных системах эта программа создает файл во временной директории с предопределенным именем, состоящим из строки символов, в которую входят слово example, пять символов идентификатора процесса и одна буква латинского алфавита. Первый недостаток рассматриваемой программы заключается в том, что между проверкой существования файла и его созданием может возникнуть ошибка «состояние гонок» (Race Conditions), обусловленная соперничеством программ за ресурсы. Второй – в том, что имя файла можно сравнительно легко предсказать, поскольку идентификатор процесса можно определить, а последний символ – это одна из 26 букв английского алфавита. В результате возможна успешная для злоумышленника атака символических связей. Для того чтобы определить, позволяет ли операционная система воспользоваться указанными уязвимостями, достаточно исследовать файлы, созданные программой в директории /tmp.
   При помощи такой утилиты, как grep, можно исследовать большие программные файлы на наличие в них известных ошибок. Означает ли это, что будут выявлены все уязвимости? К сожалению, нет, но это позволит найти и устранить большинство часто встречающихся ошибок. Единственно надежный способ обеспечения безопасности программного обеспечения – построчный аудит многочисленными независимыми экспертами. И даже после этого уровень безопасности программного обеспечения может быть оценен только как достаточно высокий, без гарантий полной безопасности.

Технологии реинжиниринга

   Технологии реинжиниринга в большинстве случаев позволяют с большой точностью определить уязвимости в программе с недоступными исходными текстами. Для реинжиниринга программ существует различный инструментарий, выбор которого определяется используемой операционной системой и предпочтениями исследователя. Но независимо от этого чаще всего применяются одни и те же способы реинжиниринга.
   Обычно наиболее целесообразна методика работы «сверху вниз», предполагающая сначала рассмотрение общих случаев, а затем, по мере необходимости, их детализацию. В большинстве случаев это означает первоначальное применение средств мониторинга операционной системы для определения файлов и ресурсов, к которым обращается исследуемая программа. (Исключение из этого правила составляют сетевые программы. При исследовании сетевых программ чаще всего требуется перейти к анализу передаваемых по сети пакетов.)
   В составе операционных систем Windows подобный инструментарий не поставляется, поэтому используют программные средства других производителей. До настоящего времени главным их источником для Windows был сайт SysInternals по адресу www.sysinternals.com в Интернете. Особенно интересны программы FileMon, RegMon, а в случае NT – HandleEx. Подробнее о них будет рассказано в главе 5. Все, что вам необходимо знать об этих средствах сейчас, – это то, что они позволяют контролировать выполняющуюся программу (или программы), узнать, к каким файлам обращается контролируемая исследователем программа, читает ли она их или пишет в них информацию и куда именно, какие другие файлы она ищет. Перечисленные функции реализованы в программе FileMon. Программа RegMon позволяет исследовать то же самое применительно к реестру Windows NT: к каким ключам реестра программа обращается, какие ключи читает, обновляет, ищет и т. д. HandleEx реализует те же самые функции, но несколько другим способом. Результаты ее работы упорядочены по процессам, дескрипторам файлов и тем объектам, на которые указывают дескрипторы файлов.
   В качестве дополнительной услуги доступны свободно распространяемые версии почти всех инструментальных средств SysInternals, причем большинство из них с исходными текстами программ. (Помимо сайта SysInternals, на родственном сайте Winternals.com продаются аналогичные коммерческие инструментальные средства с несколько большими возможностями.) Для пользователя UNIX в этом нет ничего необычного, но для пользователя Windows это приятная неожиданность.
   В состав большинства дистрибутивов UNIX включены программные средства, которые могут облегчить анализ VB-программ. В списке Rosetta Stone перечислено много программ трассировки. Список можно найти по адресу http://bhami.com/rosetta.html в Интернете. Любая программа трассировки реализует низкоуровневые функции, поэтому она может работать только под управлением ограниченного количества операционных систем. Примерами программ трассировки могут служить программы trace, strace, ktrace и truss, а также утилита strace, выполняемая в операционной системе Red Hat Linux, версия 6.2. Утилита (как и большинство ранее упомянутых программ трассировки) позволяет исследовать системные обращения (обращения к ядру операционной системы) и их параметры, что позволяет многое узнать о работе программы.
Приоткрывая завесу
   Декомпиляторы VB
   Изрядное количество программ во всем мире написано на Visual Basic (VB). Сюда относятся как зловредные программы, так и программы законопослушных программистов. VB бросает вызов всякому, кто отважится декомпилировать программу, написанную на этом языке. Последний свободно доступный декомпилятор мог работать только с программами VB3. Начиная с VB5, результат компиляции программы может быть представлен как во внутреннем коде исполняемого модуля («native code»), реализующем стандартное обращение к Windows, так и в p-code. P-код – это псевдокод, который похож на байт-код (или машинно-независимый код), генерируемый Java-компилятором. P-код распознает интерпретатор реального времени Visual Basic VBRUN300.DLL, VBRUN500.DLL или VBRUN600.DLL. Сложность заключается в том, что очень мало доступной документации, в которой описано соответствие конструкций исходного текста программы функциям VB в откомпилированной программе. Конечно, всегда можно декомпилировать интерпретатор VB DLL и восстановить соответствие, но это очень трудоемкое занятие.
   Вместо этого опытные хакеры воспользовались бы средствами отладки. Конечно, они мысленно преследуют совсем другие цели. В основном их интересует, как взломать защиту от копирования. Поэтому напрямую их навыки не всегда могут пригодиться для декомпиляции программ, написанных на VB. В большинстве известных работ в этой области используется пошаговое выполнение программы для обнаружения места, где проверяется, например, серийный номер. Затем ищутся пути отключения проверки. Тем самым хакеры стремятся заблокировать выполнение нужного им участка программы. Несмотря на это, изучение способов работы хакеров позволяет начать квалифицированную работу по анализу программ, написанных на VB.
   Для удобства восприятия протокол трассировки дополнен комментариями:

   [elliptic@ellipse]$ echo hello > test
   [elliptic@ellipse]$ strace cat test
   execve(“/bin/cat”, [“cat”, “test”], [/* 21 vars */]) = 0

   Утилита strace не начинает вывод до тех пор, пока не будет вызвана команда cat. Поэтому нельзя отследить процесс ее поиска командным процессором shell. К моменту начала работы утилиты strace команда cat находилась в директории /bin. Из примера трассировки видно, что входными параметрами программы execve являются местонахождение cat, ее имя, аргумент (test) и список из 21 переменной окружения.

   brk(0) = 0x804b160
   old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
   MAP_PRIVATE|MAP_ANONYMOUS, – 1, 0) = 0x40014000
   open(“/etc/ld.so.preload”, O_RDONLY) = -1 ENOENT (No
   such file or directory)

   После вызова execve начинается обычный процесс загрузки: распределение памяти и т. д. Отметим свидетельствующий об ошибке код возврата, равный —1, при попытке открыть /etc/ld.so.preload. Ошибка поясняется диагностическим сообщением об отсутствии файла или директории. Действительно, такого файла нет. Из примера ясно, что если вместо файла указать параметры так, как это указано в примере open, execve самостоятельно найдет файл. Это было бы полезно для последующих действий привилегированного пользователя. Но для этого нужно поместить новый файл в директорию /etc, в которой запрещено что-либо делать до тех пор, пока кто-нибудь не откорректирует файл системных разрешений. В большинстве Unix-систем право записи в директорию /etc имеет только пользователь, получивший привилегированные права «root» тем или иным способом. Это еще одна причина, по которой обычные пользователи не могут писать в /etc. Если задаться целью спрятать Троянского коня, то лучшего места не найти (после того как будут получены права привилегированного пользователя root).

   open(“/etc/ld.so.cache”, O_RDONLY) = 4
   fstat(4, {st_mode=S_IFREG|0644, st_size=12431, ...}) = 0
   old_mmap(NULL, 12431, PROT_READ, MAP_PRIVATE, 4, 0) =
   0x40015000
   close(4) = 0
   open(“/lib/libc.so.6”, O_RDONLY) = 4
   fstat(4, {st_mode=S_IFREG|0755, st_size=4101324, ...}) = 0
   read(4,
   “7ELF02”...,
   4096) = 4096

   Прочитаны первые 4 Кб библиотеки libc. Libc – это стандартная библиотека коллективного доступа, в которой расположены функции, вызываемые из программ на языке C (такие как printf, scanf и т. д.).

   old_mmap(NULL, 1001564, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4,
   0) = 0x40019000
   mprotect(0x40106000, 30812, PROT_NONE) = 0
   old_mmap(0x40106000, 16384, PROT_READ|PROT_WRITE,
   MAP_PRIVATE|MAP_FIXED, 4, 0xec000) = 0x40106000
   old_mmap(0x4010a000, 14428, PROT_READ|PROT_WRITE,
   MAP_PRIVATE|MAP_FIXED| MAP_ANONYMOUS, -1, 0)
   = 0x4010a000
   close(4) = 0
   mprotect(0x40019000, 970752, PROT_READ|PROT_WRITE) = 0
   mprotect(0x40019000, 970752, PROT_READ|PROT_EXEC) = 0
   munmap(0x40015000, 12431) = 0
   personality(PER_LINUX) = 0
   getpid() = 9271
   brk(0) = 0x804b160
   brk(0x804b198) = 0x804b198
   brk(0x804c000) = 0x804c000
   open(“/usr/share/locale/locale.alias”, O_RDONLY) = 4
   fstat64(0x4, 0xbfffb79c) = -1 ENOSYS (Function not
   implemented)
   fstat(4, {st_mode=S_IFREG|0644, st_size=2265, ...}) = 0
   old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
   MAP_PRIVATE|MAP_ANONYMOUS, – 1, 0) = 0x40015000
   read(4, “# Locale name alias data base.\n#”..., 4096) = 2265
   read(4, “”, 4096) = 0
   close(4) = 0
   munmap(0x40015000, 4096) = 0

   Если в программе встречается вызов функции setlocale, то libc читает локализованную информацию (информацию о местной специфике) для определения формата отображения чисел, даты, времени и т. д. Напомним, что хотя стандартные разрешения не позволяют модифицировать файлы локализации непривилегированным пользователям, но их достаточно для чтения этих файлов. Добавим, что разрешения файлов обычно печатаются при выводе информации о каждом вызове fstat (например, в приведенном примере 0644). Это позволяет легко визуально отследить неверные разрешения. Если ищется файл локализации, в который предполагается записать информацию, будьте осторожны, чтобы при записи не получить ошибки переполнения буфера. Третий (косвенный) параметр в списке входных параметров – файлы локализации.

   open(“/usr/share/i18n/locale.alias”, O_RDONLY) = -1 ENOENT
   (No such file or directory)
   open(“/usr/share/locale/en_US/LC_MESSAGES”, O_RDONLY) = 4
   fstat(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
   close(4) = 0
   open(“/usr/share/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES”,
   O_RDONLY) = 4
   fstat(4, {st_mode=S_IFREG|0644, st_size=44, ...}) = 0
   old_mmap(NULL, 44, PROT_READ, MAP_PRIVATE, 4, 0)
   = 0x40015000
   close(4) = 0
   open(“/usr/share/locale/en_US/LC_MONETARY”, O_RDONLY) = 4
   fstat(4, {st_mode=S_IFREG|0644, st_size=93, ...}) = 0
   old_mmap(NULL, 93, PROT_READ, MAP_PRIVATE, 4, 0)
   = 0x40016000
   close(4) = 0
   open(“/usr/share/locale/en_US/LC_COLLATE”, O_RDONLY) = 4
   fstat(4, {st_mode=S_IFREG|0644, st_size=29970, ...}) = 0
   old_mmap(NULL, 29970, PROT_READ, MAP_PRIVATE, 4, 0)
   = 0x4010e000
   close(4) = 0
   brk(0x804d000) = 0x804d000
   open(“/usr/share/locale/en_US/LC_TIME”, O_RDONLY) = 4
   fstat(4, {st_mode=S_IFREG|0644, st_size=508, ...}) = 0
   old_mmap(NULL, 508, PROT_READ, MAP_PRIVATE, 4, 0)
   = 0x40017000
   close(4) = 0
   open(“/usr/share/locale/en_US/LC_NUMERIC”, O_RDONLY) = 4
   fstat(4, {st_mode=S_IFREG|0644, st_size=27, ...}) = 0
   old_mmap(NULL, 27, PROT_READ, MAP_PRIVATE, 4, 0)
   = 0x40018000
   close(4) = 0
   open(“/usr/share/locale/en_US/LC_CTYPE”, O_RDONLY) = 4
   fstat(4, {st_mode=S_IFREG|0644, st_size=87756, ...}) = 0
   old_mmap(NULL, 87756, PROT_READ, MAP_PRIVATE, 4, 0)
   = 0x40116000
   close(4) = 0
   fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 4),
   ...}) = 0
   open(“test”, O_RDONLY|O_LARGEFILE) = 4
   fstat(4, {st_mode=S_IFREG|0664, st_size=6, ...}) = 0

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

   read(4, “hello\n”, 512) = 6
   write(1, “hello\n”, 6) = 6
   read(4, “”, 512) = 0
   close(4) = 0
   close(1) = 0
   _exit(0) = ?

   В заключение cat пытается прочитать 512 байтов из файла (читает 6) и выводит их на экран (который описан STDOUT с дескриптором файла 1). При повторной попытке прочитать очередные 512 байтов файла читается 0 байт, что свидетельствует о достижении конца файла. В результате файл закрывается, дескриптор файла освобождается и выполняется нормальный выход (признаком нормального выхода является нулевой код завершения).
   Для демонстрации читателю представляем очень простой пример. Логика работы команды cat очень проста и легко восстанавливается. На псевдокоде команду cat можно записать следующим образом:

   int count, handle
   string contents
   handle = open (argv[1])
   while (count = read (handle, contents, 512))
   write (STDOUT, contents, count)
   exit (0)

   Для сравнения приведем результат выполнения утилиты truss для той же самой команды, выполненной в системе Solaris 7 на машине (x86):

   execve(“/usr/bin/cat”, 0x08047E50, 0x08047E5C) argc = 2
   open(“/dev/zero”, O_RDONLY) = 3
   mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
   MAP_PRIVATE, 3, 0) = 0xDFBE1000
   xstat(2, “/usr/bin/cat”, 0x08047BCC) = 0
   sysconfig(_CONFIG_PAGESIZE) = 4096
   open(“/usr/lib/libc.so.1”, O_RDONLY) = 4
   fxstat(2, 4, 0x08047A0C) = 0
   mmap(0x00000000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4,
   0) = 0xDFBDF000
   mmap(0x00000000, 598016, PROT_READ|PROT_EXEC, MAP_PRIVATE,
   4, 0) = 0xDFB4C000
   mmap(0xDFBD6000, 24392, PROT_READ|PROT_WRITE|PROT_EXEC,
   MAP_PRIVATE|MAP_FIXED, 4, 561152) = 0xDFBD6000
   mmap(0xDFBDC000, 6356, PROT_READ|PROT_WRITE|PROT_EXEC,
   MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xDFBDC000
   close(4) = 0
   open(“/usr/lib/libdl.so.1”, O_RDONLY) = 4
   fxstat(2, 4, 0x08047A0C) = 0
   mmap(0xDFBDF000, 4096, PROT_READ|PROT_EXEC,
   MAP_PRIVATE|MAP_FIXED, 4, 0) = 0xDFBDF000
   close(4) = 0
   close(3) = 0
   sysi86(SI86FPHW, 0xDFBDD8C0, 0x08047E0C, 0xDFBFCEA0)
   = 0x00000000
   fstat64(1, 0x08047D80) = 0
   open64(“test”, O_RDONLY) = 3
   fstat64(3, 0x08047CF0) = 0
   llseek(3, 0, SEEK_CUR) = 0
   mmap64(0x00000000, 6, PROT_READ, MAP_SHARED, 3, 0)
   = 0xDFB4A000
   read(3, “ h”, 1) = 1
   memcntl(0xDFB4A000, 6, MC_ADVISE, 0x0002, 0, 0) = 0
   write(1, “ h e l l o\n”, 6) = 6
   llseek(3, 6, SEEK_SET) = 6
   munmap(0xDFB4A000, 6) = 0
   llseek(3, 0, SEEK_CUR) = 6
   close(3) = 0
   close(1) = 0
   llseek(0, 0, SEEK_CUR) = 296569
   _exit(0)

   Проанализировав конец протокола, можно заметить, что в Solaris команда cat выполняется несколько по-другому. Различие проявляется в том, что в Solaris ош использует проецируемый в память файл для передачи диапазона адресов непосредственно вызову функции write. Эксперимент с большим файлом (результаты которого здесь не приведены) выявил цикл запросов между вызовами функций memorymap/write, причем за один раз обрабатывается 256 Кб.
   Приведенная трассировка не раскрывает правил использования инструментария трассировки (хотя с этим и стоило бы познакомиться, но для этого потребовалось написать бы несколько глав). Скорее всего, приведенный пример демонстрирует некоторые факты, с помощью которых можно выяснить логику работы операционных систем в этой ситуации.
   Для углубления своих представлений об используемом инструментарии следует рассмотреть случаи применения файлов с предсказуемыми именами в директории временной памяти /tmp, чтения информации из файлов, доступных всем для записи, различных вариантов вызова функций и т. д.

Дизассемблеры, декомпиляторы и отладчики

   Подготовка к анализу загрузочного файла – тема отдельного разговора. Отладчики – это программные средства, предназначенные для контроля выполнения программ. Отладчики позволяют приостановить выполнение программы в некоторой точке, изменить значение переменных и даже, в некоторых случаях, внести изменения в машинный код программы на лету в процессе ее выполнения. К сожалению, возможность выполнения отладчиком подобных действий зависит от включения в выполнимый код отладочной информации, прежде всего таблицы соответствия символов (для большинства загрузочных программ это не выполняется). Если отладочной информации в выполнимом коде нет, то отладчик может выполнить некоторые функции, хотя большую часть работы по отладке программ приходится выполнять вручную, например при указании точек прерывания вместо имен приходится задавать адреса памяти.
   Декомпилятор (или дизассемблер) – программа, которая преобразует двоичный код программ в исходный текст, написанный на одном из языков программирования, чаще всего – ассемблере. Некоторые дизассемблеры могут представить исходный текст на простом языке C. В процессе трансляции большая часть информации об исходном тексте программы теряется, например имена переменных, поэтому декомпилятор пытается восстановить исходный текст программы настолько, насколько это возможно. Если при декомпиляции таблица соответствия имен была не найдена, то зачастую декомпилятор присваивает переменным имена, составленные из плохо воспринимаемой последовательности цифр и букв.
   Проблема несколько упрощается, если исследователь в состоянии разобраться с ассемблерным кодом, генерируемым декомпилятором. В этом случае декомпилятор особенно полезен. Рассмотрим пример результатов работы декомпилятора.
   Среди коммерческих декомпиляторов для Windows хорошая репутация у IDA Pro компании DataRescue (пример работы декомпилятора показан на рис. 4.1). IDA Pro может декомпилировать программный код многих процессоров, включая виртуальную машину Java.
   Рис. 4.1. Пример работы IDA Pro

   На рисунке показан пример применения декомпилятора IDA Pro для дизассемблирования программы pbrush.exe (Paintbrush). IDA Pro нашел секцию внешних функций, используемых программой pbrush.exe. Если программа выполняется под управлением операционной системы, которая поддерживает разделяемые библиотеки (например, под управлением операционных систем Windows или UNIX), то она содержит список необходимых ей библиотек. Обычно этот список представлен в удобочитаемом виде, который легко обнаружить при экспертизе выполняемого кода. Для выполнения программ операционной системе также требуется этот список, поэтому она загружает его в память. В большинстве случаев это позволяет декомпилятору вставить список в двоичный код программы, сделав его более понятным.
   Чаще всего таблица соответствия имен pbrush.exe недоступна, поэтому в большей части сгенерированного декомпилятором ассемблерного кода отсутствуют имена.
   Оценочную версию IDA Pro, пригодную для первоначального знакомства с программой, можно загрузить с www.datarescue.com/idabase/ida.htm. SoftICE компании Numega – другой популярный отладчик. Дополнительные сведения о нем можно найти по адресу www.compuware.com/products/numega/drivercentral/.
   Для сравнения была написана небольшая программа на языке C (классическая небольшая программа, выводящая строку «Hello World»). Для отладки использовался отладчик GNU (GDB). Код программы представлен ниже:

   #include <stdio.h>
   int main ()
   {
   printf (“Hello World\n”);
   return (0);
   }

   Программа была скомпилирована с включением отладочной информации (был включен переключатель —g):

   [elliptic@]$ gcc -g hello.c -o hello
   [elliptic@ellipse]$ ./hello
   Hello World

   Пример протокола отладки под управлением GDB показан ниже:

   [elliptic@ellipse]$ gdb hello
   GNU gdb 19991004
   Copyright 1998 Free Software Foundation, Inc.
   GDB is free software, covered by the GNU General Public
   License, and you are welcome to change it and/or
   distribute copies of it under certain conditions.
   Type “show copying” to see the conditions.
   There is absolutely no warranty for GDB. Type “show
   warranty” for details.
   This GDB was configured as “i386-redhat-linux”...
   (gdb) break main

   Была установлена точка прерывания при входе в функцию main. При ее достижении выполнение программы было приостановлено для выполнения программистом действий по отладке программы. Контрольная точка была установлена до выдачи команды run.

   Breakpoint 1 at 0x80483d3: file hello.c, line 5.
   (gdb) run

   Команда run начинает выполнение программы под управлением отладчика.

   Starting program: /home/ryan/hello
   Breakpoint 1, main () at hello.c:5
   5 printf (“Hello World\n”);
   (gdb) disassemble

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

   Dump of assembler code for function main:
   0x80483d0 <main>: push %ebp
   0x80483d1 <main+1>: mov %esp,%ebp
   0x80483d3 <main+3>: push x8048440
   0x80483d8 <main+8>: call 0x8048308 <printf>
   0x80483dd <main+13>: add x4,%esp
   0x80483e0 <main+16>: xor %eax,%eax
   0x80483e2 <main+18>: jmp 0x80483e4 <main+20>
   0x80483e4 <main+20>: leave
   0x80483e5 <main+21>: ret
   End of assembler dump.

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

   (gdb) s
   printf (format=0x8048440 “Hello World\n”) at printf.c:30
   printf.c: No such file or directory.

   После задания командой s («step») режима пошагового выполнения программы в отладчике выполняется переход к вызову функции printf. GDB сообщает о невозможности дальнейшей детализации функции printf из-за отсутствия в распоряжении отладчика исходного кода функции printf.

   (gdb) s
   31 in printf.c
   (gdb) s
   Hello World
   35 in printf.c
   (gdb) c
   Continuing.

   Далее выполняется несколько шагов реализации программы внутри функции printf и программа завершается. По команде c («continue») программа будет выполнена до следующей точки прерывания или будет завершена.

   Program exited normally.
   (gdb)

   В число аналогичных программ входят программы nm и objdump пакета GNU. Программа objdump позволяет управлять объектными файлами. Она применяется для отображения символов объектного файла, его заголовка и даже дизассемблирования. Nm выполняет аналогичные действия, что и objdump, позволяя просматривать символьные ссылки на объектные файлы.
Инструментарий и ловушки
   Инструментарий никогда не заменит знаний
   Некоторые из средств дизассемблирования и отладки предлагают фантастические возможности. Но они, как и любой другой инструментарий, несовершенны. Особенно это проявляется при анализе злонамеренного кода (вирусов, червей, Троянских коней) или специально разработанных программ. Обычно авторы подобных поделок делают все возможное для затруднения их анализа и снижения эффекта от применения отладчиков, дизассемблеров и других подобных инструментальных средств. Например, вирус RST для Linux в случае обнаружения, что он работает под управлением отладчика, завершает свою работу. Этот же вирус при инфицировании исполняемых и компонуемых файлов ELF (Executable and Linkable Format – формат исполняемых и компонуемых модулей) модифицирует их заголовки таким образом, что некоторые дизассемблеры не могут дизассемблировать двоичный код вируса (обычно это достигается путем размещения кода вируса в необъявленном программном сегменте). Часто злоумышленный код шифруется или сжимается, что защищает его от экспертизы. Черви Code Red распространялись половинками своих программ, маскируясь под строки переполнения, и, таким образом, формат их двоичных данных не подходил ни под один из стандартных заголовков файла.
   Поэтому при анализе двоичных данных нужно знать не только о том, какие инструментальные средства и как применять, но и как обойтись без них. Анализируя заголовок файла, возможно, потребуется определить, какие данные в файле модифицированы, как и с какой целью. Вероятно, потребуется проанализировать зашифрованные данные и процедуру их расшифровки, восстановить алгоритм работы программы и выяснить результаты ее работы.
   Необходимо знать ассемблер не только в объеме, достаточном для чтения ассемблерных программ, но и для написания программ расшифровки или восстановления данных. Писать на ассемблере намного сложнее, чем читать программы, написанные на этом языке.
   Из этого не следует, что инструментальные средства бесполезны. Далеко не так. Нужно только выявить часть программы, оказавшуюся не по зубам инструментальным средствам, и проанализировать ее самостоятельно, а остальную часть программы – при помощи инструментальных средств. Кроме того, иногда для лучшего понимания логики работы программы следует воспользоваться инструментарием.

Тестирование методом «черного ящика»

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

Чипы

   Неизвестная микросхема – удачный пример встречающегося на практике «черного ящика». Без маркировки определить предназначение чипа очень сложно.
   Что можно вынести из визуального осмотра? Только то, что у чипа 16 контактов или что-то подобное этому. Исследовав монтажную плату и токопроводящие слои, довольно легко можно определить контакты питания. Их можно проверить вольтметром. Но если предположение о контактах питания окажется ошибочным, микросхема будет сожжена.
   Кроме того, следует попытаться сделать выводы, основываясь на других компонентах устройства. Можно составить список компонентов, подсоединенных к чипу, и выяснить, к каким контактам они подсоединены. Например, может оказаться, что два контакта в конечном счете подключены к светодиоду LED (LED – Light-Emitting Diode – светоизлучающий диод).
   Если окажется, что чип – простое устройство TTL-логики (transistor-transistor logic – транзисторно-транзисторные логические схемы), то можно определить реализуемые этим чипом простые логические функции, подавая на различные контакты напряжение, эквивалентное сигналам «истина/ложь» и одновременно измеряя выходное напряжение на других контактах. Если удастся определить, что чип относится, например, к классу схем И-НЕ (NAND (not-and) gate), то по каталогу микросхем можно определить исследуемый чип или его аналог.
   С другой стороны, чип может оказаться по своей сложности сравнимым с небольшим микропроцессором или встроенной вычислительной системой. В последнем случае для определения соответствия между входными и выходными сигналами методом проб и ошибок потребуется рассмотреть слишком много комбинаций. Вполне возможно, что во встроенной системе окажутся аналоговые компоненты (например, динамик), которые сведут на нет все попытки установления закономерностей двоичной логики.
   С образцами подобных устройств можно познакомиться по адресу www.parallaxinc.com/html_files/products/Basic_Stamps/module_bs2p.asp. Parallax производит семейство чипов со встроенным интерпретатором BASIC, отличающихся различными комбинациями входных и выходных интерфейсов. Главная сложность подобного устройства заключается в том, что число его состояний заведомо больше, чем можно перечислить. Даже крошечный компьютер с небольшим количеством памяти может сгенерировать бесконечно большое число неповторяющихся результатов. В качестве простого примера представьте себе компьютер на одном чипе, который складывает большие целые числа. Все, что он может сделать, – это выполнить простую программу добавления 1 к введенному числу и вывести результат. Вероятно, исследователь быстро определит, что на компьютере выполняется простая программа сложения чисел, но определить другие возможности компьютера практически невозможно. Иными словами, ничего нельзя сказать о том, является ли это устройство компьютером общего назначения или оно выполняет единственную функцию.
   Сложно найти закономерность при исследовании систем методом «черного ящика». Но некоторые извлекают пользу из этого. Закономерности могут быть найдены случайно или в результате активных исследований. Прежде чем попытаться скрыть какую-либо закономерность, следует удостовериться в том, что число вариантов ее проявления достаточно велико. Конкретный пример приведен в статье по адресу www.casinoguru.com/features/0899/f_080399_tocatch.htm. В статье говорится o жуликоватом технике игорных автоматов, который заменил чип в некоторых автоматах. В результате каждый раз при вбрасывании определенной последовательности монет в автомат и дерганья за ручку автомат выплачивал джек-пот. Речь идет об основных приемах «зашивки» в программы «секретных» недокументированных сообщений!
   Если из результатов исследования и доступной информации непонятно, что это за чип, то вскройте его! Вскрыть чип? Именно так. Исследователям защитного корпуса таких устройств, как смарт-карты (smart card – кредитная карточка с микропроцессором), известно много способов их изучения, включая выжигание корпуса чипа кислотой и исследование его структуры под микроскопом. Подробнее эти вопросы освещены в главе 14.
   Итак, если исследователь с помощью метода «черного ящика» не может разобраться с устройством чипа, то он должен вскрыть его. Опыт посещения автором копий обсидиана (вулканического стекла) в Аризоне наглядно демонстрирует это. Если держать обсидиан на расстоянии вытянутой руки, то он выглядит как черный камень. Но при ярком свете обсидиан становится немного прозрачнее. Таким образом, он не вполне «черный ящик», а скорее в той или иной степени прозрачный «ящик из обсидиана». Другими словами, у исследователя всегда есть возможность получить информацию о решаемой задаче.

Резюме

   Методологии поиска уязвимости часто используют принципы аудита безопасности систем. Изучение исходного текста программ начинается с выявления потенциально небезопасных функций, например strcpy и sprintf. Другой способ заключается в тщательной построчной экспертизе исходного текста программы в соответствии с логикой ее работы. Анализ различий – еще один способ поиска уязвимостей, при котором широко применяется утилита diff. Утилита diff, сравнивая две версии программы, позволяет найти внесенные в программу исправления. При исследовании выполнимого кода программы применяются различные средства: программы трассировки, отладчики, анализаторы, а также аудит документации.
   Аудит исходного текста программы предполагает поиск потенциально опасных функций и применение методологии построчного аудита. В этой главе были рассмотрены примеры, демонстрирующие переполнение буфера при использовании функций strcpy, sprintf, strcat и gets. Были рассмотрены такие ошибки проверки входных данных, как уязвимость форматирующей строки функции printf и функции open в программе, написанной на языке Perl. Также был рассмотрен пример конкуренции программ за ресурсы и сопутствующая ей ошибка условия гонок на примере функции mktemp.
   Реинжиниринг – один из наиболее часто используемых методов поиска уязвимостей в программе, исходный текст которой недоступен. Этот тип исследования проводится по методике «сверху вниз». Средства аудита в Windows можно найти на сайте sysinternals.com, а список Rosetta Stone поможет выбрать средства трассировки на различных платформах. В этой главе был рассмотрен пример трассировки команды cat сначала в среде Red Hat Linux и в Solaris 7.
   Дизассемблер и отладчики позволяют исследовать выполнимый код. Дизассемблер (также известный как декомпилятор) – это программа, которая преобразует двоичный код в исходный текст программы на языке высокого уровня, но чаще всего на языке ассемблера. Отладчик – программа, которая может управлять выполнением другой программы. В этой главе был приведен пример дизассемблирования программы на платформе Windows с использованием отладчика IDA Pro, а также пример сессии отладки под управлением отладчика GDB в Linux. Также были обсуждены возможности программ objdump и nm. Программа objdump позволяет управлять объектными файлами программ, а nm — отображает содержащуюся в них символьную информацию.
   «Черный ящик» – концептуальный компонент, чьи внутренние функции скрыты от пользователя. Тестирование «черного ящика» похоже на бинарный аудит. На практике к методам тестирования «черного ящика» прибегают при реинжиниринге интегральных схем. Определить предназначение чипа можно, изучив выходные сигналы чипа, а если это не поможет – вскрыв его корпус. «Черные ящики» могут различаться по степени своей прозрачности для исследователя, в зависимости от его знаний об устройстве анализируемой системы.

Конспект

Суть методологии исследования уязвимости
   · Исследование исходного текста программ предполагает поиск подверженных ошибкам директив, построчную экспертизу исходного текста программы и изучение различий в нем.
   · Изучение выполнимого кода программы осуществляется при помощи программ трассировки, отладчиков, модулей проверки текущего состояния программы (анализаторов) и аудита документации проектирования программы.
Значение экспертизы исходного текста программы
   · Экспертиза исходного текста программы – необходимая часть обеспечения ее безопасности.
   · Поиск подверженных ошибкам конструкций языка программирования в исходном тексте программ позволяет найти ошибки переполнения буфера, проверки входных данных и ошибки, сопутствующие конкуренции программ за ресурсы.
   · Утилита grep может использоваться для повышения эффективности поиска подверженным ошибкам директив.
Технологии реинжиниринга
   · На сайте www.sysinternals.com можно найти свободно распространяемые инструментальные средства аудита для Windows.
   · Список Rosetta Stone (по адресу http://bhami.com/rosetta.html) позволяет найти программы трассировки для заданной платформы.
   · Отладчики используются для управления выполнением исследуемой программы и поиска ошибок в ней или исследования логики ее работы.
Тестирование методом «черного ящика»
   · Тестирование методом «черного ящика» позволяет обнаружить внутренние компоненты, скрытые от невооруженного взгляда исследователя.
   · Вскрытие корпуса «черногоящика» – самый легкий способ для определения его внутреннего строения.
   · Абсолютно «черныхящиков» нет. Одни из них – более «черные», а другие – менее.

Часто задаваемые вопросы


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

   Вопрос: Законны ли с юридической точки зрения декомпиляция и другие методы реинжиниринга?
   Ответ: В Соединенных Штатах реинжиниринг скоро может стать противозаконным. В Акте авторского права цифрового тысячелетия (Dig^l Millennium Copyright Act) содержатся меры по предотвращению обхода обманным путем технологических мер управления доступом к работам, защищенным авторским правом. Исходный текст программы может быть защищен авторским правом, поэтому в этом случае реинжиниринг текста, защищенного авторским правом, противозаконен.

   Вопрос: Какие инструментальные средства могут быть полезны при экспертизе сложных исходных текстов программ?
   Ответ: Такие инструментальные средства, как SCCS и CVS, могут облегчить экспертизу исходного текста программы. Кроме того, применение интегрированных сред разработки (IDEs – Integrated Development Environmen) может облегчить экспертизу исходного текста.

   Вопрос: Где можно узнать правила разработки защищенного программного обеспечения?
   Ответ: Для этой цели подойдут ресурс Интернета «Часто задаваемые вопросы по разработке защищенного программного обеспечения в среде UNIX (Secure UNIX Programming FAQ)» по адресу www.whitefang.com/sup/secure-faq.html или список адресатов secprog, поддерживаемый Оливером Фридричсом (OliverFriedrichs).

   Вопрос: Где можно достать утилиту strace для моей платформы?
   Ответ: Утилита strace – инструментальное средство Linux. Наилучший выбор для платформы Windows, обладающий аналогичными функциональными возможностями, – IDO Pro. Truss реализует ту же самую функцию на платформе Solaris. Дополнительную информацию можно найти в документации производителя.

   Вопрос: Откуда можно загрузить исходные тексты приведенных в главе примеров?
   Ответ: Исходные тексты доступны по адресу www.syngress.com/solutions.

Глава 5
Поиск различий

   В этой главе обсуждаются следующие темы:
   • Суть поиска различий
   • Исследование инсрументария поиска различий
   • Поиск неисправностей
   · Резюме
   · Конспект
   · Часто задаваемые вопросы

Введение

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

Суть поиска различий

   Команда diff присутствует во многих современных операционных системах семейства UNIX и им подобных. Впервые она появилась в дистрибутиве UNIX компании AT&T, и в настоящее время эксплуатируются различные ее версии. Слово diff – сокращение от английского слова difference (различие) – означает составление списка различий двух файлов.
   Таким образом, слово диффинг может быть определено как применение команды diff (или подобной программы) для сравнения двух файлов. Сравнивая файлы, можно выявить внесенные изменения в новую версию программы по сравнению с предыдущей, определить различия двоичных файлов, претендующих на эквивалентность, или отследить влияние изменений файла данных на работу программы.
   Изучите исходный текст программы, приведенный на рис. 5.1.
   Рис. 5.1. Исходный текст scpybufo.c

   Уже говорилось о сопутствующей этой программе ошибке переполнения буфера. (Эта программа была рассмотрена в главе 4 в секции, посвященной переполнению буфера.) Просмотрите исходный текст программы, представленный на рис. 5.2.
   Рис. 5.2. Исходный текст sncpyfix.c

   Применяя команду diff операционной системы UNIX, можно точно определить место и суть различий между двумя программами (см. рис. 5.3).
   Рис. 5.3. Результаты сравнения файлов scpybufo.c и sncpyfix.c командой diff

   Из протокола работы команды видно, что относящиеся к файлу scpybufo.c данные отмечены символом <, а к файлу sncpyfix.c – символом >. Команда нашла первое отличие в заголовке этих файлов.
   Со строки номер 25a24 начинаются различия в исходных текстах программ. Переменная Size_t есть в файле sncpyfix.c, но отсутствует в scpybufo.c. А в строке под номером 27c26 видна замена функции strcpy на strncpy. Хотя сравнить столь небольшие файлы можно и вручную, целесообразность применения команды diff для cравнения больших файлов более очевидна. Далее будут обсуждены причины поиска различий.

Почему нужно знать о различиях файлов?

   Для этого ему следует сделать копию файла, сменить пароль и сравнить копию с измененным файлом. Различия между этими файлами, а их может быть несколько, позволит найти пароль. Зная место (места) хранения пароля, хакер может изменять двоичный файл в обход исследуемой программы. В этой главе будет рассмотрен пример, поясняющий сказанное. В подобных случаях целью злоумышленника является непосредственное изменение хранимых в файле данных.
   Иногда злоумышленник в большей степени заинтересован в декодировке информации, а не в ее изменении. До обнаружения различий последовательность действий может совпадать с уже рассмотренной. После выявления различий, вместо того чтобы записать по найденным адресам свою информацию, злоумышленника могут заинтересовать причины и условия подобных изменений.
   Другая причина поиска различий кроется в исследовании безопасности программ. Во времена всеобщей открытости обычной практикой производителей остается выпуск обновлений программ без раскрытия их сути. Виновники этой практики – некоторые ведущие производители программного обеспечения, как, например, Microsoft, Hewlett-Packard и Caldera. С другой стороны, производители Linux (за исключением Caldera) – исключение из этого правила. А ряд компаний занимают промежуточную точку зрения по этому вопросу, как, например, Cisco.
   Метод поиска различий позволяет изучить заявленную производителем уязвимость, но до конца им не раскрытую. В результате выявления различий в исходных текстах двух программ становятся ясны недостатки программы, и можно оценить их влияние на безопасность. Кроме того, выявленные различия позволят найти ошибки, которые производитель устранил без лишнего шума в старших версиях программы.

Просмотр исходного текста программы

   Благодаря отчету команды diff, приведенному на рис. 5.3, можно найти два исправления в исходном тексте программы. Первое состоит в добавлении переменной size_t в программу sncpyfix.c. Второе – в замене функции strcpy в программе scpybufo.c на функцию strncpy в программе sncpyfix.c.
   Найти ошибки в открытых программных средствах относительно легко. (open source software – открытые программные средства – лицензионные программы вместе с их исходными текстами, не связанные ограничениями на дальнейшую модификацию и распространение с сохранением информации о первичном авторстве и внесенных изменениях). Зачастую это объясняется возможностью инсталляции файлов, устраняющих ошибки. Это можно наблюдать на примере патчей (заплаток), выпущенных производителями операционных систем семейства UNIX, например Linux и BSD. Проанализируйте патч на рис. 5.4 выявленной уязвимости FreeBSD-SA-02:02 (FreeBSD Security Advisory FreeBSD-SA-02:02).
   Рис. 5.4. Исходный текст патча pw.patch FreeBSD

   Этот патч представлен в унифицированном формате различий. Хотя предоставленная службой компьютерной безопасности FreeBSD информация о патче содержит все необходимые сведения, включая детальное описание уязвимости, анализ отчета результата сравнения двух файлов позволяет понять ее суть. Из первой строки протокола патча ясно, что он применяется к программе pwupd.c из директории usr.sbin/pw/.
   Утилита pw операционной системы FreeBSD предназначена для добавления, удаления или модификации пользователей системы либо их групп. Выявленная уязвимость состояла в том, что при работе утилиты pw создавался временный файл с разрешениями, которые позволяли всем пользователям читать его. Разрешения временного файла в отчете выделены знаком минус (-). В результате пользователь мог получить доступ к зашифрованным паролям системы.
   Автор самостоятельно проанализировал исходный текст утилиты pw. После получения двух версий исходных текстов (файл pwupd.c) утилиты (до и после внесения изменений) и их сравнения при помощи команды diff можно найти различия в исходных текстах данной программы, как это показано на рис. 5.5.
   Рис. 5.5. Протокол различий программы pwupd.c версий 1.12.2.3.2.1 и 1.17

   Из сравнения двух версий программы видны различия, аналогичные изменениям, показанным на рис. 5.4.
Приоткрывая завесу
   Рекурсивный просмотр директорий
   Что делать, если неизвестен файл, в который были внесены изменения? Что делать, если вместо подробной информации об уязвимости доступна только новая версия программы, содержащая многочисленные директории исходных текстов программ? Это именно тот случай, когда наиболее удобно воспользоваться командой diff для сравнения директорий.
   Используя флаг рекурсии – г, содержимое директории может быть исследовано при помощи команды diff. При сравнении директорий в этом режиме сравниваются все файлы директории и все поддиректории заданной директории. Возможность рекурсивного сравнения присутствует в команде GNU diff и отсутствует в версиях других операционных систем.
   Например, возможность рекурсивного сравнения отсутствует в команде diff операционной системы Solaris 8 и более ранних. Хотя, используя некоторые изощренные приемы работы с командной строкой, это можно выполнить. В соответствии с IAOQ (IAOQ – Ryan Tennant's (Argoth) Solaris Infrequently Asked Obscure Questions – список наиболее часто задаваемых вопросов повышенной сложности по системе Solaris Райана Теннанта (Argoth)) рекурсивный просмотр директорий может быть выполнен при помощи следующей команды:

   /usr/bin/find. | /usr/bin/xargs /usr/bin/grep PATTERN

В поисках золота. Игровой пример
   В тринадцать лет автор загорелся идеей оказания воздействия на приложение путем непосредственной работы с файлами. В то время у него был компьютер Apple][+ и он в меру увлекался компьютерными играми. С точки зрения игр он вполне был на уровне мастерства, достигаемого за один-два года практики. Его любимой игрой была Ultima 2. Ultima 2 – это ролевая фантастическая игра, где вам предлагается сыграть роль героя, который в поисках золота может выбирать оружие для истребления монстров. Как в типичных играх этого жанра, цель состоит в повышении уровня мастерства и опыта в деле поиска золота. А попутно при этом решается еще ряд вопросов. Чем опытнее игрок, тем эффективнее он истребляет монстров, тем больше у него золота, тем лучшее оружие и амуницию он может купить.
   Однажды автор захотел обмануть игру. Он устал честно убивать монстров. Уже в этом возрасте у него появились мысли, как подправить игру, обманув ее. Первое, что пришло ему в голову, – это изменить количество золотого запаса. Он знал, что при сохранении игры на диск записывается какая-то информация об игре. Нужно было только найти, где именно на диск сохраняются сведения о золотом запасе, и изменить их.
   Использованная автором техника немного отличается от изложенной в этой главе, главным образом потому, что тогда в распоряжении автора были программные средства более примитивные, чем сегодня. Запомнив количество золота, автор сохранял игру, а затем завершал ее. В его распоряжении был редактор секторов – программа, позволяющая непосредственно редактировать сектора диска, обычно в шестнадцатеричном формате. Используя функцию поиска редактора, можно было по имени своего героя найти приблизительное место хранения информации, интересующей автора. Короче говоря, автор нашел несколько чисел, соответствующих золотому запасу героя на момент сохранения игры. Увеличив эти числа и сохранив изменения на диске, после загрузки игры автор убедился, что золотой запас героя возрос. Эврика! Это был первый хакинг автора. Таким образом, автор наткнулся на прием, который будет служить ему в течение многих лет.
   Автор смог расширить свое маленькое исследование и написал редактор героев Ultima 2, который позволил ему изменять такие свойства героев, как их сила, ум, количество и тип оружия, амуниция и т. д. Конечно, сегодня, по прошествии многих лет, он раскаивается по поводу содеянного. (К сведению читателя автор сообщает, что недавно вышла Ultima IX. В среднем производитель выпускает новую версию игры каждые 2 года.) В настоящее время автор играет в разные фантастические ролевые игры, например Heroes of Might and Magic II, где игрок играет роль героя, пытающегося добыть золото, совершенствующего свое мастерство в деле убийства монстров… Ну, вы поняли идею. На рисунке 5.6 показан старт типичной игры.
   Рис. 5.6. Начало игры Heroes of Might and Magic II

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

   Команда fc сравнивает два файла. Если задать опцию /b, то выполняется побайтное сравнение. В результате печатается отчет найденных различий в шестнадцатеричном виде. Поэтому следующее, на чем следует остановиться, – это калькулятор Windows (программа calc.exe), который позволяет перевести числа 7500 и 7425 из десятичной системы счисления в шестнадцатеричную. Если выбрать подменю Scientific меню View калькулятора, то станут доступными дополнительные возможности преобразования чисел, включая преобразование из десятичного формата в шестнадцатеричное, что нам и требуется. При выбранном режиме Dec следует набрать 7500 и затем щелкнуть на кнопке Hex. В результате получим представление числа 7500 в шестнадцатеричной системе счисления 1D4C. Повторив то же самое для числа 7425, получаем 1D01.
   Просмотрев результаты выполнения команды fc, обнаруживаем многообещающее различие по адресу 368 (в шестнадцатеричном представлении). Ранее там было 4C, а стало 01, что точно совпадает с проведенными вычислениями. Также можно предположить значения других чисел. Ранее в замке было восемь скелетов. После покупки одного осталось семь. На это, кажется, указывает байт по адресу 3AE4. Байт по адресу 3AD3 может означать один скелет в гарнизоне замка, где прежде не было ни одного.
   Но поскольку автора интересует золотой запас, то он запускает шестнадцатеричный редактор и загружает файл hack2.gm1. Шестнадцатеричный редактор схож с редактором секторов, но ориентирован на работу с файлами, а не с дисковой памятью. Перейдя по смещению 368, видим, что там находятся данные 1D 01. Отметим, что цифры в числе расположены в обратном порядке, что непривычно для людей, которые используют язык, имеющий одинаковые корни с латинским языком. Объясняется это порядком запоминания чисел в процессорах Intel: наименее значащий байт числа запоминается по младшему адресу. Есть единственный способ удостовериться в правильности предположения о хранении найденной величины – изменить найденный байт. Автор изменил самый правый байт числа 1D (поскольку в этом случае результаты изменения проявятся сильнее всего) на величину FF (максимальная величина в шестнадцатеричной системе счисления). На рисунке 5.8 показан результат загрузки hack2.gm1 при старте игры.
   Рис. 5.8. Та же игра после редактирования ее сохраненных данных

   Обратите внимание на золотой запас, который теперь составляет 65 281 порцию. Быстрая проверка на компьютере подтверждает, что это десятичное представление шестнадцатеричного числа FF01. Теперь у игрока появилось серьезное преимущество: он может с легкостью крушить своих воображаемых врагов. Если бы игрок захотел увеличить свой золотой запас до максимально возможной в игре величины, то ему следовало бы также увеличить следующий байт справа от 1D, который в момент исследования был равен 0. В худшем случае несколько попыток изменения смежных байт в файле с помощью шестнадцатеричного редактора подскажут, какой байт следует изменить для увеличения золотого запаса игрока.
   Конечно, цель этой книги не в том, чтобы научить читателя обманывать игры. Есть более достойное применение изложенного материала. В частности, для подобных игр написан редактор сохранения игр, возможно, на основе использования изложенной техники. Также можно включить в игру несколько фрагментов кода, страхующих игрока от проигрыша. Читателю, заинтересовавшемуся подобными вопросами, можно посоветовать найти эту информацию в Интернете.
   Если читатель знаком с игрой, то он может быть удивлен, почему изложенное не проиллюстрировано на примере современной версий игры Heroes of Might и Magic III. Причина будет раскрыта далее.

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

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

Применение инструментария сравнения файлов

Использование команды fc
   Команда fc, включаемая в течение многих лет в DOS, а позднее и в Windows – первый инструментарий, который будет подробно рассмотрен. На машинах с операционной системой Windows 9x команду fc можно найти в директории c: \windows\command, c: \windows или, в крайнем случае, в одной из директорий Windows. По умолчанию директория c: \windows\command перечислена в списке каталогов, используемых для задания порядка поиска выполнимых программ. Список задается командой path. Поэтому при необходимости можно просто набрать fc и выполнить команду. Опции команды fc перечислены ниже:

   C:\windows\COMMAND>fc /?
   Compares two files or sets of files and displays the
   differences between
   them.
   FC [/A] [/C] [/L] [/LBn] [/N] [/T] [/W] [/nnnn]
   [drive1:][path1]filename1
   [drive2:][path2]filename2
   FC /B [drive1:][path1]filename1 [drive2:][path2]filename2
   /A Displays only first and last lines for each set of
   differences.
   /B Performs a binary comparison.
   /C Disregards the case of letters.
   /L Compares files as ASCII text.
   /LBn Sets the maximum consecutive mismatches to the
   specified number of lines.
   /N Displays the line numbers on an ASCII comparison.
   /T Does not expand tabs to spaces.
   /W Compresses white space (tabs and spaces) for
   comparison.
   /nnnn Specifies the number of consecutive lines that must
   match after a mismatch.

   О переключателе /b уже говорилось. При сравнении двоичных файлов без указания переключателя процесс сравнения файлов завершается при достижении символа конца файла или нулевого байта. У этой команды переключатели режимов не чувствительны к регистру. Другими словами, работа команды не зависит от того, набраны ли переключатели строчными или заглавными буквами. Например, в файле подсказки описан переключатель /В, набранный заглавными буквами, в то время как в книге продемонстрирована прекрасная работа команды с переключателем /b. У команды есть ряд дополнительных переключателей, который читатель сможет изучить самостоятельно. В дальнейшем будет сказано о ряде утилит, которые сравнивают текстовые файлы лучше, чем команда fc. Но если выбранная читателем утилита может и отсутствовать на его компьютере, то, в крайнем случае, fc всегда присутствует на машинах с операционной системой Windows.
   Примечание
   В первом приближении эквивалентом команды fc в системе UNIX является команда cmp -l (l — строчная буква).
Использование команды diff
   Первоначально команда diff появилась на платформе UNIX. Она позволяет сравнивать двоичные файлы, но особенно полезна для сравнения текстов. Фактически ее возможностей сравнения текстовых файлов более чем достаточно. Полностью перечислить все возможности команды diff на страницах этой книги не представляется возможным, потому что их слишком много. Но с ними можно ознакомиться на оперативных страницах руководств UNIX или по документации (man page, сокр. manual page – оперативная страница руководства, – гипертекстовая страница консультативной информации, поясняющая действие конкретной команды).
   Для того чтобы у читателя стожилось представление о команде diff, если он не слышал о ней ранее, в главе приведен список наиболее часто используемых возможностей команды. Команда diff определяет изменения в двух файлах, которые нужно сделать для приведения их в соответствие друг к другу. Она позволяет запоминать версии файлов без необходимости хранения полных копий каждой версии файла. Команда diff настолько хороша, что понимает, должны ли строки удаляться или добавляться в файл при приведении файлов в соответствие друг к другу:

   [root@rh /tmp]$ diff decode.c decode2.c
   14a15
   > #include <newinclude.h>
   [root@rh /tmp]$ diff decode2.c decode.c
   15d14
   < #include <newinclude.h>

   Указанные в аргументах два файла (decode2.c и decode.c) полностью совпадают, за исключением строки с оператором #include <newinclude.h>, добавленной к файлу decode2.c. В первом примере файл decode.c – первый аргумент команды diff, а decode2.c – второй. Протокол работы команды свидетельствует о том, что если во второй файл в 14-ю строчку добавить 15-ю строку из файла decode2.c #include <newinclude.h>, то далее файлы будут соответствовать друг другу. А если поменять аргументы местами, то для приведения файлов в соответствие надо будет удалить 15-ю строчку файла decode2.c (обратите внимание на буквы a в первом отчете и d во втором).
   Результат выполнения команды называется выводом команды diff (diff-файлом), или файлом различий, и обладает тем свойством, что если есть diff-файл и один из исходных сравниваемых файлов, то второй файл можно восстановить. Именно поэтому для отправки небольшого количества изменений текстового файла, особенно исходных текстов программ, часто используется пересылка файла различий. При отправке по почте открытых исходных текстов исправлений уязвимостей программ отправитель не всегда пересылает файл различий, который позволяет исправить исходный текст программы. Программа, которая исправляет ошибки, используя файл различий, называется патчем (заплаткой).
   В зависимости от версии diff в отчет команды, кроме выявленных различий, включается и другая информация, например для редактора ed или системы управления аудитом (RCS – Revision Control System). Для того чтобы ее можно было обработать, включаемая информация должна содержать регулярные выражения для выполнения некоторых операций, понимать файлы программ, написанных на языке С, и, как часть своего отчета, может выводить имя функции, в которой выявлены изменения.
   Благодаря проекту Cygwin доступна Windows-версия команды diff (как и большинство других программ UNIX). В рамках этого проекта задуман перенос ряда программного инструментария GNU и других программ UNIX на платформу Windows. В той или иной форме продукты GNU выпускаются под защитой общедоступной лицензии GNU (GPL – GNU PublicLicense), в соответствии с которой продукт становится общедоступен. Дополнительные сведения (включая пакет, содержащий Windows-версию команды diff) могут быть найдены по адресу http://sourceware.cygnus.com/cygwin.
   Компания Microsoft включила утилиту Windiff в состав инструментария ресурсов (resource kits) Windows NT и Windows 98. Это графическая версия команды diff, которая отображает изменения разными цветами и имеет графическое представление удаляемых или вставляемых строк.

Работа с шестнадцатеричными редакторами

   Говоря о применении шестнадцатеричных редакторов, уже упоминалось о возможности изменения двоичных файлов. Шестнадцатеричный редактор – это программное средство, позволяющее пользователю получить непосредственный доступ к двоичному файлу в обход приложения, использующего этот файл. Говоря о двоичных файлах, имеются в виду и текстовые файлы. Конечно, большинство людей используют для редактирования текстовых файлов специальные программы, поскольку применение для этих целей шестнадцатеричных редакторов неудобно и, говоря образно, сродни самоубийству.
   В общем случае шестнадцатеричный редактор не понимает формат редактируемых файлов. Некоторые шестнадцатеричные редакторы снабжены мощными возможностями поиска, преобразования цифрового представления чисел, вставки, удаления и др. Но на самом деле они работают с последовательностью байтов. Только пользователь шестнадцатеричного редактора определяет, какие байты следует изменить, как это ранее было продемонстрировано на примере игры.
   Известно большое количество шестнадцатеричных редакторов, которые различаются ценой (от свободно распространяемых до коммерческих), качеством и функциональными возможностями. Для большинства людей выбор редактора определяется личными предпочтениями. Читателю следует попробовать несколько редакторов, пока он не найдет наиболее ему подходящий.
   Далее кратко будут рассмотрены три шестнадцатеричных редактора: – Hackman, [N] Curses Hexedit и Hex Workshop. Их рассмотрение не охватывает все шестнадцатеричные редакторы. Просто они представляются автору наиболее интересными.
Hackman
   Hackman – свободно распространяемый шестнадцатеричный редактор в среде Windows. У него ряд возможностей, включая функции поиска, удаления, вставки, дизассемблирования, шестнадцатеричный калькулятор и многое, многое другое. Как видно из рис. 5.9, графический интерфейс пользователя (GUI) несколько аскетичен.
   Рис. 5.9. Интерфейс пользователя редактора Hackman

   В конце рис. 5.9 показано, что редактор Hackman предоставляет интерфейс командной строки. На рисунке приведен пример шестнадцатеричного редактирования файла cmd.exe при помощи редактора Hackman. Hackman легок в использовании. Кроме основных функциональных возможностей, необходимых пользователю при работе с шестнадцатеричным редактором, он дополнительно предоставляет хорошо продуманный интерфейс пользователя. Благодаря недавним усилиям разработчиков он надежен и удобен для пользователя. Редактор можно найти по адресу www.technologismiki.com/hackman.
[N] Curses Hexedit
   [N] Curses Hexedit – другая свободно распространяемая программа (фактически ее можно рассматривать как более свободно распространяемую, поскольку она распространяется по общедоступной лицензии GPL). Поскольку программу можно получить по общедоступной лицензии, то ее исходные тексты общедоступны и разрешено их улучшать или адаптировать под нужды конкретного пользователя. Существуют версии редактора [N] Curses Hexedit для всех основных UNIX подобных операционных систем и DOS.
   Если читатель думает, что интерфейс Hackman простой, то у этой программы, как видно из рис. 5.10, – явно спартанский.
   Рис. 5.10. Интерфейс редактора [N] Curses Hexedit, DOS версия

   Функциональные возможности редактора обычные для этого класса программ. В редакторе реализована функция поиска, присутствует простой двоичный калькулятор, обычные команды просмотра и редактирования. Список команд представлен на рис. 5.11.
   Рис. 5.11. Подсказка редактора [N] Curses Hexedit Help Screen

   Если кому-то покажется, что в этом редакторе реализованы далеко не все функциональные возможности, то это компенсируется простотой, легкостью использования ресурса и поддержкой многочисленных платформ. Согласно журналу изменений, текущая версия редактора – 0.9.7 от 8 августа 1999 года. Из этого не следует, что проект свернут и не имеет будущего. Скорее всего, редактор полностью удовлетворяет требованиям своих разработчиков. Возможно, если автор решит добавить что-либо или будет найдена ошибка в редакторе, то будет выпущена очередная версия программы. Также возможно, что если читатель усовершенствует редактор и сообщит об этом разработчикам, то они включат его добавления в новый официальный выпуск.
   [N] Curses Hexedit можно получить по адресу http://ccwf.cc.utexas.edu/~apoc/programs/c/hexedit.
Hex Workshop
   В заключение рассмотрим коммерческую версию шестнадцатеричного редактора Hex Workshop компании Breakpoint Software. Это относительно недорогой пакет (на момент написания книги он стоил .95) для платформы Windows. Бесплатно предоставляется 30-дневный испытательный срок использования программы. В редакторе реализован приятный интерфейс с полным набором функций. Интерфейс приведен на рис. 5.12.
   Рис. 5.12. Интерфейс пользователя Hex редактора Workshop

   В состав Hex Workshop включены арифметические функции, конвертер системы счисления, калькулятор, калькулятор контрольной суммы и многие другие возможности. Если руки читателя привыкли к стандартным клавишам управления операционной системы Windows (например, по нажатии CTRL-F инициируется диалоговое окно поиска), то, вероятно, он почувствует себя в родных стенах.
   Если читатель – пользователь Windows, тратящий много времени на редактирование двоичных файлов, то, возможно, он захотел бы поближе познакомиться с пакетом. Hex Workshop может быть найден по адресу www.bpsoft.com.

Использование инструментария мониторинга файловой системы

   Инструментальные средства мониторинга файловой системы – третий класс инструментальных средств, рассмотренных в этой главе. Они отличаются от инструментария работы с отдельными файлами тем, что работают с такими группами файлов, как раздел, логический диск или директория. В соответствии со своим предназначением в инструментальных средствах мониторинга файловой системы реализован более широкий диапазон функциональных возможностей. В некоторых случаях будут рассмотрены полезные побочные эффекты.
   Перед началом работы следует определиться, какой именно файл представляет интерес для исследования. Иногда он может быть определен при помощи метода проб и ошибок, иногда – на основе тех или иных предположений. Но в любом случае желательно иметь средства, которые бы облегчили этот процесс.
   Например, читатель, возможно, захочет узнать, что изменилось в результате выполнения программы. В большинстве случаев меняются файлы (файл) на диске, но какие именно? Не зная имен модифицированных файлов, как определить, какие файлы были модифицированы?
   Очевидный способ заключается в сохранении копии каждого представляющего интерес файла и сравнении каждого файла, который потенциально мог быть модифицирован, со своей копией для определения, был ли файл модифицирован или нет (не забывая о проверке новых файлов). Но этот способ сложно реализовать, и он требует необоснованно больших затрат времени. Поэтому проанализируем несколько методов, которые могут облегчить эту работу.
Трудоемкий способ: ручное сравнение
   Естественно, у читателя есть возможность сделать все вручную, но для этого потребуется затратить много усилий. Как уже говорилось, читатель может вручную сделать копии всего, что может быть изменено (все файлы на диске в директории или на всем диске), дождаться момента изменений и затем проверить, были ли изменены файлы.
   Очевидно, что так можно сделать, но на это уйдет больше времени и труда, чем если бы читатель поступил по-другому. Хотя в отдельных случаях ручное сравнение – лучший способ исследования. Например, при исследовании реестра Windows (Windows Registry – иерархическая база данных, хранящая информацию о конфигурации компьютера и об аппаратном и программном обеспечении; организована в структуру поддеревьев с ключами и подключами) может получиться так, что на исследуемой машине не окажется инструментальных средств контроля нужной части реестра. В то же время утилита Regedit почти всегда доступна. Она позволяет экспортировать реестр Windows в текстовый файл. В других случаях, при необходимости отбора нескольких файлов среди ряда дополнительных, поиск различий на всем диске может оказаться предпочтительным для первоначальной локализации файла, представляющего интерес. Иногда метод грубой силы может оказаться привлекательнее тонких методов исследования, особенно если на их подготовку потребуется дополнительное время.
Сравнение атрибутов файла
   Один из методов поиска модифицированных файлов, позволяющих избежать копирования файлов, основан на использовании их атрибутов. К атрибутам файла относятся дата, время создания и модификации файла и разрешения работы с ним. Некоторые из них могут оказаться полезными для определения только что измененных файлов.
   Ниже представлен уместный фрагмент кода файла ext2_fs.h инсталляции Red Hat 6.2 Linux:

   /*
   * Structure of an inode on the disk
   */
   struct ext2_inode {
   __u16 i_mode; /* File mode */
   __u16 i_uid; /* Owner Uid */
   __u32 i_size; /* Size in bytes */
   __u32 i_atime; /* Access time */
   __u32 i_ctime; /* Creation time */
   __u32 i_mtime; /* Modification time */
   __u32 i_dtime; /* Deletion Time */
   __u16 i_gid; /* Group Id */
   __u16 i_links_count; /* Links count */
   __u32 i_blocks; /* Blocks count */
   __u32 i_flags; /* File flags */

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

   [elliptic@ellipse]$ diff /tmp/before /tmp/after
   2,3c2,3
   < drwxrwxr-x 2 ryan ryan 7168 Jun 16 01:55 .
   < drwxrwxrwt 9 root root 1024 Jun 16 01:55 ..
   –
   > drwxrwxr-x 2 ryan ryan 7168 Jun 16 01:56 .
   > drwxrwxrwt 9 root root 1024 Jun 16 01:56 ..
   97c97
   < -rw-r—r– 1 ryan ryan 31533 Jun 16 01:55 fs.h
   –
   > -rw-r—r– 1 ryan ryan 31541 Jun 16 01:56 fs.h

   Из примера видно, что файл fs.h изменился. Этот способ сравнения содержимого директории обнаруживает изменение любого атрибута файла. Быстрый способ простого отслеживания изменения атрибута времени заключается в использовании команды ls – al, показанной в следующем примере. Команда ls – al в примере соединена программным каналом с командой more:

   [elliptic@ellipse]$ ls -alt | more
   total 2224
   drwxrwxrwt 9 root root 1024 Jun 16 01:56 ..
   drwxrwxr-x 2 ryan ryan 7168 Jun 16 01:56 .
   -rw-r—r– 1 ryan ryan 31541 Jun 16 01:56 fs.h
   -rw-r—r– 1 ryan ryan 7295 Jun 16 01:55 a.out.h
   -rw-r—r– 1 ryan ryan 2589 Jun 16 01:55 acct.h
   -rw-r—r– 1 ryan ryan 4620 Jun 16 01:55 adfs_fs.h

   …и т. д. Файлы, модифицированные последними, выводятся первыми. В DOS/Windows команда dir /o: d позволяет отсортировать список выводимых файлов по дате, как это показано в следующем примере:

   C:\date>dir /o:d
   Volume in drive C has no label
   Volume Serial Number is 3C3B-11E3
   Directory of C:\date
   HEX-EDIT EXE 58,592 03-14-95 9:51p Hex-edit.exe
   HEXEDI~1 GZ 165,110 06-05-00 11:44p hexedit-0_9_7_tar.gz
   HEXEDIT EXE 158,208 06-06-00 12:04a hexedit.exe
   . <DIR> 06-16-00 12:18a .
   .. <DIR> 06-16-00 12:18a ..
   3 file(s) 381,910 bytes
   2 dir(s) 10,238.03 MB free

   В этом случае последние модифицированные файлы помещены в конец отчета.
Использование атрибута «Архивный»
   Расскажем о небольшой уловке, доступной пользователям DOS/Windows. Таблица размещения файлов (FAT – file allocation table) содержит атрибут файла «Архивный». Первоначально атрибут предназначался для определения факта изменения файла после последнего резервного копирования. В случае модификации файла этот атрибут свидетельствовал о необходимости создания очередной архивной копии файла. Конечно, после модификации файлов этим атрибутом можно воспользоваться для собственных целей. Посмотрите на пример просмотра директории с помощью команды attrib:

   C:\date>attrib
   A HEX-EDIT.EXE C:\date\Hex-edit.exe
   A HEXEDIT.EXE C:\date\hexedit.exe
   A HEXEDI~1.GZ C:\date\hexedit-0_9_7_tar.gz

   Обратите внимание на символ A в начале каждой строки. Он свидетельствует об установке атрибута «Архивный» и указывает на необходимость резервного копирования файла, к которому относится этот атрибут. Если повторно использовать команду attrib для очистки атрибута «Архивный», то получим следующее:

   C:\date>attrib -a *.*
   C:\date>attrib
   HEX-EDIT.EXE C:\date\Hex-edit.exe
   HEXEDIT.EXE C:\date\hexedit.exe
   HEXEDI~1.GZ C:\date\hexedit-0_9_7_tar.gz

   Теперь если изменить один или два файла из группы, то их атрибут «Архивный» будет установлен снова, как это показано на следующем примере:

   C:\date>attrib
   A HEX-EDIT.EXE C:\date\Hex-edit.exe
   HEXEDIT.EXE C:\date\hexedit.exe
   HEXEDI~1.GZ C:\date\hexedit-0_9_7_tar.gz

   Из примера видно, что у файла HEX-EDIT.EXE после его изменения опять установлен атрибут «Архивный». Хорошей возможностью команды attrib является переключатель /s, который позволяет обработать файл с указанными именами в текущей директории и во всех ее поддиректориях. После этого можно воспользоваться командой dir /a: a (вывод файлов с указанным атрибутом a — файлы для архивирования) для просмотра измененных файлов.
Исследование контрольных сумм и кэш-значений
   Одна из центральных проблем обеспечения безопасности заключается в определении факта изменения файла. Можно ли при этом доверять атрибутам файлов? Атрибуты файлов можно фальсифицировать. Довольно несложно установить нужные значения атрибутов файлов: размер файла, дата и время последней модификации. Большинство приложений это не делает, но иногда вирусы, Троянские кони или программы типа rootkit могут изменять их для скрытия своего присутствия. Противостоять этому позволяют алгоритмы подсчета контрольных сумм и криптографического кэширования.
   Алгоритмы подсчета контрольных сумм, например алгоритмы контроля с помощью циклического избыточного кода CRC (CRC – cyclical redundancy check), легко фальсифицируются, если злоумышленник или его программа знает используемый для контроля файлов алгоритм. Поэтому вместо контрольных сумм рекомендуется использовать криптографически стойкие алгоритмы кэширования. Важная особенность алгоритмов кэширования состоит в том, что возможность получения для двух различных кэшируемых файлов одной и той же величины кэш-значения ничтожно мала. Практически невозможно подменить один файл другим с той же самой величиной кэш-значения. Величина кэш-значения – это обычно 128-битовое или 160-битовое двоичное число, для хранения которого требуется значительно меньше места, чем для кэшируемого файла.
   Алгоритмы кэширования позволяют определить модификацию файла, несмотря на все попытки скрыть это. Для каждого контролируемого файла вычисляется величина кэш-значения до и после некоторого события. Если эти две величины различаются, то файлы были изменены, несмотря на то что атрибуты файлов остались прежними.
   Очевидно, этот метод имеет хорошие перспективы для обеспечения безопасности систем. Чтобы быть совершенно точным, автор должен частично отречься от своего утверждения, что при помощи алгоритмов кэширования можно определить изменения файлов, выполненные программами типа root kit. Они позволят определить изменения файлов, выполненные при помощи наивных программ этого типа. Действительно, хорошая программа типа root kit, предполагая о возможности кэширования, вынуждает операционную систему работать с разными файлами в разное время. Например, при чтении файла (кстати говоря, программой кэширования), измененная операционная система передает реальный исходный файл. При запросе на выполнение выполняется модифицированный файл.
   Примеры подобной технологии можно найти на сайте rootkit.com в разделе «EXE Redirection» («Переадресация выполнимых файлов»). Этот сайт посвящен разработке открытых исходных текстов программ типа root kit для NT.

Другие инструментальные средства

   В конечном счете цель хакера заключается во внесении в программу изменений, которыми можно управлять. Если цель заключается в увеличении золотого запаса игрока в описанной ранее игре, то вполне возможно, что хакер захочет сделать это без использования поиска различий. Возможно, он не имеет ничего против использования шестнадцатеричных редакторов, хотя может и не использовать их. Если это так, то, возможно, он хотел бы расширить свой арсенал используемых инструментальных средств.
   Если хакер когда-либо занимался программированием, то наверняка он захочет воспользоваться каким-нибудь средством или языком программирования. Как и в случае редакторов, выбор средств программирования – дело очень личное и субъективное. Сгодится любой язык программирования с полным набором функций, который позволяет получить доступ к любым файлам или адресам памяти. Если злоумышленнику потребуется доступ к специальным файлам, например к реестру Windows (Windows Registry), ему потребуется язык программирования, который предоставляет средства работы с ними. В случае реестра Windows это может быть компилятор языка C с соответствующими библиотеками, предоставляющими программный интерфейс приложения API (API – application programming interface), ActiveState Perl for Windows и, возможно, многие, многие другие. Те, кто заинтригован, могут найти ActiveState Perl for Windows в Интернете по адресу www.activestate.com/Products/ActivePerl/index.html.
   Программа Game Wizard 32 была создана во время господства DOS на рынке компьютерных игр. Эта программа предоставляет игрокам ряд дополнительных возможностей, но сейчас будет рассказано только об одной из них, относящейся к теме обсуждения. Эта программа обладает возможностью поиска различий для игр. Это резидентная программа, постоянно присутствующая в оперативной памяти после ее запуска. После старта Game Wizard 32 можно начинать игру. В процессе игры игрок записывает на свой счет некоторые величины (набранные очки, золотой запас, запас энергии и т. д.), изменяя параметры игры. В результате будет составлен список найденных параметров игры (list of matches). Затем, после изменения параметров игры, можно еще раз просмотреть список, найти различия, отредактировать их и возобновить игру с новыми параметрами.
   В настоящее время большинство игроков называет подобные игры тренерами или редакторами памяти. Принцип их работы аналогичен рассмотренному ранее принципу работы с файлами. Широкий диапазон программ этого класса может быть найден по адресу http://gamesdomain.telepac.pt/directd/pc/dos/tools/gwiz32.html.
   Другие инструментальные средства, которые могут оказаться чрезвычайно полезными при работе в Windows, – это программы File Monitor (FileMon) и Registry Monitor (RegMon) компании Sysinternals. Если читатель работает с NT, то пусть он попробует программу HandleEx, которая предоставляет похожие возможности. Сайт компании находится по адресу www.sysinternals.com. На сайте много полезных утилит, большинство из которых свободно распространяются вместе с исходными текстами.
   FileMon – программа, которая позволяет отслеживать обращение различных программ к файлам и их работу с файловой системой (чтение, запись, изменение атрибутов и т. д.), как это показано на рис. 5.13.
   Рис. 5.13. Отчет программы FileMon

   Применяя фильтрование, можно узнать о действиях выбранной для анализа программы, сократив объем выводимой информации. Обратите внимание, что при фильтрации во время чтения файла отображаются смещение и длина читаемых данных, что помогает определить их адрес в файле. Таким образом, программа FileMon предоставляет еще один способ сокращения списка просматриваемых файлов.
   RegMon – другая программа компании Sysinternals. Как и следовало ожидать, она аналогична FileMon, но работает с реестром Windows, как это показано на рис. 5.14.
   Рис. 5.14. Отчет программы RegMon

   Во время подготовки этого примера автор слушал приложение Spinner с сайта spinner.com, который использует Real Audio для воспроизведения музыки. Во время своего выполнения Real Audio находится в состоянии «занято». В строчке с номером 472 можно увидеть работу протокола динамической конфигурации хоста DHCP (DHCP – Dynamic Host Configuration Protocol). Протокол динамической конфигурации хоста является сетевым стандартом, регламентирующим процесс присваивания сервером IP-адресов и другой конфигурационной информации машинам-клиентам. Программа RegMon особенно полезна для проверки подозрений о записи приложением чего-либо интересного где-нибудь в потаенном местечке реестра или при попытке определить действия Троянского коня. Программа также информирует при копировании и сравнении всего реестра в целом.

Поиск неисправностей

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

Проблемы контрольных сумм и кэширования

   Первое, с чем может столкнуться читатель, – это то, что вместе с файлом запоминается служебная информация: контрольная сумма или кэш-величина. В данном случае служебная информация предохраняет файл от несанкционированного изменения и представлена двоичными данными небольшой разрядности, которые описывают контролируемую часть файла. При поступлении запроса на чтение программа обрабатывает часть данных и получает контролирующую их величину. Обычно эта величина занимает от 4 до 20 байт и запоминается вместе с файлом.
   При чтении файла программа читает данные вместе с их контрольными суммами / кэш-величинами. Если вновь вычисленные величины совпали со старыми, то программа предполагает, что файл корректен. В противном случае программа, скорее всего, сообщит об ошибке, выдав приблизительно следующее диагностическое сообщение: «Файл некорректен».
   В некоторых случаях этот же самый механизм может быть применен разработчиком программного обеспечения для защиты своих данных. Во-первых, для обнаружения случайных повреждений файла данных. Некоторые приложения не смогут правильно обработать поврежденные данные. Во-вторых, как попытка предотвратить некоторые запрещенные действия со стороны пользователей приложения, начиная от попыток обмануть игру до изменения файлов паролей.
   Конечно, этот метод защиты не отвечает всем требованиям безопасности. Все, что нужно сделать злоумышленнику, – это определить используемый алгоритм подсчета контрольной суммы, или алгоритм кэширования, и выполнить те же самые действия, что и программа. Местонахождение кэш-величины в файле не является тайной, поскольку, наблюдая за изменениями в файле при определении местонахождения изменяемых величин, всегда найдется одна или несколько последовательностей постоянно изменяющихся байт. Одна из них и является контрольной суммой.
   Если исследователю неизвестен алгоритм вычисления контрольной суммы, то некоторые способы помогут ему определить его. Но, даже зная алгоритм вычисления контрольной суммы, потребуется дополнить выяснить, какая часть файла используется при подсчете контрольной суммы. Это можно узнать экспериментально. Если нет уверенности, какая именно часть файла используется для подсчета контрольной суммы, то измените в какой-либо части файла данные и попробуйте поработать с ним. Если в ответ получите сообщение о разрушении файла, то, вероятнее всего, эта часть файла используется для подсчета контрольной суммы.
   Даже не проводя анализа машинного кода или некоторых внешних признаков (например, сообщений программы о CRC32 ошибке), первые предположения об используемом алгоритме можно сделать, основываясь на количестве байт кэш-величины. Наиболее известный алгоритм подсчета контрольной суммы CRC32 вычисляет 32-битовую (четырехбайтовую) величину. Этот алгоритм подсчета контрольной суммы используется в ряде сетевых технологий. Примеры его программной реализации могут быть найдены повсеместно, только запустите поиск в Интернете. Например, подходящий пример может быть найден по адресу www.faqs.org/faqs/compression-faq/part1/section-26.html.
   Алгоритмы MD4 и MD5 (MD – сокращения от Message Digest – профиль сообщения. Профиль сообщения – это короткая цифровая строка фиксированной длины, формируемая из более длинного сообщения с использованием специального алгоритма) генерируют 128-битовую (16-байтовую) величину, а алгоритм SHA (SHA – Secure Hash Algorithm – алгоритм аутентификации и проверки целостности информации) – 160-битовую (20-байтовую) величину.
   Примечание
   Возможны любые изменения описанных в этой секции методов, если разработчик захочет усложнить жизнь хакеру. В худшем для хакера случае он сможет определить алгоритм, просмотрев выполнение программы в отладчике. Пример использования отладчика может быть найден в главах 4 и 8 книги.

Проблемы сжатия и шифрования

   Если проанализировать различия между исходным и сжатым или зашифрованным файлом (если используется качественный алгоритм преобразования файлов), то можно обнаружить изменение большого количества данных в файле. В начале главы автор приводил пример применения метода поиска различий для игры Heroes of Might and Magic II, хотя в то время уже продавалась игра Heroes of Might and Magic III. Дело в том, что, как кажется автору, в последней игре файлы сжимаются. Автор делает подобное предположение по следующим причинам. Во-первых, файл неразборчив (при просмотре файла не видно английских слов). Во-вторых, при сохранении игры каждый раз изменяется почти весь файл целиком, даже если между сохранением игры ничего не делается. В-третьих, с течением времени размер файла слегка изменяется. Поскольку размер сжатого файла зависит от его содержания, а размер зашифрованного файла имеет тенденцию оставаться постоянным при шифровании одинакового числа байт, то автор предполагает, что в данном случае используется сжатие вместо шифрования.
   Сжать файл можно ограниченным числом способов. Широкодоступны библиотеки сжатия, и большинство людей не будут писать собственные программы сжатия данных. В худшем случае, с точки зрения затрат времени и усилий, можно воспользоваться отладчиком или средством трассировки программ для определения алгоритма работы программы сжатия.
   В случае зашифрованных данных все сказанное выше остается в силе. За исключением того, что очень велики шансы написания разработчиком своей собственной программы «шифрования». Автор намеренно взял слово «шифрование» в кавычки, потому что большинство людей не сможет написать приличную программу шифрования (в том числе и автор). Поэтому, в случае применения собственной программы «шифрования», очень велики шансы, что ее взломают. Если же для шифрования файлов использованы настоящие криптографические алгоритмы, то и их можно расшифровать. Ведь программе требуется расшифровать зашифрованные файлы, поэтому нужно только узнать, как она это делает. Подробнее этот вопрос освещен в главе 6.

Резюме

   Поиск различий используется для определения места хранения паролей в приложениях или выяснения сути исправлений известных уязвимостей. Был рассмотрен пример патча в унифицированном формате различий и проанализирован его отчет.
   Для выявления различий используются различные программные средства, например команда fc операционной системы Windows или команда diff системы UNIX. Следует обратить внимание на шестнадцатеричные редакторы, работающие на различных платформах. Например, на редактор Hackman для операционной системы Windows. Инструментальные средства мониторинга файловой системы работают с группой файлов, разделом или логическим диском. В этой главе был обсужден трудоемкий способ контроля файловых систем: копирования всей файловой системы и выполнения пофайлового сравнения. В результате исследования структуры файловой системы ext2, обсужденной в этой главе, было рассказано о средствах идентификации модифицированных файлов: команде ls системы UNIX, команде dir MS-DOS. Команда dir, используя атрибут «Архивный» файловой системы FAT, позволяет найти модифицированные файлы. Контрольные суммы могут использоваться для контроля файлов от разрушения и несанкционированного изменения путем вычисления контрольной суммы и последующего их сравнения. Обратите внимание на то, что некоторые программы типа root kits могут обходить контрольные суммы.
   Известны и другие инструментальные средства, например ActiveState Perl, FileMon и RegMon. На ActiveState Perl можно писать собственные программные средства. Утилиты операционной системы Microsoft Windows FileMon и RegMon контролируют доступ приложений к файлам и реестру Windows соответственно. Обе утилиты разработаны компанией Sysinternals.
   В завершение были обсуждены возможные проблемы использования инструментария, описанного в главе. При создании систем безопасности следует учитывать возможность преодоления защиты на основе контрольных сумм и кэширования, если известно местоположение контрольных величин (контрольной суммы или кэш-величины) и метода их расчета. Было сказано несколько слов о проблемах сжатия и шифрования. Пояснено, почему нельзя найти место хранения контрольной суммы в зашифрованном или сжатом файле до тех пор, пока не будет обойден механизм защиты.

Конспект

Суть поиска различий
   · Поиск различий может использоваться для обнаружения изменения файла программным путем или выяснения сути исправления уязвимости.
   · Команда diff может быть применена для исследования содержимого директории путем сравнения входящих в нее файлов.
   · Исследование методом поиска различий может быть применено к исходным текстам программ и двоичным файлам.
Исследование инструментария поиска различий
   · В состав большинства операционных систем UNIX включена команда поиска различий diff. Для этих же целей в состав операционной системы Microsoft включена команда fc.
   · При отправке по почте открытых исходных текстов исправлений уязвимостей программ отправитель не всегда пересылает файл различий (diff-файл), который позволил бы исправить исходный текст программы и установить исправленную версию программы.
   · Шестнадцатеричный редактор позволяет редактировать двоичные файлы непосредственно, минуя приложение. Шестнадцатеричные редакторы доступны на многих платформах, например редактор Hackman для Windows или hexedit для UNIX.
   · Поскольку атрибуты файла легко фальсифицировать, не стоит на них полагаться при определении модифицированных файлов. Измененные файлы могут укрывать вирусы, Троянских коней или программ типа root kit. Один из способов недопущения этого заключается в использовании контрольных сумм или алгоритмов кэширования файлов, хранимых вместе с файлами.
   · В состав утилит мониторинга операционной системы Windows входят утилиты RegMon и FileMon.
Поиск неисправностей
   · Для защиты файлов применяются вычисление контрольных сумм, кэширование, сжатие и шифрование.
   · Основанная на контрольных суммах и кэшировании защита файлов может быть преодолена, если будет обнаружено место хранения контрольной суммы или кэш-величины и раскрыт алгоритм их вычисления. С помощью различных уловок можно определить, как вычисляется контрольная сумма. Но дополнительно к алгоритму ее вычисления нужно знать, на основе каких данных файла она рассчитывается.
   · До изменения контрольных сумм или кэш-величин следует выяснить примененные способы шифрования и сжатия. Число способов сжатия и шифрования файлов ограничено. Если программа расшифровывает файлы, то следует только узнать, как она это делает.

Часто задаваемые вопросы

   Ответ: Да. Она может быть получена из дистрибутива Cygwin, распространяемого Cygnus Solutions.

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

   Вопрос: Существует ли версия grep с возможностью рекурсивного построения отчета?

   Вопрос: Что, если я захочу для создания своих собственных программных средств использовать язык С вместо Perl?
   Ответ: У вас будет больше возможностей. В состав большинства открыто распространяемых UNIX-подобных операционных систем входит компилятор с языка С. Для операционной системы Windows можно порекомендовать DJGPP, который можно найти по адресу www.delorie.com/djgpp.

   Вопрос: Где можно найти другие свободно распространяемые утилиты?
   Ответ: Sourceforge.net имеет большое хранилище открытых программных средств. Кроме того, Freshmeat.net предоставляет машину поиска свободно доступного программного обеспечения.

Глава 6
Криптография

   В этой главе обсуждаются следующие темы:
   • Концепции криптографии
   • Стандарты алгоритмов шифрования
   • «Грубая сила»
   • Неверное использование алгоритмов шифрования
   • Любительская криптография
   · Резюме
   · Конспект
   · Часто задаваемые вопросы

Введение

   Ныне криптография используется всюду: при кэшировании паролей, шифровании почты, в протоколе IPSec виртуальных частных сетей (IPSec – комплект протоколов, предложенных IETF для передачи информации в виртуальных частных сетях. Он обеспечивает аутентификацию, проверку целостности и шифрование пакетов) и шифровании файловых систем. Одна из причин шифрования объясняется желанием обезопасить зашифрованные данные. Обеспечить безопасность данных можно только в том случае, если понимать принципы работы криптографических алгоритмов. Материала, изложенного в этой главе, недостаточно для профессионального изучения криптографии. Для этого нужны годы. Но его хватит для понимания, как использовать криптографические функции (конечно, без изучения их сложного математического обоснования).
   В главе будет бегло рассмотрена история криптографии и изучены популярные криптографические алгоритмы, включая улучшенный стандарт шифрования AES, недавно принятый США для защиты важной информации на правительственном уровне. Будут рассмотрены причины широкого использования криптографии с открытым ключом и обмена ключами, а также вопросы их использования на практике. Будет показана теоретическая уязвимость практически всех криптографических алгоритмов к атаке «грубой силы» (атаки в лоб).
   Попутно с рассмотрением возможностей криптографической защиты будет рассмотрено восстановление зашифрованных сообщений на примере взлома паролей и атак «злоумышленник посередине» (man-in-the-middle-type attacks). Также будут рассмотрены атаки, позволяющие разрушить систему защиты, основанную на плохой реализации криптостойких алгоритмов. В заключение будет показан способ легкого взлома устаревших криптографических алгоритмов.

Концепции криптографии

   Что означает слово крипто ? Оно происходит от греческого слова «криптос» – скрытый. Поэтому целью криптографии является скрытие сути информации от посторонних лиц таким образом, чтобы с ней мог ознакомиться только тот, кому она предназначена. В терминах криптографии скрытие информации называется шифрованием, а ее чтение – расшифрованием, или дешифрованием. Словарь Merriam-Webster's Collegiate Dictionary определяет шифр как «метод преобразования текста для скрытия его значения». Информация, которая подлежит скрытию, называется открытым (незашифрованным) текстом (plaintext), а зашифрованные данные – зашифрованным текстом (ciphertext). Зашифрованное сообщение можно передавать, не опасаясь, что его сможет прочитать кто-либо, кроме получателя. А тот, кому оно предназначено, всегда сможет расшифровать его.

Историческая справка

   Фред Кохен (Fred Cohen) предал гласности документально подтвержденные факты использования криптографии в Древнем Египте более 4000 лет тому назад. Юлий Цезарь (Julius Caesar) использовал свой собственный способ шифровки писем, который получил название шифра Цезаря. Идея шифра Цезаря заключалась в замене каждой буквы на третью букву далее по алфавиту. Например, S заменялась на букву V, а E – на H. По современным меркам шифр Цезаря слишком прост, но он хорошо служил Цезарю в его дни. Читателю, желающему углубить свои знания по истории криптографии, автор рекомендует посетить сайт www.all.net/books/ip/Chap2-1.html.
   Подобный шифру Цезаря алгоритм ROT13 (алгоритм сдвига символов на 13 позиций английского алфавита – примитивный способ скрытия электронных посланий от посторонних глаз) используется в системах UNIX до сих пор. Он не годится для хранения секретов в тайне. Алгоритм ROT13 больше подходит для скрытия решений ребусов, шуточных посланий и потенциально оскорбительного текста. Если же подобный текст будет расшифрован, то ответственность за возможно нанесенную обиду ляжет не на отправителя, а на того, кто расшифровал его. Например, мистер G. может получить приведенное ниже сообщение, расшифровав которое он, возможно, оскорбится. Но в зашифрованном виде сообщение никого обидеть не может: V guvax Jvaqbjf fhpxf.
   Алгоритм ROT13 очень прост, для того чтобы с ним можно было работать с карандашом в руке и листком бумаги. Достаточно написать алфавит в два ряда со смещением второго ряда на тринадцать букв относительно первого:

   ABCDEFGHIJKLMNOPQRSTUVWXYZ
   NOPQRSTUVWXYZABCDEFGHIJKLM

Типы криптосистем

   В криптографии используется два типа криптосистем: симметричные и асимметричные. В симметричных криптосистемах используются более длинные ключи, причем один и тот же ключ используется как для зашифровки, так и для расшифровки текста. Такой ключ называется секретным ключом, и его следует хранить в тайне из-за того, что любой владелец секретного ключа может расшифровать данные, зашифрованные этим же ключом. Большинство симметричных криптосистем используются много лет и хорошо известны. Единственное, что действительно является тайной, – это используемый ключ. Практически все действительно полезные алгоритмы, применяемые на практике сегодня, полностью открыты обществу.
Инструментарий и ловушки…
   Оценка криптостойкости алгоритма
   Проверить алгоритмическую безопасность криптографического алгоритма можно, только атакуя его. Поскольку намного чаще подвергаются атаке криптографические алгоритмы, опубликованные в открытой печати, то чем дольше алгоритм доступен для всеобщего изучения, тем больше будет предпринято попыток перехитрить или взломать его. Ненадежные криптографические алгоритмы взламываются очень быстро, обычно за несколько дней или месяцев, в то время как криптостойкие алгоритмы шифрования могут десятилетиями оставаться неприступными. В любом случае, открытость алгоритма для публичного анализа – важное условие доказательства его безопасности. Хотя если отсутствуют какие-либо сведения о сложности используемых в криптосистеме алгоритмов, то взломать криптосистему сложнее (вне зависимости от криптостойкости используемых в ней алгоритмов). Но при использовании общеизвестного алгоритма всегда есть некоторые предположения относительно его безопасности. Отчасти взлом алгоритма противоречит праву собственности на него. Однако слабый алгоритм может быть взломан, даже если криптограф до конца его и не понял. Очевидно, следует доверять запатентованным алгоритмам только в рамках их долгосрочных обязательств. Именно из-за необходимости тщательного изучения внутреннего устройства алгоритмов для обеспечения их безопасности многие из применяемых на практике запатентованных алгоритмов, как, например, RC6 компании RSA Laboratories, общедоступны.
   Применению симметричных криптографических алгоритмов присущ ряд проблем. Во-первых, где гарантия, что отправитель и получатель используют один и тот же ключ для зашифровки и расшифровки сообщений? Обычно для обеспечения идентичности ключей отправителя и получателя пользуются услугами курьерской службы или каким-либо другим средством пересылки ключей. Во-вторых, что делать, если у получателя не окажется ключа, которым были зашифрованы принимаемые данные? Например, представьте себе ситуацию, когда ключ симметричной криптосистемы, реализованной аппаратными средствами, изменяется каждое утро в 4.00 на приемном и передающем конце. Что произойдет, если на одном из концов «забудут» изменить ключ в нужное время (вне зависимости от того, как это будет реализовано: при помощи полоски ленты, дополнительной аппаратуры или каким-либо другим способом) и передадут зашифрованные старым ключом данные, а на приемной стороне ключ будет изменен? Получатель, используя правильный ключ, не сможет расшифровать принятые данные. В результате во время кризиса могут возникнуть проблемы. Особенно если старый ключ был удален. Этот простой пример показывает, к чему может привести использование получателем и отправителем разных ключей шифрования.
   Асимметричные криптосистемы – относительно новое направление в криптографии, возможно, более известное под синонимом криптография с открытым ключом. В асимметричных криптосистемах используются два различных ключа: открытый ключ – для зашифровки сообщения и секретный (личный) – для расшифровки. Уитфилд Диффи (Whitfield Diffie) и Мартин Хеллман (Martin Hellman) первыми заявили о криптографии с открытым ключом в 1976 году, опубликовав метод обмена ключами в системе с секретными ключами. Опубликованный ими алгоритм, впоследствии названный алгоритмом Диффи-Хеллмана (DH-алгоритмом), будет рассмотрен в этой главе. Хотя большинство считает В. Диффи и М. Хеллмана авторами криптографии с открытым ключом, тем не менее некоторые отдают приоритет английской разведке BSS (British Secret Service), поскольку якобы за несколько лет до публикации В. Диффи и М. Хеллмана BSS уже знал об аналогичном методе. Правда, предполагается, что BSS после изобретения алгоритма нигде его не использовал. Подробнее об этом читатель сможет узнать по адресу: www.wired.com/wired/archive/7.04/crypto_pr.html.
   Некоторое время спустя криптография с открытым ключом стала популярной благодаря Филу Зиммерману (Phil Zimmerman), который в августе 1991 года выпустил версию 1.0 программы «Pretty Good Privacy» (PGP) для DOS. В 1993 году, после выпуска версии 2.3 программы PGP, была добавлена поддержка других платформ, в том числе UNIX и Amiga. С течением времени программа PGP была усовершенствована и распространялась многочисленными фирмами, включая ViaCrypt и PGP, Inc., которые в настоящее время вошли в состав Network Associates. Доступны как коммерческие, так и свободно распространяемые (для некоммерческого использования) версии программы PGP. Жители Соединенных Штатов и Канады могут получить свободно распространяемую версию программы с сайта http://web.mit.edu/network/pgp.html. Коммерческая версия может быть куплена на сайте Network Associates www.pgp.com.

Стандарты алгоритмов шифрования

   Почему так много алгоритмов шифрования? Почему не стандартизируют один из них? Учитывая большое количество алгоритмов шифрования, следует признать, что на этот вопрос нельзя дать простой ответ. Максимум, что возможно, – это достичь компромисса между безопасностью, скоростью и удобством применения. В данном случае под безопасностью алгоритма понимается его способность противостоять как современным атакам, так и атакам в будущем. Скорость алгоритма характеризует его возможности по обработке данных и выражается временем, которое необходимо затратить на зашифровку и расшифровку сообщений. И наконец, под удобством применения понимается удобство реализации алгоритма программным или аппаратным способом. Каждый алгоритм хорош по-своему и ни один из них не идеален. В этой главе будут рассмотрены пять алгоритмов, с которыми чаще всего приходится иметь дело: стандарт шифрования данных DES (Data Encryption Standard), улучшенный стандарт шифрования AES [Rijndael], международный алгоритм шифрования данных IDEA (International Data Encryption Algorithm), алгоритм Диффи-Хеллмана и алгоритм RSA. Но знайте, что есть и другие алгоритмы, которые ничем не уступают названным.

Симметричные алгоритмы

   В этой секции будет рассмотрено несколько наиболее типичных представителей класса симметричных алгоритмов: DES, его преемник AES и Европейский стандарт IDEA. Имейте в виду, что криптостойкость симметричных алгоритмов определяется прежде всего размером используемых в алгоритме ключей и числом циклов алгоритма. Все симметричные алгоритмы теоретически уязвимы к атакам «грубой силы», в основе которых лежит перебор всех возможных ключей. Но часто подобные атаки технически неосуществимы. Детально они будут обсуждены далее в главе.
Алгоритм DES
   Стандарт шифрования данных (алгоритм) DES – один из старых и наиболее известных алгоритмов шифрования, который был изобретен корпорацией IBM и был американским правительственным стандартом с 1976 до 2001 года. В значительной степени DES основан на алгоритме Люцифер (Lucifer) Хорста Фейстеля (Horst Feistel), который не получил широкого распространения. Существенно то, что в алгоритме DES используется единственный 64-битовый ключ: 56 бит значащие и 8 бит – проверочные биты для контроля на четность. Алгоритм обрабатывает блоки данных порциями по 64 бита. Ключ разбивается на 16 отдельных 48-битовых подключей по одному на каждый раунд, который называется циклом Фейстеля (Feistel cycles). На рисунке 6.1 показана схема работы алгоритма DES.