Как подменить адрес отправителя электронной почты
Перейти к содержимому

Как подменить адрес отправителя электронной почты

  • автор:

Подделка письма электронной почты почти от любого человека менее чем за 5 минут и способы защиты

На протяжении большей части последних 40 лет пользователям приходилось совершать прыжок веры каждый раз, когда они открывали электронную почту. Считаете ли вы, что письмо действительно приходит от того, кто указан в графе отправителя? Большинство легко ответит «да» и на самом деле очень удивится, узнав как легко подделать электронную почту почти от любого отправителя.

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

Результатом является то, что заголовки писем, включая поля «From: » и «Reply-to: », очень легко подделать. В некоторых случаях это так же просто, как набрать «john@company.com» в поле «From: ». Объединив это с неподозрительным содержанием, убедительной графикой и форматированием, вполне возможно обмануть людей, подумавших, что сообщение в их почтовом ящике действительно пришло от банка, ФНС, руководителя или президента США.

Приняв во внимание повсеместное распространение электронной почты, вы осознаете основу нашего нынешнего кризиса информационной безопасности. Слабость в электронной почте привела к массе фишинговых атак, направленных на то, чтобы заставить людей нажимать на вредоносные ссылки, загружать и открывать вредоносные файлы, отправлять форму W-2 (аналог 2-НДФЛ в США) или переводить средства на счета преступников.

Совсем недавно Coupa, компания из Кремниевой долины, была в центре внимания после отправки данных о заработной плате всех 625 сотрудников мошеннику. В прошлом году одна из крупнейших компаний Европы Leoni AG потеряла 45 миллионов долларов, когда сотрудник ошибочно перечислил деньги на учетную запись мошенника по причине фальшивой электронной почты. По оценкам ФБР, фишинговые атаки типа «компрометация деловой переписки» (BEC — Business Email Compromise), обходятся компаниям США в 3 миллиарда долларов в год.

На databreaches.net был составлен список фактов фишинга формы W-2. Работа над списком в этом году указывает на то, что количество случаев с 2016 года растет и на данный момент он состоит из 204 отчетов. По списку можно понять, что известны случаи кражи данных тысяч сотрудников и такой вид мошенничества является очень распространенным.

Как злоумышленник может подделать незащищенную электронную почту от почти любого человека менее чем за 5 минут

На самом деле, поддельный адрес в поле «от» — это основа и начальная стадия большинства атак. Почему стоит беспокоиться о фальсификации электронной почты с условного «company.com», когда возможно просто зарегистрировать похожий поддельный домен (например, c0mpany.com) и использовать его? Или создать учетную запись Gmail (randomaddress1347356@gmail.com), присвоить ей дружеское имя, которое выглядит как имя генерального директора компании? Потому что, на самом деле, подделать отправку письма с адреса реального человека даже проще, чем регистрировать поддельный домен или создать учетную запись Gmail.

Три простых способа

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

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

Следующий способ — это отправка с помощью командной строки UNIX. Если у вас есть компьютер с настроенной почтовой службой, достаточно ввести эту команду:

В итоге получается сообщение, в котором в поле «От» будет содержаться «any@anydomain.com». Введя строку темы и остальную часть сообщения, после нажатия Ctrl+D сообщение отправится получателю. Работостпособность этой идеи зависит от того, как настроена ваша система. Тем не менее, она работает во многих случаях.

Используя PHP, вы можете создать электронное письмо с помощью нескольких строчек очень простого кода:

Фактически, это строки кода, используемые в качестве примера в онлайн-руководстве для функции отправки почты mail() с дополнительными шапками/header.

Эти инструменты спуфинга сильно упрощены. Чтобы сделать сообщения более реалистичными, потребуется немного больше работы и, конечно, навыки социальной инженерии. Но основная техническая составляющая очень проста. Единственное, что действительно предотвращает спуфинг — аутентификация электронной почты с помощью совместного использования SPF-записи, DKIM-подписи и DMARC. Далее мы расскажем, как работают и чем отличаются эти технологии. Они не являются чем-то новым, однако, к счастью для мошенников, большинство доменов в Интернете еще не защищены. Например, только около 4% доменов .gov используют аутентификацию. Что касательно других 96%? Злоумышленники могут отправлять электронные письма под видом исходящих с почтовых ящиков этих доменов в любой момент.

