Страница:
тайной двери в системе, поэтому администратор вынужден разглядывать
только исполняемый модуль. Для реассемблирования объектного кода мож-
но применить отладчик (adb), но если только вы не имеете безумно
близкого знакомства с внутренностями системы UNIX, вам будет весьма
трудно представить себе, что происходит. Изощренные программы потай-
ной двери избегают также присутствия легко узнаваемых строк в испол-
няемых модулях. Вы можете, однако, применить команду strings (если
она есть в вашей системе) для поиска символьных строк, которые там
могли бы быть.
Одна из простейших ловушек для того, кто пытается добыть права
суперпользователя - создавать запись, помещаемую в протокольный файл.
При этом администраторам нужно следить за протокольными файлами, не
появляются ли там записи, которые могут быть признаком злодейства.
Ниже мы покажем вам инструментальное средство, которое автоматически
следит за одним из таких протокольных файлов - файлом sulog, содержа-
щим транзакции "замененного пользователя". Другой протокольный файл,
часто нуждающийся в проверке, это протокол программы uucp, потому что
эта программа может быть использована для несанкционированных пересы-
лок файлов. Многие нарушители пытаются проверить протокольные файлы и
удалить компрометирующие записи, сгенерированные при их вмешательст-
ве. В арсенале администратора есть средства борьбы с этим. Они не на
100 процентов эффективны, но отлавливают некоторых нарушителей и, ус-
ложняя им жизнь, могут отбить охоту вторгаться в систему.
В дополнение к обычным протокольным файлам, поддерживаемым сис-
темой UNIX, некоторые администраторы заводят свои собственные прото-
кольные файлы, а затем подправляют ключевые команды так, чтобы они
помещали данные в эти новые регистрационные файлы в процессе своей
работы. Это может помочь обезвредить неосторожных лазутчиков. Один
знакомый администратор сделал протокольный файл для команды cu и наз-
вал его /tmp/.../.culog. Довольно умный тайный фокус, но в
/usr/lib/crontab у него была запись для периодической печати этого
файла. Это его выдавало: нужно было маскироваться получше. Заметим
также, что ваши "скрытые" имена протокольных файлов могут быть извле-
чены путем просмотра исполняемого образа команды с помощью утилиты
strings.
Если у вас есть пользователь, от которого вы ожидаете чего-ни-
будь запрещенного, вы должны уметь установить специальную систему ре-
гистрации, которая запускала бы более совершенный механизм, когда та-
кой пользователь работает в системе. Программу watch из главы 6 можно
модифицировать так, чтобы она вызывала специальную протоколирующую
программу, когда в систему входит пользователь из известного списка.
Протоколирующая программа могла бы повторять команды ps (process
status, состояние процесса) и/или делать "моментальные снимки" обыч-
ных регистрационных файлов (особенно учетных файлов) и направлять ре-
зультаты в припрятанный протокольный файл. Идея состоит в том, что
опасные процессы можно было бы обнаружить до того, как нарушитель по-
лучает возможность войти в протокольные файлы и изменить их. (Видимо,
вам нужно избегать применения команды at в такой программе, а перио-
дически пользоваться вместо нее командой sleep. В противном случае,
нарушитель может распознать ваши мероприятия по записи файла
crontab.) Как только вы имеете результат о сеансе работы опасного
пользователя, вы можете запустить grep для поиска интересующих вас
имен или написать инструментальное средство, которое выполняет для
вас такой поиск.
Вероятно, наиболее важным среди протокольных файлов является
учетный файл. В учетном файле имеется запись о каждом и всяком про-
цессе, запускаемом в системе. Точную структуру можно посмотреть в
файле /usr/include/sys/acct.h. В одном из полей этой структуры запи-
саны процессы, имеющие суперпользовательские возможности.
Когда кто-либо входит в систему через корневую дверь, для shell-
интерпретатора, который он запускает, и для всех процессов, которые
он порождает, владельцем является корень (суперпользователь). В учет-
ном файле отражен номер терминала, с которого запущен процесс, поэто-
му вы можете увидеть корневые процессы, запущенные с таких термина-
лов, на которых пользователям не разрешен суперпользовательский
доступ.
Если у вас имеются обычные линии с набором номера, то все такие
записи могут представлять не одного и того же пользователя. Другие
входы в систему могут иметь одинаковый номер терминала, но разные
пользовательские идентификаторы. Однако, вы можете знать, кто обычно
имеет доступ к некоторым выделенным линиям.
Учетные файлы могут хорошо разоблачить процессы, имеющие не та-
кой пользовательский идентификатор, как у лица, запустившего эти про-
цессы. Поищите процессы, владельцем которых был известный пользова-
тель, но которые имеют суперпользовательские возможности. Среди них
могут быть корректные записи, например lpr, так как отображаются все
системные программы, запущенные со взведенным битом setuid. Записи,
которые мы ищем, относятся к shell-интерпретаторам с установленным
учетным флагом суперпользователя. Это выдает тот факт, что была вы-
полнена программа потайной двери. Изучите подключаемый файл acct.h,
чтобы увидеть все определения. Используя бит ASU для проверки поля,
мы можем изолировать флаговую область, отражающую привилегию супер-
пользователя. Самый лучший способ рассмотреть эту структуру - напи-
сать программу на языке Си, печатающую все элементы структуры. В сле-
дующей распечатке показаны некоторые важные учетные поля:
--------------------------
|
| cmd f uid tty btime
|
| more 0 russ 0 Sat Jul 5 01:25:59 1986
| ls 0 russ 0 Sat Jul 5 01:31:12 1986
| ps 0 russ 0 Sat Jul 5 01:31:59 1986
| id 0 russ 0 Sat Jul 5 01:34:00 1986
| pwd 0 russ 0 Sat Jul 5 01:34:12 1986
| sh 1% russ 0 Sat Jul 5 01:33:51 1986
| \__ корневой shell с эффективным пользовательским идентификатором
|
| sync 0 russ 0 Sat Jul 5 01:34:21 1986
| df 0 russ 0 Sat Jul 5 01:34:27 1986
| id 0 root 0 Sat Jul 5 01:34:37 1986
| sh 2# root 0 Sat Jul 5 01:34:33 1986
| \__ корневой shell с реальным пользовательским идентификатором,
| 2# обозначает бит суперпользователя,
| владелец изменен на root
|
Отметим, что shell-интерпретаторы с эффективным пользовательским
идентификатором маскируют бит во флаге суперпользователя, но владель-
цем их процессов является обычный пользователь. Не известно, все ли
системы применяют значение 1 в качестве флага shell-интерпретатора с
эффективным пользовательским идентификатором. Похоже, что Berkeley
поступает именно так, а System V нет.
КОМАНДА su
Как мы уже отмечали, UNIX предоставляет пользователям обычный
способ стать суперпользователем - это команда su. Как видно из преды-
дущего изложения, суть команды su заключается в системном вызове
exec. Тот, кто применяет команду su, должен знать корневой пароль,
транзакция протоколируется в файле /usr/adm/sulog, а команда ps огла-
шает тот факт, что активен корневой shell. Этот прием не самый хитро-
умный.
Помните о том, что НИКОГДА нельзя оставлять без присмотра терми-
нал, на котором вы работаете в качестве суперпользователя? Пока вы
отсутствуете, кто-то может воспользоваться этим терминалом, чтобы вы-
полнить команду chmod с целью установки бита пользовательского иден-
тификатора. Хорошо подготовленный нарушитель уже имеет откомпилиро-
ванную программу потайной двери, владельцем которой является
суперпользователь, и ждет, когда будут изменены права доступа. Не ос-
таются ли консольные терминалы доступными в качестве суперпользова-
тельских ночью, во время действий по резервному копированию? Если ос-
таются, то наутро администратор может оказаться в незавидном
положении!
БОЛЕЕ ПОДРОБНО О ПОЛЬЗОВАТЕЛЕ bin
Мы уже упоминали о "лазейке" в некоторых системах, позволяющих
пользователю "bin" без труда завладеть суперпользовательским досту-
пом. Проблема "bin" имеет еще ряд аспектов. Если несанкционированные
пользователи могут войти в систему через bin (являющийся владельцем
большинства дистрибутивных исполняемых модулей), то они почти навер-
няка смогут получить права суперпользователя. Прежде всего, в некото-
рых версиях владельцем всех исполняемых модулей, размещенных в ката-
логах /bin и /usr/bin, является bin. Это значит, что нарушители могут
перезаписать или подправить исполняемые модули своими собственными
вариантами, выполняющими некоторые особые действия, например "chmod
4755 door", а затем восстановить на место исходную версию исполняемо-
го модуля.
Еще один способ простого превращения bin в суперпользователя
заключается в модификации /etc/rc - файла запуска команд ("run
command"). Он запускается каждый раз, когда машина загружается в мно-
гопользовательском режиме. Записывая в него "chmod 777 /etc/passwd",
нарушитель может превратить парольный файл в обычный пользовательский
после того, как машина загрузится.
Последний способ - использовать файл /usr/lib/crontab. Этот путь
изменен в последней версии System V. Теперь полное имя этого файла
/usr/spool/cron/crontabs/xxx, где xxx - файл crontab для каждого
пользователя. В старом варианте владельцем файла /usr/lib/crontab
иногда является bin. Кто-нибудь может отредактировать этот файл и по-
местить в него такие, например, команды:
* * * * * chmod 777 /etc/passwd
* * * * * chmod 4755 /tmp/door
* * * * * /bin/su root -c "chmod 777 /etc/passwd"
Все это срабатывает по той причине, что cron выполняется процес-
сом init. Поскольку init - один из первых запущенных процессов, его
владельцем является суперпользователь. Поэтому любая команда, которую
выполняет cron, имеет корневые привилегии. Звездочки означают, что
cron должен выполнить указанные команды в очередной возможный момент
времени. Cron запускает процесс, изменяющий права доступа к указанно-
му файлу. Нарушители могут поменять парольный файл (что несколько бо-
лее опасно) или просто активизировать программу потайной двери. Если
две первые команды не сработают, то владелец будет изменен на супер-
пользователя методом грубой силы - выполнением команды su, а затем
передачей команды chmod shell-интерпретатору, запущенному командой
su. Вы должны почаще проверять файлы crontab и /etc/rc!
Это редко применяемый метод. Он предполагает, что обычный поль-
зователь имеет право на запись в исполняемый модуль или в специальный
файл. Если кто-то может писать в исполняемый модуль, скажем ls, то он
может поместить туда некоторый код, который устанавливает потайную
дверь, а затем заменяет себя настоящей утилитой. Это работает еще
лучше, когда эту команду запускает пользователь с корневыми возмож-
ностями, так как тогда команда выполняется как привилегированный про-
цесс. Такой способ упрятывания кода в программу с возможностью запус-
ка ее не вызывающим подозрения пользователем называется "троянским
конем". Он выглядит безвредным, но то, что спрятано у него внутри,
крепко бьет по защите системы. Как мы уже отмечали, периодическая
проверка контрольных сумм для стандартных исполняемых модулей - одно
из противоядий от "троянских коней".
Если нарушители овладевают возможностью чтения или записи файлов
устройств, они могут прочитать в этих файлах информацию о суперблоке
и файловой системе и получить доступ к любому файлу. Им может понадо-
биться пройти по файловой системе в поисках нужного файла, подправить
его и записать обратно в файл устройства. Люди, которые этим занима-
ются и совершают при этом ошибки, могут добиться краха всей системы.
Если файл устройства находится в памяти, пользователи могут
просматривать информацию о процессах или ядре непосредственно в памя-
ти. Может быть использован старый прием отслеживания списков clist на
предмет поступления пароля пользователя, входящего в систему. Это
требует больших знаний о том, где данная информация размещается в па-
мяти и как к ней добраться, поэтому этим методом пользуются, вероят-
но, только опытные нарушители.
В некоторых системах бывает, что после перезагрузки машины на
консоли работает суперпользовательский shell. Такое может произойти в
однопользовательском режиме или на микро-ЭВМ, служащей консолью для
большой машины. Очевидное решение - ограничить физический доступ к
консоли.
ИСПОЛЬЗОВАНИЕ ПРЕИМУЩЕСТВ ПЕРЕМЕННОЙ $PATH
Кое-кто может воспользоваться ситуацией, когда пользователь име-
ет каталог $HOME/bin впереди системных каталогов /bin и /usr/bin в
своей переменной PATH. Помещая подправленную программу в регистраци-
онный каталог безвредного пользователя, нарушитель заставляет эту
программу выполняться вместо настоящей, поскольку система исполняет
первый файл, совпадающий с именем команды, который она обнаруживает в
ходе просмотра определенного пользователем маршрутного списка. Приме-
ром могла бы служить команда ls.
Когда команда выполняется, она запускается с теми же правами
доступа, что и запустивший ее пользователь. Конечная цель нарушителей
- добиться прав суперпользователя, поскольку тогда они смогли бы вы-
полнить любую команду. Диверсионная программа может подготовить по-
тайную дверь для овладения правами суперпользователя или даже нес-
колько таких дверей. Она может удалить себя, чтобы при очередном
вызове данной команды выполнялась настоящая команда. Настоятельная
необходимость для администратора - проверять наличие в рабочем прост-
ранстве опасных файлов (в частности, исполняемых модулей).
Мы не слышали, чтобы кто-либо это делал, но имеет смысл от этого
защититься. Старательный нарушитель мог бы сначала подготовить правки
для системы, поместить их на ленту и переслать их вам, администрато-
ру. Вы, вероятно, предположили бы, что это правильные модификации
системы и установили бы их. И ваша система получила бы "подарочек" от
нарушителя. Поэтому администратор может захотеть сверить новые версии
с их изготовителем перед тем, как устанавливать их у себя.
Хотя мы не можем дать гарантию, что кто-нибудь смекалистый не
опишет, как расколоть парольную защиту, кодирование пароля в системе
UNIX по алгоритму DES считается довольно секретным. (Рассмотрение ме-
ханизма DES выходит за пределы данной книги.) К этой защите добавля-
ется одна вещь - два символа, генерируемые случайным образом, называ-
емые "солью" (salt) и хранимые в файле /etc/passwd для каждой записи.
"Соль" используется для определения того, какой из 4096 вариантов ал-
горитма DES применяется для кодирования заданного пароля. Нарушитель
мог бы захватить пароль, использовать его "соль" и зашифровать список
известных паролей. Если бы результат совпадал с пробным паролем,
взлом был бы осуществлен.
Нарушителю пришлось бы иметь доступ к некоторой довольно чувс-
твительной методике, чтобы добиться своего. Нелишняя мера, которую
может предпринять администратор,- следить за чрезмерным использовани-
ем команды crypt (если она есть в вашей системе). Эта команда специ-
ально сконструирована так, чтобы занимать много процессорного времени
- не настолько много, чтобы причинять неудобства законным пользовате-
лям, но достаточно много, чтобы выявить попытки автоматизированного
взлома.
Западня работает только на специально выделенных линиях. Когда
UNIX ожидает, что кто-то будет входить в систему, она печатает ре-
гистрационную строку из файла /etc/gettydefs. Пользователь вводит
свое регистрационное имя и пароль и попадает в систему.
Программа западни извлекает из этого выгоду. Она имитирует пове-
дение экрана во время регистрации. Когда пользователь вводит свое имя
и пароль, такая программа печатает сообщение "login incorrect" ("не-
верная регистрация"), а затем запускает настоящую регистрационную
программу. Пользователь думает, что он сделал ошибку и повторяет по-
пытку входа в систему, на этот раз успешно. Регистрационное имя и па-
роль можно куда-нибудь отложить для последующего изучения. Самая луч-
шая защита администратора от этого - обучение пользователей. Видимо,
с помощью регулярной почты или бюллетеней нужно напоминать им, что
если им кажется, что они набрали пароль правильно, но получили при
этом сообщение "incorrect", то они должны немедленно сменить свой па-
роль и сообщить об этом происшествии администратору. Бывают случаи,
когда пользователь действительно ошибается при вводе пароля, но к
большому количеству таких происшествий нужно отнеститсь со всей серь-
езностью.
Команда монтирования была создана для того, чтобы позволить при-
соединять к системе несколько дисковых устройств. Раньше, в эпоху ми-
никомпьютеров единственным видом дисковых устройств были большие на-
копители, в которые вставлялись большие дисковые пакеты. Они обычно
находились в машинном зале, и только администратор монтировал их.
Теперь многие системы имеют гибкие диски. Они гораздо персональ-
нее и намного меньше, чем большие дисковые пакеты. Это уменьшение
размера ощутимо воздействует на важность самого объекта. Похоже, что
теперь каждый пользователь может иметь дело со своими дисками, и ад-
министратору больше нет необходимости заниматься этим. Такой сценарий
работы приводит к следующему.
Обычное действие, предпринимаемое в небольших системах для того,
чтобы дать пользователям возможность работать с их собственными гиб-
кими дисками,- это установка бита пользовательского идентификатора
для файла команды /etc/mount. Таким образом, когда запускается коман-
да монтирования, ее пользовательский идентификатор становится корне-
вым, и она может смонтировать гибкий диск. Команда демонтирования
должна быть подготовлена аналогично.
Кто-то может извлечь выгоду из того, что команда mount может по-
лучить во время своей работы права суперпользователя. Обычно в не-
больших системах одна машина открыта для экспериментов несанкциониро-
ванного пользователя. Он может стать суперпользователем в вашей
системе, подготовить программу потайной двери и поместить ее на гиб-
кий диск. Владельцем является суперпользователь, а права доступа
4755. Затем нарушитель может размонтировать гибкий диск и войти в за-
щищенную систему.
С этого момента нарушитель может просто входить в систему как
обычный пользователь, без всяких специальных прав доступа и монтиро-
вать гибкий диск, на котором имеется программа потайной двери. Когда
гибкий диск монтируется, файловая система гибкого диска встраивается
в файловую систему жесткого диска, и две системы сливаются в одну.
Это означает, что потайная дверь для овладения правами суперпользова-
теля готова для файловой системы на жестком диске.
Когда нарушитель запускает программу потайной двери на гибком
диске, происходит то же самое, что происходило бы, если бы эта прог-
рамма была на жестком диске. Мера предотвращения - контролировать ис-
пользование команды mount в вашей системе. Доступ к команде mount
должен быть ограничен определенным кругом пользователей, она не долж-
на разрешать монтировать файлы с установкой пользовательского иденти-
фикатора.
АВТОНОМНЫЙ shell (SASH)
В системах UNIX с гибкими дисками загрузочный диск обычно загру-
жается с гибкого накопителя. Подразумевается, что гибкий диск приме-
няется для подготовки жесткого диска и копирования всех файлов систе-
мы UNIX с гибкого диска на жесткий. Но за этим кроется нечто большее.
На самом деле загружаемый гибкий диск - это компактная, перено-
симая версия системы UNIX. Ядро адаптировано к тому, чтобы размещать-
ся на гибком диске, а не на жестком. Когда вы его загружаете, вы по-
лучаете интерпретатор shell и среду точно так же, как при работе с
жесткого диска. Вот почему такой shell называется автономным (SASH,
standalone shell).
Корневая файловая система на гибком диске даже выглядит точно
так же, как файловая система жесткого диска. Фактически вы можете
смонтировать загружаемый диск и скопировать утилиты с жесткого диска
на гибкий. Нужны две важные команды: mount и umount. Ограничением яв-
ляется размер гибкого диска. На него не так много помещается.
Сценарий, с помощью которого несанкционированный пользователь
может применить SASH для входа в систему с суперпользовательскими
привилегиями, выглядит примерно так. Сначала он должен отключить пи-
тание или перезагрузить защищенную систему. Затем он должен загрузить
SASH и смонтировать корневую файловую систему жесткого диска в точку
монтирования своей файловой системы гибкого диска. Команды могут быть
такими:
# /etc/mount /dev/fp001 /mnt <-- для System V
# /etc/mount /dev/hd0a /mnt <-- для XENIX
Это дает нарушителям доступ на жесткий диск при помощи обращения
/mnt/*. Все, что им нужно для редактирования файла /etc/passwd - это
пройти вниз по дереву каталогов. Для этого можно применить такие ко-
манды:
# /mnt/bin/vi /mnt/etc/passwd
# sync
Теперь жесткий диск изменен, и его можно вернуть на место. Нару-
шитель может остановить автономный вариант UNIX и перезагрузиться с
жесткого диска. Он может использовать новое регистрационное имя, соз-
данное при помощи SASH. Мы не знаем, насколько часто люди могут
предпринимать такие попытки. Небольшие системы более уязвимы, но в
них и меньше пользователей (и потенциальных злодеев). Во многих слу-
чаях нижней границей "логической защиты" становится "физическая защи-
та". Большинство людей, имеющих большие машины или даже мини-ЭВМ,
постоянно осознают, что им есть что защищать. А микро-ЭВМ выглядят
настолько "дружественными" и простыми, что люди обычно забывают, что
информация, которая содержится на микрокомпьютерах, при определенных
обстоятельствах может оказаться настолько же желаемой и значительной,
как и на больших машинах.
Чаще всего правки исходных текстов являются самым мощным, хотя и
не самым легким способом проникновения нарушителей в систему. Внедряя
свой собственный код в подходящих местах, несанкционированные пользо-
ватели могут извлечь всю секретную информацию, которая им нужна. Од-
нако, правки кода могут быть полезны также и для администратора. Ад-
министратору может понадобиться внести правки в регистрационную
программу, чтобы посмотреть, кто и как часто пытается зарегистриро-
ваться на машине. Другой вариант - внесение правок в программы с ус-
тановкой пользовательского идентификатора и в другие доступные огра-
ниченному кругу лиц программы, чтобы они регистрировали свой сеанс
работы в секретном протокольном файле.
Еще одно место, в котором нужно следить за несанкционированными
правками - библиотеки ядра. Подправленные объектные модули можно лег-
ко поместить в библиотеки незамеченными. Другим библиотекам грозит та
же опасность. Дополнительные разумные усовершенствования ядра можно
обнаружить в системных вызовах chmod и chown. Когда выполняются эти
системные вызовы, они проверяют, имеете ли вы пользовательский иден-
тификатор 0. Если нет, то ваш запрос не удовлетворяется. Отменив эту
проверку, любой обычный пользователь мог бы изменить владельца файла
на суперпользователя, а также изменить режим защиты файла, чтобы
взвести бит установки пользовательского идентификатора. Это позволило
бы успешно обойти защитный барьер.
ПРОГРАММА passwd
Программа passwd - охранник ворот системы UNIX. Точно так же,
как многие древние города пали из-за того, что враги подкупили охран-
ника ворот, так и хорошо защищенная система UNIX может быть превраще-
на в широко открытую, если кто-либо подправит эту программу. Посколь-
ку пользователи применяют программу passwd для изменения своих
паролей, подправленная версия может записывать новый пароль, вводимый
пользователем для изменения, в секретный файл, принадлежащий наруши-
телю. Это может обесценить каждый вновь создаваемый в системе пароль.
Внутри программы passwd пароль является просто символьным массивом,
поэтому с этими данными легко управиться.
ПРОГРАММА crypt
Потенциальной правкой программы шифрования файлов crypt может
быть накопление имен файлов и ключей шифра при каждом использовании
программы. Таким методом вы можете проследить, кто запускает эту ко-
манду, какой файл он использует и какой ключ применяется для того,
чтобы получить доступ к этому файлу.
Неприятности, связанные с последними двумя случаями, заключаются
в том, что кто-нибудь может разрушить меры системной безопасности.
Если вы считаете, что в вашей системе есть заманчивые, важные данные,
то вам как администратору следует почаще проверять эти программы (по
контрольной сумме или сравнением) на предмет повреждения.
КОМАНДА su
Поскольку команда su предоставляет суперпользовательский доступ
для обычных пользователей, имеющих корневой пароль, это еще одна по-
тенциальная лазейка в защите системы.
Общая схема работы команды su выглядит так:
--------------------------------------------
|
| Получить информацию о пользователе: пользовательский идентификатор,
| групповой идентификатор, пароль, номер терминала, ...
| Если пароль пустой или пользовательский идентификатор равен нулю,
| То пройти мимо вопросов о пароле.
|
| Запрос пароля
| Если зашифрованный вариант того, что было только что набрано,
| не совпадает с парольной строкой из файла /etc/passwd,
| То запротоколировать неудачную попытку применения su,
| напечатать сообщение "sorry" (сожаление по поводу неудачи),
| выйти.
| Пароль прошел:
| запротоколировать успешную попытку применения su,
| выполнить системные вызовы для того, чтобы ввести в действие
только исполняемый модуль. Для реассемблирования объектного кода мож-
но применить отладчик (adb), но если только вы не имеете безумно
близкого знакомства с внутренностями системы UNIX, вам будет весьма
трудно представить себе, что происходит. Изощренные программы потай-
ной двери избегают также присутствия легко узнаваемых строк в испол-
няемых модулях. Вы можете, однако, применить команду strings (если
она есть в вашей системе) для поиска символьных строк, которые там
могли бы быть.
Одна из простейших ловушек для того, кто пытается добыть права
суперпользователя - создавать запись, помещаемую в протокольный файл.
При этом администраторам нужно следить за протокольными файлами, не
появляются ли там записи, которые могут быть признаком злодейства.
Ниже мы покажем вам инструментальное средство, которое автоматически
следит за одним из таких протокольных файлов - файлом sulog, содержа-
щим транзакции "замененного пользователя". Другой протокольный файл,
часто нуждающийся в проверке, это протокол программы uucp, потому что
эта программа может быть использована для несанкционированных пересы-
лок файлов. Многие нарушители пытаются проверить протокольные файлы и
удалить компрометирующие записи, сгенерированные при их вмешательст-
ве. В арсенале администратора есть средства борьбы с этим. Они не на
100 процентов эффективны, но отлавливают некоторых нарушителей и, ус-
ложняя им жизнь, могут отбить охоту вторгаться в систему.
В дополнение к обычным протокольным файлам, поддерживаемым сис-
темой UNIX, некоторые администраторы заводят свои собственные прото-
кольные файлы, а затем подправляют ключевые команды так, чтобы они
помещали данные в эти новые регистрационные файлы в процессе своей
работы. Это может помочь обезвредить неосторожных лазутчиков. Один
знакомый администратор сделал протокольный файл для команды cu и наз-
вал его /tmp/.../.culog. Довольно умный тайный фокус, но в
/usr/lib/crontab у него была запись для периодической печати этого
файла. Это его выдавало: нужно было маскироваться получше. Заметим
также, что ваши "скрытые" имена протокольных файлов могут быть извле-
чены путем просмотра исполняемого образа команды с помощью утилиты
strings.
Если у вас есть пользователь, от которого вы ожидаете чего-ни-
будь запрещенного, вы должны уметь установить специальную систему ре-
гистрации, которая запускала бы более совершенный механизм, когда та-
кой пользователь работает в системе. Программу watch из главы 6 можно
модифицировать так, чтобы она вызывала специальную протоколирующую
программу, когда в систему входит пользователь из известного списка.
Протоколирующая программа могла бы повторять команды ps (process
status, состояние процесса) и/или делать "моментальные снимки" обыч-
ных регистрационных файлов (особенно учетных файлов) и направлять ре-
зультаты в припрятанный протокольный файл. Идея состоит в том, что
опасные процессы можно было бы обнаружить до того, как нарушитель по-
лучает возможность войти в протокольные файлы и изменить их. (Видимо,
вам нужно избегать применения команды at в такой программе, а перио-
дически пользоваться вместо нее командой sleep. В противном случае,
нарушитель может распознать ваши мероприятия по записи файла
crontab.) Как только вы имеете результат о сеансе работы опасного
пользователя, вы можете запустить grep для поиска интересующих вас
имен или написать инструментальное средство, которое выполняет для
вас такой поиск.
Вероятно, наиболее важным среди протокольных файлов является
учетный файл. В учетном файле имеется запись о каждом и всяком про-
цессе, запускаемом в системе. Точную структуру можно посмотреть в
файле /usr/include/sys/acct.h. В одном из полей этой структуры запи-
саны процессы, имеющие суперпользовательские возможности.
Когда кто-либо входит в систему через корневую дверь, для shell-
интерпретатора, который он запускает, и для всех процессов, которые
он порождает, владельцем является корень (суперпользователь). В учет-
ном файле отражен номер терминала, с которого запущен процесс, поэто-
му вы можете увидеть корневые процессы, запущенные с таких термина-
лов, на которых пользователям не разрешен суперпользовательский
доступ.
Если у вас имеются обычные линии с набором номера, то все такие
записи могут представлять не одного и того же пользователя. Другие
входы в систему могут иметь одинаковый номер терминала, но разные
пользовательские идентификаторы. Однако, вы можете знать, кто обычно
имеет доступ к некоторым выделенным линиям.
Учетные файлы могут хорошо разоблачить процессы, имеющие не та-
кой пользовательский идентификатор, как у лица, запустившего эти про-
цессы. Поищите процессы, владельцем которых был известный пользова-
тель, но которые имеют суперпользовательские возможности. Среди них
могут быть корректные записи, например lpr, так как отображаются все
системные программы, запущенные со взведенным битом setuid. Записи,
которые мы ищем, относятся к shell-интерпретаторам с установленным
учетным флагом суперпользователя. Это выдает тот факт, что была вы-
полнена программа потайной двери. Изучите подключаемый файл acct.h,
чтобы увидеть все определения. Используя бит ASU для проверки поля,
мы можем изолировать флаговую область, отражающую привилегию супер-
пользователя. Самый лучший способ рассмотреть эту структуру - напи-
сать программу на языке Си, печатающую все элементы структуры. В сле-
дующей распечатке показаны некоторые важные учетные поля:
--------------------------
|
| cmd f uid tty btime
|
| more 0 russ 0 Sat Jul 5 01:25:59 1986
| ls 0 russ 0 Sat Jul 5 01:31:12 1986
| ps 0 russ 0 Sat Jul 5 01:31:59 1986
| id 0 russ 0 Sat Jul 5 01:34:00 1986
| pwd 0 russ 0 Sat Jul 5 01:34:12 1986
| sh 1% russ 0 Sat Jul 5 01:33:51 1986
| \__ корневой shell с эффективным пользовательским идентификатором
|
| sync 0 russ 0 Sat Jul 5 01:34:21 1986
| df 0 russ 0 Sat Jul 5 01:34:27 1986
| id 0 root 0 Sat Jul 5 01:34:37 1986
| sh 2# root 0 Sat Jul 5 01:34:33 1986
| \__ корневой shell с реальным пользовательским идентификатором,
| 2# обозначает бит суперпользователя,
| владелец изменен на root
|
Отметим, что shell-интерпретаторы с эффективным пользовательским
идентификатором маскируют бит во флаге суперпользователя, но владель-
цем их процессов является обычный пользователь. Не известно, все ли
системы применяют значение 1 в качестве флага shell-интерпретатора с
эффективным пользовательским идентификатором. Похоже, что Berkeley
поступает именно так, а System V нет.
КОМАНДА su
Как мы уже отмечали, UNIX предоставляет пользователям обычный
способ стать суперпользователем - это команда su. Как видно из преды-
дущего изложения, суть команды su заключается в системном вызове
exec. Тот, кто применяет команду su, должен знать корневой пароль,
транзакция протоколируется в файле /usr/adm/sulog, а команда ps огла-
шает тот факт, что активен корневой shell. Этот прием не самый хитро-
умный.
Помните о том, что НИКОГДА нельзя оставлять без присмотра терми-
нал, на котором вы работаете в качестве суперпользователя? Пока вы
отсутствуете, кто-то может воспользоваться этим терминалом, чтобы вы-
полнить команду chmod с целью установки бита пользовательского иден-
тификатора. Хорошо подготовленный нарушитель уже имеет откомпилиро-
ванную программу потайной двери, владельцем которой является
суперпользователь, и ждет, когда будут изменены права доступа. Не ос-
таются ли консольные терминалы доступными в качестве суперпользова-
тельских ночью, во время действий по резервному копированию? Если ос-
таются, то наутро администратор может оказаться в незавидном
положении!
БОЛЕЕ ПОДРОБНО О ПОЛЬЗОВАТЕЛЕ bin
Мы уже упоминали о "лазейке" в некоторых системах, позволяющих
пользователю "bin" без труда завладеть суперпользовательским досту-
пом. Проблема "bin" имеет еще ряд аспектов. Если несанкционированные
пользователи могут войти в систему через bin (являющийся владельцем
большинства дистрибутивных исполняемых модулей), то они почти навер-
няка смогут получить права суперпользователя. Прежде всего, в некото-
рых версиях владельцем всех исполняемых модулей, размещенных в ката-
логах /bin и /usr/bin, является bin. Это значит, что нарушители могут
перезаписать или подправить исполняемые модули своими собственными
вариантами, выполняющими некоторые особые действия, например "chmod
4755 door", а затем восстановить на место исходную версию исполняемо-
го модуля.
Еще один способ простого превращения bin в суперпользователя
заключается в модификации /etc/rc - файла запуска команд ("run
command"). Он запускается каждый раз, когда машина загружается в мно-
гопользовательском режиме. Записывая в него "chmod 777 /etc/passwd",
нарушитель может превратить парольный файл в обычный пользовательский
после того, как машина загрузится.
Последний способ - использовать файл /usr/lib/crontab. Этот путь
изменен в последней версии System V. Теперь полное имя этого файла
/usr/spool/cron/crontabs/xxx, где xxx - файл crontab для каждого
пользователя. В старом варианте владельцем файла /usr/lib/crontab
иногда является bin. Кто-нибудь может отредактировать этот файл и по-
местить в него такие, например, команды:
* * * * * chmod 777 /etc/passwd
* * * * * chmod 4755 /tmp/door
* * * * * /bin/su root -c "chmod 777 /etc/passwd"
Все это срабатывает по той причине, что cron выполняется процес-
сом init. Поскольку init - один из первых запущенных процессов, его
владельцем является суперпользователь. Поэтому любая команда, которую
выполняет cron, имеет корневые привилегии. Звездочки означают, что
cron должен выполнить указанные команды в очередной возможный момент
времени. Cron запускает процесс, изменяющий права доступа к указанно-
му файлу. Нарушители могут поменять парольный файл (что несколько бо-
лее опасно) или просто активизировать программу потайной двери. Если
две первые команды не сработают, то владелец будет изменен на супер-
пользователя методом грубой силы - выполнением команды su, а затем
передачей команды chmod shell-интерпретатору, запущенному командой
su. Вы должны почаще проверять файлы crontab и /etc/rc!
Это редко применяемый метод. Он предполагает, что обычный поль-
зователь имеет право на запись в исполняемый модуль или в специальный
файл. Если кто-то может писать в исполняемый модуль, скажем ls, то он
может поместить туда некоторый код, который устанавливает потайную
дверь, а затем заменяет себя настоящей утилитой. Это работает еще
лучше, когда эту команду запускает пользователь с корневыми возмож-
ностями, так как тогда команда выполняется как привилегированный про-
цесс. Такой способ упрятывания кода в программу с возможностью запус-
ка ее не вызывающим подозрения пользователем называется "троянским
конем". Он выглядит безвредным, но то, что спрятано у него внутри,
крепко бьет по защите системы. Как мы уже отмечали, периодическая
проверка контрольных сумм для стандартных исполняемых модулей - одно
из противоядий от "троянских коней".
Если нарушители овладевают возможностью чтения или записи файлов
устройств, они могут прочитать в этих файлах информацию о суперблоке
и файловой системе и получить доступ к любому файлу. Им может понадо-
биться пройти по файловой системе в поисках нужного файла, подправить
его и записать обратно в файл устройства. Люди, которые этим занима-
ются и совершают при этом ошибки, могут добиться краха всей системы.
Если файл устройства находится в памяти, пользователи могут
просматривать информацию о процессах или ядре непосредственно в памя-
ти. Может быть использован старый прием отслеживания списков clist на
предмет поступления пароля пользователя, входящего в систему. Это
требует больших знаний о том, где данная информация размещается в па-
мяти и как к ней добраться, поэтому этим методом пользуются, вероят-
но, только опытные нарушители.
В некоторых системах бывает, что после перезагрузки машины на
консоли работает суперпользовательский shell. Такое может произойти в
однопользовательском режиме или на микро-ЭВМ, служащей консолью для
большой машины. Очевидное решение - ограничить физический доступ к
консоли.
ИСПОЛЬЗОВАНИЕ ПРЕИМУЩЕСТВ ПЕРЕМЕННОЙ $PATH
Кое-кто может воспользоваться ситуацией, когда пользователь име-
ет каталог $HOME/bin впереди системных каталогов /bin и /usr/bin в
своей переменной PATH. Помещая подправленную программу в регистраци-
онный каталог безвредного пользователя, нарушитель заставляет эту
программу выполняться вместо настоящей, поскольку система исполняет
первый файл, совпадающий с именем команды, который она обнаруживает в
ходе просмотра определенного пользователем маршрутного списка. Приме-
ром могла бы служить команда ls.
Когда команда выполняется, она запускается с теми же правами
доступа, что и запустивший ее пользователь. Конечная цель нарушителей
- добиться прав суперпользователя, поскольку тогда они смогли бы вы-
полнить любую команду. Диверсионная программа может подготовить по-
тайную дверь для овладения правами суперпользователя или даже нес-
колько таких дверей. Она может удалить себя, чтобы при очередном
вызове данной команды выполнялась настоящая команда. Настоятельная
необходимость для администратора - проверять наличие в рабочем прост-
ранстве опасных файлов (в частности, исполняемых модулей).
Мы не слышали, чтобы кто-либо это делал, но имеет смысл от этого
защититься. Старательный нарушитель мог бы сначала подготовить правки
для системы, поместить их на ленту и переслать их вам, администрато-
ру. Вы, вероятно, предположили бы, что это правильные модификации
системы и установили бы их. И ваша система получила бы "подарочек" от
нарушителя. Поэтому администратор может захотеть сверить новые версии
с их изготовителем перед тем, как устанавливать их у себя.
Хотя мы не можем дать гарантию, что кто-нибудь смекалистый не
опишет, как расколоть парольную защиту, кодирование пароля в системе
UNIX по алгоритму DES считается довольно секретным. (Рассмотрение ме-
ханизма DES выходит за пределы данной книги.) К этой защите добавля-
ется одна вещь - два символа, генерируемые случайным образом, называ-
емые "солью" (salt) и хранимые в файле /etc/passwd для каждой записи.
"Соль" используется для определения того, какой из 4096 вариантов ал-
горитма DES применяется для кодирования заданного пароля. Нарушитель
мог бы захватить пароль, использовать его "соль" и зашифровать список
известных паролей. Если бы результат совпадал с пробным паролем,
взлом был бы осуществлен.
Нарушителю пришлось бы иметь доступ к некоторой довольно чувс-
твительной методике, чтобы добиться своего. Нелишняя мера, которую
может предпринять администратор,- следить за чрезмерным использовани-
ем команды crypt (если она есть в вашей системе). Эта команда специ-
ально сконструирована так, чтобы занимать много процессорного времени
- не настолько много, чтобы причинять неудобства законным пользовате-
лям, но достаточно много, чтобы выявить попытки автоматизированного
взлома.
Западня работает только на специально выделенных линиях. Когда
UNIX ожидает, что кто-то будет входить в систему, она печатает ре-
гистрационную строку из файла /etc/gettydefs. Пользователь вводит
свое регистрационное имя и пароль и попадает в систему.
Программа западни извлекает из этого выгоду. Она имитирует пове-
дение экрана во время регистрации. Когда пользователь вводит свое имя
и пароль, такая программа печатает сообщение "login incorrect" ("не-
верная регистрация"), а затем запускает настоящую регистрационную
программу. Пользователь думает, что он сделал ошибку и повторяет по-
пытку входа в систему, на этот раз успешно. Регистрационное имя и па-
роль можно куда-нибудь отложить для последующего изучения. Самая луч-
шая защита администратора от этого - обучение пользователей. Видимо,
с помощью регулярной почты или бюллетеней нужно напоминать им, что
если им кажется, что они набрали пароль правильно, но получили при
этом сообщение "incorrect", то они должны немедленно сменить свой па-
роль и сообщить об этом происшествии администратору. Бывают случаи,
когда пользователь действительно ошибается при вводе пароля, но к
большому количеству таких происшествий нужно отнеститсь со всей серь-
езностью.
Команда монтирования была создана для того, чтобы позволить при-
соединять к системе несколько дисковых устройств. Раньше, в эпоху ми-
никомпьютеров единственным видом дисковых устройств были большие на-
копители, в которые вставлялись большие дисковые пакеты. Они обычно
находились в машинном зале, и только администратор монтировал их.
Теперь многие системы имеют гибкие диски. Они гораздо персональ-
нее и намного меньше, чем большие дисковые пакеты. Это уменьшение
размера ощутимо воздействует на важность самого объекта. Похоже, что
теперь каждый пользователь может иметь дело со своими дисками, и ад-
министратору больше нет необходимости заниматься этим. Такой сценарий
работы приводит к следующему.
Обычное действие, предпринимаемое в небольших системах для того,
чтобы дать пользователям возможность работать с их собственными гиб-
кими дисками,- это установка бита пользовательского идентификатора
для файла команды /etc/mount. Таким образом, когда запускается коман-
да монтирования, ее пользовательский идентификатор становится корне-
вым, и она может смонтировать гибкий диск. Команда демонтирования
должна быть подготовлена аналогично.
Кто-то может извлечь выгоду из того, что команда mount может по-
лучить во время своей работы права суперпользователя. Обычно в не-
больших системах одна машина открыта для экспериментов несанкциониро-
ванного пользователя. Он может стать суперпользователем в вашей
системе, подготовить программу потайной двери и поместить ее на гиб-
кий диск. Владельцем является суперпользователь, а права доступа
4755. Затем нарушитель может размонтировать гибкий диск и войти в за-
щищенную систему.
С этого момента нарушитель может просто входить в систему как
обычный пользователь, без всяких специальных прав доступа и монтиро-
вать гибкий диск, на котором имеется программа потайной двери. Когда
гибкий диск монтируется, файловая система гибкого диска встраивается
в файловую систему жесткого диска, и две системы сливаются в одну.
Это означает, что потайная дверь для овладения правами суперпользова-
теля готова для файловой системы на жестком диске.
Когда нарушитель запускает программу потайной двери на гибком
диске, происходит то же самое, что происходило бы, если бы эта прог-
рамма была на жестком диске. Мера предотвращения - контролировать ис-
пользование команды mount в вашей системе. Доступ к команде mount
должен быть ограничен определенным кругом пользователей, она не долж-
на разрешать монтировать файлы с установкой пользовательского иденти-
фикатора.
АВТОНОМНЫЙ shell (SASH)
В системах UNIX с гибкими дисками загрузочный диск обычно загру-
жается с гибкого накопителя. Подразумевается, что гибкий диск приме-
няется для подготовки жесткого диска и копирования всех файлов систе-
мы UNIX с гибкого диска на жесткий. Но за этим кроется нечто большее.
На самом деле загружаемый гибкий диск - это компактная, перено-
симая версия системы UNIX. Ядро адаптировано к тому, чтобы размещать-
ся на гибком диске, а не на жестком. Когда вы его загружаете, вы по-
лучаете интерпретатор shell и среду точно так же, как при работе с
жесткого диска. Вот почему такой shell называется автономным (SASH,
standalone shell).
Корневая файловая система на гибком диске даже выглядит точно
так же, как файловая система жесткого диска. Фактически вы можете
смонтировать загружаемый диск и скопировать утилиты с жесткого диска
на гибкий. Нужны две важные команды: mount и umount. Ограничением яв-
ляется размер гибкого диска. На него не так много помещается.
Сценарий, с помощью которого несанкционированный пользователь
может применить SASH для входа в систему с суперпользовательскими
привилегиями, выглядит примерно так. Сначала он должен отключить пи-
тание или перезагрузить защищенную систему. Затем он должен загрузить
SASH и смонтировать корневую файловую систему жесткого диска в точку
монтирования своей файловой системы гибкого диска. Команды могут быть
такими:
# /etc/mount /dev/fp001 /mnt <-- для System V
# /etc/mount /dev/hd0a /mnt <-- для XENIX
Это дает нарушителям доступ на жесткий диск при помощи обращения
/mnt/*. Все, что им нужно для редактирования файла /etc/passwd - это
пройти вниз по дереву каталогов. Для этого можно применить такие ко-
манды:
# /mnt/bin/vi /mnt/etc/passwd
# sync
Теперь жесткий диск изменен, и его можно вернуть на место. Нару-
шитель может остановить автономный вариант UNIX и перезагрузиться с
жесткого диска. Он может использовать новое регистрационное имя, соз-
данное при помощи SASH. Мы не знаем, насколько часто люди могут
предпринимать такие попытки. Небольшие системы более уязвимы, но в
них и меньше пользователей (и потенциальных злодеев). Во многих слу-
чаях нижней границей "логической защиты" становится "физическая защи-
та". Большинство людей, имеющих большие машины или даже мини-ЭВМ,
постоянно осознают, что им есть что защищать. А микро-ЭВМ выглядят
настолько "дружественными" и простыми, что люди обычно забывают, что
информация, которая содержится на микрокомпьютерах, при определенных
обстоятельствах может оказаться настолько же желаемой и значительной,
как и на больших машинах.
Чаще всего правки исходных текстов являются самым мощным, хотя и
не самым легким способом проникновения нарушителей в систему. Внедряя
свой собственный код в подходящих местах, несанкционированные пользо-
ватели могут извлечь всю секретную информацию, которая им нужна. Од-
нако, правки кода могут быть полезны также и для администратора. Ад-
министратору может понадобиться внести правки в регистрационную
программу, чтобы посмотреть, кто и как часто пытается зарегистриро-
ваться на машине. Другой вариант - внесение правок в программы с ус-
тановкой пользовательского идентификатора и в другие доступные огра-
ниченному кругу лиц программы, чтобы они регистрировали свой сеанс
работы в секретном протокольном файле.
Еще одно место, в котором нужно следить за несанкционированными
правками - библиотеки ядра. Подправленные объектные модули можно лег-
ко поместить в библиотеки незамеченными. Другим библиотекам грозит та
же опасность. Дополнительные разумные усовершенствования ядра можно
обнаружить в системных вызовах chmod и chown. Когда выполняются эти
системные вызовы, они проверяют, имеете ли вы пользовательский иден-
тификатор 0. Если нет, то ваш запрос не удовлетворяется. Отменив эту
проверку, любой обычный пользователь мог бы изменить владельца файла
на суперпользователя, а также изменить режим защиты файла, чтобы
взвести бит установки пользовательского идентификатора. Это позволило
бы успешно обойти защитный барьер.
ПРОГРАММА passwd
Программа passwd - охранник ворот системы UNIX. Точно так же,
как многие древние города пали из-за того, что враги подкупили охран-
ника ворот, так и хорошо защищенная система UNIX может быть превраще-
на в широко открытую, если кто-либо подправит эту программу. Посколь-
ку пользователи применяют программу passwd для изменения своих
паролей, подправленная версия может записывать новый пароль, вводимый
пользователем для изменения, в секретный файл, принадлежащий наруши-
телю. Это может обесценить каждый вновь создаваемый в системе пароль.
Внутри программы passwd пароль является просто символьным массивом,
поэтому с этими данными легко управиться.
ПРОГРАММА crypt
Потенциальной правкой программы шифрования файлов crypt может
быть накопление имен файлов и ключей шифра при каждом использовании
программы. Таким методом вы можете проследить, кто запускает эту ко-
манду, какой файл он использует и какой ключ применяется для того,
чтобы получить доступ к этому файлу.
Неприятности, связанные с последними двумя случаями, заключаются
в том, что кто-нибудь может разрушить меры системной безопасности.
Если вы считаете, что в вашей системе есть заманчивые, важные данные,
то вам как администратору следует почаще проверять эти программы (по
контрольной сумме или сравнением) на предмет повреждения.
КОМАНДА su
Поскольку команда su предоставляет суперпользовательский доступ
для обычных пользователей, имеющих корневой пароль, это еще одна по-
тенциальная лазейка в защите системы.
Общая схема работы команды su выглядит так:
--------------------------------------------
|
| Получить информацию о пользователе: пользовательский идентификатор,
| групповой идентификатор, пароль, номер терминала, ...
| Если пароль пустой или пользовательский идентификатор равен нулю,
| То пройти мимо вопросов о пароле.
|
| Запрос пароля
| Если зашифрованный вариант того, что было только что набрано,
| не совпадает с парольной строкой из файла /etc/passwd,
| То запротоколировать неудачную попытку применения su,
| напечатать сообщение "sorry" (сожаление по поводу неудачи),
| выйти.
| Пароль прошел:
| запротоколировать успешную попытку применения su,
| выполнить системные вызовы для того, чтобы ввести в действие