MS 1월달 보안패치가 나온지 몇일 되지도 않았는데 IE 0-Day가 떴네요
취약한 IE버전은 IE5이상 모든 버전이라고 하지만 실질적으로 SP3에서 IE7, IE8은 크래쉬만 일어나네요
(10번 시도에 10번다 크래쉬 // 그렇다고 0%라고 할 수 없는겠죠 - heapspray라서, 사용하는 메모리가 랜덤한 영역에 위치할경우 공격이 통하지는 않겠죠;)
테스트했던 IE6의 경우 10번중 8번 실행되네요


또한, IE8같은경우는 DEP(Data Excution Prevention-데이터 실행 방지) 부분이 디폴트로 적용되어 있어
활성화 되어 있는 경우 임시적으로 공격을 막을 수 있다고 합니다.
사용자 삽입 이미지


다음은 metasploit에서 실행시킨 결과입니다
사용자 삽입 이미지


해당 통신내용의 exploit 코드는 다음과 같습니다. 전형적인 Heapspray로 파악됩니다.
사용자 삽입 이미지

사용자 삽입 이미지

긴급으로 MS에서 패치하지 않는 이상
해당 코드는 현재 v3,알약,바이로봇등으로 탐지가 안되니 IE8로 업그레이드를 수행하시는 것이 좋을 것 같습니다

이제 어떤 DLL의 어떤 함수가 문제가 되는지 찾아봐야 할 것 같네요
올리랑 놀때가 된 것 같습니다.
Posted by 궁상박군
:

일전에 악성코드 분석하다가 Prefetch(이하 한글로 쓰죠~)에 대해서 완전 잘못알고 있다가 낭패를 본 경험이 있습니다

프리패치란 윈도우 부팅될때 윈도우가 사용할 파일들을 메모리에 올리는 것이고, 많은 윈도우 부팅시 지렁이(?) 지나갈 때 느리게 하는거군 이라고만 생각하고 있다가, 악성코드 리버싱 하는 도중에 Filemon 띄어놓고 있다가 pf파일을 만들길래 헉! pf만들어서 윈도우 부팅될때마다 실행되게 하려는구나! 라고 어처구니 없는 생각에 엄청난 삽질을 거듭했죠..;;

결론적으로 뭐 틀린말은 아니지만 위의 문단에서 가장 틀린 부분은 pf를 만든다고 윈도우 부팅될때마다 실행되는건 아니라는 것이지요. 프리패치는 사용자가 윈도우 사용중 어떤 특정 파일을 실행시킬때도 생성하게됩니다-제가 잘못 알고 있던 부분이죠-프리패치 이것도 구조가 꽤 복잡하고 뭐 그렇습니다.

먼저 prefetching이란 windows xp 이후부터 나오는 기술로 어원그대로 '先꺼내기(?)'정도로 해석할 수 있겠습니다.
 (비스타부터는 슈퍼패치라는 기술로 바뀌었어요~)
이때 Prefetching때 사용하는 파일이 프리패치파일이라고 하죠

1. Prefetching이란 Application들의 성능 향상을 위해서 구동에 필요한 데이터들을 메모리에 먼저 올려놓게 하는 것
2. Prefetch란 Prefetching시 사용하는 파일로 메모리에 올려놓으려는 정보를 담고 있는 파일을 말합니다

사용자 삽입 이미지

풀어서 설명하자면 하드디스크를 엑세스 하는 시간이 길어지면 길어질수록 '느리다'라고 할 수 있으니 그러한 작업을 최소화 하고자 데이터를 미리 메모리에 올리는 기술이라고 할 수 있습니다.
그림 아래로 내려갈수록 엑세스 속도가 느려지는 것을 확인할 수 있죠

(아.. 이 그림이 요기잉네? //컴퓨터 개론,구조,운영체제등등 다 포함되는 또 이 그림이야! 라고 하실만 하실테지만서도 이해를 돕고자..)





그렇다면 네이버 지식인님에서 자주 올라오는 "윈도우 부팅속도가 느린데 어떻게 해야하죠" 라는 답변에 "프리패치를 지우세요" 라고 답변 달아주시는 분들은 어떤생각 일까요?

물론, 윈도우는 한번이라도 실행했다면 해당 파일에 pf를 만듭니다. c:\windows\prefetch\에 들어가보시면 알겠지만, 윈도우 업데이트 받았던 것, 이런 파일도 내가 실행시켰던가? 라는 생각이 들 정도로 많은 파일들이 존재하죠

사용자 삽입 이미지

따라서, 프리패치를 지워주는 것이 어떻게 생각하면 좋을 수도 있겠죠;
위의 그림에서 보시면 알겠지만 프리패치 파일은 application_name-hash.pf 형태로 이루어져 있습니다.
(hash에 관한 정보는 다음에 올리겠습니다)

여하튼 프리패치 파일은 사용자의 삭제가 있기전까지는 절대로 지우지지 않습니다. 따라서 침해대응이나 포렌식 관련하여 중요한 정보가 된다고 합니다. 한가지 예로 침해사고가 발생시 해당 시간의 MAC 타임으로 파일들을 검색하였을 경우에 만들어진 프리패치가 있다면, 원본파일이 지워졌어도 공격자가 이런 것을 실행했었구나 얼추 계산할 수 있죠.


포스팅 내용은 이게 아니었는데 사설이 길었군요
그렇다면 본격적으로 프리패치 파일에 어떤 내용이 담겨있나 확인해보겠습니다
(사용된 이미지는 Windows XP SP2, 사용 프리패치는 노트패드로 하였습니다.)

먼저 Winhex로 해당 프리패치 파일을 오픈하였습니다.
1) 0x00 -> prefetch signature

사용자 삽입 이미지
위의 Drag된 8바이트 부분이 프리패치의 header signature 입니다. 시그니처이기 때문에 바뀔일이 없겠죠?


2) 0x58 -> 해당 파일을 실행하기 위해서 메모리에 올라와야할 파일들의 수
(바인딩 될 DLL도 있고 부수적으로 실행되야하는 exe파일, nls, ime, sdb등등)의 개수를 나타냅니다.
사용자 삽입 이미지
위의 값인 0x25 / 십진수로 바꾸면 총 36개의 파일들이 notepad 실행될 때 사용되네요


