Written by n0fate
on 

Google Drive Forensics (Mac OS X)

최근에 디지털 포렌식 동향 관련한 자료를 수집하다보니, 작년부터 올해까지는 클라우드 스토리지(Cloud Storage)에 대한 포렌식 분석 기술이 상당히 많이 올라와 있음을 알게되었다.

최근에는 스마트폰이나 노트북 등 한명의 사용자가 다수의 스마트 디바이스를 제어하다보니, 하나의 작업을 여러 디바이스에서 같이 해야하는 필요성이 높아졌다. 클라우드 스토리지는 이러한 점을 충족시킬 수 있는 제품으로,  예전에는 Dropbox, Copy와 같은 해당 솔루션만을 제공하는 전문업체에서만 서비스를 제공했으나, 올해부터 구글, 마이크로소프트, 아마존 등의 대형 IT 업체가 이러한 서비스를 제공하기 시작했다.

클라우드 스토리지에 대한 분석 글은 매우 잘 되어있고, 많이 공개되어 있다. 하지만 대부분의 분석 글이 Windows 중심으로 기술되다보니, 다른 운영체제 특히 클라이언트로 윈도 다음으로 많이 사용되는 Mac OS X에서는 어떠한 정보가 어느 위치에 있는지에 대한 정보를 알 수 없었다. 이에 본 포스팅에서는 이러한 클라우드 스토리지 중 하나인 구글 드라이브의 아티팩트를 확인해보고자 한다. 물론 땡기면, 드롭박스나 아마존 클라우드 스토리지도 진행할 예정이다.

일단 클라우드 스토리지가 어떤 개념인지 간단히 알아보도록 하자.

1. 클라우드 스토리지

클라우드 스토리지는 기업형 네트워킹 저장소(networked enterprise storage) 모델로 데이터가 사용자의 컴퓨터에만 남는 것이 아니라 가상화된 스토리지에도 함께 저장되도록 한다. 가상화된 스토리지는 대형 데이터센터에서 여러 개의 스토리지를 묶어서 관리되며, 클라이언트가 저장하는 데이터를 보관한다. 최근의 클라우드 스토리지는 사용자 요청 시 데이터를 롤백하거나, 복원하는 기능도 내장하고 있다.

이러한 스토리지 서비스는 크게 다음과 같은 요소에 디지털 흔적을 남긴다.

 

2. 구글 드라이브

구글 드라이브는 2012년 4월에 공개된 파일 저장소이며 동기화 서비스를 제공하는 클라우드 스토리지이다. 구글 드라이브의 특징은 다음과 같다.

구글 드라이브는 기본적으로 15기가를 제공하며, 기존의 많은 구글 독스 사용자가 이용하기 때문에 생각보다 많은 사용자가 이용하는 서비스이다. 특히, 구글 드라이브는 파일 포맷 구분없이 모든 파일을 업로드하고 공유할 수 있다.

Google Docs

 

3. 포렌식 아티펙트 분석

클라우드 스토리지 포렌식을 진행할 땐 공통적으로 다음과 같은 요소를 식별해야 한다.

  1. 사용자 계정 정보(아이디, 패스워드, 이메일 등)
  2. 클라우드에 저장된 파일의 메타 정보
  3. 클라우드에 저장된 파일의 컨텐츠

여기에선 각 요소 별로 분석을 진행하도록 한다.

1. 사용자 계정 정보

구글 드라이브는 사용자 계정 정보를 Mac OS X의 키체인 시스템(Keychain System)에 저장한다.

Keychain : Google Drive

키체인 시스템에 대한 설명은 이전에도 많이 했으니 여기에선 간략하게 설명하겠다.

키체인 시스템은 Mac OS X에서 사용하는 수많은 애플리케이션의 패스워드를 통합 관리하기 위한 것으로 단순히 계정을 통합 관리하는 것 뿐만 아니라, 높은 보안 수준으로 관리하고 있다. 이 시스템을 이용함으로, 각 애플리케이션은 키체인에 새로운 키 엔트리를 생성하고 그곳에 사용자 아이디와 패스워드를 저장한다. 애플리케이션은 각 엔트리에 접근할 때마다 사용자의 허락을 받아야 한다. 사용자가 선택할 수 있는 건 크게 3가지이다.

항상 허용 : 해당 애플리케이션의 정보가 키 엔트리에 저장되어, 앞으로 키 엔트리에 해당 애플리케이션이 접근하는 경우에는 사용자 고지 없이 접근이 가능하다.

허용 : 1회성 허용으로, 추 후 재접근 시 다시 사용자에게 접근을 요청한다.

거부 : 애플리케이션이 접근하지 못하도록 한다. 1회성이다.

