Краткое содержание «Техника сетевых атак»
жүктеу/скачать 3.83 Mb.
|
- Бұл бет үшін навигация:
- Врезка «для начинающих» *
- Рисунок 008 Подключение к почтовому серверу
- Рисунок 000 Приветствие сервера
- Рисунок 006 Декодирование сообщения, переданного в формате MIME
- Рисунок 007 Подключение к серверу mail.ru
- Рисунок 004 Приглашение сервера mail.ru
Атака на telnet-клиента
Точно как и сервера, telnet клиенты подвержены угрозе срыва стека. В частности, telnet клиент, входящий в состав Windows 95, Windows 98 и даже Windows 98 SE, не проверяя длину аргументов командной строки, копирует ее в буфер фиксированного размера. Специальным образом подобранная строка позволяет злоумышленнику выполнить любой код на компьютере клиента. Один из возможных способов атаки заключается в размещении на WEB страничке ссылки следующего вида: telnet://server.com/xxxxxxxx. Стоит жертве кликнуть по ней мышкой, как браузер автоматически запустит telnet клиента, передав ему аргументы в командной строке (поэтому не стоит кликать по чему попало – простым кликом можно подпустить лапти на свой компьютер). Однако, присутствие одной и той же ошибки на клиенте всех трех платформ, возводит эту атаку, основанную на заурядном срыве стека, в ранг актуальных угроз. От пользователя не требуется никаких экзотических или настораживающих действий, большинство переходит по ссылкам, абсолютно не интересуясь их содержимым, поэтому значимость этой уязвимости для злоумышленников очень велика. Подробнее об этом можно прочитать в Microsoft Security Bulletin (MS99 033)189. Фирма Microsoft выпустила заплатки, которые находятся на ее сервере. Для Windows 95 здесь: http://www.microsoft.com/windows95/downloads/contents/WUCritical/Telnet/Default.asp, а для Windows 98 и Windows 98 SE здесь: http://www.microsoft.com/windows98/downloads/contents/WUCritical/Telnet/Default.asp . С 10 сентября 1999 года заплатки доступны и через Windows Update. Однако большинство пользователей оказалось не осведомлено об этой проблеме и лишь у немногих из них установлены необходимые обновления. Поэтому, возможность атаки все еще остается. Если telnet клиент работает с драйвером ANSI, поддерживающим макрокоманды, то существует возможность выполнять любые команды на компьютере клиента. Однако, такая ситуация встречается достаточно редко. Большинство ANSI терминалов ограничиваются поддержкой цветов и дополнительных наборов символов, но не позволяют удаленному компьютеру передавать макросы. Клиенты rlogin в силу своей простоты обычно не содержат грубых ошибок и в общем случае не могут быть атакованы. Однако некоторые реализации не ограничивают длину буфера запоминаемых данных. Клиенты rlogin, получив сигнал срочности, должны запоминать принимаемые данные до тех пор пока с последним байтом срочных данных не получат от сервера команду. Если же сервер злоумышленника станет забрасывать клиента огромным количеством бессмысленных данных, и «забудет» передать команду, то рано или поздно вся оперативная и виртуальная память клиента истощатся и наступят ласты. Впрочем, учитывая тот факт, что большинство клиентов не обладают быстрыми каналами потребуется чрезвычайно длительный промежуток времени чтобы эффект от такого воздействия стал заметным. История вообще пишется ретроспективно, и чем дальше от описываемых событий, тем она выглядит значительнее и красивее. Het Monster. Тринадцать врат Протокол POP3
Протокол POP3 (Post Office Protocol version 3) был разработан для удаленного управления почтовыми ящиками и доставке корреспонденции с сервера-почтальона на компьютер клиента. Лет десять – двадцать тому назад количество абонентов сети еще не измерялось астрономическими цифрами, а большинство узлов представляли собой круглосуточно работающие майнфреймы. Если возникала необходимость отправить письмо, устанавливали соединение с компьютером получателя, на котором был заведен особый, так называемый, «почтовый» файл и дописывали свое сообщение в его конец. В любое время получатель мог открыть этот файл средствами операционной системы и просмотреть его содержимое. Но с разрастанием сети такой подход становился все менее и менее удобным: компьютер получателя мог быть перегружен или вовсе отсоединен от сети, – иной раз проходило немало времени, пока до него удавалось «достучаться». Сегодня подавляющее большинство абонентов Internet составляют «персональные» пользователи, которые не могут позволить себе держать круглосуточную связь и входят в сеть лишь на короткое время. Поэтому, появились специализированные почтовые сервера, занимающиеся приемом и накоплением почты. В любой момент пользователь мог подсоединиться к такому серверу и разом принять всю поступившую на его имя корреспонденцию. Несмотря на то, что существующие протоколы позволяли осуществить такое взаимодействие без труда, необходимость стандартизации общения клиента с сервером, привела к возникновению новых, узкоспециализированных протоколов. Наибольшую популярность на сегодняшний день завоевал протокол POP3, который поддерживает несколько простейших команд, обеспечивающих базовые операции управления почтовым ящиком и доставку почты на локальный компьютер, перекладывая все заботы по ее обработке клиентскому программному обеспечению. Протокол POP3 ведает исключительно доставкой корреспонденции с сервера на компьютер клиента, а отправкой почты занимаются другие протоколы (как правило, для этой цели используется протокол SMTP, описанный в одноименной главе). Здесь не будут рассматриваться механизмы регистрации нового клиента на сервере, поскольку обсуждение этого вопроса выходит за рамки возможностей протокола POP3. Для всех последующих экспериментов необходимо иметь уже существующий почтовый ящик, причем, желательно непустой (а, если писем все нет и нет, на худой конец можно послать пару сообщений самому себе).
Если используется telnet клиент из поставки Windows 2000, то подготовительные операции могут выглядеть так: нажатие комбинации клавиш “ Оба клиента запоминают последнюю используемую конфигурацию и в дальнейшем их можно вызывать из командной строки, например, следующим образом: “telnet.exe имя узла 110”.
Если адрес сервера и порт указаны правильно, а сам сервер не находится в глубоком «дауне», через некоторое время (в зависимости от загруженности и скорости канала связи) будет установлено TCP соединение, и на экране появится приветствие, приглашающее к началу работы (смотри рисунок 000). Содержимое приветствия может варьироваться в широких пределах. Так, например, в приведенном примере сервер возвратил название и версию реализации программного обеспечения. С этого момента сервер готов принимать запросы пользователя, если же тот в течение длительного времени не проявит никакой активности, соединение будет разорвано (на жаргоне это звучит «выгнали по тайм-ауту»). Чаще всего время бездействия ограничивается десятью минутами, но администраторы некоторых интенсивно используемых серверов, иногда уменьшают его до десятков секунд! 
Рисунок 000 Приветствие сервераВ дальнейшем, дабы не приводить расточительные копии экрана, в книге будет использоваться содержимое окна telnet, представленное в удобочитаемой текстовой форме. Во избежание путаницы, команды, набираемые пользователем, будут выделяться таким, а ответы сервера - таким шрифтом. Сразу же с момента выдачи приглашения сервер переходит в состояние аутентификации (Authorization state) – ожиданию имени пользователя и пароля, открывающего доступ к почтовому ящику. Команда «user» служит для передачи имени пользователя, которое должно быть отделено от команды пробелом. Например, это может выглядеть так:
Если сервер подтверждает наличие указанного пользователя в системе, он требует сообщить пароль. Для передачи пароля предусмотрена команда “PASS”. В отличие от имени пользователя, пароль необходимо вводить с соблюдением регистра – в большинстве случаев (но не всегда) строчечные и заглавные символы различаются. Ниже приведен пример аутентификации пользователя с регистрационным именем “Orion” и паролем “Ngc1976”:
Если сервер подтверждает корректность пароля, он открывает доступ к ящику и сразу же информирует о его состоянии. В приведенном выше примере в ящике содержатся четыре письма с общим объемом в 789 046 байт190. Врезка «замечание»При перегрузке сервер может разорвать соединение, попросив пользователя повторить попытку немного позже. Например:
Иногда, по каким-то причинам почтовый ящик бывает временно недоступен. К примеру, при разрыве соединения, сессия с пользователем может удерживаться до десяти (а иногда и свыше тридцати!) минут – в течение этого времени попытки входа на ящик будут блокироваться. В случае несовпадения пароля сервер, выдержав паузу (предусмотренную для предотвращения перебора паролей), сообщит об ошибке и разорвет соединение. Например, это может выглядеть так:
С момента подтверждения корректности пароля, сервер переходит в, так называемое, состояние транзакции (Transaction state), и ожидает от пользователя команд управляющих почтовым ящиком или доставляющих корреспонденцию на его локальный компьютер. С пересылкой сообщений связано одно существенное ограничение протокола POP3, которое особенно неприятно для неанглоязычных корреспондентов. Стремясь увеличить скорость обмена между сервером и клиентом, американские разработчики (а протокол POP3 разработали именно они) решили пожертвовать одним битом, отводя на каждый символ семь бит, вместо положенных восьми.
Врезка «замечание»По причине семибитной кодировки протокола POP3 объем сообщений стало удобнее измерять не в байтах, а в октетах. Следующий пример позволяет продемонстрировать, в чем заключается различие. Пусть, передается приветствие “Hello, my world!”, занимающее шестнадцать байт. Но, в силу обрезания одного бита, по сети физически будет передан о только 16 х 7 = 112 бит или 112 / 8 = 14 – четырнадцать октетов. Тем не менее, это не мешает считать байты и октеты тождественно равными друг другу, если идет речь об объеме информации, передаваемой от одного узла к другому. Технически безграмотно, но удобно. Английский алфавит вместе со всеми спецсимволами и знаками препинания полностью умещается в первой половине таблицы ASCII, но передача кириллицы приводит к значительным искажениям текста: в каждом символе старший бит окапается обрезанным. Например:
Поэтому, первые эксперименты с почтовым ящиком, описанные этой главе, проводятся с англоязычными письмами, не содержащими ни одного символа кириллицы. (Использование национальных алфавитов сопряжено с хитроумными алгоритмами, которые будут описаны несколько позднее). Для получения списка сообщений, хранящихся в почтовом ящике, предусмотрена команда “LIST”, пример использования которой продемонстрирован ниже:
Чтение корреспонденции осуществляется командой “RETR” с указанием номера выбранного сообщения. Например:
Ответ сервера состоит из следующих частей:
Строка статуса указывает на успешность (неуспешность) операции и может принимать значение либо “+OK”, либо “+ERR” соответственно. Более сложную структуру имеет заголовок письма. Современные почтовые клиенты скрывают от пользователя большую часть его содержимого. А жаль! Порой заголовок содержит много интересного и даже способен выдать маленькие тайны отправителя письма. Заголовок состоит из полей – ключевых слов и параметров, разделенных знаком двоеточия. Существуют поля двух видов. Одни формируются отправителем письма (или его почтовым клиентом), а вторые – серверами, обрабатывающими письмо в ходе его отправления – доставки. Существует возможность подделки и фальсификации содержимого заголовка. Так, поле обратного адреса заполняется отправителем и может указывать куда угодно. Аналогичным образом заголовок может быть искажен во время пересылки письма (в главе «Анонимная рассылка корреспонденции» показано, как написать простейший скрипт, умеющий пересылать письма с уничтожением или фальсификацией всей информации об отправителе). Поэтому, никогда нельзя полагается на достоверность заголовка, но не стоит забывать о скидке «на дурака» – далеко не каждый пользователь умеет грамотно подделывать заголовки. Первым в заголовке обычно указывается поле ‘Received’, вставляемое транзитными серверами, пересылающими почту. Какова роль промежуточных узлов? Не проще ли устанавливать соединение непосредственно с почтовым сервером получателя? Да, когда-то именно так все и происходило, но с ростом потока сообщений пришлось усложнить схему пересылки. Появились серверы – ретрансляторы, специализирующиеся на пересылке почты. Подробнее о них рассказано в главах «Протокол SMTP» и «Почтовый сервер изнутри». Содержимое поля “Received” произвольно и меняется от сервера к серверу. В той или иной форме оно должно указывать на адреса серверов отправившего и получившего письмо с сообщением времени отправления - доставки. Каждый последующий сервер в цепочке добавляет новую запись в начало заголовка, и самая верхняя строка оставляется почтовым сервером адресата, получившим письмо. В приведенном выше примере она выглядит так:
Анализ заголовка позволяет установить, что в приведенном примере, сообщение было передано сервером baldrick.eia.brad.ac.uk (в скобках указан его IP адрес), но… удивительно, кем оно было получено! В заголовке значится доменное имя camel.mail.ru, принадлежащее популярной бесплатной службе mail.ru, а пути немотивированного возникновения письма на сервере mail.computerra.ru становятся весьма загадочными. Вероятно, заголовок был модифицирован, – удалена, по крайней мере, одна строка. Действительно, изначально письмо адресовалось kpnc@aport.ru. Оно было благополучно доставлено адресату, но хитрый mail.computerra.ru перебросил его в свой ящик, ни словом не обмолвившись этим фактом в заголовке. Впрочем, сервера с таким поведением большая редкость. Врезка «замечание»Две бесплатные почтовые службы mail.ru и aport.ru на самом деле являются одной службой в разных лицах! Следующее (и последнее в цепочке) поле “Received” содержит адрес сервера-отправителя, но не сообщает никакой информации о самом отправителе. Поэтому достоверно определить кем было отправлено письмо не представляется возможным.
Если собственноручно добавить к заголовку еще одно поле “Received” с некоторой информацией и передать письмо на baldrick.eia.brad.ac.uk, то получатель, анализируя заголовок, извлечет последнюю строчку «Received», содержащую подложный адрес. Подробнее о фальсификации содержимого поля “Received” рассказано в главе «Анонимная рассылка корреспонденции». Поле «Data» заполняется сервером-отправителем сообщения, но его достоверность не гарантирована, ведь злоумышленник способен передать письмо непосредственно на ретранслятор от имени почтового сервера-отправителя. Поле «Message-Id» служит для идентификации сообщений, позволяя из одних писем ссылаться на другие. Для обеспечения непротиворечивости каждый идентификатор должен быть уникален для всей сети Internet, то есть необходимо гарантировать существование всего лишь одного письма с данным идентификатором. Но как можно согласовать работу множества несвязанных друг с другом серверов? Организовать банк данных, отслеживающий все выданные идентификаторы возможно только теоретически. Но, поскольку каждый сервер обладает уникальным IP адресом (и, вероятнее всего, доменным именем), достаточно включить его в идентификатор, дополнив уникальной для данного сервера последовательностью, что обеспечит единственность такой комбинации во всей сети. Поэтому, идентификатор обычно состоит из имени узла-отправителя сообщения и буквенно-числовой последовательности, как правило191, включающей в себя дату и время пересылки сообщения. Ниже приведен пример типичного идентификатора (локальная уникальная последовательность выделена жирным шрифтом):
Поле “From:” содержит обратный адрес отправителя сообщения, который пожелал оставить сам отправитель. При отправке письма сервер проверяет лишь синтаксическую корректность содержимого поля “From”, но не гарантирует подлинность представленных данных. Так, в приведенном примере, отправитель создает впечатление, что он находится на узле telescope.org, но анализ идентификатора Message-Id позволяет установить истинный адрес сервера-отправителя.
Такое поведение не является чем-то ненормальным, поскольку для посылки и приема сообщений допускается использовать разные серверы, но в то же время это создает возможность фальсификации адреса отправителя с целью рассылки корреспонденции от чужого имени. Подробнее о подделке заголовков сообщений рассказывается в главе «Анонимная рассылка корреспонденции». Поле “To” указывает на получателя сообщения и состоит из двух частей – имени пользователя и адреса узла почтового сервера получателя. В общем виде оно выглядит так: username@servername. В качестве имени сервера допускается использовать его IP адрес, например: username@127.0.0.1 Все остальные поля являются факультативными и заполняются отправителем сообщения по желанию. Тело письма отделено от заголовка одной пустой строкой и завершается точкой. В простейшем случае тело сообщения представляет собой читабельный ASCII текст, не требующий дополнительной перекодировки. Передача символов кириллицы невозможна без дополнительных ухищрений, о которых наступило время рассказать. Существует огромное множество самых разнообразных форматов, из которых ниже будет в общих чертах рассмотрен лишь один – самый популярный из них MIME-формат (Multipurpose Internet Mail Extensions). Сообщение, закодированное в формате MIME, может выглядеть следующим образом:
Поле “MIME-Version: 1.0” (в тексте оно выделено жирным шрифтом) указывает на способ кодирования сообщения. Пара символов, расположенных справа от знака равенства, интерпретируется как шестнадцатеричный код символа исходного текста. Такая кодировка получила название “quoted printable” и завоевала широкое распространение. Она удобна тем, что символы первой половины таблицы ASCII [0x0 – 0x7F] представлены в своем естественном виде. Это сохраняет читабельность англоязычных сообщений, но оказывается крайне неэкономичным при кодировании кириллицы, – почти каждый символ исходного текста заменяется тремя, отчего письмо здорово «распухает». Но даже такая избыточность ничуть не уменьшает популярности формата MIME. Ниже показано, как можно расшифровать такое сообщение. Для этого потребуется любой шестнадцатеричный редактор, например, QVIEW. Запустите его и перейдите в режим открытия файла
Если теперь в правом окне начать вводить шестнадцатеричные значения символов, в левом окне станет появляться исходный текст письма (смотри рисунок 006): 
Рисунок 006 Декодирование сообщения, переданного в формате MIMEДетальное описание формата MIME выходит за пределы данной книги, но может быть найдено в техническом руководстве RFC-1341. Врезка «для начинающих» *Что такое RFC (Request For Comments)? В силу открытости архитектуры сети Internet и необходимости поддерживать общие соглашения между независимыми разработчиками появился набор стандартов и соглашений, доступный для массового использования. Любой разработчик имеет право внести свое предложение. Оно будет подвергнуто тщательной экспертной оценке и, если не встретит никаких возражений, будет добавлено в RFC. За каждым соглашением закреплен определенный номер, так, например, POP3 протокол описывается в RFC-1081, RFC-1082, RFC-1225, RFC-1725, RFC-1939. Для удаления сообщений из почтового ящика предусмотрена команда “DELE”, которая принимает в качестве аргумента порядковый номер уничтожаемого сообщения. Один из примеров ее использования продемонстрирован ниже:
Внимание: непосредственно после операции удаления перенумерации сообщений не происходит! Т.е. уничтоженное сообщение просто «выпадает» из списка, а следующие за ним сообщение не занимает этот индекс, и не сдвигается вверх. Сообщения будут перенумерованы только при следующем сеансе работы с сервером. Сеанс завершает команда “QUIT”. Сервер переходит в состояние обновления транзакции (transaction update) и разрывает соединение. Выглядеть это может следующим образом:
Если до обновления транзакции произойдет обрыв соединения, сервер выполнит откат транзакции, т.е. приведет почтовый ящик в тот вид, каким он был до начала последнего сеанса связи и все удаленные сообщения окажутся восстановленными (вернее, правильнее было бы сказать, не удаленными, поскольку команда “DELE” физически не уничтожает письма, а лишь помечает их для удаления, которое происходит в процессе обновления транзакции; если же связь оборвется, и обновление транзакции не будет выполнено, – все сообщения так и остаются не удаленными). Ниже будут рассмотрены некоторые дополнительные возможности протокола POP3. Для проведения описанных экспериментов потребуется подключиться к серверу, поддерживающему такие расширения. Одним из подходящих серверов является бесплатная служба электронной почты mail.ru.
После успешного установления TCP-соединения, сервер mail.ru возвращает приглашение, содержащее уникальный идентификатор (на рисунке 004 он обведен вокруг пером): 
Рисунок 004 Приглашение сервера mail.ruВыше уже отмечалась незащищенность пароля, открытым текстом передаваемого по сети. Если злоумышленник перехватит информационный поток, он сможет восстановить оригинальный пароль и вплоть до его смены несанкционированно проникать в систему. Для аутентификации, осуществляемой по нестойким к подслушиванию каналам связи, были разработаны специальные алгоритмы, которые обеспечивают однонаправленное шифрование и постоянную смену паролей. Один из таких алгоритмов, именуемый «запрос-отклик», работает следующим образом: сервер посылает клиенту случайную последовательность условно именуемую меткой. Клиент зашифровывает ее, используя в качестве ключа свой пароль, и полученный результат отправляет серверу. При этом алгоритм шифрования специальным образом подобран так, чтобы, зная зашифрованный пароль и метку, было бы невозможно найти ключ шифрования иначе, чем прямым перебором. Затем сервер самостоятельно шифрует метку хранящимся у него паролем пользователя и сравнивает полученные результаты. Если они идентичны, следовательно, пользователь ввел правильный пароль и наоборот. Подробнее о схеме «запрос отклик» рассказывается в главе «Атака на Windows NT» и здесь, во избежание повторения, никакие математические выкладки приводиться не будут. Уникальная последовательность, передаваемая клиенту при каждом соединении с сервером, называется временной меткой. Стандарт не оговаривает формат представления метки, но обычно она имеет следующий вид: processID.clock@hostname, где processID – идентификатор процесса, clock – состояние таймера сервера на момент установления соединения, а hostname – имя узла. Один из примеров временной метки показан ниже (в тексте он выделен жирным шрифтом):
Пользователь шифрует временную метку своим паролем по алгоритму MD 5, и полученный результат (который именуется зашифрованным паролем, или, технически более грамотно, “digest”) передает на сервер. Следующий эксперимент позволяет убедиться, что временные метки действительно различны при каждом новом соединении:
Для передачи серверу имени пользователя и зашифрованного пароля предусмотрена команда “APOP”. По стандарту она не входит в перечень команд, обязательных для реализации, поэтому существуют сервера, которые принимают только открытый пароль. Признаком того, что сервер поддерживает команду “APOP” служит наличие временной метки в строке приглашения. Пример использования команды APOP приведен ниже:
В приведенном примере в почтовом ящике лежит письмо значительных размеров, поэтому, возникает потребовать в предварительном просмотре фрагмента письма без его загрузки целиком (быть может, нет никакого смысла получать это сообщение и его можно безболезненно удалить). Для этой цели предусмотрена команда “TOP msg n”, которая выводит n первых строк, сообщения с порядковым номером msg. Например, “TOP110” возвращает десять первых строк от начала первого письма. Это может выглядеть так:
Для отката транзакции (и восстановления всех удаленных в течение последнего сеанса сообщений) можно воспользоваться командой “RSET”, вызываемой без аргументов. Но не существует команды, способной восстановить одно, конкретно, взятое сообщение. Пара команд “STAT” и “NOOP служат для проверки состояния ящика и целостности соединения. Обе вызываются без аргументов. Пример их использования приведен ниже:
Первое число, выдаваемое командой “STAT” сообщает количество сообщений, хранящихся в почтовом ящике, а второе содержит их суммарный объем в октетах. За подробным описанием протокола POP3 и смежных с ним вопросов можно обратиться к RFC-1081, RFC-1082, RFC-1225, RFC-1725, RFC-1939 и другим техническим руководствам.
жүктеу/скачать 3.83 Mb. Достарыңызбен бөлісу:
|
