Что такое Яндекс ПДД и для чего это нужно?
Яндекс PDD (почта для домена) - популярное решение среди небольших организаций для корпоративной почты. Если вам необходимо менее 1000 учетных записей, то абсолютно бесплатно вы получаете простой интерфейс администрирования, удобное API, понятный и красивый веб-клиент для пользователей. Вам не придется самостоятельно настраивать и размещать SMTP и POP/IMAP сервера (вам даже не нужно знать что это такое). Яндекс.Почта имеет статус безопасного и современного сервиса.
В процессе аудита мы часто сталкиваемся с организациями, доверивших почтовую переписку данному сервису. Настроив корпоративную почту на Яндексе можно уже не беспокоиться о безопасности переписки. Или нельзя? Я провел небольшое исследование на эту тему. В первую очередь, мое внимание привлек функционал сброса паролей.
Особенности восстановления доступа к сервису Яндекс.Почта
При регистрации личного почтового ящика в яндексе существует возможность не указывать номер телефона, а выбрать контрольный вопрос на случай необходимости восстановления пароля. Тему безопасности двухфакторной авторизации через SMS рассматривать сейчас не будем (атаки на SS7, SIM swap и т.д. - это темы для многих исследований), просто примем, что это надежнее метода секретных вопросов.
Использование секретных вопросов снижает защищенность аккаунта, так как ответы на них часто можно найти методами анализа социальных сетей, а порой они очевидны. В Яндекс отлично это понимают) Каждый раз при авторизации сервис настойчиво предлагает привязать номер телефона. Через короткий промежуток вы не сможете войти в свой аккаунт, не активировав двухфакторную авторизацию, поэтому личных почтовых аккаунтов с восстановлением пароля через секретный вопрос практически не существует.