Согласно источнику, одно из четырех писем с доменов .gov является мошенническим. Домены justice.gov, House.gov, Senate.gov, Whitehouse.gov, а также democrats.org, dnc.org, gop.com, rnc.org. и DonaldJTrump.com — все они могут быть легко использованы для спуфинга почтовыми мошенниками.

Способы защиты от спуфинга

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

Важность этого резко возросла благодаря быстрому росту облачных сервисов (SaaS), более 10 000 из которых отправляют электронную почту от имени своих клиентов по теме продаж, маркетинга, поддержки клиентов, HR, бухгалтерского учета, юридических и прочих услуг. Благодаря принудительной аутентификации, вы можете заблокировать всех, кто пытается отправить письмо от вашего имени, — спамеров, фишеров и даже «серых» отправителей, которые могут быть легитимными, но не указаны вами в списке разрешенных.

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

  • Используя SPF-запись, имеет ли отправляющий сервер право использовать доменное имя (или имена), указанное в заголовках сообщения?
  • Если к сообщению прикреплена криптографическая DKIM-подпись, с помощью открытой версии ключа в записи DNS домена можно расшифровать заголовки входящих сообщений и узнать, действительно ли сообщение исходит от заявленного отправителя.
  • Благодаря настройке DMARC владельцы доменов могут создавать правила обработки писем, которые поступили с доменов, не прошедших авторизацию и проверять совпадают ли заголовки друг с другом (например, поля From: и Reply-to:). Правила включают инструкции о том, что должен сделать принимающий сервер с сообщениями, не прошедшими проверку подлинности, например, не пропускать их, помещать в папку со спамом или помечать их как потенциально опасные. Проверка подлинности по электронной почте дает владельцу домена глобальный контроль над тем, что происходит с сообщениями, отправленными от их имени кем угодно и кому угодно. Например, если вы представляете домен-отправитель почты и публикуете DMARC-запись с запросом информации, то вы будете получать от всех доменов-получателей, которые тоже поддерживают DMARC, статистику обо всех почтовых письмах, которые приходят с обратным адресом от вашего домена. Статистика приходит в XML и содержит IP-адрес каждого отправителя, который подписывается вашим доменом, количество сообщений с каждого IP-адреса, результат обработки этих сообщений в соответствии с правилами DMARC, результаты SPF и результаты DKIM

Почему необходимо совместное использование этих технологий?

В упрощенном смысле SPF позволяет создавать белый список для IP-адресов. Если почтовый сервер с IP-адресом, который отсутствует в вашем списке, пытается отправить электронное письмо с использованием вашего домена, тест проверки подлинности SPF не будет пройден. Однако, большая проблема с SPF заключается в том, что используется домен, указанный в поле Return-Path для проверки подлинности, а не поле From, который люди действительно читают.

Хуже того, злоумышленники, занимающиеся фишингом, могут настроить SPF-запись для своих собственных доменов. Затем они могут отправлять электронные письма, которые, как будет казаться, поступают от компании или бренда, которым доверяют, но домен этой компании будет отображаться в поле «От», а домен мошенника в Return-Path. Такие письма пройдут проверку подлинности SPF. Дополнительное использование DMARC, решает эту проблему, позволяя владельцу домена требовать «выравнивания», что означает, что обратные и исходящие адреса должны быть одинаковыми.

SPF-записи представляют собой текст, но синтаксис довольно сложный. Легко можно сделать опечатки, которые трудно обнаружить. При этом, они сделают SPF-запись бесполезной. Анализ SPF-записей всех 62 спонсоров конференции RSA 2017 года показал, что только 58 опубликовали SPF, при этом у 17 спонсоров конференции по кибербезопасности были ошибки в записи. Компании, которые не имеют большого опыта в IT-области, часто находят SPF еще более сложным.

Также и DKIM не особенно эффективен против мошенничества без использования DMARC. Чтобы остановить фишинг, самым важным адресом является домен в поле «От». Однако, проверка только DKIM-подписи нечего не говорит по поводу домена в этом поле. Используемый для подписи сообщения домен может полностью отличаться от домена, указанного в поле «От». Другими словами, хакеры могут создавать сообщения, которые подписываются через DKIM, используя контролируемый ими домен, но в поле «От» будет находится email вашего банка. Большинство людей не собираются копаться в заголовках всех входящих сообщений, чтобы убедиться, что данные DKIM-подписи являются легитимными. Также стоит учитывать большое количество законных почтовых служб, которые могут делать рассылки от имени отправителя и проблему сохранения секретности закрытого ключа, используемого для подписи сообщений.

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

