Комментарии 55
запустил программу для «исправления» каждого из файлов «package.json» клонированного проекта с оператором «postinstall», имея логику для эксфильтрации переменных среды
Имя логику, а заодно, по ходу, переводчика и весь русский язык.
Код отфильтровал важные переменные среды. Допустим, вы делаете POC, и отправки имени вашего компьютера более чем достаточно.
Так отфильтровал или всё же нет?
подпись коммита не проверена
коммит вообще не подписан подписью.
Удаление постустановочных скриптов на самом деле ничего не решит — вместо этого вы просто вставите свой вредоносный код куда-нибудь в код пакета.
Действительно, удалял на днях постустановочный скрипт и, внезапно, вставил вредоносный код внутрь пакета. Боги, что за чушь тут написана?
Эта атака, возможно, направлена на пользователей, которые вводят в search-engines-related code snippets
даже magic gooddy лучше бы справился
для получения имени пользователя и адреса электронной почты пользователя, которого злоумышленник хотел бы выдать за другого
Кого, простите, злоумышленник хочет выдать за другого? Получаемое имя пользователя?
Вы вроде пытались важную информацию донести своей статьёй но где-то по пути что-то явно пошло не так. Это как если бы айтишники статьи по медицине писали, ей богу — было бы не менее смешно и столь же удручающе читалось, какая бы полезная (и не важно, насколько баянистая, ага) там информация не была выложена.
Timeweb, если вы считаете ЭТО хорошей рекламой своему сервису на IT–ресурсе, то у меня для вас плохие новости.
Я вообще нифига не понял. Похоже суть в том, что злоумышленник форкает популярный репозиторий, добавляет вредоносный код, коммитит его (в своём же форке) как бы от имени владельца оригинального репозитория, юный программист, возжелавший исходников, натыкается на форк, копирует код себе, не глядя запускает и приехали. Если так, то это всё равно что по ссылкам в фишинговом письме щёлкать, и такому юзеру и так пофиг от кого там последние коммиты и подписаны они или нет. А коммитить, используя чужой идентификатор, вроде и раньше можно было и где-то было обсуждение - является ли это вообще угрозой или нет.
Если так, то это всё равно что по ссылкам в фишинговом письме щёлкать, и такому юзеру и так пофиг от кого там последние коммиты и подписаны они или нет.
Ну в целом так: в гитхабе же не только крупные и поддерживаемые проекты, хватает небольших полезных проектов, которые давно заброшены маинтейнерами - и у многих куча форков с исправлениями под современные реалии. И десяток вредоносных форков среди таких будет совершенно не заметен.
А про подпись коммитов я лично в первый раз слышу - в руководствах по использованию гита на него не натыкался.
Ну тут надо быть очень внимательным, да.
Про коммит от имени чужого пользователя я по-моему видел что-то на хабре, но не могу найти. Вроде там только email пользователя надо знать и больше ничего.
Сам гитхаб вот что пишет:
Why are my commits linked to the wrong user?
Ну а про подпись вот навскидку:
Git Tools - Signing Your Work
Про коммит от имени чужого пользователя я по-моему видел что-то на хабре, но не могу найти.
Возможно вот https://habr.com/ru/post/515550/
не все так однозначно. Как быть с проектами которые разработчик забросил, а их подхватил кто-то другой, например? изучать полностью 2 ветки и пытаться понять вредоносный код это или полезный?
Имхо там всё предельно понятно. Злоумышленник пофоркал проекты и потом влил туда телеметрию, переписав историю тем или иным образом. В надежде, что они попадут в поиск.
Подпись коммитов - это действительно хорошая идея для чего-то важного.
Перевод страдает. Вероятно, автору нужно было самым первым запостить эту новость, и на красивости не было времени.
Статья - какой-то лютый бессмысленный речекряк, абсолютно ничего не объясняющий.
Он рекомендует не устанавливать случайные packages из Интернета, и призывает подписывать коммиты GPG.,
Смотря какой fabric, смотря откуда приходит fabric
Как сказали на реддите под этой новостью:
Person uploads malware into their own project that wasn't used by anyone. Panic ensues.
Офигенная атака, да.
На самом деле вектор атаки тут есть. Если форкать давно не обновляемые репозитории, лупить туда псевдоапдейты в которых якобы что-то пофикшено или указан переход на современные библиотеки то вполне себе вменяемый человек может такие форки попытаться использовать. А если там кроме вредоноса действительно что-то нужное исправлено/добавлено то и оставить в рабочем проекте.
Проблема в том, что можно делать коммиты под чужим именем. Вы делаете коммит от кого-то знакомого мейнтейнеру проекта, надеясь что он не будет внимательно все проверять и смержит. Можно использовать подпись, но все ли так делают?
Вообще сама идея "собственного имени" - это нечто, что противоречит идее децентрализации. Чтобы имя стало "собственным", нужно чтобы какой-то центральный источник это подтвердил. Наличие центрального источника - прямая дорожка до тоталитаризма. Гит - это децентрализованная система, и в этом его ценность!
было гораздо более понятное объяснение произошедшего.
Разработчик Стивен Лейси обнаружил [1, 2] широко распространенную атаку вредоносного ПО на GitHub, затронувшую около 35 000 репозиториев программного обеспечения.
Речь идет о клонировании тысяч репозиториев GitHub в рамках нацеливания на ничего не подозревающих разработчиков. Тысячи проектов являются форками известных проектов, таких как crypto, golang, python, js, bash, docker, k8s и др., правда с начинкой в виде бэкдоров.
В анализа одного из них с открытым исходным кодом инженер заметил следующий URL-адрес в коде hxxp://ovz1.j19544519.pr46m.vps.myjino[.]ru.
При поиске GitHub по этому URL-адресу было найдено более 35 000 результатов, отображающих файлы с вредоносным URL-адресом. При этом более 13 000 результатов поиска соответствовали одному репозиторию под названием redhat-operator-ecosystem, который был оперативно удален с GitHub.
Разработчик Джеймс Такер указал, что клонированные репозитории, содержащие вредоносный URL-адрес, не только извлекают переменные среды пользователя, но и дополнительно содержат однострочный бэкдор.
Эксфильтрация переменных среды сама по себе может предоставить злоумышленникам ключи API, токены, учетные данные Amazon AWS и криптографические ключи, где это применимо.
Подавляющее большинство клонированных репозиториев были изменены с помощью вредоносного кода в течение последнего месяца. Тем не менее, были и репозитории с вредоносными коммитами, датированными еще 2015 годом.
GitHub удалил вредоносные клоны со своей платформы после получения отчета инженера. Тем не менее ресерчер Флориан Рот предоставил правила Sigma для обнаружения вредоносного кода в среде.
Разработчикам следует не забывать использовать ПО исключительно из официальных репозиториев и внимательно отслеживать потенциальные опечатки или разветвления репозитория, которые могут казаться идентичными исходному проекту, но скрывать вредоносное ПО.
Я давно уже считаю что использовать переменные окружения в наше время неудобно и небезопасно. Просто положив ваши пароли-секреты в отдельный файлик вне папки с кодом, вы уже значительно усложните задачу по их поиску. Конечно, это тоже не очень способ, но хоть с чего-то надо начать..
Прочитать переменные окружения и отправить POST-запрос с ними сейчас, теоретически, можно сравнительно маленьким куском кода, замаскированным под регексп.
Просто положив ваши пароли-секреты в отдельный файлик вне папки с кодом
Вы только что начали лечить понос затыканием жопы)
Сэр, вот вы пришли в комментарии, нагрубили пошлым комментарием неизвестному вам человеку, по сути не предложили ничего умного. Это хорошо?
Я, тем не менее, с удовольствием узнаю вашу точку зрения - как бы вы предложили решить такую проблему?
Большая часть проектов на гитхабе - это небольшие библиотеки или скрипты. Им нет необходимости городить сложные энвароменты с, например, Vault или другими хранилищами секретов, но им нужны, например, ключи для AWS.. Вроде бы сейчас уже меньше стало хардкода паролей в коде, но переменные окружения до сих пор считаются нормальной практикой, несмотря на кучу уязвимостей с ними.
Если вставить в практически произвольное место проекта на, скажем, питоне, однострочник с отправкой переменных окружения на какой-то левый адрес, то есть шанс, что никто и не заметит. И это довольно просто сделать для тысяч проектов (как и было продемонстрировано). Если же ваши пароли лежат в отдельном файле, то его еще надо найти (атака уже адресная), а для проекта прочитать файл не сложнее работы с окружением.
Я понимаю все минусы хранения в файлах, конечно же. Но - я здесь сравниваю только с переменными окружения.
Я, тем не менее, с удовольствием узнаю вашу точку зрения - как бы вы предложили решить такую проблему?
Как бы совершенно очевидно, что если ваша пропатченая библиотека или скрипт используют логин и пароль, то куда бы вы его не прятали, в переменную окружения ли, в командную строку, или в не менее секретный файлик — в любом из этих случаев ваш драгоценный пароль утечёт, а дырявая библиотека откроет на вашей машине дупло таких размеров, что вы замучаетесь потом всё это вычищать. Поэтому совершенно очевидно, что решать проблему нужно не затыканием жопы (читай: перекладыванием пароля из одного места в другое), а неиспользованием левых репозиториев, незапуском мутного вареза на машине, и вообще мытьём рук перед едой.
Это просто немыслимо. Webpack стандарт в мире разработки фронтэнда. Фактически, в веб-разработке практически на любом своременном стеке (даже на F#) он к вам доедет. У него самого больше сотни зависимостей (включая дев), у каждой из которых от 10 до 30 своих зависимостей, если покопаться, можно выйти на https://www.npmjs.com/package/xo (кто об это вообще слышал) -> execa -> c8 -> standard -> standard-engine -> installed check -> npm-run-all2 у которого есть pretest скрипт, который что-то делает. Проверить эту всю кротовую нору фактически нереально, поэтому нужно предпринимать более сложные шаги, на подобие сборки в докере без доступа к окружению.
а подобие сборки в докере без доступа к окружению
Ну собрали без доступа к окружению, и дальше что? Ваша дырявая прога будет слушать дефолтный порт, и при приёме магического пакета будет выполнять команду drop database (или create user, если хотите). Даже если у вас вообще нет никакого доступа ни к какому окружению (допустим, это статический сайт), то всё равно остаётся возможность отгрузить клиентам веб-майнер, или ещё какую-нибудь хрень.
Просто сейчас линуксоиды столкнулись с тем, с чем столкнулась винда 30 лет назад: разработка вирусни под линукс внезапно стала выгодной.
С одной стороны да, с другой - это же просто минимизация рисков. Ну вот взять веб-звонки. Мы в данный момент не можем потянуть написать это с нуля, вынуждены пользоваться чем-то. Да и вебпак нужен тоже. Ничего не ставить - так себе бизнес модель. Более того, шансов что самописный код будет иметь уязвиосмость больше чем шансы зловредна у пакета, который скачивают 40 млн раз в неделю (окей, что его никто не заметит с этими вашими сонар кубами и прочим).
Но минимизировать все равно можно. Конкретно с фронтэнжом собирая в «чистом» докере мы не даем доступов ни к чему во время сборки. Чтото может просочиться в бандл, но мы постоянно толпой просматриваем все запросы которые делает наш фронтэнд и куда он их делает, более того у нас есть service worker который протестирует все запросы и поддельный будет обнаружен быстро (впрочем, это особенности именно нашего продукта, в котором нам нельзя делать 3rd party requests вообще. У части клиентов стоит строгий whitelist например). Да, теоретически он может «спать» неделями, годами, но опять же - риск менеджмент он такой.
С бэкэндом, конечно же, сложнее. Но тоже решается зеркалом и доступами куда ему можно ходить.
К слову, с тем что перекладывание паролей из одного места в другое слабо решает проблему, я все же соглашусь. Это довольно распространенная практика и все используют одни и те же пакеты для Парсинга конфигов, так что толку то. Да и можно внедрить вредонос непосредственно в драйвер базы данных (рефлексией или какой еще магией вам позволяет это сделать язык) и удачи.
шансов что самописный код будет иметь уязвиосмость больше чем шансы зловредна у пакета, который скачивают 40 млн раз в неделю
Это без сомнения именно так. Но в статье речь о другом: о том, что вы случайно вместо одного пакета включаете другой, со скачиванием 10 раз в неделю, в котором шанс нахождения зловреда на порядки выше. Просто потому, что вам пытаются показать, что этот пакет новее, или лучше поддерживается.
Проверить эту всю кротовую нору фактически нереально
Речь идёт не о том, чтобы лично вы проверяли эту кротовую нору, а о том, чтобы вы как минимум не воткнули в свой проект левый форк вместо оригинального репозитория. Потому что тема сейчас определённо поедет.
Мой пример был о том, что в ноде вы не воткнули, но как вы определите что какой-то из дочек дочек дочек не воткнул?
но как вы определите что какой-то из дочек дочек дочек не воткнул?
Это же не я определяю, а мейнтейнеры пакетов. Но целевая аудитория этой конкретной атаки с фейковыми форками не они, а обычные ололо-веб-программисты.
С чего вы взяли что разработчик "какой-то из дочек дочек дочек" не может быть так обманут? Там зачастую точно такие же ололо-веб-программисты (ох уж этот элитизм...)
С чего вы взяли что разработчик "какой-то из дочек дочек дочек" не может быть так обманут?
Как минимум с того, что его код популярен, и проверен множеством использований (и элитизм тут ни при чём).
Как минимум с того, что его код популярен, и проверен множеством использований (и элитизм тут ни при чём).
В это предлагается просто исступленно верить, потому как после этой фразы принято кивать с умным видом и расходиться. Кто те полчища мэйнтейнеров, которые проверяют каждый пакет во всех тысячах зависимостей обычно уже не обсуждается.
Я думал эта байка опенсорса рассыпалась после целой череды уязвимостей, которые годами висели ненайденными. Чего стоит только последняя пачка уязвимостей в Самбе.
и элитизм тут ни при чём
Я и не говорю что он оправдан.
Если вставить в практически произвольное место проекта на, скажем, питоне, однострочник с отправкой переменных окружения на какой-то левый адрес, то есть шанс, что никто и не заметит.
Если вставить в практически произвольное место проекта на, скажем, питоне, однострочник с отправкой файла с паролями на какой-то левый адрес, то шанс что никто его не заметит тоже есть.
Если практика хранения паролей в отдельном файле станет распостраннённой и вирусы будут красть файлы, а не переменные окружения, то вы будете реккомендовать вынести пароли из файла в какое-то другое место? Например, в переменные окружения?)
Я, например, буду рекомендовать, например, прочитать настройки из этого файла и удалить, чтобы больше к нему не имел доступа никто из этого контейнера. Их все еще можно будет получить из памяти, из этого же файла до его удаления, но это уже, опять же, адресная атака на конкретно это приложение, здесь можно много всего придумать.
Переменные окружения часто наследуют даже дочерние процессы, запущенные из основного, а сервисы в контейнерах до сих пор запускаются из-под root, так что, опять же - с ними проблема стоит острее.
Я, например, буду рекомендовать, например, прочитать настройки из этого файла и удалить, чтобы больше к нему не имел доступа никто из этого контейнера.
Ну т.е. вы будете хранить пароли не в файле, а в памяти? И однострочнику на пайтоне ничего не помешает прочитать их из памяти и отправить на удалённый сервер?
Их все еще можно будет получить из памяти, из этого же файла до его удаления, но это уже, опять же, адресная атака на конкретно это приложение
Если описанная вами практика станет популярна, то зловреды будут сразу искать пароли в памяти и подобная атака перестанет быть адресной.
Система безопасности которая опирается на экзотичное место хранения паролей - это security through obscurity в чистом виде. Вы с таким-же успехом можете поменять местами имена переменных окружения: например назвать переменную с паролем для базы данных "REDIS_HOST", а переменную с паролем для редиса "MAIL_USERNAME". Я уверен, атакующий будет в замешательстве.
Мне очень нравится как вы предлагаете способы решения проблем. Ой, а вы же не предлагаете! Критиковать очень просто, да.
Давайте я еще раз зачем-то для вас повторю то что я уже в этом же треде писал: я понимаю все эти проблемы с файлами. Если захотят взломать конкретно мое приложение - никого не остановят ни хранение паролей в памяти, ни их шифрование, ни другие способы. Особенно если проект лежит в открытом репозитории.
Вот смотрите - было показано что для 35000 файлов из разных репозиториев можно автоматически вставить отправку переменных окружения. В переменные окружения сейчас лепят практически все секреты и они там живут весь срок работы сервиса, причем прочитать их могут даже соседние процессы.
Принимая во внимание все то что в этих комментариях тут уже писали - у вас есть предложения по теме?
Если вы сами понимаете все эти проблемы то зачем предлагаете подобные способы "защиты"? Вы можете жонглировать паролями хоть каждую секунду - переносить их из окружения в файлы, из файлов в БД, из БД в память и т.д - если код зловреда имеет те-же полномочия что и основной код - то он может прочитать пароли оттуда-же откуда его читает основной код.
На этом уровне проблема защиты принципиально не решаема, нужно исправлять проблему с зловредными библиотеками.
Мне очень нравится как вы предлагаете способы решения проблем. Ой, а вы же не предлагаете! Критиковать очень просто, да.
Если вы адепт логики "Критикуешь - предлагай", то рекомендую вам отвыкать от неё. Мне не обязательно знать решение проблемы что-бы понять что ваше решение ничего не даёт.
- Коллеги, нам нужно придумать лекарство от рака. У кого-нибудь есть предложения?
- А давайте вколим пациенту три литра физраствора и заставим его танцевать джангу!
- Что за бред? Как это поможет пациенту?
- Критиковать всегда просто, а вы попробуйте сами что-нибудь предложить.
Ок, вот вам более понятный пример.
Допустим, вам стало известно что в моем проекте используется библиотека, к которой у вас есть доступ. Пусть это будет что-то простое - например, дополнительные математические функции для статистики. Вы можете поменять какую-то часть кода на свою и если изменения небольшие - есть шанс что они проскочат формальную инспекцию и попадут в проект.
Вы не знаете про мой проект ничего - ни как используются ваши функции, ни как организован проект, ни права процесса. Вам нужно утащить все возможные пароли и секреты, хотя бы один - что вы сможете придумать? Язык - на ваш выбор из Python/Javascript/PHP. Мне не нужен код - просто идеи.
Мне не обязательно знать решение проблемы что-бы понять что ваше решение ничего не даёт.
Самый очевидный и простой вариант - получить и отправить переменные окружения. Если их нет - что тогда?
Например:
Отправить содержимое файлов в популярных каталогах: /etc, /var…
Сделать core dump и отослать его.
Каждый раз при вызове функции вычисления синуса перебирать все файлы и отправлять? Вы представляете объем файлов из папки /var на обычном сервере?
С довольно большой вероятностью у вас просто не будет прав на какие-то из этих действий, оно либо упадет, либо в системный лог запишется куча предупреждений. Скорее всего все это отловится еще на этапе сборки и тестирования.
Размер кода для всех этих действий будет не такой уже маленький, в пару незаметных строк это уже не уместить, что повысит вероятность обнаружения.
Конечно, в 1 из 1000 случаев это сработает и пришлет вам какие-то файлы..
Однако, если вы запущены в serverless-окружении - то ничего вы и не получите ни из каких файлов.
Еще раз: отказавшись от хранения секретов в переменных окружения, вы усложняете атаку на вас как минимум на порядок.
Каждый раз при вызове функции вычисления синуса перебирать все файлы и отправлять?
Это можно сделать один раз, например заиспользовав статическую переменную. Чтобы не тормозить приложение, можно делать это в отдельном треде, корутине, горутине, и т.д. (в зависимости от возможностей языка).
С довольно большой вероятностью у вас просто не будет прав на какие-то из этих действий, оно либо упадет, либо в системный лог запишется куча предупреждений.
Если приложение смогло взять значения секретов, то почему вредоносный код в том же приложении не сможет? Да, некоторые файлы не удастся прочитать, но нужные наверняка будут прочитаны с успехом. А логи врядли помогут, так как скорее всего приложение не будет логгировать попытку прочитать какой-то файл. Теоретически так можно защитится, но давайте посмотрим с практической стороны.
Однако, если вы запущены в serverless-окружении - то ничего вы и не получите ни из каких файлов.
А откуда по вашему приложение возьмет секреты (env переменные, файлы, аргументы запуска)? Ну да ладно, допустим ни один из этих вариантов не подошел. Но вот вариант с отправкой того де coredump вполне может оказаться рабочим. Не знаю, почему вы его проигнорировали.
Тянуть их с локального сервера, желательно - не имеющего доступа в большой интернет и с доступом только по белому листу.
Грубо говоря, у нас есть сервер с бизнес логикой, который должен работать с конфиденциальными данными. Мы поднимаем рядом с ним (можно даже в той же машине, просто докером) еще 1 сервер, который принимает запросы ТОЛЬКО от сетки 192.168... (или даже только с локалхоста) и отдает статичный JSON.
Сломайте)
Как вариант экзотики - сервер можно сделать SFTP и на каком-нибудь нестандартном порту.
И как это будет с ci/cd работать?
Плохо будет работать. И проблема известна, но все что рекомендуют - "проверяйте коммиты", что, на мой взгляд, довольно плохой совет сам по себе.
В CI/CD есть своя уличная магия для паролей/ключей/секретов. Надо её использовать.
Это вы про вот это вот?
Filetype variables:* Consist of a key, value and file.
* Are made available in jobs as environment variables
То есть пароль для Google Apps, нужный только маленькой части приложения, становится доступен сразу всем другим частям, в том числе и левым библиотекам, подгруженным по зависимостям. И, вспоминая node.js dependency hell, например, я не представляю как можно простым ревью кода что-то тут предотвратить.
Вижу слова и предложения но в осмысленную последовательность они не складываются, слишком сложно читать. Если бы я не знал про эту атаку раннее то думаю вообще бы ничего не понял. Можно писать как-то проще как раз для наивных разработчиков которые не разбираются в этой теме и терминах?
Это что-то вроде «таджикского вируса»?
Сканирование исходников специализированными антивирусами поможет?
Текст адверсариал атак! Емердженси выход! not rè̑ͧ̌aͨl̘̝̙̃ͤ͂̾̆ ZA̡͊͠͝LGΌ ISͮ̂҉̯͈͕̹̘̱ TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭O̚N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ
Еще и в теги го поставили, на основании того, что там про голанг и packages упоминание :)
Очень странные дела на GitHub