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

Содержание статьи

• Продвигаемся
• Чего удалось добиться
• Возможные риски
• Выводы

В этой статье я рас­ска­жу, как нашел инте­рес­ную уяз­вимость во вре­мя bug bounty. Слу­чай рас­простра­нен­ный: недос­таточ­ное экра­ниро­вание вход­ных парамет­ров. Началось все с того, что я под­метил ошиб­ку 500 при генера­ции PDF на сай­те. Я заин­тересо­вал­ся проб­лемой, и пос­тепен­но она при­вела меня к RCE. Давай раз­берем всю ата­ку по шагам.

Это иссле­дова­ние получи­ло третье мес­то на Pentest Award 2025 в катего­рии «Про­бив WEB». Сорев­нование еже­год­но про­водит­ся ком­пани­ей Awillix.

Итак, сайт выдавал «внут­реннюю ошиб­ку сер­вера» (500) при попыт­ке сге­нери­ровать PDF, если в зап­росе ока­зывал­ся сим­вол перено­са (%0d).

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

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

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

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

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

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

Поз­же я нашел исполь­зуемую уяз­вимую биб­лиоте­ку — это go-exiftool, проб­лему можешь уви­деть в стро­ке 246 ее исходни­ка. Свя­зать­ся с авто­ром биб­лиоте­ки для уве­дом­ления о проб­леме мне не уда­лось.

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

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

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

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

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

test -description<=/etc/passwd

С таким пей­лоадом содер­жимое фай­ла вер­нется в теге -description в докумен­те.

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

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

Источник: xakep.ru