Вроде все хорошо, а что не так с Яндекс ПДД?
Отличие аккаунта зарегистрированного через Яндекс PDD от личной Яндекс.Почты в том что, сервис лояльнее относится к секретным вопросам. Да, периодически вам будут предлагать привязать номер телефона к учетной записи, но вход до момента активации двухфакторной авторизации не заблокируют. Говоря о Yandex PDD мы обычно имеем дело с корпоративными аккаунтами. Паттерны поведения при работе с рабочими/личными аккаунтами имеют отличия: часто пользователи опасаются компрометации личных учетных записей гораздо больше. Это психологический аспект: безопасность моей почты - моя проблема, а рабочей - зона ответственности администратора. Многие четко разделяют рабочие и личные контакты и не хотят использовать личный номер телефона для привязки к корпоративной почте, а служебный мобильный телефон есть не у каждого. Вместо телефона можно привязать дополнительный адрес почты. Но так делают не все. Практика показывает, что корпоративные учетные записи защищенные секретным вопросом - не редкость. Не редкость и совсем простые вопросы.
Яндекс предоставляет 10 попыток для ответа на секретный вопрос, а потом блокирует на 1 час:
Я выяснил, что блокируется IP-адрес с которого производились попытки сброса пароля, поэтому заменив выходную ноду TOR или VPN сервер мы можем продолжить подбор ответа. Даже куки чистить нет необходимости. Выход с других устройств и браузеров после удачного сброса пароля опционален (и отключен по умолчанию). Это значит, что после сброса необходимо как можно быстрее удалить сообщение о смене авторизационных данных. Если пользователь не успеет прочитать его - факт компрометации почтового ящика останется незамеченным длительное время. В реальных условиях - около двух недель я сидел на ящиках одновременно с их владельцами, пока они не заметили, что их пароль не подходит.
Применение в реальной жизни
Как определить, что домен использует Яндекс ПДД? Самый простой способ - воспользоваться службой DNS. Каждый домен имеет MX-запись, она необходима для маршрутизации почтовых сообщений, передаваемых по протоколу SMTP. Определяем SMTP-сервер, использующийся для приема почты:
Если в ответе видим mx.yandex.ru - значит в организации используют PDD. Другого способа пользоваться SMTP Яндекс я не знаю. Во время проведения последнего аудита из открытых источников я выявил 78 почтовых учетных записей работников организации. 18 из них были защищены секретным вопросом. Мне удалось доступ к 5 почтовым ящикам. 1 из учетных записей принадлежала администратору, ответственному за приобретение и оплату VPS. В письмах содержались параметры авторизации к различным серверам компании. Админы были очень удивлены, когда узнали что их взломали через Яндекс, такой вектор атаки они не ожидали.
Если вам не повезло взять жирную почту с паролями, имея аккаунт сотрудника вы все равно получаете дополнительные возможности для развития атаки. Кроме собственно почты взломанной учетки у вас будет доступ контакт листу (все учетки организации) и Яндекс.Диск (там тоже попадаются интересные файлы).Тут уж на что фантазии хватит: появляется возможность рассылки малвари от доверенного отправителя, можно попытать убедить админов организовать вам удаленный доступ к сети компании и т.д.
Реальные секретные вопросы, попадавшиеся при пентестах:
1. "Мой почтовый индекс";
2. "Моя первая машина";
3. "Название компании";
4. "Девичья фамилия матери" - да, и такая банальщина тоже встречалась).
Получить доступ к таким учетным записям не составляет труда. Даже если ответ обладает некоторой энтропией (т.е. необходим разумный брутфорс), процесс вполне возможно автоматизировать меняя IP-адрес каждые 10 попыток и используя сервис решения капч.
Что еще кроме сброса паролей?
Во время другого аудита в настройках взломанного веб-приложения присутствовал токен администратора почтового домена (в административном разделе был функционал взаимодействия в Яндекс PDD). Данный токен позволяет производить любые действия с почтовыми ящиками посредством предоставляемого API. Можно получить список учетных записей, сбросить пароль на любой из них, удалить, создать. API очень простой и имеет хорошую документацию. Таким образом после взлома сайта получен приятный бонус в виде доступа ко всей корпоративной переписке.
Токен администратора - очень чувствительная информация, которую можно попытаться поискать в репозиториях, на pastebin и т.д.
Выводы
Секретные вопросы для восстановления доступа это плохо, этот факт известен давно, но порой данный метод встречается даже в таких серьезных сервисах как Яндекс ПДД. Вообще, эту особенность нельзя назвать уязвимостью, но она серьезно снижает безопасность. При аудите любого веб-приложения протокол восстановления доступа является тем, на что стоит обратить пристальное внимание. Так же интересным показался факт, что недостаток устраненный в сервисе для широкого круга пользователей остался в мелко-корпоративном сегменте.
Джереми Гроссман на конференции BLACK HAT USA 2019 рассказывал о том, что классические критические уязвимости веб-приложений сейчас встречаются все реже, а эксплуатировать их становится намного сложнее. LFI или SQL-inj на серьезных сервисах являются редкостью. В тренде становятся атаки на бизнес-процессы и логику приложений. Такие ошибки практически нереально найти автоматическими средствами, от них не защититься с помощью WAF. Рассмотренный в статье метод является прекрасной иллюстрацией сказанного.
Ссылки
1. Про фичи PDD - https://connect.yandex.ru/pdd/
2. Документация к API - https://yandex.ru/dev/pdd/doc/about-docpage/
3. Как происходит маршрутизация почтовых сообщений - https://ru.wikipedia.org/wiki/SMTP
4. Перевод доклада об актуальных методах атак c конференции BLACK HAT USA 2019 - https://habr.com/ru/company/ua-hosting/blog/476088/
5. Модуль для работы с API Яндекс PDD на Python - https://github.com/zt50tz/yandex-pdd
Яндекс PDD (почта для домена) - популярное решение среди небольших организаций для корпоративной почты. Если вам необходимо менее 1000 учетных записей, то абсолютно бесплатно вы получаете простой интерфейс администрирования, удобное API, понятный и красивый веб-клиент для пользователей. Вам не придется самостоятельно настраивать и размещать SMTP и POP/IMAP сервера (вам даже не нужно знать что это такое). Яндекс.Почта имеет статус безопасного и современного сервиса.
В процессе аудита мы часто сталкиваемся с организациями, доверивших почтовую переписку данному сервису. Настроив корпоративную почту на Яндексе можно уже не беспокоиться о безопасности переписки. Или нельзя? Я провел небольшое исследование на эту тему. В первую очередь, мое внимание привлек функционал сброса паролей.
Особенности восстановления доступа к сервису Яндекс.Почта
При регистрации личного почтового ящика в яндексе существует возможность не указывать номер телефона, а выбрать контрольный вопрос на случай необходимости восстановления пароля. Тему безопасности двухфакторной авторизации через SMS рассматривать сейчас не будем (атаки на SS7, SIM swap и т.д. - это темы для многих исследований), просто примем, что это надежнее метода секретных вопросов.
Использование секретных вопросов снижает защищенность аккаунта, так как ответы на них часто можно найти методами анализа социальных сетей, а порой они очевидны. В Яндекс отлично это понимают) Каждый раз при авторизации сервис настойчиво предлагает привязать номер телефона. Через короткий промежуток вы не сможете войти в свой аккаунт, не активировав двухфакторную авторизацию, поэтому личных почтовых аккаунтов с восстановлением пароля через секретный вопрос практически не существует.

