yangbongsoo
commented
2 years ago https://digitalcommons.newhaven.edu/cgi/viewcontent.cgi?article=1089&context=electricalcomputerengineering-facpubs https://github.com/storj
Storj에 대한 범죄 공격: P2P 블록체인 지원 분산 스토리지 시스템
Storj 는 오픈 소스 클라우드 저장소 플랫폼이다(블록체인 기술이 탈중앙화 클라우드 저장소 네트워크를 구축하는 데 활용된다고 한다). 데이터를 거대한 데이터센터에 저장하는 전통적인 클라우드 저장소 솔루션과 달리, 스토리지는 수천 명의 독립 컴퓨터 네트워크를 운영한다.
Storj는 제공되는 서비스에 대한 지불에 사용되는 암호화폐 토큰을 사용하여 사람들이 자신의 하드 드라이브 공간을 전 세계 다른 사용자에게 대여할 수 있는 블록체인 지원 시스템입니다.
우리는 발견된 공격을 완화할 수 있는 잠재적인 솔루션, 프레임업 공격의 희생자가 있는지 검토하기 위한 개발된 도구, 그리고 임대인 몰래 파일이 하드 드라이브에 저장되었음을 보여주는 메커니즘을 제공한다. 우리는 이 작업이 블록체인과 암호화폐 토큰을 수용하는 분산형 피어 투 피어 스토리지 시스템 탐색에 있어 향후 보안 및 과학 수사 연구 방향을 고무하기를 바란다.
Introduction
전 세계 사용자들은 구글 드라이브, 애플의 아이클라우드 드라이브, 드롭박스 등의 클라우드 스토리지를 채택했으며, 데이터 저장 및 백업을 중심으로 비즈니스 모델을 만든 기업들이 이를 유지 및 중앙 집중화하고 있다. 그러나 블록체인 기술이 부상하면서 분산형 시스템이라는 개념이 현실화되면서 기업이 사람의 데이터를 저장하고 통제한다는 개념에 도전장을 내밀었다.
데이터 저장의 에어비앤비로 알려진 Storj는 Storj 암호화폐 토큰 구현이 추가된 계약 기반의 블록체인을 통해 개인이 전 세계 사람들의 컴퓨터에서 대여한 하드 드라이브 공간에 안전하고 분산된 방식으로 데이터를 저장할 수 있는 플랫폼이다. 사람들은 Storj 토큰을 사용하여 대여된 저장 공간을 지불할 수 있고, 그들의 하드 드라이브 공간을 대여한 개인들은 그 대가로 Storj 토큰으로 지불을 받을 수 있다.
블록체인 기술로 가능한 분산 시스템은 크게 확장되고 있지만, 구현에는 몇 가지 약점이 있을 수밖에 없으므로, 이러한 시스템에 대한 중요한 과학적 조사는 사용자의 개인 정보 보호와 보안에 매우 중요하다. 이러한 시스템은 사용자에게 새로운 공격 벡터를 제공합니까? 만약 그렇다면, 그것들은 무엇인가? 좀 더 구체적으로 말하면, 사용자가 암호화되지 않은 방식으로 전 세계 컴퓨터에 데이터를 저장하여 하드 드라이브 공간을 임대하는 사용자를 프레임화할 수 있습니까? 드라이브 공간을 임대하는 사람이 범죄 공격이 가능한 경우 무죄로 입증될 수 있습니까? 이것은 2004년 카니와 로저스의 "트로이 목마가 나를 그렇게 만들었다"는 오래된 연구된 주장을 떠올리게 하는데, 그들은 악성코드가 잠재적으로 불법적인 자료를 생성하거나 컴퓨터에 다운로드하여 사용자를 유죄로 만들 수 있는지, 그리고 이것이 탐지될 수 있는지 탐구했다.
우리의 목표는 분산 Storj 시스템을 사용하여 사람들을 프레임화하는 것의 효과를 조사하고 개인이 실제로 프레임화되었음을 증명하는 접근 방식을 만드는 것이었다. 우리는 Storj 플랫폼에 대한 심층적인 조사를 통해 이를 수행했다. 따라서 우리의 작업은 다음과 같은 기여를 한다.
- 우리는 이 기술의 보안 조사에 대한 기본 계정을 제공합니다.
- 우리는 다른 피어 투 피어 클라우드 스토리지 네트워크에 대한 향후 조사를 고무한다.
- 법의학자들에게 이 잠재적인 범죄의 공격에 대해 알게 합니다.
- Storj 구현에 대한 자세한 내용을 제공합니다.
- 우리는 Storj 네트워크에 연결된 사람들의 컴퓨터에 있는 데이터의 안전하지 않고 명확한 텍스트 저장을 허용하는 두 가지 범죄 공격을 이론과 예로 보여준다. 우리는 또한 생성되고 테스트된 공격의 가변성에 대해 논의한다.
- 우리는 이러한 공격이 완화될 수 있는 방법에 대한 제안을 제공한다.
- 우리는 누명을 씌운 것으로 의심되는 피해자의 결백을 감사(audit)하고 인증하기 위한 도구를 개발했습니다.
Storj network
Storj는 중앙 및 분산 네트워크의 아키텍처 설계 요소를 수용하는 오픈 소스 P2P(Peer-to-Peer) 분산 클라우드 스토리지 네트워크이다. 스토리지 관점에서 네트워크는 분산된 것으로 간주됩니다. 파일 콘텐츠가 여러 피어에 분할 및 배포되기 때문입니다. 그러나 Storj는 통신 제어를 위해 중앙 집중식 서버를 사용합니다. 중앙 집중식 서버는 사용자 인증을 처리하고 피어 스토리지 노드에서 암호화된 파일 세그먼트 스토리지를 협상하고 용이하게 합니다. Storj 네트워크는 Figure 1에 표시된 여러 다른 단위로 구성됩니다(Bridge, Renter, Farmer).
임차인(Renter)은 Storj 네트워크에서 저장 공간을 '임대'하려는 사용자입니다. 임차인은 Storj의 클라이언트 애플리케이션을 사용하여 네트워크와 상호 작용합니다. 클라우드에서 파일을 업로드 및 다운로드할 수 있습니다. 임차인은 네트워크와 통신하기를 원할 때마다 먼저 Bridge와 communicate 해야 합니다. 그 후에 Bridge는 임차인이 Farmer와 파일을 주고받을 수 있도록 승인합니다. Bridge는 네트워크의 핵심입니다. 네트워크의 모든 요소는 Bridge와 communicate 하며 Renter과 Farmer 간에 전송되는 파일을 제외하고 모든 형태의 통신은 다리에서 위임됩니다. 모든 Renter와 Farmer는 다리를 통해 네트워크에 액세스할 수 있습니다. 네트워크에 대한 주기적 상태 확인은 연결된 모든 Farmer와 Renter를 관찰하여 Bridge에서 수행됩니다.
Farmers는 클라우드 스토리지를 위한 공간을 제공하는 네트워크의 사용자입니다. 공간을 제공하기 전에 브리지에 네트워크 가입 권한을 요청해야 합니다. 일단 Farmer가 합류하면 Farmer는 Renter에게 드라이브 공간을 제공할 수 있도록 그들과 Renter 사이에 보관 계약을 맺을 수 있습니다.
네트워크의 주요 측면을 설명하면, Renter과 나머지 네트워크 간의 통신 프로세스를 설명할 수 있습니다. 이제 네트워크에서 파일을 업로드 및 다운로드하는 절차를 설명합니다.
Renter 가 P2P 스토리지 클라우드에서 농부들에게 파일을 업로드하는 과정에는 몇 가지 단계가 포함된다. Renter 는 파일을 처리하기 전에 먼저 농부와 보관 계약을 체결해야 합니다. 필요한 계약이 준비되면 브리지에 저장되고 파일이 업로드 대기열에 추가됩니다. 이 대기열은 Renter가 파일을 암호화한 다음 파일을 샤드라고 하는 다른 조각으로 분할하는 것으로 시작됩니다. 샤드가 생성된 후 계약과 함께 농부에게 배포됩니다. 그런 다음 중복 샤드 복사본이 생성되고 백업 메커니즘으로 배포되어 농부가 샤드를 분실하거나 파괴하거나, Renter 가 파일에 액세스하려고 할 때 농부가 오프라인 상태인 경우 데이터 가용성을 보장합니다.
파일을 다운로드할 때 Renter는 bridge에 연락하여 농부(들)에게 파일을 요청합니다. 브리지는 먼저 사용 가능한 샤드에서 파일을 재구성할 수 있는지 확인하여 Renter가 파일을 다운로드할 수 있는지 확인합니다. 파일을 재구성할 수 있는 경우 브리지는 농부에게 샤드를 Renter 에게 다시 보내기 시작하도록 지시합니다. Renter 가 파일을 복원하는 데 필요한 모든 샤드를 가지고 있으면 샤드가 하나의 파일로 결합되고 암호가 해독됩니다. 이 시점에서 파일이 검색되어 거래를 감사(audit)하는 브리지와 함께 Renter의 컴퓨터에 저장됩니다.
Frameup attack
우리는 탈중앙화 스토리지가 제기하는 중요한 보안 문제를 식별하고 설명합니다. 현재까지 중앙 집중식 스토리지 네트워크에 대한 연구가 집중되어 왔기 때문에 이 문제는 지금까지 간과되었습니다. 개별 사용자의 개인용 컴퓨터와 관련된 분산 스토리지는 공격자가 악용할 수 있는 새로운 벡터를 제공합니다. 우리는 이 공격을 Frameup 공격이라고 부르고 Figure 2에 묘사합니다.
이 공격에서 사악한 Storj Renter는 잠재적으로 악성 소프트웨어, 밀수품 및 기타 악의적인 콘텐츠로 구성된 암호화되지 않은 파일을 전 세계 농부의 컴퓨터에 업로드할 수 있습니다. 이는 Renter가 파일 분할 및 샤드 업로드 전에 암호화 프로세스를 비활성화함으로써 가능합니다. 그 결과 암호화되지 않은 데이터가 농부 컴퓨터에 저장되어 악성코드의 경우 무의식적으로 실행되거나 밀수품의 경우 무의식적으로 소유될 수 있습니다. 그러나 사악한 Renter가 프레임업 공격으로 특정 농부를 대상으로 삼을 수 없다는 점을 주의해야 합니다.
개인을 명확하게 대상으로 지정할 수 없으면 대상이 아닌 대상으로 공격 범위를 제한할 수 있지만 대상 희생은 달성할 수 있습니다. Storj의 설계에 따라 Renter의 샤드를 저장하기 위해 노드/파머를 선택하는 프로토콜은 결정적입니다. 농부는 Renter 에게 가장 낮은 지연 시간과 가장 빠른 데이터 전송 속도가 있을 때 Renter 의 샤드를 저장하도록 지명됩니다. 정보에 입각한 공격자는 이 설계 특성을 활용하여 공격의 정확도를 높일 수 있습니다. 공격자와 대상이 지리적으로 동일한 네트워크 또는 시설 내에 있는 경우 전체 클라우드에 대해 광범위하게 분산된 공격이 필요하지 않습니다.
프레임업 공격을 수행하는 것이 항상 단일 개체/사람/컴퓨터로 제한되는 것은 아닙니다. 광범위한 악의적인 활동은 막대한 피해를 초래합니다. Renter는 Storj 네트워크에 저장할 파일의 중복 복사본 양을 지정할 수 있습니다. 따라서 농부에서 악성 조각을 발견한 조사관은 해당 조각이 수백 또는 수천 명의 다른 농부에게 미러링되었음을 식별할 수 있습니다. 이 상황은 법의학 조사관이 영향을 받는 모든 농부를 수집하고 조사하는 데 엄청난 시간을 소비하도록 유도할 수 있기 때문에 달성 가능하고 문제가 있습니다.
Methodological overview
공격을 검증하기 위해 필요한 것은 다음과 같습니다. 1) 농부, 브리지, 복합 노드 및 renter 노드 등 모든 구성 요소를 실험적으로 모니터링할 수 있는 실시간 Storj 스토리지 네트워크 2) 파일 암호화를 비활성화하고 Storj 네트워크에 파일을 업로드할 수 있는 Storj 클라이언트 소프트웨어 3) 다양한 크기와 유형의 모의 범죄 파일(예: 텍스트 파일, 이미지, 비디오, 실행 파일 등) 4) 관련된 하드 드라이브의 포렌식 분석을 수행하는 디지털 포렌식 소프트웨어.
다음 단계를 사용하여 공격을 성공적으로 구성했습니다.
-
Storj 유지 관리 브리지를 사용하는 경우 모든 네트워크 구성 요소를 모니터링하고 분석할 수 있는 것은 아니므로 자체 로컬 개인 Storj 네트워크를 구축했습니다. 그러나 Storj 오픈 소스 코드2를 사용했기 때문에 네트워크의 실험 결과를 공용 Storj 네트워크에 일반화할 수 있다고 생각합니다. 자세한건 Detailed methodology 에서 확인.
-
일반 텍스트 조각의 농부 저장을 용이하게 하기 위해 먼저 사설 네트워크에 연결하도록 Storj 클라이언트를 구성한 다음 클라이언트 소스 코드의 업로드 동작을 수정했습니다. 수정 사항은 Sec. 5.2.
-
더 자세한건 5.4에 있다. 그런 다음 다양한 유형의 문서와 멀티미디어 파일이 포함된 일반 텍스트 파일 데이터 세트를 만들었습니다. 그런 다음 Sec. 6.1, 파머가 샤딩되는 원본 파일과 동일한 콘텐츠를 저장했는지 확인하기 위해 다양한 크기의 일반 텍스트 파일을 업로드했습니다.
-
위 3에서 얻은 결과를 바탕으로 프레임업 공격을 최적화하였다. 최적화된 공격은 업로드된 일반 텍스트 파일을 HTML로 캡슐화하여 파일 분할 프로세스에서 더 잘 살아남습니다. 더 자세한 설명은 Sec. 6.2.
-
그런 다음 널리 채택된 포렌식 도구 FTK(Forensic Toolkit)를 사용하여 포렌식 수사관의 관점에서 공격을 확인했습니다. FTK의 데이터 조각 프로세스를 통해 일반 텍스트 조각이 복구 가능하고 실행 가능한 콘텐츠의 경우 포렌식 스테이션에서 실행되는 방식으로 캡슐화될 수 있는지 확인할 수 있었습니다. 세부 사항은 Sec7 에 나와 있습니다.
-
프레임업 공격으로 인해 업로드된 샤드에 암호화되지 않은 데이터가 포함되어 있는지 테스트할 수 있는 접근 방식을 제시했습니다. 또한, 우리는 누명을 쓴 사람들을 위한 전략을 설명합니다. 이 전략은 피해자가 기술적 관점에서 프레임업 공격을 받고 있음을 보여줄 수 있습니다. 이러한 예방 및 조사 접근 방식은 Sec. 8.
Detailed methodology
Private Storj network
실험 환경은 클라우드 스토리지를 위한 사설 Storj 네트워크와 스토리지 서비스를 요청하는 악의적인 Renter의 클라이언트 애플리케이션이 필요했습니다. 그림 3과 같이 빨간색 블록은 사악한 Storj Renter 및 클라이언트 소프트웨어를 나타냅니다. 블록의 왼쪽 상단 모서리에 소프트웨어 프로젝트 이름을 표시했습니다. 예를 들어 브릿지 서버를 구축하기 위해 Storj Labs의 Github 페이지에서 'bridge' 프로젝트를 다운로드하여 커스터마이징했습니다. 사설 네트워크의 구성 요소와 여기에 연결하는 클라이언트 응용 프로그램은 모두 동일한 로컬 네트워크의 Ubuntu 16.04 LTS 컴퓨터에서 호스팅되었습니다. 브리지와 컴플렉스는 동일한 컴퓨터에 배포되었습니다. 클라이언트와 농부는 각각 다른 로컬 네트워크 컴퓨터에 설치되었습니다.
그림 1과 같이 Storj 네트워크는 Renter과 농민을 위한 계약을 체결하고 Renter 등록, 노드 IP 주소, 계약 세부 정보, 샤드의 메타 데이터 등과 같은 필수 정보를 저장하기 위해 중앙 집중식 서버(브리지)가 필요합니다.
우리의 사설망에서는 공용 Storj 네트워크용 브릿지 서버인 api.storj.io 대신 브릿지(v5.22.2) 서버에 IP:port 192.168.1.117:8080을 할당했습니다. 이에 따라 브릿지 서버의 설정 파일인 ~/.storj-bridge/config/develop 에 의해 브릿지 서버의 설정 파일인 'server' 오브젝트에서 'host' 문자열의 값이 http://192.168.1.117로 대체되었습니다. 또한 프라이빗 브리지를 위한 인프라를 지원하기 위해 포트 27017에서 MongoDB 서버를 호스팅했습니다.
프로그래밍 관점에서 Storj 랩은 복잡한 서버로 간주되며 몇 개의 renter 노드는 Storj 네트워크에 필요한 구성 요소입니다. complex는 아파트 complex의 집주인과 비슷합니다. 그들은 Storj 네트워크에서 renter 노드를 관리합니다. renter 노드는 renter와 동일하지 않습니다. 그들은 저장 공간을 요구하지 않습니다. 그들의 유일한 목적은 농부와 renter가 언제든지 네트워크에 참여할 수 있는 게이트웨이를 제공하는 것입니다. 즉, 네트워크를 활성 상태로 유지하기 위해 항상 네트워크에 연결됩니다. 본질적으로 Complex는 네트워크에 합류하기 위한 '항상 알려진' 액세스 포인트를 포함합니다. 이론적으로 브리지가 네트워크를 초기화하기 전에 충분한 파머를 알고 있었다면 Complex 서버 또는 renter 노드가 필요하지 않을 것입니다. 그러나 실제로 브리지는 다른 노드/농부가 참여할 수 있도록 원래 Storj 네트워크를 생성하기 위해 항상 몇 개의 노드가 필요합니다. 또한 임차인 노드는 Storj 연구소 또는 Storj 네트워크를 초기화하려는 다른 사람이 만들 수 있습니다. Complex 서버의 목적은 이들을 관리하는 것입니다. 로컬 네트워크에서 이러한 구성 요소는 Complex(v5.6.0) 프로젝트를 구성하여 구성되었습니다. 우리는 포트 8081을 Complex 서버에 할당하고 포트 4000 – 4002를 renter 노드에 할당했습니다.
농부에게 원래 Storj 네트워크에 가입할 수 있는 기능을 제공하려면 'storjshare-daemon' 또는 'storjsharegui' 프로젝트를 설치해야 했습니다. 이 경우 CLI(명령줄 인터페이스)가 있는 storjshare-daemon(v3.5.5)을 선택합니다. 프로젝트가 컴퓨터 192.168.1.126에 설치됨에 따라 유효한 이더리움(ETH) 지갑 주소가 CLI 명령 'storjshare-create'에 제공되었고 4명의 농부 각각에 대한 구성 파일이 폴더 ~/.config/storjshare/configs/에 생성되었습니다. 농부에 대한 구성 파일의 이름은 노드 ID(예: 68336ce3f8b3ad5052c4259bbbde707057ee8cb2.json)로 지정되었습니다.
그 후 구성 파일을 수정했습니다. 특히 'bridgeUri'는 http://192.168.1.117:8080에 할당되어 농부들이 우리의 사설망에 연결할 수 있습니다. 또한 'seedList'에는 renter 노드의 정보가 채워졌습니다. 예를 들어, storj://192.168.1.117: 4000/337472da3068fa05d415262baf4df5bada8aefdc는 포트 4000의 renter 노드에 대한 유효한 표현입니다. 채워진 'seedList'는 농부가 초기화된 사설 네트워크의 노드가 되는 데 도움이 됩니다. 또한 농부에게 원격 제어를 제공하는 '데몬' 프로그램은 일반적으로 농부를 초기화하기 전에 실행됩니다. 농부들이 노드가 되자 사설 Storj 네트워크가 구축되었습니다.
Storj Labs는 renter에게 업로드 및 다운로드 기능을 제공하기 위해 Storj API를 기반으로 통합된 클라이언트 애플리케이션으로 프로젝트 'libstorj'를 출시했습니다. 5.2절에서 'libstorj'의 수정을 도입했다는 점을 감안할 때, 이 시점에서 수정되지 않은 버전의 'libstorj'가 192.168.1.120의 로컬 네트워크 컴퓨터에 복제되었다는 점에 유의해야 합니다.
Modification on Storj client
Storj 클라이언트 'libstorj'가 개인 Storj 네트워크에 일반 텍스트 파일을 업로드할 수 있도록 하려면 클라이언트가 개인 브리지를 찾을 수 있어야 합니다. 따라서 아래 코드에서 볼 수 있듯이 ~/libstorj/src/cli.c 파일에서 main 함수의 라인 1155를 먼저 수정했습니다. 이 라인은 클라이언트를 192.168.1.117:8080의 프라이빗 브리지로 전달합니다.
List1 : Setting 192.168.1.117 as bridge
i f ( ! s t o r j _ b ri d g e ) {
s t o r j _ b ri d g e = " h t tp : / / 1 9 2 . 1 6 8 . 1 . 1 1 7 : 8 0 8 0 / " ;
}두 번째로, ~/libstorj/src/upload.c 파일의 1428 및 1603 행에 각각 prepare_frame(..) 및 create_encrypted_file(..) 함수가 저장되어 있는 업로드된 파일의 암호화와 관련된 세 가지 함수를 찾았습니다. body_shard_send(..) 함수는 ~/libstorj/src/http.c 파일의 37행에 저장되었습니다.
이러한 모든 기능은 파일을 암호화하는 또 다른 기능인 ctr_crypt를 호출했습니다. ctr_crypt 함수는 세 가지 암호화 함수 모두에서 유사한 방식으로 구현되었으므로 예제로 prepare_frame(..) 함수에 속하는 Listing 2만 설명했습니다.
이 경우 세 가지 기능을 모두 수정했습니다. ctr_crypt를 호출하면 변수 read_data에 저장된 일반 텍스트 데이터와 cphr_txt 변수에 저장된 암호화된 데이터에 대해 AES256 암호화가 수행되었습니다. 암호화된 데이터가 아닌 일반 텍스트 데이터를 업로드하려고 했기 때문에 암호화된 데이터를 다시 일반 텍스트로 교체하기 위해 암호화 기능 다음에 memcpy 함수를 삽입했습니다. 즉, Storj 클라이언트가 암호화 기능을 성공적으로 수행했음에도 불구하고 Storj 네트워크에 최종적으로 업로드된 데이터는 암호화되지 않은 상태였습니다.
Listing2: Replacing cipher-text with clear-text
// Encrypt data
c t r_c r yp t ( enc ryp ti on_c tx−>ctx , (
n e t tl e_ ci p h e r_ f u n c ∗) aes256_encrypt ,
AES_BLOCK_SIZE, enc ryp ti on_c tx−>
enc r yp ti on_c t r , read_bytes , ( uint8_t ∗)
cphr_txt , ( uint8_t ∗) read_data ) ;
// Replace the cypher−t e x t t o cl e a r −t e x t
memcpy ( cphr_txt , read_data , AES_BLOCK_SIZE ∗2 5 6 ) ;클라이언트가 수정되면 암호화되지 않은 버전의 파일을 개인 네트워크에 업로드하기 위해 컴파일되었습니다.
Account registration
Storj 네트워크에 파일을 업로드하려면 사용자가 브리지에 계정과 암호를 등록해야 합니다. 유효한 사용자 계정과 함께 시스템에는 업로드된 파일을 수용할 가상 버킷이 하나 이상 있어야 합니다. 파일 업로드를 위해 버킷의 고유 ID를 제공해야 합니다. 예를 들어, 우리의 경우 버킷 a01501b963e7b23e9203d206을 생성했습니다.storj upload-file a01501b963e7b23e9203d206
Storj files and data structures
프레임업 공격을 테스트하려면 많은 일반 텍스트 파일이 필요했습니다. 그러나 일반 텍스트 파일의 데이터 세트를 구성하려면 Storj 데이터 구조를 이해해야 합니다.
Storj는 Kademlia File Store(KFS)라는 파일 저장 시스템 내에서 농부의 샤드를 저장하기 위해 Google의 LevelDB를 구현합니다. LevelDB에는 데이터 저장을 위한 .log 및 .ldb 데이터베이스 파일이 포함되어 있으며, 여기에 Storj가 농부의 샤드 내용을 저장합니다. .log 파일에는 데이터베이스에 대한 최신 업데이트/추가 사항이 포함되어 있습니다. .log 파일이 미리 결정된 4MB 크기에 도달하면 파일은 .ldb 정렬 테이블로 변환되며, 이 테이블도 미리 결정된 4MB 크기를 가집니다.
.log 및 .ldb 파일에는 원래의 샤딩된 파일이 아닌 파일에 삽입된 '추가' 바이트가 있습니다. 이러한 추가 바이트는 LevelDB 파일 구조와 관련이 있기 때문에 .log 및 .ldb 파일 내에 있어야 합니다. .log 파일에 나타나는 두 가지 형식의 삽입된 바이트와 .ldb에 두 가지 형식이 있습니다. .log 파일의 경우: 69-71바이트 그룹은 약 128KB마다 나타나고 7바이트 그룹은 32KB마다 나타납니다. .ldb 파일의 경우: 58-60바이트 그룹이 파일 시작 부분에 나타나고 71-73바이트 그룹이 약 128KB마다 나타납니다. 7바이트 시퀀스는 다음과 같이 Leveldb의 사양에서 파생됩니다. .log 파일의 모든 32KB는 '블록'으로 간주됩니다. 각 '블록'은 '레코드' 시퀀스로 구성됩니다: '데이터'의 리틀 엔디안으로 된 crc32c 체크섬, 리틀 엔디안으로 된 데이터 길이, '블록' 유형 및 '데이터'라고 하는 바이트 시퀀스. 7바이트는 4바이트 crc32c, 2바이트 '데이터' 길이, 1바이트 '블록' 유형에서 파생됩니다. 7바이트 다음에는 샤드에서 32KB 이하의 시퀀스가 있습니다. '블록'에 32KB 미만의 '데이터' 섹션이 있는 레코드가 있는 경우 다른 레코드가 해당 '블록' 내에 있을 수 있습니다. 따라서 하나의 .ldb 또는 .log 파일에 여러 샤드/파일의 '블록'이 포함될 수 있습니다.
.ldb 및 .log 파일의 모든 128KB는 샤드의 데이터 '청크'로 간주됩니다. '청크'는 128KB 미만일 수 있습니다. 즉, .ldb 및 .log 파일이 청크 크기보다 작을 수 있습니다. '청크'는 이전 '청크'에서 삽입된 바이트 그룹의 n 인스턴스 추가를 오프셋하기 위해 128KB 표시 약간 뒤에 시작할 수 있습니다. 이러한 '청크'에는 renter 의 다운로드 요청이 있을 때 샤드의 모든 청크를 효율적으로 찾기 위한 고유 식별자가 포함되어 있습니다.
At the beginning of a chunk in a .log file, there is a key, which is a group of 69 to 71 bytes of data containing:
.log 파일의 청크 시작 부분에는 다음을 포함하는 69~71바이트의 데이터 그룹인 키가 있습니다.
the 7-byte grouping, a byte for indicating the chunk’s number/identifier in the .log file, the 12-byte sequence ‘0x000000000000000100000001’, a forward slash followed by the full content’s hash formatted in hexadecimal, a space, a 6-byte numerical index, and 1 to 3 bytes that relate to the chunk’s length.
7바이트 그룹화, .log 파일에서 청크의 번호/식별자를 나타내는 바이트, 12바이트 시퀀스 '0x00000000000000100000001', 슬래시 뒤에 오는 16진수 형식의 전체 콘텐츠 해시, 공백, 6바이트 숫자 인덱스 및 청크 길이와 관련된 1~3바이트입니다.
At the beginning of a chunk in a .ldb file, there is a 9-byte sequence ‘0x000000000100000000’, followed by a 4-byte sequence, followed by ‘0x0037’ followed by a 1-3 byte sequence related to the length of the chunk, a 40-byte key for the file that the chunk relates, a space, a 6- byte chunk index identifier, a 2-byte value that indicates the chunk index identifier in hex format, followed by the 6-byte sequence ‘0x000000000000’.
.ldb 파일의 청크 시작 부분에는 9바이트 시퀀스 '0x000000000100000000', 4바이트 시퀀스, '0x0037', 1-3바이트 시퀀스의 길이와 관련된 시퀀스가 있습니다. 청크, 청크와 관련된 파일의 40바이트 키, 공백, 6바이트 청크 인덱스 식별자, 16진수 형식으로 청크 인덱스 식별자를 나타내는 2바이트 값, 6바이트 시퀀스 '0x000000000000' '.
KFS에 대한 이러한 사전 지식을 바탕으로 테스트에 사용된 일반 텍스트 파일은 전체 파일이 하나의 샤드에 들어갈 수 있는 GovDocs4 데이터 세트에서 선택되었습니다. 샤드는 추가 바이트를 포함하여 4197472바이트(약 4.1MB)여야 합니다. 우리는 JPG, GIF, 사진용 PNG를 포함하여 널리 사용되는 15가지 파일 유형 각각의 20개 파일을 수집했습니다. 비디오용 AVI, FLV, MOV, MP4, MPG; 문서용 TXT, DOC, PDF, XLS 및 압축 파일용 ZIP, GZIP, BZ2. 총 300개의 파일이 수집되었으며 GitHub 리포지토리5에서 찾을 수 있습니다.
Frameup attack testing and results
이 섹션에서는 Storj 네트워크의 전체 프레임업 공격 프로세스를 보여줍니다. 먼저 암호화되지 않은 파일을 농부에게 업로드하는 기능을 확인하는 데 사용되는 예비 공격을 제시합니다. 다음으로 공격 범위와 영향력을 높이기 위해 공격을 지속적으로 최적화한 방법을 설명합니다. 두 공격 모두에 대해 테스트 파일 데이터 세트에서 일반 텍스트 파일을 업로드하고 파머 노드에서 샤드가 복구 가능하고 가시적이며 실행 가능한지 수동으로 확인했습니다.
Preliminary attack(예비 공격)
예비 공격은 프레임업 공격의 초기 단계이다. 이 공격에서 우리는 다음을 결정하려고 했습니다: 1) 업로드 시 원본 파일의 일반 텍스트 버전으로 되돌리도록 설계된 수정된 버전의 Storj 클라이언트인 경우 2) 일반 텍스트 파일의 콘텐츠가 샤드에서 발견될 수 있는 경우 3) 일반 텍스트 파일을 열고 농부에서 볼 수 있는 경우.
먼저 두 개의 농부 노드를 등록하고 사용할 수 있도록 했습니다. 그런 다음 각 파일에 대해 storj upload-file a01501b963e7b23e9203d206
성공적인 업로드 알림 후, 우리는 샤드를 검사하기 위해 개인 Storj 네트워크의 컴퓨터 192.168.1.126에서 ~/.config/storjshare/shares/68336ce3f8b3ad5052c4259bbbde707057ee8cb2/ sharddata.kfs 가 /68336ce3f8b3ad5052c4259bbbde707057ee8cb2/ sharddata.kfs 및 ~/.config/storjshare/shares/ d1f5b48e687be49f9472c3eeca0099030cc8ae6b/ sharddata.kfs 를 공유하는 폴더에 액세스했습니다.
폴더 내에는 'xxx.s'라는 이름의 수백 개의 하위 폴더가 있었고 여기서 'xxx'는 농부가 생성한 고유 번호였습니다. 이 숫자 폴더 각각은 샤드 파일을 저장했습니다. 예비 공격을 확인하기 위해 두 농부가 저장한 샤드 파일을 수동으로 검사했습니다.
예상대로 업로드된 파일의 콘텐츠가 이전에 설명한 추가 KFS 생성 데이터와 함께 샤드에서 일반 텍스트로 발견되었습니다. 다음으로 우리는 복구 가능하고 볼 수 있도록 프레임업 공격에 적합한 샤드 수를 수동으로 테스트했습니다. 워크로드를 줄이기 위해 대부분의 샤드에 대한 파일 서명을 식별하고 활용했습니다. 예를 들어, 샤드의 첫 번째 바이트가 JFIF인 경우 샤드는 .jpg 파일로 간주되고 적절한 그래픽 파일 API를 사용하여 파일을 엽니다. 그러나 이전에 설명했듯이 샤드에는 여러 파일의 데이터가 포함될 수 있습니다.
따라서 샤드 파일이 알려진 파일 서명으로 시작하지 않는 경우 실행기로 드래그하기 전에 다른 파일 확장자를 시도했습니다. 조사관이 여전히 '인식'할 수 있었던 그림 4에 표시된 부분적으로 손상된 그림(샤드)과 같이 샤드를 실행하거나 실질적으로 인식할 수 있는지 여부만 테스트했습니다.
대부분의 조각은 인식할 수 없었습니다. 샤딩 프로세스 중에 추가된 추가 데이터로 인해 파일을 인식할 수 없게 되었습니다. 예를 들어, JPG 파일 구조에는 의미를 식별하는 마커가 있는 세그먼트가 포함되어 있습니다. 마커가 수정(또는 이동)되면 마커 다음에 오는 세그먼트의 의미로 인해 파일이 손상될 수 있습니다. AVI, MPG 및 PDF와 같은 소수의 파일 형식만이 비교적 높은 실행률을 생성했습니다. 다양한 유형의 파일에 대한 실행 가능한 샤드의 수는 표 1에 나열되어 있습니다.
샤드에서 TXT 파일의 내용을 찾았지만 하나의 TXT 파일 데이터가 여러 샤드 파일 간에 분리될 수 있습니다. 따라서 TXT 파일이 예비 공격에 적합하다는 결론을 내리기는 하지만 표 1에는 포함하지 않았습니다.
실험 결과는 공격자가 무의식적으로 농부에게 일반 텍스트 파일을 업로드할 수 있음을 확인하지만 표 1에서 볼 수 있듯이 공격은 몇 가지 파일 유형에 대한 가독성 관점에서만 효과적입니다(the attack is only effective from a readability standpoint for a few file types). 즉, 많은 파일 형식이 샤딩 프로세스 동안 추가된 추가 바이트를 견딜 수 없습니다. 따라서 우리는 Optimized attack 에서 파일 콘텐츠 무결성과 사용성을 더 잘 유지할 수 있는 최적화된 공격을 제안합니다.
Optimized attack
이론적으로 추가 데이터가 삽입된 파일이 손상되더라도 데이터는 손실되지 않습니다. 오히려 데이터가 이동하고 있습니다. 따라서 이러한 삽입 지점에서 논리적 분할이 있도록 파일을 처리하면 문제를 일으키는 추가 데이터를 무시하면서 이러한 부분을 원본 파일로 결합할 수 있습니다. 샤드를 열고 실행할 때 포함된 데이터를 우회하기 위해 HTML 캡슐화를 제안합니다.
특히 원하는 파일을 base64 일반 텍스트로 변환하고 인코딩하여 테스트 파일을 HTML 파일에 포함합니다. 추가 데이터가 삽입될 위치를 미리 계산하고 추가 데이터를 열 때 무시될 유효한 HTML 주석으로 변환하기 위해 적절한 위치에 주석 문을 미리 제작합니다.
따라서 추가 데이터는 더 이상 파일의 가독성을 손상시키지 않습니다. 또한 파일 내용을 문자열 변수에 저장하고 Javascript를 사용하여 파일 내용을 엽니다. 이는 Listing3에 나와 있습니다.
Listing 3: Base64 encoded image in HTML with string segmentation
<!DOCTYPE html>
<html>
<script language=" Javascript ">
var str0 = " <img src= \" data:image / png;base64 ," +
"iVBORw0KGgoAAAANSUhEUgAAAM0AAADNCAMAAAAsYgRbAA" +
"AAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccll" +
"PAAAABJQTFRF3NSmzMewPxIG // ncJEJsldTou1jHgAAAAR" +
"BJREFUeNrs2EEKgCAQBVDLuv + V20dENbMY831wKz4Y / VHb" +
"/5 RGQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0" +
"NDQ0PzMWtyaGhoaGhoaGhoaGhoaGhoxtb0QGhoaGhoaGho" +
"aGhoaGhoaMbRLEvv50VTQ9OTQ5OpyZ01GpM2g0bfmDQaL7" +
"S+ ofFC6xv3ZpxJiywakzbvd9r3RWPS9I2 + MWk0 + k"
/*
#### Byte Injection Space ####
##{[8|  -/53853 dc1313238a0a508bba3b9f274e3a3fb3
a4f 000000  ############
*/
var str1 = " bf0Hih9Y17U0nTHibrDDQ0NDQ0NDQ0NDQ0" +
"NDQ0NTXbRSL / AK72o6GhoaGhoRlL8951vwsNDQ0NDQ1ND" +
"c0WyHtDTEhDQ0NDQ0NTS5MdGhoaGhoaGhoaGhoaGhoaGh" +
"oaGhoaGposzSHAAErMwwQ2HwRQAAAAAElFTkSuQmCC \">"
document.firstline = str0 + str1 + "\n "
</script>
<body>
<script>
document.open()
document.write(document.firstline)
document.open()
</script>
</body>
</html>HTML로 캡슐화된 base64 일반 텍스트 데이터는 추가된 데이터의 영향을 받지 않으며 인터넷 브라우저에서 이미지를 표시할 수 있습니다. 그러나 모든 유형의 파일이 브라우저에서 표시되는 것은 아니기 때문에 이러한 브라우저에서 표시하기에 적합하지 않은 파일 유형을 처리하는 기능을 추가했습니다.
여기에서 업로드된 샤드는 웹 서버에서 대상 파일을 자동으로 다운로드하거나 사용자에게 로컬 다운로드 요청을 표시하는 브라우저에서 파일을 열도록 설계된 HTML 파일로 구성됩니다. AVI, FLV, MOV, MPG, DOC, XLS, PDF, ZIP, GZIP 및 BZ2 파일 형식에 이 파일 복원 기술을 적용했습니다. 이 기술은 지금까지 부과된 4MB 샤드 크기 제한보다 큰 파일을 업로드하는 데에도 사용할 수 있습니다.
Listing4: Javascript code for files embedded into HTML file to be
automatically downloaded on browser
<!DOCTYPE html >
<html >
<body >
<script >
function base64Img2Blob ( code ){
// convert Base64 data to Blob data for IE.
var parts = code.split ('; base64 ,');
var contentType = parts [0]. split (':') [1];
var raw = window.atob ( parts [1]) ;
var rawLength = raw.length;
var uInt8Array = new Uint8Array ( rawLength );
for (var i = 0; i < rawLength; ++ i) {
uInt8Array [i] = raw.charCodeAt (i );
}
return new Blob ([ uInt8Array ] ,{ type: contentType
}) ;
}
function detectBrowser () {
// detect which Browser the HTML is executed on.
var userAgent = navigator.userAgent;
if ( userAgent.indexOf (" Firefox ") > -1 ) { return
" Firefox "; }
if ( userAgent.indexOf (" Trident ") > -1 ) { return
" IE "; }
if ( userAgent.indexOf (" Chrome ") > -1 ) { return
" Chrome "; }
}
var blobObject = new Blob ( [ base64Img2Blob ("
data:image / png;base64 , iVBORw0KGgoAAAA... ") ]) ;
// base64 data of the uploaded file.
if ( detectBrowser () === " IE ") { // If executed on IE
window.navigator.msSaveOrOpenBlob ( blobObject , '
example.png ');
} else { // If executed on Firefox or Chrome
url = window.URL.createObjectURL ( blobObject ) ;
a = document.createElement ('a');
a.download = ' example.png ';
a.href = url;
document.body.appendChild ( a);
a.click () ;
}
</script >
</body >
</html >Listing4는 다운로드 기능이 있는 HTML 파일의 예를 보여줍니다. IE(Internet Explorer)는 앵커() 태그 요소를 지원하지 않기 때문에 코드는 detectBrowser() 함수에 의해 브라우저가 IE인지 감지하도록 구성되었습니다.
IE 브라우저의 경우 데이터를 Blob 개체로 변환하기 위해 base642Blob() 함수에 base64 데이터를 제공한 다음 다운로드 기능을 활용하기 위해 blob을 함수 window.navigator.msSaveOrOpenBlob(..)에 전달해야 했습니다. 다른 브라우저의 경우 다운로드를 위해 <a> 요소를 만들었습니다.
최적화된 공격을 테스트하기 위해 준비 단계에서 생성된 다른 두 농부 노드를 활성화했습니다. 파머 노드의 ID/폴더 이름은 5a2f433555261377396036672418f765b51f0de9 및 f33e0bfe6eaa263bf2eb08b9d919c80ac5c30157입니다. 다음으로, 일반 텍스트 파일을 적절한 HTML로 변환하고 개인 Storj 네트워크에 업로드했습니다.
이러한 방식으로 브라우저에서 임베디드 파일을 표시하거나 다운로드할 수 있는지 테스트하기 위해 두 파머 노드에서 모든 샤드를 수집하고 샤드 확장자를 '.html'로 변경하고 IE로 열어 보았습니다. 우리의 결과는 표 2에 나와 있습니다. 최적화된 공격은 모든 파일 유형을 업로드하고 성공적으로 읽는 데 실행 가능하지만 모든 경우는 아닙니다.
평균적으로 업로드된 파일의 55% 이상을 샤드 파일을 실행하여 찾아서 복구할 수 있습니다. 예비 공격과 달리 성공적으로 다운로드되어 브라우저에 표시되는 샤드가 모두 원래의 완전한 무결성을 유지하는 것은 아닙니다.
Attack evaluation with FTK
Frameup attack testing and results 에서 우리는 예비 공격과 최적화된 공격을 모두 사용하여 파일 샤드의 인식 가능성(recognizability)을 테스트했습니다.
그러나 모든 증거를 수동으로 테스트하는 것은 실제 포렌식 조사의 표준 관행이 아닙니다. 따라서 이 섹션에서는 FTK 6.2.1에서 샤드를 로드하여 프레임업 공격을 테스트하고 평가했습니다. FTK가 다양한 기능을 제공하지만 테스트는 대부분 일반 텍스트 파일 또는 대부분 눈에 띄는 부분 일반 텍스트 파일의 복구와 관련된 데이터 조각 기능에 의존합니다. 궁극적으로 우리는 경험적으로 다음과 같이 결정했습니다. 1) FTK로 복구할 수 있는 일반 텍스트 파일의 수, 2) FTK를 사용한 실제 조사에서 샤드 내에서 일반 텍스트 파일의 발견과 관련된 프로세스의 어려움.
FTK에서 '프로파일 처리'에서 '데이터 조각' 기능이 활성화되면 이상적으로는 샤드에서 지원되는 유형의 파일을 조각합니다. 데이터 세트에서 지원되는 파일 유형은 JPEG, HTML, PDF, GIF, PNG 및 ZIP입니다. FTK에는 IE 브라우저 API가 내장되어 있기 때문에 조사관은 조각된 일반 텍스트 파일을 화면에서 미리 볼 수 있습니다.
수동 테스트(표 1에 표시된 결과)와 비교할 때 FTK는 샤드에서 더 많은 일반 텍스트 파일을 검색했습니다. 구체적으로 말하면, 동일한 12개의 DOC, 17개의 JPG, 11개의 PDF, 4개의 GIF, 15개의 PNG 및 10개의 XLS 실행 파일이 두 농부 모두에서 조각되었습니다. 파일이 부분적으로 손상되었지만 조각된 것으로 계산하기 위해 최종 사용자가 볼 수 있는 콘텐츠의 최소 50% 이상을 임계값으로 사용했습니다.
반면에 최적화된 공격으로 생성된 샤드를 처리할 때 FTK는 일반 텍스트 파일을 검색할 수 없었습니다. FTK의 내장 IE API를 사용하여 파일 내용을 표시할 때 Javascript가 실행되지 않았습니다. 따라서 일반 텍스트 파일 추출을 위한 조각을 실행하기 위해 조사자는 조각된 파일 조각을 내보내고 FTK 외부 브라우저에서 실행하거나 조사자가 파일에서 파일을 두 번 클릭해야 합니다. 기본적으로 FTK가 외부 브라우저를 통해 파일을 실행하도록 하는 목록 보기로 인해 Javascript가 실행됩니다. 이 접근 방식을 통해 수동 테스트와 동일한 결과를 얻었습니다(Table2 참조).
Figure5 에서 우리는 FTK 테스트의 결과를 보여줍니다. 여기에서 X축은 데이터세트(TXT 파일은 포함되지 않음)에 있는 일반 텍스트 파일(샤드 파일)의 크기 범위를 나타내고 Y축은 해당 샤드 크기까지 파일의 누적 백분율입니다. 이 두 가지 공격에 유효합니다. 녹색 점은 예비 공격을 받고 있는 농부를 나타냅니다. 크기가 500KB 이하인 파일의 경우 전체 파일의 23.21%가 유효했습니다. 크기가 1000KB 이하인 파일의 경우 모든 파일의 23.93%가 유효했습니다. 일반 텍스트 파일이 500KB에 도달하면 유효한 샤드의 수가 점근적이 됩니다. 즉, 최적화된 공격은 더 큰 일반 텍스트 파일에 대해 더 나은 작업을 수행했으며 일반적으로 더 높은 성공률을 달성했습니다.
요약하면 FTK 테스트는 다음과 같은 공격의 장점과 단점을 공개했습니다.
Preliminary attack: Advantage: FTK와 같은 포렌식 도구가 사용되는 한 조사관이 일반 텍스트 파일을 발견하기 위한 추가 단계가 없습니다. Disadvantage: 1) 상당히 작은 크기의 일반 텍스트 파일에서만 작동합니다. 2) 관심 있는 모든 파일 유형을 기본적으로 지원하지 않을 수 있는 포렌식 도구의 데이터 조각 기능에 의존합니다. 3) 일부 샤드가 공격에 유효하더라도 무결성을 보장할 수 없습니다.
Optimized attack: Advantage: 1) 다양한 크기의 일반 텍스트 파일에 대해 똑같이 잘 작동합니다. 2) 실행 가능한 코드(예: 악성 자바스크립트)는 무결성이 보장된 농부들에게 업로드될 수 있습니다. Disadvantage: 모든 파일 효과가 구현되도록 HTML 파일과 Javascript를 포렌식 도구 외부의 브라우저에서 실행해야 합니다.
https://github.com/decrypto-org/blockchain-papers
https://cs.paperswithcode.com/search?q_meta=&q_type=&q=blockchain
구글 스칼라