3) 0x64 -> 메모리에 올려야할 파일들의 목록이 있는 곳의 offset 값
사용자 삽입 이미지

Endian방식에 따라 00 00 29 38 offset 값으로 이동해보죠
사용자 삽입 이미지
어떤 파일들이 메모리에 올라와야 할지 확인할 수있습니다


4) 0x68 -> 메모리에 올라와야 할 파일들의 총 길이
사용자 삽입 이미지

뭐.. 예상하셨겠지만, OS에게 어디까지가 메모리에 올려야 할 부분이야 라고 알려줘야겠죠?
위의 Drag된 부분이 그 값이지요. 0x64 번지의 offset값이 가르치는 부분에서 떨어진 만큼의 값이니 이동해봅시다
(00 00 29 38 + 00 00 0F FA 부분으로 가시거나 00 00 29 38에서 go to offset 하셔서 current position으로 이동하셔도 되겠죠)
여하튼 00 00 39 32 로 이동하게 되는데 다음 그림처럼 끝 부분인 것을 확인할 수 있습니다.
사용자 삽입 이미지


5) 0x6C -> Volume Infomation Block
사용자 삽입 이미지

해당 부분은 사용되는 컴퓨터의 디스크 정보 부분입니다. 우선 이동해보죠
사용자 삽입 이미지

첫부분의 4Byte 00 00 00 28은 Volume Infomation Block의 offset값을 나타냅니다 0x28 을 십진수로 바꾸면 40이니
Drag된 부분이 Volume Infomation Block이네요.
해당 부분은 정리가 아직 덜 끝나서 몇일 후에 다시 포스팅 하기로 하고 한가지 부분만 살펴보고 넘어가겠습니다.
Volume Infomation Block부분만 따로 떼어서 0x08부분을 확인해보죠
사용자 삽입 이미지