Основными вкладами DMARC являются:

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

Проверить, что DMARC настроен можно с помощью сервисов
→ mxtoolbox.com
→ mail-tester.com и прочих.

Хакерские секреты простых вещей

В первой задаче мы с тобой продолжим познавать различные атаки на электронную почту и обратим внимание на такой вектор, как подмена адреса отправителя в email’ах. Задача старая (еще бы, ведь электронная почта постарше www будет), но своей актуальности совсем не потеряла. Хотя когда-то и ходили разговорчики о том, что в скором времени мы откажемся от почты (да у нас в редакции каждый день ходят — по пять раз на дню отказываемся от этого архаизма :). — Прим. ред.), но, по мне, сейчас email — это один из основных методов «идентификации» пользователей. Хочешь где-то зарегиться — указывай email свой. О применении же подмены адреса я приведу ниже пару жизненных примеров.

WARNING

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

На самом деле решение этой задачи достаточно простое. Все, что нам понадобится, — это понимание протокола SMTP (TCP, 25-й порт), о котором мы начали говорить в прошлых номерах.

Напомню, что это протокол, который используется для пересылки email’ов. Когда ты отправляешь письмо, твой email-клиент подключается по SMTP к твоему почтовому серверу (MTA), а тот, в свою очередь, подключается к MTA-серверу получателя (из MX DNS записи имени домена).

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

Итак, сначала мы получаем MX DNS запись сервера нашего получателя. Берем то, что идет после @, и пишем в консоли «nslookup -type=mx target.com».

Пример спуфинга отправителя для Yandex

Другие статьи в выпуске:

Хакер #182. Все о Bitcoin

  • Содержание выпуска
  • Подписка на «Хакер» -60%

Потом подключаемся к 25-му порту полученного сервера. Для этого можно использовать ncat. После приветствия от сервера мы пишем:

  1. HELO any_text Это наше приветствие. Текст чаще всего может быть любой (помни, что он сохранится в заголовках).
  2. MAIL FROM: any_name@any_host.com Здесь мы должны указать, от кого письмо. Указывать можно, по сути, любые значения. Но в зависимости от настроек сервера получателя мы можем столкнуться с некоторыми ограничениями. Так, некоторые серверы резолвят имя домена и если оно не существует, то не принимают его (то есть gmail.com подставишь, а asdijasdop.com — нет). Некоторые не разрешают, чтобы имя было эквивалентно имени домена получателя (например, target.com)
  3. RCPT TO: victim@target.com Далее указываем поле, кому адресовано наше письмо.
  4. DATA Указав сверху основные поля, далее мы переходим к телу сообщения, что и озаглавливает команда DATA. Но надо сказать, что она специфическая. Во-первых, здесь можно использовать переносы строк. Фактически, для того чтобы закончить команду DATA, а с ней и все письмо, необходимо чаще всего написать точку (.) и перенос строки (\r\n). Как только ты закрываешь эту команду, сервер прилепляет письму специальный идентификатор, и его можно считать отправленным. Во-вторых, несмотря на то что DATA как бы определяет тело сообщения, в итоге все данные именно из него попадают в поля «От кого», «Кому» и прочие в почтовом клиенте получателя письма (неважно, веб или десктопное приложение). Поэтому далее мы указываем данные, которые фактически будут отображаться в почтовом клиенте.
  5. To: victim@target.com Поле «Кому» в почтовом клиенте. В зависимости от настроек сервера может быть и любым. Но для спуфинга, конечно, лучше написать email получателя (то же, что и в RCPT TO).
  6. From: any_name@any_host.com Поле «От кого». Это главное поле, на которое мы хотим повлиять. По идее, значение может быть совсем любым. Также оно может не совпадать со значением в MAIL FROM, что отвязывает нас от привязки к существующим доменам для примера выше.
  7. Subject: blah-blah Поле «Тема». Текст может быть любым.
  8. Далее через строку (два переноса строки) мы пишем текст нашего сообщения, а в конце ставим точку и перенос для окончания команды DATA

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

