Исследователь Ахмед Мехтаб нашел (новость, исследование) нетривиальный способ частичного взлома учетных записей GMail. Используя ошибку в функции объединения разных аккаунтов и пересылки почты, он показал, как можно отправлять сообщения от имени жертвы. В нормальных условиях подключить дополнительную учетную запись к собственной можно с помощью соответствующего меню в настройках. После этого на дополнительную почту отправляется подтверждение. Необходимо кликнуть на линк в этом сообщении, и у вас появляется возможность отправлять почту с собственного ящика от имени этого дополнительного аккаунта. Соответственно, если у вас нет доступа к атакуемой почте, вы не увидите письмо с подтверждением и ссылку. Но в редких случаях это не требуется: если атакуемая учетная запись деактивирована, и почтовый сервер Google присылает нотификацию о невозможности доставки сообщения. Тогда можно стандартными средствами запросить подтверждение, оно отправится на атакуемый ящик, и вернется целиком в составе сообщения о невозможности доставки. Останется только кликнуть ссылку.
Понятно, что атака имеет крайне ограниченную сферу применения: против реальных почтовых ящиков она возможна только в случае, если каким-то образом заставить владельца деактивировать аккаунт. Второй вариант: жертва заблокировала ваш почтовый ящик, в таком случае начинают присылаться аналогичные сообщения. Как бы то ни было, можно только отправлять письма от имени жертвы, но не получать их. Исследователю удалось прикрутить к своей почте несуществующие адреса с красивыми именами типа gmail@gmail.com. Естественно, на момент публикации исследования, лазейка уже была закрыта.
Видео атаки:
Исследователь показал способ обхода двухфакторной авторизации для Outlook Web Access
Новость
UPD: См. комментарий уважаемого VitalKoshalew. Как минимум все не так однозначно, а на самом деле есть вероятность, что «уязвимость» 2FA все же вызвана нерекомендуемой конфигурацией OWA+EWS+2FA.
А вот в этой новости речь идет об уязвимости, которая то ли не закрыта, то ли не может быть квалифицирована как уязвимость, то ли, как в анекдоте «всю систему надо менять». Суть в том, что двухфакторную авторизацию в веб-интерфейсе для корпоративной почты Outlook Web Access можно достаточно легко обойти, если у компании-жертвы используется стандартная конфигурация этой службы. Стандартная конфигурация предполагает доступность извне не только OWA, но и компонента Exchange Web Services, на котором 2FA в принципе не реализована. Через EWS можно получить доступ и к почте, что делает двухфакторную авторизацию бессмысленной — она как бы есть, но толку нет.
Исследователь (отчет) отправил информацию в Microsoft, не получил ответа, обнародовал данные. После этого Microsoft предложила решение проблемы, заключающееся в отключении доступа к EWS извне. Действительно, речь идет скорее не об уязвимости, а о неверной конфигурации. С другой стороны, речь идет о дефолтной конфигурации OWA, так что определенные действия со стороны вендора все же требуются. Хотя бы в формате рекомендаций по безопасному внедрению 2FA, которая все-таки работает.
Закрыты уязвимости в OpenSSL
Новость | Advisory
Достаточно серьезную уязвимость в библиотеке OpenSSL закрыли на этой неделе. Уязвимость может быть эксплуатирована при TLS-подключении с использованием недавно стандартизированного алгоритма шифрования ChaCha20-Poly1305: при определенных условиях можно вызвать отказ в обслуживании.
Впрочем, не более того. Ошибка была внесена в код библиотеки недавно, существует только в версии 1.1.0, исправляется апдейтом 1.1.0с. Кроме того, разработчики OpenSSL напомнили о прекращении поддержки версии библиотеки 1.0.1 и более ранних — с нового года обновления и патчи для этой ветки больше выпускаться не будут.
Что еще произошло
Google придумал отдельный флажок для сайтов, на которых неоднократно размещался опасный контент.
Обнародованная на прошлой неделе ITW уязвимость в Windows закрыта.
Эксперты «Лаборатории» рассказывают о шифровальщике, использующем механизм Telegram-ботов.
Древности
«Aircop»
Очень опасный вирус. Поражает Boot-секторы дискет, сохраняя старый Boot-сектор по адресу 1/39/9 (головка/трек/сектор). Данные, расположенные по этому адресу, будут уничтожены. Пытается пережить перезагрузку. При попытке загрузки с диска, не содержащего системных файлов DOS, выводит на экран: «Non-system». Периодически сообщает: «RED STATE, Germ offensing — Aircop». Перехватывает int 12h, 13h, 1Bh.
Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 99.
Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Комментарии (5)
VitalKoshalew
15.11.2016 22:44Суть в том, что двухфакторную авторизацию в веб-интерфейсе для корпоративной почты Outlook Web Access можно достаточно легко обойти, если у компании-жертвы используется стандартная конфигурация этой службы. Стандартная конфигурация предполагает доступность извне не только OWA, но и компонента Exchange Web Services, на котором 2FA в принципе не реализована.
Можно ссылку на эту «стандартную конфигурацию»?
После этого Microsoft предложила решение проблемы, заключающееся в отключении доступа к EWS извне.
Можно ссылку, где Microsoft признаёт неправильную конфигурацию у горе-специалиста «проблемой» и предлагает решение?
Microsoft говорит, что это не стандартная, а неправильная конфигурация.
In Exchange Server, authentication configuration settings for client endpoints are not shared across protocols. Supported authentication mechanisms are configured independently on a per protocol endpoint basis. Multi-Factor Authentication in Exchange Server can be enabled in multiple ways, including OAuth. Before implementing MFA with Exchange Server it is important that all client protocol touchpoints are identified and configured correctly.
Вендор решения 2-факторной аутентификации в документации открыто говорит, что для EWS они 2-факторную аутентификацию не реализовали:
Does Duo Security's OWA application affect ActiveSync?
ActiveSync continues to work as it did prior to installing Duo. Duo's OWA application does not add two-factor authentication to the EWS and ActiveSync endpoints. We recommend against exposing the ActiveSync endpoint to external access.
В конце концов даже сами горе-тестеры поняли, что с O365 2-факторная аутентификация на EWS работает, а они просто не дождались пока в облаке настройки применятся:
UPDATE as of 11:15am EST on 11/4/16 BHIS has retested the portion of this article detailing a bypass against Office365 Multi-Factor Authentication and it does indeed appear to not work.
Итого: горе-тестеры взяли внутренний сервис и выставили егоголым задомв интернет, без WAP, без настроек. Установили на него решение 2FA от сторонней компании, в документации к которому написано, что EWS оно не защищает. Проверили — действительно, не защищает! На радостях включили 2FA в O365. Не дождавшись применения настроек, проверили — и там ничего не работает! Написали в Microsoft, где пожали плечами и поставили их в игнор. Через месяц — звёздный час! — можно раструбить на весь интернет о своём существовании.
f15
16.11.2016 11:40Офигеть! Спасибо за уточнения, обновил текст новости. Если речь идет о каком-то редком сочетании разных решений, еще и от разных вендоров, то определенно получается совсем другая история. Все-таки один момент, мне кажется, можно уточнить: каковы шансы, что в какой-то компании настроят EWS так же, как горе-тестеры?
VitalKoshalew
16.11.2016 19:27Тут не EWS настраивали (его, как раз, не трогали), тут сумма вероятностей следующих действий, при том, что конфигурация не «коробочная», требуется принятие осознанных решений сисадмином:
1. Вероятность того, что кто-то выставит внутренний ресурс в интернет без дополнительного контроля, просто отфорвардив весь порт 443 с периметра и ничего не настраивая на сервере Exchange — ну бывает, одно время, когда TMG уже был объявлен EOL, а WAP ещё не доделали, некоторые сотрудники Microsoft от безысходности рекомендовали так пробрасывать. Сама по себе такая конфигурация одинаково (не)безопасна и для OWA и для EWS. И, конечно же, в тех рекомендациях речь не шла о 2FA, а, тем более, о стороннем продукте, который, упрощённо, этот URL на 443 порту защищает (/OWA), а вот этот (/EWS) — нет. Таким образом, дополнительные настройки при интеграции двух продуктов — ответственность сисадмина.
2. Вероятность того, что кто-то поставит Duo Security OWA и не прочитает к нему инструкцию. Тут уж совсем, что называется, «как потопаешь, так и полопаешь» — если лень читать инструкцию, а задача, лишь бы как-то заработало, то оно и будет «как-то» работать. Вендор рекомендует EWS/ActiveSync наружу не выставлять ("recommend against"). Как происходит инсталляция Duo Security OWA и предлагают ли они сами меры по закрытию лишних сервисов на порту, или полагаются, что этим озаботится сам сисадмин, прочитав их рекомендацию — тут вопрос к Duo Security, я не пользовался их продуктом. Но даже если их конфигуратор по умолчанию никуда больше не лезет, кроме того места, куда просят — это нормально, они в документации указали, что остальные сервисы они не защищают и их наружу попросили не выставлять. То есть, опять же, интеграция — ответственность сисадмина.
Таким образом, тут нельзя говорить о «конфигурации по умолчанию» — это не коробочное решение, а интеграция двух продуктов. В документации указано, как их рекомендуется интегрировать. Если документацию проигнорировали — это самодеятельность, всю ответственность за которую несёт сисадмин. «Коробочное» решение от Microsoft (O365) защищает и EWS тоже.
Guyver1982
16.11.2016 11:34Отдельный флажок для сайтов от гугла это да — долой рецидивистов!; о) Взломанные сайты под эту категорию не подпадают — интересно, как они будут отделять зёрна от плевел?
lehha
centos 6 и 7 больше обновлять openssl не будут? backports хотя бы?