[ccibomb@CRG]# _bykim



 3-3-3. 로그파일 수정한 Shell Script 복구하기 (Keyword Searching)

ii. clear_log.txt 내용 확인
(각 이미지의 „/var/log/messgaes‟ 들어간 부분의 앞뒤 10줄씩이 모두 저장되어있는 text 파일)

     iii. clear_log.txt 중 로그파일 수정 script 추측되는 부분 확인
           (당연히 script 전체가 아닌 부분만 있다. 앞뒤 10줄만 출력한 것이기 때문이다.)

     iv. 공격코드의 일부가 있는 행의 앞, 뒤 Line 수를 여러 번 수행해보며 Script 전체를 확인해본다.

      v. 찾은 공격코드

     vi. Keyword Searching 기법을 사용하는 경우 (포렌식 관점) :

로그파일을 생성하거나 수정한 실행 파일을 찾거나(지워진 경우 복구하거나),
환경설정파일을 참조한 실행파일을 찾거나(지워진 경우 복구하거나),
이미 삭제된 루트킷 설치한 script 파일을 복구하거나(설치된 파일들의 이름을 아는 경우에만 가능),
지워진 로그 파일이나 히스토리 파일을 복구하는 등 활용분야가 넓다.

4. 참고문헌

 
      http://old.honeynet.org/challenge/index.html

      http://www.ibm.com/developerworks/kr/library/au-speakingunix14/index.html

      http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.files/doc/aixfiles/inode.h.htm

      http://lefoot.egloos.com/tag/inode/page/1

      http://wiki.kldp.org/Translations/html/The_Linux_Kernel-KLDP/tlk9.html

 

기술문서_삭제된파일복구.pdf

3-3.  inode 가 남아있지 않는 경우 (Data Carving)

위의 3-2처럼 ils와 icat 가지고 복구할 수 없는 경우가 있다. inode table 자체가 깨진 경우이다. 이에 해당하는 경우에 사용할수 있는 방법이 있다.

바로 carving 기법이다. carving 이란 inode 가 남아있지 않아 복구가 복잡해졌을 때 쓰는 방식으로, 여러가지 기술이 있다.

예를 들자면, 파일의 signature를 통해 파일의 시작점을 찾을 수 있다.  jpeg의 경우 처음이 FF D8이고 끝부분(trailer)이 FF D9이다. 파일의 끝점까지 찾아서 해당 부분을 dump를 뜨는 것이 가장 완벽한 방법이나, 끝점을 찾는 것은 매우 힘들다. Jpeg과 같이 끝점에도 signature가 있는 경우는 거의 없기 때문이다. 따라서 size 정보 또는 파일의 최대 size를 이용하여 시멘트 카빙을 한 후 유의미한 data만 추출하는 방법을 사용한다.

시멘트 카빙의 경우 data가 연속배열 되어 있지 않으면 유의미한 결과를 얻을 수 없으나, 최근 hdd 용량의 대량화로 대부분 연속배열 되어있기 때문에 유용하게 사용가능하다.

이해를 돕기 위해, 직접 file 형태로 된 shell script 를 모두 복구해보는 예제를 들어보겠다. 위에서 실습을 위해 다운로드 받았던 이미지 파일 5개(honeypot.hda5.dd 등)로부터, 로그 파일을 조작한 후 삭제된 shell script를 복구해보겠다.

따라해보며 개념을 익히기 바란다.

3-3-1. Data Carving 시 사용할 Tool 설명

        i. fsstat : Block 사이즈 살펴보기

       ii. sigfind : 디스크 상에서 signature를 포함한 Block을 찾는 툴

<사용법>  sigfind -o (offset) -b (block size) signature image위치

eg. sigfind 로 BR 찾기 (BR의 signature는 511, 512 번째에 '55 AA')

     iii. blkcat : 해당 Block을 Dump 하는 툴

(script 가 한 개 블록임을 가정한다. 넘어가면 짤린다.)

eg. blkcat honeypot.hda5.dd 3698    // 3698번 Block 스크립트를 보여준다.

iv. sigfind와 blkcat 툴을 사용하기 위해서는 sleuthkit 을 설치해야한다.

