Блог Cisco в России и СНГ
Share

Защита от Email атак нового поколения


June 27, 2013


Фишинг атака, произошедшая на РЖД вызвала очень большой резонанс в СМИ.

РИА Новости http://ria.ru/politics/20130619/944474840.html#ixzz2WkJeI0LD

Информацию о якобы имевшей место отставке президента РЖД Владимира Якунина, разосланную в среду вечером неизвестными лицами от имени правительственной пресс-службы, распространили все российские информагентства и другие крупнейшие СМИ, включая основные ТВ-каналы.

Поддельное сообщение неизвестные разослали около 20:00 мск среды, и уже вскоре не нашедшая подтверждения новость о кадровых перестановках стала одной из главных тем в ключевых российских СМИ. В 20.06 сообщение об этом выпустили РИА Новости и Интерфакс, в 20.09 ИТАР-ТАСС и РБК. Также ложное сообщение передали мировые агентства Рейтер и Bloomberg.

Эта атака поднимает интересные вопросы, связанные как с доверием в интернет, что уже описал Алексей Лукацкий в своем блоге, так и вопросы, связанные с увеличением количества целевых фишинг-атак нового поколения.

Этот тип атаки очень распространен. Устоявшегося русскоязычного термина не существует , на английском языке это называется Email Spoofing. SMTP протокол практически является ровесником IP протокола, спецификация IPv4, RFC 791 появилась в 1981 году, а первая спецификация SMTP, RFC821 появилась в 1982 году. SMTP протокол небезопасный по своей природе, он очень простой, для отправки письма достаточно четырех команд и любой человек, даже очень слабо знакомый с основами SMTP может очень легко “обмануть” принимающий сервер и отправить почту от любого имени. Однако существует ряд дополнений к SMTP, которые позволяют корректно аутентифицировать отправителя и проверить, что письмо не является поддельным.

Рассмотрим, как работает SMTP, почему возможна подделка адресов, и как с этим можно бороться. Когда письмо отправляется по SMTP, необходимый минимум для отправки письма — это четыре команды.

1. Команда EHLO. Первой вводится команда EHLO (HELO в старой спецификации), после которой идет доменное имя подключившегося сервера. Стандарт говорит, что ввод корректного доменного имени является обязательным, а если у подключившегося нет доменного имени (например, назначен динамический IP), то должен использоваться IP адрес.

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

2. Команда MAIL FROM. Команда MAIL FROM сообщает SMTP серверу адрес отправителя письма. Обычно этот адрес используется для служебных целей (отправка сообщения о доставке), и механизмы его дополнительной проверки в RFC  отсутствуют.

3. Команда RCPT TO. Эта команда сообщает SMTP серверу адрес получателя письма. Сервер выполняет все необходимые и дополнительные операции, а именно — может ли он отправлять письма для этого получателя, существует ли этот получатель в компании, и т.д.

Вышеприведенные команды называется “Конвертом” (Envelope).

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

Итак, основная проблема в том, что в протоколе у нас отсутствуют механизмы проверки правильности адреса отправителя. Мы можем использовать любой адрес в поле MAIL FROM:, более того, мы можем специальным образом сформировать письмо и поставить любой адрес в поле From: в заголовке письма, в результате чего большинство почтовых клиентов покажет корректный обратный адрес.

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

Второй метод проверки основан на проверке соответствия правильности DNS записей. При подключении к SMTP серверу мы знаем IP адрес подключившегося. Для выполнения дополнительных проверок мы можем запросить DNS PTR запись для этого IP адреса, а потом запросить DNS А запись для проверки соответствия записей в прямой и обратной зонах. И дополнительно проверить доменную часть отправителя (та, которая вводится в MAIL FROM команде). SMTP сервер может сделать запрос на проверку MX записи для домена отправителя, и если MX домен отправителя не существует, отбросить это письмо.

Защищают ли подобные методы от спуфинг атак? Плохо. К почтовому серверу может подключиться атакующий с корректной DNS записьмо (DNS проверка хоста пройдет), использовать корректное доменное имя в запросе EHLO (проверка будет осуществлена), использовать в поле MAIL FROM: адрес, который пройдет проверку и сформировать поддельное письмо с корректными заголовками, которое будет очень похоже на настоящее. Настоящие спуфинг атаки именно так и делаются, и именно с этим и столкнулись российские госорганы.

Для защиты от спуфинга были разработаны два дополнительных стандарты Sender Policy Framework/Sender ID Framework (SPF/SIDF) и Domain Keys Identified Management (DKIM). Все эти системы ипользуют  DNS для своей работы. SPF позволяет администраторам определить, какие хосты могут отправлять почту для определенного домена с помощью SPF записи в DNS. Sender IF Framework дополняет проверки SPF тем, что он предлагает использовать для проверки не только значения, введенные в  MAIL FROM, но и значения в заголовках письма. В качестве примера, вот как выглядит SPF запись cisco.com:

cisco.com.86400 IN TXT “v=spf1 ip4:171.68.0.0/14 ip4:64.100.0.0/14 ip4:64.104.0.0/16 ip4:72.163.7.160/27 ip4:72.163.197.0/24 ip4:128.107.0.0/16 ip4:144.254.0.0/16 ip4:66.187.208.0/20 ip4:173.37.86.0/24 ip4:173.36.130.0/24 ip4:204.15.81.0/26 ip4:216.206.186.129/25″ ” ip4:208.90.57.0/26 mx:res.cisco.com ~all”

Эта запись говорит о том, что мы поддерживаем SPF версии 1 (стандартный SPF), что если соединение было установлено с адресов, перечисленных в списке, то эти адреса имеют право отправлять электронную почту для домена cisco.com, а также у нас есть еще один сервер для отправки с именем res.cisco.com.

DKIM — это механизм, основанный на асимметричных алгоритмах шифрования. Отправитель генерирует два ключа, открытый ключ публикуется в DNS в виде  TXT записи, закрытый ключ используется почтовым сервером для подписи заголовков письма. Принимающий почтовый сервер запрашивает соответствующую запись домена отправителя и проверяет подпись, в случае несовпадения выдает ошибку.

SPF не обеспечивает механизмов проверки целостности, а DKIM сигнатуры у нас проверяют только заголовок письма. Значения, введенные в  MAIL FROM: и EHLO остаются необработанными, поэтому рекомендуется использовать эти два механизма одновременно. Эти механизмы, при их правильном использовании, являются достаточно надежным средством, чтобы защититься от большинства spoofing атак. Они не требуют больших затрат или времени на использование и развертывание и позволяют надежно защититься от поддельных сообщений.

Компания Cisco и решения Cisco Email Security обеспечивают полную защиту от большого количества email атак и полностью поддерживают все существующие стандарты Email аутентификации, SPF/SIDF, DKIM, а в следующей версии мы добавим поддержку нового стандарта, DMARC, который дополняет и расширяет существующие возможности по аутентификации отправителей и по защите от spoofing сообщений.

Tags:
Оставить комментарий

3 Comments

  1. Остается открытым вопрос о публикации на сайте правительства – http://www.rbcdaily.ru/society/562949987478754
    Но в целом всё верно и e-mail spoofing в новостном и корпоративном сегменте большая проблема.

  2. Добрый день!

    В предложении “Итак, основная проблема в том, что в протоколе у нас отсутствуют механизмы проверки легитимности получателя.”, по контексту более подходит термин проверка отправителя, чем – получателя.

    Максим

    • Максим, спасибо! Механическая ошибка, скоро исправлю.