Защита информации в Интернет

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



Службы удаленного вызова процедур (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).

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