결론부터 말씀드리면 위의 Drag한 8Byte 부분이 Volume 최초 생성 시간이 되겠습니다.
사용자 삽입 이미지
이 밖에도 Volume Serial Number, 폴더 경로의 offset, 폴더 경로의 수등 다양합니다. 해당 정보는 정리되는데로 포스팅 하겠습니다.


6) 0x78 -> 마지막 실행 시간
사용자 삽입 이미지
해당 8byte 부분이 XXX-hash.pf 의 XXX가 마지막으로 실행된 시간입니다.
마찬가지로 decode date로 돌려보면
사용자 삽입 이미지
위와 같은 시간을 얻을 수 있습니다.


7) 0x90 -> 실행 회수
사용자 삽입 이미지
vmware로 스냅샷 돌리면서 사용하니까 notepad를 4번밖에 사용안했네요 ㅎㅎ
이 걸로 내가 wow를 몇번이나 접속 했는지를 알아낼 수 있는!!!!....쿨럭(물론 더 좋은 방법도 많습니다)


물론 공부할때는 수동으로 이렇게 하나하나 보는 것이 더 도움이 되긴합니다만,
바쁜데 이렇게 사용할 수도 없는 노릇이고
그래서 역시나 이런 것을 자동으로 보여줄 수 있는 툴이 있죠

소개해 드릴 툴은 "WinPrefetchView"라는 툴입니다
사용자 삽입 이미지
해당 툴은 자동으로 c:\windows\prefetch 부분에 있는 pf파일을 읽어옵니다(다른곳에 있는 pf는 못읽어요)
위의 그림에서 1번 부분이 프리패치 파일 목록이며
2번 부분이 해당 프리패치에 기록된 선택된 application이 실행될 때 메모리에 올려진 부분이며
3번은 프리패치 파일 선택 후 우 클릭 Properties를 선택했을 때 나타나는 부분입니다.


참~! 그래도 프리패치를 사용하고 싶지않다 하시는 분들은
KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters EnablePrefetcher 값을
0으로 설정해주시면 됩니다.
0 : 사용안함
1 : Application 만 사용
2 : Boot 할 때 사용되는 것만 사용
3 : 그냥 둘 다 사용 <-- 이게 디폴트 설정값이죠


프리패치때문에 삽질했던 기억 때문에 포스팅해봤는데
다른분들한테 도움이 되었으면 좋겠네요 ㅎㅎ

Posted by 궁상박군
:

RussKill

Malware Analysis 2010. 1. 6. 05:55 |
 
   1.개요

  악성코드를 분석할 때는 항상 해커들의 입장에서 분석하려고 노력한다. 따라서 서비스 공격이나, 서비스거부공격, 웹해킹등을 간단하게 할 수 있는 방법이 없을까? 혹은 많은 사용자들에게 감염시킬 수 있는 방법이 없을까에 대해서 항상 질문하고 방법을 찾는데, 이번에 분석한 악성코드 역시 그러한 생각 때문에 찾은 악성코드이며, 12 17 Opensive Computing RussKill. Application to perform denial of service attacks 라고 소개되었으며, 아직 국내 사이트에서 다룬적이 없는 악성코드이다. -어려운 것도 아니고 그냥 보통의 악성코드와 비슷하다- 따라서 탐지명을 RussKill로 가정하고 진행한다.

 

  
2.RussKill이란.
 
  RussKill
DoS(혹은 DDoS) 발생시킬 있는 툴로서 기능들이 Opensive Computing에서 소개하듯이 Extremely 정도로 간편화 되어 사용할 있으며, C&C서버도 자동으로 구성하여 타겟을 지속적으로 바꿀 있다(실질적으로 분석하는 도중에도 여러 도메인으로 계속 바뀌었다).

 또한, RussKill HTTP-Flooding, SYN-Flooding 공격을 수행할 있으며, 공격자가 서버에서 시간당 발생패킷을 지정하여 PPS 조절할 있다. 모든 과정이 모두 마우스 클릭으로 바로바로 이루어진다.

 

  3. 공격 시나리오

사용자 삽입 이미지

