Пример спуфинга в Gmail: мошенник подделал обратный адрес
facebook.com, демоМногие не знают, насколько легко подделать обратный адрес электронного письма. То есть отправить письмо с чужого адреса или с произвольного домена. Спамеры, фишеры и прочие мошенники постоянно обходят защиту SPF, DKIM и DMARC.
Посмотрим, как они это делают и как защитить своё письмо от спуфинга.
Средний офисный работник получает 120 писем в день, большинство из которых не требует срочного ответа, а некоторые представляют откровенный спам. Тут без фильтрации не обойтись.
А где фильтрация — там и ошибки. Например, ваш почтовый сервер могут занести в чёрный список просто потому, что у него неудачные соседи на VPS-хостинге из того же диапазона IP-адресов. К сожалению, это нередкая ситуация.
Другая опасность — подделка адреса отправителя. Примеры со взломом Yahoo в 2014 году, взломы Gmail-аккаунтов высокопоставленных чиновников показывают, что подделка адреса — серьёзная и актуальная угроза.
Три типа атак для подделки обратного адреса, источник
Подделка адреса отправителя
Существует как минимум 18 способов подделать адрес отправителя email. Например, в 2020 году на хакерской конференции DEFCON была представлена утилита espoofer, которая позволяет обойти аутентификацию SPF, DKIM и DMARC в почтовых системах (см. слайды презентации, видео).
Программа espoofer помогает системным администраторам и пентестерам быстро выявить уязвимости в целевых почтовых серверах.
Уязвимости в почтовом сервере, выдача espoofer
К сожалению, таких уязвимостей очень много, и злоумышленники находят всё новые способы обхода защиты, потому что инфраструктура email фундаментально уязвима для таких атак (см. ниже).
Защита электронных сообщений
Как показывает практика, мошенники успешно обходят защиту SPF, DKIM и DMARC. У всех этих политик три общие уязвимости:
- Все они основаны на DNS, так что эффективно действуют все известные виды атак на DNS (например, спуфинг запросов к DNS).
- Защита адреса ограничена только доменной частью.
- Поскольку подписи DKIM применяются только почтовым сервером отправителя и проверяются почтовым сервером получателя, гарантия целостности содержимого и подлинности отправителя не является полностью сквозной. Сообщение остается уязвимым между клиентом и почтовым сервером как для отправителя, так и для получателя. Эту проблему можно решить путём правильной реализации TLS на обоих серверах.
Именно с этой задачей S/MIME справляется лучше, чем SPF, DKIM и DMARC.
Защита с помощью S/MIME
S/MIME (Secure / Multipurpose Internet Mail Extensions) — это стандарт для шифрования и подписи в электронной почте с помощью открытого ключа:
- Подписи S/MIME применяются непосредственно почтовым клиентом отправителя и проверяются только почтовым клиентом получателя. Невозможны никакие манипуляции с сообщением ни на каком этапе.
- Открытый ключ для проверки подписи прилагается к сертификату, который идёт вместе с письмом. Поэтому почтовому клиенту не нужно полагаться на запись DNS.
- Организация отправителя в сертификате проверена центром сертификации.
- Формат имени по стандарту RFC 822 в сертификате точно соответствует полю
from, то есть подлинность отправителя гарантируется на уровне адреса электронной почты, а не только на уровне домена.
Как видим, существующие методы SPF, DKIM и DMARC можно обойти и подделать письмо, если отправитель не использует защиту S/MIME со сквозным шифрованием и цифровой подписью.
Подробнее о защите электронной почты для организаций на сайте GlobalSign
Комментарии (5)
dragoangel
09.02.2022 18:07+4Скажем так: о каком обходе gmail dmarc может идти речь когда у gmail чёрным по белому написано:
_dmarc.gmail.com. 600 IN TXT "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"И такое у многих freemail. Просто реклама smime. Я с таким же приколом могу дать ссылку на efail: https://efail.de и сказать что smime это тлен и он не работает от слова совсем, но это будет точно такая же не правда как и та что написана в статье, ибо у всего есть свои кондишены, есть свои недостатки, и просто делать такие вбросы ради рекламы, ну фу...
P.s. не иметь шифрования между клиентом и почтовиком, это куда более страшный кейс чем не иметь smime без которого все живут на ура и наличие smime не каким боком не защитит вашу авторизацию к серверу без шифрования, просто вброс. Настраивайте client => ssl => mta => ssl => mta и будет вам счастье. Увы да, протокол smtp не может никак гарантировать как другой клиент с обратной стороны подключиться к своему mta, но это уже не на вашей совести. Добиться mandatory client => ssl => mta очень просто настройками вашего почтового сервера. Добиться входящего mta => ssl => mta тоже не так уж и сложно с помощью dane/mta-sts или обоих вместе взятых. Dane поддерживают почти все уважающие себя mta, в отличие от mta-sts, минус только в том что для некоторых dnssec непостижимо сложен или TLD тормозит с внедрением. В случаях когда TLD тормозит внедрение dnssec можно хотя бы сам MX повесить на нормальный TLD с dnssec, этого уже будет достаточно для того чтобы заставить отправителей не падать в plaintext. Добиться исходящего mta => ssl => mta можно с помощью политик, и написать их для всех заведомо частых dst.
BigElectricCat
10.02.2022 11:44Gmail-аккаунтов высокопоставленных чиновников
Это не соединяемо от слова совершенно.
А может такой замечательный тренд, что у «высокопоставленных чиновников» нет свой государственой ИБ, что они позволяют себе гуано-ящики с тотальной индексацией содержимого использовать?
SPF, DKIM и DMARC — созданы для идентификации сервера отправителя, а не для защиты письма конкретного отправителя.
Раз вы вспомнили про S/MIME, то наверное стоит вспомнить и про PGP/GPG, которые и сейчас очень часто используют. Главное не забыть сказать, что тема письма не шифруется при шифровании самого тела письма.
edo1h
10.02.2022 16:02А может такой замечательный тренд, что у «высокопоставленных чиновников» нет свой государственой ИБ, что они позволяют себе гуано-ящики с тотальной индексацией содержимого использовать?
высокопоставленными чиновниками не рождаются.
когда человек приходит на какую-то высокую должность, то у IT/безопасников может не хватить веса убедить его отказаться от использования привычного ему личного ящика для рабочих переписок тоже.
olegtsss
Много интересных ссылок, спасибо за качественно подобранный материал. Совсем не давно был опубликован материал на аналогичную тему (https://habr.com/ru/post/647579/). Механизмы SPF, DKIM и DMARC при корректной настройке почтового сервера не пропустят relay атаку и аналогичные. И самое главное, что они работают на стороне серверов, а не клиентов. Подписывать письма на клиентской стороне — классная идея, реализовать ее можно многими способами, если в этом есть необходимость.
Было бы интересно посмотреть на практике, как проходит спам/фрод атака на тестовый почтовый сервер, чтобы детальнее понимать механизмы защиты и возможности их обхода.
Revertis
Ну вам же написали:
Видимо они думают, что всю эту информацию они предоставили тут в заметке...