Инъекция в шаблоны

Шаблонизаторы - это инструменты, которые позволяют разработчикам/дизайнерам отделить программную логику от представления данных при создании динамических веб-страниц. Другими словами, есть код, который принимает HTTP запрос, запрашивает необходимые данные с базы данных и представляет их пользователю в одном файле, шаблонные движки отделяют представление этих данных от остальной части кода, который вычисляет их (помимо этого, популярные фреймворки и CMS также отделяют HTTP запрос от запроса в базу данных).

Инъекция в шаблон на стороне сервера (SSTI) возникает, когда шаблонизаторы отображают пользовательский ввод без его надлежащей обработки, подобно XSS. Например, в Jinja2, шаблонизаторе для языка Python, пример страницы ошибки 404, взятый у nVisium, может выглядеть так:

1 @app.errorhandler(404)

2def page_not_found(e):

3 template = ’’’{%% extends ”layout.html” %%}

4{%% block body %%}

5<div class=”center-content error”>

6<h1>Opps! That page doesn’t exist.</h1>

7<h3>%s</h3>

8</div>

9{%% endblock %%}

10’’’ % (request.url)

11return render_template_string(template), 404

Источник: (https://nvisium.com/blog/2016/03/09/exploring-ssti-in- flask-jinja2)

Здесь функция page_not_found создаёт HTML и разработчик форматирует URL как строку и отображает её пользователю. В итоге, если атакующий введёт http://foo.com/nope{{7*7}}, код разработчика отобразит это как http://foo.com/nope49, обрабатывая вставленое выражение. Опасность этой уязвимости увеличивается, когда вы передаете реальный код на Python, и он интерпретируется с помощью Jinja2.

Опасность каждой SSTI зависит от используемого движка шаблонов, и от того, какие валидации сайт применяет в отношении вводимых данных, если применяет вообще. Например, Jinja2 предоставлял доступ к произвольному файлу и RCE, движок шаблонов Rails ERB обеспечивал RCE, Liquid Engine - движок шаблонов Shopify - предоставлял доступ к ограниченному числу методов Ruby, и так далее. Демонстрация степени критичности обнаруженной вами уязвимости сильно зависит от тестирования того, что она способна позволить вам совершить. И хотя вы можете интерпретировать некий код, в итоге уязвимость может оказаться незначительной. Например, я нашел SSTI, используя код {{4+4}}, возвращавший 8. Однако, когда я использовал {{4*4}}, я получил текст {{44}}, поскольку звездочка была убрана при обработке. Поле также удаляло специальные символы вроде () и [] и позволяло вводить не более 30 символов. Все это в сочетании делало SSTI бесполезной.

Контрастом SSTI являются межсайтовые инъекции в шаблон

(Client Side Template Injections, или CSTI). Замечание: CSTI

не является стандартной аббревиатурой для уязвимости в отличии от других в этой книге, я не рекомендовал бы использовать её при написании отчетов. Эта уязвимость воз-

никает, когда приложения используют в качестве шаблонизаторов клиентские фреймворки, вроде AngularJS, вставляющие пользовательский контент на страницы без надлежащей обра-

ботки. Это очень похоже на SSTI, с единственным отличием в том, что уязвимость создается клиентским фреймворком. Тестирование на CSTI в Angular подобно тестированию в Jinja2 и включает использование {{ }} с произвольным выражением внутри.

Примеры

1. Внедрение шаблона в Uber Angular

Сложность: Высокая

Url: developer.uber.com

Ссылка на отчёт: https://hackerone.com/reports/125027 ¹

Дата отчёта: 22 марта 2016

Выплаченное вознаграждение: $3,000

Описание:

В марте 2016, Джеймс Кетл (один из разработчиков Burp Suite, инструмента рекомендованого в главе “Инструменты”) нашёл

CSTI уязвимость по URL https://developer.uber.com/docs/deeplinking?q=wrtz{{7*7}}. В соответствии с его отчетом, если вы просмотрите сформированый код страницы, вы обнаружите в нем строку wrtz49, что демонстрирует обработку введенного выражения.

Что интересно, Angular использует то, что называется sandboxing чтобы “поддерживать надлежащее разделение обязанностей приложений”. Иногда разделение предоставляется песочницей, которая разработана как элемент безопасности, призванный ограничить то, куда атакующий может получить доступ.

¹https://hackerone.com/reports/125027

Как всегда, с уважением к Angular, в документации говорится что “эта песочница не сможет остановить хакера, который имеет возможность редактировать шаблоны… [и] может быть возможным запуск произвольного JavaScript кода внутри двойных фигурных скобок…” И Джеймсу удалось сделать именно это.

Используя следующий Javascript, Джеймс получил возможность обойти песочницу Angular и выполнить произвольный

JavaScript:

1https://developer.uber.com/docs/deep-linking?q=wrtz{{(_\

2=””.sub).call.call({}[$=”constructor”].getOwnPropertyDe\

3scriptor(_.__proto__,$).value,0,”alert(1)”)()}}zzzz

Angular Injection in Uber Docs