Attacker RussKill을 웹서버에 구동한다.(이 과정에서 악성코드과 Target Server가 설정된다)

Victim들이 악성코드를 다운로드한다. (본 공격의 효율성을 위해서는 상관없는 여러 사이트들에

   감염시키는 것이 좋으나, 현재는 모두 한곳에서만 다운로드 한다.)

③ 악성코드에 감염된 사용자가 C&C서버로 접속한다. 여기서 C&C Web서버의 php페이지이다.

④ 감염된 Victim Group들이 설정된 C&C서버에서 전달받은 서버로 공격을 수행한다.

Victim Group들은 지속적으로 C&C서버로(설정값에 따라 시간변동) 접근하여 변경내용을 확인한다.

Attacker Victim의 개수를 파악하고 공격의 중지 혹은 Target Server를 변경할 수 있다.


4. 악성코드 분석

  실제적으로
google 통해서 찾은 악성코드는 www.kimosimotuma.cn/999/wihpg.exe 지만, malwareurl.com이나 malwaredomainlist.com 통해 찾은 Russkill관련 도메인은 다음과 같다.

사용자 삽입 이미지

[그림1] malwaredomainlist.com에서 신고된 domain

 

  Kimosimotuma.cn atatata.org, glousc.com 3개의 도메인 모두 중국 IP이며, atatata.org glosc.com IP 115.100.250.107이었으며, kimosimotuma.cn 115.100.250.104 마지막 IP 다른걸 봐서는 공격자가 같을 것이라고 추측할 있다.(이를 증명하는 것은 뒤에도 나오므로 차후에 설명하기로 한다)

 

1)     www.glousc.com/hellotobad/hellotobad.exe 다운로드

 

사용자 삽입 이미지

[그림2] 악성코드 다운로드

 

 

2)     바이로봇 탐지내역 확인

 

사용자 삽입 이미지

[그림3] 바이로봇 탐지결과

 

  바이로봇뿐만 아니라 virustotal.com에서 돌렸을 경우 대부분의 백신에서 탐지를 하지만, 수많은 악성코드의 변종으로 검사된다.

그중에서 Microsoft, AntiVir, eTrust-Vet 경우 Ruskill 탐지한다.(발빠르게 대처한건가?)

 

3)     Wireshark 구동 악성코드 수행

사용자 삽입 이미지

[그림4] 패킷 확인 결과

Glousc.com에서 받은 hellotobad.exe glousc.com/hellotobad/r.php 접속 다른 도메인으로 SYN 패킷을 발생시켰으며, kimosimotuma.cn에서 받은 wihpg.exe kimosimotuma.cn
/999/r.php
접속 다른 도메인으로 SYN패킷을 발생시켰다. 또한, 두개의 악성코드 모두 서비스에 등록하여 재부팅시 두개 모두 kimosimotuma.cn/999/r.php 접속하여 Target Server 가져오는 것을 확인하여 공격자가 동일한 것으로 가정할 있다.

  r.php Follow TCP Stream으로 확인한 결과 다음과 같았으며 r.php 접속하여도 같은 결과를 있다.

사용자 삽입 이미지

[그림5] Follow TCP Stream


사용자 삽입 이미지

[그림6] glousc.com/hellotobad/r.php

사용자 삽입 이미지

[그림7] atatata.org/888/r.php

사용자 삽입 이미지

[그림8] kimosimoutma.cn/999/r.php

그림6,7,8에서 확인하였듯이 각각의 서버마다 지정해놓은 Target Server 달랐으며, 실질적으로 분석을 수행할 가끔씩 Target 바뀌었으며 그때마다 r.php 바뀌어 있었다. 또한, r.php로만 주기적으로 접근을 시도할뿐 Target Server 패킷을 잠시 안보낼 경우도 있는데, 경우 역시 공격자가 임의적으로 Stop 걸어놓았다고 가정할 있다.

SYN Packet 발생시키는 것도 분석할 때마다 초당 많게는 5,000 적게는 100 PPS정도 발생되었다. 역시 공격자가 임의적으로 조작한 것으로 추정된다.                                       

