Невероятная опасность зависимостей от апстрима

В этой статье рассматриваются многочисленные случаи перехвата репозиториев JavaScript с помощью социальной инженерии, в результате чего происходят невероятные атаки на ничего не подозревающих пользователей и программное обеспечение. Первое: Компромисс с BitPay.

EventStream Взлом

20 ноября 2018 г. Айртон Спарлинг громко обнаружил проблему в репозитории Github для модуля NPM EventStream: новый сопровождающий репо внедрил вредоносный код в него. доработок, а потом замазали .

История настолько же смехотворно проста, насколько и нагла: EventStream, восходящая зависимость (например, автоматически импортированная в цепочки зависимостей NPM), по сути, была неподдерживаемым репо, первоначально созданным Домиником Тарром.

Случайный пользователь с низким уровнем коммитов и минимальной репутацией, right9ctrl, спросил, может ли он взять на себя обслуживание.

Доминик согласился.

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

После отчета Айртона к расследованию присоединились многочисленные пользователи, и подробности того, что может сделать полезная нагрузка, были ужасающими:

Хуже того: тонны криптопроектов зависели от EventStream. В том числе BitPay.

И это не первый раз, когда раскачивающаяся башня JavaScript LEGO обрекает на гибель сотни или тысячи проектов.

Помните Неопубликованную эпопею Азера Кочулу?

Kik’d to the Curb

Азер Кочулу написал множество модулей NPM. Одного случайно звали Кик, и юристы мессенджера Kik решили, что они хотят присвоить место NPM, которое проект Кочулу занимал, своим собственным.

Он отказался переименовать свой проект.

NPM забрал его, вызвав эпическое «аннулирование публикации» всего, что он внес в NPM.

Неожиданно большая часть Интернета немедленно отключилась, поскольку проверки зависимостей NPM завершились неудачно из-за отсутствия конкретного проекта: left-pad.

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

NPM фактически отменил публикацию проекта, чтобы положить конец панике.

Темная Башня

Зависимости от апстрима - это новая норма для разработчиков Node.js.

Действительно, в экосистеме Node.js существует так много LEGO-подобных кирпичиков, которые настолько легко доступны с помощью диспетчера пакетов узлов, что проверка и безопасность становятся все труднее.

То, что было собрано, как продемонстрировано в случае EventStream, представляет собой «темную башню» зависимостей, в которой некоторый процент требуемых проектов является заброшенным, не обслуживаемым или незащищенным.

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

Какие существуют механизмы для решения этой проблемы? Какие органы проверяют состояние этих цепочек зависимостей?

Конечно, НПМ реагирует на информацию, но почему не может быть активной методологии оценки этих рисков?

Кроме того, нельзя ли изобрести механизм вознаграждения первоначальных сопровождающих, чтобы они не теряли интереса к своей работе, когда она становится все интенсивнее? (Любая простая такая система вознаграждения, естественно, станет жертвой фальсификации, но я думаю, что ее стоит изучить).

Попробуй себя

Ваш проект затронут взломом EventStream?

Перейдите в папку своего проекта и запустите npm ls event-stream flatmap-stream, чтобы узнать.

Хороший результат выглядит так:

Но плохой результат покажет зависимость, как это было в случае с пользователем lcl22hope:

Резюме

  • Пакеты NPM имеют длинные, иногда слабо защищенные цепочки зависимостей.
  • Одно слабое звено может привести к автоматическому выполнению вредоносных программ и эксплойтов.
  • Вероятно, мы недостаточно делаем для защиты унаследованных проектов, которые широко используются, но не стимулируют исходных разработчиков.
  • Как показывает критика Доминика, предполагается, что владельцы репо несут какую-то длительную ответственность за свои взносы. Оправдана ли такая личная критика или виноваты сами механизмы?