Думаю, что вы слышали о взломе Uber , Cisco , LastPass , Okta , Microsoft, Twitter , Cloudflare , Twilio ? Если нет, то позволю себе напомнить.
Взлом LastPass
В инциденте с LastPass злоумышленник получил доступ в сегмент разработки через скомпрометированный компьютер одного из разработчиков, который был атакован через систему многофакторной аутентификации. Компания не раскрывает деталей, но есть две версии, как такое могло произойти. Первая — использовался метод MFA, неустойчивый к фишингу и атаке “человек посередине” (а такие используются чаще всего ввиду своей дешевизны).
Фишинговая атака на MFA
Вторая — пользователя просто закидали запросами от MFA и он в какой-то момент просто устал от них и нажал “Да”, предоставив тем самым доступ хакеру к внутренней инфраструктуре (в истории с Uber была именно такая ситуация).
Атака MFA bombing. Она же «атака на усталость от MFA» (MFA fatigue attack)
Взлом Uber
В случае с Uber злоумышленник с помощью социального инжиниринга получил доступ к компьютеру одного из сотрудников, представившись сотрудником ИТ-службы и попросив выполнить ряд действий (аналогичный способ был использован в недавних взломах Okta, Mailchimp, Microsoft и т.п.). После этого он смог через VPN-соединение проникнуть в корпоративную сеть агрегатора такси, где наткнулся на один из скриптов PowerShell, в котором был указан логин и пароль админа к системе управления привилегированными записями Thycotic, что, как мы понимаем, позволило получить доступ ко всей внутренней инфраструктуре, а также множеству внешних сервисов — AWS, Slack, Google Workspace Admin, vSphere, SentinelOne EDR (тут вообще нет слов — решение, которое позволяет получить доступ и данные со всех компьютеров внутри сети), BugBounty платформе HackerOne.
Хакер рассказывает, как он взломал Uber
Доступ ко всем тикетам BugBounty-платформы означает, что у злоумышленников есть описание всех выявленных кем-то еще слабых мест инфраструктуры и решений компании, в том числе и еще неустраненных!
Кейс Uber интересен тем, что 18-тилетний хакер, взломавший компанию, сам проявил себя, написав о своем взломе в одном из внутренних каналов Slack. Есть мнение, что таким образом он просто хотел привлечь внимание к слабой безопасности компании, чем был заинтересован в краже каких-либо данных. На фоне происходящего сейчас суда над бывшим CISO агрегатора, который в 2016-м году скрыл другой взлом от общественности по решению руководства компании, текущий взлом становится очень интересным.
Интересно, что во всех случаях, злоумышленники смогли обойти систему многофакторной аутентификации. Пока больше всего деталей опубликовано для кейса с Uber и во многих внутренних системах, в которые смог проникнуть злоумышленник, должна была использоваться система многофакторной аутентификации. Но она не сработала! Почему? Тут вариантов видно два (помимо очевидного — MFA не было вообще, что не очень логично, если уж она была реализована как минимум в сценарии удаленного доступа) — либо злоумышленник создал собственного пользователя, от имени которого потом и проводил все операции внутри инфраструктуры (в кейсе Cisco было именно так), либо MFA была отключена для целевых пользователей-жертв (такое было сделано в кейсе Okta).
Есть и третий вариант, который был использован как минимум в случае с Uber. Первую жертву просто “заспамили” пушами от MFA с последующей просьбой от имени лжеИТ-сотрудника принять соответствующий запрос, который позволил зарегистрировать ему свое устройство, с которого он затем и выполнял все операции (но врядли такое использовалось для всех внутренних скомпрометированных систем — это стало бы очень быстро заметно).
Взлом Cisco
В случае с Cisco ситуация с первичным вектором проникновения была идентична Uber, только вместо текстовых сообщений в Whatsapp от имени ИТ-службы, хакер использовал голосовые сообщения (vishing). Результат же оказался тем же — пользователь принял запрос от MFA (это тоже было решение Duo), что дало хакеру возможность зарегистрировать несколько новых устройств и затем уже инициировать VPN-соединение с внутренней инфраструктурой.
Вообще в MFA-решениях слишком большое число запросов на аутентификацию должно быть тригером для блокировки (в используемом в Uber решении Cisco Duo стоит лимит в 10 таких попыток). Получается, что в Uber либо было отключено установленное по умолчанию ограничение, либо хакер смог заставить сотрудника среагировать на пуш меньше чем за 10 попыток. Обратите внимание, что даже сами хакеры обращают на это внимание, делясь деталями взлома.
Не забудьте настроить число push-запросов в вашем MFA-решении
А у вас пользователи в курсе, что делать, когда они получают множество push-сообщений от решения MFA?
Microsoft, которая проводила анализ тактик и техник группировки LAPSUS$, стоявшей за взломом как минимум Okta и Cisco, подтвердила, что одним первичных векторов атаки, используемым группировкой, является голосовой фишинг (но такой вектор использовался и ранее, например, в атаке на Twitter в 2020-м году), а также подмена SIM-карт, с последующим получением доступа к учетным записям сотрудников организаций-жертв и использованием кризисных коммуникаций (например, подготовленных для оповещения сотрудников во время инцидентов) для втирания в доверие к жертвам и принуждения их выполнить нужные хакерам действия.
А как вы следите за корпоративными SIM-картами сотрудников? Это входит в обязанности службы ИБ?
Взлом Okta
Компанию, выпускающую решения для многофакторной аутентификации, взломали через подрядчика, который обеспечивал поддержку клиентов от имени Okta и чей компьютер был скомпрометирован. После проникновения в сеть Okta злоумышленники смогли получить доступ к ряду ключевых систем и коммуникаций, что позволяло, в свою очередь, существенно расширить плацдарм (например, в Okta хранила в Slack ключи AWS).
Доказательства взлома Okta
Также злоумышленники утверждали, что способны обнулить все пароли и MFA 95% клиентов Okta.
Возможность обнуления MFA для клиентов взломанной Okta
Как писали злоумышленники у себя в Telegram-канале их интересовала не сама компания, а ее клиенты.
А как вы оцениваете защищенность своих поставщиков услуг по кибербезопасности?
Позже Okta подтвердила, что по ее оценкам 2,5% ее клиентов могли стать жертвами хакеров. Многие эксперты обвиняли Okta, что та очень поздно сообщила о своей компрометации, — спустя два месяца после произошедшего. Вообще Okta не очень правильно себя повела в публичном поле, сначала скрывая, а потом постоянно «меняя показания», что заставляло взломавших их хакеров рассказывать в своем Telegram-канале «как оно было на самом деле».
У вас же есть план коммуникаций с внешним миром в случае инцидента ИБ?
Взлом Microsoft
Взлом Microsoft произошел благодаря взлому Okta, решения которой она использовала (это, кстати, интересно, компания, продвигающая свои решения по многофакторной аутентификации использует чужое MFA-решение), что позволило обнулить пароли сотрудников и настройки MFA, чтобы при следующем входе (это уже делали злоумышленники) необходимо было заново настроить MFA уже на новом устройстве, контролируемом злоумышленником.
Возможность обнуления MFA (на примере сотрудника Cloudflare)
Что делать?
Вообще, описание инцидентов, в которых была взломана или обойдена система многофакторной аутентификации, можно было бы продолжить. В этом году такие случаи происходили сплошь и рядом, но все они были похоже на описанные выше. Я специально упоминал кейсы очень известных компаний, в том числе и занимающихся ИБ, чтобы показать, что и на старуху бывает проруха и что взломать можно любую компанию.
Вопрос только в том, успеет ли компания обнаружить данный факт и оперативного среагировать на него, недопустив наступления критичных для своего бизнеса последствий? Согласитесь, что одно дело — компрометация рабочего ноутбука сотрудника, которая была оперативно обнаружена и заблокирована на VPN-шлюзе или порту коммутатора (при доступе изнутри), и совсем другое дело — когда с этого компьютера злоумышленник смог проникнуть на сервера подразделения разработки и внедрить закладку в ПО, поставляемое тысяч клиентов. Инцидент есть в обоих случаях, но во втором последствия гораздо более серьезные и такой инцидент может быть отнесен к недопустимым событиям для компании; чего не скажешь о первом кейсе.
Что же делать, чтобы такая история не повторилась с вами? Я бы выделил несколько рекомендаций:
- Разберитесь с тем, как можно осуществить обход MFA применительно к вашей инфраструктуре.
Способы обхода многофакторной аутентификации
- Отключение MFA (например, для отдельных пользователей или IP-адресов).
- Обход MFA (например, через перехват одноразовых кодов в SMS или использование инструментов типа Evilginx )
- Использование авторизованных исключений в MFA
- Кража приватного ключа для подписи сертификата SAML (например, так было сделано при взломе SolarWinds)
- Повторное использование сессии (у некоторых MFA используется по умолчанию 30-тидневный период перед повторной аутентификацией)
- MFA bombing
- Использовать современное решение по многофакторной аутентификации (MFA), неподверженное фишингу или атакам «человек посередине». Это точно не должно быть решение на базе SMS или софт-токенов, которое пока еще используется повсеместно. Я бы посмотрел в сторону токенов FIDO2 или решений на базе WebAuthn .
Неплохая дискуссия (на английском языке) по поводу использования современных методов аутентификации.
- Хорошо, если у MFA-решения будет возможность профилировать устройства, а также ограничивать или полностью блокировать доступ с неуправляемых или неизвестных устройств, особенно из новых или ранее неиспользуемых местоположений. Если такой возможности нет (а у отечественных MFA-решений ее нет :-(), то осуществлять мониторинг доступа с ранее неизвестных устройств или из нетипичных для сотрудника местоположений с помощью решений класса NGFW, NDR/NTA, EDR/XDR.
Обнаружение аномалий при многофакторной аутентификации - Контролировать все попытки входа на предмет аномальной активности с помощью решений класса UEBA и NDR/EDR/XDR.
- Осуществлять мониторинг каналов кризисных коммуникаций на предмет появления в них посторонних.
- Провести тренинг (включить в существующие тренинги) для сотрудников в части реагирования на атаку MFA bombing, а также научить реагировать на ситуации, в которых сотрудники ИТ- или ИБ-подразделения вдруг просят «нажать на кнопку» или прислать пароль.
Кстати, в 2020-м году, в разгар пандемии COVID-19, я как-то писал о том, что в условиях удаленки, когда мы не можем посмотреть в глаза айтишнику, пришедшему к нам на рабочее место, мы должны разработать способ подтверждения подлинности удаленных привилегированных пользователей, которые заставляют нас что-то делать дистанционно. Это могут быть ключевые фразы (ага, вспомнили фильмы про шпионов и разведчиков) или даже скретч-карты.
- Банально прозвучит, но может быть стоит провести пентест/пригласить Red Team, чтобы убедиться, что у вас нельзя реализовать описанные выше ситуации?
Ну и еще немного полезных ссылок по теме защиты многофакторной аутентификации:
- Доклад « Двухфакторная аутентификация: что, зачем, почему? » на PHDays 2022.
- Небольшое исследование о применении двухфакторной аутентификации и ее трансформации в надежную многофакторную на базе стандартов FIDO Alliance
- Как Twitter после своего взлома изменил управление MFA внутри своей инфраструктуры?
- Как 3 сотрудника Cloudflare попались на SMS-фишинг от взломанной Okta, но компания предотвратила проникновение внутрь своей инфраструктуры?
- Детальное описание кампании 0ktapus, в которой были взломано 130 организаций с помощью фишинга на MFA-решения.
- Как была взломана SolarWinds через обход многофакторной аутентификации?
- Доклад « 12 способов взломать 2FA » на RSA Conference 2019
- Доклад « Purple Team Auth: Hacking & Bypassing MFA Systems, and How to Armor Up » на RSA Conference 2021
- Доклад « Modern Identity Hacking: Have Hackers Really Adjusted to Constant Remote? » на RSA Conference 2021
- Доклад « Defending Against New Phishing Attacks that Abuse OAuth Authorization Flows » на RSA Conference 2022
- Руководство NIST по выбору методов идентификации и аутентификации SP 800-63 «Digital Identity Guidelines »
- Книга « Взламывая многофакторную аутентификацию » от издательства Wiley
Стоит помнить, что средства/технологии ИБ, как и компании их выпускающие, тоже могут стать мишенью злоумышленников. А неумелое использование имеющихся решений по защите информации может создать чувство ложной защищенности, которое может дорого обойтись и компании, и ИБшникам, их внедрившим и эксплуатирующим.
