Читать онлайн «ТЕХНИКА СЕТЕВЫХ АТАК». Страница 52

O Атака на HTTP-клиента

O Устройство почтового сервера

O Анонимная рассылка корреспонденции

O Анонимное получение корреспонденции

O Постиг сообщений в модерируемые конференции

O Безопасность Java-приложений

В основе межсетевого общения лежат протоколы - соглашения, выполняемые сервером и клиентом. А сетевые атаки, в свою очередь, базируются либо на ошибках реализаций протоколов, либо используют уязвимости самих протоколов. В главах «Атака на Windows NT» и «Атака на Windows 95» уже упоминался прикладной протокол SMB, слабости реализации которого позволяют злоумышленнику подбирать пароль для входа в систему, устанавливать подложный именной канал и т.д.

Реализации других протоколов также порой далеки от совершенства и часто позволяют злоумышленнику выполнять действия никак не запланированные ни разработчиками, ни администратором системы. Следует различать понятия «протокола» от «реализации протокола». Сам протокол - это только набор соглашений, правил и договоренностей, записанный на бумаге [184]. Реализация протокола - «живая» действующая программа, со всеми присущими ей программными ошибками.

Ошибкам подвержены как сами протоколы, так и их реализации (причем реализации гораздо чаще). Но ошибки реализации устраняются программными заплатками, а недостаток защищенности протокола можно рассматривать как концептуальную уязвимость. Например, UDP протокол работает без установки соединения и не гарантирует, что полученный пакет был действительно отправлен отправителем, а не кем-то еще, кто вздумал подделать его адрес. Это создает возможность внедрения ложных объектов в сеть, и часто приводит к успешным атакам.

Собственно, незащищенность UDP протокола еще не повод объявлять этот протокол «плохим», ведь ничто не хорошо и не плохо само по себе. А вот бездумное применение UDP протокола, в ответственных ситуациях, чувствительных к подделке адреса отправителя - плохо, ибо приводит к уязвимости. Так, DNS сервер, работающий на UDP протоколе, позволяет злоумышленнику отправлять ответы от имени DNS, и программное обеспечение жертвы вместо соединения с положенным сервером, неожиданно (и незаметно!) для нее подключается к машине злоумышленника! И жертва, не подозревая подлога, доверчиво передаст свой пароль на «вражеский» узел!

Другой пример: протокол SMTP не требует авторизации и позволяет злоумышленнику рассылать письма, используя чужие сервера. Исправление этой очевидной ошибки (хотя при разработке протокола она не была такой очевидной, ведь в то время спамеров еще не существовало) оказалось сопряжено со значительными трудностями.

Устранение недостатков протоколов автоматически не исправляет существующее программное обеспечение! Любой мало-мальски популярный протокол может иметь многие тысячи реализаций серверных и клиентских приложений, созданных различными, никем не координированными, разработчиками. Нужны очень веские доводы, чтобы склонить всех разработчиков, администраторов и пользователей перейти на новый стандарт. Даже если он имеет неоспоримые преимущества, его внедрение может растянуться на несколько лет. Но появление новых протоколов не приводит к полному отказу от старых, и они мирно уживаются рядом друг с другом.

Ниже будут подробно рассмотрены наиболее популярные протоколы, и описаны некоторые ошибки их реализаций. В большинстве книг изложение традиционно начинается с изучения транспортных протоколов, а затем переходят к прикладным. Но такой подход имеет, по крайней мере, один существенный недостаток: читатель в первых главах не может «пощупать» предмет изучения и должен довольствоваться сухой теорией. Напротив, работу прикладных протоколов легко продемонстрировать простыми экспериментами.

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

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

O История возникновения telnet

O Задачи, решаемые с помощью протокола telent

O Виртуальные терминалы

O Передача команд в потоке

O Краткое описание команд telnet

O Алгоритм Нагла

O Перехват и расшифровка сессии telnet-клиента с сервером

O Краткая история возникновения протокола rlogin

O Задачи, возлагаемые на rlogin