Конечно, есть целый ряд технологий и методов (типа DMARC) для борьбы со спуфингом, но пока что это плохо работает (имхо). По этому поводу приведу ряд примеров. Я протестировал mail.ru, Yandex и Google на спуфинг по описанному выше методу. Только гугл помещал мои письма в папочку «Спам». С остальными можно было делать все что угодно. Кроме того, мы в Digital Security проводили ряд работ по социальной инженерии и спокойно спуфили адреса: письма всегда доходили и проблем не было. Причем письма можно отправлять и от внутренних адресов. Представь: приходит какому-нибудь бухгалтеру письмо от имени его директора с PDF’очкой — ведь, конечно, он и откроет, и запустит его. Да что там PDF — от «волнения» и экзешник запустит :).

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

Кстати, если совсем уж лень писать скрипт для отправки сообщений, то можно воспользоваться каким-нибудь из множества сервисов в интернете. Например, здесь.

Проспуфленное письмо

Подделать отправителя в Facebook

Решение

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

Во-первых, у каждого пользователя ФБ есть почтовый адрес в формате username@facebook.com. Причем username общеизвестен. Он есть в адресе страницы пользователя ( facebook.com/username ). И конечно, на этот email можно слать ему сообщения. Они появятся у него во входящих.

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

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

Все очень просто, как видишь. Фейсбук исправлять это не собирается (да и не особо может). За подробностями отправляю тебя к статье моего друга Сергея Белова.

Подмена отправителя в Facebook

Определить антивирус через IE

Решение

В одном из последних выпусков «Хакера» я описывал в Easy Hack’е способ, как можно в Internet Explorer’е узнать о существовании какого-то файла в файловой системе с помощью JavaScript’а и встроенного XML-парсера, который поддерживает внешние entity (XXE). Вот, наткнулся на интересный скрипт, с помощью которого можно задетектить антивирус, установленный на компьютер-жертву. Скрипт работает для IE 10-й версии (и выше) и проверяет существование того или иного файла в системе. Но старый метод лучше, так как работает во всех версиях. Так что из этого скрипта можно вытянуть лишь пути по умолчанию для большинства актуальных версий Касперского.

Атаковать принтеры

Решение

Мы с тобой в Easy Hack’e обсуждали уже много различных методов атак на различные системы. Многие из них касались именно корпоративных сетей. Теперь дошел черед и до сетевых принтеров. Если компания становится хоть сколько-то крупной, без сетевых принтеров уже не обойтись. Но казалось бы, что можно сделать с этими глупыми железячками? На деле — достаточно многое.

Итак, для начала давай вспомним и изучим кое-какие особенности этих устройств. Во-первых, они не так глупы. Как и большинство современных девайсов, это устройство представляет собой миникомпьютер. То есть внутри может крутиться даже какая-то знакомая тебе ОС типа линукса, с полной поддержкой TCP/IP-стека. Далее, чаще всего данные девайсы имеют целый арсенал для удаленного их управления: SNMP, Telnet, SSH, веб-сервер для настройки через браузер. И конечно, по умолчанию они либо без пароля, либо с паролем стандартным. В-третьих, большинство из них можно еще и перепрошивать. Вроде ничего не забыл. Перейдем к тому, зачем же и как мы их можем атаковать.

Начнем с малого. С учетом первого пункта — поддержки TCP/IP-стека — мы можем использовать их для сканирования сети в Zombie mode Nmap’а. Напомню тебе, что эта техника представляет собой. У нас есть три хоста: атакующий, сканируемый хост (жертва), принтер. Атакующий отправляет от имени принтера запросы на подключение к портам жертвы. Жертва отвечает принтеру на запрос с теми или иными флагами в зависимости от открытости порта. В зависимости от выставленных флагов внутренние счетчики пакетов принтера меняются. Атакующий, подключаясь к принтеру, может узнать, изменились ли данные счетчики и насколько, и на основе этого сделать вывод: открыт порт или нет. Таким образом, атакующий может незаметно просканировать жертву, а все возможные подозрения будут падать на принтер. Задача еще больше затрудняется для жертвы, так как сканирование можно проводить со множества таких зомби-хостов (принтеров).

