Техника сетевых атак
Шрифт:
Существует несколько типов атак: атаки, основанные на ошибках реализации программного обеспечения (срыв стека, использование конвейера); атаки, основанные на неправильной конфигурации сервера и атаки, основанные на уязвимости сетевых протоколов (внедрение ложного DNS, перехват трафика).
Даже при условии отсутствия ошибок реализации правильно настроенный почтовый сервер может быть атакован, если не предпринять особых мер предосторожности, о которых осведомлен далеко не каждый администратор.
Например, пусть Алиса отправляет Бобу письмо, а Ева хочет его перехватить. Процесс пересылки письма выглядит так: почтовый сервер Алисы (скажем, aserver.com) смотрит на адрес получателя (скажем, bob@bserver.com) и обращается к «знакомому» DNS-серверу с просьбой определить IP-адрес сервера “bserver.com”. Получив ответ, он устанавливает с сервером получателя SMTP-соединение и передает ему послание. Если Ева знает адреса серверов Алисы и Боба [224], она сможет сфальсифицировать ответ DNS-сервера и сообщить адрес своего собственного сервера, а не bserver.com!
В большинстве случаев протокол DNS реализован поверх UDP-протокола, а протокол UDP работает без установки соединения, принимая пакеты от кого бы то ни было на заданный порт. Для определения личности отправителя предусмотрен специальный идентификатор, который не известен злоумышленнику [225]. Идентификатор представляет собой 16-битовое значение, поэтому, послав всего лишь 216 пакетов, Ева может быть уверена, что один из них жертва воспримет как ответ от настоящего DNS. А если идентификатор не абсолютно случайное число (как это часто и случается), то количество требуемых попыток существенно уменьшается.
Обсуждение перехвата трафика путем подобного «подмятия» DNS-сервера - тема отдельного разговора, выходящая за рамки рассказа об уязвимости почтовых соединений. Позже она будет детально рассмотрена в главе «Атака на DNS сервер» [226], здесь же достаточно заметить - если в e-mail адресе не указан IP (т.е. например, kpnc@195.161.42.222), а получатель не находится на том же сервере, что и отправитель, то перехват такого сообщения в принципе возможен.
Анализ почты позволяет злоумышленнику почерпнуть множество информации, облегчающей дальнейшее проникновение в систему, и расширяет границы социальной инженерии. Кроме того, в корпоративной (да и не только) переписке часто содержатся сведения и документы, представляющие огромный интерес для конкурентов и промышленно-финансовых шпионов всех мастей. Единственный выход - шифровать всю конфиденциальную корреспонденцию утилитами, наподобие PGP.
Впрочем, атаки, направленные на перехват переписки, не получили большого распространения. Намного чаще злоумышленники пытаются овладеть удаленной машиной, и почтовый сервер одно из возможных средств для достижения такой цели. Сложность и запутанность почтового программного обеспечения затрудняют его тестирование, а оставленные ошибки могут представлять лазейку для злоумышленника.
Первый громкий прецедент произошел осенью 1988 года, когда по сети расползся червь Морриса. Один из способов распространения заключался в использовании отладочного режима в программе SendMail. Отладочный режим служил для удаленного управления почтовым демоном и позволял выполнить команды, передаваемые в теле письма. Остальное, как говорится, было делом техники. Вирус посылал «затравку» на языке Си с указанием откомпилировать ее и запустить. «Затравка» стирала заголовки почты, способные пролить свет на ее происхождение, и, связавшись с отправителем, «перетягивала» на сервер все остальные модули червя.
Ниже приводится фрагмент кода вируса (с небольшими сокращениями), демонстрирующий как он использовал отладочный режим (жирным цветом выделены строки, передаваемые им на сервер по SMTP-соединению).
· send_text(s, "debug");
·…
· #define MAIL_FROM "mail from:«/dev/null»\n"
· #define MAIL_RCPT "rcpt to:«\"| sed \'1,/^$/d\' | /bin/sh; exit 0\"»\n"
·…
· send_text(s, MAIL_FROM);
· i = (random amp; 0x00FFFFFF);
· sprintf(l548,MAIL_RCPT, i, i);
· send_text(s, l548);
·
Вскоре после атаки лаз был закрыт, но червь Морриса послужил наглядным доказательством принципиальной возможности атак и стал хорошим стимулом к поиску других, еще никем не обнаруженных ошибок. В том, что они существуют, - никто не сомневался. Так оно и получилось.
Некто (имени которого история не сохранила) обратил внимание, что у многих почтовых серверов в файле «/etc/aliases» содержится строка приблизительного следующего содержания: «decode: |/usr/bin/uudecode». Если послать на такой сервер письмо, адресованное получателю «decode», оно попадает в руки программы “uudecode”, предназначенной для распаковки UUE-сообщений.
Необходимость передавать двоичные файлы через почтовые системы, не допускающие использование символов с кодами менее 32 и более 127, привела к появлению UUE кодировки. Идея, лежащая в ее основе, заключается в следующем: три байта (24 бита) разбиваются на четыре шестибитовых «осколка», каждый из которых суммируется с кодом пробела (0х20), образуя транспортабельный текст.
Таким образом, закодированный текст состоит из следующих символов (и только из них): `!"#$% amp;'*+,-./012356789:;«=»?@ABC…XYZ[\]^_, каждый из которых может быть передан по любым телекоммуникационным каналам, в том числе и семибитовым.
Получатель проделывает на свой стороне обратный процесс, - из каждого символа вычитает код пробела, и из каждых четырех «осколков» закодированного текста собирает по три байта оригинального послания.
Типичное UUE-сообщение выглядит приблизительно так (все необязательные поля для упрощения понимания опущены):
· begin 644 filename
· =D»JEJR"AKJ'@H"`M(. amp;OH.$@I*7@I:*N(0T``0(`
· `
· end
Слово “filename”, стоящее в заголовке, обозначает ни что иное, как имя файла, в который отправитель предлагает записать раскодированный текст. Большинство расшифровщиков не проверяют наличие файла на существование и затирают его содержимое без запроса подтверждения пользователя.
Если демон SendMail обладает наивысшими привилегиями (а так чаще всего и бывает), программа uudecode наследует их при запуске. Следовательно, существует возможность перезаписать любой файл в системе.
Например, злоумышленник может внести в файл “.rhosts” строку вида «+ +». В файле “.rhosts” содержится перечень адресов доверительных узлов и имен пользователей, которым с этих самых узлов разрешен вход на сервер без предъявления пароля. А комбинация «+ +» открывает свободный доступ всем пользователям со всех узлов сети.