|
The "Venetian" exploit Creating Arbitrary Shellcode In Unicode Expanded Strings The "Venetian" exploit Chris Anley (chris@nextgenss.com) 8th January 2002 www.ngssoftware.com [개요] 이 문서는 "shellcode"
타입의 보안 결점을 막기위한 보호 메커니즘 개발에 책임을 가진 보안계의 일부분을 위한 것이다.; 유니코드 버퍼오버플로우가 익스플로잇
될 수 없는 것으로 인식하는 것을 깨뜨리고 그것으로 인한 일반적인 네트워크 보안 상태를 개선시키려는 의도로 작성한 것이다. 사실상 임의적 코드가 실행 가능할 때 몇몇의 오버플로우나 포맷스트링 버그의 종류는 "denial of
service" 공격으로 분류되는 경우가 있는데 이 문서는 이런 오버플로우의
부류에 관해 다룬다. 이 문서는, 인텔 x86 프로세서에서, "Unicode" 스트링이 있는 곳에서 버퍼
오버플로우가 발생 할 때 작은 용량의 임의적 코드로 실행을 해 낼 수 있는 기술(베네치아식 익스플로잇-Venetian Exploit)을 소개 한다. 이런 경우는 윈도우
시스템에서 공통적이나 이 기술은 특정 운영체제에 적용되는 것은 아니다. [소개] 윈도우 플랫폼에서는 오버 플로우 되기 이전에 유니코드로 컨버트
된 스트링에서 오버플로우가 발견되는 경우가 있다. 요청될 스트링(submitted
string)의 각 바이트 사이마다 널 바이트를 삽입하여 쉘코드를 만들면서 부터 "익스플로잇" 작성이 복잡하다. 예를들어 AAAA 는 00 41 00 41
00 41 00 41 이 된다. 일반적으로 매번 교대하는 바이트가 제로인 상황에서 의미있는 쉘코드를 작성하기란 매우 어렵다고 여겨진다. 이 문서는 출력가능한 ASCII 문자만으로 익스플로잇 코드를 만드는 "bridge building" 방법과
다르지 않은 기술을 사용하여 이 문제를 어떻게 극복할 수 있는지 설명한다. [가정] 이 기술을 유용하게 사용하기 위해 다음과 같은 상태를 유지해야 한다: 1) 대상 프로그램의 실행 경로를 유니코드 버퍼로 리다이렉트 시킬 수 있어야 한다. 그리고 어느 한쪽이라도 가능해야 함: 2) eax, ebx, ecx, edx,
esp, ebp or esi 레지스터 중 하나는 유니코드 버퍼의 알려진 오프셋을 가리켜야 한다. 또는 3) 우리의 버퍼 메모리에 정확한 주소를 알거나 지정할 수 있어야
한다. [베네치아식 익스플로잇] "Unicode" 버퍼는 베네치아식 블라인드와 비슷하다: 우리가 컨트롤 하는 "solid" 바이트들과 그 간격마다 반복적 제로들의
"gap"이 있다. 앞으로 다룰 기술은 버퍼의 더 아래쪽 gap들에 선택된 바이트들을
끼워넣기 위힌 버퍼 시작점에서 "solid" 바이트를 사용하는 것과 블라인드를 "닫음"으로서, 익스플로잇의 payload 가 될 작은 용량의 쉘코드를 만드는 것에 대해 다룬다. 우리는 이것을 하기 위해 메모리 수정을 위한 특정한 방법으로 반복적 제로를 포함시켜 인스트럭션을 사용하는 것에 대해 알고 있어야 한다. 인텔 프로세서에서의 instruction은 변수 길이를 가진다. 각 바이트마다 제로를 가지고 있어야 하므로, 우리는 인스트럭션 바운더리에 똑바로 맞춰 정렬되는 것을 확실히 하기
위해 같은 의미의 인스트럭션을 수행하는 "nop"을 우리의 코드에 삽입할 것이다. (이 nop 인스트럭션은 우리 코드에서 아무런 결과를
초래하지 않지만 코드에 채울 수 있는 역할을 한다.) 00로 시작하는 인스트럭션은, 우리에게 특별히 유용하지 않지만, 모두 "add" 명령이다. 일반적으로 non-zero 바이트로 시작하는 인스트럭션을 사용할 것이다. 따라서 우리가 코드를 작성할 때 다음 수행해야 할 인스트럭션이 00로 시작해야 한다면 "재정렬" 된 다음과 같은 특정한 형식의 instruction들을
사용할 수 있다. 그러면 우리는 다음 인스트럭션으로 좀
더 흥미로운 것을 할 수 있게 된다. 00 6D 00:add byte ptr [ebp],ch 이것은 쓰기 가능한 어떤 곳을 포인트 하고 있다는 것을 나타내고 있다. 그리고
그곳은 "익스플로잇"의 목적과는 상관 없으므로 관심가질 필요가 없다. 만약 그렇지 않은 경우라면, 다음과 같이 다른 레지스터들을 사용하면 된다. 00 6E 00:add byte ptr [esi],ch 00 6F 00:add byte ptr [edi],ch 00 70 00:add byte ptr [eax],dh 00 71 00:add byte ptr [ecx],dh 00 72 00:add byte ptr [edx],dh 00 73 00:add byte ptr [ebx],dh 만약 모든 레지스터들이 우리가 안전하게 덮어쓸 수 있는 곳으로 포인트하고 있지 않다면 constant 포인터 값을 다음과 같은 인스트럭션으로 eax에
할당하면 된다. 6A 00:push 0 58 :pop eax (eax에 "0"을 할당함), 그다음 같은 뜻의 정렬 인스트럭션인 "nop"로 eax 레지스터가 안전하게 덮어쓸 수 있는 메모리 위치로 포인트
될 때 까지, 아래 설명 할 "add"와 "sub"를 해나간다. 위 상태에서, 우리는 우리의 유니코드 버퍼로 포인트하는 레지스터를 가지게 된다. 다음 우리가 해야 할 일은 우리의 버퍼 내에 있는 특정한 포인트 아래의 모든
00 바이트에 다음과 같이 "set" 을 하는 것이다. 80 00 75:add byte ptr [eax],75h ... 그다음 eax를 두번 inc(증가) 시키고... 40 :inc eax 00 6D 00 :add byte
ptr [ebp],ch 40 :inc eax 그리고 다음 00 바이트를 세팅하면
된다. 이것은 우리의 쉘코드의 마지막 앞부분의 버퍼에
위치하고 있는 임의적 바이트들로 끝나게 될 것이다. 그러면 그 버퍼는 다음과 같이 놓이게 된다. 0x00000000 ... [ alternate-zero byte setting code ] [ arbitrary bytes of shellcode ] ... 0xffffffff 물론, 첫번째로 해야
하는 일은 임의적 바이트를 쓰려고 하는 버퍼의 부분을 가리키는 포인터를 획득하는 것이다. 이걸 하기 위해, 우리의 쉘코드를
가리키고 있는 레지스터의 값과 eax 레지스터의 값을
교환해야 하는데, 1 바이트로 가능한 "xchg" 인스트럭션을 사용 할 것이다. 다음 중의 하나가 될 것이다: 93:xchg eax,ebx 91:xchg eax,ecx 92:xchg eax,edx 94:xchg eax,esp 95:xchg eax,ebp 96:xchg eax,esi 97:xchg eax,edi 그리고 우리는 "add"와 "sub"를 사용하여 eax 값을 바꿔야 하는데, 우리
버퍼의 "임의적 바이트" 부분을 가리키기
위함이다. 05 00 75 00 4C: add eax,4C007500h 2D 00 75 00 4C: sub eax,4C007500h "add"와
"sub" 오퍼레이션을 반복해 나가는 것이 필요한데 256의 배수를 더할
때 다음과 같이 할 수 있다. add eax,4C007500h sub eax,4C007400h 그리고 위에 설명한 대로 더하고 증가시켜 나간다. "바이트 세팅"된 코드를 통해 임의적 코드로 실행된다는 사실에 따라
우리의 임의적 코드는 이제 실행 가능 해 지게 된다. 만약 초기화된 포인터 오프셋을 똑바로 알고 있다면
우리의 임의적 코드로 실행을 계속 할 수 있을 것이다. [문제] 첫번째로 만약 대상 프로그램이
high bit filter를 보유하고 있다면, 이니셜 포인터를 "xchg" 해야 할 필요가 있고 옵코드가 0x7f보다 높게 요구하므로 이 기술은 매우 어려운 것인데, 'push'와 'pop' 인스트럭션으로
동일하게 만들 수 있을지 몰라도 만들기에는 어렵다. 크기 또한 문제다, 단일 00 바이트가
다음과 같이 세팅 되는 인스트럭션 시퀀스가 있다: 40 :inc eax 00 6D 00:add byte ptr [ebp],ch 40 :inc eax 00 6D 00:add byte ptr [ebp],ch 80 00 75:add byte ptr [eax],75h 00 6D 00:add byte ptr [ebp],ch 그래서 2개의 임의적 코드를 세팅하기
위해 14바이트의 코드가 있어야 한다. (우리는 하나를 자유롭게
가진다. 그 하나는 이미 문자안에 있는 것이다.) 우리가 세팅할 수 있는 1024
바이트의 버퍼를 의미하는 것이고 그러면 익스플로잇 코드의 최대 크기 값은 (1024*2)/14=146 바이트가 될 것이다. (유니코드 문자가 2바이트이므로) 그래도 임의적 명령을 실행 시켜 해롭게 하기에는 충분하다. 치밀하게 이 기술을 사용하면 임의적 쉘코드를 만드는데 필요한 코드의
크기를 줄이는 것이 가능할 것이다. 컨텍스트에 이것을 놓을 때는 리버스 쉘을 일으키는 코드는
170 바이트보다 작게 맞아 떨어진다. 이 기술은 따라서
"wild" 한 곳에 나가 유니코드 오버플로우 익스플로잇을 작성하는데 충분할 것이다. [결론] 이 문서에서 설명한 "베네치아식" 익스플로잇 기술은 다소 복잡하게 익스플로잇을 작성하는 방법이다. 하지만 이것은 윈도우 운영체제 패밀리군에 꽤 공통적으로 나타나는 상황에 대해 다루고 있다. 익스플로잇 할 수 없는 것은 위험할 수 있다는 오버플로우들을 기초로하여 유니코드를 다루는 방법이 제대로 전달되었으면
한다. 프로그램의 실행 경로를 바꿀 수 만 있으면 그것으로 언제나 임의적 코드의 실행이 가능하다는 것을 명심해라. |