Автор: (c)Крис Касперски ака мыщъх
Несмотря на все усилия и многомиллионные вложения в защитные средства, спамеры уходить со сцены не собираются, разрабатывая новые виды изощренных атак, жертвой которых может стать практически каждый и если вовремя не контратаковать, полезные сообщения буквально утонут в лавине непрошеной рекламной корреспонденции. Эта статья главным образом ориентирована на простых пользователей и владельцев домашних серверов, за ошибки конфигурации которых приходится расплачиваться не только разными неудобствами, но еще и трафиком, а трафик (особенно исходящий) - обычно стоит денег.
Среди множества хитроумных трюков, применяемых спамерами (и хакерами!) 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 "-//W3C//DTD HTML 4.0 Transitional//EN"> <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> </DIV></BODY></HTML> ------=_NextPart_000_05D5_01C757AD.994C4660--
Листинг 1. Пример уведомления о невозможности доставки сообщения несуществующему пользователю, возвращенного сервером.
Термин "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-сервер, даже не являющийся ретранслятором), то они не кончатся никогда и на недостаток в них спамер навряд ли сможет пожаловаться. А вот для владельцев самих атакованных серверов настанут мрачные деньки и им придется совершить нехилые телодвижения, доказывая, что никакого спама они не рассылали!
Рисунок 2. Замедление времени отклика - один из возможных способов защиты от NDR-атак.
Как защититься от подобных атак?! Нет ничего проще! Достаточно как следует покопаться в настройках сервера. Прежде всего, следует включать в отчет о недоставке только фрагмент исходного сообщения (заголовок плюс пара-тройка строк), что сделает его совершенно бесполезным для спамеров и они потеряют к нему всякий интерес. Если же это невозможно (например, сервер не поддерживает таких настроек), задействуйте режим замедления SMTP-ответов, установив задержку в несколько секунд для неавторизованных пользователей. Конечно, это слегка замедлит производительность сервера, но... что поделаешь! Между "скорострельностью" и безопасностью приходится выбирать что-то одно.
Спамеры заинтересованы отправлять сообщения только на действующие адреса и уведомления о недоставке тут приходятся как нельзя кстати. В частности, ошибка типа "mailbox is full" говорит, что получатель, скорее всего, забил на этот ящик и уже давно его не использует, а потому он заполнен до предела. Но это мелочи. Главная проблема спамеров - сбор адресов для поиска которых разрабатываются хитроумные программы-харвестры (от английского harvester - собиратель), блуждающие по просторам сети и анализирующие web-странички, а также проникающие на уязвимые узлы и сканирующие адресную книгу. Однако пользователи не дураки. Свою основную мыльницу на форумах уже давно никто не оставляет, а бесплатные ящики, создаваемые на короткое время на серверах типа mail.ru, спамерам не очень интересны, да и фильтры там стоят достаточно мощные.
Наибольший доход приносит рассылка по корпоративным адресам. Вот только как эти самые адреса найти? А почему бы не воспользоваться перебором по словарю? А что! Пользователи склонны выбирать короткие и легко запоминающиеся адреса, как правило состоящие из имени (с добавленным к нему годом, когда такое имя уже кем-то занято), популярных слов типа "mafia", "hacker", "supermen" или инициалов в стиле "kk", что расшифровывается как "Kris Kaspersky". Когда-то у меня был такой адрес на sendmail'е. Спаму туда сыпалось немерено. Чуть меньше доставалось "n2k", зарегистрированному на том же сервере. Четырехсимвольный алиас "kpnc" чувствовал себя довольно уверенно - спаму туда приходило относительно немного, но все-таки значительно больше, чем на "kris.kaspersky". Отсюда вывод - любые короткие имена (неважно, словарные они или нет) легко находятся тривиальным подбором. Атакующий просто отправляет большое количество писем, перебирая различные буквенно-цифровые комбинации и ловит NDR-уведомления от почтового сервера. Несуществующие адреса отметаются сразу, а вот на остальные направляется стабильный поток незапрошенной корреспонденции. Для экономии трафика тело "тестового" письма обычно содержит минимум символов и зачастую просто состоит из нескольких байт.
Исследование, проведенное автором этой статьи, показало, что одно, двух- и трех- символьные комбинации представлены на популярных почтовых серверах достаточно полно и покрывают около двух десятков тысяч действующих адресов. Причем, в отличие от адресов, почерпнутых из спамерских баз (за которые еще платить надо!) короткие имена намного медленнее устаревают, поскольку их владельцам жалко с ними расставаться. Даже если они выберут другое короткое имя - ну и что с того? Оно также будет найдено методом перебора.
Четырехсимвольные имена перебирать становится труднее, поскольку из двух миллионов комбинаций реально используется жалкая сотня тысяч или даже менее того. К тому же, отправка двух миллионов писем - процедура нетривиальная и привлекающая к себе внимание. Рассылка начнет давиться фильтрами задолго до того, как спамер успеет пожать плоды своих трудов. Пятисимвольные имена лобовым перебором уже не находятся в принципе, точнее - находятся, конечно, но... смысл?! Разослать сто миллионов (!) писем, чтобы собрать ту же сотню тысяч адресов?!
Другое мощное оружие - перебор по словарю. Кстати говоря, принятая система раздачи адресов в корпорациях (по имени и/или фамилии сотрудников) этому только способствует, поскольку, во-первых, существуют словари имен и фамилий, а, во-вторых, даже если какая-то конкретная фамилия в таком словаре отсутствует (например, "Вуглускреб"), то она все равно содержит предсказуемые корни и подчиняется правилам чередования гласных и согласных, что существенно ограничивает перебор.
Короткий лингвистический ликбез. Большинство русских (и японских) имен содержат одинаковое количество попеременно чередующихся гласных и согласных (Таня, Маня, Мазепа, Иванов, Сидоров). Имена, включающие в себя несколько подряд идущих гласных (Козлов, например) также широко распространены, но... самих сочетаний подряд идущих согласных очень и очень немного, причем, в различных языках эти сочетания разные. Мы с трудом выговариваем звук "th", в то время как американцы приходят в ужас от слова "защищающиеся" (попытайтесь записать его латиницей и пусть вас охватит гордость за наш язык).
Рисунок 3. ...а гласных в латинском алфавите всего шесть.
Естественно, все, что известно лингвистам, известно и хакерам (тем более, что об этом можно прочесть в любом лингвистическом учебнике, там же даны и таблицы распространенности различных сочетаний звуков и букв). Учитывая, что гласных в латинском алфавите только шесть, нетрудно подсчитать, сколько наберется "осмысленных" имен, сгенерированных с учетом лингвистических особенностей (простейшие генераторы, которые легко найти в сети, исходят из предположения, что гласных и согласных должно быть поровну. Более сложные программы, использующие сложные психофизические модели, как правило, распространяются за деньги, однако и те, и другие дают поразительный результат и эффективно "находят" даже девятисимвольные имена - разумеется, без учета словаря).
Как вариант, можно использовать словарь и программу модификатор - переставляющую буквы местами, записывающую "O" как "ноль", "l" как единицу, набирающую русские имена латинскими буквами с учетом их расположения на клавиатуре: "Марина" -> "Vfhbyf" и т.д. и т.п.
Короче говоря, даже если нигде не светить свое "мыло", настырные спамеры его все равно найдут (исключение составляют длинные - свыше пяти-шести символов - имена, состоящие из одних согласных букв, цифр и спецсимволов). Можно ли защититься от данных атак? На уровне почтового сервера - можно. Достаточно генерировать сообщение о недоставке в ответ на все подозрительные сообщения или даже на все сообщения с неизвестным адресатом (т.е. такому адресату, которому получатель сообщения ранее не отправлял никакой корреспонденции). Практика показывает, что честные пользователи сразу (или через некоторое время) повторяют попытку отправки вновь, в то время как спамеры тут же заносят данный адрес в список несуществующих. Кстати говоря, поскольку спамеры анализируют уведомления о недоставке не вручную, а с помощью автоматизированных программ, выдирающих из тела письма код ошибки, то имеет смысл добавить в уведомление русский текст, предлагающий пользователю отправить сообщение еще раз, чтобы он зря не нервничал, полагая, что ошибся в адресе.
Базовые почтовые протоколы разрабатывались в эпоху ранней юности Интернета (когда никаких вандалов не существовало) и с тех пор практически не претерпели изменений, став легкой добычей для хакеров и заставив нас расплачиваться за ошибки своих отцов и дедов.
Впрочем, не будем о грустном. Все не так уж и мрачно. Протоколы постепенно дорабатываются, появляются новые механизмы аутентификации, однако в силу децентрализованной природы Интернета их внедрение затягивается на неопределенный срок...