И снова здравствуйте: ваши фишинг и спуфинг

Александр Борисов

Руководитель направления анализа защищенности ГК Innostage.

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

Пандемия, коронавирус, экономический кризис — это не только наша реальность, но и основные тематики фишинговых писем этого года. Согласно данным издания Informationage ( https://ia.acs.org.au/article/2020/cyber-attacks-have-peaked-in-2020.html ) количество атак за первую половину 2020 года уже превысило итоговые значения за весь 2019 год. Основной прирост в данной статистике вызван очередным бумом фишинга. Согласно последним исследованиям, количество фишинговых атак увеличилось почти в 2 раза.

Как правило, злоумышленники используют два подхода к проведению атак, это “spray and pray” и “spear-phishing”. В первом случае, злоумышленники рассылают письма без детальной проработки на большую аудиторию с расчетом на количество срабатываний, отсюда и название: «распыли и молись». Во втором случае ведется серьезная подготовительная работа, и целью атаки становится один человек или небольшая группа.

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

Одна из техник, которую довольно часто используют злоумышленники – это подмена отправителя (Email spoofing). Рассмотрим эту технику более детально. История этой атаки довольно длинная, но она не теряет своей актуальности и по сей день. Зачастую ее удается применить из-за использования стандартных конфигураций – “лишь бы работало”.

Перед углублением в детали атаки, вспомним, как работает электронная почта в принципе.

Для передачи электронных писем между серверами используется протокол SMTP. Вот так в его представлении выглядит обычное письмо, которое Алиса из домена «a.org» хочет отправить Бобу в домене «b.org»:

Письмо состоит из:

• SMTP Конверта
• Контента, который включает:
• Тело письма
• Заголовки ( rfc-5322 , rfc-4021), которые, как правило, и отображаются у получателя в почтовом клиенте.

Чтобы доставить это письмо на незащищенный почтовый сервер, не обязательно иметь свой собственный. Достаточно установить с сервером получателя соединение на 25 порту netcat’ом или telnet’ом и перепечатать команды выше. В результате этого в почтовом клиенте Bob увидит такое письмо:

Как видим, информация, которую мы указали в заголовках, была успешно отображена почтовым клиентом, в данном случае – Outlook’ом. (Включая указанную дату).

При отправке этого письма можно заметить, что мы указываем отправителя и получателя дважды – в конверте и в самом сообщении, но зачем? Давайте определим следующие аналогии с обычной почтой:

• SMTP конверт – бумажный конверт, на котором мы пишем имя отправителя (MAIL FROM) и имя получателя (RCPT TO). По этой информации почтальон (почтовый сервер) будет знать, куда надо доставить письмо.
• Контент – открытка, которая кроме различных полей так же содержит поля «От кого» и «Кому», которые соответствуют заголовкам «From» и «To» в заголовках.

Когда Алиса отправляла письмо Бобу, почтовый сервер (почтальон) смотрит только на конверт, игнорируя содержимое. Боб же, получив письмо, игнорирует конверт и определяет отправителя по заголовках (полям на открытке).

Но что будет, если мы укажем разных отправителей в конверте и заголовках письма? Это и будет классический случай подмены отправителя. Если изменить заголовок “From” («Alice» на «Trent») в вышеупомянутом письме и повторить отправку, Боб получит письмо якобы от Трента, но почтовый сервер по-прежнему будет думать, что оно от Алисы.

И на этом основана данная атака, которая позволяет злоумышленнику при проведении фишинговой атаки подделать отправителя и значительно повысить эффективность своего фишинга.

Чтобы защищаться от такой подмены отправителя, будет достаточно сверить поле «MAIL FROM» из SMTP-конверта и заголовка «From», с чем почтовые сервера и спам-фильтры иногда справляются.

Подмена отправителя не ограничивается этим примером, но он наиболее ярок и встречается в реальной жизни (чаще, чем хотелось бы). В противодействие подмене отправителя были разработаны методы E-mail аутентификации - DKIM, DMARC, SPF . Если кратко:

• SPF ( RFC-7208 ) – определяет с каких хостов разрешено отправлять почту от имени вашего домена, при получении проверяются адреса из SMTP-конверта (“HELO” и MAIL FROM”), игнорируется заголовок “FROM”.
• DKIM ( RFC-6376 ) служит для цифровой подписи тела письма и основных его заголовков.
• DMARC ( RFC-7489 ) – исправляет недостатки SPF и DKIM – сверяет домен из заголовка “FROM” с доменом из поля сигнатуры “d=” при проверке DKIM или с доменом из поля “MAIL FROM” SMTP конверта при проверке SPF, а также говорит, что делать с письмами от имени домена, которые не прошли данную проверку.

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

Базовая проверка SPF:

Настройка SPF-записей довольна сложна и многогранна, полна подводных камней и нюансов, которые могут приводить к избыточности и синтаксическим ошибкам. А ошибки, в свою очередь, могут свести толк от SPF к нулю. Вот интересный пример у Сбербанка из 2016 года - https://habr.com/ru/post/307852/ .

Рассмотрим моменты, которые, на мой скромный взгляд, требуют дополнительного внимания при создании SPF-записи:

• Значения “Мягкий отказ” («~») и “Не определено” («?») – опции, которые говорят, что если письмо провалит выбранные проверки, оно не будет отброшено. В некоторых случаях это может добавить очков в Spam-Rate.

Если вы используете СЗИ для защиты почты от фишинга, то вам будет знаком термин Spam-Rate. В данном случае это синтетическая метрика, присваиваемая сначала письму, а затем и серверу, с которого это письмо ушло (в разных СЗИ данные механизмы могут быть реализованы по-разному). Эта метрика характеризует потенциальную возможность получения зловредного письма от сервера-отправителя. При сработке «мягкого отказа» («~»), ваше СЗИ может увеличить Spam-Rate для сервера отправителя и пропустить письмо дальше. Однако, если будут провалены последующие проверки и Spam-Rate превысит определённый порог, письмо будет помечено как спам, а сервер-отправитель будет заблокирован.

• Include – не панацея. Если проверка SPF провалится внутри блока include, письмо не будет отброшено (даже если -all), а проверки продолжатся на верхнем уровне SPF.
• Нужно проверить, нет ли возможности отправить сообщение из-под IP, указанных в SPF. Бывали случаи, когда гостевой wi-fi выдавал IP адреса, которые были указаны в SPF записи или хост, включенный в SPF, живет с RCE c 2003 года на периметре. Лучше проверять такие моменты.

Базовая проверка DKIM:

Подменить цифровую подпись DKIM злоумышленник вряд ли сможет из-за особенностей ее формирования. DKIM, по большему счету, бесполезен без DMARC, т.к. если мы просто обрежем подпись сообщения, получатель не сможет ее подтвердить или же узнать, должна ли она быть вообще.

Базовая проверка DMARC

DMARC использует протоколы SPF и DKIM и проверяет, как письмо проходит ту или иную проверку указанных технологий.

Если с доменом не ассоциирована DMARC запись, высока вероятность, что злоумышленник сможет отправлять письма от имени данного домена, если на стороне получателя не используются дополнительные механизмы контроля заголовка «From». То же касается случая, когда его политика указывает игнорировать провал проверки DMARC (в DNS записи это отражено как «p=none»), и такие конфигурации могут добавить штрафных баллов в Spam-Rate.
Даже в 2020 году многие компании игнорируют использование DMARC. По информации 2020-DMARC-Adoption-Report почти 60% банков в Европе игнорируют данный метод аутентификации, а 20% имеют политику «None». Более подробный отчет по широкому кругу компаний за 2019 год можно найти тут .

Дополнительную информацию по статистике использования SPF/DKIM/DMARC в интернете можно получить по ссылке - https://trends.builtwith.com/mx/

Капля дегтя

Почтовые протоколы не создавались как протоколы для безопасного (в широком смысле) обмена почты. Основной целью было доставить сообщение, а уже потом возникла потребность в повышении безопасности существующих протоколов. Именно так и появились SPF, DKIM, DMARC. Однако даже в случае корректной конфигурации всех механизмов аутентификации может быть найден способ их обхода. Так на недавнем BlackHat USA 2020 были представлены 18 различных атак, позволяющих обходить данные механизмы – https://i.blackhat.com/USA-20/Thursday/us-20-Chen-You-Have-No-Idea-Who-Sent-That-Email-18-Attacks-On-Email-Sender-Authentication.pdf .
И тут нам на помощь снова придут решения класса Security Email Gateway. Они могут не только работать с Spam-Rate, как я писал выше, но и использовать репутационные списки, вводить дополнительные проверки для писем и их заголовков, предъявлять дополнительные требования к серверам отправителям и т.д. Конечно, нужна будет расширенная настройка и регулярная адаптация, но это лучше, чем пасть жертвой фишинга, верно?

Мы рассмотрели особенности работы электронной почты и основные доступные методы защиты, однако защита от фишинга этим не ограничивается.

Как уменьшить возможности фишинговой атаки?

• Настройте SPF/DKIM/DMARC для вашего домена.
• Убедитесь, что ваш почтовый сервер корректно проверяет SPF/DKIM/DMARC для входящей почты.
• Используйте спам-фильтры.
• Обновляйте ПО почтового сервера.
• Используйте Security Email Gateway решения.
• Используйте песочницы (SandBox) – этот класс решений уже де факто стандарт для защиты от ВПО (вирусного программного обеспечения) в письмах.
• Проводите обучение пользователей:
• Устраивайте им фишинговые рассылки, так, как бы это проводил настоящий злоумышленник
• Проводите курсы повышения осведомленности (Security Awareness)

Сочетание этих двух подходов будет наиболее эффективно для повышения осведомленности пользователей.

Полезные материалы:

Чтобы быстро проанализировать корректность DKIM, SPF DNS записей, можно воспользоваться утилитой mailspoof - https://github.com/carlospolop-forks/mailspoof .
https://xakep.ru/2014/03/05/easy-hack-182/
https://habr.com/ru/company/cbs/blog/314738/
https://habr.com/ru/company/cloud4y/blog/341096/
https://book.hacktricks.xyz/pentesting/pentesting-smtp#mail-spoofing
https://mailsploit.pwnsdx.com/index
Внедрение DMARC для защиты корпоративного домена от спуфинга - https://habr.com/ru/company/mailru/blog/315778/

Заключение

У злоумышленников огромной набор возможностей по проведению фишинговых рассылок. Нам же необходимо использовать известные методы по противодействию фишингу, внедрять СЗИ, работать с ними и постоянно проводить обучение пользователей.