Mafia의 진실
Mafia의 진실 2010.02.10

낚시성 제목에 방문하신 분께는 죄송합니다. 이 글은 오래전부터 twitter 사용자들을 대상으로 퍼져나가고 있는 'Mobster world'라는 온라인 MMORPG 게임과 관련된 글입니다. 트위터 사용자 분들 중에는 위와 유..

iPhoto 슬라이드 쇼

트위터에 질문이 하나 올라와 짧게 작성해봤습니다. iPhoto에서 슬라이드 쇼 생성하는 방법입니다. 1. 먼저 사진 메뉴에서 슬라이드 쇼에 추가할 사진을 선택합니다. 사진 선택은 Command 키와 마우스를 이용합니다. 2...

노키아에서 동작하는 Mac OS X 10.3

핀란드에 사는 Toni Nikkanen이라는 분이 자신의 Nokia N900 모델에 Mac OS 10.3 Panther를 설치하고 실행시키는데 성공했다고 합니다. Toni의 블로그에 가보니 Mac OS X 말고도 Windows..

침해 대응 & 컴퓨터 포렌직에 관련한 첫번째 글이네요 ^^; 오늘은 간단한 팁에 가까운 테크닉을 하나 소개할까합니다. 사실 외국에서는 일반화된 지식같은데 혹시나 해서 잠깐 검색을 해본 결과로는 국내에 관련된 글이 없는 듯 해서 올려봅니다.  

개 요
침해 대응 또는 컴퓨터 포렌직을 목적으로 시스템을 조사하는 경우 빼놓을 수 없는 조사 대상 중 하나가 로그 파일입니다. 이러한 로그 파일 분석은 삭제되거나 저장 매체에 잔존하는 로그 파일의 복구, 손상된 로그 파일 복원, 조작 가능성 판별,  로그에 나타난 공격 시그너춰분석, 통계 정보 추출, 로그와 로그 간 상관관계 분석, MAC time 분석 등 다양한 기법과 기술을 필요로 하는 작업입니다. 오늘 주제는 바로 이 로그 분석과 관련 있습니다. 뭐 다 다룰려면 한두 꼭지의 글로 되겠습니까? ^^;  이 글에서 다룰 내용은 제목 그대로 "윈도우 이벤트 로그 리페어 기법" 입니다. 어려운 것 별로 없구요... 제목만 보고 "와~"하시면 다 읽고 나셔서 "뭐야이게" 하실수도..(허무금지 ^^) 시작해 볼까요?


이벤트 로그 내부 구조 사~알짝 살펴보기
이벤트 로그 파일을 완전히 해부하려는 것은 아니구요~ 이벤트 로그 리페어에 필요한 간단한 내용만 알아보도록 하겠습니다. [그림 1]은 %systemdir%\system32\config\SecEvent.evt 파일을 WinHex로 오픈하여 살펴본 내용입니다. 부담없이 살펴보면 됩니다.

먼저 이벤트 로그 헤더 파일은 총 48bytes(0x30)로 구성되어 있습니다. 전체 48bytes 중 처음 4bytes와 마지막 4bytes는 헤더 사이즈입니다.

오프셋 4~7까지는 MS 공식 사이트에는 Reserved라고 표현되어 있습니다. 하지만 좀 더 자세히 읽어보면 아래와 같이 항상 0x4c664c65(LfLe) 값을 가지는 것을 알 수 있습니다. 이 부분은 이벤트 로그 파일의 시그너춰로도 활용할 수 있는 부분입니다.

오프셋 32~35까지의 데이터는 이벤트 로그 파일의 최대 크기를  나타냅니다.

오프셋 36~39까지는 Status byte입니다. 이벤트 로그 리페어에 있어 중요한 역할을 하는 필드이므로 잘 알아둘 필요가 있습니다. 이 필의 값은 보통 09, 0B, 08, 00 중 하나를 가지는데 09,0B는 현재 이 파일이 오픈되어 있음을 의미합니다. 이 필드의 값이 09또는 0B인 상황에서 Event Log API를 이용하는 프로그램(예 이벤트로그 뷰어)을 이용하여 파일을 오픈하려고 시도하면 에러가 발생합니다. 08과 00은 파일이 클로즈되어 있음을 의미합니다. 이벤트 로깅 서비스를 정상적으로 종료하는 경우 이 필드의 값은 08로 설정되며 이벤트 뷰어에서 "Save Log File As"를 이용하여 파일을 저장한 경우 새롭게 생성된 로그 파일의 이 필드 값은 00이 됩니다.

   

사용자 삽입 이미지

      [그림 1] 이벤트로그 헤더의 모양1


[그림 2]를 보면서 중요한 몇 몇 필드를 좀 더 살펴보도록 하겠습니다.

