Внимание, сотрудники предприятий в командировках: дважды подумайте, прежде чем подключаться к столь удобному общедоступному Wi-Fi.
По данным команды Threat Research компании ReliaQuest, по крайней мере с июня злоумышленники взламывают «гостевые» шлюзы Wi-Fi и другие портальные устройства в отелях, конференц-центрах и подобных местах общего пользования, чтобы перехватывать учётные записи Microsoft 365 у пользователей.
Получив контроль над шлюзом, злоумышленник может незаметно перенаправлять трафик пользователя на свою инфраструктуру и похищать учётные данные Microsoft 365, не касаясь устройства пользователя, не взламывая конечные точки и не отправляя фишинговые ссылки или вредоносные вложения.
«Самый опасный элемент заключается в том, что атака происходит на сетевом шлюзе, который находится ниже большинства уровней доверия, на которые полагаются пользователи и устройства», — сообщили в ReliaQuest CSO Online. «Сама по себе это не обязательно событие уровня корпоративного взлома, но это очень реальный риск для отдельных учётных записей».
Эксплуатация «фундаментального доверия»
Отравление системы доменных имён (DNS), при котором внедряются ложные данные для перенаправления обычного веб-трафика на мошеннические домены, ранее наблюдалось на маршрутизаторах малых офисов, но теперь атакующие расширяют эту технику на цели более высокого уровня, пояснили исследователи ReliaQuest в блог-посте.
Злоумышленники, вероятно, получают доступ к шлюзам через слабые или повторно используемые учётные данные администратора в сочетании с открытыми интерфейсами, такими как Secure Shell (SSH), Simple Network Management Protocol (SNMP) и другими веб-консолями, отметили они.
Административный доступ к шлюзу — это всё, что нужно злоумышленникам, поскольку устройства по своей сути доверяют DNS, который преобразует доменные имена, такие как login.microsoftonline[.]com, в IP-адреса для маршрутизации. Таким образом, одного взлома шлюза достаточно, чтобы атакующий мог перенаправлять трафик каждого гостя, подключающегося к сети, предоставляя в ответ на DNS-запросы IP-адреса, которые он контролирует, вместо легитимных, не затрагивая ни одной конечной точки.
«Гостевые портальные устройства находятся на сетевом периметре для каждого гостя в этой сети», — написали исследователи. «Обнаружение по своей сути затруднено, потому что атака происходит на стороне шлюза, вне зоны видимости конечной точки».
В кампании, отслеживаемой ReliaQuest, использовались четыре домена, зарегистрированные злоумышленниками: m365-owa[.]com, owa-ms365[.]com, ms365-device[.]com и ms365-live[.]com — для приманок, имитирующих Microsoft.
Скомпрометированные шлюзы Wi-Fi были обнаружены в нескольких городах США, а также в Индии и Саудовской Аравии; пострадавшие пользователи были из компаний в сфере профессиональных и финансовых услуг, юриспруденции, розничной торговли, здравоохранения и энергетики, что указывает на то, что метод не привязан к конкретному сектору.
«Мы видели достаточно случаев утечки данных из SharePoint, чтобы знать, что одна скомпрометированная учётная запись может привести к значительной потере данных», — отметили в ReliaQuest. В то же время для операторов сетей существует «репутационное измерение»; компрометация пользователя — это «серьёзная проблема доверия и бренда, независимо от того, насколько “изощрённой” является лежащая в основе атака».
Безопасные сервисы и DNSSEC недостаточны
Фиксация сетевых конфигураций на «безопасном» DNS-провайдере, таком как Google (8.8.8.8), Cloudflare (1.1.1.1) или облачный OpenDNS, не является достаточной тактикой, поскольку это не меняет путь, по которому фактически проходят запросы, утверждают в ReliaQuest.
По умолчанию устройства отправляют DNS-запросы как незашифрованный протокольный трафик, и эти пакеты всё равно должны проходить через сеть отеля, чтобы достичь Google, Cloudflare или OpenDNS, пояснили в компании. Поскольку шлюз находится непосредственно на этом пути, он может проверять, блокировать или перенаправлять запрос до того, как он достигнет выбранного резолвера.
«Указание доверенного DNS-сервера меняет предполагаемый пункт назначения, а не того, кто контролирует дорогу к нему», — отметили в ReliaQuest.
Кроме того, расширения безопасности системы доменных имён (DNSSEC), использующие цифровые подписи и криптографию с открытым ключом, лишь «частично» решают проблему. DNSSEC обеспечивает аутентификацию и целостность для подписанных доменов, что означает, что проверяющий резолвер может обнаружить и отклонить поддельные или изменённые ответы.
«Чего он не делает, так это не обеспечивает конфиденциальность или доступность», — заявили в компании. «Он не шифрует DNS-трафик и не мешает злоумышленнику перехватывать, блокировать или перенаправлять запросы».
Таким образом, хотя DNSSEC может противостоять определённым атакам с подделкой ответов для подписанных зон, шлюз, находящийся на пути, всё равно может видеть запросы, отбрасывать их или принуждать к поведению с понижением уровня. Однако этот уровень защиты помогает только тогда, когда домены действительно подписаны, и только если клиент или резолвер выполняет проверку, чего «многие stub-резолверы не делают», по данным ReliaQuest.
Требуются VPN с полным туннелем
Для борьбы с проблемой предприятиям следует требовать от всех корпоративных устройств использования VPN с полным туннелем для сетевого подключения. Контроль должен предотвращать доступ в интернет до тех пор, пока туннель не будет активен, советуют в ReliaQuest.
Это направит весь трафик устройства, включая DNS, через зашифрованное соединение к доверенному VPN-серверу, прежде чем он отправится куда-либо ещё, пояснили в компании, тем самым предотвращая возможность локальных сетей, таких как гостиничные шлюзы, видеть или изменять DNS- и интернет-трафик.
«По сути, это исключает ненадёжную сеть из уравнения доверия», — отметили в ReliaQuest.
Однако конфигурация полного туннеля не является настройкой по умолчанию для VPN, поскольку она сопряжена с «реальными компромиссами», отметили исследователи: она увеличивает стоимость, задержку и требования к пропускной способности, так как каждый пакет должен проходить через корпоративную инфраструктуру. Таким образом, принудительное направление всего трафика через корпоративную магистраль «не всегда практично» для распределённых или требовательных к пропускной способности сотрудников.
Предприятиям также следует применять условный доступ в Entra ID для блокировки потока аутентификации с кодом устройства, который имеет мало легитимных случаев использования для большинства пользователей в большинстве сред, отметили в ReliaQuest.
Дополнительные меры предосторожности
Компания также рекомендовала:
- Ограничить получение файлов автоматической настройки прокси (PAC) только одобренными внутренними хостами;
- Отключить автоматическое обнаружение веб-прокси (WPAD) через групповые политики (это часто включено по умолчанию в Windows);
- Развернуть зашифрованный DNS, такой как DoH или DoT, в строгом режиме в качестве «дополнения или альтернативы» VPN с полным туннелем. Это особенно важно для организаций, где VPN с постоянным подключением невозможен.
- Обучать сотрудников проверять URL и сертификат любой страницы, запрашивающей учётные данные, перед их вводом, особенно в сетях общедоступного Wi-Fi.
Профилактика здесь важнее обнаружения, указали в ReliaQuest: хотя в таких инструментах, как Microsoft Defender для конечных точек, события ‘DnsConnectionInspected‘, показывающие запросы к контролируемым злоумышленником доменам, являются основным сигналом на уровне конечной точки, «к моменту срабатывания этих событий перенаправление обычно уже произошло. Другими словами, телеметрия конечной точки скорее подтверждает произошедшее, чем предотвращает его».
Именно поэтому такие методы, как шифрованный транспорт, условный доступ и усиление WPAD и PAC, важнее, чем одно только обнаружение, подчеркнули исследователи.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Taryn Plumb
