Статья Как я получил RCE на сервере через инъекцию аргументов ExifTool

[stihl]

В этой статье я расскажу, как нашел интересную уязвимость во время bug bounty. Случай распространенный: недостаточное экранирование входных параметров. Началось все с того, что я подметил ошибку 500 при генерации PDF на сайте. Я заинтересовался проблемой, и постепенно она привела меня к RCE. Давай разберем всю атаку по шагам.
Это исследование получило третье место на Для просмотра ссылки Войди или Зарегистрируйся в категории «Пробив WEB». Соревнование ежегодно проводится компанией Awillix.
Итак, сайт выдавал «внутреннюю ошибку сервера» (500) при попытке сгенерировать PDF, если в запросе оказывался символ переноса (%0d).


Для просмотра ссылки Войди или Зарегистрируйся
Другие спецсимволы на результат никак не влияли.

За формирование PDF на основе другого PDF-файла отвечал вот этот метод API со скриншота ниже. Он записывал информацию из полученного параметра в метаданные EXIF.

Для просмотра ссылки Войди или Зарегистрируйся
Для записи метаданных разработчики решили использовать популярную тулзу Для просмотра ссылки Войди или Зарегистрируйся.

Методом проб и ошибок я обнаружил, что можно передавать произвольные аргументы в ExifTool через символ переноса строки.

Пример с аргументом description

Эта уязвимость связана со Для просмотра ссылки Войди или Зарегистрируйся ExifTool, сделанным для повышения производительности при пакетной обработке файлов. Очередной пример того, что погоня за производительностью может создавать проблемы безопасности! В этом режиме ExifTool остается запущенным между сессиями обработки разных файлов, а параметры для обработки принимает из стандартного ввода — каждый параметр на новой строке.

Позже я нашел используемую уязвимую библиотеку — это Для просмотра ссылки Войди или Зарегистрируйся, проблему можешь увидеть в строке Для просмотра ссылки Войди или Зарегистрируйся ее исходника. Связаться с автором библиотеки для уведомления о проблеме мне не удалось.

Но вернемся к уязвимости. Чего можно добиться с помощью инъекции произвольных параметров в ExifTool? После чтения Для просмотра ссылки Войди или Зарегистрируйся я понял, что можно:

• читать файлы с помощью параметров -TAG<=DATFILE;
• писать файлы (с некоторыми ограничениями) с помощью параметров -W[+|!] FMT;
• исполнять произвольный код с помощью -if EXPR.

К сожалению, в этом месте начались проблемы, поскольку символы вроде <, + или ! экранировались, и единственное, что удалось получить, — это слепое выполнение кода (пример будет дальше).

Продвигаемся​

Чтобы полноценно поэксплуатировать все возможные векторы, хотелось найти какой‑то байпас. В API приложения был еще один метод, который генерирует PDF из DOCX и добавляет EXIF-метаинформацию из заголовка этого документа. Поскольку формат DOCX — это просто архив ZIP с набором XML-файлов, можно попробовать использовать полезные нагрузки с предыдущего этапа. Например, файл docProps/core.xml содержит информацию о документе и в нем можно поменять заголовок. Пример полезной нагрузки для чтения файла:

test
-description<=/etc/passwd
С таким пейлоадом содержимое файла вернется в теге -description в документе.

Так мне удалось обойти экранирование спецсимволов.

Но есть еще одна проблема — в случае с выполнением кода результат выполнения команды никуда не возвращается (а в тестируемом сервисе не было доступа в интернет, поэтому ответ было невозможно куда‑то отправить). Возникла идея вернуть результат выполнения в значение какого‑нибудь тега, который потом прилетит в PDF-документе.

Чтобы разобраться, как это сделать, потребовалось изучить Для просмотра ссылки Войди или Зарегистрируйся ExifTool. В ход пошли пользовательские параметры: добавляем аргумент с фейковым параметром, выполняем команду и записываем результат в этот параметр, а потом итоговое значение параметра записываем в тег, который вернется в документе. Итоговая команда для выполнения команды id выглядела примерно так:

exiftool -userparam "inj=foo" -if '$$self{OPTIONS}{UserParam}{inj}=id;1' '-description<$inj' --filename sample.pdf
Из важных моментов:

• ExifTool проверяет user params до начала исполнения, поэтому их надо чем‑то инициализировать.
• Методы работы с user params не работали в контексте исполнения команд, поэтому пришлось устанавливать их напрямую через {OPTIONS}{UserParam}{inj}.
• Важно не забыть вернуть успешное значение (true) после выполнения кода.
• Записать значение в тег можно с помощью операции <.

В итоге удалось вернуть результат выполнения команды в тег description в документе.

Чтобы поделиться этими находками, я завел Для просмотра ссылки Войди или Зарегистрируйся в GTFOBins, а для желающих попробовать поэксплуатировать это подготовил Для просмотра ссылки Войди или Зарегистрируйся.

Чего удалось добиться​

В базовом варианте эксплуатации удалось получить слепое выполнение кода.

Для просмотра ссылки Войди или Зарегистрируйся
В варианте с DOCX удалось добиться чтения файлов.

Чтение /etc/passwd

Также работает выполнение кода с возвратом результатов в тег и отображением его в PDF.

Вывод команды id через PDF

Возможные риски​

Уязвимый сервис был запущен внутри Kubernetes, что при правильном использовании уменьшает количество возможных рисков. Однако они все равно есть.

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

Давай попробуем дать оценку этой уязвимости по калькулятору CVSS:

• Вектор атаки: сетевой, так как атака выполняется через HTTP-запрос.
• Сложность атаки: низкая, так как не требуется никаких специальных условий.
• Необходимые привилегии: низкие — для выполнения атаки достаточно прав обычного пользователя системы.
• Взаимодействие с пользователем: не требуется, атака выполняется без взаимодействия с пользователем.
• Область (Scope): меняется, запрос выполняется к веб‑приложению, но это дает доступ к выполнению команд на уровне операционной системы.
• Конфиденциальность (Confidentiality): низкая, с помощью выполнения команд можно получить доступ к данным других пользователей или системы, но, так как время жизни сервиса небольшое, количество данных ограничено, а из‑за настроенных сетевых ограничений найти какие‑то другие сервисы во внутренней сети не удалось.
• Целостность (Integrity): низкая, поскольку с помощью выполнения команд можно изменить данные других пользователей и системы, но раз время жизни сервиса небольшое, то количество данных ограничено.
• Доступность (Availability): высокая, так как с помощью выполнения команд можно влиять на доступность данных других пользователей либо всего сервиса.

Итоговый вектор: Для просмотра ссылки Войди или Зарегистрируйся, оценка 9,1.

Выводы​

Основная рекомендация, которая остается неизменной уже не одно десятилетие, — это экранировать пользовательский ввод. В нашем случае лучше подойдет экранирование с использованием белого списка, а не черного, так как набор символов для названия файла ограниченный.

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