Взломай Атлантиду! Распутываем загадки RuCTFE 2016 с командой создателей

Спецсимволы не экранируются, поэтому в parser.signature можно вставить подзапрос. Чтобы это сделать, надо написать небольшую программу на C++:

После этого собираем бинарник:

и генерируем символы:

Файл символов just_crash.sym имеет текстовый формат, так что его легко модифицировать. Так как наша программа падает в main(), сигнатура у отчета будет main. Откроем файл just_crash.sym и заменим все слова main на main',(SELECT guid from reports))--. Зальем с помощью первой уязвимости файл символов по пути (сервис любезно создаст все нужные папки)

Остается вести себя, как проверяющая система: запускать каждый раунд just_crash, паковать сгенерированный мини-дамп и отправлять сервису. Если зайти на страницу отчета, то в поле Remote IP мы увидим результат инъекции. Можно использовать имя submarine_internal, чтобы мимикрировать под проверяющую систему. Более того, когда первую уязвимость закроют, эта останется работоспособной, пока ее не пофиксят.

Павел PAHAZ Блинов

Роман RX00 Быков

AtlaBlog — атлантийский блог для научного сообщества (кодовое название Cross Social Science). Написан на языке Python с использованием веб-фреймворка Sanic. Регистрация в блоге открытая, публиковать посты и писать комментарии может любой зарегистрированный пользователь, модерация отсутствует. К комментариям и постам можно прикреплять произвольные документы.

При прикреплении файла к посту или комментарию для него генерировалось случайное имя — UUID, при этом расширение оставалось нетронутым. При выводе полного имени файла <UUID>.* расширение не экранировалось, то есть блог был подвержен хранимой XSS-атаке на пользователя. Самой сложной задачей для участников было понять, что XSS позволял получать флаги. Обычно на attack-defence CTF чекеры не исполняют JavaScript из-за трудностей развертывания соответствующей инфраструктуры. Представь: участвуют сотни команд, и для каждой команды нужно раз в минуту запускать полноценный браузер, причем хорошо изолированный — иначе можно ждать атак на проверяющую систему.

Обнаружить, что в качестве чекера выступает полноценный браузер, можно было по регулярным запросам к статике (JS, CSS). Дополнительную сложность составляло наличие в ответе сервера HTTP-заголовка Content-Security-Policy: default-src 'self' 'unsafe-inline'. Из-за этого не получалось публиковать флаги на внешние ресурсы, и нужно было сформировать запрос от имени пользователя и сохранять его приватные данные в существующий пост.

Чекер написан на языке Python, с использованием модуля Selenium (драйвер — PhantomJS). Сначала чекер создавал нового пользователя и помещал флаг в приватное поле с почтовым адресом. Затем публиковал пост, проверял работоспособность поллинга новых постов и прикреплял произвольный файл к уже созданному посту.

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

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

Кодировать расширение прикрепляемых файлов html.escape(extension).

Константин KOST Плотников

Сервис поиска попутчиков в мире Атлантиды. Написан на языке Swift 3.

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

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

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

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

Виктор KRAIT Дворецкий

Вот как выглядит главная страница сервиса Weather, которая показывает прогноз погоды в Атлантиде:

Прогноз делается на основе данных, которые присылает проверяющая система на специальный TCP-порт 16761. Каждое сообщение состоит из двенадцатисимвольного ключа и значения длиной 32 символа. Каждая команда могла подключиться к сервису любой другой команды и положить туда свои данные. Через этот же порт данные можно было получить обратно, зная ключ. На том же порте можно было получить текстовую версию главной страницы.

В текстовой версии видно поле «Signature: » (в веб-версии оно тоже есть, но на скриншоте его не видно). Это магическое значение, которое генерируется на основе текста запроса и проверяется чекером, чтобы сервис нельзя было заменить на произвольное хранилище key-value.

Сервис состоит из единственного маленького 32-битного ELF’а weather, скомпилированного с PIE (position-independent executable). Все уязвимости в нем эксплуатируются несложно и хорошо известными методами, чтобы даже неопытные реверсеры могли почувствовать свою силу и стащить несколько флагов.

Первая точка входа для атакующего — переполнение буфера в запросе к текстовой версии прогноза.

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

Первым делом понадобится узнать адреса: бинарник является PIE, поэтому загружается по случайному базовому адресу. Адрес стека тоже рандомизирован.

Послав запрос с достаточным количеством %p, попадающих в шаблон, можно получить как адрес образа, так и адрес стека. Рассмотрим, как получить адрес, по которому загрузился бинарник.

В обычной ситуации шаблон заполняется значениями температуры и строками с описанием погоды. Таким образом, второй аргумент sprintf и заодно второй int32 на стеке — это сегодняшняя погода. Перезаписав шаблон строкой вида %p %p, мы узнаем указатель на одну из строк ‘clear’, ‘rain’ и так далее. Посмотрев, как эти строки расположены в секции .rodata, можно заметить, что их адреса отличаются только последним байтом.

