Дополнение. Обзор telnet клиентов

Атака на telnet и rlogin -сервера

• 
  В этой главе:
  
• 
  Ошибки реализации telnet-серверов
  
• 
  Перехват пароля, передаваемого протоколом telnet
  
• 
  Манипуляция переменными окружения
  
• 
  Модификация файла rhosts
  

Сегодня протокол telnet используется в основном для удаленного администрирования, но, кроме этого, telnet серверы часто устанавливаются на многих служебных узлах сети, например, маршрутизаторах. Многие операционные системы, устанавливают telnet сервер по умолчанию, даже когда он совсем не нужен. Распространенность telnet не так уж и велика, но и он иногда становится объектом атак злоумышленников.

Как и любая другая программа, telnet сервер подвержен угрозе срыва стека, что позволяет выполнить на удаленной машине любой код или, по крайней мере, заблокировать сервер («завесить» его). Атаки, основанные на срыве стека, подробно описаны в главе «Технология срыва стека», здесь же будут рассмотрены уязвимости, характерные именно для telnet.

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

Например, InterAccess TelnetD Server 4.0, работающий под управлением Windows NT, помещает имя, введенное пользователем при регистрации, в буфер фиксированного размера, но не контролирует его длину. Это позволяет злоумышленнику исполнить свой код на удаленном сервере. Сервер BFTelnet Server v1.1 содержит практически идентичную ошибку, за исключением того, что не позволяет злоумышленнику «подсунуть» свой код, но допускает «завешивание» системы.

Другой пример: если на CISCO 2621при включенном NAT (Network Address Translation) злоумышленник, находящийся во внешней сети, устанавливает TCP соединение во внутреннюю сеть по 23 порту, то система скидывает ласты. Эту ошибку впервые обнаружил Blue Boar, связаться с которым можно, написав по адресу BlueBoar@THIEVCO.COM

Ошибки, описанные выше, демонстрируют принципиальную возможность атак на telnet службы, но уже давно неактуальны. Однако, помимо ошибок реализаций, сам протокол telnet содержит концептуальные уязвимости, две их которых рассмотрены ниже.

В базовой спецификации telnet протокола, декларированной в RFC 854, не содержится никаких средств аутентификации. Пароль и имя пользователя посылаются открытым текстом (причем в зависимости от режима каждый символ может либо помешаться в отдельный пакет, либо в пакет упаковывается вся строка целиком, но, поскольку используется алгоритм Нагла, даже в символьном режиме пароль может быть передан всего в двух пакетах, подробнее об этом рассказано в главе «Протоколы telnet и rlogin»).

Если канал связи не защищен от прослушивания (а практически всегда так и есть), то злоумышленник, перехватив пакеты, сможет восстановить имя пользователя и пароль. Широковещательная среда локальных Ethernet сетей позволяет осуществить такой перехват без труда, а в глобальных сетях существует угроза «подмятия» DNS сервера и подмены адреса узла, с которым пользователь пытается установить соединение. Подробнее об этом рассказано в главе «Атака на DNS сервер», которая находится во втором томе настоящей книги.

Современные реализации telnet, однако, уже поддерживают шифрование паролей при аутентификации. Например, клиент от Windows 2000, поддерживает NTLM шифрование, которое достаточно надежно. Перехват канала связи не позволяет злоумышленнику восстановить пароль (подробнее об этом рассказано в главе «Атака на Windows NT»). Однако до сих пор во многих случаях на сервер передаются незашифрованные пароли, и вся атака сводится к их перехвату.

Другая уязвимость заключается в возможности клиента манипулировать переменными окружения сервера до аутентификации. Впервые такая возможность упоминается в RFC 1408, затем в RFC 1572, и поддерживается многими современными telnet серверами. Если атакующий имеет доступ к серверу на запись (например, на нем установлен ftp-сервис, позволяющий анонимному пользователю закачивать файлы), то изменением переменных окружения, таких, как PATH, легко добиться, чтобы вместо легальных программ, запускались программы злоумышленника. Таким образом, злоумышленник получает право удаленного запуска программ, от имени другого пользователя, а иногда и системы!

Известен случай, когда злоумышленник изменил стандартную Си-библиотеку libc, таким образом, чтобы при вызове некоторых функций активировался скрытый в ней троянский конь, который выполнял задуманные действия, а затем уничтожал модифицированную библиотеку, заметая следы. Затем он помещал ее в любой каталог, доступный для записи по ftp и с помощью telnet-сервера менял переменную окружения, указывающую путь к библиотечным файлам. Когда один из пользователей сервера компилировал очередную программу, линкер использовал подложенную библиотеку! Обнаружить такую атаку оказалось нелегко. Ведь злоумышленник выполнял легальные, не привлекающие внимания действия, а изучать откомпилированный код никому бы и в голову не пришло! На переменные же окружения редко кто обращает внимание, как и на захламленные каталоги incoming.

Но даже после этого случая далеко не все администраторы запретили удаленную модификацию переменных, поэтому, в сети существует множество узлов, уязвимых перед описанной атакой.

Сервера, поддерживающие протокол rlogin, значительно меньше распространены, но все же иногда встречаются. Аналогично ранним реализациям telnet, протокол rlogin передает пароль в открытом виде (если передает). Это позволяет похитить его тривиальным перехватом. Но, в отличие от telnet, с помощью rlogin нельзя войти на сервер с правами администратора. Такое ограничение уменьшает интерес злоумышленников, но, разумеется, не исключает возможности атаки.

В файле “.rhosts”, хранящемся на удаленном сервере, содержатся имена доверенных узлов, аутентификация которых не требуется. Если удастся каким-то образом модифицировать этот файл, например, используя ошибки реализаций других протоколов (а такая ситуация действительно, порой имеет место), злоумышленник сможет внести себя в список доверенных узлов и войти на сервер без предъявления пароля!

Точно так, если злоумышленник сумеет проникнуть в один из доверенных узлов (или в доверенный доверенного), он автоматически получит доступ на сервер. Часто администраторы оказываются не очень щепетильны в выборе своих «друзей» и доверяют плохо защищенным (или совсем не защищенным) узлам.

Таким образом, протоколы telnet и rlogin очень плохо защищены и могут быть подвержены атаке.