Термин FUD (Fear, Uncert­ainty and Doubt), вызывающий опасения и сомнения в качестве продукта, хорошо известен в компьютерной индустрии, и явление, им обозначаемое, отнюдь не стало достоянием истории. Об этом свидетельствует недавний отчет о некоей уязвимости клиента OWA, подготовленный сотрудниками специализирующейся на проблемах информационной безопасности компании Cybereason. В довольно сомнительном докладе не содержится достаточно подробной информации, позволяющей судить о том, реальна ли поднятая авторами проблема. Лично я отвечаю на этот вопрос отрицательно, хотя, конечно, трудно принять определенное решение, не разобравшись в том, как именно некий взломщик чудесным образом прорвался на сервер Exchange. Ну что ж, определитесь и вы, уважаемые читатели!

Вероятно, доклад под названием A new persistent attack methodology targeting Microsoft Outlook Web Applica­tion (OWA) (http://www.cybereason.com/cybereason-labs-research-a-new-persistent-attack-methodology-targeting-microsoft-owa/) доставил немало хлопот администраторам Exchange, которые, возможно, подумали, что речь идет о фундаментальной уязвимости клиента. Комментарий по этому вопросу, подготовленный командой разработчиков Exchange, вы можете прочесть в журнале EHLO (http://blogs.technet.com/b/exchange/archive/2015/10/07/no-new-security-vulnerability-in-outlook-web-access-owa.aspx). Прежде всего, я не думаю, что исследователи понимают, как функционирует платформа Exchange. Между тем, как мне кажется, чтобы разобраться, в чем состоит возможная угроза и насколько перспективны направления атаки, открытые для злоумышленника, нужно располагать определенным опытом работы с внутренними механизмами Exchange. Приведу небольшую цитату из доклада: «Клиент OWA отличается от других веб-серверов, которые, как правило, наделены только веб-интерфейсом. В этом отношении OWA уникален; в Интернет выходит и жизненно важная внутренняя инфраструктура, в результате чего клиент становится посредником между внутренней, предположительно защищенной DMZ и Интернетом». Утверждения вроде этого вынуждают меня усомниться, разбираются ли авторы в архитектуре анализируемой ими технологии. И имеют ли они хоть какое-то представление о том, как развертываются серверы Exchange?

Похоже, что успех атаки зависит от того, удастся ли хакеру разместить на сервере Exchange скомпрометированную (вредоносную и оснащенную «черным входом») версию OWAAUTH.DLL с целью захвата учетных данных Active Directory, предоставленных пользователями, которые проводили аутентификацию при соединениях с почтовыми ящиками. Скомпрометированная OWAAUTH была загружена и использовалась системой Exchange. Похоже, эта библиотека была выбрана после перезагрузки вследствие изменений, внесенных в реестр. Как бы то ни было, раз уж DLL была загружена, злоумышленники могут получать запросы на аутентификацию, направленные службе Active Directory после дешифровки, так что все отображается открытым текстом. Сведения о паролях хранились в зашифрованном файле (C:\log.txt), а он как будто не является тем местом, где администратор будет хранить данные, которые намерен использовать. Исследователи заявляют, что им удалось извлечь из журнального файла 11000 пар паролей. Что и говорить, по меркам организации Exchange средних размеров им попался весьма загруженный сервер.

Злоумышленник в состоянии создать библиотеку DLL, содержащую код для считывания учетных данных пользователей, он может разместить ее на сервере Windows и скрыть скомпрометированный код с помощью кода сборки. NET. В этом у меня нет сомнений. Внести изменения в системный реестр — дело несложное, если только вы обладаете необходимыми разрешениями. Но здесь прежде всего возникает вопрос: как хакеру удалось получить доступ к интересующему его серверу и откуда у него расширенные права? Должным образом защищенный и обслуживаемый сервер не предоставит хакерам возможности помещать скомпрометированные файлы в системные папки. Доклад не содержит каких-либо подробностей относительно того, как хитроумные взломщики выполнили свою грязную работу.

Кроме того, взлом системы, по-видимому, возможен лишь в случае размещения целевого сервера Exchange в DMZ и наделения его прямым доступом в Интернет, поскольку «пользователь применял OWA для обеспечения доступа удаленных пользователей к Outlook». Даже если оставить в стороне вопрос о смешивании понятий (Outlook — это клиент, а Exchange — сервер), здесь мы имеем дело со странной схемой развертывания. Хотя размещение серверов Exchange в демилитаризованной зоне возможно (проблема обсуждается с 2002 года), этой возможностью пользуются лишь немногие администраторы. В последних версиях продукта специалисты Microsoft усовершенствовали средства защиты Exchange от атак, и сегодня мы можем обезопасить хорошо управляемый и грамотно обслуживаемый сервер Exchange 2013 от подобных нападений, даже если он расположен за пределами DMZ.

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

Единственная категория серверов Exchange, развертывание которых в демилитаризованной зоне поддерживается Microsoft, — это серверы, выполняющие роль пограничных серверов, Edge (http://blogs.technet.com/b/exchange/archive/2013/02/18/exchange-firewalls-and-support-oh-my.aspx). Эти серверы не подключаются к домену и не являются частью организации Exchange, которая включает в себя почтовые ящики пользователей. Они не играют никакой роли в аутентификации соединений пользователей со службой Active Directory, поэтому я не понимаю, как описываемая атака может повлиять на работу серверов Edge или скомпрометировать проверку полномочий пользователей в соответствии с описанием, приведенным в докладе.

Странная схема развертывания — это одна из причин, побуждающих меня сомневаться в ценности доклада. Вторая причина состоит в том, что в документе мы не находим некоторых важных деталей, касающихся настроек программных средств. Какая версия Exchange была установлена на скомпрометированном сервере? Какая версия Windows использовалась? Были ли установлены все выпущенные на тот момент модули коррекции, обеспечивающие повышение уровня безопасности Windows, и другие дополнения? При отсутствии этих сведений невозможно понять, идет ли в докладе речь об устаревших серверах Exchange, которые уже не эксплуатируются, или о новейших накопительных добавлениях к системе Exchange 2013.

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

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

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