0) Скачиваем свежие сорцы.

$ svn co https://svn.ntop.org/svn/ntop/trunk/PF_RING/ && cd ./PF_RING/kernel

1) Используем debhelper для создания CDBS(Common Debian Build System) пакета.

$ dh_make --cdbs --copyright gpl --native --packagename pf-ring-dkms_4.7.1

Эта команда создаст директорию ./debian в которой стандартный набор файлов.

$ ls ./debian/
changelog  copyright           emacsen-remove.ex   manpage.1.ex     menu.ex             pf-ring.doc-base.EX  preinst.ex  README.Debian  source
compat     docs                emacsen-startup.ex  manpage.sgml.ex  pf-ring.cron.d.ex   postinst.ex          prerm.ex    README.source  watch.ex
control    emacsen-install.ex  init.d.ex           manpage.xml.ex   pf-ring.default.ex  postrm.ex            README      rules

Идем в ./debian и начинаем редактировать файлы

$ cd ./debian

2) Конфиг для DKMS должен называться dkms.conf и определять директивы DKMS о том, как собрать модуль (или несколько). Названия переменных говорят сами за себя.

PACKAGE_VERSION="4.7.1"
PACKAGE_NAME="pf-ring"
CLEAN="make clean"
BUILT_MODULE_NAME[0]="pf_ring"
BUILT_MODULE_LOCATION[0]="./"
DEST_MODULE_LOCATION[0]="/kernel/net"
MAKE[1]="make"
AUTOINSTALL="yes"

3) changelog — Стандартный файл для debhelper

pf-ring-dkms (4.7.1) unstable; urgency=low

  * Initial Release.

 -- Fedor Sakharov <fedor.sakharov@gmail.com>  Sun, 24 Jul 2011 11:02:45 +0400

4) control — Описание пакета и его зависимостей.

Source: pf-ring-dkms
Section: net
Priority: extra
Maintainer: Fedor Sakharov <fedor.sakharov@gmail.com>
Build-Depends: cdbs, debhelper (>= 7.0.50~)
Standards-Version: 3.8.4
Homepage: http://ntop.org

Package: pf-ring-dkms
Architecture: any
Depends: dkms
Description: PF_RING high-speed traffic capture module.
 PF_RING is kernel module for high-speed traffic capture.

5) pf-ring-dkms.install определяет установочные директории для файлов в пакете. DKMS требует, чтобы сорцы модуля находились по адресу /usr/src/-.

*                   usr/src/pf_ring-4.7.1
debian/dkms.conf    usr/src/pf_ring-4.7.1

6) pf-ring-dkms.postinst постинсталл скрипт, в нем мы пишем команды для добавления модуля данной версии в дерево DKMS, его сборки и установки.

NOTE: CVERSION надо разгрепывать из результатов dpkg-query, но здесь приведен упрощенный вариант.

#!/bin/sh
# postinst script for pf-ring
#
# see: dh_installdeb(1)

set -e

# summary of how this script can be called:
#        * <postinst> `configure' <most-recently-configured-version>
#        * <old-postinst> `abort-upgrade' <new version>
#        * <conflictor's-postinst> `abort-remove' `in-favour' <package>
#          <new-version>
#        * <postinst> `abort-remove'
#        * <deconfigured's-postinst> `abort-deconfigure' `in-favour'
#          <failed-install-package> <version> `removing'
#          <conflicting-package> <version>
# for details, see http://www.debian.org/doc/debian-policy/ or
# the debian-policy package

CVERSION=4.7.1

case "$1" in
    configure)
        echo "Adding Module to DKMS build system"
        dkms add -m pf_ring -v $CVERSION > /dev/null
        echo "Doing initial module build"
        dkms build -m pf_ring -v $CVERSION > /dev/null
        echo "Installing initial module"
        dkms install -m pf_ring -v $CVERSION --force > /dev/null
        echo "Done."
    ;;

    abort-upgrade|abort-remove|abort-deconfigure)
    ;;

    *)
        echo "postinst called with unknown argument \`$1'" >&2
        exit 1
    ;;
esac

exit 0

7) pf-ring-dkms.prerm скрипт. При удалении пакета необходимо удалить модуль из дерева DKMS.

#!/bin/sh
# prerm script for pf-ring
#
# see: dh_installdeb(1)

set -e

# summary of how this script can be called:
#        * <prerm> `remove'
#        * <old-prerm> `upgrade' <new-version>
#        * <new-prerm> `failed-upgrade' <old-version>
#        * <conflictor's-prerm> `remove' `in-favour' <package> <new-version>
#        * <deconfigured's-prerm> `deconfigure' `in-favour'
#          <package-being-installed> <version> `removing'
#          <conflicting-package> <version>
# for details, see http://www.debian.org/doc/debian-policy/ or
# the debian-policy package

CVERSION=4.7.1

case "$1" in
    remove|upgrade)
        echo "Removing all DKMS modules"
        dkms remove -m pf_ring -v $CVERSION --all > /dev/null
        echo "Done"
    ;;

    *)
        echo "prerm called with unknown argument \`$1'" >&2
        exit 1
    ;;
esac

exit 0

8) README

The Debian Package pf-ring
----------------------------

PF_RING Linux kernel module for high-speed traffic capture.

 -- Fedor Sakharov <fedor.sakharov@gmail.com>  Sun, 24 Jul 2011 11:02:45 +0400

9) rules — здесь мы не юзаем makefile.mk, чтобы не запускался мейк модуля при сборке пакета, просто копируем файлы куда надо.

#!/usr/bin/make -f

include /usr/share/cdbs/1/rules/debhelper.mk

DEB_DH_INSTALL_ARGS=-Xdebian
SRC_VERSION=$(shell dpkg-parsechangelog | grep '^Version:' | cut -d' ' -f2 | cut -d- -f1 | cut -d\: -f2)

binary-install/pf-ring-dkms::
        cp $(CURDIR)/debian/dkms.conf $(CURDIR)/debian/$(cdbs_curpkg)/usr/src/pf_ring-$(SRC_VERSION)

10) Строим пакет

$ dpkg-buildpackage

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

Идея в двух словах: есть системы безопасности уровня ядра ОС такие, как SELinux, AppArmor. Они расширяют стандартную модель безопасности unix-подобных систем, реализуя т.н. «принцип минимальных привилегий». В том числе, это значит, что процесс должен иметь права на доступ к тем и только тем объектам системы, доступ к которым ему необходим для штатного функционирования. В стандартной же модели безопасности приложение всегда имеет доступ ко всем объектам, к которым имеет доступ пользователь, что, очевидно, является избыточным с точки зрения принципа минимальных привилегий. Моей задачей является ещё более сильное ужесточение ограничений, накладываемых на поведение приложений, чем есть в SELinux и AppArmor. Под ужесточением понимается переход от контроля за целым приложением к контролю за его различными участками.

Итак, градус гранулярности повышается примерно так:
* стандарнтая модель – пользователи
* SELinux, AppArmor – процессы
* моя работа – участки кода процессов.

Зачем это делать? Очевидно, что на разных этапах исполнения процесса множество минимальных прав, необходимых приложению для нормального функционирования является различным. Простым примером может быть приложение, которое при запуске считывает файл конфигурации, затем начинает обслуживать сетевые соединения. Права на чтение файлов конфигурации необходимы данному приложению только в начале исполнения. Но в SELinux мы обязаны наделить приложение объединением всех множеств таких прав. В результате, если злоумышленник обнаруживает уязвимость в обработке сетевых соединений нашим сервисом, он может получить доступ к файлам конфигурации.

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

Вообще, данный подход позволяет побороться с атаками на уязвимости, эксплуатация которых приводит к изменению нормального хода исполнения приложений. Классическим примером из книжки является переполнение стека. И подобные атаки возможны до сих пор, хотя на данный момент, очевидно, дело обстоит несколько сложнее, чем описано в Shellcoder’s Handbook.

