Зачем изобретать велосипед?

Это известное изречение — то, о чем я думаю, когда думаю о стороннем коде. Менеджеры пакетов, такие как npm, RubyGems и Maven, настолько упрощают обмен написанным кодом между людьми, что разработчики используют его для таких небольших задач, как проверка того, является ли число положительным. Это абсолютно здорово, но многие ли из нас задумываются о том, что именно происходит за кулисами, под капотом, за волшебным занавесом?

Разработчики могли вписать любое количество уязвимостей, бэкдоров или вредоносных действий в библиотеку, которую они предоставляют для вашего использования, и вы об этом никогда не узнаете. Да, можно внимательно изучить содержимое кода, но на самом деле у разработчиков часто нет на это времени. Но что они могли сделать? Отличный вопрос.

В код можно вписать любое количество вещей, но давайте посмотрим на пример rimfall. Еще в 2015 году Lift security написал пост о том, как преинсталляционный хук в npm-пакете rimfall содержал и выполнял команду rm -rf /* в системе пользователя. Эта библиотека просуществовала в реестре npm всего 2 часа после того, как плохое поведение привлекло внимание сообщества HackerNews.

Приведенный выше пример не был широко распространен, но что, если бы это произошло с левой панелью?

В марте 2016 года популярный пакет npm left-pad был удален разработчиком Azer Koçulu после спора об имени другого пакета, который он поддерживал (см. Здесь для полной истории). В то время, как только пакет был удален из npm разработчиком, любой другой пользователь мог загрузить другой пакет с тем же именем. Удаление left-pad оказало катастрофическое влияние на сообщество разработчиков, так как этот пакет был очень популярен и широко распространен. Если бы злоумышленник был быстр, он смог бы загрузить пакет с именем left-pad, который имел те же функции, что и исходный пакет, но также содержал вредоносные действия. Если бы все было сделано достаточно быстро, многие люди бы ничего не поняли. Похожий случай был выявлен 1 августа 2017 года Оскаром Болмстеном, когда он написал это сообщение в Твиттере Кенту С. Доддсу, владельцу популярного пакета cross-env.

@kentcdodds Привет, Кент, похоже, что этот пакет npm крадет переменные env при установке, используя ваш пакет cross-env в качестве приманки: pic.twitter.com/REsRG8Exsx

— Оскар Болмстен (@o_cee) 1 августа 2017 г.

Он указал, что его пакет был опечатан пакетом со злым умыслом. Опечатка — это атака, при которой злоумышленник полагается на ошибки пользователя. Выбрав похожее имя пакета crossenv, разработчик (зарегистрировавшийся в npm под именем hacktask) сделал ставку на распространение своего вредоносного пакета на то, что люди могут случайно выбрать загрузку crossenv вместо cross-env. Пользователь, который с тех пор был удален из npm, также опубликовал дополнительные 37 типовых пакетов.

Вредоносный пакет, опубликованный hacktask, будет принимать переменные среды и отправлять их по адресу npm.hacktask.net. Если вас интересуют другие последствия, которые могут иметь эти атаки, ознакомьтесь с постом Злоупотребление библиотеками npm для кражи данных, который Асанкая написал в конце 2016 года.

Как узнать, отправляет ли какая-либо часть вашего кода данные в неожиданный источник?

Ранее SourceClear выпустила инструмент под названием Build Inspector — криминалистическую песочницу для сред непрерывной интеграции. Помимо прочего, Build Inspector можно использовать для предоставления обзора сетевого трафика, созданного во время сборки.

Используя вкладку «Сетевая активность», вы можете найти все разрешенные доменные имена, а также любые небезопасные запросы, которые выполняются через HTTP, пример которых указан ниже.

Изучив этот список, знающий разработчик сможет определить любые потенциально вредоносные действия, которые могут происходить. В показанном выше примере есть 2 подозрительных элемента, на которые следует обратить внимание. Оба подозрительных элемента вращаются вокруг домена areweflashyet.com. Это не тот URL, который можно было бы ожидать увидеть в сборке. Это может быть признаком того, что происходит какая-то вредоносная активность. После расследования, даже если вы обнаружите, что связь с areweflashyet.com является законной, она все равно будет указана в разделе Небезопасная сетевая активность, что означает, что она не осуществляется с использованием HTTPS. Уже одно это делает вас уязвимыми для атак человек посередине (MitM).

Обладая более глубокими знаниями о процессе и времени сборки, разработчики могут также использовать отчет, который создает Build Inspector, для обнаружения любых неожиданных изменений файлов или выполненных команд, происходящих в процессе сборки. Использование Build Inspector для любых неизвестных или подозрительных зависимостей позволяет узнать, происходили ли во время сборки какие-либо необычные действия, такие как кража переменных среды. Помимо работы со сборками npm, Build Inspector также можно использовать для выполнения и мониторинга сборок с gradle, mvn и gem. Это упрощает использование Build Inspector для тестирования новых, неизвестных зависимостей, прежде чем разрешить им быть частью ваших производственных сборок.

Дополнительную информацию о Build Inspector, его требованиях, использовании и нескольких примерах можно найти в следующем репозитории GitHub: https://github.com/continuous-security/build-inspector.