1.    Sleuthkit Tool을 download 받는다.

            2. 압축을 풀어 INSTALL.txt 파일을 열어본다.

3.    그대로 따라하며 설치한다.

 3-3-2. 로그파일 수정한 Shell Script 복구하기

(Sleuthkit의 SIGFIND, BLKCAT Tool을 활용)

*. sigfind, blkcat 툴을 사용하여 shell script 파일을 싹 다 복구한 후, 로그파일을 수정한 script만 찾아내보도록 하겠다.

-> 만약 이 방법으로 나오지 않는다면, script 가 파일로 존재 하지 않는 것이므로 keyword searching 을 하는 수밖에 없다.

i. 각 이미지의 Block Size를 추출하는 쉘코드 작성 (Sigfind Tool 사용시 Block Size를 알아야 하기 때문)

 
ii. 추출한 fsstatdata의 Block Size 확인

//   honeypot.hda1.dd 의 Block Size : 1024
      honeypot.hda5.dd 의 Block Size : 4096

      honeypot.hda6.dd 의 Block Size : 4096
      honeypot.hda7.dd 의 Block Size : 1024
      honeypot.hda8.dd 의 Block Size : 1024 

iii. honeypot.hda1.dd 등에 있는 모든 script 파일을 dump

             (sript 파일의 사이즈가 하나의 Block을 넘어가지 않는다고 가정하며,
              Sleuthkit의 sigfind와 blkcat Tool을 사용하도록 한다.)

script 여부 확인 방법 : sigfind를 통해 script 파일의 맨앞 (#!/bin/sh or #!/bin/bash) 의 4byte 인 23212f62('#!/b'의16진수 변환.)까지를 시그너춰로 보자. (sigfind의 signature 는 4 byte까지밖에 못준다.)

c.f) 16진수 변환 방법 : echo '문자' | xxd : 출력 중 0A는 엔터임

 쉘스크립트 파일이면서 var/log/message (로그파일 저장) 문자열을 포함하는 파일을 추려서 저장하는 기능 추가

<그림 27. /var/log/message 문자열 포함 Shell Script 추출>

v. iv의 Shell Script 실행 결과 :

         hda5(/usr) 이미지에 일치하는 파일 1개 존재 확인

     hda8(/ : root) 이미지에도 일치하는 파일이 1개 확인

vi. 찾은 공격 스크립트 (1 block 에 해당하는 script 만 찾음)

iii.  삭제된 inode 복구하기

1.   지워진 inode 중, 한번이라도 쓴 inode 찾기

 * 복구의 조건 :

· st_alloc(2번째 필드) : data block의 상태를 표시해준다.
                           f 즉 free (사용가능) 이어야 복구 가능

                 c.f) st_alloc 이 a (allocated)인 경우는 inode가 이미 새로운 data 저장을 위해 할당되어있는 상태임을 의미하므로 복구가 불가능하다.

· st_size(11번째 필드) : 0보다 클 것 (data 가 있음을 의미)

· 주의 : 필드는 1번부터 세고, 0은 전체를 나타낸다.

c.f) ' ' : 쿼팅제한! 필드구분자 -F '|'

 

awk(자동화툴)  : 필드를 처리하는 툴 중 하나다. -F는 Field Separater를 뜻한다. 여기에서 필드를 구분해주는 것이 |이므로 '|'로 나타낸다. 두번째 필드가 f이고, 11번째 필드의 값이 0보다 커야 하므로 (왜냐하면 virgin inode가 아닌, 한번이라도 쓴 inode를 찾아서 빼기 위해서이다.)

<awk의 사용법>

     awk [옵션] '스크립트' [변수=값] [파일(들)]

    or

  awk [옵션] -f 스크립트 파일 [변수=값] [파일(들)]

 

ils 명령어(숨겨진 데이터를 찾기) : ils는 마운트 되어 있는 디바이스의 inode 정보를 리스트로 만들어주며, 또한 삭제된 inode 정보를 확인할 수 있다.

  <ils 옵션>

  -e : 파일 시스템의 모든 inode 정보를 리스트로 만들어 준다.

