Background: PIE # 들어가며 ASLR이 적용되면 바이너리가 실행될 때마다 스택, 힙, 공유 라이브러리 등이 무작위 주소에 매핑되므로, 공격자가 이 영역들을 공격에 활용하기 어려워짐 PIE: ASLR이 코드 영역에도 적용되게 해주는 기술 해당 기술은 보안성 향상을 위해 도입된 것이 아니기 때문에 엄밀하게 보호 기법은 아니나 이를 보호 기법이라고 소개하는 글이나 발표도 있음 Figure 1. PIE가 적용되지 않은 addr의 실행 결과 # PIC와 PIE - PIC 리눅스에서 ELF는 실행 파일(Executable)과 공유 오브젝트(Shared Object, SO)로 두 가지가 존재 실행 파일은 addr 바이너리처럼 일반적인 실행 파일이 해당하고, 공유 오브젝트는 libc.so와 같은 라이브러리..

Background: RELRO # 서론 Lazy Binding: 함수가 처음 호출 될 때 함수의 주소를 구하고, 이를 GOT에 적는 것 Lazy Binding을 하는 바이너리는 실행 중에 GOT 테이블을 업데이트할 수 있어먀 하므로 GOT에 쓰기 권한이 부여됨 → 바이너리를 취약하게 만드는 원인 ELF의 데이터 세그먼트에는 프로세스의 초기화 및 종료와 관련된 .init_arrary, .fini_array가 있음 해당 영역들은 프로세스의 시작과 종료에 실행할 함수들의 주소를 저장하고 있음 여기에 공격자가 임의로 값을 쓸 수 있다면, 프로세스의 실행 흐름이 조작될 수 있음 이러한 문제를 해결하고자 프로세스의 데이터 세그먼트를 보호하는 RELocation Read-Only(RELRO)가 개발됨 RELRO는 ..

rop Exploit Tech: Return Oriented Programming에서 실습하는 문제입니다. # 문제 분석 - ROP (Return Oriented Programming) 리턴 가젯을 사용하여 복잡한 실행 흐름을 구현하는 기법 ROP 페이로드는 리턴 가젯으로 구성되며, ret 단위로 여러 코드가 연쇄적으로 실행되는 모습에서 ROP Chain이라고도 불림 - 소스코드 저번 문제와 달리 system 함수를 호출하지 않아 PLT에 등록되지 않으며 "/bin/sh" 문자열도 데이터 섹션에 기록되지 않음 따라서 system 함수를 익스플로잇에 사용하기 위해서는 함수의 주소를 직접 구해야하고 "/bin/sh" 문자열을 사용할 다른 방법을 고민해보아야 함 // Name: rop.c // Compile:..

ssp_001 이 문제는 작동하고 있는 서비스(ssp_001)의 바이너리와 소스코드가 주어집니다. 프로그램의 취약점을 찾고 SSP 방어 기법을 우회하여 익스플로잇해 셸을 획득한 후, “flag” 파일을 읽으세요. “flag” 파일의 내용을 워게임 사이트에 인증하면 점수를 획득할 수 있습니다. 플래그의 형식은 DH{…} 입니다. # 문제 분석 - checksec 확인 32bit 환경 canary 존재 NX enabled 이므로 스택 내 실행 권한 X - 소스코드 옵션 선택 F: box 배열에 내용을 입력할 수 있으며 이때 bof는 발생하지 않음 P: box 배열 내의 원소를 index로 접근할 수 있으며 이때 index에 대한 검증 과정이 없기 때문에 oob read 가능 E: name 배열에 내용을 입력..

Return to Library Exploit Tech: Return to Library에서 실습하는 문제입니다. # Review Return Address Overwrite: 반환 주소를 악성 함수의 주소로 덮어서 셸 획득 Stack Canary: 스택 프레임의 반환 주소 전에 랜덤한 카나리를 주입하여 반호나 주소를 덮기 어렵게 함 Return to Shellcode: 카나리를 우회하고, 셸 코드를 주입한 버퍼의 주소로 반환 주소를 덮어서 셸 획득 ASLR: 임의 버퍼의 주소를 알기 어렵게 함 NX: 각 세그먼트에 불필요한 실행권한을 제거함으로써 공격자가 임의 버퍼에 주입한 코드를 실행하기 어렵게 함 # 문제 분석 - Return to Library NX로 인해 공격자가 버퍼에 주입한 셸 코드를 실행하..

