NDR-attack

крис касперски, ака мыщъх, no-email

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

Среди множества хитроумных трюков, применяемых спаммерами (и хакерами!) NDR-атаки стоят на особом месте, поскольку они основаны на фундаментальных спецификациях, описывающих работу протокола SMTP (Simple Mail Transfer Protocol – Простой Протокол Доставки Почты). Пусть слово «простой» не вводит вас в заблуждение. SMTP – основной протокол, прямых конкурентов которому нет и по-видимому уже не будет (IMAP4 можно не брать в расчет, это все-таки экзотика, а SMTP – «рабочая лошадка»).

Свое название 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 — Открытый Формат Сообщений Уведомляющих о Статусе Доставки), однако, в реальной жизни он варьируется в весьма широких пределах.

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

Другие интересные (и полезные для ознакомления) документы: RFC 3461 –Simple Mail Transfer Protocol Service Extension for Delivery Status Notifications(Расширения Простого Протокола Доставки Почты для Уведомлений о Статусе Доставки), RFC 3463 — Enhanced Status Codes for SMTP (Расширенные коды статуса для SMTP), RFC 3834 –Recommendations for Automatic Responses to Electronic Mail (Рекомендации по Автоматическим Ответам на Электронную Почту). Все ссылки приведены на одноименной врезке.

В общем, уведомления о недоставке — вполне стандартная и внешне вполне безобидная фича, реализованная еще в незапамятные времена. Казалось бы, ну чем она может быть полезна для хакеров?! На самом же деле, с ней связано целых две атаки — использование SMTP-сервера в качестве Proxy (bounce message- или backscatter-attack) и поиск валидных (т. е. активно используемых) адресов (trial-n-error attack).

Return-path: <>

Received: from mail by mx27.mail.ru with local

id 1HKiBz-000PxE-00

for kpnc@inbox.ru; Sat, 24 Feb 2007 00:43:03 +0300

X-Failed-Recipients: u77@nezumi.org.ru

From: Mail Delivery System Mailer-Daemon@mx27.mail.ru

To: kpnc@inbox.ru

Subject: Mail delivery failed: returning message to sender

Message-Id: E1HKiBz-000PxE-00@mx27.mail.ru

Date: Sat, 24 Feb 2007 00:43:03 +0300

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its

recipients. This is a permanent error. The following address(es) failed:

u77@nezumi.org.ru

SMTP error from remote mailer after RCPT TO:u77@nezumi.org.ru:

host nezumi.org.ru [83.239.33.46]: 550 Unknown user

—— This is a copy of the message, including all the headers. ——

Return-path: kpnc@inbox.ru

Received: from [83.239.33.46] (port=34297 helo=kpnc)

by mx27.mail.ru with smtp

id 1HKiBt-000Pcb-00

for u77@nezumi.org.ru; Sat, 24 Feb 2007 00:42:58 +0300

Message-ID: <05d801c75794$7731fed0$0100a8c0@kpnc>

From: «Kris Kaspersky» kpnc@inbox.ru

To: u77@nezumi.org.ru

Subject: test

Date: Sat, 24 Feb 2007 00:49:11 +0300

MIME-Version: 1.0

Content-Type: multipart/alternative;

boundary=«—-=_NextPart_000_05D5_01C757AD.994C4660»

X-Priority: 3

X-MSMail-Priority: Normal

X-Mailer: Microsoft Outlook Express 6.00.2800.1506

X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506

This is a multi-part message in MIME format.

——=_NextPart_000_05D5_01C757AD.994C4660

Content-Type: text/plain;

charset=«koi8-r»

Content-Transfer-Encoding: quoted-printable

——=_NextPart_000_05D5_01C757AD.994C4660

Content-Type: text/html;

