Максимальная Безопасность:

Руководство Хакера по Защите Вашего Internet Сайта и Сети

Предыдущая главаСледующая главаСодержание

15

Дыра

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

Концепция Дыры

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

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

ПРИМЕЧАНИЕ: Только два связанных с применением компьютеров элемента когда-либо считались полностью свободными от дыр (по крайней мере по стандартам национальной безопасности). Один это процессор Gemini, изготовленный Gemini Computers. Он был оценен классом A1 в Списке Оцененных Программ NSA. Он сопровождается только одним другим продуктом в этом классе: Boeing MLS LAN (Версия 2.1). Проверьте оба продукта на
http://www.radium.ncsc.mil/tpep/epl/.

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

Масштаб Уязвимости

Существуют различные типы дыр, включая

Эти типы дыр и нападений могут быть классифицированы по опасности, которую они представляют узлу жертвы. Некоторые представляют существенную опасность, и могут уничтожить адресата. Другие менее серьезны, квалифицируясь только как неприятности. Рисунок 15.1 показывает своего рода "Шкалу Internet Richter" для измерения опасности различных типов дыр.

Индекс дыр: опасности, которые дыры могут представлять
Рисунок 15.1. Индекс дыр: опасности, которые дыры могут представлять.

Дыры, Которые Позволяют Отказ в Обслуживании

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

Для больших сетей или сайтов, нападение отказ в обслуживании имеет только ограниченное значение. Оно приносит неприятность и не больше. Однако более мелкие сайты могут пострадать от нападения отказ в обслуживании. Это особенно так, если сайт поддерживает только единственную машину (и поэтому, единственный почтовый сервер или сервер новостей). Глава 3, "Хакеры и Взломщики", и 8, "Война в Internet", содержат примеры нападений отказ в обслуживании. Они происходят чаще всего в форме нападений подобных syn_flooding. Превосходное определение нападений отказ в обслуживании даётся в популярном документе названном "Protecting Against TCP SYN Denial of Service Attacks" ("Защита Против TCP SYN Нападения Отказ в Обслуживании"):

Нападения отказ в обслуживании это класс нападений, в которых один или несколько людей эксплуатируют аспекты набора Internet Протоколов, чтобы лишить других пользователей законного доступа к системам и информации. TCP SYN нападение это то, в котором серверу в большом объеме посылаются запросы на подключение, вызывая его перегрузку. Результат, медленный или недостижимый сервер, и расстроенные клиенты.
Ссылка: Проверьте "Protecting against TCP SYN Denial of Service Attacks" в онлайне на
http://www.proteon.com/docs/security/tcp_syn.htm.

Нападение syn_flooder провоцируется, создавая высокое число полуоткрытых подключений. Поскольку каждое подключение открылось, оно должно быть обработано окончательно (в этом случае, превышение времени), система временно захлебывается. Это проблема присуща проекту набора протоколов TCP/IP, и которую не так легко исправить. Как отмечает CERT консультация по этому вопросу:

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

Эта дыра находится в сердце сетевых служб операционной системы UNIX (или почти любой операционной системы, выполняющей полноценный TCP/IP по Internet). Таким образом, хотя прилагаются усилия, чтобы исправить это, я не классифицировал бы эту дыру как высокоприоритетную. Это так, потому что почти во всех случаях нападения отказ в обслуживании не представляют никакого риска проникновения. То есть взломщики не могут повредить данные или получить неавторизованные уровни привилегий через эти средства. Они могут только создать себе неприятности.

Ссылка: Хорошие статьи, доступные в Сети, могут дать Вам более ясное представление того, что такое нападение отказ в обслуживании. Одна из них "Security Problems in the TCP/IP Protocol Suite" ("Проблемы Безопасности в Наборе Протоколов TCP/IP") от Steve Bellovin, которая появилась в Обзоре Компьютерных Коммуникаций (Компьютерном Обзоре Связи) в апреле 1989. Найдите её на
ftp://research.att.com/dist/internet_security/ipext.ps.Z.

