Уязвимость в Chrome для Windows позволяет похитить учетные данные при помощи SCF-файлов

Просто открыв папку, содержащую вредоносный SCF-файл, пользователь, атакованный через Google Chrome, невольно передаёт учётные данные по протоколу SMB. Сами методы не новые, но это комбинация двух разных техник — одна взята из Stuxnet, а вторая — детально рассмотренная исследователями безопасности на конференции по безопасности Black Hat. 

SCF-файлы как вестники плохих новостей

Эта атака представлена сербским исследователем безопасности Боско Станковичем из DefenseCode и ориентирована на файлы SCF.

SCF (Shell Command File) — это формат, поддерживающий очень ограниченный набор команд Windows Explorer, таких как открытие окна проводника или отображение рабочего стола. Ярлык «Свернуть все окна», который мы все используем ежедневно, представляет собой файл SCF.

При хранении на диске, как и LNK-файлы (ярлыки), SCF-файлы извлекают иконки файлов при их открытии в окне проводника.

На протяжении многих лет файлам LNK разрешалось хранить местоположение своего файла значка внутри DLL или по URL-адресу. После того, как Equatation Group (одно из подразделений АНБ США) использовала возможность загрузки вредоносного кода через файлы LNK в атаках Stuxnet, Microsoft исправила их таким образом, чтобы загружать иконки только из локальных ресурсов.

На SCF-файлы этот патч не повлиял, поэтому с их помощью всё еще можно загрузить иконку SCF-файла из интернета.

Ретрансляционная атака используется для получения учетных данных

Используя информацию с конференции Black Hat 2015, Станкович создал SCF-файл, который скачивает иконку с URL-адреса, по которому расположен SMB-сервер.

Это означает, что всякий раз, когда компьютер пользователя попытается загрузить изображение, сервер будет запрашивать учетные данные пользователя и получать их, так как операционной системе будет казаться, что ей необходимо пройти аутентификацию.

Проблема заключается в том, что эти SMB-запросы выполняются независимо от желания пользователя. ОС Windows построена таким образом, что загрузка иконки происходит автоматически при переходе в папку, без взаимодействия с пользователем.

Когда пользователь переходит в папку, содержащую вредоносный SCF-файл, ОС мгновенно считывает его, создаёт запрос к удаленному SMB-серверу и передаёт учетные данные в виде хеша пароля типа NTLMv2, NTLMv1 или LM, в зависимости от версии операционной системы.

Это проблема, потому что существует много инструментов с открытым исходным кодом, которые могут взломать эти типы хешей. LM тривиален, а на NTLMv2 может уйти до нескольких дней.

Кроме того, в случае с Windows 8 и выше злоумышленник получает хеши не только пароля, но и других служб, таких как OneDrive, Outlook.сom, Office 365, Office Online, Skype, Xbox Live и других.

Но причём здесь Google Chrome?

Не было бы никаких проблем, если бы пользователи не имели вредоносных SCF-файлов на своих компьютерах. И тут на сцену выходит Google Chrome, самый популярный браузер на рынке.

Станкович объясняет, что эти SCF-файлы очень легко доставить на пользовательский компьютер. Это связано с тем, что в настройках по умолчанию браузера Chrome файлы, которые он считает безопасными, при запуске скачивания не запрашивают у пользователя место загрузки — такими являются и SCF-файлы.

Кроме того, злоумышленнику необязательно требуется социальная инженерия для передачи пользователю вредоносного SCF-файла. Существует множество сайтов, подверженных уязвимости с «отраженным» скачиванием файла (Reflected File Download)«, позволяющей злоумышленнику загружать файлы на компьютер пользователя. При использовании конфигурации Chrome по умолчанию, которую используют многие пользователи, этот файл попадёт в папку «Загрузки».

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

Как защититься?

Станкович советует пользователям настраивать браузер Chrome таким образом, чтобы он каждый раз запрашивал, куда сохранять файл. Сделать это можно следующим образом:

Более продвинутой мерой защиты будет включение блокировки исходящих SMB-запросов через межсетевые экраны, чтобы локальные компьютеры не могли запрашивать удаленные SMB-серверы.