А вот если на приложение можно как-то напасть не изменяя его нормальный ход исполнения, то такой подход будет неприменим. Типичным примером может быть remote-root в exim4 2010-го года. Вообще, из-за того, что жизнь классических уязвимостей переполнения буфера очень сильно осложнилась в последнее время под linux, на передний план выходят различные атаки на особенности приложений. Очень многие любят сделать у себя какие-нибудь исполняемые конфиги, или, там, язык ACL для почтового сервера, где есть команда run{}. Если подумать, то сегодня определенного вида встроенный язык присутствует практически в каждой программе(да, форматная строка это тоже своего рода язык). Кроме этого, есть мир уязвимостей в JIT, короче, не переполнением стека единым. И на данный момент, класс реальных уязвимостей, к которым применим мой подход является весьма пустым. Но это до первой найденной атаки на адрес возврата, например.

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

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

Из-за определенных причин наша команда является довольно самобытной и весёлой, игры CTF не являются для нас основным видом деятельности до такой степени, что нам очень лениво тренироваться в тактике, распределении ролей, автоматизации разной фигни, администрировании и всём прочем. Мы не устраиваем тренировок, как это делают многие наши соперники, у нас всё на это нет времени и сил, мы играем for fun. Самобытность нашей команды подчёркивают свободный академический духъ, который гордо реет над нашими рядами, как бы далеко мы не были от Главного ВУЗа страны, глубокие научные познания и опыт работы в сфере защиты информации.

Вот что по этому поводу думает капитан одной из местных команд:

Капитан HackerMayCry Сергей Азовсков надеется на победу. Основными своими конкурентами считает команды из Томска, Калининграда, Челябинска и Санкт-Петербурга.

С результатами команды HackerMayCry и других местных команд вы можете ознакомиться в финальном скорборде, ссылка ниже.

На этом RuCTF мы посвятили подготовке два дня, которые у нас были непосредственно перед финалом соревнований. Разумеется, не все дни целиком, но какое-то время. Коллеги изучали различные аспекты веба, я читал какие-то статьи. Наши тактические планы мы вынашивали в Старом Дублине, свою сабмитилку мы дописывали в подвале УрГУ. Короче говоря, в совершенно расслабленном режиме провели дни до финала.

В финале мы резко и решительно применили свободный академический дух, взяли на опыт работы и приложили научные познания. Отмечу, что в прошлом году мы заняли 12-е место без вариантов. В этом году мы уверенно шли рядом с лидерами, в атаке нас серьезно превзошли только Leet More, что позволяет сделать вывод о том, что только благодаря своей лени и неумению писать нормальные адвайзори мы не вошли в тройку и не получили чашку, заняв 4-е место. Финальный скорборд.

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

P.S. Передаю привет нашим соседям команде из Калининграда, в частности, красивым девушкам, которые были в их составе. Надеюсь, что вам понравились наши рутовые шеллы и SELinux %)

P.P.S. Извиняюсь перед коллегами, что не привез вам местного пива.

Anyway. Соревнования с самого начала начали вызывать определенные (но ожидаемые в данной ситуации) вопросы. Но обо всём по порядку.

Для того, чтобы поучаствовать в финале данных соревнований, командам пришлось пройти отборочный тур. Уже в ходе отборочного тура задания начали наталкивать на размышления о своей весьма косвенной причастности к тематике информационной безопасности. Я думаю, что соответствующие write-up’ы вы сможете легко найти в блогах участвовавших команд.

Те команды, которые прошли отбор должны были придумать по одному заданию для финала. Мы с большим удовольствием придумали задание, справедливо полагая, что придуманные командами задачи лишь составят компанию заданиям от организаторов (СПб ГУТ).