Далее. Теперь важно вспомнить, что представляет собой собственно печать на сетевом принтере. В самом обычном виде есть открытый порт у принтера: 9100 TCP. Все, что приходит на него, автоматически печатается на принтере. Таким образом, просто подключившись Ncat’ом к этому порту, мы можем напечатать любой текст. Но это так, для фана. Хотя на деле, когда печать идет с обычного компа, на этот порт посылаются данные в формате PJL или PostScript какой-нибудь, которые позволяют сделать правильную разметку страницы и вставить картинку. То есть тот же плейн-текст, но за счет команд PJL мы можем управлять поведением принтера при печати. Но для наших целей формат фактически не так важен, главное, что все идет плейн-текстом. Таким образом, все, что нам необходимо, — это произвести man-in-the-middle атаку, и мы сможем видеть все, что печатается на принтере. Казалось бы, что здесь такого? Но точно тебе скажу, что многие компании очень боятся утечек информации, а на принтерах печатается много всего конфиденциального. Так что принтер — прекрасное место для шпионажа.

Конечно, для проведения самой атаки мы можем, например, воспользоваться ARP-спуфингом, но есть метод лучше и проще. Так как чаще всего принтеры никто не настраивает и пароль по умолчанию к управляющим интерфейсам подходит, то мы можем подключиться к принтеру, сменить его IP на любой другой (все принтеры позволяют это сделать), а себе установить IP принтера. А с учетом того, что другие компы печатают данные просто подключаясь по определенному IP на 9100-й порт, подмены никто не заметит. Все, что нам надо, — принять эти данные и переслать их на итоговый принтер. И теперь можно сидеть и собирать материалы компании :). Просто, но мощно.

Крис Джон Райли (Chris John Riley) опубликовал небольшой Python-скрипт, который открывает 9100-й порт, сохраняет все задачи по печати (то есть документы) и перенаправляет их на любой другой принтер.

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

Если тебя заинтересовала данная тема, то вот пара ссылочек: goo.gl/1wIqfB, goo.gl/8NH4vi.

Атаковать с использованием WebDAV

Решение

Веб — это большая-большая смесь различных технологий на самом деле. Их много-много, и неполоманного тоже много. А есть старое и почти забытое, но которое в определенных ситуациях дает отличный профит. Итак, WebDAV (Web Distributed Authoring and Versioning) — это относительно старая технология, позволяющая, если по-простому, работать с файлами на веб-сервере. Мы можем закачивать файлы, искать, перемещать их, используя возможность только веб-сервера. Получается некий аналог файловой системы. Хотя, с другой стороны, WebDAV — это не совсем доступ именно к файлам, так как это могут быть и «виртуальные» файлы и директории. Но для наших целей (атака) это не настолько важно.

Скорее здесь интересней то, что WebDAV — расширение протокола HTTP. То есть в том же виде HTTP-запросов, который мы знаем, передаются WebDAV-команды и их «параметры». Метод HTTP-запроса (GET) является командой, например PROPFIND, а параметры передаются в теле запроса чаще всего в XML-формате. По картинке будет понятно.

Пример работы команд WebDAV

Думаю, необходимо отметить, что браузеры сами по себе не умеют работать с WebDAV’ом. В смысле там нет функционала для просмотра коллекций (файлов) или для их загрузки на сервер. Так что нужно пользоваться сторонним ПО. В винде есть поддержка проводником. Для этого надо зайти в меню «Сервис -> Подключить сетевой диск» и указать полный путь для веб-сервера (вроде http://host.com/webdav_here/ ).

О’кей. Идейно разобрались. Что же до атаки? Ну, WebDAV нам сулит две вещи. Во-первых, это дисклоз информации. Так как мы можем производить поиск по файловой системе (не по всей, разумеется), то есть шанс найти что-то, что не должно быть нам доступно. Во-вторых, это возможность заливки файлов. И здесь все может быть очень аппетитно. Как минимум мы можем залить HTML’ку и поиметь хранимую XSS, как максимум (?) — мы можем залить туда шелл и получить полный доступ.

Как же нам это провернуть? Для этого надо понять ряд вещей: поддерживает ли сервер WebDAV и какой доступ у нас есть. Для того чтобы понять, есть ли поддержка, мы можем посмотреть заголовки веб-сервера. Тот же апач сообщает об этом. Кроме того, некоторые веб-серверы поддерживают его по умолчанию (IIS 5.x).

Но поддержка еще ничего нам не дает, потому что мы должны найти директорию веб-сервера, которая с WebDAV’ом. Для того чтобы ее искать, нам потребуется использовать HTTP-метод OPTIONS. Если мы запросим данным методом директорию с WebDAV’ом, то нам выползет список WebDAV-методов, доступных для нее. То есть отсутствие WebDAV-методов в ответе на OPTIONS-запрос к корню веб-сервера еще совсем не означает отсутствие поддержки WebDAV во всех директориях.

Детектим поддержку WebDAV

Далее, если мы ее обнаружили, то мы можем использовать команду PROPFIND или SEARCH для поиска имеющихся файлов на сервере. Но тут нас может ждать первая преграда — аутентификация. К сожалению, очень на многих веб-серверах при настройке WebDAV это одно из необходимых условий. Брутфорс и пароли по умолчанию, конечно, в помощь. Когда мы найдем необходимый файл, то спокойно можем его качать (используется обычный GET).

А как же с загрузкой файлов? Здесь тоже все отчасти просто. Используется метод PUT для закачки файлов. Но есть два существенных ограничения. Во-первых, чаще всего мы не можем писать в любую директорию. На это у директории должны быть соответствующие права. Но главное, насколько я знаю, невозможно понять, для какой директории есть права на запись, а для какой — нет. То есть тот же OPTIONS будет един для всех. С другой стороны, мы просто можем потыкаться везде PUT’ом. Во-вторых, часто имеется список расширений, которые можно загружать. Да-да, не только мы умные :).

