Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Знаешь ли ты, сколько интерпретаторов Node.js работает на твоем компе? А сколько в них уязвимостей? С веб‑страниц язык JavaScript пришел на серверы, а с серверов — на десктопы, и вот старые баги заиграли новыми красками. В этой статье я разберу некоторые проблемы безопасности Node.js и покажу, как они работают, на примере популярных приложений — в том числе Discord и VS Code.
В основе этой статьи — мой доклад, который я читал на ZeroNights 2018, но по разным причинам (в том числе из‑за просьб Nvidia подождать до следующего патча) выход статьи затянулся. Я вообще мог забыть об этой теме, если бы антивирусные компании не стали находить вредоносное ПО, которое использует схожую с описанной мной в докладе технику.
Если хочешь быстро пробежаться по моим находкам, посмотри слайды презентации, а в статье я рассмотрю проблему более детально. Почему так вышло, что создатели малвари отнеслись к моей находке с большим интересом, чем разработчики софта?
info
Словосочетание NPM Package Hijacking уже могло тебе встречаться в исследовании, которое было опубликовано Нейтаном Джонсоном в 2016 году. Однако я расскажу об иной технике, и совпадение здесь в основном в названии.
Началась эта история, когда я еще вел в «Хакере» ежемесячные обзоры эксплоитов. Чтобы пользоваться всеми прелестями формата Markdown, я писал статьи в одном модном тогда редакторе и случайно обнаружил уязвимость типа XSS в модуле предпросмотра статьи. Я всего‑то забыл добавить кавычки, чтобы обрамить код очередного эксплоита, и вскоре докопался до RCE!
Я несколько раз отправлял разработчикам информацию об уязвимости, но руки до этого бага у них, видимо, так и не дошли. В очередной раз об этой проблеме я вспомнил, когда наткнулся на статью человека, нашедшего все ту же уязвимость в редакторе Atom.
Это вдохновило меня продолжать исследование и поискать похожие программы. Ведь Node.js в целом и движок Electron в частности все больше набирают популярность и используются во многих распространенных приложениях. Тут тебе и продукты Adobe, и апдейтеры разных игр, редакторы кода и текста, мессенджеры (в том числе «защищенные») и прочий софт. Node.js часто используется для создания установщиков и апдейтеров — Adobe попала в мой список именно так. Или можно вспомнить Nvidia GeForce Experience — утилиту, которая следит за обновлениями другого ПО Nvidia. Она тоже написана на модном нынче Node.js.
Приложения на Electron включают в себя браузер, основанный на Chromium, а к нему обычно идет локальный веб‑сервер — он тоже входит в программу и запускается вместе с ней. Так и получается, что на твоем рабочем компе внезапно крутится куча серверного софта. Вот только сисадминов у этого софта нет, а уязвимости или слабые места в защите по‑прежнему могут быть проблемой. Об эксплуатации одной из таких слабостей мы и поговорим.
В презентации я проиллюстрировал разницу между серверным и десктопным софтом картинками из одной известной игры
В «Хакере» уже не раз писали о DLL Hijacking, он же DLL/Binary Planting или Preloading. Эта техника работает так. Если разработчик не указал явным образом пути для загрузки библиотек DLL в своем исполняемом файле, то операционная система будет искать эти библиотеки по путям, перечисленным в переменной PATH
(в том числе в Windows, подробнее — в официальной документации). Подложив в какую‑то из этих папок вредоносный клон библиотеки, атакующий может исполнить произвольный код.
При загрузке модулей Node.js ищет папку node_modules
по всем путям выше родительской директории вызываемого скрипта, проверяя их, пока не найдет нужный модуль. Получается что‑то вроде ../node_modules
, где указателей на родительскую папку может быть произвольное количество. Более наглядно это представлено на картинке ниже.
Загрузка модулей Node.js
Думаю, ты уже догадался, почему я окрестил эту атаку NPM Hijacking по аналогии с DLL Hijacking. На исследуемых машинах я заметил многочисленные попытки загрузить скрипты из каталогов, перечисленных в переменной PATH
, или домашнего каталога текущего пользователя. Уж эта‑то папка доступна без всяких повышенных прав, чем и могут воспользоваться вредоносы. Собственно, такие фокусы уже вовсю практикуются при атаках на веб‑серверы с «Нодой», но там защита в целом на более высоком уровне, чем на десктопе, поэтому такая проблема менее опасна.
Давай теперь посмотрим, как эта особенность эксплуатируется в разных приложениях, внутри которых крутятся серваки с Node.js. Мы рассмотрим три примера:
Чат Discord знаменит возможностью общаться голосом, а сделан он на Electron. Неудивительно, что он уязвим перед NPM Hijacking, — проблему я обнаружил во времена версии 0.0.300, о чем и оповестил разработчиков. При запуске Discord ищет следующие скрипты, идя вверх по каталогам:
discord_utils.js
;discord_overlay2.js
;discord_game_utils.js
;discord_spellcheck.js
;discord_contact_import.js
;discord_voice.js
.Сам поиск и загрузка скрипта с точки зрения ОС выглядят как последовательный перебор следующих папок:
C:UsersUserAppDataRoamingdiscord .0.300modulesdiscord_desktop_corenode_modules
C:UsersUserAppDataRoamingdiscord .0.300modulesnode_modules
C:UsersUserAppDataRoamingdiscord .0.300node_modules
C:UsersUserAppDataRoamingdiscordnode_modules
C:UsersUserAppDataRoamingnode_modules
C:UsersUserAppDatanode_modules
C:UsersUsernode_modules
C:Usersnode_modules
C:node_modules
C:UsersUserAppDataRoamingdiscord .0.300modulesdiscord_voice.js
По умолчанию с первого по девятый пункт операционная система ничего не обнаружит, если у тебя нет таких папок, и только потом (на пункте 10) Node.js начнет поиск скрипта, лежащего не в node_modules
, а отдельно, как и сделано в Discord. Если нам доступна для записи папка пользователя, то мы можем подложить свою библиотеку так, чтобы она загрузилась, например, на пункте 7.
Источник: xakep.ru