И сам инцидент, и результаты расследования представляют большой интерес. Речь идет о действиях хорошо подготовленной группировки, которая воспользовалась далеко не самым простым способом взлома корпоративной переписки. Последовавшее за взломом расследование также дает уникальный шанс понять, как такие инциденты становятся возможными в очень крупных организациях с большими затратами на защиту корпоративной инфраструктуры.
Прежде чем мы перейдем к результатам расследования, стоит напомнить о деталях самой атаки. О взломе корпоративной почты специалисты Microsoft узнали от клиента, который обнаружил подозрительную активность еще 16 июня. Изначально предполагалось, что взлом произошел по простому сценарию: через компрометацию одной из учетных записей сотрудника пострадавшей организации. Но позднее выяснилось, что токены доступа, принадлежащие компании, для взлома не использовались.
Вместо этого организаторы атаки воспользовались приватным ключом для выпуска уникальных токенов. Предположительно таким образом у атакующих появилась возможность получать доступ к инфраструктуре любой компании, использующей облачные сервисы Microsoft. Более того, из-за ошибки в конфигурации сгенерированный пользовательский ключ для доступа к сервисам типа Outlook Web Access также можно было использовать для доступа к Azure Active Directory. Наиболее подробно процесс взлома описан Microsoft, опубликованном в июле.
Однако на тот момент не было известно, как именно организаторы атаки получили доступ к приватному ключу. В новом отчете раскрывается как раз эта деталь. Ключ был украден у Microsoft, хотя в начале отчета компания говорит о том, что такого, по идее, происходить не должно. Инфраструктура была достаточно хорошо защищена, использовался строгий многоступенчатый контроль доступа к чувствительным данным. Но в какой-то момент еще в апреле 2021 года произошел сбой в системе выпуска клиентских токенов доступа. Как и при любом падении программного обеспечения, возник дамп пострадавшего процесса, в который случайно попал приватный ключ.
Этого тоже, по идее, не должно было произойти: приватные ключи не должны попадать в логи любого вида. В свежем отчете Microsoft сообщает о некоем состоянии гонки (race condition), из-за которого ключ все-таки попал в crash dump. Само по себе это не могло привести к утечке, так как лог хранился в изолированной инфраструктуре. Но в ходе рутинной работы по анализу таких логов crash dump был перемещен в менее защищенную среду, открытую для широкого доступа со стороны сотрудников Microsoft. Злоумышленники использовали скомпрометированную учетную запись одного из таких сотрудников для доступа к логу, из которого и извлекли приватный ключ.
Таким образом, речь идет о сложном киберинциденте в достаточно хорошо защищенной корпоративной инфраструктуре. К утечке привели совпадение случайных факторов и в целом мелкие недоработки: в crash dump попал приватный ключ, логи были перенесены в менее защищенную инфраструктуру, где довольно долго хранились, а затем были похищены и проанализированы злоумышленниками. Стоит отдать должное взломщикам: это еще надо было догадаться, что самые ценные артефакты хранятся именно в логах, и затем воспользоваться ключом для кражи корпоративных данных!
Есть в этой истории один нюанс: Microsoft лишь предполагает, что имела место данная последовательность событий, но не может утверждать это наверняка. Ввиду «политики по сохранению логов» реальных доказательств того, что описанное выше произошло, не существует. Здесь надо отдать должное уже тем, кто проводил расследование: они смогли восстановить наиболее вероятную картину киберинцидента по неполным данным. Вопрос хранения логов в этой истории вообще ключевой: пострадавшие клиенты столкнулись с трудностями при анализе взлома, так как их тарифный план не предусматривал достаточную детализацию журнала событий.
По итогам расследования Microsoft пришлось внести множество изменений в собственные процессы. Закрыта проблема, вызвавшая попадание приватного ключа в логи. На случай других подобных ошибок внедрена система сканирования логов на наличие приватных ключей. Изменена логика работы токенов доступа так, чтобы по ключу к почте нельзя было также получить доступ к Active Directory.
Что еще произошло:
Эксперты «Лаборатории Касперского» подробно разбирают альтернативный для соцсети Telegram со встроенными шпионскими функциями. Приложение ориентировано на пользователей в Китае и может красть историю переписки, список контактов, номер телефона и другое. На момент публикации отчета приложение было доступно в официальном магазине Google Play.
7 сентября Apple срочные патчи для iOS и iPadOS до версии 16.6.1. По организации Citizen Lab, две закрытые уязвимости могли использоваться в атаке типа zero-click. Злоумышленники могли взломать устройство, отправив на него сообщение iMessage, причем никаких дополнительных действий со стороны владельца не требовалось. Предположительно эксплойт для уязвимостей входил в набор ПО Pegasus, разрабатываемого компанией NSO Group. Отдельно Citizen Lab обсуждает, что, скорее всего, защищенный режим предотвращал такую атаку на устройства Apple. Не исключено, что разработчики средств атаки скоро начнут искать уязвимости, позволяющие обходить и этот особо безопасный режим.
Компания Google официально режим Privacy Sandbox в браузере Chrome. Название фичи слегка противоречит его сути: теперь браузер сам будет отслеживать ваши интересы на основе истории посещения сайтов и открывать доступ к этой информации для рекламодателей. Google пытается заменить этим новым подходом старый метод отслеживания интересов на основе «кук». Следующим этапом будет блокировка в Chrome сторонних (third-party) файлов cookie, что вынудит рекламодателей пользоваться платформой Google. Такое нововведение не выглядит как улучшение приватности для пользователей, но, по крайней мере, фичу в браузере можно будет отключить.
В обновленном текстовом редакторе Notepad++ запатчены уязвимости, приводящие к переполнению буфера при открытии подготовленного файла. Подробно эти проблемы, теоретически позволяющие выполнить произвольный код, описаны .
