Как мы проводили аудит Корпоративной Почты Mail.ru — сервиса для крупного бизнеса

Корпоративные данные часто представляют собой коммерческую тайну. Их утечка может привести к удару по репутации, финансовым потерям или даже банкротству. Поэтому требования безопасности к B2B-продукту должны быть очень высокими. Создавая новый продукт мы уделяли вопросу его безопасности особое внимание. Корпоративная Почта Mail.ru — on-premises версия знакомой всем обычной Почты Mail.ru. По сравнению с ней она содержит ряд модификаций для работы в новых условиях — контуре клиента.

Мы решили пройти аудит в сторонней компании и исправить все найденные недостатки до того, как предлагать продукт рынку. Для этого обратились к одной из самых авторитетных компаний в сфере информационной безопасности — Digital Security.

Удаленное выполнение кода в uWSGI

У нас обнаружился uWSGI-сервер, доступ к которому был у всех внутренних компонентов продукта.
В uwsgi-протоколе можно использовать магические переменные для динамического конфигурирования uWSGI-сервера. UWSGI_FILE позволяет загрузить новое динамическое приложение, если указать путь до файла. Как оказалось, uWSGI-сервер может обрабатывать в этом пути section, fd, call и exec. То есть можно выполнить произвольную bash-команду. Для анализа этой проблемы был написан эксплоит: https://github.com/wofeiwo/webcgi-exploits/blob/master/python/uwsgi_exp.py.

Пример запроса, выполняющего команду.


Эта уязвимость могла быть проэксплуатирована, только если злоумышленник:

• Уже находится во внутренней сети продукта.
• Имеет SSRF с возможностью отправки произвольных данных по TCP.
  

Реализации CGI-интерфейсов для других языков программирования или фреймворков тоже могут быть уязвимы, пример — эксплоит из того же репозитория для FastCGI: https://github.com/wofeiwo/webcgi-exploits/tree/master/php/Fastcgi. Скорее, это особенность CGI-серверов, поэтому нужно максимально ограничивать доступ к ним.

Обход CSRF-защиты

Сlient-side атаки в современном вебе постепенно начинают исчезать. Однако ошибки в настройке или некритичные уязвимости могут позволить провести CSRF-атаки. Такие ошибки были обнаружены в приложении календаря, входящего в наш продукт.

В API для обращения к объекту в URL-пути передается параметр UID, который отвечает за ID календаря или события:

example.com/api/calendar/{UID}/action?
example.com/api/event/{UID}/action?




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

Первое — импорт файлов в формате ICS. В них есть специальное поле UID, которое пользователь контролирует при импорте. После импорта событий их UID останутся такими же, как в файле. Фильтрации у этого параметра нет.

Второе — возможность перехватить запрос с редактированием календаря и изменить поле UID. Фильтрация отсутствовала и тут.

Другая важная особенность: в этом API реализована CSRF-защита. А передавать CSRF-токены в GET-параметрах — плохая практика, возможна утечка.

Соберем всё вместе. Злоумышленник может в приложении контролировать UID объектов и делиться с другими пользователями доступом к событиям и к календарям. Поэтому злоумышленник может сделать объект с UID вида:

../. ./. ./AnyPathTo?anyparam=value&

При выполнении действия над объектом сгенерируется запрос с CSRF-токеном:

example.com/api/event/. ./. ./. ./AnyPathTo?anyparam=value&/action&token=abcdef


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


example.com/AnyPathTo?anyparam=value&/action&token=abcdef


Можно заставить пользователя отправить запрос к приложению по произвольному пути с произвольными параметрами и с корректным CSRF-токеном. А когда пользователь редактирует объект, отправляется PUT-запрос с телом запроса. При редактировании календаря в теле запроса будет JSON со всеми параметрами текущего календаря. Если перенаправить запрос на редактирование со «зловредного» календаря на приватный календарь пользователя, то к нему применятся все свойства «зловредного».



Возможность MITM-атаки

У нас реализована интеграция с Active Directory для аутентификации через LDAP и сбора писем с сервера Exchange. В этом примере речь пойдет об ActiveSync. При соединении между продуктом и Active Directory передаются учетные записи и пароли пользователей.

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

Самая частая атака внутри корпоративных сетей — MITM. Обычно злоумышленник попадает в пользовательский сегмент сети, в котором нет сервера Exchange или контроллера домена. Также в нашем случае продукт не использует широковещательные протоколы разрешения имен — NBNS, LLMNR, mDNS. А для успешной MITM нужен доступ в сеть с одним из этих компонентов. Достигнуть этой цели иногда можно через уязвимые маршрутизаторы или серверы.

Выяснилось, что наша интеграция с Active Directory уязвима к MITM-атакам.

Когда пользователь вводит логин и пароль, система отправляет два LDAP-запроса на контроллер домена. Первый запрос возвращает список почтовых адресов, и если в нём есть логин пользователя, то отправляется второй запрос — Simple LDAP Authentication. Данные передаются в открытом виде. Это позволяет получать учетные записи пользователей, которые в данный момент авторизуются в продукте.




Вторая проблема: при соединении с Exchange-сервером по протоколу ActiveSync для сбора входящих писем система не проверяла подлинность TLS-сертификата сервера.



Результат

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

Мы попросили аудиторов уделить наибольшее внимание измененной авторизации (в Корпоративной Почте используется AD заказчика) и основному почтовому API. Найденные недостатки в основном были связаны с измененной топологией сети и специфичными для on-premises модификациями. Для остальных компонентов (календарь, интерфейс администрирования Mail.ru для бизнеса) использовалась модель gray-box.

Мы нашли ряд недостатков в некоторых компонентах и оперативно исправили. Заодно убедились в высоком уровне защищенности большинства других компонентов. Планируем проводить такие аудиты регулярно.