지난 2017년 11월, 마이크로소프트 오피스(Microsoft Office, 이하 MS오피스) 프로그램의 구성 요소인 수식 편집기(Equation Editor) 관련 취약점(CVE-2017-11882)이 알려졌다. 유독 이 취약점이 관심을 끈 이유는MS오피스 프로그램의 최초 배포 시점부터 존재해왔으나 무려 17년이 지나서야 알려졌다는 점 때문이다. 마이크로소프트(이하 MS)가 서둘러 보안 패치를 배포했으나 미처 조치되지 않은 부분으로 인해 또 다른 취약점(CVE-2018-0802)이 남게 된 것도 한 몫 한다.

이와 관련해 안랩 시큐리티대응센터(AhnLab Security Emergency response Center, 이하 ASEC)는 최근 ‘MS Office 수식 편집기 취약점 분석 보고서’를 발표했다. 안랩은 수집 및 공개된 CVE-2017-11882, CVE-2018-0802 취약점 샘플 파일을 이용해 이들 취약점의 발생 원인과 함께 유사성 및 차이점 등에 대해 상세히 분석했다.

CVE-2017-11882 취약점이 공개된 지난 2017년 11월 이후, 비록 많은 양은 아니지만 이를 이용한 악성 파일들이 종종 나타나고 있다. 해외에서는 2017년 연말 지능형 위협 공격(Advanced Persistent Threat, APT)에 해당 취약점이 이용된 것이 확인됐다. 국내에서는 기업을 대상으로 스팸 메일을 통한 관련 샘플 유포가 확인되었으며, 최근에는 외형적으로 기존과 약간의 차이를 보이는 변종도 확인됐다.

공격자가 해당 취약점을 악용할 경우, 현재 사용자의 관리자 권한으로 로그인해 임의의 코드를 실행할 수 있다. 이들 취약점에 영향 받는 제품군은 MS오피스 2007, 2010, 2013, 2016 등으로, 현재 시중에서 이용되고 있는 대다수의 MS오피스 제품군이 해당된다. 즉, 수많은 MS오피스 사용자들이 영향 받을 수 있으며, 이에 따라 이들 취약점의 심각도는 “높음(HIGH)”으로 분류되어 있다. 

연관된 취약점의 생성 배경

CVE-2017-11882, CVE-2018-0802는 MS오피스에 포함된 수식 편집기 프로그램, 즉 EQNEDT32.EXE 관련 취약점으로, 각각 2017년 11월과 2018년 1월에 공개됐다. 이들은 모두 메모리 손상 취약점(Memory Corruption Vulnerability)으로, EQNEDT32.EXE가 메모리상에서 특정 오브젝트를 적절하게 처리하지 못하는 과정에서 발생한다. MS는 CVE-2017-11882 취약점 해결을 위한 보안 패치를 발표했으나, 결과적으로 또 다른 취약점인 CVE-2018-0802가 존재하게 되었다. 이로 인해 MS는 자사 오피스 패키지에서 EQNEDT32.EXE를 제외하기에 이르렀다.

여기에서 주목할 부분은 [표 1]과 같이 CVE-2017-11882 취약점에 대한 보안 업데이트가 발표된 지 10여일만에 CVE-2018-0802가 보고되었다는 점이다. 이들 취약점은 모두 하나의 프로그램에서 동일한 원리, 즉 스택 오버플로우에 의해 발현되는데, 당초 배포된 보안 업데이트에서 잠재적으로 취약한 모든 부분에 대해 조치가 이루어지지 못했기 때문에 이러한 현상이 발생했다.

[표 1] CVE-2017-11882/CVE-2018-0802 취약점 타임라인

CVE-2017-11882 취약점이 처음 발견됐을 당시, 아래와 같은 EQNEDT32.EXE의 취약한 부분 2가지가 확인되었다.

•SUB_41160F() 내부의 strcpy() - CVE-2017-11882 취약점 관련

•SUB_421774() 내부의 SUB_421E39() 에서의 strcpy() - CVE2018-0802 취약점 관련

EQNEDT32.EXE에서 폰트 레코드의 폰트명을 처리하는 과정에서 strcpy()가 사용되는데, 문자열 복사 대상 버퍼는 32바이트로 선언되어 있다. 그러나 복사 과정에서 원본과 대상 버퍼에 대한 경계 체크가 이루어지지 않는다. 따라서 복사 원본 버퍼(폰트명)에 32 바이트를 초과하는 데이터가 존재하더라도 대상 버퍼로 그대로 복사되는 스택 오버플로우가 발생하게 된다.

