Почему электронные письма легко подделать

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

Как мошенникам удается создавать «идеальные» подделки? Андрей Константинов отвечает на этот вопрос в своем докладе об идентификации электронных писем на 36-й хакерской конференции Chaos Communication Congress. Он также рассказывает о том, насколько эффективна защита от фальшивых сообщений.

Проблема № 1. Почта должна работать бесперебойно

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

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

Проблема № 2. Протокол электронной почты без аутентификации

Основной протокол для взаимодействия «клиент-сервер» и «сервер-сервер» — SMTP. Он был предложен в 1982 году и последний раз обновлялся больше 10 лет назад, в 2008-м. С точки зрения безопасности SMTP, как и многие другие архаичные стандарты, — сущий кошмар.

Вот из чего состоит сообщение электронной почты:

• SMTP-конверт. Этот элемент используется в моделях «сервер-сервер» и никогда не отображается в почтовых клиентах. В нем прописаны адреса отправителя и получателя.
• Заголовки. Они отображаются в почтовых клиентах. Именно там находятся хорошо знакомые пользователям поля «От кого», «Кому», «Дата» и «Тема», которые есть в каждом электронном письме.
• Тело письма. Собственно текст сообщения и другое содержимое.

Из чего состоит сообщение электронной почты. Источник

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

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

Не нужно быть профессиональным хакером, чтобы понимать, что с этим могут возникнуть проблемы.

Протокол электронной почты не позволяет понять, что сообщение действительно отправлено тем, кто указан в поле «От кого».

Проблема № 3. Ложные исходящие и входящие

Поскольку любая переписка подразумевает общение двух сторон, эта проблема с отсутствием механизма аутентификации разделяется на две подпроблемы.

С одной стороны, вы хотите быть уверены, что полученное вами письмо действительно отправлено тем, кто указан в поле «от». С другой стороны, вам не хотелось бы, чтобы кто-либо еще мог отправлять корреспонденцию, которая выглядела бы, как отправленная с вашего адреса. К сожалению, текущий стандарт этого гарантировать не может.

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

Попытка исправления № 1. Технология Sender Policy Framework, SPF

В основе SPF лежит довольно простая идея: сервер-получатель должен иметь возможность проверить, совпадает ли адрес сервера, с которого фактически было отправлено сообщение, с адресом подлинного почтового сервера, ассоциированного с доменом отправителя.

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

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

Итог:

• SPF помогает проверить, действительно ли сообщение пришло с указанного сервера.
• Адрес, который видит пользователь, по-прежнему можно подделать.

Попытка исправления № 2. Технология DomainKeys Identified Mail (DKIM)

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

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

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

Итог:

• DKIMпозволяет включать в сообщения цифровую подпись, что помогает серверу-получателю удостовериться, что сообщение действительно отправлено вами.
• Внедрить ее непросто, поскольку система подразумевает управление криптографическими ключами.
• Злоумышленники могут просто удалить подпись и отправить поддельное письмо от вашего имени.
• Определенные ошибки конфигурирования могут позволить злоумышленникам создавать поддельные сообщения с подлинными DKIM-подписями.

Попытка исправления № 3. Технология Domain-based Message Authentication, Reporting and Conformance (DMARC)

Несмотря на довольно длинное название, протокол DMARC проще для понимания, чем SPF или DKIM. По сути это их логическое продолжение, пытающееся устранить наиболее очевидные недочеты.

Во-первых, DMARC позволяет администратору домена выбрать, какой механизм защиты будет использоваться на сервере — SPF, DKIM или оба. Это позволяет закрыть очевидную проблему с DKIM. Во-вторых, решается и проблема с SPF, поскольку проверяются и адрес в поле «От кого», и адрес сервера в SMTP-конверте.

Из минусов: протокол DMARC достаточно новый и еще не стал стандартом: RFC 7489 даже не определяет его как «предложенный стандарт», а всего лишь присваивает статус Informational («Информационный»). В результате он используется далеко не так широко, как следовало бы. Согласно исследованию, из 20 000 доменов только на 20% вообще использовалась технология DMARC, и только 8,4% применяли строгие политики.

К сожалению, протокол DMARC пока еще не распространен, а во многих случаях используются политики без дополнительных проверок. Источник

Итоги:

• Технология исправляет наиболее критичные недочеты как SPF, так и DKIM.
• Она пока еще не получила широкого распространения (соответственно, потенциал реализован не полностью).

Как защититься от поддельных электронных писем

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

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

Вот несколько рекомендаций по защите электронной почты:

• Задействуйте хотя бы SPFи правильно сконфигурируйте его. При этом имейте в виду, что изобретательные злоумышленники могут обойти SPF-защиту (подробнее об этом в докладе).
• Реализуйте DKIMдля усиления защиты. Это технологически сложнее, но стоит того. Опять-таки, обеспечьте правильное конфигурирование (здесь рассказано, на что в первую очередь обращают внимание злоумышленники).
• Лучше всего использовать DMARC, поскольку эта технология устраняет самые очевидные недостатки SPF и DKIM.
• Также проверьте настройки почтового сервера для обработки входящих сообщений.
• Используйте защитные решения, поддерживающие работу с современными механизмами аутентификации. Например, Kaspersky Security для почтовых серверов и Kaspersky Security для Microsoft Office 365.