Рандомизация базового адреса это не меняет, так что можно узнать адрес строки ‘clear’, просто заменив последний байт адреса, который мы получили, на 0x60. Теперь у нас есть точка отсчета, от которой можно вычислить адрес чего угодно в образе бинарника. Это понадобится для эксплуатации всех уязвимостей.

Пореверсив бинарник, можно заметить, что прогноз погоды строится на основе последних шести флагов, которые для этой цели отложены в отдельное место (назовем его lastValues) в секции данных.

Сами строки не дублируются, там лежат лишь указатели на них.

Теперь надо научиться читать данные по произвольному адресу. Заметим, что первые 4 байта запроса оказываются на стеке. Чтобы добраться до этого места, надо сдвинуться на 57 4 байта по стеку от вызова sprintf. Осталось только построить запрос, который будет читать значение по произвольному указателю с помощью %s: ` + + ‘%p’ 57 + ‘%s’`.

Итак, чтобы прочитать шесть последних флагов, нужно:

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

Каждый узел в дереве — массив из 26 указателей (в ключе можно использовать только строчные буквы от a до z). В обычных узлах указатели ссылаются на следующие узлы, а в последних узлах — на сами строки с данными.

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

Ты мог заметить, что в бинарнике импортирована функция system. Есть несколько способов ей воспользоваться. Рассмотрим один из них, использующий уязвимость в функции подсчета подписи.

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

Здесь есть ошибка, которая позволяет перезаписать 24 лишних значения int32 на стеке. Но перезаписать не произвольными данными, а путем прибавления и умножения на маленькие числа (байты строки запроса). Глядя на код, ты можешь заметить, что байты, меньшие 16 (знаково!), обрабатываются особым образом: значения на стеке умножаются на положительные байты и складываются с абсолютными значениями отрицательных байтов.

Идея в том, чтобы подменить адрес возврата из wt_sign на адрес функции system и подменить значение по адресу <return address location> + 8, которое будет аргументом функции system, на адрес буфера с запросом. Туда можно написать любые команды, которые захочется выполнить.

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

WWW

• Код эксплоита с тремя режимами работы

 RuCTFE на «Хакере»

Часть тасков перед соревнованиями RuCTFE размещалась на сайте «Хакера». По легенде, чтобы дешифровать флаги, исследователю нужно было найти пять параметров для шифровальной машины «Энигма». Возможно, ты помнишь, что в какой-то период на сайте вверху появилась плашка, при клике на которую тебя перебрасывало на статью «Погружение в крипту. Часть 1: как работают самые известные шифры в истории?». Именно в этой статье мы их и спрятали. Поскольку это была «затравка» к основному CTF-таску, мы не ставили целью проэксплуатировать реальные уязвимости: задачи были на смекалку и внимательность исследователя.

 Как получить доступ к заданиям

Чтобы активировать таски, в URL статьи нужно было дописать GET-параметр /?ctf=. Значение параметра и регистр неважны. По сути, любой параметр, содержавший в себе подстроку ctf, активировал таски: например, ['/?RuCTF=', '/?Ctf=', '/?RUctfE=']. Итоговый URL для активации выглядел как https://xakep.ru/2015/12/24/crypto-part1/" target="_blank?RuCTF=.

Чтобы до этого догадаться, нужно было заглянуть в исходный код плашки со ссылкой, которая висела все это время на сайте: она содержала data-атрибут data-hint='/?RuCTFE'. Дополнительно в Твиттере запостили подсказку: Hint0: Add ?RuCTFE=2016 (could be obtained from data-hint attribute of welcome banner).

Тот самый хинт: somehting был заменен на RuCTFE, а потом и просто на ctf

Флаг № 1: в таблице шифра Цезаря

• Оригинальный флаг: {'Type':'M3'}
• Base64: eydUeXBlJzonTTMnfQ==
• Цезарь (сдвиг +3): hbgXhAEoMcrqWWPqiT

В статье в разделе про шифр Цезаря есть такой текст:

…Это количество позиций называется ключом. При ключе, равном трем, этот метод называется шифром Цезаря. Император использовал его для секретной переписки. Для того чтобы зашифровать сообщение, нужно построить таблицу подстановок.

При добавлении GET-параметра к URL статьи появлялось дополнительное предложение:

Император использовал его для секретной переписки. >>Выглядел он примерно так: hbgXhAEoMcrqWWPqiT.<< Для того чтобы зашифровать сообщение, нужно построить таблицу подстановок.

Кусок текста, в котором появлялось дополнительное предложение с шифртекстом

