1 취약점 발견 방법

static 한 방식으로  취약점을 찾는 전략은 strcpy, strcat 같은 안전하지 않는 c/c++ 라이브럴 함수들 근처에 있는 코드를 찾는 방법이다. 또는 부호와 관련된 취약점을 찾기 위해 movsx 명령어를 디스어셈블리에서 검색할 수 있다. 추약한 코드 위치를 찾았담ㄴ 그 코드로부터 역추적하면서 app의 엔트리 포인트에서 접근 가능한 취약점을 노출하고 있는지 살펴본다.

퍼징이라는 방법도 있다. 자신만의 퍼징 프레임 네트워크를 개발해서 대부분의 버그를 퍼징 툴로 찾아내는 사냥꾼들도 있다. 복잡한 프로그램이 주어졌을 때 데이터가 전달되는 시작점을 찾기란 쉽지 않겠지만 복잡한 소프트웨어는 망가진 입력 데이터를 처리할 때 충돌이 일어난ㄷ. 웹브라우저, 오피스 제품군이 그렇다. 즉 파싱하는 소프트웨러들이다. 일반적으로는 보안 문제와 연관 없지만 사용자가 입력한 데이터를 어디서부터 살펴볼 수 있는지 알려주기도 한다. 

취약점은 익스프로잇이 가능한 메모리 오류를 발생시킨다. 

- 소유하고 있지 않은 메모리르 참조 

- 할당된 것보다 많은 메모리르 참조 

- 할당되지 않는 메모리를 사용할 때 

- 오류가 있는 힙 메모리 관리자를 사용할 때 

메모리 충돌은 프로세스나 스레드 또는 커널이 소유하고 있지 않은 메모리 위치를 변경하거나 그러한 변경으로 인해 메모리의 상태가 충돌할 때 발생한다. 메모리 오류 이외에도 논리적 오류, 크로스 사이트 스트립팅,  SQL 인젝션 같인 웹에 특화된 취약점 등이 있다. 

EIP = 41414141 이러한 코드를 얻었다면 해당 프로세스의 제어권을 획득한 것이나 다름없다. 

파싱하는 프로그램에 대한 분석 순서(소스코드가 주어졌을 경우)

1. 먼저 입력하는 값을 다루는 구조체를 먼저 찾아낸다. 즉 입력 스트림 부분 

2. 입력 스트림 구조체를 찾은 후 해당 변수를 참조하는 부분을 뒤지기 시작한다. 

예를 들어서 p_demux -> s 이 부분은 인풋된 파일의 구조체에 해당한다. (파싱하는 프로그램의) 그리고 stream_read함수는 말그대로 스트림을 들어들이는 함수이다. p_dmux-s 로부터 mst_buf 에 32바이트를 집어넣는다.

긜고 msf_buf의 20번째 바이트로부터 특정 데이터의 사이즈를 얻어왔다. 그리고 여기서 얻은 사이즈를 기반으로 스트림을 한 번더 read한다. 여기서 mst_buf의 크기는 32이기 때문에 8+i_map_size 이기 때문에 이 부분의 크기가 24를 넘는다면 버퍼오버플로우가 발생한다. 

3. 익스플로잇 단계

파일 포맷에 대한 명세서가 없다면소스코드 분석을 통해서 취약점 코드에 접근할 방법을 찾아내야한다. 

i_map_size에 해당하는 부분을 24 넘게 변경한다면 버퍼오버플로우가 발생할 것이다. 

이제 사이즈를 늘려서 return address 를 덮어쓸 수 있는지 확인한다.  eip를 성공적으로 변형시키는데 성공했다면 아주 좋은 징조다. 

이 것은 고친 후이다. 완전히 고쳐진 것처럼 보일 수 있지만 완전히 고쳐지지 못했다. 왜냐하면 i_map_size 가 80000000 이상이면 음수로 취급되면서 우회할 수 있기 때문이다. 즉 부호있는 정수이기 때문에 발생한 일이다.  

DEP

process explorer에서 view -> select columns -> ASLR, DEP enable 을 하면 볼 수 있다. 

DEP는 특별한 API와 컴파일 옵션을 사용해서 설정한 시스템 정책에 의해 설정된다. 

윈도우 비스타의 경우 OptIn 이라고 불리는 DEP 정책이 기본적으로 전역에 적용된다. 이 모드를 사용하면 DEP를 사용하겠다고 명시한 프로세스에 대해서 DEP가 활성화된다. 

DEP를 활성화하려면 컴파일 시에 적절한 링커 옵션을 사용하거나 SetProcessDEPPolicy API를 호출해서 DEP를 활성화할 수 있다. 

출처 :  버그 헌터 다이어리