Background: Library - Static Link vs. Dynamic Link # 라이브러리 라이브러리는 컴퓨터 시스템에서, 프로그램들이 함수나, 변수를 공유해서 사용할 수 있게 함 대개의 프로그램은 서로 공통으로 사용하는 함수들이 많음 ex) printf, scanf, strlen, memcpy, malloc 등 많은 C 프로그래머들이 코드를 작성하면서 사용하는 함수 C언어를 비롯하여 많은 컴파일 언어들은 자주 사용되는 함수들의 정의를 묶어서 하나의 라이브러리 파일로 만들고, 이를 여러 프로그램이 공유해서 사용할 수 있도록 지원하고 있음 라이브러리를 사용하면 같은 함수를 반복적으로 정의해야하는 수고를 덜 수 있어 코드 개발의 효율이 높아짐 각 언어에서 범용적으로 많이 사용되는 함수들은 표준..

Mitigation: NX & ASLR # 들어가며 r2s를 통한 공격자의 침입을 더 어렵게 하려면 공격자가 메모리에서 임의 버퍼의 주소를 알기 어렵게 하고 메모리 영역에서 불필요한 실행 권한을 제거하는 보호 기법을 추가로 도입해야 함 # ASLR Address Space Layout Randomization(ASLR): 바이너리가 실행될 마다 스택, 힙, 공유 라이브러리 등을 임의의 주소에 할당하는 보호 기법 ASLR은 커널에서 지원하는 보호 기법이며, 다음의 명령어로 확인 가능 리눅스에서 이 값은 0, 1, 또는 2의 값을 가질 수 있음 각 ASLR이 적용되는 메모리 영역은 다음과 같음 No ASLR(0): ASLR을 적용하지 않음 Conservative Randomization(1): 스택, 힙, ..

Return to Shellcode Exploit Tech: Return to Shellcode에서 실습하는 문제입니다. # 문제 분석 - Return to Shellcode 반환 주소를 shellcode가 저장된 곳으로 우회하여 프로그램의 실행 흐름을 조작하는 것 해당 문제는 카나리를 우회하고, 쉘 코드와 Return Address Overwrite를 이용하여 쉘을 획득할 수 있음 - Checksec 카나리가 적용되어 있음 - 소스코드 buf의 주소 및 rbp와 buf 사이의 주소 차이를 알려줌 스택 버퍼인 buf에 총 두 번의 입력을 받음 → 두 입력 모두에서 오버플로우 발생 // Name: r2s.c // Compile: gcc -o r2s r2s.c -zexecstack #include #incl..

Mitigation: Stack Canary # 들어가며 Return Address Overwrite: 스택의 반환 주소(Return Address)를 조작하여 실행 흐름을 획득하는 공격 기법 스택 카나리(Canary): 스택 버퍼 오버플로우로부터 반환 주소를 보호 함수의 프롤로그에서 스택 버퍼와 반환 주소 사이에 임의의 값을 삽입하고, 함수의 에필로그에서 해당 값의 변조를 확인하는 보호 기법 카나리 값의 변조가 확인되면 프로세스는 강제로 종료됨 스택 버퍼 오버플로우 반환 주소를 덮으려면 반드시 카나리를 먼저 덮어야 하므로 카나리 값을 모르는 공격자는 반환 주소를 덮을 때 카나리 값을 변조하게 됨 → 에필로그에서 변조가 확인되어 공격자는 실행흐름을 획득하지 못함 # 카나리의 작동 원리 1. 카나리 정적 ..

Memory Corruption: Stack Buffer Overflow # 서론 모리스 웜: 스택 버퍼 오버플로우 공격을 통해 전파됨 CVE details에 따르면 스택 버퍼 오버플로우를 포함한 오버플로우 취약점은 이제까지 18,081개가 발견되어 전체에서 3번째로 많이 발견되었으며, 2019년에도 1,247개가 추가로 발견됨 # 스택 버퍼 오버플로우 1. 버퍼 오버플로우 1.1 버퍼 버퍼(Buffer): 데이터가 목적지로 이동되기 전에 보관되는 임시 저장소 데이터가 처리속도가 다른 두 장치가 있을 때, 이 둘 사이에 오가는 데이터를 임시로 저장해두는 것은 일종의 완충 작용을 함 예를 들어 키보드에서 데이터가 입력되는 속도보다 데이터를 처리하는 속도가 느린 프로그램이 있음 이런 키보드를 사용하는데 별도..