Безопасность >>>
Классификация пользователей и типовых сценариев атак в UNIX
Рассмотрим основные пути получения взломщиком несанкционированного доступа на UNIX-компьютере.
Как известно, в UNIX различают два вида пользователей - обычный пользователь, имеющий права на доступ в рамках своего идентификатора (UID, userid) и членства в группе (GID, group ID), и так называемый суперпользователь (root), имеющий неограниченные права (UID и GID у него равны специальному значению 0).
|
Каждый пользователь UNIX в текущий момент может быть членом только одной группы, поэтому он имеет один UID и один GID.
|
По мере развития ОС среди обычных пользователей выделились так называемые специальные пользователи. Они, как правило, имеют зарезервированные имена (например, guest, bin, uucp и т.п.) и номера UID и GID (например, меньше 100). Хотя в защите UNIX нет никакого особого механизма, отличающего специального пользователя от обычного, можно сказать, что первый имеет еще меньше прав, чем второй. В частности, специальным пользователям обычно нельзя зайти в систему нормальным образом. Самым интересным для нас примером специального пользователя является анонимный пользователь ftp, который так и называется - anonymous, или ftp.
Наконец, условно к категории пользователей можно отнести человека, удаленно подключившегося (обычно по протоколу TELNET) к вашей машине и взаимодействующего с одной из программ-демонов (в современной терминологии такие программы называются серверами). Эти программы обычно стартуют при загрузке машины, чаще всего от имени суперпользователя, и постоянно активны как процессы, что позволяет пользователю в любой момент удаленно подключаться к ним, но при этом он не имеет никаких прав на чтение/запись информации на вашем компьютере и вообще не идентифицируется системой UNIX (команда who). Однако он может исполнять некоторые команды - не программы UNIX, а команды-запросы к тому демону, к которому он подключен. Так, подключившись по протоколу TELNET на 25-й порт, можно вводить команды SMTP-сервера, например mail или ехрn. Последний тип пользователя (назовем его псевдопользователь) оказывается чуть ли не самым важным для нашего рассмотрения, так как, не обладая никакими правами и обязанностями (кстати, от него не требуется аутентификации, учет по нему тоже не ведется), он взаимодействует с демонами, которые практически всегда имеют полномочия суперпользователя.
Итак, условно иерархию пользователей на UNIX-машине можно представить следующим образом:
- Суперпользователь - неограниченные права.
- Обычный пользователь - права с ограничениями, установленными для него суперпользователем.
- Специальный пользователь - права с ограничениями, установленными ему суперпользователем для работы с конкретным приложением.
- Псевдопользователь - нет никаких прав, он вообще не идентифицируется системой.
Очевидно, что любой пользователь Internet всегда имеет привилегии третьего уровня на вашем хосте, а также, если поддерживается соответствующий сервис, привилегии второго уровня.
Таким образом, задачей хакера является несанкционированное получение привилегий более высокого уровня. (Заметим, что необязательно конечной целью хакера является получение именно привилегий суперпользователя - вирус Морриса, например, даже и не пытался сделать этого.) Эту задачу он, очевидно, может попытаться решить различными путями: либо получить сразу требуемые привилегии, либо постепенно наращивать их. Рассмотрим далее типовые сценарии получения привилегий и средства UNIX, делающие их возможными.
- "Сразу в дамки" - имея привилегии третьего уровня, хакер получает права суперпользователя. Как уже отмечалось, такой фантастический прыжок возможен благодаря механизму демонов UNIX, отвечающих за обработку удаленных запросов. Так как эти демоны чаще всего выполняются от имени суперпользователя, то все, что нужно псевдопользователю, - это знать существующие "дыры" или ошибки в этих демонах (или найти самому), которые позволят эксплуатировать их нестандартным или запрещенным образом. Обычно это сводится к возможности удаленно выполнить от их имени любую команду на атакуемом хосте, какую конкретно - зависит от намерений и характера хакера. Иногда это может быть создание ошибочной ситуации, приводящей к аварийному завершению демона с выдачей дампа памяти на диск, содержащий весьма полезную для хакера информацию (например, кэшированные пароли). Типичными примерами уязвимых демонов были и остаются sendmail, ftpd, fingerd. Новые демоны (типа httpd или talkd) имеют гораздо меньшую историю эксплуатации, поэтому известно меньшее число их дыр и, соответственно, они перспективнее для поиска новых.
Такой сценарий был очень популярен на заре развития глобальных сетей, им пользовался вирус Морриса (см. в этой главе раздел "Червь"). Сейчас найти дыру такого рода в демонах очень трудно, хотя и можно. Хосты, допускающие атаку по этому сценарию, должны считаться катастрофически незащищенными.
- "Из специального - в обычного, или выше". Этот сценарий очень похож на предыдущий, с тем исключением, что для хакера требуются начальные привилегии второго уровня (иначе говоря - запущен некоторый дополнительный сервис). Для четкого отличия таких атак от первого типа будем считать, что злоумышленник всегда проходит некую (пусть примитивную) идентификацию и, возможно, аутентификацию. Это не очень серьезное допущение, большинство хостов поддерживают некоторый удобный (например, анонимный ftp) или необходимый (типа tftp для удаленной загрузки бездисковых станций) сервис. Привилегии второго уровня могут дать возможность хакеру читать некоторые файлы (например, из ~ftp/pub) и, что самое главное, записывать свои файлы на ваш компьютер (в каталог типа ~ftp/incoming). С другой стороны, так как пользователь регистрируется на вашем компьютере, в его файлах-протоколах остается некоторая информация о подключении.
Типичным примером атаки по данному сценарию является атака, которая по протоколу tftp получает файл паролей /etc/passwd, а затем с его помощью подбираются пароли пользователей. Этот пример показывает, что необязательно желаемые привилегии будут получены немедленно, такие атаки могут лишь создать предпосылки для возможного их получения в дальнейшем.
Хосты, допускающие подобные атаки, также должны считаться катастрофически незащищенными в случае, если используемый в них сервис нельзя отключить без ущерба функционированию системы.
- "Маловато будет: из обычного - в суперпользователи". Этот сценарий, пожалуй, наиболее прост и широко распространен. Подавляющее большинство сообщений о так называемых "дырах" в UNIX относится именно к нему. Для его осуществления злоумышленник должен уже быть обычным пользователем (иногда говорят, что он имеет бюджет, или account) на том компьютере, который он собирается взламывать. Это, с одной стороны, серьезное ограничение на масштабность проникновения, с другой стороны - большинство утечек информации происходит через "своих", через подкупленного сотрудника, который пусть и не имеет больших полномочий, но уж входное имя на секретный компьютер у него есть.
Своей осуществимостью атаки данного рода обязаны очередному недостатку безопасности UNIX, который называется механизмом SUID/SGID-процессов. Не будем сейчас подробно останавливаться на необходимости и причинах появления такого механизма в этой операционной системе, отметим лишь, что многим системным программам (которые могут быть запущены любым, в том числе и непривилегированным пользователем) для правильного функционирования необходимы дополнительные полномочия. Приведем хрестоматийный пример изменения пользователем пароля самому себе. Не вызывает сомнения, что пользователь может иметь право на подобную операцию, однако в терминах UNIX это равносильно наличию права на запись в общий для всех пользователей файл /etc/ passwd, что, очевидно, недопустимо. Поэтому программа, осуществляющая смену пароля пользователя, выполняется не от имени запустившего его пользователя, а от имени суперпользователя (который, естественно, имеет право на запись в файл /etc/passwd). Для этого она обладает специальным атрибутом SUID/SGID, означающим смену идентификатора пользователя и/или группы у запущенного процесса.
Такая особенность UNIX, нарушающая, безусловно, исходную модель разграничения доступа, считалась бы "нехорошей", будь она всего у одной программы passwd. Однако оказывается, что этот атрибут необходим целому множеству программ, порой очень сложных. Отсюда ясно, что злоумышленник, найдя ошибку в одной из программ, обладающих атрибутом SUID
root, может от ее (то есть супериользователя) имени произвести некоторые действия. Стандартным приемом считается копирование файла с командным интерпретатором (sh или csh) и установка на него атрибута SUID root. Таким образом, злоумышленник имеет под рукой стандартную программу sh, но все команды в ней он исполняет от имени суперпользователя.
Ошибки в SUID/SGID-программах находятся регулярно, с частотой несколько раз в месяц. Следуя одной из основных аксиом программирования, можно сделать вывод, что эти ошибки будут находиться всегда. Соответственно, многие защищенные версии UNIX стремятся обезопасить себя от атак такого рода, сильно модифицировав SUID/SGID-механизм или вообще отказавшись от него.
Внимательный читатель заметил, что данный сценарий, вообще говоря, не является удаленной атакой по определению (и не будет подробно рассматриваться в примерах), но введен в классификацию из-за масштабности и фундаментальности - механизма SUID/SGID-процессов. Надо также помнить о том, что локальная атака легко становится удаленной, если злоумышленник подключается к компьютеру по протоколу TELNET - в этом смысле UNIX вообще не делает отличия локального пользователя от удаленного.
Поскольку любая система UNIX (использующая этот механизм) является уязвимой, то хосты, которые подвержены атакам такого класса, будем называть потенциально незащищенными.
- "Он слишком многим доверял". Взлом производит обычно псевдопользователь, либо повышая свои полномочия до обычного, либо получая несанкционированный доступ к информации с использованием механизма доверия. Термин "доверие" (одна из важнейших брешей в безопасности UNIX) появился с тех пор, когда компьютерные системы строились на доверии друг другу. "Доверие" употребляется всякий раз, когда возникает ситуация, в которой хост может позволить пользователю (как правило, удаленному) применять локальные ресурсы без аутентификации или с явно недостаточной аутентификацией (без ввода пароля).
В UNIX существует много подсистем, использующих доверие. Наиболее простыми и часто применяемыми (даже против такого мастера, как Шимомура) из них являются так называемые r-службы (remote - удаленные). При наличии файлов .rhosts и hosts.equiv, содержащих имена хостов, доступ с них возможен без указания пароля. Аналогичным образом на механизме доверия построены, например, NFS-серверы, в управляющих (export) файлах которых можно разрешить доступ к некоему каталогу для группы пользователей, при этом удаленный пользователь никак не должен подтверждать свою причастность к данной группе. Как подчеркивал В.Венема в своей статье [22], "любая форма доверия может быть подменена, обманута или разрушена, особенно когда служба, получающая запросы на проверку клиента, расположена вне сервера или когда механизм доверия основан на слабой форме аутентификации".
Часто доступ к системе по данному сценарию возможен только при неправильных настройках соответствующих файлов (не будем сейчас подчеркивать, что эти настройки также могут быть внесены злоумышленником сознательно - см. атаку Митника), поэтому хосты, подверженные атакам такого класса, можно называть "слишком доверчивыми" или административно незащищенными.
Итак, подводя итог, повторим те механизмы и особенности UNIX, которые делают возможными удаленные атаки на эту ОС. Это, в первую очередь, наличие демонов, обеспечивающих обработку удаленных запросов. Чаще всего они запускаются от имени суперпользователя, и при неправильном функционировании его права могут быть получены удаленным пользователем. Во-вторых, это широкое использование механизма доверия, который может быть обманут удаленным пользователем. И, в-третьих, механизм SUID/SGID-процессов легко позволяет обычному пользователю получить привилегии другого пользователя или группы.
Наиболее интересные или известные способы проникновения в UNIX-системы мы опишем далее в хронологическом порядке.
|