Так вот, чтобы четко протестить веб-сервер на предмет WebDAV, необходимо просканить все директории с помощью OPTIONS-метода (тлз отдельных не видел, а модуль в метасплоите проверяет лишь корень веб-сервера, так что рукописный скрипт или Burp тебе в помощь). А после этого каждую из найденных — на возможность загрузки в нее различных страшных файлов. Вот под это есть одна тулзенка — DAVTest. Она вполне удобна для тестирования. Создает рандомные имена файлам и папкам, загружает с различными расширениями, подчищает за собой. Кроме того, может проверить олдскульный трик: закачать файл с одним расширением, а потом его переименовать. Аналогичные модули есть и в Metasploit’е.

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

И успешных познаний нового!

Как изменить адрес отправителя в моих сообщениях?

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

При создании нового сообщения

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

Кликните адрес отправителя, который хотите использовать. Если его нет в списке, вам нужно будет его добавить. Узнайте больше о том, как добавить новый адрес отправителя.

Старый редактор
При создании нового письма вы можете выбрать адрес отправителя на странице Настройка рассылки.

Кликните выпадающее меню От.
Вы можете выбрать адрес из списка.

меню адреса отправителя в настройках рассылки.

  • Если адрес отправителя, который вы хотите использовать, есть в списке, кликните его.
  • Если его нет в списке, кликните Добавить новый адрес «От». Узнайте больше о том, как добавить новый адрес отправителя.

При редактировании черновика

Если вы ещё не отправили своё сообщение, и оно сохранено как черновик:

расположение кнопки редактирования черновика.

  1. Перейдите в Email-маркетинг >>Черновики .
  2. Найдите сообщение, затем кликните иконку действий (три вертикальные точки) и выберите Изменить.
  3. На странице настроек рассылки кликните меню Адрес отправителя. Выберите необходимый адрес, и следуйте инструкциям выше (см. Создание новой рассылки).

Примечание Вы можете редактировать адрес отправителя в автоответчиках и письмах автоматизации таким же образом.

Я добавил новый адрес отправителя, но не получил письма для его подтверждения

В таких случаях мы рекомендуем:

  • повторите отправку письма подтверждения
  • еще раз проверьте входящие, включая все дополнительные папки и папку «Спам»
  • добавьте IP адреса GetResponse в белый список:

Я кликнул ссылку подтверждения, но адрес отправителя не был подтвержден

В таких случаях мы рекомендуем:

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

Всё равно не работает?

Наша служба поддержки будет рада помочь. Чтобы ускорить процесс, подготовьте следующую информацию:

  • Email адрес, который вы хотите подтвердить
  • название сообщения, над которым вы работаете

Спуфинг почтового адреса: как злоумышленники выдают себя за других

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

Протокол SMTP (Simple Mail Transfer Protocol — основной протокол передачи электронной почты в сетях TCP/IP) не предусматривает никакой защиты от спуфинга, поэтому подделать адрес отправителя довольно легко. Фактически все, что нужно злоумышленнику — инструмент, позволяющий выбрать, от чьего имени придет письмо. А им может стать и почтовый клиент, и специальная утилита или скрипт, которых в Сети немало.

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

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

