asciira, betagost, cmap1, cmap2, shout, webdept, webdeptcrypto, well: writeups

Author: nsychev

tasks/asciirsa/WRITEUP.md

@@ -1,3 +1,15 @@
 # ASCII-RSA: Write-up
 
+Перед нами ещё одна странная реализация RSA. Странно в ней абсолютно всё — побуквенное шифрование, модуль 256 (очевидно не состоящий из двух простых делителей), непонятное умножение символов.
+
+Пойдём самым простым путём: давайте просто посмотрим на все символы с кодами от 32 до 126 (это все «печатаемые символы» — пробел, цифры, буквы, подчёркивание и много чего ещё) и узнаем, во что зашифруется каждый символ.
+
+Для этого можно, например, в текстовый файл `flag.txt` строку
+
+```
+ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~
+```
+
+и зашифровать её. Теперь осталось найти в полученном файле символы из нашего зашифрованного флага и сопоставить.
+
 Флаг: **ugra_dont_roll_asciirsa_crypto_4b72d642e66ced42**

tasks/betagost/WRITEUP.md

@@ -1,3 +1,24 @@
 # ГОСТ 34.13-2022: Write-up
 
+Итак, в этом задании флаг просто ксорится с некой ключевой последовательностью, которую выдаёт класс `Stream`.
+
+Известно, что функция `XOR` обладает простым свойством — `a xor b xor b = a`. Это означает, что таск решается предельно просто — запустим тот же скрипт, но для зашифрованного файла — и файл расшифруется. Но не тут-то было.
+
+Что ж, воспользуемся предложенным сайтом. Попробовав зашифровать одно и то же сообщение несколько раз видим, как шифротекст меняется. Дело в том, что переменная `value` — глобальная — и меняется после каждого шифрования.
+
+Алгоритм, по которому генерируется ключевая последовательность, довольно стандартный и известный. Называется он _LFSR_, или регистр сдвига с линейной обратной связью.
+
+Значение `value` в нём и обозначает этот самый регистр. Для решения задания даже необязательно разбираться, как работает алгоритм. Достаточно заметить две вещи:
+
+* `value` никогда не превысит $2^{18}$
+* следующий бит и новое значение `value` зависит только от текущего `value`
+
+Следовательно, если значение `value` совпадет с каким-то из предыдущих, вся дальнейшая последовательность `value` будет циклическим повтором. При этом `value` гарантированно хотя бы раз за $2^{18}$ шагов повторится — потому что всего различных возможных чисел у нас $2^{18}$.
+
+> Интересно то, что для данного секрета длина такого цикла — 262143 — максимально возможная. Это связано с тем, что под неприметным числом 174807 скрывается многочлен $x^{17} + x{15} + x^{13} + x^{11} + x^9 + x^7 + x^6 + x^4 + x^2 + x + 1$ — это примитивный многочлен степени 17.
+
+Осталось перебрать все эти 262143 возможных значений `value` и для каждого узнать, не начинается ли флаг с `ugra`.
+
+[Код для перебора](exploit.py)
+
 Флаг: **ugra_lfsr_is_so_cyclic_dbf6deae053a5be4**

tasks/betagost/exploit.py

@@ -35,13 +35,8 @@ def encrypt(plaintext: bytes) -> bytes:
 with open("flag.enc", "rb") as flag_file:
     encrypted = flag_file.read()
 
-for offset in range(131071):
-    value = Stream.value
-
-    if encrypt(PREFIX) == encrypted[:len(PREFIX)]:
-        Stream.value = value
-        print(offset, encrypt(encrypted))
-
+for value in range(1, 262144): # value == 0 is impossible
     Stream.value = value
-    Stream.bit()
 
+    if encrypt(PREFIX) == encrypted[:len(PREFIX)]:
+        print(value, PREFIX + encrypt(encrypted[len(PREFIX):]))

tasks/cmap/README.md

@@ -10,6 +10,8 @@ ppc 150, @nsychev
 > 
 > _Примечание._ В этом задании два флага.
 >
+> _Примечание 2 (добавлено 28 февраля в 17:32)._ не все программы для просмотра PDF показывают содержимое файла корректно. Вы должны увидеть много букв на каждой странице. Если вы их не видите — например, в Chromium, попробуйте другую программу.
+>
 > _flag.pdf_
 
 [Write-up](WRITEUP.cmap1.md)

tasks/cmap/WRITEUP.cmap1.md

@@ -1,3 +1,11 @@
 # cmap I: Write-up
 
+В файле видим длинный текст из английских заглавных букв. Однако, при копировании мы получаем некую последовательность нечитаемых символов.
+
+Название таска нас отсылает к библиотеке [для языка вёрстки LaTeX](https://www.ctan.org/tex-archive/macros/latex/contrib/cmap), которая делала получаемые PDF-файлы «искабельными и копируемыми». Нам это, правда, никак не помогает.
+
+Что ж, в файле всего 32 различных символа. Можно заметить, что одинаковые буквы в тексте превращаются в одинаковые символы при копировании. Найдём руками соответствие букв и символов и заменим.
+
+Получаем файл в кодировке base32, после декодирования видим PNG-картинку с флагом.
+
 Флаг: **ugra_you_do_not_need_usepackage_cmap_4228eae1c90b**

tasks/cmap/WRITEUP.cmap2.md

@@ -1,3 +1,11 @@
 # cmap II: Write-up
 
+Цель второго таска не ясна. Но нам явно говорят, что где-то в файле есть скрытая пометка. Можно начать исследование от первого таска — в нём была проблема со шрифтом, в нём и попробуем разобраться.
+
+Воспользуемся любой утилитой для извлечения шрифта из PDF. Исследуем все символы в полученном шрифте. На случайных позициях видим заглавные буквы и цифры — ровно эти позиции и нужно было найти в первой части задания (возможно, так даже проще их находить).
+
+Но наше внимание в этот раз привлекают символы с кодами больше 65536 — зачем они нужны? Присматриваемся в глифы (рисунки символов) и видим, что они последовательно составляют флаг.
+
+Это и есть та самая метка.
+
 Флаг: **ugra_oh_what_a_weird_font_here_017272589fec**

tasks/shout/WRITEUP.md

@@ -1,3 +1,42 @@
 # Поорите: Write-up
 
-Флаг: **ugra_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa_690868a2aeaff4c1**
+Перед нами задание на бинарную эксплуатацию. Посмотрим, что оно умеет, не открывая ни бинарный файл, ни дебаггер.
+
+Нередко в таких заданиях бывает переполнение, и, чтобы забить нужное количество байт, обычно используют буквы `A`. Возможно, на это нам и намекают, когда просят поорать. Что ж, попробуем: введём 100 букв `A`:
+
+```bash
+$ ./shout 
+Shout here: 
+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+Too weak, try again.
+```
+
+Попробуем ввести больше букв. Например, 2000:
+
+```
+Too weak, try again.
+Segmentation fault (core dumped)
+```
+
+На этот раз приложение упало с ошибкой. Это означает, что уязвимость всё-таки есть — и эта уязвимость — переполнение стека. Уязвимость заключается в том, что приложение неправильно валидирует данные, хранящие на стеке приложения: мы можем ввести больше данных, чем есть места — в этом случае приложение их просто начнёт писать дальше, затирая какие-то важные данные.
+
+Всё-таки дальше без изучения приложения не обойтись. Откроем его в IDA или Cutter и посмотрим, что внутри. Сразу замечаем какую-то непонятную секцию `.flags`, местоположение которой, скажем прямо, удивляет — она находится через 532 МБ от начала приложения.
+
+В этой секции мы находим единственную функцию `print_flag` по адресу `0x21414141`, которая открывает файл `flag.txt` и печатает его. Казалось бы, вот и решение — но незадача: эта функция нигде в коде не вызывается.
+
+Теперь нужно понять, как можно использовать найденную уязвимость для вызова функции. На самом деле, стек вызовов выглядит примерно так:
+
+```
+... | shout                                 | main                                  | ...
+... | local vars | ebp | return addr | args | local vars | ebp | return addr | args | ...
+```
+
+Таким образом, если мы затрём данные после локальной переменной в функции `shout`, мы сможем переписать `ebp`, `return addr` и всё, что находится дальше. А что произойдёт потом? А потом программа успешно дойдёт до конца функции и попробует вернуться в «предыдущую функцию» по адресу, который лежит в return addr. И, если нам удастся подставить сюда адрес нашей функции `print_flag`, то мы победим.
+
+Следующая проблема — формат ввода. Как известно, мы вводим в программу буквы, а адрес перехода состоит из цифр. Что же делать? Тут всё очень просто — мы вводим те символы, шестнадцатеричные коды которых соответствуют байтам нашего адреса. Есть одно маленькое «но» — в Linux порядок байт little endian, поэтому адрес нужно вводить «наоборот». Числу `41` соответствует символ `A`, а числу `21` — символ `!`. Получается, наш адрес мы будем вводить как `AAA!`.
+
+Наконец, нужно понять, сколько байт нам нужно всего. Можно просто перебрать. Проще — локально. Создадим файл `flag.txt` и будем запускать наш файл с разным количеством `A`. Можно отреверсить этот бинарный файл и узнать, сколько байт выделяется на стеке.
+
+В итоге мы получаем эксплойт — 1039 букв `A` и восклицательный знак. Ровно так нужно проорать, чтобы получить флаг.
+
+Флаг: **ugra_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA_690868a2aeaff4c1**

tasks/webdept/WRITEUP.webdept.md

@@ -1,3 +1,28 @@
 # Веб-департамент: Write-up
 
+Сначала зайдём на сайт с помощью любого приложения для двухфакторной аутентификации — например, Google Authenticator или Authy. На сайте есть две страницы — одна позволяет запросить содержимое любого сайта, а вторая — отправить сообщение.
+
+Обращаем внимание, что все ответы от сервера сопровождаются заголовком `X-Backend: 10.13.37.159`. Это намекает нам на атаку SSRF (Server-side request forgery) — мы можем получить доступ к внутренним ресурсам.
+
+Начнём с сети `/24` и популярных веб-портов — например, с `:80`. В локальной сети обнаруживаем хост `http://10.13.37.62` — по этому адресу отдаётся некий JSON.
+
+Изучая его, приходим к выводу, что это схема API — доступных эндпоинтов на этом сервере и формата запросов. Всего видим два эндпоинта:
+
+* `GET /request-otp?username=...`
+* `POST /check-otp` `username=...&code=...`
+
+POST-запросы мы делать не можем, попробуем GET с именем пользователя `admin`: `http://10.13.37.62/request-otp?username=admin`. Получаем непонятный текст, но видим в нём `PNG`. Вероятно, это такая же картинка с кодом, что была у `andy77`.
+
+`\x89` выглядит как байт с хекс-кодом 89. Очень похоже на то, как Python кодирует бинарные строки. И действительно, даже куки намекают на использование aiohttp — это веб-фреймворк для Python.
+
+Самый простой способ получить картинку — обернуть это всё в `b"..."` — это байтовая строка, и вывести полученную переменную в файл. Код, кстати, можно скопировать из какого-нибудь таска на криптографию:
+
+```python3
+image = b"\x89PNG\r\n\x1a\n\x00\x00\x00\rIHDR...\x00IEND\xaeB`\x82"
+with open("image.png", "wb") as f:
+    f.write(image)
+```
+
+Открываем картинку, видим QR-код администратора. Входим, получаем флаг.
+
 Флаг: **ugra_isolate_your_public_hosts_d611010a81dd**

tasks/webdept/WRITEUP.webdeptcrypto.md

@@ -1,3 +1,19 @@
 # Крипто-департамент: Write-up
 
+После решения задания [«Веб-департамент»](WRITEUP.webdept.md) мы авторизованы в системе под администратором. Кроме флага, мы также узнаём, что есть и вторая сеть — 10.13.38.0/24. Просканировав все порты 80 и в ней, находим странную веб-страницу для печати сообщений — 10.13.38.116.
+
+Но какие же сообщения можно расшифровать? Вспоминаем о второй части сайта — сервисе с жалобами. Возвращаясь к ней уже с повышенными привилегиями, мы можем увидеть список последних жалоб. Но в зашифрованном виде.
+
+Попробуем напечатать любую жалобу — и, действительно, сайт нам сообщает о её печати на принтере. Если же мы отправим абракадабру, то ничего не напечатается: нам скажут, что произошла ошибка.
+
+> Обратите внимание: сама форма на загруженной странице работать и не будет — надо вручную дописывать `enc` именно в URL запроса.
+
+Вспоминаем про AES-CBC, упомянутый ранее. Атака, которая подойдёт нам в этом случае — [Padding Oracle](https://robertheaton.com/2013/07/29/padding-oracle-attack/) — она позволяет всего лишь по сообщению о корректном или некорректном шифротексте получить флаг.
+
+Посмотрим на формат зашифрованных сообщений. Независимо от длины сообщения, часть до `|` — base64 от 16 байт данных, а справа — base64 данных длины чуть большей того текста, что мы отправляем — если быть точным, длина округляется до 16 байт вверх.
+
+Предпологаем, что слева от `|` находится IV, а справа — шифротекст, заполненный паддингом. Самый распространённый формат паддингов — PKCS7; предположим, что он и использовался.
+
+[Код эксплойта](exploit.py)
+
 Флаг: **ugra_do_not_ever_use_cbc_420d096df213**