O Передача команд протокола rlogin

O Кратное описание команд протокола rlogin

O Обзор telnet-клиентов

O Конфигурирование telnet-клиента, входящего в поставку Windows 2000

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

Протокол telnet один из старейших в сети. Он разрабатывался в конце шестидесятых годов, когда слово “Internet” еще не существовало, а кабель, соединяющий несколько узлов, гордо именовался «сетью ARPANET». Тогда telnet составлял основу сети, и относился к фундаментальным протоколам - большинство узлов общались друг с другом именно посредством telnet. Со временем его вытеснили новые специализированные протоколы, и он потерял свою главенствующую роль. Сегодня telnet используется практически только для удаленного администрирования UNIX-серверов.

Telnet - прикладной протокол, реализуемый поверх транспортного TCP-протокола. Он обеспечивает дуплексный, 8-битный канал между участниками соединения и поддерживает виртуальные терминалы. По умолчанию для подключения к telnet-серверу необходимо установить соединение по 23 порту.

Виртуальный терминал (NVT - Network Virtual Terminal) это мнимое символьное устройство с клавиатурой и принтером. Данные, набранные на клавиатуре, отправляются серверу, а ответ сервера печатается на принтере. Под «клавиатурой» и «принтером» подразумеваются некие мнимые устройства. В действительности ответ сервера вовсе не обязательно выводить на настоящий принтер, вместо этого обычно используется экран.

Виртуальный терминал позволяет согласовать форматы представления данных обеих сторон, ширину и высоту экрана и т.д. Соответствие между мнимыми и физическими устройствами узла должна обеспечить реализация протокола.

Подробнее о виртуальном терминале рассказано ниже, в конце этой главы.

Протокол telnet использует довольно оригинальный способ передачи команд, называемый команды в потоке (in-band signaling), заключающийся в следующем: любой байт из интервала [0x0, 0xFF) [185] интерпретируется как данные, а байт 0xFF, называемый IAC (Interpret As Command - интерпретировать как команду), указывает на то, что следующий за ним байт является командным байтом. Если возникнет необходимость передать байт данных, равный 0xFF, его следует продублировать, т.е. отправить два байта 0xFF 0xFF.

Командный байт может принимать следующие значения, перечисленные в таблице (необходимые объяснения даны ниже).

???? Имя Код Пояснения

???? EOF 0xEC Конец файла

???? SUSP 0xED Приостановить текущий процесс

???? ABORT 0xEE Прекратить процесс

???? EOR 0xEF Конец записи

???? SE 0xF0 Конец подопции

???? NOP 0xF1 Нет операции

???? DM 0xF2 Маркер данных

???? BRK 0xF3 Прерывание

???? IP 0xF4 Прервать процесс

???? AO 0xF5 Прекратить вывод

???? AYT 0xF6 Есть кто живой?

???? EC 0xF7 Удалить последний введенный символ

???? EL 0xF8 Стереть строку

???? GA 0xF9 Идти дальше

???? SB 0xFA Начало под опции

???? WILL 0xFB Обсуждение опции

???? WONT 0xFC Обсуждение опции

???? DO 0xFD Обсуждение опции

???? DONT 0xFE Обсуждение опции

???? IAC 0xFF Байт данных 0xFF

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

· End Of File - конец файла. Получатель команды уведомляет процесс, подсоединенный к NVT терминалу, что был достигнут конец файла. В настоящее время эта команда не используется.

· (сокращение от Suspend - приостановить) «замораживает» связанный с NVT процесс и передает управление другому процессу. «Замороженный» процесс позднее сможет продолжить свое выполнение с той же самой точки. Эта команда в настоящее время игнорируется большинством получателей.

· End of Record - конец записи. Аналогично EOF. Подобно эта команда описана в RFC-885.

· No operation - нет операции. Эта команда обычно используется для проверки работоспособности сессии. Если соединение с получателем разорвано, то попытка посылки NOP приведет к ошибке TCP/IP. Некоторые сервера периодически посылают NOP, чтобы убедится в активности клиента.