한편, 위의 두 가지 취약한 부분 모두 strcpy() 사용 시 버퍼 경계의 체크가 없어 스택 오버플로우 취약성이 존재하지만 코드의 흐름 상 SUB_41160F()에서 먼저 취약점이 발생함에 따라 실질적으로 SUB_421E39()까지는 제어가 올 수 없는 구조였다.

지난 2017년 11월 배포된 MS 보안 업데이트를 통해 SUB_41160F() 함수에는 strcpy() 전•후 버퍼 크기를 확인하는 코드가 추가되었지만, SUB_421E39()의 strcpy()에 대해서는 조치가 취해지지 않았다. 더구나 업데이트 이후 기존에 문제가 되었던 SUB_41160F()를 자연스럽게 통과하여 SUB_421E39()까지 제어가 넘어올 수 있게 되면서 기존 취약점 유발 데이터를 조금만 조작하면 두 번째 취약점까지 악용하는 것이 가능해졌다. 이것이 CVE-2018-0802 취약점이다.

CVE-2017-11882, CVE-2018-0802 취약점 익스플로잇

CVE-2017-11882와 CVE-2018-0802는 서로 연관된 취약점이지만 이를 이용한 익스플로잇에서는 상당한 차이를 보인다. 요약하면, 2017년 11월 배포된 MS 보안 업데이트 적용 여부에 따라 이들 두 취약점에 대한 익스플로잇 발생 여부가 서로 엇갈린다.

[표 2] 보안 업데이트 적용 여부에 따른 익스플로잇 발현 여부

[그림 1] MS 보안 업데이트 적용 전(왼쪽)과 이후(오른쪽)의 EQNEDT32.EXE 속성

CVE-2017-11882 취약점은 MS 보안 업데이트가 적용되기 이전 버전의 EQNEDT32.EXE에서만 동작한다([그림 1]의 왼쪽). 그러나 앞서 언급한 것처럼 해당 보안 업데이트 적용 후에도 SUB_421E39()은 여전히 취약하기 때문에 해당 함수 내부에서 스택 오버플로우는 발생한다. 다만 익스플로잇은 제대로 발현되지 않는다. 리턴 주소를 덮어쓰기 위해 복사해야하는 데이터의 크기가 달라져야 하기 때문이다.

반면 CVE-2018-0802 취약점은 MS 보안 업데이트 가 적용된 EQNEDT32.EXE(2017.08.14.0 버전, [그림 1]의 오른쪽)에서만 동작한다. 이전 버전 환경에서는 SUB_421E39()이전에 SUB_41160F()에서 먼저 스택오버플로우가 발생하며, 이때 리턴 주소를 정확히 덮어쓰지 못하기 때문에 익스플로잇이 성공하지 못한다.

MS 보안 업데이트 적용 전후의 EQNEDT32.EXE 버전에 따라 이들 취약점의 익스플로잇 발현 과정과 결과에 대한 상세한 내용은 ASEC이 발표한 ‘MS Office 수식 편집기 취약점 분석 보고서’에서 확인할 수 있다. 이 글에서는 각 취약점별로 익스플로잇이 발생하는 버전에 관한 부분만 살펴본다.

CVE-2017-11882 취약점 익스플로잇

CVE-2017-11882 취약점은 보안 업데이트 배포 이전의 EQNEDT32.EXE(버전 2000.11.09.0)에서만 동작한다. EQNEDT32.EXE의 SUB_41160F() 내의 취약한 strcpy()는 [그림 2]와 같다.

[그림 2] EQNEDT32.EXE 내부의 취약한 strcpy()

MS오피스로 악성 문서를 불러오면 우선 정상적으로 폰트가 몇 차례 파싱(parsing)되며, 이후 악성 폰트 레코드 데이터가 복사된다. 복사되는 데이터는 총 0x30이며 마지막은 null(0x00)로 끝난다. 해당 데이터는 이후 쉘코드(shellcode)로 동작한다.

[그림 3] CVE-2017-11882 취약점을 악용하는 폰트명 데이터

[그림 4]는 strcpy() 호출 전후의 스택 변화이다. 원래는 0x20 크기의 데이터가 복사 되어야 하지만, 경계 체크 루틴이 존재하지 않아 [그림 4]와 같이 공격자가 의도한 대로 0x30 크기의 데이터가 모두 복사 되었으며, SUB_41160F() 호출 후 복귀할 리턴 주소가 덮어써진 것을 확인할 수 있다(@12F250 = 0x4115D8 → 0x40C4B1).