-f : 파일시스템 타입을 정의한다. 거의 모든 UNIX 시스템의 기본 파일 시스템은 ffs(Berkeley fast file system)이며, 리눅스는 기본적으로 ext2fs(second extended file system)을 사용하고 있다.

-o : 아직 열려있거나 실행중인 삭제된 파일들의 inode 정보를 만들어준다.(-aL과 동일)

-r : 삭제된 파일들의 inode 정보를 만들어 준다.(-LZ와 동일)

-v : 상세 모드 출력(stderr)

-V : 상세 모드 출력(stdout)

2.   icat 을 사용하여 해당 inode를 파일로 복구하기

 

2-1.  icat honeypot.hda5.dd 2254 > a
         : 2254 번 inode를 a란 파일로 복구

c.f) icat : inode 숫자에 해당되는 내용을 파일로 복사하기 위해서(보통 삭제된 파일의 inode 번호 사용) icat을 사용한다. 여기서 2254는 확인된 삭제된 inode 번호이다.

 

2-2.  icat honeypot.hda5.dd 140839 > 140839
         : 140839 번 inode를 원래의 것으로 복구

                  2-3. 위처럼 inode 번호를 일일이 커맨드에 대입하는 것이 아니라, Shell script를 써서 모든 파일을 복구해보자.

                   2-4.  r을 실행해보자. 실행권한이 없다고 표시될 것이다.

                       2-5.  chmod u+x ./r : r명령의 실행 Permission을 받는다.

 

                       2-6. r 명령을 실행하면 복구가 완료됨을 볼 수 있다.

3. 실습 – 삭제된 파일 복구하기

*. 실습시 사용하는 이미지 다운로드 주소 : http://old.honeynet.org/challenge/images.html

       (challenge-images.tar 압축을 풀어, 다음 이미지를 모두 마운트시킨다.
honeypot.hda1.dd, ~~.hda5.dd, ~~.hda6.dd, ~~..hda7.dd, ~~.hda8.dd )

3-1.  Bitmap 에서 inode 를 사용한다(1) 표시된 경우

-> 해당 inode 를 따라가서 data 덤프하면 파일 복구

3-1-1. Bell FS

* bitmap은 super block에 위치.

3-1-2. EXT3 방식

Cylinder Group 구조 : 앞에 깨지면 뒤의 것을 가져다 복구. 퍼포먼스를 위한 구조이다.

3-1-3. EXT2 방식

앞서 “2-4. EXT2 파일시스템 구조 분석”에서 다룸

3-2.  Bitmap 에서 inode를 사용하지 않는다(2) 표시된 경우

3-2-1. 한 번도 사용하지 않은 inode (Vergin inode) -> 복구할 필요 X
              사용했다가 지워진 inode -> index를 따라가 해당 data block 을 dump 떠서 복구함

3-2-2. 실습을 따라하며 원리를 익혀보자.

i. ls -ali 명령을 통해 inode와 기타 부가정보를 볼 수 있다.

-a : all의 뜻으로 시스템에 숨겨져 일반 사용자에게 나타나지 않는 파일을 포함한 모든 파일과 디렉토리 이름들을 화면에 표준출력

-l : long이라는 뜻으로 파일 및 디렉토리의 표시, 접근(access)에 대한 허가 사항, 링크수, 사용자, 등록명(홈디렉토리) 그리고 파일의 생성 및 최종적으로 수정된 시간과 파일 및 디렉토리 이름을 세부적으로 나열하여 사용자는 보다 더 많은 파일 및 디렉토리에 대한 정보 확인 가능

-i : i-node 번호를 파일 또는 디렉토리 이름 앞에 표준출력

ii. 삭제된 inode 보기

수많은 결과가 나온다. 이 중, 복구 가능한 inode를 선별할 필요가 있다. 다음에서 복구의 조건을 살펴보도록 한다.

c.f) 삭제된inode를 살필 때 사용한, ils 명령어를 살펴보자.

1. ils : ils는 마운트 되어 있는 디바이스의 inode 정보를 리스트로 만들어준다.

2. -r 옵션 : 삭제된 파일들의 inode 정보를 만들어준다.

3. Inode 번호, allocation, size, … 등 여러가지 필드가 있다.

