[Anyburn 4.3 x86] SEH Unicode Exploit 분석

[Anyburn 4.3 x86] SEH Unicode Exploit

https://www.exploit-db.com/exploits/46507

 

스택기반은 원인 근처에서 터지므로 딱히 원인분석이라 하기도 민망하다.

 

Image file name에서 BOF 취약점 발생.

 

때려박아 넣자.

---

[원인]

1. 입력값의 길이는 계산 되었으나

2. 목적지와의 크기 검증이 없음.

 

입력값의 크기가 계산된 후 _write_string 함수를 호출하는데, 목적지 크기와의 검증이 없다.

 

입력값의 크기가 loop counter로 들어와 wchar 한글자씩 옮기는 loop.

1. 목적지 버퍼와의 크기 검증이 없어 목적지 버퍼를 훨씬 넘어서는 스택을 다 덮어버리고

2. 스택 끝까지 도달하여 강제 예외발생.

3. 덮어쓴 SEH를 통해 EIP제어.

---

[디버깅]

목적지가 00으로 초기화 되어있는 모습 확인.

esp : 입력버퍼
esp+4 : 입력버퍼 크기
esp+8 : &Dst

IDA로도 보았듯이, Unicode로 옮기므로 size인 0x2710*2 만큼 쓰게된다.

즉, 0x05CB70A + 0x2710*2 = 0x05C6052A까지 쓰임.

 

0x05C6052A까지 도달하기 전에 스택의 끝을 만나 더 이상 쓸 수 없다며 Write Access Violation 발생.

 

Stack BOF로 이미 최상단 SEH 구조체를 덮어쓴 상태이므로 SEH Chain 오염됨.

따라서 예외를 처리하고자 예외처리 함수로 이동하지만, 예외처리 함수 주소는 우리가 이미 BOF로 덮어쓴 인위적인 주소. (PPR)

 

유니코드로 삽입되므로 유니코드로 삽입할 수 있는 PPR 주소를 찾아야함.

!mona seh -unicode

 

call _except_handler() 함수 진입 시 스택 상황을 보라.

retn
arg0
arg4 --> void *EstablisherFrame  : EXCEPTION_REGISTRATION_RECORD 주소!
arg8
argc

인데 두번째 인자가 seh chain 최상단 주소이므로 PPR을 하는 것이다.

 

일반적인 SEH Overwrite는 [nSEH : short jmp / SEH : PPR주소] 로 구성되지만 Unicode의 경우 short jmp 명령어를 삽입하기 어렵다.

따라서 short jmp대신 SEH Structure를 기계어로 실행하더라도 다음으로 무난하게 넘어갈 수 있도록 SEH 구조체를 구성하여 short jmp와 비슷한 효과를 만들어 낸다.

 

SEH에 적힌 PPR주소인 00472022를 기계어로 그대로 실행한다면 EAX=0인 상태이므로 예외 발생.

따라서 nSEH에 XCHG 명령어로 구성하여 EAX와 EDX를 바꿔줌으로써 무난하게 흘러가도록 만듬.

 

ven이라 적은 것은 ascii가 unicode로 변환될 때 붙는 00을 처리하기 위해 nop과 같은 역할을 할 명령어와 결합시키는 행위다.

Unicode로 쉘코드를 작성할 때에는 필수적.

(venetian align 참조)

 

쉘코드 주소와 근처에 있는 레지스터를 골라 offset 계산 후 push & ret를 통해 shellcode로 이동한다.

EBP레지스터에 +0xb00 효과는 +11000f00 -11000400 연산으로 구현.

완성된 주소를 Push & ret 를 통해 쉘코드 공간으로 점프.

 

msfvenom으로 작성한 계산기를 띄우는 유니코드 쉘코드다.

unicode decode + shellcode 로 구성된다.

decode루틴이 반복되며 쉘코드가 풀리고, 멀쩡한 쉘코드를 실행한다.

 

계산기 뾰롱