Dropbox 아티팩트조사

개요

클라우드 서비스중 가장 많이 사용되고 있는 서비스이다. 사용자의 컴퓨터에 쉽게 연동해서 파일을 업로드 할 수 있다는점, 최근에는 모바일에서도 업로드/다운로드를 할 수 있다는 점에서 자료유출사고에서는 필요한 조사라고 생각이 된다.

아티팩트

아티팩트 종류

아티팩트명	필요한 정보	경로	사용한 툴
[웹 히스토리]	웹 접근기록	%Profile%\AppData\Local\Google\Chrome\User Data\Default\History %Profile%\AppData\Local\Microsoft\Windows\WebCache
[프리패치]	웹 브라우저 실행기록	%SystemRoot%\Prefetch	Prefetch View
[MFT정보]	파일 상세 경로	$MFT경로	Winhex
[UsnJrnl정보]	파일 생성 정보	\$UsnJrnl\$J	LogtrackerWinhex
[DB]	파일 업로드 관련 이벤트	%Profile%\AppData\Local\Dropbox\instance[NUMBER]\sync_history.db %Profile%\AppData\Local\Dropbox\instance[NUMBER]\home.db->recents테이블 %Profile%\AppData\Local\Dropbox\instance[NUMBER]\home.db->sfj_resources테이블	SQLite Expert

생각보다 많은 아티팩트가 남지 않았다. 업로드를 하는 방식은 크게 웹을 이용한 업로드와 파일탐색기를 이용한 업로드로 구분해서 조사를 해봤다. 결론적으로 사용자의 업로드와 다운로드 행위에 대한 흔적은 남았지만 그 가짓수가 다양하지는 않았다. 웹을통한 업로드 또한 따로 구분이 되는것이 아닌 프리패치에서 웹 브라우저가 실행된 시각과 db파일에 남은 업로드 시간이 근접하다는 것을 통해서 유추하는 방법이 유일했다.

Sync_history.db

1. Direction
   1. Upload: 로컬에서 업로드를 했을때 남는다.
   2. Download: 드롭박스 서버에서 동기화를 위해 다운로드가 되었을 때 생성된다. 예를들자면 웹에서 업로드를 하면 로컬에서는 동기화를 위해 해당 파일을 로컬로 다운로드하는데 이런 경우에 Download로 남는다.
2. File_type_event
   1. Add: 파일이 추가가 되었다는 말이다.
   2. Delete: 삭제가 되었다는 이벤트이다. 예시로 업로드한 파일이 삭제가 된다면 File_type_event에는 delete로 남고 direction에는 Upload로 남게 된다.

UsnJrnl

1. FileReferenceNumber: 파일의 고유번호이다. 드롭박스의 경우에는 파일을 업로드 하면 해당 값이 새롭게 부여가 된다.
2. ParentFileReferenceNumber: 파일의 위치하고 있는 디렉토리의 고유 번호이다. 기본적으로 드롭박스는 C:\<USER_NAME>\Dropbox에 위치해 있는데 해당 디렉토리의 값을 알게되면 참조하기가 더 쉬워진다.

1. 웹을 이용한 업로드

가장 복잡하지만 환경에 제약을 두지 않는 방법이다. 인터넷이 연결되어 있고 유출하려는 파일과 웹브라우저만 있으면 언제 어디서든지 파일을 업로드 할 수 있으며 반대로 다운로드를 할 수 있다는 장점도 존재한다.

1. History
   1. History를 통해서는 웹브라우저를 통해서 드롭박스 홈페이지에 접속을 했단 기록으로 유추할 수 있다. 거의 대부분이 접속하고 로그인하는 과정이고 이 외에 파일을 업로드한 흔적은 찾지 못했다. 따라서 만약 웹 히스토리에 드롭박스에 접속한 기록이 있다면 웹을 통한 자료유출을 의심할 정황으로 생각할 수 있다.
      

      

