KMPlayer 원데이 취약점 분석 (2)

지난 번에 이어서 적겠습니다.

사실 퍼징을 계속 돌려봤는데, 크래시 재현이 안되는 파일들이 너무 많아서, 아래 글을 참고해서 크래시를 일으킬 수 있는 파일을 직접 만들어보았습니다.
https://hackyboiz.github.io/2021/03/24/l0ch/bughunting-tutorials-part3/

hackyboiz

 

그리고 KMPlayer에 windbg를 attach해서 크래시를 재현해보았는데, 다음과 같에 레지스터에 제가 작성한 값들이 overwrite되는 것을 확인했습니다.

이제 이 값들이 어디서 오는지를 확인해보도록 하겠습니다.

ub eip는 현재 명령어(eip) 이전의 명령어들을 역어셈블해서 보여달라는 명령어입니다. 즉, 우리는 바로 이전 명령어가 어떤 건지를 이 명령어를 통해 알 수 있습니다.

 

위의 빨간색 부분을 보게 되면, esi의 주소값을 가져와서 edx에 대입한 결과 fffffff라는 제가 입력한 문자열이 담기는 것을 확인할 수 있었습니다.

 

음 .. 일단 ImLoader.dll이 로드되기 때문에 그 로드되는 지점부터 잡아야 할 것 같습니다.

일단 image base 주소를 먼저 구해주었습니다.

그 다음, IDA에서 ImLoader.dll이 언제 로드되는지를 확인해보았습니다.

 

저기 나와있는 모든 주소에 일단 브포를 걸어보겠습니다.

 

0xbf3064 주소에 브레이크 포인트가 걸리는 것을 확인했습니다.

그 뒤에 ImLoader.dll의 base 주소를 구하고, 크래시가 난 함수의 시작부분에 브포를 걸고 내려가 보았는데, 이 호출이 계속 반복되다가 어느 순간 eax에 우리가 넣었던 값이 들어가있는 것을 확인했습니다.

그래서, 콜 스택을 차례대로 따라가본 결과, sub_427620 함수에서 헤더 검사 비슷한 것을 수행하는 코드를 확인했습니다.

여기서, sub_427620을 부른 함수를 보면, 헤더를 비교하는 듯한 코드가 있습니다.

19778을 16진수로 변환시켜서 텍스트로 나타내면 MB인데, dib 파일을 열어서 확인해보면 앞에 BM이라는 글자가 있습니다.

따라서, sub_427620은 파일 해석을 하는 부분인 것을 알 수 있습니다.

이제 이 함수를 조금 더 자세하게 살펴보겠습니다.

저 함수는, 우리가 임의로 수정했던 BITMAPINFOHEADER의 사이즈를 v44에 저장하는 함수입니다. 실제로 저 함수가 실행되고 난 뒤에 v44 값을 보게 되면 0x1f28로 수정되어 있는 것을 확인할 수 있었습니다.

그 뒤에는 가져온 크기 + 0x40c 만큼 메모리를 할당해줍니다.

그 다음, BITMAPINFOHEADER 시작 부분부터 size만큼 읽어서 header에 저장합니다. 앞에서 size+0x40c 만큼 할당을 해두었기 때문에 오버플로우는 발생할 수 없습니다. 실제로, header 부분을 살펴보면 다음과 같이 입력한 데이터들이 저장되어 있습니다.

그 다음에는 Compression 관련 비교문이 나옵니다. 그러나 우리는 앞에서 Compression을 0x00에서 0x0a로 수정했기 때문에 이 분기 안으로 들어갈 수 있습니다. 분기문 안에서는 맨 처음에 Object를 할당하는 것을 확인할 수 있습니다.

그리고 뒷 부분에 할당받은 Object에 BitMap 정보들을 저장합니다.

새롭게 할당받은 객체에 비트맵 정보들이 저장된 것을 확인할 수 있습니다. 이제 취약점 부분을 살펴보겠습니다.

처음에는 v45에 Header 주소 기준으로 size만큼 뒤의 주소를 저장하고 분기하여 sub_41AAF0 함수로 가는데, 이 때 전달되는 값이 0x800입니다. 아까 header의 크기가 size + 0x40c였으니, 오버 플로우가 발생합니다.

데이터가 덮어지기 전 메모리 상태는 아래와 같고, 

 

덮어써진 후의 메모리 상태는 아래와 같습니다.

취약점을 찾았으니, 이제 익스플로잇만 하면 성공적인 실습이 될 것 같습니다. 중간에 스프레이라는 잘 모르는 개념이 나와서, 이와 관련해서 심도 있는 공부를 진행한 후 다시 시도해보겠습니다.