2-4-5. EXT2 파일 시스템에서 파일 찾기

     리눅스 파일 이름은 다른 유닉스의 파일 이름과 같은 형식으로 되어 있다. 이름은 앞에 슬래시('/')가 붙은 디렉토리 이름이 이어지고 마지막에 파일 이름이 오는 형태이다. 예를 들어, 파일 이름이 /home/rusling/.cshrc이라면, /home과 /rusling은 디렉토리 이름이고 파일 이름은 .cshrc이다. 다른 모든 유닉스 시스템과 마찬가지로 리눅스는 파일 이름 자체의 형식은 신경쓰지 않는다. 길이 제한도 없고, 인쇄 가능한 아무런 문자로 구성된다. 이 파일을 나타내는 inode를 EXT2 파일 시스템 안에서 찾기 위해, 시스템은 파일 이름을 해석해서 한 디렉토리씩 처리하여 파일 자체를 얻게 된다.

     처음 필요한 inode는 파일 시스템의 루트의 inode로, 그 inode 숫자값은 파일 시스템의 수퍼 블럭에서 얻는다. EXT2 inode를 읽기 위해서는 해당하는 블럭 그룹의 inode 테이블에서 찾아야 한다. 예를 들어 루트 inode의 번호가 42라면 우리는 블럭 그룹 0의 inode 테이블의 42번 째 inode가 필요한 것이다. 루트 inode는 EXT2 디렉토리를 위한 것이다. 다시 말해서 루트 inode의 모드는 루트 inode가 디렉토리임을 나타내며 데이터 블럭에는 EXT2 디렉토리 엔트리가 들어 있다.

     home은 여러 디렉토리 엔트리 중의 하나일 뿐 이며 /home 디렉토리를 나타내는 inode의 번호를 알려준다. 이 디렉토리를 읽어서 (디렉토리를 읽으려면 우선 inode를 읽고 그 inode 가 가리키는 데이터 블럭으로부터 디렉토리 엔트리를 읽어야 한다.) rusling 엔트리를 찾으면 그 엔트리는 /home/rusling 디렉토리를 나타내는 inode의 번호를 알려줄 것이다. 마침내 우리는 /home/rusling 디렉토리를 나타내는 inode가 가리키는 디렉토리 엔트리를 읽어서 .cshrc 파일의 inode 번호를 찾은 다음, 이 번호를 이용하여 파일의 내용을 갖고 있는 데이터 블럭을 가져오게 된다.

※ “ /dir/file.txt “ 를 inode를 이용해 찾아가기!

1 루트 디렉토리의 inode 번호는 2번 (ext)

2 루트 inode의 index block을 통해 Dir inode를 알아냄

3 dir inode의 index block을 통해 file inode를 알아냄

4 file inode의 index block을 통해 DATA를 찾음!

2-4-1. EXT2 inode

EXT2 파일 시스템에서 inode는 가장 기본이 되는 단위이다. 파일 시스템의 모든 파일이나 디렉토리는 각기 단 하나의 inode에 의하여 표현된다. 각 블럭 그룹을 위한 EXT2 inode는 어떤 inode가 할당되었는지 아닌지를 추적하기 위한 비트맵과 함께 inode 테이블에 저장된다. <그림 2. EXT2 inode>는 EXT2 inode의 형태를 보여준다. 저장되는 정보에는 다음과 같은 항목이 있다.
 

• 모드(mode) 여기에는 이 inode가 어느 파일에 해당하는지를 나타내는 정보와, 접근권한을 나타내는 정보가 저장된다. EXT2에서 하나의 inode는 하나의 파일, 디렉토리, 심볼릭 링크, 블럭 장치, 문자 장치 또는 FIFO를 나타낸다.
• 소유자 정보(Owner Information) 이 파일 또는 디렉토리에 대한 사용자와 그룹 식별자이다. 이 정보를 이용하여 파일 시스템은 접근권한을 제대로 관리할 수 있게 된다.
• 크기(Size) 파일의 크기를 바이트 단위로 가지고 있다.
• 타임스탬프(Timestamps) inode가 만들어진 시간과 최종적으로 수정된 시간을 기록한다.
• 데이터블럭(Datablocks) 이 inode가 표현하고 있는 데이터가 저장된 블럭에 대한 포인터. 맨 앞의 열두개의 포인터는 이 inode가 표현하고 있는 데이터를 저장한 실제 블럭에 대한 포인터이며 마지막 세개의 포인터는 점점 더 높은 수준의 간접적인 연결을 갖고 있다. 예를 들어, 이중 간접 블럭 포인터(double indirect block pointer)는 데이터 블럭에 대한 포인 터들의 블럭에 대한 포인터들의 블럭을 가리키고 있다. 따라서, 길이가 12개 데이터 블럭 이하인 파일은 그 보다 큰 파일보다 훨씬 빨리 액세스 된다. Data Block 사이사이에 Directory Block 존재한다. 