2. sync_history.db
   1. 웹을 이용했을때 sync_history.db에는 당연히 업로드를 했다는 흔적은 남지 않는다. 하지만 동기화된 항목을 기록하는 db파일이기 때문에 웹에서 업로드된 파일을 로컬과 동기화를 위해 다운로드 된 흔적은 남게 된다. 이런 흔적이 남게 된다면 유출이 의심되는 자의 다른 컴퓨터나 모바일 기기에 대해서 추가적인 조사가 필요할 것이다.
      
   2. 가장 오른쪽에 남은건 timestamp이다. Sync_history.db에서는 유닉스 타임스탬프를 사용하고 있다. DCode라는 시간형식 변환 프로그램을 사용해서 위의 사진의 시간 값인 1605305079를 변환해 본다면다음과 같이 2020년 11월 14일 오전 7시 4분 39초라는 시간 값이 나오게 된다
      

      

      
      (예시로 찍어둔 스크린 샷이 오래전에 업로드한 파일이라 그렇다.)

2. 워드파일에서 바로 로컬에 있는 드롭박스로 저장

파일을 업로드 하는 방법중에 가장 쉬운방법은 사용하고 있던 응용프로그램이나 파일 탐색기를 통해서 바로 업로드를 하는것이다. 드롭박스를 로컬에 마운트 시켜둔후에 작업하는 문서파일등을 바로 해당 경로에 저장을 하게 되면 자동으로 업로드를 할 수 있어서 업무의 편의성에 도움이 된다. 따라서 파일을 로컬에서 드롭박스로 업로드 하는 방법을 조사해 봤다.

1. UsnJrnl, Sync_history.db
   1. 파일을 복사 붙여넣기를 통해서 업로드를 해보았다.
   
2. 새 텍스트 문서.txt라는 파일은 새롭게 생성된 파일이기 때문에 File_Created라는 이벤트를 통해서 생성이 되고 0x000500000002F83F라는 FileReferneceNumber가 부여된다 그 후에 같은 파일을 upload copy and paste.txt라는 파일로 이름을 변경하고 (같은 레퍼런스 넘버를 가지고 있다) 이 파일을 복사하여 드롭박스 디렉토리에 붙여넣기를 하였다.
3. 결과적으로 해당 파일은 새로운 File_Created이벤트로 저장이 되고 0x0001000000002F9B5라는 새로운 레퍼런스 넘버가 부여된다.
4. 파일을 업로드 후에 삭제를 해보았다.

삭제를 하더라도 여전히 UsnJrnl과 Sync_history.db에는 남아있는 모습을 볼 수 있다.

다만 Sync_history.db에는 delete라는 File_type_event로 남아서 해당 파일이 삭제 되었다는 증거가 남게 된다. Sync_history.db는 로컬과 계정간의 연동을 끊더라도 파일이 유지가 된다는 장점이 있지만 이벤트를 저장하는 갯수에는 제한이 있어서 모든 업로드와 다운로드 이벤트를 저장하고 있지는 않다.

결론

사내에서 로컬을 통한 파일 유출은 쉬운일이 아니지만 데이터 유출 방지 시스템이 적용되지 않는 스타트업이나 중소기업에서는 충분히 발생할 수 있는 사항이다. 특히 드롭박스는 모바일과의 동기화도 간편해서 가장 많이 사용되고 있는 클라우드 서비스중 하나이다. 드롭박스에서의 업로드와 다운로드의 이벤트가 많이 남지는 않아서 아쉽지만 한번쯤은 정리할 가치가 있다고 생각했다. 드롭박스 외에도 구글 드라이브나 아이클라우드같은 클라우드 서비스를 통한 유출행위에서는 어떠한 아티팩트가 남는지는 충분히 연구할 가치가 있다고 생각한다.

 

원본 글

https://www.notion.so/Dropbox-709230fc989e4ba2980cb1763e868404