사용자 삽입 이미지
                                                      [그림9] SYN Packet 발생

 

4)     Reversing

사용자 삽입 이미지
                                                [그림10] ASPack 2.12 Packing

 

해당 코드는 ASPack 의해 Packing되어 있어서 자세한 구조를 확인하기 어려워 Unpacking 수행하여 해당 코드를 살펴보았다. 

사용자 삽입 이미지
                                      [그림11] c:\windows\system32\winsrir.exe 생성 부분 

해당 악성코드는 두개 모두 c:\windows\system32\winsrir.exe 생성하였으며, 외에는 파일 생성 하는 과정이 없었다.

사용자 삽입 이미지
                                                [그림12] 레지스트리 수정 부분

 

위의 함수에서 실질적으로 레지스트리를 수정 키값을 생성하며 목록은 다음과 같다

       HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\Root\LEGACY_WINSRIR

       HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\Root\LEGACY_WINSRIR\0000

       HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\Root\LEGACY_WINSRIR\0000\Control

       HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\winsrir

       HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\winsrir\Security

       HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\winsrir\Enum

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_WINSRIR

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_WINSRIR\0000

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_WINSRIR\0000\Control

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\winsrir

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\winsrir\Security

 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\winsrir\Enum


위의 목록중 HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\winsrir에서 윈도우 서비스에 등록된다.

사용자 삽입 이미지
                                        [그림13] 서비스 등록 부분

 

위의 레지스트리 편집기에서 DisplayName 부분이 한문으로 깨져서 나오지만 실질적으로 등록된 서비스를 확인해보면 Services Windows Controller 동록 된다.

사용자 삽입 이미지

[그림14] 서비스 등록



5. RussKill 정보

  Russkill
이라는게 소개된지도 얼마되지 않았기 때문에 관련된 정보가 많지 않다. 실제적으로 http://planety-hackeram.ru 라는 러시아 해킹툴 다운로드사이트에서 관련된 자료를 다운로드할 있는것으로 파악되는데 사이트를 번역해가면서 가입해본 결과 wmz(webmoney) 요구한다.

Opensive computing이나 최초발견자들의 개괄적인 분석내용을 살펴보면 다음과 같은 그림들을 확인할 있는데 여기서 개괄적인 정보를 유추할 있다. Online이란 현재 r.php 접속해서 받아가는 Victim 수이며, URL Target-server, 초당 packet 발생 , 공격의 중지 혹은 target server 변경등이 가능한 것으로 보인다.

사용자 삽입 이미지

[그림15] Russkill 정보#1

사용자 삽입 이미지

[그림16] Russkill 정보#2

 

공격에 대한 셋팅이 이루어지므로, 웹서버 어떤 페이지는 로그인하는 화면이 있을 것으로 생각하고 blind 페이지를 요청해보았으며 다음과 같은 로그인 창을 찾을 있었다.

사용자 삽입 이미지

[그림17] Russkill 로그인 창

 

(Brute Force의 욕구가 잔뜩)  

 

기존에 해외에서 신고된 도메인의 URI 기본적으로 /연속된숫자3자리/r.php 이다. 물론, 공격이 여러건 나온 것이 아니니 Russkill default 설치하면 저렇게 것이다 가정하였을 경우 패턴의 입력이 가능하다. 하지만 snort 경우 /\[0-9]{3}\/[Rr]\.[Pp][Hh][Pp] 같은 형식으로 정규식 써서 등록이 가능하지만 Sniper는 정규식이 안먹으니 패스~

### r.php로 접속했을때 target server 주소 앞에 숫자|숫자|숫자|숫자 되어 있는 부분에 따라서
공격의 수행여부(혹은 중단) 패킷의 발생빈도 이런걸 나타내는데 2,4번째 필드부분을 아직 못찾아서;
또 삽질을 해야하나;;


'Malware Analysis' 카테고리의 다른 글

악성코드 분석을 위한 스크립트 만들기!! #1  (1) 2011.01.13
악성코드 수집  (0) 2010.03.21
Posted by 궁상박군
: