Крис Касперский - ТЕХНИКА СЕТЕВЫХ АТАК

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

Например, пусть Алиса отправляет Бобу письмо, а Ева хочет его перехватить. Процесс пересылки письма выглядит так: почтовый сервер Алисы (скажем, aserver.com) смотрит на адрес получателя (скажем, bob@bserver.com) и обращается к «знакомому» DNS-серверу с просьбой определить IP-адрес сервера “bserver.com”. Получив ответ, он устанавливает с сервером получателя SMTP-соединение и передает ему послание. Если Ева знает адреса серверов Алисы и Боба [224], она сможет сфальсифицировать ответ DNS-сервера и сообщить адрес своего собственного сервера, а не bserver.com!

В большинстве случаев протокол DNS реализован поверх UDP-протокола, а протокол UDP работает без установки соединения, принимая пакеты от кого бы то ни было на заданный порт. Для определения личности отправителя предусмотрен специальный идентификатор, который не известен злоумышленнику [225]. Идентификатор представляет собой 16-битовое значение, поэтому, послав всего лишь 2 16пакетов, Ева может быть уверена, что один из них жертва воспримет как ответ от настоящего 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), образуя транспортабельный текст.