После успешной установки соединения, клиент переходит в рабочий режим. А вернутся в командный помогает нажатие сочетания клавиш «Ctrl-]». Находясь в командном режиме, можно в любой момент закрыть активное соединение командой “close” или выйти из клиента (с закрытием соединения) командой “quit”. Для того чтобы переключится в рабочий режим необходимо нажать клавишу «Enter».

Две команды “set” и “unset” позволяют управлять параметрами клиента. Доступны следующие опции (для того, что бы получить их список достаточно набрать знак вопроса после команды set или unset):

· NTLM - посылать серверу при аутентификации только NT хеш (подробнее об этом рассказано в главе «Атака на Windows NT»)

· LOCAL_ECHO эхо-отображение символов, набираемых на клавиатуре

· TERM тип терминала (ANSI, VT100, VT52 или VTNM)

· CRLF завершать каждую строку символами CR (0xD) и LF (0xA)

Команда set устанавливает требуемую опцию (например, set LOCAL_ECHO включает эхо-отображение), а команда unset соответственно сбрасывает (unset LOCAL_ECHO выключает эхо-отображение).

Врезка «замечание»

Установка опции “NTLM” приведет к тому, что аутентификация на сервере, не поддерживающего этот режим, окажется невозможна. Подробнее об этом рассказано в главе «Атака на Windows NT». Наоборот, если на сервере иные методы аутентификации, за исключением NTLM запрещены, сброс этой опции приведет к невозможности войти на сервер.

Но telnet-клиенты могут использоваться не только для работы с telnet-серверами. Прозрачность telnet-протокола позволяет использовать telnet-клиента в качестве универсального клиента для любых протоколов, базирующихся на TCP.

В этом случае telnet-клиент играет роль утилиты, которая умеет отображать на экране данные, принятые от сервера и посылать серверу данные, введенные пользователем. Именно для этого telnet-клиент часто используется в данной книге.

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

O В этой главе:

O Ошибки реализации telnet-серверов

O Перехват пароля, передаваемого протоколом telnet

O Манипуляция переменными окружения

O Модификация файла 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 сервер», которая находится во втором томе настоящей книги.