EXT2 inode는 특별 장치 파일을 표현할 수도 있다는 점에 주목하여야 한다. 이들 파일은 실제 파일은 아니지만 장치를 액세스하는데 사용되는 프로그램을 다룬다. /dev 디렉토리 아래 의 모든 장치 파일은 프로그램이 리눅스 장치를 액세스할 수 있도록 하기 위하여 거기에 있는 것이다. 예를 들어 마운트 프로그램은 마운트하려는 장치 파일을 인자로 사용한다.

    2-4-2. EXT2 수퍼블럭(Superblock)

    수퍼블럭에는 그 파일 시스템의 정보(기본적인 크기나 모양에 대한 설명)가 들어 있다. 이를 이용하여 파일 시스템 관리자는 파일 시스템을 활용하고 유지한다. 보통 파일 시스템이 마운트 될 때에는 블럭 그룹 0에 들어 있는 수퍼블럭을 읽어들인다. 하지만, 모든 블럭 그룹에는 똑같은 복사본이 있어서 파일 시스템이 깨지는 경우를 대비하고 있다. 여기에 들어 있는 정보에는 다음과 같은 것들이 있다.
 

• 매직 넘버(Magic Number) 이 값은 마운트하는 소프트웨어로 하여금 이것이 진짜 EXT2 파일 시스템의 수퍼블럭이라는 것을 확인케한다. 현재 버전의 EXT2에서는 0xEF53으로 되어 있다.
• 개정 레벨(Revision Level) 메이저 개정 레벨과 마이너 개정 레벨로 구성되며, 마운트 프로그램이 어떤 특정한 버전에서만 지원되는 기능이 이 파일 시스템에서 지원되는지 아닌지를 확인하는데 사용된다. 또한 기능 호환성 항목라는 것이 있어서 마운트 프로그램이 이 파일 시스템에서 안전하게 사용할 수 있는 기능이 무엇인지를 판단할 수 있도록 해준다.
• 마운트 횟수(Mount Count)와 최대 마운트 횟수(Maximum Mount Count) 이 두 개의 값을 이용하여 시스템은 파일 시스템 전부를 검사할 필요가 있는지를 확인할 수 있다. 마운트 횟수는 파일 시스템이 마운트될 때 마다 1씩 증가하며, 그 값이 최대 마운트 횟수와 같아지면 "최대 마운트 횟수에 도달하였습니다, e2fsck를 실행하는 것이 좋습니다"라는 메시지가 표시된다.
• 블럭 그룹 번호(Block Group Number) 현재 보고 있는 수퍼블럭 복제본을 갖고 있는 블럭 그룹의 번호.
• 블럭 크기(Block Size) 이 파일 시스템의 블럭 크기를 바이트 단위로 (예를 들어, 1024 바이 트) 표시한다. 1회 I/O 가 이루어지는 양을 의미한다.
• 그룹당 블럭수(Blocks per Group) 하나의 그룹에 속하는 블럭의 수. 블럭 크기와 마찬가지로 파일 시스템을 만들때 정해진다.
• 프리 블럭(Free Blocks) 파일 시스템내의 프리 블럭의 수.
• 프리 Inode(Free Inode) 파일 시스템내의 프리 inode의 수.
• 첫번째 Inode(First Inode) 파일 시스템내의 첫번째 inode의 inode 번호. EXT2 루트 파일 시스템에서 첫번째 inode는 "/" 디렉토리에 대한 디렉토리 엔트리이다.

