드라이버 분석할때 정보

참조 : http://mylabs.tistory.com/m/post/17

여기서 중요한점은 

[ 디스어셈블 하고자 하는 드라이버의 EP부터 트레이싱 하기 위한 방법 ]
    - EP의 첫 바이트를 CC(int 3)으로 변경, checksum 을 수정 (커널 드라이버 로드시, 체크섬값 검사)
    - breakpoint 가 설정된 곳에서 멈추면, 해당 바이트를 다시 원래 코드로 수정
    - Trace 시작~!

 자, 감염된 상태의 시스템에서 로드된 NDIS가 악성인지 아닌지 어떻게 알수 있을까?!
 가장 간단하게 섹션의 정보 부터 확인해보자.

에서 드라이버를 분석하기위해 ep부분에 cc로 변경 후 다시 원래 바이너리로 수정하는거

---------------------------------------------------------------------------------

 작성한 6월 보안칼럼에서 ndis.sys를 변조시키는 악성코드에 관해서 언급했었다.

 당시 Sality 파일바이러스 심층분석으로 골머리를 썩고있는 상황이어서, 미루고 미뤄두었던 악성코드이다.
 CodeEngn 2009에서 고흥환님께서 발표하신 내용중에 일부이기도 한 악성코드이다. 
 간단하게 분석한 내용을 적어본다.

 [ Win32.Protector.A ~ C ]
 정상파일을 변조시키는 행동은 파일바이러스와 일맥상통하는 부분이지만, 추가적인 2차 감염을 발생시키지는 않는다.
 Virut 파일 바이러스들 중 일부가 ndis.sys 커널 드라이버를 변조시키는 사례가 많이 발생됐었다.
 그리고 최근에 다시 이슈화 된 AntiVirus 2010 계열의 허위백신은 같은 골격으로 ntfs.sys를 변조시키며,
 해외와 국내에 agp440.sys도 변조되고 있는 상황이다.

 커널드라이버 악성코드는 윈도우시스템에 필수 드라이버 파일인 ndis.sys 와 ntfs.sys 등 여러 드라이버를 타겟으로 하고있으며, 이는 여타 다른 드라이버파일도 안전할수 없다는 것을 의미한다.
 변조된 악성코드는 정상 드라이버의 이름을 가지고 있기때문에 커널 로드시 악성코드가 그대로 같이 메모리에 올려진다.
 커널에 로드된 악성 ndis.sys는 정상 ndis와는 확연히 다른 형태의 PE인것을 한눈으로 확인이 가능하며, 실행되어진 상태의 메모리 모습이기 때문에 최종으로 복호화 되어진 HEX값 역시도 확인 가능하다.

 변조된 드라이버 파일을 이용하여 시스템을 감염시켜보자.

 아래의 [그림1] 은 

 변조된 드라이버파일이 로드된 시스템을 windbg 커널 디버그 모드로 Attach 시킨 후에 로드된 NDIS 주소값이다.  
   [그림1] kernel에서의 NDIS드라이버가 로드된 주소값

 
 ndis.sys 의 EP(Entry Point) 부터의 어셈블리코드
   [그림2] Disassembly EP : f839c500

[ 디스어셈블 하고자 하는 드라이버의 EP부터 트레이싱 하기 위한 방법 ]
    - EP의 첫 바이트를 CC(int 3)으로 변경, checksum 을 수정 (커널 드라이버 로드시, 체크섬값 검사)
    - breakpoint 가 설정된 곳에서 멈추면, 해당 바이트를 다시 원래 코드로 수정
    - Trace 시작~!

 자, 감염된 상태의 시스템에서 로드된 NDIS가 악성인지 아닌지 어떻게 알수 있을까?!
 가장 간단하게 섹션의 정보 부터 확인해보자.

 먼저 정상 NDIS의 섹션정보를 보자.
  [그림3] 정상 NDIS의 섹션정보

 정상 ndis는 위와 같은 섹션 정보를 헤더에 가지고 있지만, 감염된 상태의 ndis는 확연히 차이나는 섹션구조를 가지고 있다.

  [그림4] 변조된 NDIS의 섹션정보
 [그림4] 는 windbg에서 커널에 로드된 상태의 헤더부분이지만, 실제 변조된 ndis 파일의 헤더정보도 위와 동일한 형태를 취하고 있다. (변종에 따라 INIT 섹션이 있는 경우도 있다.)


 이 글을 포스팅하기 한참전에 로직은 이미 완성된 상태였다. 최초엔 진단명을 특정 드라이버파일만을 변경한다는 의미에서 
Mndis, Mntfs 등으로 만들었지만,,, 동일한 감염로직으로 최근 다른 드라이버들도 피해를 보고있는 실정이다. 
 그래서 보편적으로 사용하고 있는 Protector 진단명으로 변경하게 되었다. Protector 진단명은 최초 카스퍼스키에서 만든것으로 추정되며, 진단명은 악성코드의 디버그 정보를 참조한 것 같다.
  - Conficker 도 그랬고, 대부분의 악성코드 제작자가 Release 버젼이 아닌 debug버젼으로 컴파일해서 배포를 하는듯 한데, 그 과정에서 파일상에 정보가 조금씩 남는 경우가 많다.

  [그림5] 파일상에 남아있는 디버그 정보
 

 [ Protector 주요 특징 ]

[그림6] 메모리상에 복호화된 정상 NDIS
 [그림1] 에서 로드된 드라이버 메모리를 잘 살펴보면, 또 하나의 PE 파일이 붙어있는 것을 볼수 있다. 눈으로 확인 가능한 것은 암호화된 내용이 메모리에는 복호화 되어 올라가기 때문이다. ( 커널에서 로드시에 이미 해당 루틴들을 다 수행한 상태이기 때문 )

 

 Protector.A~C 는 전체적인 구조는 같으나, 정상
 드라이버파일을 품고있는 암호화 로직이 다르다.
 

 

 

 대표적인 샘플A의 코드는 아래 [그림7] 과 같다.

빨간색으로 표시해둔 부분이 주요 코드 부분이다.

 복호화에 필요한 로컬 변수들을 초기화 하고, 구하는 루틴들을 포함하고 있으며, EP부터 조금 아래 부분을 살펴보면 똑같은 함수를 호출하는 부분을 볼 수 있다.
 바로 그 두번의 호출이 복호화 루틴인 것이다.

 복호화 로직은 아주 간단하며, 어셈을 조금만 공부하면 간단하게 풀수있는 로직이다.

 복호화는 두번의 호출로 정상 driver와 악성 driver를 복호화 하며, 특히 ndis.sys가 변조된 파일의 악성 driver는 IoCallDriver를 Hook하는 루틴을 포함하고 있다. 이는 안티바이러스 제품들의 접근을 회피하기 위한 방법으로 사용된다. 
 AntiVirus2010 에 의해서 변조되는 ntfs.sys 와 agp440.sys 는 IoCallDriver Hook 루틴이 없으며, 일반적인 로직으로 접근 및 원복이 가능하다.

 일반적인 Winapi로 파일을 접근할 시엔 감염된 상태를 정상적인 상태로 보여주면서 진단을 회피하게 된다.
  
 [그림7] 변조된 드라이버파일의 코드
 

  // 분명히 스킨부분의 소스를 고쳐서 글자색을 검은색으로 했는데,, 언제부턴가 회색으로...@.@
      다시 다 검은색으로 바꾸는 엄청난 작업을... 
      Tistory 어렵네요... 괜찬은 팁이 있으신 분은 알려주세요~! ㅠ