Хотя UNIX известна своей уязвимостью нападениям отказ в обслуживании, другие платформы не свободны от этого. Например, как я буду обсуждать в Главе 16, "Microsoft", можно привести к зависанию некоторые дистрибутивы NT простым Telnet запросом к конкретному порту и выдачей нескольких простых символов. Это вынуждает ЦПУ быть на 100 процентов загруженным, таким образом выводя из строя машину в целом.

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

Например предположим, что я чувствую неприязнь к пользователям Netscape Navigator. (Не смейтесь. Есть такие люди. Если Вы когда-либо приземлялись на их страницах, то знаете это.) Используя или Java или JavaScript, я могу эффективно предпринять следующие действия:

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

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

Меньше чем за 40 секунд целевая машина зависла бы. (О да, с больше чем 64МБ ОЗУ она могла бы выжить достаточно долго, чтобы пользователь смог завершить процессы. Тем не менее, средний пользователь был бы вынужден перезагрузиться.) Это вызвало бы то, что мы технически классифицируем как нападение отказ в обслуживании.

Ссылка: Одна хорошая ссылка относительно нападений отказ в обслуживании это "Hostile Applets on the Horizon" ("Враждебные Апплеты на Горизонте") от Mark D. LaDue. Этот документ доступен на
http://www.math.gatech.edu/~mladue/HostileArticle.html.

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

ПРИМЕЧАНИЕ: Не каждое нападение отказ в обслуживании должно быть выполнено по Internet. Имеются много типов нападений отказ в обслуживании, которые происходят на локальном уровне, возможно даже не в сетевой среде. Хороший пример это известное нападение отказ в обслуживании блокировка файла, которое работает на платформе Microsoft Windows NT. Типовой код для этого нападения был широко распространён в списках рассылки по безопасности. Код (когда откомпилирован) приводит к программе, которая берет любой файл или программу как параметр командной строки. Этот параметр командной строки является целевым файлом, который Вы желаете заблокировать. Например, это может быть WINWORD.EXE или даже файл DLL. Файл останется полностью заблокированным (недоступным любому пользователю) в течение отрезка времени, указанного взломщиком. В течение этого периода никто, даже администратор, не может использовать файл. Если взломщик установил период времени как неопределенный (или скорее, эквивалент этого), единственный способ снять блокировку полностью уничтожить сессию этого пользователя. Такая блокировка программы также работает на разделенных дисках.

Одно особенно раздражающее нападение отказ в обслуживании (которое включено во многие программы взлома для Windows 95) страшное нападение CHARGEN. CHARGEN это служба, которая выполняется на порту 19. Это знакогенератор (следовательно, имя), используемый, прежде всего в отладке. Многие администраторы используют эту службу, чтобы определить, отбрасываются ли пакеты или где эти пакеты исчезают перед завершением данной TCP/IP транзакция. В любом случае, инициализируя множество запросов к порту 19, нападающий может вызвать нападение отказ в обслуживании, приводящее к зависанию машину.

Дыры, Которые Позволяют Локальным Пользователям Неавторизованный Доступ

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

ПРИМЕЧАНИЕ: На Рисунке 15.1 я указываю на незатененный файл passwd как возможную проблему класса B, и по правде говоря, это так. Тем не менее, это не проблема приложения. Существует множество таких неприкладных проблем, но они отличаются от бескомпромиссных дыр класса B. Здесь, бескомпромиссные дыры класса B это те, которые содержатся в фактическом коде конкретного приложения. Следующий пример поможет проиллюстрировать различие.

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

sendmail

Прекрасный пример дыры, которая позволяет локальным пользователям получать увеличенный и неавторизованный доступ, известна как проблема sendmail. Sendmail возможно наиболее популярный метод передачи электронной почты. Это основа системы электронной почты Internet. Как правило, эта программа инициализируется как демон во время загрузки и остается активной, пока активна машина. В своем активном состоянии sendmail слушает (на порту 25) запросы на доставку или другие запросы из пустоты.

Когда sendmail стартует, она обычно делает запрос, чтобы определить личность пользователя, потому что только root уполномочен выполнять запуск и обслуживание программы sendmail. Другие пользователи с эквивалентными привилегиями могут делать это, но только в некоторой степени. Однако согласно консультации CERT, озаглавленной "Sendmail Daemon Mode Vulnerability" ("Уязвимость Режима Демона Sendmail"):

К сожалению, из-за ошибки кодирования, sendmail может быть вызвана в режиме демона способом, который обходит встроенную проверку. Когда проверка обойдена, любой локальный пользователь способен запустить sendmail в режиме демона. Кроме того, с версии 8.7, sendmail перезапускает себя, когда получает сигнал SIGHUP. Она делает операцию перезапуска непосредственным использованием системного вызова exec(2). Перезапуск делает её корневым пользователем. Управляя средой sendmail, пользователь затем может программой sendmail выполнять произвольную программу с корневыми привилегиями.

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

Ссылка: Для информации о некоторых обще известных дыр sendmail, проверьте
http://info.pitt.edu/HOME/Security/pitt-advisories/95-05-sendmail-vulnerabilities.html
и http://www.crossroads.fi/~tkantola/hack/unix/sendmail.txt.

Более старые версии sendmail содержат слабость в буфере (Вы узнаете немного о сценарии буфер/стек в следующих параграфах). Можно было взломать систему, вызывая опцию debug в sendmail и переполняя буфер. Это делалось опцией -d. Подобная проблема всплыла относительно связи sendmail с демоном syslog (другая проблема переполнения буфера).

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

ПРИМЕЧАНИЕ: Дыры в программах подобных sendmail особенно существенны, потому что эти программы доступны всем пользователям в сети. Все пользователи должны иметь, по крайней мере, основные привилегии, чтобы использовать программу sendmail. Если бы они не имели их, то не смогли бы посылать почту. Поэтому, любая ошибка или дыра в sendmail очень опасны.

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

B Класс Дыр

Большинство дыр класса B является результатом некоторого дефекта в приложении. Существуют некоторые довольно общие ошибки программирования, которые ведут к таким дырам. Одна такая ошибка касается символьного буфера в программах, написанных на C (следовательно, боящихся переполнения буфера). Переполнение буфера определено в Файле Жаргона как

Что случается, когда Вы пробуете внести в буфер (область хранения) больше данных, чем он может вместить. Это может быть следствием несовпадения в показателях создания и поглощения процессов (смотрите превышение и синдром пожарного рукава), или потому что буфер просто слишком мал, чтобы вместить все данные, которые должны накопиться перед тем, как часть их сможет быть обработана.
Ссылка: Файл Жаргона это широкая коллекция определений, которые охватывают странные и красочные термины, используемые в компьютерном жаргоне или слэнге (техноязыке). Все новые пользователи Internet должны просмотреть Файл Жаргона, потому что он содержит значения многих акронимов и других слэнговых терминов, упоминаемых в группах новостей Usenet и общих областях обсуждения в Internet. Хорошая HTML версия Файла Жаргона расположена на
http://nmsmn.com/~cservin/jargon/alpha.html.

Вместо исчерпывающего освещёния темы переполнения буфера, я кратко опишу эту проблему. Цель этого объяснения состоит в том, чтобы познакомить Вас с довольно изобретательной методикой получения неавторизованного доступа. Я надеюсь сделать это без бесконечного исследования языка C (C охвачен более интенсивно в Главе 30, "Язык, Расширения и Безопасность").

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

char first_name[20];

он даёт пользователю 20 символов для имени. Но предположим, что имя пользователя имеет 35 символов. Что случится с последними 15 символами? Они переполняют символьный буфер. Когда это переполнение происходит, последние 15 символов помещаются куда-нибудь в память, по другому адресу (адрес, который программист не намеревался пользовать для этих символов). Взломщики, манипулируя этими дополнительными символами, могут заставить операционную систему выполнить произвольные команды. Чаще всего эта методика используется локальными пользователями, чтобы получить доступ к корневой оболочке. К сожалению многие общие утилиты восприимчивы к нападениям переполнения буфера.

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

ПРИМЕЧАНИЕ: Отказ включить проверку на переполнение буфера вызывает некоторые проблемы, которые я уже обсудил, типа дыр sendmail.