Вроде все хорошо, а что не так с Яндекс ПДД?
Отличие аккаунта зарегистрированного через Яндекс PDD от личной Яндекс.Почты в том что, сервис лояльнее относится к секретным вопросам. Да, периодически вам будут предлагать привязать номер телефона к учетной записи, но вход до момента активации двухфакторной авторизации не заблокируют. Говоря о Yandex PDD мы обычно имеем дело с корпоративными аккаунтами. Паттерны поведения при работе с рабочими/личными аккаунтами имеют отличия: часто пользователи опасаются компрометации личных учетных записей гораздо больше. Это психологический аспект: безопасность моей почты - моя проблема, а рабочей - зона ответственности администратора. Многие четко разделяют рабочие и личные контакты и не хотят использовать личный номер телефона для привязки к корпоративной почте, а служебный мобильный телефон есть не у каждого. Вместо телефона можно привязать дополнительный адрес почты. Но так делают не все. Практика показывает, что корпоративные учетные записи защищенные секретным вопросом - не редкость. Не редкость и совсем простые вопросы.
Яндекс предоставляет 10 попыток для ответа на секретный вопрос, а потом блокирует на 1 час:
Я выяснил, что блокируется IP-адрес с которого производились попытки сброса пароля, поэтому заменив выходную ноду TOR или VPN сервер мы можем продолжить подбор ответа. Даже куки чистить нет необходимости. Выход с других устройств и браузеров после удачного сброса пароля опционален (и отключен по умолчанию). Это значит, что после сброса необходимо как можно быстрее удалить сообщение о смене авторизационных данных. Если пользователь не успеет прочитать его - факт компрометации почтового ящика останется незамеченным длительное время. В реальных условиях - около двух недель я сидел на ящиках одновременно с их владельцами, пока они не заметили, что их пароль не подходит.
Применение в реальной жизни
Как определить, что домен использует Яндекс ПДД? Самый простой способ - воспользоваться службой DNS. Каждый домен имеет MX-запись, она необходима для маршрутизации почтовых сообщений, передаваемых по протоколу SMTP. Определяем SMTP-сервер, использующийся для приема почты:
Bash:
dig MX domain +short
10 mx.yandex.ru.
Если в ответе видим mx.yandex.ru - значит в организации используют PDD. Другого способа пользоваться SMTP Яндекс я не знаю. Во время проведения последнего аудита из открытых источников я выявил 78 почтовых учетных записей работников организации. 18 из них были защищены секретным вопросом. Мне удалось доступ к 5 почтовым ящикам. 1 из учетных записей принадлежала администратору, ответственному за приобретение и оплату VPS. В письмах содержались параметры авторизации к различным серверам компании. Админы были очень удивлены, когда узнали что их взломали через Яндекс, такой вектор атаки они не ожидали.
Если вам не повезло взять жирную почту с паролями, имея аккаунт сотрудника вы все равно получаете дополнительные возможности для развития атаки. Кроме собственно почты взломанной учетки у вас будет доступ контакт листу (все учетки организации) и Яндекс.Диск (там тоже попадаются интересные файлы).Тут уж на что фантазии хватит: появляется возможность рассылки малвари от доверенного отправителя, можно попытать убедить админов организовать вам удаленный доступ к сети компании и т.д.
Реальные секретные вопросы, попадавшиеся при пентестах:
1. "Мой почтовый индекс";
2. "Моя первая машина";
3. "Название компании";
4. "Девичья фамилия матери" - да, и такая банальщина тоже встречалась).
Получить доступ к таким учетным записям не составляет труда. Даже если ответ обладает некоторой энтропией (т.е. необходим разумный брутфорс), процесс вполне возможно автоматизировать меняя IP-адрес каждые 10 попыток и используя сервис решения капч.
Что еще кроме сброса паролей?
Во время другого аудита в настройках взломанного веб-приложения присутствовал токен администратора почтового домена (в административном разделе был функционал взаимодействия в Яндекс PDD). Данный токен позволяет производить любые действия с почтовыми ящиками посредством предоставляемого API. Можно получить список учетных записей, сбросить пароль на любой из них, удалить, создать. API очень простой и имеет хорошую документацию. Таким образом после взлома сайта получен приятный бонус в виде доступа ко всей корпоративной переписке.
Токен администратора - очень чувствительная информация, которую можно попытаться поискать в репозиториях, на pastebin и т.д.
Выводы
Секретные вопросы для восстановления доступа это плохо, этот факт известен давно, но порой данный метод встречается даже в таких серьезных сервисах как Яндекс ПДД. Вообще, эту особенность нельзя назвать уязвимостью, но она серьезно снижает безопасность. При аудите любого веб-приложения протокол восстановления доступа является тем, на что стоит обратить пристальное внимание. Так же интересным показался факт, что недостаток устраненный в сервисе для широкого круга пользователей остался в мелко-корпоративном сегменте.
Джереми Гроссман на конференции BLACK HAT USA 2019 рассказывал о том, что классические критические уязвимости веб-приложений сейчас встречаются все реже, а эксплуатировать их становится намного сложнее. LFI или SQL-inj на серьезных сервисах являются редкостью. В тренде становятся атаки на бизнес-процессы и логику приложений. Такие ошибки практически нереально найти автоматическими средствами, от них не защититься с помощью WAF. Рассмотренный в статье метод является прекрасной иллюстрацией сказанного.
Ссылки
1. Про фичи PDD - https://connect.yandex.ru/pdd/
2. Документация к API - https://yandex.ru/dev/pdd/doc/about-docpage/
3. Как происходит маршрутизация почтовых сообщений - https://ru.wikipedia.org/wiki/SMTP
4. Перевод доклада об актуальных методах атак c конференции BLACK HAT USA 2019 - https://habr.com/ru/company/ua-hosting/blog/476088/
5. Модуль для работы с API Яндекс PDD на Python - https://github.com/zt50tz/yandex-pdd
Вложения
Последнее редактирование: