취약한 언어 / SDLC / 범위를 벗어난 쓰기 / 완화 방법 등

취약한 언어

C언어는 굉장히 취약함

그런데, 알려진 취약점이 적다고 안전한 언어는 아님

그냥 사람들이 관심이 없어서 취약점이 없는 경우가 많음

 

PHP는 발견되는 취약점이 2019->2020년 크게 줄었는데,

PHP가 안전해졌다기 보다는 그냥 PHP의 인기가 식었다고 생각할 수 있음

 

GO는 2019년->2020년 발견되는 취약점이 늘었는데

PHP와 반대로 사람들의 관심이 늘었다고 볼 수 있음

 

어쨌든 안전한 언어 선택은 중요함

성능 신경 안쓰면 파이썬 좋고, 러스트는 성능도 좋고 안전함

---

SDLC

Plan & Analyze

Design

Develop

Test

Deploy

Maintain

기획 및 분석 - 설계 - 개발 - 테스트 - 디플로이 - 유지보수

보통 설계, 개발 단계에서 약점이 발생 (많은 경우 5:5 비율)

그리고 디플로이 단계에서 해커들이 취약점 악용

 

문제를 나중 단계에서 고칠 수록 돈이 많이 듦

---

KEV (Known Exploited Vulnerabilities)

공격하는 방법이 알려진 취약점

CWE에서 관련된 KEV가 많을수록 위험

---

CWE-787: Out-of-bounds Write

지정된 버퍼 범위 앞, 혹은 뒤로 벗어나서 write하는 경우

=> 메모리 코룹션

int returnChunkSize(void *) {
	....
}

int main() {
	...
	memcpy(destBuf, srcBuf, (returnChunkSize(destBuf) - 1));
	...
}

returnChunkSize의 리턴값이 int라 음수, 예를 들어 -1 가능 -> MAXINT - 1로 인식될 수 있음

=> 원래 읽어야 하는 범위보다 더 많이 읽게 됨

 

영향: 무결성, 가용성

메모리 변조로 인한 도스(크래시, 종료, 재시작)

다른 약점과 결합되면 임의 코드 실행도 가능

 

완화(Mitigration) 방법

페이즈: 요구사항 분석

- 언어 선택 잘 하기(자바, 펄은 버퍼 오버플로우의 대상이 아님)

 

페이즈: 설계

- 안전한 라이브러리, 프레임워크 쓰기

 

페이즈: 컴파일

- GS 플래그, FORTIFY_SOURCE GCC 플래그 같은 걸 사용

 

페이즈: 구현

- 안전한 함수 사용하기

- 몇가지 규칙

-- 버퍼가 필요한 만큼 큰 지 확인하기

-- strncpy같이 복사할 바이트 수를 전달하는 함수의 경우 NULL 문자 자리 있는지 체크

-- 루프에서 할당된 버퍼 범위를 넘어가지 않는지 체크

-- 필요한 경우 모든 입력 문자열을 잘라서 받고 연결하기

 

 

페이즈: 오퍼레이션

- ASLR, PIE를 제공하는 환경에서 운영하기

- Data Execution Protection을 제공하는 CPU 및 운영체제 사용 (메모리의 특정 영역의 코드는 실행 불가능하도록 함)

 

 

Detection Methods

예방해도 안되면 탐지할 방법이 있어야 함

** 보통 자동화한 툴을 사용

 

정적 분석 도구 (static Analysis)

코드를 실행하지는 않고 분석함

스패로우, 포티파이, 플로우 파인드 등

Segmentation fault, Divide by zero, Null pointer dereference, Use After free 등

코드만 보는 걸로 찾지 못하는 오류들이 있음

특히, 동기화 문제(레이스 컨디션)를 제대로 못찾음

 

동적 분석 도구 (Dynamic Analysis)

실행되는 환경에서 테스트함 (대표적인게 디버거)

많고 다양한 입력값을 주고 문제 없는지 테스트 (퍼징)

 

보통 굉장히 큰 값, 0, 굉장히 작은 값(음수) 등 골고루 줘봐야 함