NDR-атаки – проблемы и решения
Несмотря на все усилия и многомиллионные вложения в защитные средства, спамеры уходить со сцены не собираются, разрабатывая новые виды изощренных атак, жертвой которых может стать практически каждый. И если вовремя не контратаковать, полезные сообщения буквально утонут в лавине рекламной корреспонденции. Эта статья ориентирована главным образом на простых пользователей и владельцев домашних серверов, за ошибки конфигурации которых приходится расплачиваться не только разными неудобствами, но еще и трафиком, а трафик (особенно исходящий) обычно стоит больших денег.
Среди множества хитроумных трюков, применяемых спамерами (и хакерами), NDR-атаки имеют особое место, поскольку они основаны на фундаментальных спецификациях, описывающих работу протокола SMTP (Simple Mail Transfer Protocol – Простой протокол доставки почты). Пусть слово «простой» не вводит тебя в заблуждение. SMTP – основной протокол, прямых конкурентов у которого нет и, по-видимому, уже не будет (IMAP4 можно не брать в расчет, это все-таки экзотика, а SMTP – «рабочая лошадка»).
RFC, SMTP, NDR
Свое название NDR-атаки получили по первым буквам выражения Non-Delivery Report (отчет о недоставке почты). Всякий раз, когда SMTP-сервер не может доставить письмо (скажем, по причине отсутствия указанного адреса), он возвращает сообщение об ошибке с кодом 5xx, которое может выглядеть, например, так: «550 5.7.1 Unable to relay for kk@sendmail.ru», после чего разрывает TCP/IP-соединение. Однако сервер может и принять сообщение, отложить его в очередь, оповещая отправителя положительным кодом завершения операции (250).
Когда же в процессе обработки письма выяснится, что доставлять его некому, сервер, как порядочный гражданин, возвратит письмо адресату с объяснением причины невозможности доставки (здесь уместно провести аналогию с «улиточной» почтой). Вот это самое уведомление и называется Non-Delivery Report, или сокращенно NDR. Теоретически формат отчета специфицирован в RFC-3464 (An Extensible Message Format for Delivery Status Notifications — Открытый формат сообщений, уведомляющих о статусе доставки), однако в реальной жизни он варьируется в весьма широких пределах. Одни серверы помещают исходную копию письма во вложение, а сам отчет (составленный, как правило, на английском языке) кладут в основное тело сообщения. Другие же в целях экономии трафика отправляют только отчет, добавляя к нему короткий фрагмент исходного письма, включающий как минимум заголовок и несколько первых строк (чтобы отправитель мог разобраться, какое именно письмо «пострадало»).
В общем, уведомления о недоставке — стандартная и внешне вполне безобидная фича, реализованная еще в незапамятные времена. Казалось бы, ну чем она может быть полезна хакерам? Однако с ней связано целых две атаки: использование SMTP-сервера в качестве proxy (bounce message или backscatter-attack) и поиск валидных адресов (trial-n-error attack).
Backscatter-attack
Термин backscatter перекочевал в хакерскую среду из физики, где он означает отклонение волн от исходной траектории по тем или иным причинам (например, рэлеевское рассеяние света на молекулах воздуха, придающее небу голубой цвет). Применительно к SMTP-серверам backscatter «символизирует» процесс отскока или отбивания посланного сообщения. Такая атака также часто называется bounce message attack.
Один из крупнейших дефектов SMTP-протокола заключается в отсутствии штатных механизмов проверки аутентичности обратного адреса отправителя сообщения. Сервер всецело полагается на адрес, оставленный отправителем в поле «MAIL FROM:», не делая никаких попыток его проверки, а потому злоумышленник может запросто подставить любой адрес, какой ему вздумается, и именно туда сервер возвратит сообщение при невозможности его доставки конечному получателю. Что делает злоумышленник? Он берет адрес жертвы, прописывает его в поле «MAIL FROM:», а в поле «RCPT TO:» подставляет координаты заведомо несуществующего получателя. Если сервер не является ретранслятором (также называемым релеем — от английского relay), то есть берется за доставку корреспонденции лишь своим локальным адресатам, то он с вероятностью, близкой к единице, отобьет сообщение еще на стадии заполнения поля «RCPT TO:» и атака не состоится. Впрочем, некоторые серверы, в частности Microsoft Exchange Server, имеют довольно дурную систему поиска имен и зачастую принимают сообщения до проверки пользователя на существование.
Что же касается ретрансляторов (к которым де-факто принадлежат все публичные серверы, такие, например, как mail.ru), то они вообще не в состоянии определить существование нелокальных пользователей и потому принимают все письма без разбора. Лишь потом, в случае невозможности доставки, они посылают отправителю (или, точнее говоря, тому лицу, чей адрес указан в поле «MAIL FROM:») соответствующее уведомление.
Ну и как это можно использовать для атаки? И тем более для спама? Ведь рассылка уведомлений по множественным адресам запрещена, и потому атакующему для отправки N писем размером в K мегабайт придется израсходовать N*K мегабайт своего трафика. А это ровно столько, сколько тратится при так называемой директивной рассылке, когда атакующий вообще не прибегает к услугам промежуточных SMTP-серверов, а связывается с каждым получателем напрямую и кладет в его почтовый ящик конверт со спамом (или с вирусом — неважно). Потому-то хакеры и стремятся использовать открытые ретрансляторы, допускающие задание в поле «MAIL TO:» множества адресатов. В идеале (если количество адресов неограниченно) атакующий тратит лишь K мегабайт собственного трафика, остальные же почтовый сервер оплачивает из своего кармана. Однако с каждым днем находить открытые ретрансляторы становится все труднее и труднее. Практически все почтовые серверы устанавливают жесткие лимиты на максимальное количество сообщений, передаваемых в единицу времени, и либо вообще запрещают множественную рассылку, либо соглашаются доставлять письмо ограниченному числу получателей (как правило, не более шести).
Стоп! А зачем атакующему нужны открытые ретрансляторы, если широкие DSL-каналы сегодня не роскошь, а средство передвижения? К тому же исходящий трафик обычно либо совсем бесплатный, либо тарифицируется по весьма льготным ценам. Сегодня каждый может позволить себе арендовать канал, о котором вчера добрая половина провайдеров не могла и мечтать! Кажется, что в сложившихся условиях директивная рассылка должна стать основным орудием спамеров, но…
В том-то и дело, что при практической реализации атаки сразу же всплывает множество «но». Большинство корпоративных (да и публичных) серверов попросту не примут письмо неизвестно от кого. Поэтому как минимум потребуется обзавестись доменным именем третьего уровня и воздвигнуть собственный почтовый сервер (хотя бы чисто формальный). А для этого уже желательно иметь статический IP, хотя доменное имя третьего уровня можно бесплатно зарегистрировать и на динамическом.
В результате некоторых манипуляций мы добились того, что почтовые серверы начинают принимать от нас корреспонденцию. Но стоит только начать рассылать спам, как уже через несколько часов атака потухнет, как бычок в писсуаре. Используя распределенные черные списки (они же блэк-листы), почтовые серверы очень быстро заблокируют наш IP-адрес (а то и всю подсеть). В случае статического адреса это еще ничего (моя селедка, что хочу с ней, то и делаю), а вот блокировка динамического IP (или всей подсети) создает огромные проблемы для провайдера, который тут же отключает хакера. Вот так со всего маху и отключает. Прямым ударом. В челюсть. Ведь попасть в черные списки намного проще, чем выбраться оттуда, да и процедура «реабилитации» обычно далеко не бесплатна. А количество провайдеров (даже в крупном городе) хоть и велико, но все-таки ограничено.
Короче, директивная рассылка оправдывает себя только на ботнетах — пишем червя, заражаем несколько десятков тысяч машин и ретранслируем письма их руками. Но ведь ботнет еще создать нужно! К тому же, в отличие от спама (юридический статус которого до сих пор не определен), это уже является довольно серьезным правонарушением, особенно если в число зараженных узлов попадут компьютеры различных секретных ведомств. В таких случаях пощады ждать, как правило, не приходится и приговор оказывается очень суров, а судимость (пускай даже условная) — это все-таки судимость, существенно ограничивающая гражданина в правах.
И тут на помощь спамерам приходят backscatter-атаки. Злоумышленник, используя различные SMTP-серверы, рассылает корреспонденцию, подставляя адрес получателя в поле «MAIL FROM:» и указывая заведомо несуществующего пользователя в поле «RCPT TO:». Несмотря на то что подлинный IP-адрес спамера остается в заголовке письма (помещаемого сервером во вложение или в основное тело сообщения), существующие фильтры не настолько интеллектуальны, чтобы достать его оттуда, и потому заносят в черный список IP почтового сервера, рассылающего уведомления о невозможности доставки сообщений. Поскольку таких серверов очень много (данным условиям отвечает практически любой SMTP-сервер, даже не являющийся ретранслятором), они не кончатся никогда, и на недостаток в них спамер навряд ли сможем пожаловаться. А вот для владельцев самих атакованных серверов настанут мрачные деньки, и им придется совершить нехилые телодвижения, доказывая, что никакого спама они не рассылали!
Как защититься от подобных атак? Нет ничего проще! Достаточно как следует покопаться в настройках сервера. Прежде всего, следует включать в отчет о недоставке только фрагмент исходного сообщения (заголовок плюс пара-тройка строк), что сделает его совершенно бесполезным для спамеров, и они потеряют к нему всякий интерес. Если же это невозможно (например, сервер не поддерживает таких настроек), задействуй режим замедления SMTP-ответов, установив задержку в несколько секунд для неавторизованных пользователей. Конечно, это слегка замедлит производительность сервера, но… что поделаешь! Между «скорострельностью» и безопасностью приходится выбирать что-то одно.
Trial-n-error attack
Спамеры заинтересованы в отправке сообщений только на действующие адреса, и уведомления о недоставке тут приходятся как нельзя кстати. В частности, ошибка типа «mailbox is full» говорит, что получатель, скорее всего, забил на этот ящик и уже давно его не использует, а потому он заполнен до предела. Но это мелочи. Главная проблема спамеров — сбор адресов. Для их поиска разрабатываются хитроумные программы-харвестеры (от английского harvester — «собиратель»), блуждающие по просторам Сети и анализирующие web-странички, а также проникающие на уязвимые узлы и сканирующие адресную книгу. Однако пользователи не дураки. Свою основную мыльницу на форумах уже давно никто не оставляет, а бесплатные ящики, создаваемые на короткое время на серверах типа mail.ru, спамерам не очень интересны, да и фильтры там стоят достаточно мощные.
Наибольший доход приносит рассылка по корпоративным адресам. Вот только как эти самые адреса найти? А почему бы не воспользоваться перебором по словарю? А что! Пользователи склонны выбирать короткие и легко запоминающиеся адреса, как правило, состоящие из имени (с добавленным к нему годом, когда такое имя уже кем-то занято), популярных слов типа mafia, hacker, supermen или инициалов в стиле kk, что расшифровывается как Kris Kaspersky. Когда-то у меня был такой адрес на sendmail’е. Спаму туда сыпалось огромное количество. Чуть меньше доставалось n2k, зарегистрированному на том же сервере. Четырехсимвольный алиас kpnc чувствовал себя довольно уверенно — спаму туда приходило относительно немного, но все-таки значительно больше, чем на kris.kaspersky. Отсюда вывод: любые короткие имена (неважно, словарные они или нет) легко находятся тривиальным подбором. Атакующий просто отправляет большое количество писем, перебирая различные буквенно-цифровые комбинации, и ловит NDR-уведомления от почтового сервера. Несуществующие адреса отметаются сразу, а вот на остальные направляется стабильный поток незапрошенной корреспонденции. Для экономии трафика тело тестового письма обычно содержит минимум символов и зачастую просто состоит из нескольких байт.
Исследование, проведенное автором этой статьи, показало, что одно-, двух- и трехсимвольные комбинации представлены на популярных почтовых серверах достаточно полно и покрывают около двух десятков тысяч действующих адресов. Причем, в отличие от адресов, почерпнутых из спамерских баз (за которые еще платить надо), короткие имена намного медленнее устаревают, поскольку их владельцам жалко с ними расставаться. Даже если они выберут другое короткое имя — ну и что с того? Оно также будет найдено методом перебора.
Четырехсимвольные имена перебирать труднее, поскольку из двух миллионов комбинаций реально используется жалкая сотня тысяч или даже и того меньше. К тому же отправка двух миллионов писем – процедура нетривиальная, привлекающая к себе внимание. Рассылка начнет давиться фильтрами задолго до того, как спамер успеет пожать плоды своих трудов. Пятисимвольные имена лобовым перебором уже не находятся в принципе, точнее, находятся, конечно, но… смысл? Разослать сто миллионов писем, чтобы собрать ту же сотню тысяч адресов?
Другое мощное оружие — перебор по словарю. Кстати говоря, принятая система раздачи адресов в корпорациях (по имени и/или фамилии сотрудников) этому только способствует, поскольку, во-первых, существуют словари имен и фамилий. Во-вторых, даже если какая-то конкретная фамилия в таком словаре отсутствует (например, Вуглускреб), то она все равно содержит предсказуемые корни и подчиняется правилам чередования гласных и согласных, что существенно ограничивает перебор.
Короткий лингвистический ликбез. Большинство русских (и японских) имен содержит одинаковое количество попеременно чередующихся гласных и согласных (Таня, Маня, Мазепа, Иванов, Сидоров). Имена, включающие в себя несколько подряд идущих гласных, также широко распространены, но сочетаний подряд идущих согласных очень и очень немного, причем в различных языках они разные. Мы с трудом выговариваем сочетание th, в то время как американцы приходят в ужас от слова «защищающиеся» (попытайся записать его латиницей, и пусть тебя охватит гордость за наш язык :)).
Естественно, все, что известно лингвистам, известно и хакерам (тем более что об этом можно прочесть в любом лингвистическом учебнике, там же даны и таблицы распространенности различных сочетаний звуков и букв). Учитывая, что гласных в латинском алфавите только шесть, нетрудно подсчитать, сколько наберется «осмысленных» имен, сгенерированных с учетом лингвистических особенностей (простейшие генераторы, которые легко найти в Сети, исходят из предположения, что гласных и согласных должно быть поровну). Более сложные программы, использующие замороченные психофизические модели, как правило, распространяются за деньги, однако и те и другие дают поразительный результат и эффективно находят даже девятисимвольные имена, разумеется, без учета словаря.
Как вариант – можно использовать словарь и программу-модификатор, переставляющую буквы местами, записывающую «O» как ноль, «l» как единицу, набирающую русские имена латинскими буквами с учетом их расположения на клавиатуре: Марина – Vfhbyf и т.д.
Короче говоря, даже если нигде не светить свое мыло, настырные спамеры его все равно найдут (исключение составляют длинные — свыше пяти-шести символов — имена, состоящие из одних согласных букв, цифр и спецсимволов). Можно ли защититься от подобных атак? На уровне почтового сервера — можно. Достаточно генерировать сообщение о недоставке в ответ на все подозрительные сообщения и даже на все сообщения с неизвестным адресатом (то есть таким адресатом, которому получатель сообщения ранее не отправлял никакой корреспонденции). Практика показывает, что честные пользователи сразу (или через некоторое время) повторяют попытку отправки вновь, в то время как спамеры тут же заносят такой адрес в список несуществующих. Кстати говоря, поскольку спамеры анализируют уведомления о недоставке не вручную, а с помощью программ, выдирающих из тела письма код ошибки, то имеет смысл добавить в уведомление русский текст, предлагающий пользователю отправить сообщение еще раз, чтобы тот зря не нервничал, полагая, что ошибся адресом.
Заключение
Базовые почтовые протоколы разрабатывались в эпоху ранней юности интернета (когда никаких вандалов еще не было) и с тех пор практически не претерпели изменений, становясь легкой добычей хакеров и заставляя нас расплачиваться за ошибки своих отцов и дедов.
Впрочем, не будем о грустном. Все не так уж и мрачно. Протоколы постепенно дорабатываются, появляются новые механизмы аутентификации, однако в силу децентрализованной природы интернета их внедрение затягивается на неопределенный срок.
Автор: Крис Касперски
Взято с августовского выпуска журнала Хакер