우옷, :)
꾀 많은 시간이 걸렸습니다.
일주일 정도(?)
KiFastCallEntry()의 코드에 대하여 분석한 후,
이를 똑같이 구현해 보고자 하였습니다.
많은 시행착오를 거쳤지만,
결국 완성을 했습니다. (아직 두가지 호출에 대해선 완성이라 말하긴 뭐하지만)
어제 재가 글을 올리기를,
재가 앞으로 쓸글의 내용을 보면 SSDT Hooking을 무력화 시키는 방법을
알 수 있다고 하였는데요,
앞으로 쓸글의 내용은 이 KiFastCallEntry()의 구조에 대한 것인데,
KiFastCallEntry()의 코드중 다음과 같은 부분이 있습니다.
~~~~~~~~~~~~~~~~~~~
//인자들 공간 확보
mov ebx,[edi+0xC] //SERVICE_DESCRIPTOR_NUMBER
xor ecx,ecx
mov cl,byte ptr [eax+ebx]
//함수 주소를 구해온다.
mov edi,dword ptr[edi] //Service_Descriptor_Base
mov ebx,dword ptr[edi+eax*4]
//스택 공간 확보
sub esp,ecx
//인자 & 목적지 크기 지정
shr ecx,2
mov edi,esp
//MmUserProbeAddress인지 확인
cmp esi,_MmUserProbeAddress //0x7FFF0000
jnb AccessViolation
~~~~~~~~~~~~~~~~~~~~~~~~
4번째 줄에 보면 mov edi,dword ptr[edi]가 있는데,
이 코드가 실행전에는 edi에는 ServiceDescriptorTable의 주소가 들어있고,
실행된 후에는 그속에 있던 ServiceTableBase의 값이 들어가게 됩니다.
그리고 eax에는 CallNumber가 들어있는데,
이 주소를 다음줄에서 계산에서 ebx에 넣은후
call ebx <===이렇게 호출 합니다.
SDT Hooking은 ServiceTable의 Function Entry중,
Hooking하고자 하는 Function의 Entry를 자신의 Entry로 바꾸는 방법을 사용합니다.
그럼으로 변경된 ServiceTable이 아닌,
외부에서 조작되지 않는 꺠긋한 상태의 ServiceTable을 쓰면,
SDT Hooking은 작동하지 않게 되는 것이지요.
그럼 그럴 기회가 언제 우리에게 있는가?
저는 과거에는 ServiceDescriptorTable을 바꾸는 방법도 사용해 보았고,
ServiceTable을 바꾸는 방법도 사용해 보았으나,
이는 실제 구조체의 값을 바꾸는 것으로,
공격자에 의해 다시 수정될 가능성이 큽니다. (외부에서 export되는 변수들을
통해 주소를 알수 있기 떄문에)
그런데, 만약 위의 코드에서 다음과 같은 방법으로 수정을 가하면..?
~~~~~~~~~~~~~~~~~~~
//인자들 공간 확보
mov ebx,[edi+0xC] //SERVICE_DESCRIPTOR_NUMBER
xor ecx,ecx
mov cl,byte ptr [eax+ebx]
//함수 주소를 구해온다.
mov edi,dword ptr[edi] //Service_Descriptor_Base
cmp edi,NativeServiceTable //Win32k or native?
jne Win32k
mov edi,NewNativeServiceTable
Win32k:
mov edi,NewWin32kServiceTable
mov ebx,dword ptr[edi+eax*4]
//스택 공간 확보
sub esp,ecx
//인자 & 목적지 크기 지정
shr ecx,2
mov edi,esp
//MmUserProbeAddress인지 확인
cmp esi,_MmUserProbeAddress // AccessViolation
~~~~~~~~~~~~~~~~~~~~~~~~
재가 추가한 내용은 간단합니다.
서비스 테이블이 수정되었던 안되었건,
상관없이 본 드라이버 내부적으로 가지고 있는
꺠끗한 서비스 테이블을 사용함으로써,
SDT Hooking으로 부터 자유로울수 있는 것이지요. :)
:) 실제로 테스트 해본 결과,
SDT Hooking을 무력화 시킬 수 있었고,
이는 상용 보안 솔루션 등에도 마찬가지였습니다.
이번 Article의 공개는 꾀 재밌을거 같습니다. :p
(0) 
(0)Posted by Dual