Спуфинг легитимного домена (Legitimate Domain Spoofing)

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

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

  • Стандарт SPF (Sender Policy Framework) позволяет владельцу почтового домена ограничить набор IP-адресов, которые могут отправлять письма с этого домена, а почтовому серверу — проверять, что IP-адрес отправителя авторизован владельцем домена. Правда, проверяет SPF не заголовок From, а домен отправителя, указанный в SMTP-конверте, который используется для передачи информации о маршруте письма между почтовым клиентом и сервером и не показывается получателю.
  • DKIM решает проблему проверки подлинности отправителя с помощью цифровой подписи, которая генерируется на основе закрытого ключа, хранящегося на сервере отправителя. Открытый ключ для проверки подписи помещается на DNS-сервер, отвечающий за домен отправителя. Если в действительности письмо отправлено с другого домена, подпись окажется невалидной. Однако у этой технологии тоже есть слабое место: злоумышленник может отправить поддельное письмо без DKIM-подписи, и его будет невозможно проверить.
  • DMARC (Domain-basedMessageAuthentication, ReportingandConformance) позволяет проверить домен в заголовке From на соответствие домену, подтвержденному с помощью DKIM и/или SPF. Таким образом, при использовании DMARC письмо со спуфингом легитимного домена не пройдет проверку. Однако при выборе строгой политики DMARC может блокировать и полезные письма — в одной из наших статей мы рассказывали, как наши решения улучшают эту технологию и сводят к минимуму ложноположительные срабатывания.

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

Спуфинг отображаемого имени (Display Name Spoofing)

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

Пример отображаемого имени

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

Ghost Spoofing

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

Пример Ghost Spoofing

При этом на самом деле письмо приходит с совсем другого адреса.

Реальный адрес отправителя в Ghost Spoofing и почтовая аутентификация

AD Spoofing

AD (Active Directory) Spoofing тоже является одной из разновидностей спуфинга отображаемого имени, но в отличие от техники Ghost Spoofing не предполагает указания поддельного адреса в качестве части имени. При этом в адресе злоумышленников, с которого рассылаются такие письма, используется имя человека, от лица которого они рассылаются.

Пример AD Spoofing

Этот метод выглядит более примитивным по сравнению с Ghost Spoofing, однако мошенники могут предпочитать его по нескольким причинам. Во-первых, если почтовый агент получателя все-таки отображает содержимое заголовка From целиком, то двойной адрес отправителя вызовет у пользователя больше подозрений, чем адрес на общедоступном домене. Во-вторых, технически Ghost Spoofing легче блокировать спам-фильтрами: достаточно просто отправлять в спам письма, где в отображаемом имени отправителя содержится почтовый адрес. Запретить же все входящие письма от тезок всех коллег и контрагентов, как правило, не представляется возможным.

Спуфинг схожего домена (Lookalike domain Spoofing)

В более сложных атаках злоумышленники используют специально зарегистрированные домены, похожие на домен организации-мишени. Это требует немного больших затрат: все же найти и купить определенный домен, настроить на нем почту, подписи DKIM и SPF и аутентификацию DMARC сложнее, чем просто немного изменить заголовок From. Но и распознать подделку в таком случае труднее.

Primary Lookalike

Lookalike-домены — это домены, схожие по написанию с доменами подделываемой организации, но отличающиеся от них одной или несколькими буквами. Подробнее мы рассказывали о них в статье «Lookalike-домены и защита от них»). Например, письмо на скриншоте ниже пришло с домена deutschepots.de, который очень легко перепутать с доменом немецкой почтовой компании Deutsche Post (deutschepost.de). Если перейти по ссылке в таком письме и попытаться оплатить доставку посылки, можно не только потерять 3 евро, но и оставить мошенникам данные своей карты.

Пример письма с lookalike-домена

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

Unicode Spoofing

Unicode Spoofing — разновидность спуфинга, в которой один из ASCII-символов в имени домена заменяется на схожий по написанию символ из диапазона Unicode. Чтобы понять эту технику, нужно разобраться, как кодируются домены, в которых используются нелатинские символы (например, кириллица или умлауты). Для работы с ними был создан метод преобразования Punycode, в соответствии с которым символам Unicode сопоставляются так называемые ACE-последовательности (ASCII Compatible Encoding — кодировка, совместимая с ASCII), состоящие из букв латинского алфавита, дефисов и чисел от 0 до 9. При этом многие браузеры и почтовые клиенты отображают Unicode-версию домена. Так, например, домен:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *