Новости RuCTF Quals. Admin. Разбор.

Wolong
, 05 March 2009

Тут я решил кратко рассмотреть квесты из раздела Admin на отоброчном туре RuCTF.

Задания были очень интересные, но давайте по порядку.

Админ100

Надо было настроить VPN сеть до сервера организаторов, были выделены конфиги для OpenVPN. В первый день их сервер упорно откидывал сертификат как не валидный.

Ну я, естественно, подозревал в этом злой умысле организаторов и пытался восстановить сертификат.

Начал с того, что модифицировал в сертификате по одному байту пытась подстроить его таким образом, чтобы он подошел под корневой. Естественно, ничего не вышло :) в подобных бесплодных попытках прошел первый вечер игры.

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

Зашёл из дома на сервер в университете, скачал заного конфиг, openvpn --config team22.conf --daemon... Все заработало. Ура. Надо было чтобы в сети пинговались два адреса, 10.NN.0.2 и 10.NN.0.2, а так как удаленно включить машины в универе не было никакой возможности, я, не долго думая, прилепил ещё один IP к сетевому интерфейсу VPN-тунеля.

Accepted.

Админ200

Задание поднять почтовый сервер с smtp/pop3 доступом.

К заданию прилагался файлик, в котором было три строчки, зачем-то закодированные base64. Каждая отдельно. В чем заключался гениальный замысел организаторов, я так и не понял. Возможно, подразумевалось, что не всякий узнает base64-encoded строчку по двум пробелам в конце :)

Раскодированные строчки были формата xxxx:yyyyyyy, ничем иным это, как логинами-паролями к почте не могло быть.

Запустив установленный по-дефолту на freebsd sendmail в режим прослушивания всех интерфейсов заместо одного 127.0.0.1, я быстро добавил всех трех пользователей. Поставив из портов pop3lite-сервер, повешал его в inetd.conf.

Соединившись с сервером по netcat'у, проверил его работоспособность, отправив несколько писем между пользователями и забрав их по pop3.

В задании были слова "в своем домене teamNN.ructf", я, восприняв их неправильно, просто добавил "10.22.0.2 team.ructf." к /etc/hosts.

Тыкаем проверить на странице заданий. Фэйл.

В /var/log/maillog пусто, никаких соединений от жюри.

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

На следующий день, собравшись в универе узнал о словах организаторов, что "днс-сервер находится на 10.0.0.1".

Хмм... Отгадка замаячила впереди. Делаем

# dnstracer -s 10.0.0.1 team22.ructf.
Tracing to team22[a] via 10.0.0.1, maximum of 3 retries
10.0.0.1 (10.0.0.1)
\___ ns.team22.ructf [team22.ructf] (10.22.0.3)

Ну конечно, как я сразу-то не подумал.

Запускаю named, опять-таки из дефолтной поставки freebsd на 10.22.0.3 интерфейсе, размещаю на нем зону team22.ructf, добавляю туда A и MX записи.

Проверяем через host team22.ructf 10.0.0.1, отлично, все резволвится, почта работает.

Отсылаем решение. Опять фэйл.

Зато в логах появилось сообщение об откинутом письме с ящика test@ructf, косвенно этот факт подтверждался словами Ильи Зеленчука :)

Попытки доказать жюри, что сервер не обязан отправлять почту с не своего домена успехом не увенчались. Пришлось добавить @ructf в список доверенных для отправки доменов, хранящийся в /etc/mail/access, и разрешить @team22.ructf для релея, а также отключить пару флагов из confPRIVACY_FLAGS, хранящихся в sendmail.cf.

Все это делалось путем проб и ошибок на протяжение чуть ли не пары часов :)

Наконец, заработало. :)

Acceped.

Админ300

Поднять MediaWiki.

Задание, в принципе, простое, но были свои нюансы.

Добавив на сервере пользователя wikiructf, я создал для него fastcgi-wrapper для запуска php-fcgi от имени wikiructf через suexec и добавил его исполнение для spawn-fastcgi у lighttpd.

Мало ли что на жюри заготовило, лишняя предосторожность не помешает :)

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

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

Первое делалось одним параметром в LocalSetting.php, последнее вообще было по-дефолту.

А вот со вторым возникли сложности. Если включить поддержку TeX в медиавики, то он будет отрисовывать формулы через texvc. Мне казалось, что этого достаточно, но оказалось, что в стресс-тестах от нашего уважаемого жюри, были формулы, которые texvc не по зубам.

Наконец, решение было найдено: собрав на сервере mimetex.cgi, и поместив его в /cgi-bin/mimetex.cgi, я поправил /includes/Math.php в медиавики, заменив метод отрисовки формул своим:

function renderMath($tex) {
    return '<img src="http://10.22.0.2/cgi-bin/mimetex.cgi?'.$tex.'" />';
}

После чего неразрешимые texvc формулы отлично отрисовались :)

Accepted.

Админ400

Задание состояло в том, чтобы удалить бекдор, оставленный злоумышленником в системе.

Задание начинал копать Алексей Бавшин aka AleBaStr. Он откопал там очень много интересного, и было не особо понятно что менять стоит, а что нет.

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

Алексей думаю сможет подробнее в своем отчете рассказать, что он там нашел :)

Когда я взял в руки образ, я сначала поставил туда из пакетов к slackware(для их установки не требуется особых утилит, достаточно распаковать в корень) утилиту lsof и посмотрел на сетевую активность lsof -i.

Оказалось, что сервер слушает 22 порт SSH-сервера dropbear, 23 порт телнета через inetd, и, как ни странно, порт 6666 через udevd.

Последний казался наиболее подозрительным.

Отключив на всякий случай telnet в inetd, я принялся за исследование udevd. Поставив из тех же репов slackware утилиту strace, я запустил udevd под ним.

strace -f udevd

флаг -f нужен для того, чтобы strace аттачился к потомкам, если процесс вдруг форкнется.

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

Для начала отправил на жюрейку IP 10.22.0.2 нашего (не виртуального) сервера, исследовал активность со стороны 10.0.0.1. Он пытался посдениться с портов 6666. Странно.

Перекинув 6666 порт на виртуальную машину, я, глядя на окошко с запущенным стрейсом на udevd, ещё раз отправил решение жюри.

udevd форкнулся, прочитал строку из сокета, отправил обратно, закрыл свои stdin/stdout/stderr и dup'нул их на сокет, попытался запустить /bin/ping6, который мы залепили ранее, как очень подозрительный, заменив на симлинк /bin/ping.

В оригинале он вешал /bin/bash на какой-то порт через netcat.

Запустил его, благополучно закрылся, а от жюрейки мы получили fail.

Подумав, что дело в симлинке, я удалили /bin/ping6 и снова попытался отправить решение, после попытки запуска ping6 udevd теперь грузил libc и libcrypt, пытался вызвать из них какую-то функцию и падал в segmentation fault.

До конца игры оставался час и пришлось смириться с тем, что этот квест мы не раскрыли.

Однако после окончания игры выяснилось, что для успешного выполнения квеста достаточно было удалить ping6, не исследуя udevd и не занимаясь прочими подозрительными танцами с бубном.

Обидно. Квест-то раскопали, а очков не получили.

Админ500

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

Админ500 так же разбирал Алексей, пока я с Ильей Смитов aka Blackzert исследовал sql-инъекции в ctb.

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

В папке с cgi-скриптами был обнаружен подозрительный скрипт ping.pl примерного содержания:

#!/usr/bin/perl
while(1){if(!fork()){`ping microsoft.com`;}}

скорее всего он и являлся "программой, используемой при нападении".

В /etc/hosts обнаружился заданный ip узла microsoft.com.

Но решение упорно не желало подходить.

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

После продолжительных мучений и переговоров с жюри, удалось аксептовать решение с ping.pl.

В тот момент наша комманда поднялась с четвертого места на первое.

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

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