Проблема переполнения буфера не нова. Она существует, по крайней мере, начиная с дней Червя. Eugene Spafford, как я уже отмечал, был одним из первых людей, которые проводили целеустремленный анализ Червя. Он сделал это статье, известной теперь как "The Internet Worm: An Analysis" ("Internet Червь: Анализ"). Статья Spafford'а несомненно лучший источник информации о Черве.

На странице 4 этого документа Spafford наблюдает, что Червь Морриса эксплуатирует уязвимость в демоне fingerd (демон, который слушает и удовлетворяет finger запросы, направленные к порту 79). Программа fingerd использовала общую для языка C функцию известную как gets(), которая выполняет простую задачу чтения следующей строки ввода. Функция gets() не проверяет границы, или ввод, который может потенциально превысить буфер. Таким образом, Моррис был способен переполнить этот буфер и по сообщениям поместить другой код в стек. Этот код обеспечивал Червя необходимым системным доступом. Spafford наблюдал, что эта уязвимость была известна в сообществах программирования, даже тогда. Далее он объясняет, что функции, которые не в состоянии проверить потенциальное переполнение, не должны использоваться. Все равно даже сегодня программы пишутся с теми же самыми основными недостатками, которые позволили Червю путешествовать так далеко и так быстро.

Дыры, Которые Позволяют Удаленным Пользователям Неавторизованный Доступ (Класс A)

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

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

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

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

Вероятно наиболее знаменитая дыра такого рода это уязвимость в файле с именем test-cgi, распространяемого с ранними версиями дистрибутива Web Сервера Apache. Этот файл содержал недостаток, который разрешал вторгшимся из пустоты читать файлы из каталога CGI. Если ваш файл test-cgi содержит следующую строку, Вы вероятно уязвимы: 

echo QUERY_STRING = $QUERY_STRING

Как отмечено в статье озаглавленной "Test-CGI Vulnerability in Certain Setups" ("Test-CGI Уязвимость в Некоторых Установках"):

Все эти строки должны заключать переменные в кавычки ("). Без этих кавычек некоторые специальные символы (особенно '*') расширяются, где они не должны. Таким образом передача запроса '*' возвратит содержимое текущего каталога (вероятно, где находятся все cgi файлы).
Ссылка: Найдите "Test-CGI Vulnerability in Certain Setups" в онлайне на
http://www.sec.de/sec/bug.testcgi.

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

Test-CGI в дистрибутиве Apache 1.1.1 уже имеет требуемое: 
echo QUERY_STRING = "$QUERY_STRING"
Однако он не имеет необходимости кавычек вокруг строки 
"$CONTENT_TYPE"
Поэтому это всё ещё уязвим в своей заданной по умолчанию конфигурации.
Ссылка: Предыдущий параграф это выдержки из статьи озаглавленной "Vulnerability in Test-CGI" ("Уязвимость в Test-CGI") от Joe Zbiciak. Она может быть найдена в онлайне на
http://geek-girl.com/bugtraq/.

Проблемы подобные этой общие. Например, один HTTP сервер на платформе Novell включает типовой сценарий с именем convert.bas. Сценарий, написанный на БЕЙСИКЕ, позволяет удаленным пользователям читать любой файл в системе.

Эта проблема иногда включает больше чем только типовой сценарий. Иногда она включает способ, которым сценарии интерпретируются. Например, версия 1.0 Информационного Сервера Internet Microsoft (IIS - Internet Information Server) содержит дыру, которая позволяет любому удаленному пользователю выполнять произвольные команды. Проблема состоит в том, что IIS HTTP связывает все файлы с расширением *.bat или *.cmd с программой cmd.exe. Как объясняется Julian Assange (автором Strobe), проблема не ограничивается IIS:

Во-первых ошибка позволяет пользователю обращаться к любому файлу в том же самом раздле, где находится ваш каталог wwwroot (предположим, что IIS_user имеет разрешение читать этот файл). Это также позволяет выполнять любой исполняемый файл в том же самом разделе, где находится ваш каталог сценариев (предположим, что IIS_user имеет разрешение выполнять этот файл). Если cmd.exe файл может быть выполнен, тогда это также позволяет Вам выполнять любую команду и читать любой файл в любом разделе (предположим, что IIS_user имеет разрешение читать или выполнять этот файл) ... . К сожалению серверы Netscape Communication и Netscape Commerce имеет подобные ошибки. Подобные вещи могут быть сделаны с Сервером Netscape, если он использует BAT или CMD файлы как CGI сценарии.

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

ПРИМЕЧАНИЕ: Чтобы быть справедливым, большинство UNIX реализаций HTTPD предусматривает регистрацию IP адреса запроса. Однако, даже учитывая этот факт, идентифицирование фактического преступника может быть трудной задачей. Например, если нападавший исходил из AOL, запрос будет исходить с одной или нескольких proxy машин AOL в Reston, Виржиния. Существовали бы сотни потенциальных подозреваемых. Использование ACCESS.LOG для прослеживания взломщика плохая замена более полной регистрации и имеет реальное значение только, когда нападение исходило от маленького локального ISP.

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

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

ПРИМЕЧАНИЕ: Пользователи Microsoft не могут рассчитывать на Microsoft в немедленном просвещёнии пользователей относительно потенциальных проблем. По моему мнению, внос Microsoft в опубликовании дыр был очень слабым. Она, кажется, делает так только после того, когда так много людей узнают о дыре, что нет другого выбора, чем подтвердить ее. В то время как дыра всё ещё неясна, персонал Microsoft непреклонно отрицает существование недостатка. Эта ситуация только теперь меняется, потому что сообщество хакеров (не взломщиков) назвало это обманом и инициализировало процесс демонстрации всех дыр, свойственных платформе Microsoft.

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

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

Чтобы продемонстрировать эту мысль, я обращусь к проблеме переполнения буфера. Как сообщено в 1995 консультации по уязвимости в NCSA HTTPD (один из наиболее популярных в мире пакетов Web сервера):

В NCSA httpd Релиз 1.3 недавно (2/17/95) была обнаружена уязвимость. Была опубликована программа, наряду с пошаговыми инструкциями, которая врывается в систему HP, выполняющую прекомпилированный httpd. Программа переполняет буфер в пространство программы, которая затем выполняется.
Ссылка: Предыдущий параграф это выдержка из статьи Elizabeth Frank. Она может быть найдена в онлайне на
http://ernie.sfsu.edu/patch_desc.html.

Согласно консультации CERT ("NCSA HTTP Daemon for UNIX Vulnerability" - "NCSA HTTP Демон для Уязвимости UNIX") следует:

Удаленные пользователи могут получить неавторизованный доступ к учётной записи (uid) под которой выполняется процесс httpd.

Как объяснено в Главе 9, "Сканеры", многие люди невольно выполняют HTTPD как root. Таким образом, эта уязвимость обеспечивает удаленным пользователям корневой доступ на ненадлежащим образом сконфигурированные Web сервера.

Другие Дыры

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

В дополнение к этим программам, имеющим дыры класса A, все из них также имели дыры класса B. Кроме того, в категории класса B, множество других программ, которые я не упомянул, имели дыры. Наконец, большое количество программ также имеют дыры класса C. Я укажу на многие из них в предстоящих главах.

Влияние Дыр на Безопасность Internet

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

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

ПРИМЕЧАНИЕ: Я недавно рассмотрел случай входа в систему случай, когда взломщик получил управление учётной записью локального пользователя. К несчастью для взломщика, он плохо выбрал своего адресата. Неосторожный пользователь был законченным newbie и никогда не использовал свою учётную запись оболочки. LAST log-файлы (и другие материалы ревизии) показали это немедленно. Так что мы имели модемного клиента, который никогда не использовал свою учётную запись оболочки (или даже не создавал Web страницу) внезапно компилирующего программы, используя компилятор C с учётной записи оболочки. Хмм. Следующий раз этот взломщик будет более разборчив в том, чью учётная запись он реквизирует.

Проблема Дыр Так Ужасна Как Говорят?

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

ПРИМЕЧАНИЕ: В своём эксперименте, я исключил все не UNIX операционные системы (я обработаю не UNIX операционные системы позже в этой главе). Я сделал это, чтобы быть справедливым, поскольку, производя выборку ошибок из списка рассылки, который концентрируется, прежде всего, на машинах UNIX, я дал бы ошибочно плохое представление о UNIX и ошибочно хорошее представление о не UNIX системах. Это так, потому что списки рассылки UNIX только иногда получают консультации по безопасности по не UNIX системам. (Сейчас это происходит чаще, потому что другие системы стали больше использоваться в качестве серверных платформ для WWW, но такие консультации редки).

Вместо беспорядочного выбора примеров для конкретного имени операционной системы и добавления их в таблицы (например, захват каждой регистрации, которая упоминает syslog дыру), я тщательно просеял каждую регистрацию. Я выбрал только те регистрации, которые впервые сообщали о дыре. Все дальнейшие сообщения, которые обсуждали эту дыру, были исключены. Таким образом, только новые дыры были добавлены к моим данным. Кроме того, я брал только первые 50 по каждой операционной системе. С одним незначительным исключением, которое я объясняю позже, я не имел причины предположить, что на процент сильно повлияет взятие 100 или 1,000 сообщений.

Я должен уведомить Вас об одном моменте. Рисунок 15.2 показывает удивительное число дыр в HP-UX (Hewlett Packard ОС). Эта распространённость дыр HP-UX в значительной степени из-за группы, называемой "Scriptors of Doom". Эти личности сконцентрировали свои усилия на обнаружении дыр существующих в HP-UX. Они обещали "одну дыру в неделю". Из-за их деятельности HP-UX, как кажется, имеет проблемы в безопасности, которые являются более серьезными, чем у других операционных систем подобного рода. Это не соответствует действительности. Прочитав это, пожалуйста, исследуйте Рисунок 15.2.

Обратите внимание, что Sun (Solaris), AIX и FreeBSD идут голова в голову, и что IRIX имеет только слегка меньшее количество дыр, чем Linux. Но какие из этих дыр являются серьезным риском для безопасности? Который из них, по платформам, уязвимости класса B или класса A? Чтобы определить это, я повторно исследовал данные на Рисунке 15.2 и исключил все уязвимости, которые не приводили к получению корневого доступа локальными или удаленными пользователями. Таблица 15.1 содержит результаты.

Обзор Известных Дыр в Операционных Системах на Октябрь-Декабрь 1996
Рисунок 15.2. Обзор Известных Дыр в Операционных Системах на Октябрь-Декабрь 1996.

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

Операционная система Дыры
HP-UX 6
Solaris 2
AIX 1
Linux 4
IRIX 4
FreeBSD 3

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

Это приводит меня к важной мысли. Вы можете часто видеть, особенно в Usenet, личностей, спорящих о том, что Solaris более безопасна, чем AIX или что Linux более безопасна, чем FreeBSD и т.д. Их аргументы тщетны. Как это случается, все операционные системы имеют свои дыры. Долгосрочная экспертиза списки отчетов показывает, что консультации поступают циклически. Если бы я произвел выборку в другой период времени, AIX могла бы быть преобладающей жертвой. Нет таинственной причины для этого. Это сводится к характеру индустрии. Когда дыра обнаруживается в sendmail, например, немедленно не ясно, на какие платформы она воздействуют. Определение этого требует времени. Когда дыра подтверждена, детально описана в регистрации в списке, возможно, что больше половины всех машин, выполняющих sendmail, подвержены ей. Но когда дыры обнаруживаются в частном программном обеспечении, может случиться все что угодно. Это может привести к одномесячному прогону консультаций на единственной платформе.

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

Дыры на Других Платформах

Анализ дыр на других платформах более труден. Хотя поставщики поддерживают документы относительно некоторых лазеек в безопасности в их программном обеспечении, организованные отчеты (кроме случаев вирусных атак) только недавно стали доступными. Это так, потому что не UNIX, не VAX системы стали популярными серверными платформами только за последние два года.

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

ПРИМЕЧАНИЕ: Это правило собирается меняться. Поскольку профессионалы безопасности знают, что Microsoft Windows NT собирается стать главным игроком, отчёты о дырах NT станут более заметной деятельностью.

Обсуждения Дыр в Internet

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

Страницы Всемирной Сети

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

CERT

Компьютерная Чрезвычайная Группа Реагирования была основана после катастрофы Internet Червя в 1988 (молодой Моррис до смерти испугал много людей в Сети, не менее тех, которые были в DARPA). CERT не только выпускает консультации Internet сообществу всякий раз, когда новая уязвимость безопасности становится известной, она

Реальная золотая жила в CERT это коллекция консультаций и бюллетеней. Вы можете найти эту и другую важную информацию на http://www.cert.org (смотрите Рисунок 15.3).

WWW сайт Компьютерной Чрезвычайной Группы Реагирования (CERT)
Рисунок 15.3. WWW сайт Компьютерной Чрезвычайной Группы Реагирования (CERT).

Консультативный Орган по Компьютерным Инцидентам (Computer Incident Advisory Capability) Министерства Энергетики

CIAC был также основан в 1989, после Червя Морриса. Эта организация поддерживает базу данных связанных с безопасностью материала, предназначенную, прежде всего для Американского Министерства Энергетики. Сайт CIAC один из лучших источников информации о безопасности. В дополнение к размещёнию утилит, этот сайт также размещает доступный для поиска архив консультаций по безопасности. Кроме того, CIAC обеспечивает публикацию ряда статей по безопасности. Также, CIAC теперь использует формат файлов Adobe PDF, так что статьи, которые он обеспечивает, привлекательны, легко управляемы и легко форматируются для печати. PDF формат, по моему мнению, намного лучше формата PostScript, особенно для тех, которые не выполняются в UNIX.

Важная информация, обеспечиваемая CIAC публике, включает следующее:

CIAC расположен на http://ciac.llnl.gov/ (смотрите Рисунок 15.4).

WWW сайт Консультативного Органа по Компьютерным Инцидентам
Рисунок 15.4. WWW сайт Консультативного Органа по Компьютерным Инцидентам.

Национальный Институт Стандартов и Центр Обмена Информационными Ресурсами по Технологиям Компьютерной Безопасности

WWW сайт NIST CSRC (смотрите Рисунок 15.5) всесторонняя начальная точка. NIST объединил значительный список публикаций, утилит, указателей, организаций и услуг поддержки.

WWW сайт NIST CSRC
Рисунок 15.5. WWW сайт NIST CSRC.

Форум Групп Безопасности и Ответа на Инциденты (FIRST)

FIRST (The Forum of Incident Response and Security Teams) в действительности коалиция многих организаций, общественных и частных, работающих над распространением информации по безопасности Internet и над её улучшением. Некоторые члены FIRST

Интересная вещь относительно FIRST состоит в том, что он не осуществляет централизованного управления. Все члены организации совместно используют информацию, но никто не осуществляет контроль над любым другим компонентом. FIRST поддерживает список ссылок на все группы члены FIRST, имеющих WWW сервера. Проверьте FIRST на
http://www.first.org/team-info/ (смотрите Рисунок 15.6).

WWW сайт FIRST
Рисунок 15.6. WWW сайт FIRST.

Архив Ошибок Windows 95

Архив ошибок Windows 95 поддерживается в Университете Stanford Rich'ем Graves. К его чести, это единственное истинно всесторонний источник такого типа информации. (Правда, другие серверы дают краткие обзоры безопасности Windows 95, но нет ничего подобного этой странице.) Этот архив расположен на

Господин Graves является Сетевым Консультантом, Вебмастером, специалистом Apple Talk и главным администратором Gopher. Он кропотливо собрал огромный набор ресурсов по организации сети Windows 95 (он, фактически, автор FAQ по Организации Сети Windows 95). Его список Win95NetBugs имеет доступный для поиска индекс, который расположен здесь:

Сайт также содержит FTP архив ошибок Windows 95, к которому можно обратиться через WWW по этому адресу:

ISS Список Рассылки Безопасности NT

Этот список стал доступным публике благодаря Системам Безопасности Internet (ISS - Internet Security Systems). Это архив списка рассылки. Люди посылают вопросы (или ответы) относительно безопасности NT. В этом отношении, сообщения очень похожи на статьи Usenet. Они представлены по следующему адресу в форме списка и могут просматриваться подряд (по теме), по автору или дате.

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

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

Один особенно ценный элемент этой страницы в том, что Вы можете связаться с Распечаткой Архива Обзора Безопасности Windows NT. Это всесторонняя база данных всех регистраций NT в список по безопасности. Приложение A обеспечивает описание различных методов точного поиска таких архивов, с использованием агентов. В списке есть некоторые очень талантливые члены. Даже если Вы посетите список без определенного вопроса, то просмотр записей откроет Вам многое о безопасности Windows NT.

Ссылка: ISS также является поставщиком наборов продуктов сканирования для Windows NT. Эти продукты выполняют чрезвычайно всесторонние исследования сетей NT. Если ваша компания рассматривает оценку безопасности, возможно, Вы захотите войти в контакт с ISS (http://iss.net).

Национальные Институты Здоровья

Страница Информации по Компьютерной Безопасности в Национальных Институтах Здоровья (NIH - National Institutes of Health) это ссылочная страница. Она содержит указатели на онлайновые журналы, консультации, ассоциации, организации и другие WWW страницы, которые представляют интерес в безопасности. Проверьте страницу NIH по этому адресу:

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

Архивы Bugtraq

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

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

Одна важная прелесть списка Bugtraq в том, что он не наводнён рекламными объявлениями и другой несоответствующей информацией. Большинство людей, посылающих сообщения в список, чрезвычайно хорошо осведомлены. Фактически, список часто посещается настоящими специалистами по безопасности, которые решают реальные проблемы каждый день. Chris Chasin, узел Bugtraq, определяет список следующим образом:

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

По моему мнению, Bugtraq наиболее ценный ресурс Internet для онлайнового отчета по UNIX-основанным уязвимостям. Посетите его здесь:

Справочный Указатель Компьютерной и Сетевой Безопасности

Этот индекс другая прекрасная страница ресурсов. Она содержит ссылки на консультации, группы новостей, списки рассылки, поставщиков и архивы. Проверьте её на

Горячий Список Безопасности Eugene'а Spafford

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

ПРИМЕЧАНИЕ: Примечание для пользователей Netscape: страница Spaff'а использует фундаментальную технологию Сети для порождения дочерних окон. Это означает, что для каждой нажимаемой Вами ссылки порождается новое окно. Новые пользователи могут быть незнакомы с этим методом связи и могут быть смущены, когда будут пытаться использовать кнопку Назад. Кнопка Назад не работает, потому что нет окна, к которому можно возвратиться. Если Вы планируете попробовать несколько ссылок на странице Spaff'а, то будете должны уничтожать каждое последующее дочернее окно, чтобы вернуться к основному списку. Если Вы не сделаете так (и вместо этого свернёте каждое окно), то скоро исчерпаете виртуальную память.

Списки Рассылки

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

ПРЕДОСТЕРЕЖЕНИЕ: Помните, когда я писал о большом объеме почты, которую можно получить от такого списка? Остерегайтесь. Подписка на несколько этих списков может легко привести к 10-30МБ почты в месяц.

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

Таблица 15.2. Списки рассылки дыр и уязвимостей.

Список Тема
8lgm-list-request@8lgm.org Только дыры в безопасности. Никакого почтового барахла. В основном UNIX.
bugtraq-request@fc.ne Список рассылки дыр. Никакого почтового барахла. UNIX.
support@support.mayfield.hp.com Консультации по безопасности Hewlett Packard.
request-ntsecurity@iss.net Список рассылки по безопасности NT ISS. Этот список генерирует архив NT, упомянутый предварительно.
coast-request@cs.purdue.edu Дыры и обсуждение утилит. Прежде всего UNIX.
security-alert@Sun.COM Консультации по безопасности Sun Microsystems.
www-security-request@nsmx.rutgers.edu Дыры во Всемирной Сети.
security-alert@Sun.COM Консультации по безопасности Sun Microsystems.
Sneakers@CS.Yale.EDU Список Sneakers. Методы вторжения из реальной жизни, использующие известные дыры и утилиты.

Итог

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

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

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

Предыдущая главаСледующая главаСодержание


Macmillan Computer Publishing USA

Macmillan Computer Publishing.


Все мессаги сюда:yanich@inbox.ru
Hosted by uCoz