2-4-3 EXT2 그룹 기술자(Group Descriptor)

    각 블럭 그룹은 자신을 기술하는 자료구조를 가지고 있다. 수퍼블럭과 마찬가지로 모든 블럭 그룹을 위한 그룹 기술자는 각 블럭 그룹에 복제되어 파일 시스템이 파괴되는 경우를 대비한다. 그룹 기술자는 잇달아 나타나서 전체적으로는 하나의 그룹 기술자 테이블을 형성한다. 각 블럭 그룹에는 수퍼블럭 바로 뒤에 그룹 기술자 테이블 전체가 놓여있다. EXT2 파일 시스템 에서 실제로 사용되는 것은 (블럭 그룹 0에 있는) 첫번째 복사본 뿐이다. 다른 복사본들은, 수퍼블럭의 복사본들과 마찬가지로, 원본이 깨질 경우를 대비하고 있다.

각 그룹 기술자는 다음과 같은 정보를 갖고 있다.
 

• 블럭 비트맵(Blocks Bitmap) 이 블럭 그룹에서 블럭의 할당 상태를 나타내는 비트맵으로서 블럭의 수 만큼 있다. 이것은 블럭을 할당하거나 해제할 때 사용된다.
• Inode 비트맵(Inode Bitmap) 이 블럭 그룹에서 inode의 할당 상태를 나타내는 비트맵으로서 블럭의 수 만큼 있다. 이것은 inode를 할당하거나 해제할 때 사용된다.
• Inode 테이블(Inode Table) 이 블럭 그룹의 inode 테이블의 시작 블럭으로서 블럭의 수 만큼 있다. 각 inode는 다음에 설명하는 EXT2 inode 자료구조에 의해 표현된다.
• 프리 블럭 갯수(Free Blocks Count), 프리 Inode 갯수(Free Inode Count), 사용된 디렉토리 갯수(Used Directory Count)

 c.f) 슈퍼 블록과 그룹 디스크립터 테이블은 파일 시스템 전체에 대한 정보가 들어가기 때문에 그룹마다 똑같은 내용을 갖게 된다. (복구 용이)

2-4-4. EXT2 디렉토리

• inode 이 디렉토리 엔트리에 해당하는 inode. 이 값은 블럭 그룹의 inode 테이블에 저장되어 있는 inode 배열에 대한 인덱스이다. 그림 9.3 에서 file이라는 이름의 파일에 대한 디 렉토리 엔트리는 i1이라는 번호의 inode를 참조하고 있다.
• 이름 길이(name length) 이 디렉토리 엔트리의 길이를 바이트로 나타낸다.
• 이름(name) 이 디렉토리 엔트리의 이름.

c.f) 모든 디렉토리에서 처음 두 엔트리는 항상 "." 과 ".." 이다. 이는 각각 "현재 디렉토리" 와 " 부모 디렉토리" 를 의미한다.

2-4. EXT2 파일시스템 구조 분석

<그림 3>은 EXT2 파일 시스템이 블럭 구조로 된 장치에서 블럭을 어떻게 차지하고 있는지 배치 상태를 보여준다. 파일 시스템에 관한 한 블럭 장치는 그저 읽고 쓸 수 있는 일련의 블럭일 뿐이다. 파일 시스템은 실제 매체의 어느 곳에 블럭이 씌어야 하는지에 대해 신경 쓸 필요가 없다. 그것은 디바이스 드라이버가 알아서 할 일이다. 파일 시스템이 그 파일 시스템을 담고 있는 블럭 장치로부터 정보나 데이터를 읽으려고 한다면 단지 해당 디바이스 드라이버에게 몇 개의 블럭을 읽어달라고 요청하기만 하면 된다. EXT2 파일 시스템은 자신이 차지하고 있는 논리적인 파티션을 다시 블럭 그룹으로 쪼갠다. 각 블럭 그룹은 파일 시스템에서 무결성의 핵심이 되는 정보를 중복해서 갖고 있으며, 실제 파일과 디렉토리를 정보와 데이터의 블럭으로 갖고 있다. 이 중복은 파일 시스템이 깨지는 등의 재난이 발생해서 파일 시스템의 복구가 필요할 때 필수적이다.