Как он заметил, эта уязвимость можно использовать, что похитить аккаунты разработчиков и связанные с ними приложения.

Выводы

Смотрите, где используется AngularJS и проверяйте поля, где используется синтаксис Angular {{ }}. Чтобы сделать вашу жизнь проще, скачайте плагин для Firefox Wappalyzer - он покажет какое ПО используется на сайте, включая использова-

ние AngularJS.

2. Инъекция в шаблон в Uber

Сложность: Средняя

Url: riders.uber.com

Ссылка на отчёт: hackerone.com/reports/125980 ²

Дата отчёта: 25 марта 2016

Выплаченное вознаграждение: $10,000

Описание:

Когда Uber начали свою публичную BugBounty программу на HackerOne, они также включили “карту сокровищ”, которую можно найти на их сайте https://eng.uber.com/bug-bounty.

Карта содержит ряд важных поддоменов, используемые Uber, включая технологии которые используются на каждом из них. Итак, стек рассматриваемого сайта, riders.uber.com, включает в себя Python Flask и NodeJS. В отношении этой уязвимости, Orange (хакер) заметил, что Flask и Jinja2 используются здесь и протестировал синтаксис в поле “name”.

Теперь, проводя тестирование, Orange заметил, что любое изменение профиля на riders.uber.com приводят к письму и текстовому сообщению владельцу аккаунта. И так, ссылаясь на

²http://hackerone.com/reports/125980

его запись в блоге, он протестировал {{1+1}}, в результате чего на сайте обработалось выражение и вывело 2 в письме самому себе.

Далее он попробовал выполнить код {% For c in [1,2,3]%} {{c,c,c}} {% endfor %}, который запускал цикл, приводящий к следующему на странице профиля:

blog.organge.tw Uber profile after payload injection

и итоговое письмо:

blog.organge.tw Uber email after payload injection

Как вы можете видеть, текст отображается на странице профиля, но письмо выполняет код и включает его в письмо. В результате, существование уязвимости позволяет атакующему выполнять код Python.

Jinja2 пытается смягчить урон, помещая выполняемый код в песочницу, что значит, что функциональность при выполнении кода ограничена, но в некоторых случаях песочницу можно обойти. Этот отчет изначально более широко описан в посте блога (появившемся чуть раньше) и содержал несколько отличных ссылок на блог nVisium.com (да, тот же nVisium, которые выполнили Rails RCE), демонстрирующих, как обойти песочницу:

•https://nvisium.com/blog/2016/03/09/exploring-ssti-in-flask- jinja2

•https://nvisium.com/blog/2016/03/11/exploring-ssti-in-flask- jinja2-part-ii

Выводы

Выясните, какую технологию использует сайт, это часто приводит к ключевым идеям того, как вы можете это использовать. В данном случае, Flask и Jinja2 оказались отличным направлением для атаки. И, как и в случае с некоторыми XSS уязвимостями, уязвимость может не быть простой или очевидной, не забудьте проверить все места где отображается текст. В этом случае, имя профиля на одном из сайтов Uber выводилось в открытом тексте и сама уязвимость присутствовала в электронном письме.

3. Динамическое отображение в Rails

Сложность: Средняя

Url: Недоступен

Ссылка на отчёт: https://nvisium.com/blog/2016/01/26/rails-dynamic- render-to-rce-cve-2016-0752 ³

Дата отчёта: 1 февраля 2015 Выплаченное вознаграждение: Недоступно Описание:

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

³https://nvisium.com/blog/2016/01/26/rails-dynamic-render-to-rce-cve-2016-0752

Работая с Rails, разработчики имеют возможность неявно или явно контролировать, что должно отображаться на основе параметра переданого функции. Итак, разработчики могут отображать содержимое как текст, JSON, HTML, или какой-то другой файл.

С этим функционалом разработчики могут брать параметры, передавать их Rails, который и определит файл для отображе-

ния. И так, в Rails это будет выглядеть как-то так app/views/user/#{params[:tem

Nvisium использует пример ввода в панели инструментов, которая может рендериться из файла с расширением .html,

.haml, или .html.erb. Получая такой вызов, Rails будет искать в директории типы файлов, которые соответствуют соглашению Rails convention (мантра Rails - соглашения превыше конфигурации). Как всегда, когда вы говорите Rails отобразить что-то и подходящий файл не может быть найден, поиск будет про-

исходить в RAILS_ROOT/app/views, RAILS_ROOT и системной корневой директории.

Это и является частью проблемы. RAILS_ROOT ссылается на корневую папку вашего приложения, поиски там имеют смысл. А в корневой директории - нет, и это опасно.

Итак, используя это, вы можете вставить %2f%2fpasswd и Rails отобразит вам файл /etc/passwd. Жуть.

Теперь идём дальше, если вы вставите <%25%3dls%25>, интерпретатор поймёт это как <%= ls %>. В языке шаблонов erb , <%= %> означает код, который должен выполниться и отобразиться, так что здесь, команда выполнится ls, то есть здесь происходит уданенное выполнение кода (RCE).