키체인 시스템에 저장된 키 엔트리는 chainbreaker로 분석할 수 있다. chainbreaker로 사용자의 'login.keychain' 파일을 분석하여, 구글 드라이브의 사용자 ID와 Password를 평문으로 획득할 수 있다. chainbreaker를 이용한 분석 방법은 이 블로그에 작성한 다음 연재를 통해 확인할 수 있다.

 

2. 클라우드에 저장된 파일의 메타 정보

구글 드라이브는 클라우드에 저장되는 각 파일의 메타 정보를 하나의 데이터베이스 형태로 유지한다. 해당 데이터베이스는 "/Users/<username>/Library/Application Support/Google/Drive"에 위치한다.

drwxr-xr-x 15 n0fate staff 510 8 3 19:56 .
drwxr-xr-x 3 n0fate staff 102 7 23 16:51 ..
-rw------- 1 n0fate staff 3245 8 3 19:56 cacerts
drwxr-xr-x 5 n0fate staff 170 8 3 19:56 cloud_graph
drwxr-xr-x 2 n0fate staff 68 7 23 16:51 CrashReports
drwxr-xr-x 3 n0fate staff 102 7 23 16:52 FinderExt.bundle
-rw-r--r-- 1 n0fate staff 0 8 3 19:56 lockfile
drwxr-xr-x 3 n0fate staff 102 7 23 16:52 mach_inject_bundle_stub.bundle
-rw-r--r-- 1 n0fate staff 20480 7 23 16:51 snapshot.db
-rw-r--r-- 1 n0fate staff 32768 8 4 14:26 snapshot.db-shm
-rw-r--r-- 1 n0fate staff 829000 8 3 19:56 snapshot.db-wal
-rw-r--r-- 1 n0fate staff 5120 8 3 19:56 sync_config.db
-rw-r--r-- 1 n0fate staff 32768 8 4 14:26 sync_config.db-shm
-rw-r--r-- 1 n0fate staff 12608 8 3 19:56 sync_config.db-wal
-rw-r--r-- 1 n0fate staff 2124254 8 21 13:37 sync_log.log

이 디렉터리에는 2개의 데이터베이스에 주요 정보를 저장한다.

그런데 한가지 특이한 점이 있다. 위에서 설명한 두 개의 데이터베이스를 보면, 동일한 이름의 'db', 'db-wal', 'db-shm' 파일이 존재한다. file 명령어로 확인해보면 db는 sqlite database이고 나머지 두 파일은 그냥 data로 출력된다.

n0fate-MacBook-Air:Drive n0fate$ file snapshot.db*
snapshot.db: SQLite 3.x database
snapshot.db-shm: data
snapshot.db-wal: data
n0fate-MacBook-Air:Drive n0fate$

그리고 db 파일은 스키마 정의만 있을 뿐 안에 아무런 데이터가 저장되어 있지 않으며, sqlite db brower에서도 아무런 정보를 보여주지 못한다.  이는 WAL(Write-Ahead Logging)이 활성화된 SQLite3 Database이기 때문이다.

WAL은 SQLite3 3.7.0에서부터 등장한 개념으로 모든 데이터 트랜젝션을 데이터베이스 파일에 직접 저장하지 않고, Shared Memory Map에 맵핑한 Write-Ahead Logging에 저장하고 필요할 때 한번에 DB 파일에 한번에 커밋하는 기능을 제공한다. 대부분의 데이터 트랜잭션을 메모리에서 처리하고, 애플리케이션의 데이터베이스 정보 요청도 전부 메모리에서 처리하므로 시스템 성능이 향상된다. WAL에 저장된 모든 데이터는 checkpoint라는 명령을 통해서 DB에 저장된다. WAL도 SQLite3 DB와 마찬가지로 페이지 단위로 곡안을 할당하며, 1000페이지가 가득차게 되면 자동으로 checkpoint 명령을 실행하여 WAL의 데이터를 정리한다.

WAL은 SQLite3 DB Browser에서 지원하지 않으므로, checkpoint명령으로 DB에 저장하게 만들어야 한다. 다음과 같은 명령으로 작업을 진행하면 된다.

n0fate-MacBook-Air:Drive n0fate$ sqlite3 snapshot.db
SQLite version 3.7.12 2012-04-03 19:43:07
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> PRAGMA journal_mode=DELETE;
delete
sqlite> .quit

n0fate-MacBook-Air:Drive n0fate$ ls -al | grep snapshot.db
-rw-r--r-- 1 n0fate staff 48128 8 21 16:40 snapshot.db
-rw-r--r-- 1 n0fate staff 32768 8 21 16:39 snapshot.db-shm
-rw-r--r-- 1 n0fate staff 0 8 21 16:40 snapshot.db-wal
n0fate-MacBook-Air:Drive n0fate$

