Атака на Internet

1. Наличие демонов.

2. Механизм SUID/SGID-процессов.

3. Излишнее доверие.

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

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

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

Итак, вот те причины, по которым демоны и SUID/SGID-процессы становятся уязвимыми:

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

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

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

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

Хорошим примером непредусмотренной ситуации в многозадачной операционной системе является неправильная обработка некоторого специального сигнала или прерывания. Часто хакер имеет возможность смоделировать ситуацию, в которой этот сигнал или прерывание будет послано (в UNIX посылка сигнала решается очень просто – командой kill, как в примере с sendmail).

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

Люком или «черным входом» (backdoor) часто называют оставленную разработчиком недокументированную возможность взаимодействия с системой (чаще всего – входа в нее), например, известный только разработчику универсальный «пароль». Люки оставляют в конечных программах вследствие ошибки, не убрав отладочный код, или вследствие необходимости продолжения отладки уже в реальной системе из-за ее высокой сложности, или же из корыстных интересов. Люки – это любимый путь в удаленную систему не только у хакеров, но и у журналистов, и режиссеров вместе с подбором «главного» пароля перебором за минуту до взрыва, но, в отличие от последнего способа, люки реально существуют. Классический пример люка – это, конечно, отладочный режим в sendmail.

Наконец, многие особенности UNIX, такие как асинхронное выполнение процессов, развитые командный язык и файловая система, позволяют злоумышленникам использовать механизмы подмены одного субъекта или объекта другим. Например, в рассмотренных выше примерах часто применялась замена имени файла, имени получателя и т. п. именем программы. Аналогично может быть выполнена подмена специальных переменных. Так, для некоторых версий UNIX существует атака, связанная с подменой IFS (internal field separator – символ разделителя команд или функций) на символ «/». Это приводит к следующему: когда программа вызывает /bin/ sh, вместо него вызывается файл bin с параметром sh в текущем каталоге. Похожая ситуация возникает при атаке на telnetd. Наконец, очень популярным в UNIX видом подмены является создание ссылки (link) на критичный файл. После этого файл-ссылка некоторым образом получает дополнительные права доступа, и тем самым осуществляется несанкционированный доступ к исходному файлу. Подобная ситуация с подменой файла возникает, если путь к нему определен не как абсолютный (/ bin/sh), а как относительный (../bin/sh или $(BIN)/sh). Такая ситуация также имела место в рассмотренной уязвимости telnetd.

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

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

Windows NT

Мы специально так подробно рассмотрели UNIX и закончили классификацией причин ее уязвимости, чтобы читателю было легче провести параллель с более молодой операционной системой – Windows NT. Сразу оговоримся, что, в отличие от UNIX, речь будет идти только об одной версии – Windows NT 4.0.

Windows NT – сильно выделяющийся продукт среди ОС, производимых фирмой Microsoft. Во-первых, это единственная система, способная работать на процессорах, отличных от Intel-совместимых, а именно на процессоре Alpha. Во-вторых, эта ОС выпускается в виде двух реализаций – как сервер (Windows NT Server) и как рабочая станция (Windows NT Workstation). В-третьих, ядро этой системы писалось с нуля, и при его разработке не требовалась 100-процентная совместимость с более ранними ОС типа MS DOS. Наконец, только в этой ОС с самого начала было уделено должное внимание требованиям безопасности, что привело к созданию собственной файловой системы, нового алгоритма аутентификации, подсистемы аудита и т. п.

Последний факт послужил поводом к возникновению нескольких мифов о защищенности Windows NT. Часто можно услышать, что Windows NT на сегодняшний день – самая защищенная сетевая ОС. На самом же деле, как подчеркивалось во введении к этой главе, пока нельзя сказать, какая из ОС является более защищенной и по каким параметрам. Этого нельзя будет сделать до тех пор, пока Windows NT не проработает хотя бы несколько лет в качестве сетевой ОС на различных аппаратных и программных конфигурациях. Ей, видимо, это не грозит в связи с выходом Windows 2000 (она же Windows NT 5.0), и процесс тестирования начнется сначала. Наконец, накопленный на сегодняшний день опыт уже не подтверждает притязаний NT на самую защищенную ОС, что и показано в данном разделе.

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

1. Не Windows NT 4.0, а 3.5, причем обязательно с Service Pack 3.

2. Сертификация касалась только локальной (не сетевой) версии NT, то есть с отсутствующими сетевыми адаптерами и внешними накопителями.

3. Сертификация производилась на конкретной аппаратной платформе, а именно: Compaq Proliant 2000 and 4000 (для платформы Intel/Pentium) и DECpc AXP/150 (для платформы Alpha). Если NT установлена на другую платформу, сертификат на нее не распространяется.

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

Классификация причин уязвимости Windows NT

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

Оказывается, что классификация причин уязвимости Windows NT весьма похожа на рассмотренную аналогичную классификацию для UNIX (рис. 9.5).

Рис. 9.5. Причины уязвимости Windows NT