Тем не менее, мы приехали, заняли места согласно купленным билетам, приготовились играть соревнования. Организаторы (СПб ГУТ) сообщили, что у каждой из команд есть своя беспроводная точка доступа(пять точкек + одна резервная) и вслух сообщили пароли к каждой из них. Во-первых, эти точки оказались мегафоновскими роутерами, которые (все шесть) пытались раздать шести командам доступ к удалённому сетапу через 3g(which has proved to be as good as it could possibly be near Solnechnogorsk). Пароли от точек были, как я уже сказал, сказаны на весь зал, а пароли роутеров были «admin». Кроме этого, данные «роутеры» были настроены на автоматический выбор частот, что приводило к тому, что они неизбежно начинали постоянно переназначать свои частоты со всеми вытекающими. Будучи предприимчивыми молодыми людьми, мы смогли влезть на все точки, куда смогли, поменяли пароли роутеров и сетей на «sibearssibears», попытались разрулить ситуацию с частотами (частично удалось).

Тут дело подошло к обеду. Не скрою, кормили отлично, в лучших традициях подмосковных люксовых заведений для представителей власти и бизнеса. Обед несколько смягчил впечатление от неудавшихся точек, но среди команд уже поползли опасные разговоры на тему «надо сказать, что CTF не удался».

После обеда удалось поиграть, но не оставляло ощущение, что что-то не так. Сильная рука организаторов (СПб ГУТ) была замечена лишь один раз, в самом начале встречи, когда главный организатор (СПб ГУТ) сказал, что сможет договориться о том, что команда Уфологистов в любом случае попадёт в финал RuCTF. Не знаю, как отнеслась команда Хакердом к столь неожиданному распоряжению местами в финале её соревнований. Не знаю я, как отнестись к тому, что по правилам соревнований максимальное число участников команд равнялось четырём, но некоторые команды явно превысили данный предел. Я не знаю, как отнестись к тому, что по правилам соревнований команды должны были состоять из студентов, но некоторые команды имели в своём составе аспирантов. Но, наверное, лучше об этом не говорить. У людей сразу настроение портится…

Подводя итог, хотел бы сказать, что это первый CTF из тех, что мы играли, который явно не удался. Я не знаю, что было сделано организаторами (СПб ГУТ). С тем же успехом мы с другими командами могли договориться, захостить свои тренировочные задания и потренироваться удалённо. Людям бы не пришлось ехать через всю Россию, чтобы увидеть CTF из деревни по подмосковному 3g.

В эту субботу наша команда Bushwhackers принимала участие в соревнованиях РусКрипто CTF. Для нас это был первый CTF Не буду тратить много слов на околоцтф. Нас привезли, посадили, проинструктировали и сказали ломать. Единственное, что напрягло в непосредственно организации — формат круглого стола.

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

В результате, почти все уязвимости произвели впечатление, что они только вот-вот сошли со страниц учебной литературы. Сразу оговорюсь: я не считаю, что это плохо и это было даже местами весело. Были и SQLi, были popen, были какие-то кучи на php(а как же py? а как же rb? а как же, в конце концов, hs? привет, iCTF), были флаги в cisco ios. Я признаться, не очень падок до всяких таких вещей, но было весело. Наверное. Задание на реверсинг(ну, я так понимаю, что на реверсинг) меня разочаровало. Я брался за objdump вдохновленный заданиями на реверсинг с образов iCTF(2005, например, помните эти libpcap, картинки в base64 с нарисованными на них паролями, зашитые в бинарник, и прочее, прочее). К сожалению, все оказалось совсем неинтересно и лишь наложением рук вида shell aaaaaaaaaaaaaaaaaaa задача была решена. Ах да, и пароль там лежал просто в strings.

А ведь хотелось бы видеть задания, решение которых доставляет. Решив которые, берешься за голову, тянешь лыбу и говоришь «аааааааааааа» вслух, а не шеллу. Я говорю это не нытья ради, а в качестве пожеланий организаторам относительно следующих рускриптоцтфов. Делайте сложнее. Делайте интереснее. Думаю, что это примерно уравняет наши с CIT шансы на победу.

А вообще, было достаточно ненапряжно и весело, особенно последние пять минут соревнований, когда мы эпично вырвали очко у команды SiBears (да простят меня читатели за этот комментаторский шаблон).