오프셋 16~31까지의 16bytes는 이벤트 로그 리페어에 있어 핵심적인 부분입니다. 각각 4bytes의 크기를 가지는 4개의 필드는 아래 그림에서 볼 수 있는 것처럼 "가장 오래된 이벤트 로그의 오프셋","다음 생성할 이벤트 로그의 오프셋","다음 생성할 이벤트 로그의 아이디", "가장 오랜된 이벤트 로그의 아이디"를 의미합니다. [그림 2]에 나타나 있는 데이터에 적용시켜 보면 가장 오래된 즉 가장 먼저 생성된 이벤트 로그의 오프셋은 헤더 바로 뒤에 존재하며(오프셋이 48byte), 새롭게 생성할 이벤트 로그의 오프셋 역시 헤더 바로 뒤에 존재함을 알 수 있습니다. 다시 말해 생성된 로그가 없다는 거죠. 예에서는 새롭게 생성될 이벤트 로그가 바로 최초로 생성되는 로그이며 로그 ID는 1이라는 것도 알 수 있습니다. 

사용자 삽입 이미지
     [그림 2] 이벤트 로그 헤더의 모양2


이벤트 로그 리페어와 관련하여 알아두어야 할 것이 하나 더 있는데, 바로 [그림 3]에 있는 floating footer입니다. 이러한 이름이 붙인 데에는 물론 이유가 있습니다. 말 그대로 이벤트 로그 파일의 끝을 나타내는 footer인데 로그가 새롭게 생성될 때마다 그 위치가 자꾸 변경되기 때문에(뒤로 밀리겠죠) floating이라는 형용사를 갖다 붙인거죠. floating footer는 40bytes 사이즈를 가집니다.  Floating 포인트 역시 헤더와 마찬가지로 처음 4bytes와 마지막 4bytes는 footer size값입니다. 오프셋 4byte 지점부터 보이는 11 11 11 11 ~ 44 44 44 44까지는 변하지 않는 값으로 저장매체 상에서 floating 포인터를  식별하는 시그너춰로 활용됩니다. 그 다음 오프셋 20byte~23byte, 23byte~27byte, 28byte~31byte, 32byte~35byte는 이벤트 로그 헤더 내 오프셋 16byte~31byte 사이에 존재하는 4개의 필드와 정확하게 일치하는 값을 가집니다. 만약 헤더와 footer에 존재하는 이 필드들의 값이 일치하는 않는 경우 이벤트 로그 API를 사용하는 프로그램들은 파일이 커럽트 된것으로 인지합니다.


사용자 삽입 이미지
   [그림 3] Floating footer


이벤트 로그는 왜 깨지는가?
이미 앞에서 다 알아본 내용이므로 간단히 정리해 보도록 하겠습니다. 흔히 "이벤트 로그가 깨졌다" 즉 커럽트되었다는 메시지는 다음과 같은 상황이 그 직접적인 원인이 됩니다.

* 이벤트 로그 헤더의 status byte 값이 00 또는 08이 아닌 경우
   - 이는 파일이 정상적으로 클로즈되지 않았음을 의미합니다. 예를들어 이벤트 로그 서비스가
     활성화되어 있는 상황에서 갑자기 시스템이 다운되었다든지 하는 경우겠죠.
     음..FBI 포렌직 매뉴얼에 보면 피의자를 컴퓨터를 조사하려는 경우 사진 팡~찍고
     바로 전원 플러그를 뽑도록 되어있습니다. 가능한 데이터가 변경되는 상황을 최소화하기
     위한 조치이죠. 증거 능력을 인정받는데도 중요하구요. 하지만 이런식으로 시스템을 종료
     시키면 이벤트 로그 헤더의 status byte 값이 변경되지 않아 이벤트 뷰어등 이벤트 로그
     API를 사용하는 프로그램을 이용하여 로그를 조사할 수가 없게 되는 것입니다.

     반대로 컴퓨터 전원을 끄지 않은 상태에서 증거를 수집하였을 때도 이런 상황이 발생할 수
     있습니다. 이벤트 로깅 기능이 활성화 되어 있는 상태에서 단순히 이벤트 파일만을 복사해  
     온다면 복사본의 staus byte값이 변경되지 않은 채로 남아있게 되는 거죠.

* 이벤트 로드 헤더안의 Oldest Event Log Offet, Next Event Log Offset, Next Event ID, Oldest
   Event ID 필드의 값과 floating footer안에 있는 대응되는 각 필드의 값이 일치하지 않는 경우
   -  새로운 이벤트가 발생하여 로그가 생성되었을 때를 생각해 보세요. 새로운 로그를 기록하는
      작업은 현재 floating footer의 위치에 로그 정보를 기록하고(A) 그 뒤편에 새로운 floating
      footer를 생성하는(B)는 두 단계로 이루어질 것입니다. 이 때 (A)작업을 마치고 (B)작업을
      시작하기 전에 프로그램이 비정상 종료된다든지, OS가 멈추다든지 하게 되면
      헤더 내의 정보와 footer 안의 정보가 일치하지 않게 될 것입니다. 이러한 경우가 위 상황이
      발생하는 되는 원인 중 하나가 됩니다.