Кусочек hbgXhAEoMcrqWWPqiT явно выглядел подозрительно. Ну а раз он в абзаце про шифр Цезаря, попробуем сдвинуть обратно на три позиции этот шифртекст. Получаем eydUeXBlJzonTTMnfQ==. Несложно догадаться, что это Base64. Декодируем любым онлайн-декодером (я использовал первый попавшийся) и получаем {'Type':'M3'}. Это и есть первый параметр «Энигмы»!

Декодируем шифртекст первого параметра
Флаг № 2: в response-хедерах

• Оригинальный флаг: {'Umkehrwalze':'C'}
• Base64: eydVbWtlaHJ3YWx6ZSc6J0MnfQ==
• inverse: QfnM0J6cSZ6xWY3JHaltWbVdye

В «режиме CTF» сервер отдавал один необычный заголовок: X-Ructf. Значением его была строка QfnM0J6cSZ6xWY3JHaltWbVdye. Достаточно было просто перевернуть строку в обратном порядке, чтобы получить Base64 (последние == некритичны). Ну а дальше опять вставляем в Base64-декодер и получаем {'Umkehrwalze':'C'}.

Декодированный шифртекст второго параметра

Мы получили второй параметр!

Флаг № 3: в изображении

• Оригинальный флаг: {'Walzenlage':'III-I-II'}
• Base64: eydXYWx6ZW5sYWdlJzonSUlJLUktSUknfQ==
• inverse: QfnkUStkULJlUSnozJldWYs5WZ6xWYXdye

В третьем задании на страницу подгружалась картинка ructf.gif, на которой написано QfnkUStkULJlUSnozJldWYs5WZ6xWYXdye. Картинка была невидима на странице, так как для нее были прописаны CSS-стили:

{ position: absolute; topleft: -over9000; }

Узнать о ней (и не только о ней) можно было очень легко:

curl URL | grep 'ctf'

Но тут все не так просто. При открытии картинки в браузере исследователя ждала белая страница. Дело в том, что код был написан белым шрифтом на прозрачном фоне. Чтобы увидеть скрытый текст, можно было подменить цвет фона страницы в Chrome Developer Tools, скажем, на черный:

body{background-color: #000;} Белый текст зашифрованного параметра на прозрачном фоне

Ну а дальше опять реверс, Base64, и готово: {'Walzenlage':'III-I-II'}. Мы получили третий параметр!

Флаг № 4: GIF-картинка со спрятанным внутри ZIP-архивом

• Оригинальный флаг: {'Ringstellung':'E F T'}
• Base64: eydSaW5nc3RlbGx1bmcnOidFIEYgVCd9
• inverse: 9dCVgYEIFdiOncmb1xGblR3cn5WaSdye

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

Изображение «Энигмы», которое отдавалось по умолчанию

При обычном открытии статьи Wget’ом или curl’ом отдавалась настоящая картинка. Но на сайте «Хакера» мы используем lazy load, «ленивую» подгрузку картинок, чтобы сократить время загрузки. Так вот, если открыть страницу в браузере, вместо https://xakep.ru/wp-content/uploads/2015/12/1450870121_509b_enigma.png скриптами подгружалась другая GIF-картинка, на вид точь-в-точь как первая.

INFO

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

Трюк состоял в следующем: для GIF-изображения неважно, что находится в конце файла, главное, чтобы основной набор данных изображения в файле был целый. А для ZIP-архивов все равно, что стоит в начале, архиватор просто пропустит непонятные «мусорные» данные и начнет разархивацию с первых «знакомых» байтов. Именно поэтому можно было просто склеить GIF-картинку и ZIP-файл в одно целое, и получившийся файл был одновременно и валидной гифкой, и рабочим ZIP-архивом.

Просто скачиваем картинку и натравливаем на нее unzip.

Разархивируем unzip’ом картинку со склеенным архивом. Архиватор предупреждает о странных байтах в начале архива (наша гифка)

В архиве был файл data.txt, в нем и содержался искомый четвертый параметр 9dCVgYEIFdiOncmb1xGblR3cn5WaSdye (после дешифровки {'Ringstellung':'E F T'}).

Флаг № 5: в JSFuck

• Оригинальный флаг: {'Grungstellung':'C U R'}
• Base64: eydHcnVuZ3N0ZWxsdW5nJzonQyBVIFInfQ==
• inverse: QfnIFIVByQnozJn5WdsxWZ0N3ZuVncHdye

В исходном коде страницы статьи на xakep.ru в конце текста можно было увидеть странный <div> c JSFuck-кодом (разумеется, c display:none).

Скрытый div, который содержал JSFuck, упакованный обфускатором и затем явно испорченный

Если пробовать просто выполнить его в консоли браузера, вылезала ошибка. Сам JSFuck-код был ко всему прочему запако

Источник: xakep.ru