PDA

Просмотр полной версии : Определение подлинности "перехваченных" электронных писем. DKIM



stayer
03.03.2014, 11:47
Одной из популярных технологий проверки электронных данных является использование их электронной подписи. Это подпись основана на ассиметричной криптозащите (http://xmail.net/teapot/gpg4usb/#appendix_a), суть последней состоит в наличии 2-х половинок ключа (ключевой пары) у отправителя (секретный ключ) и получателя (публичный ключ). В кратце суть электронной цифровой подписи (ЭЦП) (http://xmail.net/teapot/gpg4usb/#signature_text) я уже описывал в статье про автономную криптозащиту:


Пусть Алиса хочет послать Бобу некое текстовое письмо, а Боб хочет удостовериться в его подлинности. Для решения этой задачи Алиса может использовать свой секретный ключ. При помощи своего секретного ключа она генерирует практически уникальный публичный слепок письма и прикладывает к тексту, создавая, тем самым, подписанное письмо. Боб при помощи публичного ключа Алисы проверяет подписанное письмо на подлинность.

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

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


Хакеры из известной группы «Anonimus» выложили в сети переписку заместителя главы украинской националистической организации «Тризуб имени Степана Бандеры» Андрея Тарасенко с заместителем председателя Меджлиса крымско-татарского народа Асланом Омером Кырымлы ....

16631


Одной из известных технологий проверки подлинности переписки, основанной на ЭЦП, является DKIM - Domain Keys Identified Mail (http://ru.wikipedia.org/wiki/DomainKeys_Identified_Mail).

Современные системы аутентификации отправителя: SIDF и DKIM

Возникновение идеи установления подлинности отправителя онлайн-корреспонденции, использующего каналы электронной почты, было обусловлено беззащитностью протокола SMTP в условиях расширения масштабов интернет-угроз. Умышленная подмена или модификация адреса отправителя стали излюбленным приемом спамеров и фишеров, стремящихся уйти от юридического преследования и ограничительных мер со стороны интернет-провайдеров. По экспертным оценкам (http://www.microsoft.com/technet/technetmag/issues/2006/12/SIDF/default.aspx?loc=ru/), в настоящее время более 95% фишерских сообщений препровождаются фальсифицированным адресом отправителя.


Распространению спама невольно способствует и принцип работы МХ-серверов, которые обязаны принимать корреспонденцию от любого клиента в Сети и доставлять ее обслуживаемым клиентским системам. По данным IETF (http://www.rfc-editor.org/rfc/rfc4871.txt), в современном Интернете насчитывается более 70 миллионов доменов, а число пользовательских адресов в значительной мере превышает эту цифру. В подобной ситуации гарантировать подлинность источника электронных сообщений может надежный механизм аутентификации.

SIDF

Разработанная Microsoft технология аутентификации Sender ID Framework (SIDF) требует публикации в DNS так называемых SPF-записей. SPF-запись вносится интернет-провайдером или владельцем домена в свой файл зон DNS-сервера и представляет собой текстовую запись всех IP-адресов серверов исходящей почты с указанием домена.


Принимающий сообщение SMTP-сервер запрашивает наличие SPF-записи в соответствующем файле в DNS. При наличии записи производится проверка IP-адреса отправляющего сервера по списку авторизованных к рассылке IP-адресов. Механизм SIDF предусматривает проверку адреса отправителя не только на уровне SMTP, но и адресов, указанных в теле письма в строке «From» («Отправитель»). По окончании проверки письмо соответствующим образом помечается (сервисы Hotmail и MSN отражают результаты проверки в особом окне), и SIDF разрешает серверу получателя провести анализ сообщения на основе репутации, контента и прочих критериев, установленных местным регламентом.


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


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


По экспертному мнению, наличие лицензионных ограничений на использование спецификаций SIDF в значительной мере замедлило темпы ее внедрения. Когда же Microsoft открыла неограниченный доступ (http://www.spamtest.ru/news?id=204194777) к этой технологии, некоторые организации выразили несогласие с рядом формулировок, содержащихся в бесплатном лицензионном соглашении.


По оценке Microsoft, SIDF защиoftn более 8 миллионов доменов; технологию используют такие компании как Alt-N, Barracuda, Cloudmark, Exchange Hosted Filtering, Iconix Message Systems, Port25 Solutions, Secure Computing, Sendmail, Sonic Wall, Strongmail, Symantec и Tumbleweed. Тем не менее, по данным MediaPost, только 43% легитимной почты сертифицируется Sender ID, а open-source сообщество пока предпочитает обходиться собственными решениями.

DKIM

Технология DKIM, объединяющая спецификации Yahoo DomainKeys и Cisco Internet Identified Mail (IIM), не только обеспечивает верификацию отправителя, но и гарантирует целостность доставленного электронного послания. Механизм DKIM предусматривает сопровождение писем шифрованной цифровой подписью, добавляемой в служебный заголовок письма и невидимой конечному получателю.


Легитимность электронной подписи автоматически проверяется на стороне получателя, после чего прошедшее DKIM-проверку письмо подвергается штатной обработке и/или направляется конечному адресату. Если указанный источник сообщения не был уполномочен производить рассылку, письмо может быть идентифицировано (по усмотрению интернет-провайдера) как спамовое или фишинговое сообщение. Политика принимающей стороны может запрещать прием писем без DKIM-подписи из поддерживающих DKIM источников.

Технология DomainKeys работает как стандартная криптосистема. Для каждого сервера генерируется одна или несколько пар ключей для асимметричного шифрования. Открытый ключ публикуется в DNS и вносится в запись txt-ресурса политики субдомена domainkey. Закрытый (приватный) ключ «привязан» к политике и загружается поддерживающим DKIM почтовым ПО.


В связи с возможностью модификации электронных сообщений в процессе пересылки они по мере необходимости преобразуются согласно требованиям SMTP-стандарта (7-бит MIME), то есть обретают форму, в которой и будут представлены адресату. Сервер-отправитель (или пользовательский почтовый агент) затем с помощью закрытого ключа генерирует шифрованную подпись, которая отражает информацию, взятую из заголовков письма. Во избежание злоупотреблений DKIM-подпись должна обязательно включать данные из читаемых адресатом полей From («От»), Sender («Отправитель»), Subject («Тема»), Date («Дата»), To («Кому»).


DKIM-подпись ставится отдельным заголовком к письму и предваряет все прочие заголовки. Заголовок DKIM может выглядеть следующим образом:



DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=o3PMxZIlFKjVfLJUugi1uubwjHnE0IIu1tsDG/ c6SwXYfW842s1df01fR+UF0QmnVhVCaTa3x NiGZZeqSITw6oLLNv5zvdCqd6BrkkkuucPPxvTV/ VuM9Uhw5R9bNU50Fg+B89/ RmkciPJkluHEX+RLaZ3d/P1adg+edL1Pwxbo=


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


В отличие от Sender ID, DKIM при верификации отправителя опирается на имя домена, так как разработчики данной технологии считают, что оно стабильнее IP-адреса и точнее идентифицирует реального адресата. Эта технология исключает проблемы с переадресацией сообщений, присущие SIDF.


DKIM не нарушает инфраструктуру современного почтового сервиса, ее ключи могут храниться в любом формате вне зависимости от типа сервера, а заголовки совместимы с SMTP-стандартом, не требуют MIME-поддержки и могут генерироваться как на уровне SMTP-сервера (MTA, MSA/MDA), так и на уровне пользователя (MUA). Верификацию могут производить и промежуточные MTA, добавляя в письмо соответствующий заголовок, что упрощает фильтрацию почты на уровне MUA, настраиваемых пользователями. В принципе DKIM автоматически функционирует в серверном звене, ничего не требуя от пользователя.


В отличие от SIDF, использование данной технологии подразумевает проведение определенных модификаций программного обеспечения почтовых серверов и клиентов. Необходимость поддержки DKIM обеими сторонами – отправителем и получателем – рассматривается специалистами как серьезный недостаток. Кроме того, использование DKIM требует дополнительных накладных расходов на обработку почтовых сообщений, более частых просмотров записей DNS, что увеличивает нагрузку на вычислительные ресурсы почтовых серверов и отражается на количестве обрабатываемых ими сообщений.


Процедура обновления ПО упрощается, если сервер уже поддерживает прототип DKIM – DomainKeys. В настоящее время разработаны DKIM-плагины для многих популярных MTA. DomainKeys успешно используется в почтовых сервисах Yahoo и Google (Gmail). Поддержка проверки отправителя по технологии DomainKeys имеется в SpamAssassin начиная с версии 3.1.
Спецификации DKIM предложены (http://www.spamtest.ru/news.html?id=207508910) IETF к публичному обсуждению и оценке в качестве проекта стандарта аутентификации RFC 4871. Публикация формального проекта и его официальное утверждение, после которого можно будет стандартизировать новый заголовок в качестве расширения SMTP, будет способствовать более широкому внедрению данной технологии.

Аутентификация и проблема спама

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


Системы аутентификации осваивают не только легальные пользователи, но и спамеры. Компьютерные мошенники нередко прибегают к законной регистрации доменных имен, схожих с именами распространенных онлайн-сервисов (например, verify-paypal.com). Легальные организации, в свою очередь, могут просто не внести соответствующие записи и ключи в DNS и стать жертвами фальсификаторов. Рассылать спам могут и зомби-компьютеры – «подлинные» отправители, с точки зрения SIDF и DKIM. Тем не менее, возможность проследить нелегитимную рассылку до IP-адреса или домена позволяет принять надлежащие меры и повышает вероятность поимки ее инициаторов.


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


В принципе технологии SIDF и DKIM комплементарны и могут использоваться совместно. Создатель SPF Мен Вонг (Meng Wong) разработал (http://www.spamtest.ru/document?pubid=19268&context=1) проект сети Unified SPF, поддерживающей одну и более систем аутентификации отправителя в зависимости от настроек системного администратора. Вонг уверен, что разнообразие – это преимущество, а не предмет для войны стандартов.




Несмотря на все, слепо доверяться ЭЦП и технологиям, подобным DKIM нельзя (http://a-weidemann.livejournal.com/58652.html). К примеру, если взломать почтовый ящик абонента Алисы и начать от ее имени вести крамольную переписку с Бобом, то ЭЦП будут в порядке, DKIM будет также подлинным. А если вставить в зад паяльник ...

Так что DKIM - необходимое, но не достаточное средство проверки подлинности электронных писем в современном мире.

Yura_ND
28.05.2016, 16:23
Опять таки, система уязимая к мидлмену Мэллори, когда Меллори имеет возможность влиять на работу центров сертификации и имеет доступ к трафику Боба. Тогда Мэллори подменяет письмо подписывает его своей ЭЦП, подделывает адрес Алисы, и ставит имя своего сертификационного центра. Боб проверяет фальшивку, получает от Меллори подтверждение и остается в счастливом неведении.
Если все выплывет наружу, то Мэллори просто нагибает очередной центр сертификации.
Поэтому Боб и Алиса либо должны защитить свой трафик (что мало реально), либо предварительно обменяться ЭЦП надежным способом.
Ну это конечно, если Мэллори умеет нагибать центры сертификации и провайдера, а он умеет.

Yura_ND
28.05.2016, 19:22
Для тех кто скажет что невозможно, подделать сертификат gmail.com и обломать https , скажу это не так . Это можно сделать, так как обычно браузер инициирует соединение по http и уже потом его редиректят на https и грамотное проксирование позволяет совершить мидл мен атаку.




Необходимо просто ;)
Следить за всем http трафиком
Пресекать любую попытку сервера (gmail) перенаправить пользователя на https, заменять ссылки, заголовок Location в редиректах и т.д.
Когда клиент делает http запрос, проксировать этот запрос к серверу


Сервер не видит ничего подозрительного, для него соединение идёт через https (впрочем, если бы сервер требовал клиентской аутентификации, то ничего бы не вышло).


Клиент видит, что соединение идёт через http, но ошибок SSL нет, и, как мы выше выяснили, браузер не жалуется, и пользователь, скорее всего, не заметит отсутствия шифрования.


Вывод: пока браузеры поддерживают http вы уязвимы для Мэллори.

- - - Добавлено - - -

Для тех кто скажет что невозможно, подделать сертификат gmail.com и обломать https , скажу это не так . Это можно сделать, так как обычно браузер инициирует соединение по http и уже потом его редиректят на https и грамотное проксирование позволяет совершить мидл мен атаку.




Необходимо просто ;)
Следить за всем http трафиком
Пресекать любую попытку сервера (gmail) перенаправить пользователя на https, заменять ссылки, заголовок Location в редиректах и т.д.
Когда клиент делает http запрос, проксировать этот запрос к серверу


Сервер не видит ничего подозрительного, для него соединение идёт через https (впрочем, если бы сервер требовал клиентской аутентификации, то ничего бы не вышло).


Клиент видит, что соединение идёт через http, но ошибок SSL нет, и, как мы выше выяснили, браузер не жалуется, и пользователь, скорее всего, не заметит отсутствия шифрования.


Вывод: пока браузеры поддерживают http вы уязвимы для Мэллори.