Stack buffer overflow 이론

쉘코드

① 공격자 입장에서는 무한한 가능성 => 모든걸 다 알 수 있기 때문

② Set-UID까지 추가되면 특정 시스템에 대해 신같은 존재 => 원하는 걸 다 할 수 있기 때문

 

 

Stack 변수들의 악용

지역 변수들은 스택에 연속하여 위치

=> 만일 특정 변수의 크기를 넘어서는 값이 쓰여지면 다른 영역에 corruption(변질) 발생 가능

 

*다른 영역의 예시

① 다른 지역 변수

② 이전 함수의 EIP

③ 리턴 주소

④ Arguments 값

⑤ 다른 함수의 영역

 

 

지역변수의 corruption

지역변수를 오염시키는 상황의 난해함

• 변수의 위치가 알려지지 않음
• 효과가 응용코드의 동작에 의존적

=> 좀 더 예측가능하고 보편적인 공격을 위해서는 스택 프레임의 고정된 정보를 corrupt시키는 것이 좋음 (Frame pointer와 Return address)

 

 

공격자의 제어 하의 실행

Return Address에 대한 덮어씌움으로 공격자는 다음이 가능해짐

=> 다음 실행 위치에 대해 공격자의 제어권 안으로 들어오게 함

• 공격자가 정한 임의의 위치에 임의의 코드를 두고 실행이 가능 => Arbitrary code
• 메모리상의 특정 위치에 코드를 저장하고 이를 호출하도록 설정 => 좀 더 일반적이고 효과적인 방법

 

 

임의의 코드의 실행

1. 공격자의 일반적인 공격 스텝

① 메모리상의 특정 위치에 실행 코드를 저장

 - 스택의 특정 영역에 위치 시킴

② Stack overflow를 이용하여 실행 위치 전환

 - 리턴 주소에 대한 위조를 실행

③ 실행코드가 공격자에게 도움이 되는 특정 작업을 수행

 - 실행코드가 존재한느 위치 주소를 EIP에 넣음

 

2. 쉘 코드 : 공격자의 대표적인 예시

• 쉘 코드를 얻음으로써 공격자는 다양한 시도가 가능
• 특히, root shell을 얻는 경우 매우 큰 위협이 됨

 

3. 쉘 코드의 특징

① 작고 담을(Self-Contained) 수 있음

 - 외부 함수 호출 없어야 함

② 메모리 위치에 독립적

- 로더 이슈

③ ASCII NULL 문자(0x00)가 내부에 없음

 

4. 공격자의 코드

• 메모리 상의 특정 위치에 실행 코드를 저장
• 스택 Overflow를 이용하여 실행 위치를 전환 => Return address의 변경. 즉, saved EIP의 변경
• 실행 코드가 공격자에게 도움이 되는 특정 작업을 수행

* 두가지 옵션

① 스택 위의 쉘 코드

② 프로그램 데이터의 다른 부분 속의 쉘 코드

 - 메모리에 로딩된 라이브러리 영역

 

시스템 콜의 실행

로더 이슈

① 정상적인 프로그램의 실행 절차를 반영 가능한지

② 메모리 세팅

• 프로그램의 메모리 복사
• 실행과 함께 Stack/Heap의 배치
• 동적/정적 링커 설정

*정적 링킹 : App이 실행되어 Process가 되는 과정에서 라이브러리가 포함(연결)되는 것

*동적 링킹 : Process가 된 상태에서 실행이 되면서 라이브러리가 실행(연결)되는 것

 

32bit의 x86 기반 리눅스 시스템의 레지스터 구성

① %eax => 11(0xb) -> execve()

② %ebx => "/bin/sh"

③ %ecx => address of argument array

④ %edx => 새로운 프로그램에 전달될 환경변수들의 주소

⑤ 128(0x80)번 인터럽트를 통해 호출

*인터럽트 : 사용자로부터 요청이 왔을 때 수행 중인 작업을 중단하는 것

 

 

어셈블리로부터 쉘 코드

• 공격자의 코드는 위치 독립적인 코드여야 함 => 어디에 위치하던 실행이 돼야 함
• 이진 표현으로 된 명령어들이 필요 (공격을 위해 전달되어야 하는 데이터)
• 바이너리 코드를 추출하여 이를 문자열 변수에 담아 악의적 입력으로 제공

 

 

NOP 명령 미끄럼

• 공격 코드의 정확한 주소는 예측이 난해함
• 예측의 확률을 높이기 위해 주소의 범위를 높임
• NOP 미끄럼(sled)을 통해 공격코드 직전위치를 찾도록 함

 

메모리 밖의 공격 코드

• 복잡한 여러 가능성들이 존재.
• 함수 포인터들의 수정, caller가 저장한 frame pointer의 위조