명령어를 수행하면 WAL 파일이 0바이트가되면서 모든 트랙잭션이 반영되어 snapshot.db에 저장된다. 단 이 방법의 경우, WAL에서 저장한 트랜잭션 정보가 반영 안되기 때문에 삭제된 레코드를 복구하고자 할 때는 WAL에 대한 별도의 분석이 필요하다. 외국에서 이 부분에 대한 연구가 진행되고 있는데, 추 후 시간이 좀 나면 정리해보겠다.

SQLite DB Browser로 보면 다음과 같이 테이블 정보를 확인할 수 있다.

SQLite DB Browser

cloud_entry와 local_entry 테이블에는 각각 다음 정보가 저장된다.

Table Name : cloud_entry
[fusion_builder_container hundred_percent="yes" overflow="visible"][fusion_builder_row][fusion_builder_column type="1_1" background_position="left top" background_color="" border_size="" border_color="" border_style="solid" spacing="yes" background_image="" background_repeat="no-repeat" padding="" margin_top="0px" margin_bottom="0px" class="" id="" animation_type="" animation_speed="0.3" animation_direction="left" hide_on_mobile="no" center_content="no" min_height="none"][table]
Column, Description
filename, 구글 클라우드에 저장된 파일명
modified, 수정된 시간 (UTC+0)
created, 생성된 시간 (UTC+0)
doc_type, 문서 타입. Folder(0) 기타 파일(1) Google PPT(2) Unknown(3) Google Form(4) Google Drawing(5) Google Document(6) Google Table(7)
removed, 파일 삭제 여부. 추 후 구글 드라이브는 삭제했던 파일을 복원하는 기능을 가지고 있음
url, 편집할 컨텐츠를 저장한 URL
size, 웹 상의 파일  크기 정보. 구글 문서 형식(gdoc/gsheet/gslide)은 무조건 0으로 저장
shared, 다른 사용자에게 공유 여부
[/table]

Table Name : local_entry
[/fusion_builder_column][fusion_builder_column type="1_1" background_position="left top" background_color="" border_size="" border_color="" border_style="solid" spacing="yes" background_image="" background_repeat="no-repeat" padding="" margin_top="0px" margin_bottom="0px" class="" id="" animation_type="" animation_speed="0.3" animation_direction="left" hide_on_mobile="no" center_content="no" min_height="none"][table]
Column, Description
filename, 로컬에 저장된 파일명
modified, 수정된 시간 (UTC+0)
size, 로컬에 저장된 파일의 크기
[/table]

 

 4. 클라우드에 저장된 파일의 컨텐츠

구글 드라이브는 보통 공유 디렉터리를 "/Users/<username>/Google Drive/"에 위치한다. 구글 드라이브에 저장되는 파일은 메타 정보만 보관하는 파일(gdoc, gsheet, gslide)와 컨텐츠 전체를 로컬에 보관하는 파일(그 외 모든 파일)로 나눌 수 있다.

1. 메타 정보만 보관하는 파일

구글에서 생성한 document, excel, powerpoint는 각각 gdoc, gsheet, gslide 확장자로 로컬에 생성된다. 이 파일은 실제 파일 컨텐츠를 저장하진 않으며, URL과 Resource ID 정보만 담고 있다. 다음은 하나의 gdoc 파일의 내용을 확인한 것이다.

{"url": "https://docs.google.com/document/d/1op6cnFcnjgyhN9hdLKwxGpAwXgc1AV5vhs7DJGvzwYs/edit?usp=docslist_api", "resource_id": "document:1op6cnFcnjgyhN9hdLKwxGpAwXgc1AV5vhs7DJGvzwYs"}

구글 드라이브는 이 파일을 사용자가 더블클릭했을 경우, 웹 브라우저를 실행하면서 URL의 내용을 전달한다. 사용자는 새롭게 띄워진 웹브라우저에서 접속된 구글 드라이브의 문서 편집기로 데이터를 수정할 수 있다.

2. 로컬에 보관하는 파일

1에서 설명한 구글 드라이브에서 만든 문서 파일을 제외한 모든 파일은 드롭박스와 같이 파일 자체를 그대로 저장한다. 이 파일은 디스크 포렌식 기술로 접근하여 데이터를 추출 분석하면 된다.

 

4. 결론

구글 드라이브는 웹에서 문서 편집이 가능하며, 드롭박스와 같이 일반 파일도 관리할 수 있는 편리한 클라우드 스토리지이다. SQLite 데이터베이스에 메타데이터 정보를 가지고 있으며, 클라우드의 데이터와 로컬 데이터의 메타 정보를 각각 다른 테이블에 저장하여, 포렌식 타임라인 분석에 유용하게 사용될 수 있다.

필요 시에는 키체인 정보 복호화 시도를 통해, 구글의 메타데이터만 존재하는 구글 문서 파일의 컨텐츠를 확인할 수도 있으며, 구글의 다른 서비스(유투브, 이메일, 캘린더) 등의 정보를 접근할 수도 있다.

 

 Reference

http://sysforensics.org/2012/05/google-drive-forensics-notes.html