간단한 실험을 통해서 이벤트 로그가 어떻게 커럽트 되는지 알아보고 커럽트 되었을 때의 이벤트 로그의 내부를 확인해 보도록 하겠습니다.

1. 먼저 이벤트 로깅 기능이 활성화 되어 있는지 확인합니다. 활성화 되어 있다면 AppEvent.evt 파일을 그냥 복사해 옵니다.

2. 복사된 AppEvent.evt를 이벤트 뷰어로 열어서 확인해 봅니다.  커럽트 되었다는 메시지만 뜨고 그 내용을 확인할 수가 없을 것입니다.

사용자 삽입 이미지
                [그림 4] 복사한 이벤트 로그 오픈 시 메시지

그럼 Hex 에디터를 이용하여 복사된 AppEvent.evt 파일을 열어서 중요 필드의 내용을 살펴보겠습니다.

사용자 삽입 이미지
[그림 5] 손상된 이벤트 로그 파일의 헤더와 floating footer 비교

대충 이벤트 로그 API가 어떠한 경우에 로그 파일이 손상되었다고 판단하는지 이해되시나요?
사실 맘 같아서 API를 추적하여 커럽트되었는지를 검사하는 루틴을 확인하고 싶지만 ^^; ... 혹 분석 해보시면 저도 알려주세용~


손상된 이벤트 로그 조사 방법
손상된 이벤트 로그를 조사하는 방법에는 로그 파일을 리페어 한 후에 조사하는 방법과 손상된 로그 파일을 수정하지 않고 레코드만 추출하여 조사하는 방법이 있습니다

리페어 후 조사하는 방법
 이벤트 로그 파일을 리페어 하는 방법은 매우 쉽습니다. 이벤트 로그 헤더 정보와 floating footer에 기록된 정보를 동기화 시켜주고 status byte 값을 08 또는 00으로 변경하면 됩니다. 그런 후에는 이벤트 로그 API를 이용한 툴들(이벤트 뷰어나 LogPaser 등)을 이용하여 조사하면 됩니다. 예제로 제공된 파일을 복구해 보도록 하겠습니다.

Hex 에디터로 손상된 이벤트 로그 파일을 오픈한 후 floating footer의 를 찾습니다. 찾을 때는 11 11 11 11 22 22 22 22  33 33 33 33 44 44 44 44 를 시그너춰로 하여 찾으면 되겠습니다. 찾은 후에는 floating footer에 기록된 Oldest Event Offset 부터 Oldest Event ID까지의 값을 복사한 후에 이벤트 로그 헤더의 해당 부분에 덮어 씌우면 됩니다. 그런 다음 status bytes의 값을 08 또는 00으로 수정하면 되는 것이죠. [그림 6]은 이러한 작업을 한 후의 모습입니다.

사용자 삽입 이미지
 [그림 6] 리페어 후 이벤트 로그 헤더와 floating footer의 모습

이제 이벤트 뷰어를 이용하여 파일을 열어보겠습니다.
사용자 삽입 이미지
 [그림 7] 복구 후 성공적으로 오픈한 모습

물론 자동화된 툴을 이용할 수도 있습니다. GrokEvtfixevt등이 대표적인 프로그램들입니다.
사용법은 단순하므로 생략합니다.
 
레코드를 직접 추출하여 조사하는 방법
앞에서 사용한 방법의 단점은 어찌되었든 커럽트된 이벤트 로그 파일을 조작해 한다는 것입니다. 포렌직 하시는 분들이 싫어할 만하죠. 그래서 같이 사용하는 방법 중에 이벤트 로그 API를 사용하지 않는 프로그램을 이용하여 수행합니다. 물론 하나씩 하나씩 분석해 볼 수도 있겠지만 현실적으로 거의 불가능하여 대부분은 Perl이나 Python같은 스크립트를 활용합니다.

(스크립트는 잠시 후에 추가하겠습니다. 밥먹으러 가야해서.. ^^;)

맺음말
간단한 팁 정도 수준의 내용이지만 알아두시면 매우 유용합니다. 로그 분석에 관련된 내용은 꾸준히 강좌를 올리도록 하겠습니다. 모두 행복한 하루 되세요.


Posted by zesrever

BLOG main image
Slow but Steady, Broad and Deep ... by zesrever

공지사항

카테고리

분류 전체보기 (44)
Digital Forensics (4)
Reverse Engineering (21)
Vulnerability (2)
Secure Coding (0)
Book Story (1)
Digital Life (7)
My Life (7)
세미나자료 (1)
개인용 (0)
Musics (0)
Total : 261,011
Today : 57 Yesterday : 223