charset=«koi8-r»

Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC «-W3CDTD HTML 4.0 TransitionalEN»> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D«text/html; charset=3Dkoi8-r»> <META content=3D«MSHTML 6.00.2800.1515» name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV>&nbsp;</DIV></BODY></HTML> ——=_NextPart_000_05D5_01C757AD.994C4660– Листинг 1 пример уведомления о невозможности доставки сообщения несуществующему пользователю, возвращенного сервером ===== backscatter-attack ===== Термин «backscatter» перекачивал в хакерскую среду из физики, где он означает отклонение волн от исходной траектории по тем или иным причинам (например, Реллевское рассеяние света на молекулах воздуха, придающее небу голубой цвет). Применительно к SMTP-серверам, «backscatter» символизирует процесс «отскока» или «отбивания» посланного сообщения, поэтому такая атака часто называется bounce message attack. Рисунок 1 «физическая» репрезентация backscatter-атак Один из крупнейших дефектов 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, впрочем, доменное имя третьего уровня можно бесплатно зарегистрировать и на динамическом. ОК, после некоторых манипуляций, мы добились того, что почтовые сервера начинают принимать от нас корреспонденцию, но… стоит только начать рассылать спам, как уже спустя несколько часов атака потухнет как бычок в писсуаре. Используя распределенные черные списки (они же black-list'ы), почтовые серверы очень быстро заблокируют наш IP-адрес (а то и всю подсеть) на хрен. В случае статического адреса это еще ничего (моя селедка, что хочу с ней то и делаю), а вот блокировка динамического IP (или всей подсети) создает огромные проблемы для провайдера, который тут же отключает хакера. Вот так со всего маху и отключает. Прямым ударом. В челюсть. Ведь попасть в черные списки намного проще, чем выбраться оттуда, да и процедура «реабилитации» обычно далеко не бесплатна. А количество провайдеров (даже в крупном городе) хоть и велико, но все-таки ограничено. Короче, директивная рассылка оправдывает себя только на ботнетах — пишем червя, заражаем несколько десятков тысяч машин и «ретранслируем» письма их руками. Но… ведь ботнет еще создать нужно! К тому же, в отличии от спама (юридический статус которого до сих пор не определен), это уже является довольно серьезным правонарушением, особенно, если в число зараженных узлов попадают компьютеры различных секретных ведомств. В таких случаях пощады ждать, как правило, не приходится и приговор оказывается очень суров, а судимость (пускай даже условная) — это все-таки судимость, существенно ограничивающая гражданина в правах. И тут на помощь спаммерам приходят backscatter-аттаки. Злоумышленник, используя различные SMTP-сервера, рассылает корреспонденцию, подставляя адрес получателя в поле «MAIL FROM:», а в поле «RCPT TO:» указывает заведомо несуществующего пользователя. Несмотря на то, что подлинный IP-адрес спаммера остается в заголовке письма (помещаемого сервером во вложение или в основное тело сообщения) существующие фильтры не настолько интеллектуальны, чтобы достать его оттуда и потому заносят в черный список IP почтового сервера, рассылающего уведомления о невозможности доставки сообщений. Поскольку, таких серверов _очень_ много (данным условиям отвечает практически любой SMTP-сервер, даже не являющийся ретранслятором), то они не кончаться никогда и на недостаток в них спамер навряд ли сможем пожаловаться. А вот для владельцев самих атакованных серверов настанут мрачные деньки, и им придется совершить нехилые телодвижения, доказывая, что никакого спама они не рассылали! ndr-attack_image_1.jpg Рисунок 2 замедление времени отклика — один из возможных способов защиты от NDR-атак Как защититься от подобных атак?! Нет ничего проще! Достаточно как следует покопаться в настройках сервера. Прежде всего, следует включать в отчет о недоставке только фрагмент исходного сообщения (заголовок плюс пара-тройка строк), что сделает его совершенно бесполезным для спаммеров и они потеряют к нему всякий интерес. Если же это невозможно (например, сервер не поддерживает таких настроек), задействуйте режим замедления 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», в то время как американцы приходят в ужас от слова «защищающиеся» (попытайтесь записать его латиницей и пусть вас охватит гордость за наш язык). Рисунок 3 …а гласных в латинском алфавите всего шесть Естественно, все, что известно лингвистам, известно и хакерам (тем более, что об этом можно прочесть в любом лингвистическом учебнике, там же даны и таблицы распространенности различных сочетаний звуков и букв). Учитывая, что гласных в латинском алфавите только шесть, нетрудно подсчитать сколько наберется «осмысленных» имен, сгенерированных с учетом лингвистических особенностей (простейшие генераторы, которые легко найти в сети, исходят из предположения, что гласных и согласных должно быть поровну. Более сложные программы, использующие сложные психофизические модели, как правило, распространяются за деньги, однако и те, и другие дают поразительный результат и эффективно «находят» даже девятисимвольные имена — разумеется, без учета словаря). Как вариант, можно использовать словарь и программу модификатор — переставляющую буквы местами, записывающую «O» как «ноль», «l» как единицу, набирающую русские имена латинскими буквами с учетом их расположения на клавиатуре: «Марина» «Vfhbyf» и т. д. и т. п. Короче говоря, даже если нигде не светить свое «мыло», настырные спамеры его все равно найдут (исключение составляют длинные — свыше пяти-шести символов — имена, состоящие из одних согласных букв, цифр и спецсимволов). Можно ли защититься от данных атак? На уровне почтового сервера — можно. Достаточно генерировать сообщение о недоставке в ответ на все подозрительные сообщения или даже на все сообщения с неизвестным адресатом (т. е. такому адресату, которому получатель сообщения ранее не отправлял никакой корреспонденции). Практика показывает, что честные пользователи сразу (или через некоторое время) повторяют попытку отправки вновь, в то время как спамеры тут же заносят данный адрес в список несуществующих. Кстати говоря, поскольку спамеры анализируют уведомления о недоставке не вручную, а с помощью автоматизированных программ, выдирающих из тела письма код ошибки, то имеет смысл добавить в уведомление русский текст, предлагающий пользователю отправить сообщение еще раз, чтобы он зря не нервничал, полагая, что ошибся в адресе. ===== заключение ===== Базовые почтовые протоколы разрабатывались в эпоху ранней юности Интернета (когда никаких вандалов не существовало) и с тех пор практически не претерпели изменений, став легкой добычей для хакеров и застав нас расплачиваться за ошибки своих отцов и дедов. Впрочем, не будем о грустном. Все не так уж и мрачно. Протоколы постепенно дорабатываются, появляются новые механизмы аутентификации, однако, в силу децентрализованной природы Интернета их внедрение затягивается на неопределенный срок… ===== »> врезка полезные ссылки ===== - Bounce message: - описание общих принципов NDR-атак на Википедии (на английском языке): http://en.wikipedia.org/wiki/Non-delivery_report__; - Выполнение пересылки SMTP в Windows 2000, Windows XP и ExchangeServer: - описание принципа и защиты от NDR-атак от Microsoft (на русском языке): http://support.microsoft.com/kb/304897/ru__; - Режим замедления ответов SMTP в Microsoft Windows Server 2003: - еще один способ защиты от NDR-атак от Microsoft (на русском языке):http://support.microsoft.com/kb/842851/ru__; - RFC 3461 —SMTP Service Extension for Delivery Status Notifications: - http://tools.ietf.org/html/rfc3461__; - RFC 3463 — Enhanced Status Codes for SMTP: - http://tools.ietf.org/html/rfc3463__; - RFC 3464 — An Extensible Message Format for Delivery Status Notifications: - http://tools.ietf.org/html/rfc3464__; - RFC 3834 — Recommendations for Automatic Responses to Electronic Mail: - http://tools.ietf.org/html/rfc3834__;