[articles.git] /

## PowerDNS

PowerDNS -- DNS сервер для массового обслуживания с хранением информации об обслуживаемых зонах в СУБД.
Когда-то в прошлой жизни я его использовал в проекте DNS-хостинга.
PowerDNS был выбран пример ПО с ярко выраженной поверхностью атаки: есть сетевое соединение обслуживающие анонимных пользователей посылающих серверу нетривиальные запросы.
(Надо отметить что в том DNS-хостиге мы прятали наш PowerDNS за более общепринятым bind9 работающем в режиме трансляции запросов)
Условия экзамена по обучающей программе предполагали использование Natch для обнаружение функций лежащих на поверхности атаки и подлежащих первоочередной обработки фаззингом.
Когда поверхность атаки ярко выраженная, это сделать проще всего.

### План эксперимента   


Предполагается 
* выполнить сборку PowerDNS из исходников
* настроить тестовую DNS-зону
* запустить сервер в режиме авторитативного мастера,
* пометить данные приходящие на 53й порт по tcp и udp 
* отправить к серверу запросы по tcp и udp протоколу
* изучить как помеченные данные перемещались через иерархию вызова функций.

### Сборка и установка

1. Получаем исходники последней версии PowerDNS:

```
git clone https://github.com/PowerDNS/pdns.git
```

В моем случае используется ветка master находящаяся на коммите d4ccf7673a от 9 апреля 2025г.

2. Устанавливаем зависимости необходимые для сборки проекта

```
apt-get build-dep pdns-server
```

3. Конфигурируем проект и запускаем сборку


```
./configure --with-modules="gpgsql"

make

sudo make install
```

Если обратить внимание на финальный вывод скрипта `./configure` то можно заметить, что PowerDNS по умолчанию собирается с отладочной информацией (ключ `-g`) и никаких дополнительных действий для сборки с покрытием предпринимать не надо.

Сборка осуществляется с модулем `gpgsql` который позволяет хранить информацию о зонах и записях в СУБД PostgreSQL, мне с ней привычнее работать.

### Настройка

#### 1. Устанавливаем PostgreSQL из пакетной системы Debian:

```
sudo apt-get install postgresql
```


#### 2. Создаем пользователя и базу данных для хранения данных PowerDNS

```
sudo su postgres
createuser -P pdns_user
# Вводим пароль
createdb pdns -O pdns_user
```

#### 3. Создание схемы базы данных

