LIMB
Вступление
Всех приветствую.
В этой статье мы рассмотрим как атаковать веб приложения на базе AEM. В частности - на каких технологиях он работает, их особенности, одну до сих пор живую CVE’ху, инструментарий и как искать таргеты для теста. Так же я немного поделючь личным опытом. Берите пиво из холодильника — и приятного чтения!
Что такое AEM
Adobe Experience Manager - довольно популярный CMS от Adobe, основанный в 2012 году. Нынче на базе AEM работает около 150к веб приложений, это примерно 0.15 % всех сайтов в интернете. Может показаться, что это мало, но во всяких bug bounty программах, доркинге через поисковики по типу shodan и при повседневном серфинге я сравнительно часто наблюдаю сайты на AEM. И каждый раз понимаю, что пентестить скучно точно не будет
Архитектура AEM
Если ты скрипткидди, какой только может что запускать инструменты по шаблону, скипай эту главу. Обычная практика - если не знаешь как работает то что тестишь, хороших результатов можно не ждать. Я советую разобраться, а то малейшие усложнения тебя остановят. Ничего лишнего, разберем только основное.
В базе лежит 3 проекта с открытым исходным кодом. С точки зрения хакера, они нужны для:
В AEM все работает на базе Java, поэтому нужен JRE/JDK для функционирования. Весь стек выше работает именно на JRE или JDK. Теперь перейдем к разбору этих 3х проектов.
Apache Felix
Apache Felix это реализация спецификации OSGi на Java. С Apache Felix можно делать много чего, этот фреймворк имеет богатый функционал, но основное его предназначение это оперирование OSGI Bundles. Что же это за бандлы такие?
Фактически это как плагины расширяющие функционал вашего AEM веб приложения. Некоторые даже идут с коробки, например - Abdera Parser. Он парсит xml документы для Java, чтобы Java мог в дальнейшем работать с ними. Бандлы можно скачать из интернета или же написать самому. Ставить их можно также разными методами. Из коробки в AEM стоит такая чудесная штука, как Apache Felix Web console. С ней оперировать ими можно намного быстрее и удобнее:
Находиться она по пути /system/console/. На скрине выше панель для управления bundle-ами. Эта панель находиться по пути /system/console/bundles
Из коробки, Apache Felix Web Consolе доступна только локально. Поэтому рандомный Вася с 8А не сможет получить доступ к этому функционалу, просто сбрутив путь и перейдя по нему. Если разработчик недостаточно знаком с практиками безопасности, он может сделать директорию доступной еще и извне, причем даже не поменяв стандартные данные для входа (admin:admin) или отключив авторизацию вовсе. Если felix console торчит наружу, можно получить доступ к управлению OSGi-бандлами, конфигурациям сервисов, журналам логов, JMX MBeans, состоянию и управлению компонентами, системным метрикам JVM, отладочным инструментам Sling, и много к чему ещё… .
Чтобы получить RCE, достатачно просто загрузить вредоносный bundle (https://github.com/0ang3el/aem-rce-bundle) и случиться магия. :magic_wand: Система скомпроментирована :sparkles:
Apache OAK JCR
Давайте еще разберемся, что такое JCR
JCR - nosql-подобная субд со структурой дерева, формат хранения данных чем-то близок с деревом файловой системы. Там находится весь контент, код и конфигурация. Ну а Apache OAK это реализация JCR. В качестве аналогии: MYSQL - это реализация стандарта SQL, а Apache OAK это реализация стандарта JCR. В AEM редактором для JCR служит CRXDE. Из коробки стоит CRXDE Lite, это удобная веб версия CRXDE. Вот так вот она выглядит:
Находиться по пути /crx/de. Стандартные логин пароль - admin:admin
По дефолту наружу она не торчит, доступна только в локальной сети. Но мы все знаем, что в мире не без идиотов)
Хранение контента: весь контент, созданный авторами (страницы, текст, изображения и т. д.), хранится как метаданные в JCR, обычно в папке /content. Но /content это в основном внутренний путь, AEM прячет эту часть пути при отдаче пользователю
/en/about.html => /content/mysite/en/about.html
Интересно, что на некоторых сайтах я видел путь /content не внутренним, а внешним. Остановимся на /content подробнее. Примерно вот так выглядит создание контента от лица автора:
Ничего удивительного, обычный визуальный редактор страниц, есть почти в каждой CMS. Но в JCR это выглядит примерно так:
То есть, после создания страницы автором, система создает в JCR свои метаданные этой страницы. Что именно создается, можно увидеть на скрине выше. Также на каждой странице есть очень важный узел как для системы, так и для нас – jcr:content
В AEM jcr:content - это узел, где хранится всё наполнение страницы. Кем создана, по какому шаблону, внутренние пути и т.д… Это нужно другим технологиям для функционирования, например для Apache Sling. Еще в метаданных иногда могут храниться важные служебные данные. Например: токены, логины, пароли.
Но есть прикол. Заключается он в том, что эту информацию при неправильной конфигурации может посмотреть любой пользователь без особых трудностей. Если добавить что-то по типу .json .tidy.json .xml и т.д… (сами пробуйте обходить фильтры) в конце ссылки, то можно получить примерно такое:
Если добавить это не к странице, а к пути, то мы сможем получить информацию о всех страницах и файлах, какие лежат по этому пути.
Иногда такое можно провернуть с узлом jcr:content, добавив в ссылку jcr:content.json (обходите фильтры, как в примере выше)
В таком случае можно получить намного больше важных данных. Я решил маленько протестить это на приватных программах, и оказалось, что много где можно встретить такие приколы. Одной VDP даже попробовал зарепортить, пофиксили на следующий день, поэтому репортить смысл есть.
С помощью этого можно эннумерейтить юзернеймы, внутренние пути, пути ко всяким интересным директориями на сайте и servlet-ы (о них позже), концепт вы поняли. Так же иногда в метаданных хранятся всякие апи ключи, логины, пароли и т.д …
Если такая штука доступна, то я бы советовал применять ее ко всем путям и файлам. Можно внезапно найти какую-то очень sensitive info
На официальном сайте AEM нам тоже говорят об этой проблеме. Возьмите во внимание.
Apache Sling
Apache Sling — это фреймворк, который по URL находит контент в JCR и обрабатывает его с помощью соответствующих servlet-ов.
Servlet - это Java-class, который обрабатывает запросы и формирует ответы.
Пример на открытом UserInfoServlet:
Конкретно тут нам выдаеться информация, о текущем пользователи и его правах. Я хотел бы сказать, что на этом эндпоинте был какой-то CORS мисконфиг или скрытый параметр, который дал что-то интересное, но увы, ничего на нем нету.
В сборе - servlet идет внутри bundle, bundle обрабатывает HTTP запросы. Думаю тут все понятно :)
Servlet-ы бывают очень полезны при пентесте, все зависит от того, какой именно вы найдете и насколько открытый он имеет функционал.
Если разбирать как работает apache sling по этапно:
На схеме показано как работает dispatcher в роли кэш-движка.
AEM Dispatcher - по сути действует как прокси сервер. Его основная задача, судя из документации, это кэшировать и доставлять контент пользователям. То есть, он отвечает за входящие запросы. Но есть одно но! Он играет важную роль в безопасности, поскольку может использоваться для принятия решений о том, какие запросы следует отклонять или разрешать, прежде чем они смогут достичь бэкенда
У вас мог возникнуть вопрос а как dispatcher и apache sling не конфликтуют друг с другом?
Все просто: если, например, контент динамический, то диспатчер не дает ответ из кэша, а пропускает запрос дальше и потом он доходит до Apache Sling. Потом уже Apache Sling его обрабатывает.
Если подытожить, то упрощенная схема выглядит примерно так (JCR внутри Author и Publish)
Это все, что вам нужно знать об архитектуре
Ебем dispatcher. Врываемся в 403 директории без стука
CVE 2016-0957
По сути, баг позволяет атакующему обойти URL-фильтры, которые должны ограждать определенные разделы CMS от нежелательного доступа. Например:
При запросе на эндпоинт /users.csv в ответе выдает статус код 403 (forbidden). Однако, если наш таргет уязвим к CVE-2016-0957, то путем несложных манипуляций можно получить доступ к эндпоинту!
Уязвимы абсолютно все версии dispatcher до 4.1.5. Давайте посмотрим на правила фильтрации диспатчера, чтобы понять, как можно обходить фильтры.
Подмечу, что /glob - это шаблон, по которому dispatcher решает, что сделать с запросом, сравнивая его с текстом запроса
Код выше уязвим, потому что диспатчер решает что делать с запросом, смотря на последние символы в URL. Правила 0011-0016 имеют для диспатчера больший приоритет, нежели путь к самой директории
example.org/system/console => 403 (в соответствии с правилом 0000)
example.org/system/console?.css => 200 (в соответствии с правилом 0011)
example.org/system/console/a.css => 200 (в соответствии с правилом 0011)
example.org/system/console;%0aa.gif => 200 (в соответствии с правилом 0012)
В 2016 году эта CVE наделала много шуму, уязвимых таргетов было ну уж очень много. Та что уж говорить, даже сам поддомен на live.com (относиться к Microsoft) был уязвим. Но microsoft не пострадал, ибо один баг баунти хантер зарепортил баг прежде чем его нашли злоумышленники. Жаль, что signout.live.com на момент 2016 был out of scope, и хакеру ничего не выплатили :melting_face:
Сейчас эта CVE остается частично актуальной по сей день и не вымерла. Где то 2 таргета из 10 уязвимы. Немного позже мы еще поговорим про нее, но с практической части
Обход через слэши
Если диспатчер настроен как-то странно, можно добавить кучу слешей в URL и обойти 403. Звучит все просто, но на деле …
/users.csv => 403 , ///users.csv => 200
/system/console => 403 , ///system///console => 200
На деле все тоже очень просто. От себя добавлю, что эта “техника” может сработать не только на AEMшных сайтах. На практике я встречал такую мисконфигурацию раза 3
Из своего опыта
Все мы прекрасно знаем, что есть куча методов обхода 403.(Напр.https://hacktricks.boitatech.com.br/pentesting/pentesting-web/403-and-401-bypasses) Разные методы, заголовки, нулевые байты, обфускация путей и так далее. Пробуйте их все. При blackbox тестировании мы не знаем, что твориться на бэкенде. Если сайт сделан на фреймворке/cms, это вовсе не значит, что часть тестов нужно отбросить. Просто запомните это как аксиому
Инструментарий для тестирования AEM
Сейчас я говорю о скриптах, какие заточены специально под наши нужды. Раскрывая тему пентеста AEM, этот инструментарий было бы просто невозможно не упомянуть https://github.com/0ang3el/aem-hacker/
aem_hacker.py - самый главный инструмент. Он анализирует сайт на наличие директорий, характерных для Adobe Experience Manager. Он не просто перебирает директории, а пытается получить доступ к ним всеми возможными способами, в частности через CVE-2016-0957
Если он что-то найдет - он выдаст вам кратко информацию о находке
python3 aem_hacker.py -u https://aem.webapp --host <ваш сервер. напр: бурп коллаборатор>
aem_discoverer.py - этому скрипту можно дать список сайтов, и он скажет какие из них работают на AEM. Даже в этом скрипте автор впихнул CVE-2016-0957 и другие техники, описанные мною выше..
Так же всем рекомендую такое расширение для браузера как wappalyzer. Отображает технологии, какие используются на вашем таргете. Постоянно ним пользуюсь.
Остальные скрипты автоматизируют PoC багов, найденных через aem_hacker.
Если вы хотите самостоятельно побрутить директории, можете использовать словарь https://github.com/clarkvoss/AEM-List/blob/main/paths . Там все то самое, что и в aem_hacker. Те самые пути и их обфусцированные версии для обхода 403
Поиск таргетов
Для наших целей гугл доркинг не годиться. Для этого советую использовать поисковые системы по типу shodan и zoomeye. Изучив синтаксис поисковых запросов, я создал несколько запросов для Shodan
http.html:/etc.clientlibs (мой любимый :rose:)
http.html:/.rum/@adobe/helix-rum-js
http.html:/content/dam/
Результатов подсыпают они довольно неплохо
Это основа запросов, если нужно, то дополняйте их сами под свои нужды. Например: исключив из ответа заголовки Server: AkamaiGHost X-Akamai-Transformed X-Akamai-Request-ID, мы снижаем вероятность попадания сайтов, защищенных Akamai WAF. Суть вы уловили
Просканив 4 сайта, мне попалось вот такое чудо:
На этом сайте букет уязвимостей, настоящий подарок для хакера. И все это из-за устаревшей версии диспатчера… Предлагаю разобрать какую-то одну находку с этого списка.
QueryBuilderJsonServlet
Позволяет делать поиск по JCR репозиторию сайта, возвращает данные про доступные узлы и их свойства в json. На скрине выше вы можете видеть, что я могу читать служебные директории и получать про них информацию. Я смог получить данные для входа от Cloud Proxy Configuration.
Иногда в свойствах можно встретить более важные данные, чем логин и пароль от локального сервиса. Выше я прикрепил скрины находок одного ресерчера.
Заключение
В этой статье мы разобрали как работает AEM и начали рассматривать как пентестить веб приложения на его базе. Я планирую посвятить минимум еще одну статью этому топику. В следующей статье планирую показать как эксплуатировать находки найденные aem_hacker на практике. Если у кого остались какие-то вопросы - пишите мне в ЛС форума. Удачи!
Всех приветствую.
В этой статье мы рассмотрим как атаковать веб приложения на базе AEM. В частности - на каких технологиях он работает, их особенности, одну до сих пор живую CVE’ху, инструментарий и как искать таргеты для теста. Так же я немного поделючь личным опытом. Берите пиво из холодильника — и приятного чтения!
Что такое AEM
Adobe Experience Manager - довольно популярный CMS от Adobe, основанный в 2012 году. Нынче на базе AEM работает около 150к веб приложений, это примерно 0.15 % всех сайтов в интернете. Может показаться, что это мало, но во всяких bug bounty программах, доркинге через поисковики по типу shodan и при повседневном серфинге я сравнительно часто наблюдаю сайты на AEM. И каждый раз понимаю, что пентестить скучно точно не будет
Архитектура AEM
Если ты скрипткидди, какой только может что запускать инструменты по шаблону, скипай эту главу. Обычная практика - если не знаешь как работает то что тестишь, хороших результатов можно не ждать. Я советую разобраться, а то малейшие усложнения тебя остановят. Ничего лишнего, разберем только основное.
В базе лежит 3 проекта с открытым исходным кодом. С точки зрения хакера, они нужны для:
- Apache Felix (Для OSGI Bundles)
- Apache OAK JCR (Для хранения данных)
- Apache Sling (Для обработки запросов, рендеринга контента)
Не удалось прогрузить медиа
В AEM все работает на базе Java, поэтому нужен JRE/JDK для функционирования. Весь стек выше работает именно на JRE или JDK. Теперь перейдем к разбору этих 3х проектов.
Apache Felix
Apache Felix это реализация спецификации OSGi на Java. С Apache Felix можно делать много чего, этот фреймворк имеет богатый функционал, но основное его предназначение это оперирование OSGI Bundles. Что же это за бандлы такие?
Фактически это как плагины расширяющие функционал вашего AEM веб приложения. Некоторые даже идут с коробки, например - Abdera Parser. Он парсит xml документы для Java, чтобы Java мог в дальнейшем работать с ними. Бандлы можно скачать из интернета или же написать самому. Ставить их можно также разными методами. Из коробки в AEM стоит такая чудесная штука, как Apache Felix Web console. С ней оперировать ими можно намного быстрее и удобнее:
Не удалось прогрузить медиа
Находиться она по пути /system/console/. На скрине выше панель для управления bundle-ами. Эта панель находиться по пути /system/console/bundles
Из коробки, Apache Felix Web Consolе доступна только локально. Поэтому рандомный Вася с 8А не сможет получить доступ к этому функционалу, просто сбрутив путь и перейдя по нему. Если разработчик недостаточно знаком с практиками безопасности, он может сделать директорию доступной еще и извне, причем даже не поменяв стандартные данные для входа (admin:admin) или отключив авторизацию вовсе. Если felix console торчит наружу, можно получить доступ к управлению OSGi-бандлами, конфигурациям сервисов, журналам логов, JMX MBeans, состоянию и управлению компонентами, системным метрикам JVM, отладочным инструментам Sling, и много к чему ещё… .
Чтобы получить RCE, достатачно просто загрузить вредоносный bundle (https://github.com/0ang3el/aem-rce-bundle) и случиться магия. :magic_wand: Система скомпроментирована :sparkles:
Apache OAK JCR
Давайте еще разберемся, что такое JCR
JCR - nosql-подобная субд со структурой дерева, формат хранения данных чем-то близок с деревом файловой системы. Там находится весь контент, код и конфигурация. Ну а Apache OAK это реализация JCR. В качестве аналогии: MYSQL - это реализация стандарта SQL, а Apache OAK это реализация стандарта JCR. В AEM редактором для JCR служит CRXDE. Из коробки стоит CRXDE Lite, это удобная веб версия CRXDE. Вот так вот она выглядит:
Не удалось прогрузить медиа
Находиться по пути /crx/de. Стандартные логин пароль - admin:admin
По дефолту наружу она не торчит, доступна только в локальной сети. Но мы все знаем, что в мире не без идиотов)
Хранение контента: весь контент, созданный авторами (страницы, текст, изображения и т. д.), хранится как метаданные в JCR, обычно в папке /content. Но /content это в основном внутренний путь, AEM прячет эту часть пути при отдаче пользователю
/en/about.html => /content/mysite/en/about.html
Интересно, что на некоторых сайтах я видел путь /content не внутренним, а внешним. Остановимся на /content подробнее. Примерно вот так выглядит создание контента от лица автора:
Не удалось прогрузить медиа
Ничего удивительного, обычный визуальный редактор страниц, есть почти в каждой CMS. Но в JCR это выглядит примерно так:
Не удалось прогрузить медиа
То есть, после создания страницы автором, система создает в JCR свои метаданные этой страницы. Что именно создается, можно увидеть на скрине выше. Также на каждой странице есть очень важный узел как для системы, так и для нас – jcr:content
Не удалось прогрузить медиа
В AEM jcr:content - это узел, где хранится всё наполнение страницы. Кем создана, по какому шаблону, внутренние пути и т.д… Это нужно другим технологиям для функционирования, например для Apache Sling. Еще в метаданных иногда могут храниться важные служебные данные. Например: токены, логины, пароли.
Но есть прикол. Заключается он в том, что эту информацию при неправильной конфигурации может посмотреть любой пользователь без особых трудностей. Если добавить что-то по типу .json .tidy.json .xml и т.д… (сами пробуйте обходить фильтры) в конце ссылки, то можно получить примерно такое:
Не удалось прогрузить медиа
Если добавить это не к странице, а к пути, то мы сможем получить информацию о всех страницах и файлах, какие лежат по этому пути.
Иногда такое можно провернуть с узлом jcr:content, добавив в ссылку jcr:content.json (обходите фильтры, как в примере выше)
Не удалось прогрузить медиа
В таком случае можно получить намного больше важных данных. Я решил маленько протестить это на приватных программах, и оказалось, что много где можно встретить такие приколы. Одной VDP даже попробовал зарепортить, пофиксили на следующий день, поэтому репортить смысл есть.
С помощью этого можно эннумерейтить юзернеймы, внутренние пути, пути ко всяким интересным директориями на сайте и servlet-ы (о них позже), концепт вы поняли. Так же иногда в метаданных хранятся всякие апи ключи, логины, пароли и т.д …
Если такая штука доступна, то я бы советовал применять ее ко всем путям и файлам. Можно внезапно найти какую-то очень sensitive info
Не удалось прогрузить медиа
На официальном сайте AEM нам тоже говорят об этой проблеме. Возьмите во внимание.
Apache Sling
Apache Sling — это фреймворк, который по URL находит контент в JCR и обрабатывает его с помощью соответствующих servlet-ов.
Servlet - это Java-class, который обрабатывает запросы и формирует ответы.
Пример на открытом UserInfoServlet:
- Юзер делает запрос на /libs/cq/security/userinfo.json
- На бэкенде запускаеться Java класс и отдает ответ
- В ответе результат выполненного класса
Не удалось прогрузить медиа
Конкретно тут нам выдаеться информация, о текущем пользователи и его правах. Я хотел бы сказать, что на этом эндпоинте был какой-то CORS мисконфиг или скрытый параметр, который дал что-то интересное, но увы, ничего на нем нету.
В сборе - servlet идет внутри bundle, bundle обрабатывает HTTP запросы. Думаю тут все понятно :)
Servlet-ы бывают очень полезны при пентесте, все зависит от того, какой именно вы найдете и насколько открытый он имеет функционал.
Если разбирать как работает apache sling по этапно:
- Пользователь делает любой HTTP Запрос
- Apache sling разбивает для себя URL на следующие части:
Не удалось прогрузить медиа
- Находит запись о ресурсе в JCR и смотрит информацию внутри узла jcr:content
- По этой информации понимает, что делать с запросом: какой выбрать servlet и т.д..
- Возвращает пользователю ответ
Не удалось прогрузить медиа
На схеме показано как работает dispatcher в роли кэш-движка.
AEM Dispatcher - по сути действует как прокси сервер. Его основная задача, судя из документации, это кэшировать и доставлять контент пользователям. То есть, он отвечает за входящие запросы. Но есть одно но! Он играет важную роль в безопасности, поскольку может использоваться для принятия решений о том, какие запросы следует отклонять или разрешать, прежде чем они смогут достичь бэкенда
У вас мог возникнуть вопрос а как dispatcher и apache sling не конфликтуют друг с другом?
Все просто: если, например, контент динамический, то диспатчер не дает ответ из кэша, а пропускает запрос дальше и потом он доходит до Apache Sling. Потом уже Apache Sling его обрабатывает.
Если подытожить, то упрощенная схема выглядит примерно так (JCR внутри Author и Publish)
Не удалось прогрузить медиа
Это все, что вам нужно знать об архитектуре
Ебем dispatcher. Врываемся в 403 директории без стука
CVE 2016-0957
По сути, баг позволяет атакующему обойти URL-фильтры, которые должны ограждать определенные разделы CMS от нежелательного доступа. Например:
При запросе на эндпоинт /users.csv в ответе выдает статус код 403 (forbidden). Однако, если наш таргет уязвим к CVE-2016-0957, то путем несложных манипуляций можно получить доступ к эндпоинту!
Уязвимы абсолютно все версии dispatcher до 4.1.5. Давайте посмотрим на правила фильтрации диспатчера, чтобы понять, как можно обходить фильтры.
Code:
/filter
{
# 0. Запрещаем всё
/0000 { /type "deny" /glob "*" }
# Публичные разделы
/0001 { /type "allow" /glob "* /content/public/*" }
/0002 { /type "allow" /glob "* /site/contact.html *" }
# Разрешённые расширения (уязвимая часть)
/0011 { /type "allow" /glob "* *.css *" }
/0012 { /type "allow" /glob "* *.gif *" }
/0013 { /type "allow" /glob "* *.png *" }
/0014 { /type "allow" /glob "* *.jpg *" }
/0015 { /type "allow" /glob "* *.jpeg *" }
/0016 { /type "allow" /glob "* *.js *" }
# API для публичных данных
/0017 { /type "allow" /glob "* /api/public/news.json *" }
/0018 { /type "allow" /glob "* /api/public/events.json *" }
/0019 { /type "allow" /glob "* /api/public/tags.json *" }
# Запрещённые приватные зоны
/0020 { /type "deny" /glob "* /content/private/*" }
/0021 { /type "deny" /glob "* /etc/workflow/*" }
/0022 { /type "deny" /glob "* /crx/*" }
/0023 { /type "deny" /glob "* /bin/*" }
/0024 { /type "deny" /glob "* /system/console/*" }
# Прочие запреты
/0025 { /type "deny" /glob "* /apps/*" }
/0026 { /type "deny" /glob "* /libs/*" }
/0027 { /type "deny" /glob "* /conf/*" }
/0038 { /type "deny" /glob "* /var/*" }
}Подмечу, что /glob - это шаблон, по которому dispatcher решает, что сделать с запросом, сравнивая его с текстом запроса
Код выше уязвим, потому что диспатчер решает что делать с запросом, смотря на последние символы в URL. Правила 0011-0016 имеют для диспатчера больший приоритет, нежели путь к самой директории
example.org/system/console => 403 (в соответствии с правилом 0000)
example.org/system/console?.css => 200 (в соответствии с правилом 0011)
example.org/system/console/a.css => 200 (в соответствии с правилом 0011)
example.org/system/console;%0aa.gif => 200 (в соответствии с правилом 0012)
В 2016 году эта CVE наделала много шуму, уязвимых таргетов было ну уж очень много. Та что уж говорить, даже сам поддомен на live.com (относиться к Microsoft) был уязвим. Но microsoft не пострадал, ибо один баг баунти хантер зарепортил баг прежде чем его нашли злоумышленники. Жаль, что signout.live.com на момент 2016 был out of scope, и хакеру ничего не выплатили :melting_face:
Не удалось прогрузить медиа
Сейчас эта CVE остается частично актуальной по сей день и не вымерла. Где то 2 таргета из 10 уязвимы. Немного позже мы еще поговорим про нее, но с практической части
Обход через слэши
Если диспатчер настроен как-то странно, можно добавить кучу слешей в URL и обойти 403. Звучит все просто, но на деле …
/users.csv => 403 , ///users.csv => 200
/system/console => 403 , ///system///console => 200
На деле все тоже очень просто. От себя добавлю, что эта “техника” может сработать не только на AEMшных сайтах. На практике я встречал такую мисконфигурацию раза 3
Из своего опыта
Все мы прекрасно знаем, что есть куча методов обхода 403.(Напр.https://hacktricks.boitatech.com.br/pentesting/pentesting-web/403-and-401-bypasses) Разные методы, заголовки, нулевые байты, обфускация путей и так далее. Пробуйте их все. При blackbox тестировании мы не знаем, что твориться на бэкенде. Если сайт сделан на фреймворке/cms, это вовсе не значит, что часть тестов нужно отбросить. Просто запомните это как аксиому
CMS вовсе не признак, что на сайте нету дырок!!!
Инструментарий для тестирования AEM
Сейчас я говорю о скриптах, какие заточены специально под наши нужды. Раскрывая тему пентеста AEM, этот инструментарий было бы просто невозможно не упомянуть https://github.com/0ang3el/aem-hacker/
Не удалось прогрузить медиа
aem_hacker.py - самый главный инструмент. Он анализирует сайт на наличие директорий, характерных для Adobe Experience Manager. Он не просто перебирает директории, а пытается получить доступ к ним всеми возможными способами, в частности через CVE-2016-0957
Не удалось прогрузить медиа
Если он что-то найдет - он выдаст вам кратко информацию о находке
Не удалось прогрузить медиа
python3 aem_hacker.py -u https://aem.webapp --host <ваш сервер. напр: бурп коллаборатор>
aem_discoverer.py - этому скрипту можно дать список сайтов, и он скажет какие из них работают на AEM. Даже в этом скрипте автор впихнул CVE-2016-0957 и другие техники, описанные мною выше..
Так же всем рекомендую такое расширение для браузера как wappalyzer. Отображает технологии, какие используются на вашем таргете. Постоянно ним пользуюсь.
Не удалось прогрузить медиа
Остальные скрипты автоматизируют PoC багов, найденных через aem_hacker.
Не удалось прогрузить медиа
Если вы хотите самостоятельно побрутить директории, можете использовать словарь https://github.com/clarkvoss/AEM-List/blob/main/paths . Там все то самое, что и в aem_hacker. Те самые пути и их обфусцированные версии для обхода 403
Поиск таргетов
Для наших целей гугл доркинг не годиться. Для этого советую использовать поисковые системы по типу shodan и zoomeye. Изучив синтаксис поисковых запросов, я создал несколько запросов для Shodan
http.html:/etc.clientlibs (мой любимый :rose:)
http.html:/.rum/@adobe/helix-rum-js
http.html:/content/dam/
Результатов подсыпают они довольно неплохо
Не удалось прогрузить медиа
Это основа запросов, если нужно, то дополняйте их сами под свои нужды. Например: исключив из ответа заголовки Server: AkamaiGHost X-Akamai-Transformed X-Akamai-Request-ID, мы снижаем вероятность попадания сайтов, защищенных Akamai WAF. Суть вы уловили
Просканив 4 сайта, мне попалось вот такое чудо:
Не удалось прогрузить медиа
На этом сайте букет уязвимостей, настоящий подарок для хакера. И все это из-за устаревшей версии диспатчера… Предлагаю разобрать какую-то одну находку с этого списка.
QueryBuilderJsonServlet
Не удалось прогрузить медиа
Позволяет делать поиск по JCR репозиторию сайта, возвращает данные про доступные узлы и их свойства в json. На скрине выше вы можете видеть, что я могу читать служебные директории и получать про них информацию. Я смог получить данные для входа от Cloud Proxy Configuration.
Не удалось прогрузить медиа
Не удалось прогрузить медиа
Иногда в свойствах можно встретить более важные данные, чем логин и пароль от локального сервиса. Выше я прикрепил скрины находок одного ресерчера.
Заключение
В этой статье мы разобрали как работает AEM и начали рассматривать как пентестить веб приложения на его базе. Я планирую посвятить минимум еще одну статью этому топику. В следующей статье планирую показать как эксплуатировать находки найденные aem_hacker на практике. Если у кого остались какие-то вопросы - пишите мне в ЛС форума. Удачи!
👍28
😁3
👏6
🤔3