Storj 는 블록체인 기반 저장소 플랫폼이다. 해당 플랫폼을 공격하는 방법과 대책에 대한 논문을 분석하고 정리했다.
먼저 구글 드라이브 같은 전통적인 클라우드 저장소 플랫폼은 아래 왼쪽 그림과 같다. 기업 데이터센터에서 모든 파일들을 관리하고 클라우드 서비스를 제공한다. 하지만 Storj 는 업로드된 파일을 보관하는 역할도 일반 유저가 한다. 이런 역할을 수행하는 유저를 Farmer 라 부르는데, 개인 저장공간을 제공함으로써 보상으로 Storj 암호화폐 토큰을 얻을 수 있다. 반대로 Storj 암호화폐 토큰을 지불하고 서비스를 이용하는 유저를 Renter 라고 한다. 아래 오른쪽 그림을 보면 마치 Storj Bride 서버가 중앙집중식으로 모든걸 관리하는것처럼 보이지만, Renter 파일을 어느 Farmer 에게 보낼지 결정만 하고 그 다음부터는 Renter 와 Farmer 가 직접 통신한다.
Renter 와 Farmer 의 관계를 좀 더 자세히 살펴보자. 먼저 Farmer 가 준비되야 Storj 서비스를 제공할 수 있다. Farmer 는 Bridge 에 네트워크 가입을 요청한다. 가입이 완료되어 합류하게 되면 Farmer 와 Renter 사이의 보관계약을 맺는다. 그 후 Renter 는 파일 업로드가 가능해진다. 업로드 하려는 파일은 먼저 암호화를 거치고 Shard 라고 하는 조각으로 분할시켜 Bridge 서버 알고리즘에 따라 Farmer 에게 분산 저장된다.
cf) Storj 네트워크는 Renter과 Farmer 를 위한 계약을 체결하고 Renter 등록, 노드 IP 주소, 계약 세부 정보, Shard 메타 데이터 등과 같은 필수 정보를 저장하기 위해 중앙 집중식 서버(Bridge)가 필요하다.
Storj 동작 메커니즘을 살펴보니(업로드한 파일을 분할시켜 여러 Farmer 들에게 저장시키는 방식) 내가 업로드한 파일을 원할 때 다운로드 받지 못할 수 있겠다는 생각이 들었다. 업로드한 내 파일중 일부를 갖고 있는 Farmer 가 실수로 포맷을 하거나, 전원이 계속 꺼져있거나 등등 여러 이유로 파일을 제공하지 못할 수 있다. 그래서 이 문제를 해결하기 위해, 즉 가용성을 높이기 위해 똑같은 Shard 를 복제해서 여러 Farmer 들에게 뿌리는 방식으로 가용성을 높인다. 하지만 Renter 는 파일의 중복 복사본 양을 직접 지정할 수 있다. 당연히 많이 할 수록 비용이 많이 들기 때문에 가용성은 낮아진다. 구글 드라이브 처럼 기업이 오너쉽을 갖고 서비스를 운영하는게 아니다보니 가용성을 높게 유지하는게 쉽지 않을거 같다. 99% 가용성을 유지한다고 하더라도 1년간 최대 장애 시간은 3일 15시간이나 된다.
다시 본론으로 돌아와서 어떻게 Storj 를 공격하는지 설명하겠다. 악의적인 목적을 가진 Renter 가 업로드할 파일로 Farmer 를 공격하기 위해선 먼저 업로드하기 전 수행하는 암호화 프로세스부터 비활성화 시켜야한다.
구체적으로 어떻게 비활성화 시킬 수 있을까? 답은 Renter 가 사용하는 Stroj 클라이언트 소프트웨어 코드를 수정하는것이다. 오픈소스니까 코드를 다운받고 아래 storj_brige 주소를 192.168.1.117:8080 으로 수정하면 된다. 이부분이 처음엔 이해가 안됐다. 공용 Storj 서버를 공격하는 방법에 대해서 설명할 줄 알았기 때문이다. 192.168.1.117 로 보낸다는것은 나만의 Bridge 서버로 요청을 보내겠다는 뜻이다. 다시말해 아래 오른쪽 그림처럼, Renter 의 Storj client, Bridge 서버, Farmer 서버 모두 새롭게 구축하고 Frameup 공격을 수행해 결과를 검증하는 논문이었다.
다음으로, 암호화 프로세스를 비활성화 시키기 위해 암호화 관련 코드를 수정한다. ctr_crypt 함수로 암호화 시킨 후 코드 아래줄에 memcpy 함수를 추가해 다시 일반 텍스트(read_data) 를 cphr_txt 값으로 엎어친다. 이렇게 암호화 프로세스를 무력화 시킬 수 있다.
여지서 잠깐 짚고 넘어갈 얘기가 있다. 악의적인 목적을 가진 Renter 는 특정 Farmer 를 타겟팅해서 공격할 수는 없다. 업로드한 파일을 Shard 단위로 분할시켜 어느 Farmer 로 보낼건지는 Bridge 가 결정하기 때문이다. 하지만 Renter 가 업로드할 파일의 복사본 양을 지정할 수 있어서 여러 Farmer 들에게 광범위한 피해를 줄 수 있다.
Renter 는 특정 Farmer 를 대상으로 공격할 순 없지만, Renter 와 Farmer 설계 특성을 활용해서 공격의 정확도를 높일 순 있다. Farmer 는 Renter 에게 가장 낮은 latency 와 가장 빠른 데이터 전송 속도가 있을 때 서로 매칭된다. 다시말해 지리적으로 가깝거나 같은 네트워크 망에 있는 경우 어느정도 타겟팅이 가능하다.
하지만 Frameup 공격이 항상 성공하는것은 아니다. 공격은 몇가지 파일 유형(AVI, MPG, PDG) 에서만 효과적인것으로 분석됐다. Storj 는 Farmer 가 보관할 Shard 를 저장하기 위해 LevelDB(Nosql) 를 사용한다. 내부적으로 .ldb, .log 파일에 저장하는데 파일 시스템 특성상 하나의 .ldb, .log 파일에 여러 Shard block 이 포함될 수 있다. 이점을 이용해서 악의적인 데이터를 추가시킨다. 하지만 JPG 파일은 추가된 데이터로 인해 마커가 수정되면서 파일이 깨진다.
그래서 더 최적화된 js 공격 방법을 알려준다. base64로 인코딩된 파일 내용을 담은 img 태그를 문자열로 만들어서 str0, str1 변수가 나눠갖는다. 아래 주석처리된 부분은 위에서 파일 시스템을 활용해 추가될 데이터 위치이다. Farmer 가 브라우저에서 해당 js 를 실행시키면 공격이 시작된다.
하지만 논문 내용을 보면 공격 프로세스가 매끄럽지 않다. Farmer 가 자신의 저장소에 저장된 Shard 파일을 html 확장자로 굳이 바꾼 다음, 브라우저를 열어서 실행 시켜야 하는데 공격 당하겠다고 마음 먹지 않은 이상 이런 행위는 일반적이지 않다.
어쨌든 논문에선 최적화된 공격이 Shard 파일 크기가 커질수록 더 유효하다고 말한다.
마지막으로 대책이다. Farmer 에 업로드된 데이터들을 엔트로피 테스트를 수행해서, 실패한 테스트 데이터는 저장하지 않도록 Farmer client SW를 수정하는 방법을 얘기한다. 그러나 실행 파일, zip 및 다양한 그래픽 파일 형식과 관련된 높은 엔트로피를 고려할 때 엔트로피 임계값을 매우 높게 설정해야 한다. 또한 Renter <–> Farmer 계약이 이미 체결된 후에만 탐지가 이루어지므로 공격이 탐지되면 Farmer 가 법적 계약을 거부하는 문제가 생길 수 있다.
cf) 엔트로피가 높다 = 불확실성이 높다 = 새로운 정보가 많다
그래서 아래 verification algorithm 을 소개한다. Bridge 서버는 Renter 가 업로드한 파일을 어느 Farmer 에게 보낼지 결정하기 때문에 '어느 Farmer 에 어느 Shard 데이터가 있는지'에 대한 메타테이터를 DB 에 갖고 있다. 그래서 DB 에 있는 Shard hash 들을 다 갖고오고 의심스러운 Farmer 의 Shard 를 갖고와서 hash 를 구한다음, 비교하는 방어로직을 추가한다.
'BlockChain' 카테고리의 다른 글
| DID 스터디 2회차 (0) | 2023.02.25 |
|---|---|
| DID 스터디 1회차 (0) | 2023.01.28 |