Копируем схему базы данных из [документации](https://doc.powerdns.com/authoritative/backends/generic-postgresql.html#default-schema) в буфер
(та же схема есть в исходниках по пути `modules/gpgsqlbackend/schema.pgsql.sql`)

Подключаемся консолью `psql` к базе `pdns` и переключаемся в пользователя `pdns_user`

```
psql pdns
set role pdns_user;

```

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

В консоли появится много строк начинающихся со слова `CREATE`.

Выходим из консоли `psql`, выходим из `shell`-консоли пользователя `postgres`

```
exit
exit
```

####  4. Создание конфигурации PowerDNS

Копируем пример файла конфигурации в актуальный конфигурационный файл

```
cp /usr/local/etc/pdns.conf-dist /usr/local/etc/pdns.conf
```

Добавляем в файл `/usr/local/etc/pdns.conf` строки

```
launch=gpgsql
gpgsql-host=127.0.0.1
gpgsql-user=pdns_user
gpgsql-password=[ваш пароль]
gpgsql-dbname=pdns
```
В значение параметра `gpgsql-password` записываете пароль который вы указали при создании пользователя pdns.

### Тестирование
 
#### 1. Проверяем что вообще запускается

По неизвестной мне причине бинарник `pdns_server` в `/usr/local/bin` при `make install` не установился, но при наличии правильного конфигурационного в ожидаемом месте можно запускать бинарник прямо из директории сборки

```
sudo pdns/pdns_server
```

Если все было сделано правильно сервер запустится, сообщит что присоединился  к каким-то портам и перейдет в режим ожидания соединения. 
Если была допущена какая-то ошибка надо ее устранить и добиться того чтобы сервер запустился.
Сервер пока останавливаем нажав Ctrl+C

#### 2. Создаем тестовую зону.

В директории сборки в папке `/psql` есть утилита для управления зонами и записями PowerDNS. Используем ее для создания зоны.

```
pdns/pdnsutil create-zone example.com
pdns/pdnsutil add-record example.com test A '8.8.8.8'
```

Этими командами мы создаем A-запись, которая указывает, что доменное имя `test.example.com` привязана к IP-адресу `8.8.8.8`

Можно зайти обратно в `psql` и убедиться, что таблицах `domains` и `records` были созданы соответсвующие записи:

```
select * from domains;
select * from records;
```

#### 3. Локальное тестирование 

Запустим сервер как в п.1

```
sudo pdns/pdns_server
```

в соседней консоли еще раз зайдем на виртуалку и выполним команды

```
dig @127.0.0.1 test.example.com

dig @127.0.0.1 test.example.com +tcp
```

Эти команды выполнят запросы к нашему DNS-серверу по UDP и TCP протоколам. Правильный ответ должен содержать строку

```
test.example.com.       3600    IN      A       8.8.8.8
```

А так же в разделе `flags:` должен присутствовать флаг `aa`, говорящий что это ответ от сервера отвечающего за зону, а не ретранслированный.

#### 4. Пробрасывание 53 порта наружу

Теперь нам надо сделать так, чтобы порт по которому PowerDNS обслуживает клиентов, оказался доступен на host-машине.

Для этого в скрипт запуска виртуалки в опции настройки сети добавим параметры `hostfwd=udp::15353-:53,hostfwd=tcp::15353-:53`, в результате чего в теории 53 порт внутри виртуалки будет замэплен на порт 15353 хост машины и по TCP и по UDP.
Проделав это перезапустим виртуалку.

#### 5. Тестирование извне виртуалки

Зайдя в виртуалку запускаем DNS-свервер как в п.1

```
sudo pdns/pdns_server
```

И на хост-машине делаем TCP и UDP DNS-запросы по порту 15353 локального интерфеса:
 
```
dig @127.0.0.1 -p15353 test.example.com +tcp
dig @127.0.0.1 -p15353 test.example.com
```

Результат должен оказаться такой же как в п.3.


### Запись трассы

На основании созданного образа виртуальной машины мы создаем два проекта natch для пометки данных по протоколу TCP и для пометки данных по протоколу UDP.
Процесс создания проектов в достаточной мере отражен в документации, обозначу лишь ключевые нюансы:

* Создаем два отдельных проекта, один для перехвата TCP, другой для перехвата UDP
* Для случая TCP в консольном диалоге запрашиваем проброс наружу 53го порта, в `tainted.cfg` в разделе `[Ports]` указываем `ip_protocol=6`, `dst=53`, `rc=53`, и все должно заработать
* Для случая UDP, после создания проекта, необходимо руками во всех конфигах заменить `hostfwd=tcp` на `hostfwd=udp`,  в `tainted.cfg` в разделе `[Ports]` указать `ip_protocol=17`, а `src` и `dst` не указывать вовсе. 

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

* Включаем запись сценария `natch record`
* Логинимся в виртуалку, уже через графическое окно qemu
* Делаем первый снэпшот
* Запускаем сервер, как это делали при тестировании
* С хост машины отправляем запрос на TCP или UDP порт на который был замаплен 53 порт виртуалки (значение добывается из конфигов натча), так же как это делали при тестировании, номер порта только надо будет поменять.
* Получаем ответ
* Делаем второй снепшот
* Выходим.

Далее командой `natch replay` снимаем трассу между первым и вторым снепшотом и загружаем ее в snatch.

### Анализ результатов

Данные пришедшие в систему 53 TCP или UDP порта, были помечены, и при помощи программы визуализации snatch можно посмотреть как они распространялись по системе

#### Resources

Посмотрев на вкладку Resources мы можем следать вывод, что помеченные данные проходили через сам процесс pdns_server'а и через процесс ядра (имеют право) и через другие процессы не проходили

![...](1. PowerDNS.imgs/resources_0.png)

заглянув внутрь узла `pdns_server/sockets` мы можем увидеть, что помеченные данные читаются из tcp или udp сокета (в зависимости от того на результаты какого эксперимента мы смотрим) и более ни в какие другие сокеты и файлы не направлялись

![...](1. PowerDNS.imgs/resources_1_tcp.png)

![...](1. PowerDNS.imgs/resources_1_udp.png)

Если нажать на подсвеченный голубым сокет, то в появившейся справа панели можно увидеть, что помеченные данные из сокета читаются, и потом обратно в него частично пишутся, и при этом пределы pdns_server'а не покидают, например не участвуют в запросе к базе данных.
Интересно, как им это удалось? Вся база записей оказывается загруженной в память и сервер делает `strcmp` с содержимым памяти?

![...](1. PowerDNS.imgs/resources_2.png)

Так же можно увидеть, что сервер по адресу 10.0.2.3 (адрес сетевого интерфейса виртуальной машины) сервер сам себе посылает udp-пакет с неким запросом `security-status`.
Это явно должно насторожить безопасников, этот механизм должен быть как минимум исследован, и возможно, если результаты исследования окажутся неудовлетворительными, то отключен.

![...](1. PowerDNS.imgs/resources_3.png)

#### Call Graph
##### TCP

В графе вызовов снятом для случая передачи данных по TCP соединению хорошо виден алгоритм обработки входящего запроса.
После ряда вызовов посвященных получению данных из сокета, вызывается большой метод отвечающий за разбор входящего пакета `DNSPacket::parse`, после чего происходит обработка входящего запроса `AuthPacketCache::get` (не совсем четко понятно что он делает, надо код читать) и `PacketHandler::doQuestion`, после чего происходит отправка ответа: `ResponseStats::submitResponse`.
Первичной целью для фаззинга совершенно очевидно следует выбрать функцию `DNSPacket::parse`, которая оказывается первой на острее атаки. Для более глубокого фаззинг исследования следует в качестве цели выбрать всю последовательность обработки запроса включая парсинг и обработку запроса, но не включая отправку ответа.  

![...](1. PowerDNS.imgs/call_graph_tcp.png)


##### UDP

Для случая UDP соединения мы видим те же самые функции `DNSPacket::parse`, `AuthPacketCache::get`, `PacketHandler::doQuestion` и `ResponseStats::submitResponse` перемежающиеся вызовами обеспечивающими работу с UDP-сетевым соединением, и завернутые в два потока выполнения. 
По какой-то причине для работы с UPD-соединением была выбрана многопоточная архитектура. Видимо в этом был какой-то практический смысл.
Принципиально новых элементов в поверхность атаки при обработке UDP-соединения обнаружено не было.

![...](1. PowerDNS.imgs/call_graph_udp.png)


### Выводы

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