[그림 4] CVE-2017-11882 취약점 익스플로잇 성공 시 스택

[그림 4]에서 또 하나 주목할 부분은 리턴 주소 바로 다음의 값이다. 이는 SUB_41160F() 호출 당시 첫 번째 인자로 전달된 값이며, strcpy()에서 원본 버퍼의 주소(ESI)에 해당한다. 즉, 복사 대상이었던 0x30 크기의 쉘코드가 존재하는 주소다(익스플로잇 성공 시 분기할 주소, @12F254 = 0x12F3D0).

[그림 5] 쉘코드 분기를 위해 사용되는 리턴 명령어

SUB_41160F() 함수 종료 후 [그림 5]와 같이 0x40C4B1 주소로 리턴한다. [그림 5]의 메모리 상에 보이는 @40C4B1은 EQNEDT32.EXE 내부 SUB_40C46C() 함수의 종료 부분의 리턴(이하 RETN) 명령을 가리키고 있다. 실제로는 EIP에 직접 값을 대입할 수 없지만 이 RETN 명령으로 인해 이론적으로 POP EIP와 같은 효과가 나타난다. 현재 ESP 위치(@12F254)에 저장된 값(0x12F3D0)으로 EIP 값이 대체된다.

RETN 실행 후 [그림 6]과 같이 EIP가 0x12F3D0로 설정되며 코드 분기가 이동한 것을 확인할 수 있다. 이 주소 영역은 앞서 설명한 바와 같이 strcpy() 복사 원본이었던 0x30 크기의 쉘코드 시작 부분에 해당한다. 이후 Equation Native 스트림 내부에 포함된 추가 쉘코드로 분기가 이루어지며, 이에 따른 악성 행위가 수행된다.

[그림 6] CVE-2017-11882 익스플로잇 성공 후 쉘코드

2017년 11월 보안 업데이트가 적용된 EQNEDT32. EXE에서는 SUB_41160F()에 버퍼 경계 체크가 추가되었기 때문에 CVE-2017-11882 취약점이 동작하지는 않는다. 그러나 앞서 언급한 바와 같이 여전히 SUB_421774() 내부의 SUB_421E39()에는 취약한 strcpy() 가 그대로 남아있는 상태다.

CVE-2018-0802 취약점 익스플로잇

CVE-2018-0802 취약점은 보안 업데이트 적용 이후의 EQNEDT32.EXE(2017.08.14.0)에서만 동작한다. 공개된 POC 샘플을 이용해 CVE-2018-0802 취약점의 익스플로잇 과정을 살펴보자.

[그림 7]과 같이 보안 업데이트를 통해 취약했던 SUB_41160F() 내부에 데이터 크기를 검증하는 코드가 추가됨에 따라 원본 크기에 상관 없이 최대 0x20 크기만큼만 데이터가 복사된다. 즉, 계산된 문자열 길이가 0x21 이상인 경우, 0x20으로 길이를 강제 치환하기 때문에 더 이상 스택 오버플로우가 발생하지 않는다.

[그림 7] 보안 업데이트로 인해 수정된 데이터 복사 구간

그러나 해당 업데이트에서 수정되지 않은 SUB_421774() 함수에서는 내부의 SUB_421E39() 함수에서 여전히 strcpy()에 의한 스택 오버플로우가 발생하며, SUB_421774() 함수 종료 후 리턴 주소가 [그림 8]과 같이 변경된다.

[그림 8] CVE-2018-0802 익스플로잇 성공 시 스택

[그림 8]의 스택에서 주목할 점은 리턴 주소가 덮어써진 방식이다. 메모리 상의 @420025 위치에는 EQNEDT32.EXE 내부의 특정 함수의 종료 부분의 RETN 명령이 존재한다. 해당 RETN 명령이 실행되면 POP EIP와 동일한 효과가 발생한다. 즉, CVE-2017-11882와 동일하게 리턴 주소 바로 직전(@12F388)에 저장된 값(= SUB_421774() 호출 시 첫 번째 인자로 전달된 값(= lpLogfont = ESI = 쉘코드 시작점)으로 EIP를 변경하기 위한 방법이다.

이전까지는 RETN 명령어의 주소를 참조할 때 스택 오버플로우를 통해 리턴 주소를 덮어쓰는 값인 4바이트 주소를 전부 사용했다. 그러나 이번 경우에서 하위 2바이트의 상대적인 오프셋만 사용한 이유는 EQNEDT32.EXE의 ASLR(Address Space Layout Randomization)을 우회하기 위한 목적으로 보인다. 2017년 11월 보안 업데이트 이전 버전의 EQNEDT32.EXE에는 ASLR이 활성화되지 않았지만, 해당 보안 업데이트를 위해 새로 빌드된 EQNEDT32.EXE 에는 ASLR이 적용된 상태이기 때문이다. 

CVE-2018-0802가 제대로 동작하기 위해서는 2017년 11월 보안 업데이트가 적용되어야 한다는 전제 조건이 존재한다. 즉, 해당 익스플로잇이 동작할 EQNEDT32.EXE 환경에서는 ASLR이 활성화된 상태이며, 따라서 해당 프로그램/코드가 메모리 상에 로드된 베이스 주소를 보장할 수 없다. 이러한 환경을 극복하기 위해 전체 주소(4바이트)가 아닌 상대적인 오프셋(2바이트)만으로 RETN 명령이 있는 주소를 찾아 사용한 것으로 보인다. 

RETN 명령으로 인해 EIP 전환이 이루어지면 [그림 10]과 같이 strcpy() 시에 ESI로 사용된 @12F3D0 위치로 코드가 분기하여 쉘코드가 실행된다. 

안랩 V3 제품군에서는 CVE-2017-11882 및 CVE2018-0802 취약점 관련 악성코드를 다음과 같은 진단명으로 탐지하고 있다.

<V3 제품군 진단명>

RTF/Cve-2017-11882

RTF/Exploit

RTF/Shellcode

X97M/Downloader

PDF/Dropper

알려지지 않은 취약점의 위협

MS오피스 수식 편집기(EQNEDT32.EXE)의 취약점 CVE-2017-11882와 CVE-2018-0802는 프로그램 최초 배포 시점부터 존재했음에도 불구하고 배포 후 17년이 지나 보안 연구가들이 발견할 때까지 알려지지 않았다. 해당 취약점이 발표된 이후 악성코드 제작자들은 공격적으로 이를 이용한 악성 파일을 제작, 배포

하는 사례가 다수 확인되고 있다.

MS오피스 수식 편집기 취약점 사례는 우리에게 시사하는 바가 크다. 오늘은 별 문제 없이 사용하고 있는 프로그램이라도 아직 알려지지 않았을 뿐 다수의 약점이 존재할 수 있으며, 언제라도 공격에 악용될 수 있다는 것을 내포하고 있기 때문이다.

알려지지 않은 취약점에 의한 보안 위협의 피해를 방지하기 위해서는 프로그램 제작사, 사용자, 그리고 보안 관계자의 노력이 동반되어야 한다. 프로그램 제작사는 지속적인 모니터링과 더불어 제품의 취약점 보완 시 미처 해결되지 않은 취약한 요소가 존재하지 않는지, 혹은 예상치 못한 영향은 없는지 더욱 신중하고 면밀하게 검토해야 한다. 사용자들은 최신 보안 업데이트를 적극적으로 적용하는 습관이 필요하다.

기업과 기관에서는 알려지지 않은 공격에 대한 대응 방안을 마련하는 한편, 다양한 운영체제 및 소프트웨어 프로그램의 보안 패치를 효율적으로 적용할 수 있어야 한다. 또한 보안 관리자는 평소 취약점 및 보안 업데이트 소식에 관심을 가져야 한다. 최근 많은 보안 연구가들이 취약점뿐만 아니라 보안 업데이트에 대한 분석을 수행하고 있으며, 업데이트로 인해 어떠한 부분이 변경 되었는지, 또 취약한 요소를 제대로 보완하였는지 등에 대한 상세한 자료를 공개하고 있다. 여기에 안랩을 비롯한 주요 보안 업체 및 관련 기관에서 제공하는 위협 인텔리전스를 적극적으로 활용하는 노력이 필요하다.

CVE-2017-11882, CVE-2018-0802 취약점에 관한 보다 상세한 내용은 안랩 시큐리티대응센터(ASEC)가 발표한 ‘MS Office 수식 편집기 취약점 분석 보고서’

에서 확인할 수 있다.

▶ ‘MS Office 수식 편집기 취약점 분석 보고서’ 더 보기​